I'm letting thebrainroom.com lapse this year after holding it for 11
years. For those that weren't with me back then, The Brain Room was my
consulting company, providing graphic and software design services.
When I joined OmniTI, I chose netevil.org
to use for my blog in a kind of self-mocking move; I equated my efforts at
taking over the world with superior software with the effectiveness of Dr.
Evil. A lot of people thought I was styling myself after Dr. Evil, which
wasn't quite right, but close enough :-)
Since I've been going around updating my account information with various
services, I thought a change would be in order. I'm of the opinion
that one should use their own name as part of their internet persona,
I finally got a domain that did just that.
So here we are: wezfurlong.org. I've
taken the opportunity to give things a really minor facelift, and also
migrated comments to the Disqus service.
The move may cause a re-post of some of my articles to aggregating
services; I apologize for that. netevil.org is not going anywhere anywhere
soon, but if you have me on file using thebrainroom.com, you will need to
update your information to wezfurlong.org instead.
Some of the feedback and questions that I've gotten about mtrack were around making it easier to deploy and use in an open or public facing environment.
To that end, I've added support of OpenID authentication and bot detection via reCaptcha.
To enable these features is quite simple; for OpenID, add the following lines to your config.ini file:
[plugins] MTrackAuth_OpenID =
You should also remove any other Auth plugins that you may have there, as how they interact with OpenID is not currently defined.
This will cause mtrack to keep users classes as anonymous until they either request to log-in via a link in the navigation bar, or attempt to access a page that requires privileges that the anonymous user lacks.
Users authenticating via OpenID can contribute to tickets and wiki (unless you change their permissions, either directly, or via their user class), and those changes will be attributed to them using their OpenID identity URL.
mtrack has a system for aliasing users from different repos and authentication schemes, so if you had a code contributor named "wez" in one of your repos, an administrator can add their OpenID URL as an alias via the user administration screens. The admin user would edit the "wez" user and add "http://netevil.org/" to the list of aliases. This will cause mtrack to see that OpenID as being equivalent to the "wez" user.
You can, if you wish, make an OpenID URL recognized as an admin user by adding the following lines to your config.ini:
[user_classes] http://netevil.org/ = admin
This will have the effect of giving me admin rights to your mtrack install.
What about captchas?
Captcha's allow you to require that the person submitting a request be a human and not an automated submission agent. In practical terms, this helps to avoid spam by limiting it to human spammers instead of spam bots.
Where pubkey and privkey are your public and private keys respectively (you must not use double quotes).
This will cause a captcha to be displayed and checked in the wiki and ticket editing screens for anonymous and authenticated users; admin users will not see the captcha.
I don't know if it's just me, or whether everyone in software development finds issue tracking software frustrating and/or broken in some way. They're all either way too complicated to set up, configure or use (the Bugzilla's or the Jira's), or have annoying "features" (such as Trac's you-lose-your-edits-if-someone-else-changed-something).
We've been using Trac at Message Systems for several years now and have been enjoying its pragmatic approach of keeping the interface simple but expressive; just enough structure to be helpful but not too much that it intrudes. We've added/modified a couple of plug-ins to it to help track time and draw some graphs, but it has otherwise served us well.
However, we've got a couple of projects that have started to converge and overlap and it's frustrating to visit the two different portals to interact and stay on top of things. As we scale up our development teams even further (we continue to have bigger and bigger plans!) this will prove to be more widely frustrating.
Enter mtrack; on one hand it's a clone of many of Trac's features (possible due to their pragmatic BSD license), but on the other it has some refinements in terms of its workflow. What's important to me is that it is built to work with multiple code repositories and allows breaking out information on a per project basis. It also tries hard to avoid losing your wiki or ticket edits if someone else updates things while you're working.
I chose to implement mtrack in PHP rather than continuing to extend Trac in python. My primary reason for this is that I've seen web apps written with Perl and Python, and while there are certainly guru developers out there that can build some awesome apps, those languages don't really lend themselves to web development and that limits the scope of potential contributors. While I can probably persuade some of my colleagues to code python web bits, I'll find it much easier to persuade more of them to code PHP web bits. I'm sure this property extends outside of our organization.
We've been running our engineering department on mtrack for a couple of weeks now (after a period of running it in parallel to Trac) with just under 20 or so people using it actively as part of their day-to-day activities, so I feel comfortable in making this blog post to solicit input from the broader community, both in terms of suggestions and bug reports as well as potential contributions.
While I am soliciting feedback, I'd like to emphasize that this is still relatively young and that there is no support and no warranty; if you are the cautious type, this is not the time to try mtrack.
And now for some Anticipated Questions to pre-empt FAQ:
Trac style wiki syntax (all of its core syntax is supported)
Subversion and Mercurial repository integration (API extensible to other VCS)
Email notifications batch related information together to reduce the amount of mail you need to read; if you make 5 changes relating to a ticket in a 5 minute period you get one email with all 5 changes in it, instead of 1 per change. Code changes that reference a ticket generate a single email with the ticket changes and the diff, not a separate email for each.
Issue tracking with configurable components, priorities, severities, milestones.
Define "projects" and associate components and paths within repositories with them to control who gets notified of changes.
Flot based graphing of Scrum burn-down based on time estimates and recorded effort
Wiki edits have in-built conflict resolution and the Issue tracker tries hard to behave reasonably in the case where multiple people are working on the same item.
Uses the Gravatar service to add some personality throughout the application.
Includes an importer to migrate your Trac project(s) into mtrack.
Has a plugin/hook API to support both core and external enhancements.
Uses the Zend Framework Lucene implementation for full-text search capabilities.
Why didn't you use <Name of Framework>?
Frameworks can increase development overhead and I wanted to get this done. Also, if I had used a framework, I would have to defend my choice against the others ;-). I am not morally opposed to contributions that adopt a framework, but would want to carefully assess the impact on longer term maintenance before doing so.
By trying it out; I'm looking forward to hearing suggestions, comments and bug reports. Please file them in the issue tracker: http://bitbucket.org/wez/mtrack/issues/?status=new&status=open and keep in mind that you may not get a response until the following weekend (or even longer!) due to my busy schedule
By fixing bugs; if you've found and resolved an issue and want to pass a patch back to me you can do so either by attaching the patch or details on how to get at the patch to the issue tracker. I recommend doing this by keeping your own fork on bitbucket as it makes it much more convenient for both of us.
By building out and sharing new features; I'm very open to adding new features. My preference is to enable those by making the core modular enough that new features don't have to be part of the main mtrack code to be used by it. This will keep the the core light and make it easier to share modules.
By fleshing out docs. I'm the first to admit that mtrack could do with more documentation.
I also wanted to share some of my thoughts on why PDO has been in a holding pattern for a while, so that more people are aware of it and can work to avoid repeating the same mistakes.
The first thing to note is that the guts of PDO were hard to develop. The PHP script facing API sounds simple enough, but the underlying libraries for each different databases work in different ways, and it was and is a challenge to build PDO in such a way that it can work in the most efficient way.
The second thing, which is really a follow-on from the first, is that the database libraries are complex and nuanced. Some are relatively simple (especially SQLite and MySQL) and others are complex in divergent ways (ODBC and Oracle). Making a great PDO necessitates having experts in each of those APIs and databases around as contributors, both for the core implementation and for unit tests.
Thirdly, there are a lot of databases out there. That requires a lot of resources for the PDO developers to do a good job; not just different database products, but also different versions of those products, need to be tested against. This is also very time consuming.
This boils down to a lot of effort.
Personally, I enjoy working hard. Tricky problems are the most satisfying kind to solve! However, working hard when there is no payoff is the least enjoyable kind of work.
For a successful PDO, there needs to be "payoff" for the contributors to keep them happy and working at it. In a commercial context, where someone sponsors development, the payoff is typically in the form of a paycheck to help cover the bills. In a FOSS context, the payoff may be satisfaction from working on hobby coding, may be vanity in wanting recognition and appreciation from peers or end-users or may be seen as effort to help build out a resume for future career opportunities. There may be other motivating factors too.
I've talked in the past about FOSS being "Itch Driven Development". So long as the contributors feel the need to scratch their respective itches, they'll keep on doing it. They'll stop if the itch goes away, or if the scratching leads to bleeding.
Bleeding is stuff that detracts from or otherwise lessens the payoff. In a commercial context this could manifest as something that wastes time (and time is money). In a FOSS context, this may also be the result of vocal and/or abusive or otherwise negative sentiments from peers or others in the community.
Bleeding is bad for the whole group because it can take a long time for those that were bleeding to want to try their hands at scratching again. Whatever form the renewed PDO development takes, it would do well to try to avoid bleeding. One way to do this is to follow the advice of Bill and Ted and "Be Excellent To Each Other".
At the end of the day, PDO (and PHP) is largely a volunteer effort, which means that it is something that will be worked on in the spare time of the contributors. Because it is hard work, the payoff needs to be enough for them to individually opt to work on it after a hard day at work instead of choosing alternatives, like family, beer or Xbox.
If you're willing and able to help improve PDO by contributing development effort and/or unit tests, please make yourselves known on the PDO mailing list. We need a critical mass to reduce the effort that any one person needs to make, and once we have momentum on our side, I think that PDO can be improved rather rapidly.
A few of my friends and associates may have heard me talk about the media server I've been running in my basement; I used to automatically transfer content from my tivo to a hard-disk in my basement so that I had more space for recordings on the tivo. Since most of the recordings that I want to keep are now available via Hulu, I haven't had much call to use it in the last 6 months.
So, what is CouchShare? It's a UPnP server that can share content from folder to an XBox 360 on your network.
It's written in PHP (and requires a tiny PHP extension to enable multicast support) and is written using the eventing framework that is part of the Alexandria codebase.
I wrote the code back in 2007 and it has served me well for a couple of years; it felt like it was about time I got off my backside and shared it with the world.
It is by no-means a polished bit of code; I think it's probably the sloppiest code I've written in quite some time, and it may well need a couple of tweaks to make an easier application out of it.
So, have at it: I've put the code up on bitbucket and I welcome code and documentation contributions!
It's been a simultaneously long and fast week for me. I flew into Chicago last Sunday, ready for the PHP core developers meeting that we had planned for the Monday and Tuesday. My journey went like a charm; perfect timing had me parked at the airport, immediately on the shuttle bus to the terminal, straight through security and to my gate just in time to start boarding. The only minor hiccough was in finding the shuttle from Chicago to the hotel; it was extremely poorly sign-posted.
Anyway, I got to the hotel and ran into the British contingent of the conference, and we eventually found our way to a Mexican restaurant not far from the hotel, and then to the bar across several lanes of traffic from the hotel, where a fair quantity of alcohol was consumed by all.
The next day we headed downtown to the Microsoft offices for day 1 of the core developer meeting, where a number of internals issues around PHP 6 were discussed. This was a very productive session, and we earned the drinks that followed at the Map Room, although I opted out of the bulk of those and headed back to the hotel (yes, I'm getting old)
Tuesday was day 2 of the core developer meeting, and thankfully was held in the conference hotel; the journey downtown took the better part of an hour and I was glad to skip it. The agenda for this day was to look primarily at what we could clean up in the code for PHP 6 and whether we might need to introduce a PHP 5.4 to aid in that transition.
We also touched on PDO 2; the short of it is that it might be about time to see if the vendors are willing to play with us again, and where the original plan was to have all the major vendors on board, we may well be looking at cutting out the less flexible vendors from the baseline PHP distribution. I'll do what I can to help facilitate a PDO 2, but don't anticipate having much free time in the coming months.
After a low-key dinner in the hotel sports bar (thanks Chris!) I retired to my room to catch up on a bit of work and put some finishing touches on my presentation deck. I returned to the bar a bit later to see who was around, and was surprised that most folks had turned in early; another sign that we're collectively getting older.
Wednesday was the start of the conference proper, and Andrei's keynote reminded us of the humble beginnings of the world-wide-web and took us through the various incarnations of PHP-past as a lead-in to PHP 6. As is usual with Andrei's sessions, I was left feeling a little jealous of the beautiful photography and humor he manages to find to complement what would otherwise be a somewhat dry technical presentation.
Later in the afternoon, it was my turn to present my new talk, which is partly best practices (really what I consider to be the baseline practices for any serious commercial development shop) and partly a re-hash of an internal presentation I gave to my team at Message Systems when I became Director of Engineering. I was pleased (perhaps even a little surprised) to find that I had a very full room for the talk, and happy that I seemed to keep everyone well engaged through to the end. I've had some good feedback and welcome constructive criticism so that I can improve it for the next time I use it; you may comment (anonymously if you wish) via the joind.in page for that session.
I sat in on Maggie Nelson'stalk on ORMs, which was an interesting comparison of PHP ORMs. Personally, I think that ORM is one of those niceties that is, unfortunately, a bit too far divorced from the ugly reality of making things work well under load in the real world. There are some articles out there on the impedance mismatch that leads to most of the problems, and some interesting work from my colleagues at OmniTI in the form of a Relucant ORM for Perl that avoids the major pitfalls.
After dinner, an open bar and a series of lightning talks put pretty much everyone in high spirits (that and consuming spirits...) that carried over into the wee hours of the following morning.
The next morning was largely playing catchup for me; both with some work and with various folks around the conference; new acquaintances and old friends. I was interviewed by Keith Casey about what went on in the PHP Developers meeting, and I think this is my first appearance on YouTube (and don't I look a little caffeine deprived?)
I caught Lorna Mitchell's session on Linux-Fu for PHP Developers which made me think that the growing number of self-taught Linux users, and the common develop-PHP-apps-on-windows-deploy-on-unix scenario does warrant some attention on what might be considered fairly basic unix know-how from PHP conference organizers. It was a good session and well presented.
After lunch, I had the (somewhat dubious!) pleasure of experiencing Eli White's gratuitous use of Knight Rider clips to highlight that you can make just about any programmer better if you give him the right tools.
The final session I attended was Chris Cornutt's session comparing a number of the popular PHP frameworks, which I found to be quite a useful comparison of their strengths. There was some drama towards the end when rival framework proponents in the audience had a somewhat heated discussion between themselves.
And shortly after that, I set out on my journey home, which was sadly rather more traumatic that the outbound journey, starting with a hot and sticky Chicago airport, a slightly delayed flight, which also had faulty air conditioning and the coup-de-grace in the form of a dead battery and faulty alternator in my car (actually Juliette's car; I let her use my car while I was away).
After a couple of assists from the airport transportation folks and local police(!), I got the car running and re-enacted my own version of the movie Speed, except that I had to keep the engine revving above 2000rpm or my electrics would fade out and the engine stall. This had me riding both the accelerator and brake pedals at the lights around the airport before I could get out onto the highway; something I think would have been easier to deal with if the car had been a manual transmission.
As ever, it was great to catch up with the usual suspects, and also to finally meet some of the younger blood in the PHP community face to face. I don't know if it's just that the majority of my fellow speakers are becoming increasingly senior in their respective jobs, or if there has been something of a shift in the industry, or if it's just me being focused into more of a managerial role in recent times (or some combination of these), but it seemed to me that there was more of a focus or awareness on practical engineering at this conference than I recall in past conferences.
I think this is a good thing because the typical PHP developer does not usually have a rigorous background in computer science or other "equivalent" scientific or engineering discipline. A few of us had a lunchtime discussion about how even the schools that are teaching computer programming tend to be skimping on applied software skills (the meat and potatoes of getting the work done, rather than just the raw programming theory), and how programming as a profession could benefit from having something akin to an apprenticeship scheme. It will be interesting to see where this train of thought leads.
Anyway, in summary: php|tek 2009, two thumbs up.
Thanks to Microsoft for hosting part of the developers meeting, Marco, Elizabeth and Arbi for the rest, Keith for the unconference, everyone whose photos I've linked in from flickr, and everyone else that attended for making the event what it was. I'm looking forward to the next time that I can attend :-)
I'm usually no big fan of chain letters (it's the "or-else" part that I object to), but this current 7-things-tag going around is pretty benign, and I think it's a great way to get some insight into the people you're reading. Thanks to Elizabeth Smith for tagging me.
Anyway, here's some facts about me that you may not know:
I have 6 siblings: 1.5 brothers and 2 sisters.
I used to live in Spain and crossed the border to Gibraltar twice daily getting to and from school.
I taught myself 6502 machine code on the C64 when I was 10. 'C' had to wait until I finally got my own Amiga at the age of 17; by that time it was already obsolete, but I'd dreamed of it for so long. The biggest barrier for learning 'C' for me was the sheer quantity of bad Intuition code examples floating around on Fish Disks and Aminet.
I studied Electronic Systems Engineering at The University of York, where I discovered my first Unix system (IRIX) and had to retake my first year exam as a result of spending too much time in the "Spod Pit" (a room filled with Indigo workstations). In retrospect, that "inappropriate" use of time was instrumental in shaping my career.
I once rolled into a 9 a.m. computer lab assessment with my partner wearing tuxedos after partying all night at a graduation ball. The lab supervisor said "let's assess you first, as you look like you've got places to go". (We aced that assessment; preparation was key).
I've moved home on average about once every 2.5 years of my life, making my time in the USA one of the longer periods in one spot.
I've been told that I have a distinctive look, which is probably largely due to my long hair. In the late 80's, early 90's, I used to have a flat top. Then I discovered Guns'n'Roses and Metallica and haven't worn my hair short since.
As for chaining, in no particularly significant order:
I treated myself to a Kindle a couple of months ago, and I'm pleased to say that I've been enjoying it a lot. I've read just over a half-dozen books on it so far; some at home and some while traveling.
At first, the page turning buttons are a little frustrating because it is very easy to accidentally press them. This is something you train yourself not to do in pretty short order.
The screen is very clear and easy to read, and has a configurable font size to cater for the eagle eyed through to the bleary eyed. There's no back light, so you need to provide your own illumination, just as you would for a regular dead-tree book.
I've found it very easy to read. I'd read in some reviews that the visible page refresh takes a second or so when you turn a page, and that some people found that annoying. I view that as being equivalent to actually turning a page and giving your eyes a moment or so to move back up to the top left of the screen. I've started to press the "next page" button as I'm reading the last line; this is an unconscious action.
The online store integration works well; you can literally pick out a book and have it appear on the device within a minute. I find this especially appealing if it's the weekend and I don't feel like taking an hour out to drive down to a book store, but it's also good if I finish a book while I'm on the road, particularly because I don't then have to lug an extra book or two back home at the end of the trip.
The battery life is excellent if you remember to turn off the mobile antenna when you're not using it. I've been purchasing a book or two before a trip and been reading for several hours on the plane in each direction and an hour or so each night for several days on a single charge, and the battery is still only about half-way done when I arrive home.
While I was in the UK, I was unable to use the wireless antenna to access the store, but I did download a couple of books to my laptop and copied them across via USB (you can mount the kindle as a mass storage device).
My only real annoyance with the device is the page turning buttons; they're quite easy to nudge as you're settling down to read, so you have to click the button for the opposite direction to correct that.
So, in all, I'm really enjoying the device; a little pricey, perhaps, but it's the kind of thing I've been waiting for for several years--definitely way ahead of reading ebooks almost half a decade ago on my old HP iPAQ.
