CruiseControl.NET and Subversion Revision Labeller plug-in

Last year, I finally managed to get into automated builds at work. We write a lot of platform code for the other business units in our organisation, so any bugs/defects have quite a high visibility; what could be a better way of improving the transparency of our processes than having an easily accessible automated build system, which would not only compile and test our code, but create release/deployment packages, all before we had even arrived at the office? It didn't take too long to get CruiseControl.NET up and running, using a fairly typical open-source blend of Subversion, NAnt, NAntContrib, NUnit etc etc, whicb should all be familiar to anyone who has read Open Source .NET Development, which should really be required reading for all .NET programmers. Using NAntContrib's <version> task, it's easy enough to automatically set the version number in an assembly. What it didn't allow us to do was pass that information back up to CruiseControl for display in the web dashboard or the system tray application for more immediate feedback. So I decided to knock up a plug-in to do just that. I'd already played about with plug-ins for open-source applications, so it wasn't quite so much of a big step. So in October 2006, I posted to the ccnet-user group, announcing the creation of the plug-in, inspired by a blog entry by Jonathan Malek. I got a response from Richard Hensley, who was putting together a library of plug-ins, suggesting I might want to add my code to his library, but unfortunately I haven't had any response to my emails. So I thought I'd take matters into my own hands, and post directly to the CC.NET community site; you can imagine my surprise when I saw that someone else has, fairly recently, also uploaded a Subversion revision labeller! Fortunately, there are enough differences between the two to make it worth uploading; so I now have two contributions to the open-source community, both small and specific to my job, but hopefully useful enough for others to use. Now I just have to get the NAntContrib guys to actually include mine in the builds...

Truck vs. Parked Car

So Thursday was shaping up to be a day from Hell. At work, what should have been a simple web application deployment dragged itself out into an all-day affair, first with configuration issues at our end, then with web services that we communicate with and so on. I finally decided that I had enough around 6pm and headed for home, dreading a repeat of Wednesday's rail SNAFU.

Actually, the journey home turned out well enough; however, I wasn't expecting this when I got off the train. I guess one of the lorry drivers who visit the industrial park at the other end of the road was in a hurry and misjudged the size of the corner just behind me. Of course, they didn't leave a note or anything.

Oh well, just as well I wasn't planning on buying a plasma screen in the near future...

The Path of the Jedi

Jeff Attwood has been discussing the geek ethic of building your own PC, particularly in relation to Google's use of commodity components.

We aren't typical users. We're programmers. The x86 commodity PC is the essential, ultimate tool of our craft. It's the end product of 30 years of computer evolution. And it's still evolving today, with profound impact on the way we code. If you treat your PC like an appliance you plug into a wall, you've robbed yourself of a crucial lesson on the symbiotic relationship between software and hardware. The best way to truly understand the commodity PC is to gleefully dig in and build one yourself. Get your hands dirty and experience the economics of computer hardware first hand-- the same economics that have shaped the software industry since the very first line of code was stored in memory.

I'm definitely singing from the same hymn sheet. Every PC I've owned has been built from the ground up, from a Texas Instruments 486-clone CPU to an Intel Core 2 Duo; the day that I buy a desktop PC is the day that some kindly men fit me out for a white canvas jacket that does up at the back. (Laptops, of course are a different matter). Naturally, rolling your own does lead to other problems, particularly in the tricky realm of hardware compatability. I've built some pretty unstable PCs in the past, where the motherboard doesn't like a particular sound card or graphics card, and the typical DIY-er doesn't really have the luxury of experimenting too much, at least if they're paying for everything themselves. My current interest is in media centres, and I'm reaping the benefits of Intel's VIIV campaign, at least in the interaction between MCE2005 and the hardware (the less said about the special 'content' the better, because as is sadly typical, countries outside the US don't actually exist) P.S. In case you're wondering about the heading, it comes from one of the comments on Jeff's posting:

It's the whole Jedi build their own light saber bit.

While I might not claim Jedi to be my religion when the census forms come round, the man has a good point.