Working with bugs

No, this is not a post on entymology; rather, it’s a bit of a lament on the lost art of filing bug reports. Though they may bestride the programming world like a colossus, even the best programmers will eventually leave bugs in their code. Sooner or later, some poor user will fall foul of it.

You then have a number of solutions, depending on where the product came from. For a commercial product, you can:

1. ignore it and hope it goes away;
2. file a bug report, and hope that the provider will fix it;
3. find some sort of workaround, or just learn to live with it;
4. vote with your wallet, and switch to a competitor’s product

For an open-source product,, you have an extra option:

1. download the source code, and fix it yourself, and preferably submitting your fix back to the community.

In my case, it was a bug in a Microsoft development tool, the succinctly named Microsoft Visual Studio Team System 2008 Database Edition GDR R2. As an aside, let me say that I’ve been using it for all of 2 days, and I absolutely love its functionality. It finally makes versioning and deploying databases a delight rather than a painful chore. There is now no excuse for organisations not to have their databases under version control, or for having painful manual deployment processes.

Anyway, it has a bug in it which is holding up a particular project at work. I searched for a solution, and found someone who had reported the same issue some 9 months ago. Unfortunately the bug report that they filed was so lacking of information that Microsoft promptly closed the bug as Not Reproducible. In fact, it’s not 100% certain that the bug relates to my issue because it is so light on details – it just reports the same error message.

As it happens, the steps required to reproduce the bug were incredibly trivial, so I opened a new bug, and gave the sort of details that a developer trying to fix a bug needs to see – in other words, I described what I was doing, what I expected to see happening, and what actually was happening. More to the point, I list the steps that the developer should take to make the same thing happen for them.

The first step to being able to resolve a bug is to be able to reproduce it. If you can’t reproduce it, how can you work out what is going wrong, and how can you prove that you’ve fixed the bug? And if the bug reporter doesn’t tell you how to reproduce the bug, what chance do you have of being able to fix it?

So please – if you want your bug to be fixed, consider the poor developer who has to fix it, and tell them what they need to know to get the job done. Anything less, and you’ll have a 9 month wait before someone else with the same problem files the same issue again.

Weird Sydney morning weather

The joys of parenthood include many early mornings. This is what awaited me this morning when Samuel woke us up. Most freaky! Any ideas what's causing this?

Update : apparently it's a dust storm. Western Australia is missing several hundred tonnes of dust and topsoil.

iPhone on 3

When the iPhone 3G was originally released in Australia, I and many others complained that 3, who provide some of the best 3G data plans in the country, did not sell it. There were ways around it,which kind of suggest that it was a problem at Apple's end rather than 3's, but it seems that with the release of the updated iPhone 3GS, users of the 3 network are finally getting some Apple love. And of course, it's at this point that I notice that my elderly Nokia N95 8Gb is finally fully supported by OS X, including syncing from iTunes and iPhoto. Now where was that a year ago when I really needed it? Never mind; just as soon as I can sell a kidney on Ebay, I'll have his'n'hers iPhone 3GS's, and the Nokia can go in the phone recycling bin.

SvnRevisionLabeller makes its v2 release

Recently Thoughtworks started to make available release candidates for version 1.4.4 of CruiseControl.NET. Tucked away inside there though are some changes to some of the core components, that break compatibility with SvnRevisionLabeller.

This gave me the proper motivation to find some time to finish off the packaging of a fairly major change to the way the labeller constructs build labels. The real work was actually done by another developer, fezguy - I just had to integrate his patch, tweak it to the way I like things (hey, it is my project after all!), and finally start work on some automated tests. I like automated tests.

Since the two changes combined do break backwards compatibility, it's good to take a step back and see where we are now.

Before, SvnRevisionLabeller was quite opinionated about how it thought build labels should be structured. With version 1.1, it was {major}.{minor}.{svnRevision}.{build} - {build} would start at 0, then if you forced another build without another commit having taken place, it would be incremented by one. A commit would then reset {build} back to 0, so you had a good idea how often the build was being forced. I later added the ability to specify prefix and suffix text for the label.

Version 1.3 saw me rethink things a bit, with the label now defaulting to {major}.{minor}.{build}.{svnRevision}; now, successive forced builds made no difference to the label. What it did give me was that when I deployed a hotfix to production (usually designated by the incremented {build} number), I could tell immediately which Subversion revision it was built with.

So it obviously works the way I wanted it to - but what about other people? Version 2.0 makes the label scheme very flexible - some tokens are defined, and you just position the tokens wherever you want them in a string pattern. So for instance, if I set my configuration thusly:

<labeller type="svnRevisionLabeller">
<major>1</major>
<minor>4</minor>
<build>2</build>
<pattern>Release v{major}.{minor}.{build} from {revision}</pattern>
</labeller>

then when revision 42 is committed, the build label will become Release v1.4.2 from 42. At work, I use the {build} number to represent the sprint number since we began working on the {minor} release.

Finally, I noticed that my project was not the only one to be caught out by CC.NET's upgrade - Codeplex's CC.NET Community Plugins are also broken by the change; unfortunately, they have a little more work to do, as it's not just a question of updating their external libraries and recompiling. I'm rather underwhelmed by the amount of activity on the site: I raised an issue earlier this month, and then submitted a patch to fix the issue, and it still hasn't been acknowledged yet, let alone added to the repository. For the time being, I won't be upgrading to v1.4.4 at work, since we need that library for our deployments.

An afternoon at Lake Parramatta

The Easter weekend was a good opportunity to get out of the house for a while and enjoy some of what Sydney has to offer. Several friends have recommended Lake Parramatta, a small dam and reservoir less than 10 minutes from our house, but we've never been there before. It was built in the late 19th century to provide drinking water for Parramatta, but these days it's a recreation area. It's sometimes swimmable, I think they're still working on the general cleanliness of the water (lots of stormwater drains etc empty into the catchment area).

There's plenty of parking etc at the entrance, barbecue areas, covered seating, even a playground for the little 'uns. It was quite busy considering sunset was less than an hour away, lots of families having picnics and so on.

We took a brief walk round the easy part of the reservoir, down to the dam wall itself. There's a small creek at the base of the dam, with some pretty lush vegetation from the water that trickles down from the dam (although the picture above doesn't explicitly show it, the wall is constantly damp, as the water finds its way through and down).

The creek at the bottom is crossed with a line of stepping stones. There's a lot of brown algae in the water, so it doesn't look very pleasant, but I think I got enough of an angle above so that it doesn't show. The full circuit around the reservoir is about 4.2km (I did say it was a little reservoir!), and although some of it is paved and flat, some of it requires a bit of a scramble. We'll have to save that for another time, because we got there not long before sunshot, and also because Emily is a bit too pregnant to be climbing anything at the moment.

MassTransit

Earlier this month, I mentioned the MassTransit project, an open-source .NET Enterprise Service Bus implementation, a topic sure to break the ice at a many a party.

We've been getting stuck into MassTransit at work for a major project, and had all sorts of problems along the way, mainly due to the youth of the project and the general lack of documentation. Where there were code samples, sometimes the code just plain didn't work.

The two main developers, Dru and Chris, have been a fountain of knowledge and general helpfulness, responding quickly to my sometimes continuous barrage of questions, not helped of course by our being on opposite sides of the planet. I've been able to chip in with the occasional patch, nothing to fancy at this stage, but at least enough for me to feel like it's not a completely one-way street.

Anyway, congratulations to MassTransit for shipping their v0.6 release candidate. I've been running it for a few days now, although without using some of the cooler pieces of new technology, such as the saga state machines. Hopefully with their help, I'll be able to get our project back on track and heading in the right direction.

Topshelf

At work, I'm currently working on a project which requires the integration of several different systems, some of them hosted on the internet, and some on different sides of the corporate firewalls. This means that we can expect to lose connections between systems, which naturally pointed us in the direction of message queues, which are designed for such scenarios. A chat with a former colleague pointed me in the direction of enterprise service buses as the core technology to take care of all the plumbing; and after comparing feature sets with our requirements, I downloaded MassTransit.

What interested me was a spin-off from the MassTransit project, called Topshelf, which has a single and simple aim - to get rid of all the cruft associated with actually launching .NET programs, especially all the boilerplate code you have to come up with to run services.

I ran into a few issues though: the first was that before, I had been using the WiX's ServiceInstall code to handle all the service registration, such as setting the service name, description and credentials. However, Topshelf provides its own code to do that, and the two aren't compatible. In the end, the solution I came up with was to remove the WiX code and use Topshelf's, which would be invoked by a custom action in the WiX script:

<CustomAction Id="InstallService" FileKey="ServiceExe" ExeCommand="/install" />
<InstallExecuteSequence>
    <Custom Action="InstallService" After="InstallFinalize" />
</InstallExecuteSequence>

FileKey is just a reference to the Id of the executable for the service, and ExeCommand contains the parameter(s) to pass to it.

All well and good, but unfortunately, Topshelf's implementation currently launches the same dialog box that installutil does, and if you're trying to produce an unattended install file, a dialog box is the last thing you want. I've had a little play around with the source code and came up with something which would technically work, but was nowhere near as elegant as the rest of the code, so I'm not planning on submitting it.

I did add a few refactorings and documentation into the codebase, nothing clever or anything; I then submitted the changes as a patch to Dru, and within the hour, they had been committed to trunk. This really reminds me why I love open-source programming so much - if the application doesn't do quite what you want it to do, you can download the source code and modify it, and if it works well, you can contribute that change back to the community. Talk about a win-win situation. Non-open source companies have to think about every way that people will use their software, and then program all that functionality in, thus proving the 80-20 rule - 80% of your users are only using 20% of your application's functionality. Did you know that Microsoft Word has a Japanese Greeting dialog box, which allows you to select a greeting specific to the month of the year?! I wonder even how many Japanese people know it exists?

Speaking of contributing to open source, I've accepted a couple of patches to my SvnRevisionLabeller project, and should be releasing a new build soon, once I've figured how to get some good tests in there. You are testing your software, right?!

This stuff is supposed to be fun

So blogged Jeff Attwood some 18 months ago, and as far as my own experience goes, he is absolutely right. When I went to university, it was to study Electronics and Communications Engineering, but by mid-way through the second year, I really wanted to on Computer Science, but really it was just too late to be changing courses, so I stuck it out to the end. To show willing, I applied to some of the major electronics companies like Philips and Marconi, but nothing came of that, so I managed to convert my summer job at the Foreign & Commonwealth Office into a more permanent job, doing typical admin stuff in the library. A healthy dose of luck and good timing saw me slide into an IT helpdesk/sysadmin role, and from there, I never looked back.

I was then able to leverage (how I hate that word) my IT skills to get into development, and there I knew that I had found my real métier. Like no doubt thousands of my technical colleagues, I have found the perfect union between my favourite pastime and my job. My wife still marvels that I spend eight or more hours a day at the office working with computers, and then when I come home, I'm happy to spend the rest of the evening, or most of the weekend, doing exactly the same thing (and not getting paid for it!).

In fact, I enjoy being a developer so much that I will do everything in my power to avoid promotion to a position where I can't sit down and write code every day. For some, it may be just a step on the ladder to management, and that's OK; but for me, the day I stop coding and using computers is the day they prise the keyboard from my cold, dead hands.

In short, I know what colour my parachute is; and being a self-professed geek, it's black.

So are there any other categories of people out there whose private life seems to be just an extension of their working life? Or perhaps even better, they see it as the other way round, where they're getting paid to do something they could spend every day doing? Musicians? Sportsmen? Accountants, anyone?!

One hour of heavy petting

I wonder if there's any chance of something like this taking off in Sydney. Maybe there's just something so incredibly Japanese about it that it wouldn't work, but I just love the idea.

Either way, it seems Sarah Marchildon has struck a bit of a chord with her blog posting, generating all sorts of interest.

Perhaps I should buy a fancy espresso machine and add a dozen cats to the household, and set myself up as the Sydney branch of 猫の時間 (Neko no Jikan, or "Cat Time").

Cuuuurses!

Oh well, so much for my earlier optimism - it turns out, that for the time being at least, Sandcastle can't easily be used on a build server.

The problem is the Help 2.0 Compiler, which in a previous life as the Help 1.x Compiler, was shipped as a standalone product. However, Microsoft, in its infinite wisdom, decided to bundle the 2.0 version into the Visual Studio SDK; and of course, to install the Visual Studio SDK, you need to first have an installation of Visual Studio, which rather defies the point of a build server. Especially for small operations on a budget, having to acquire an extra VS license just to automate the creation of documentation is more than a pain in the neck, it's downright unsociable.

There are some guides on working round this, but they only cover up to VS2005 and its SDK, whereas we're using VS2008 SP1.

I'm going to have a play around with exporting chunks of my registry which has references to the 2.0 compiler, in the hope that that fixes things. I don't hold out much hope.

Catching Up

It's been a while since my last release of SvnRevisionLabeller, and I've not paid the project pages too much attention, seeing as everything was very quiet. Unfortunately, I hadn't set up the project to notify me whenever issues were raised, so I'd missed the raising of several bug or change requests.

Well, after stumbling upon one such change request during an unrelated Google session, I thought I'd better catch up on my project maintenance; it doesn't look very professional when your projects have bug reports unloved, unacknowledged, and unresolved.

The biggest change is that build number will be configurable; it was one of the first feature requests, and for a current project at work, it's something I wanted to do anyway.

BTW if you have downloaded and installed the plugin, I'd be interested to know. Google reports 822 downloads; the person who filed that request has linked to their site, so that's one, and of course I use it at Fairfax Digital, so that's two. Anyone care to offer up any of the other 820 downloads?!

Using Sandcastle with CruiseControl.NET

For a new project at work, I'm adding automatically-generated API documentation as part of my nightly build. Back in the days of .NET 1.1, we had the NDoc project, and explicit support for it in NAnt. Unfortunately, the project never made the transition to .NET 2.0, instead coming to a rather bitter and public end due to predominantly a lack of community support (despite the large numbers of downloads). I guess it's one the main failing of open-source projects - many are happy to take, but not so happy to give (whether money or time/effort).

Sandcastle is Microsoft's official documentation generator, but even three years on, it lacks some of the user-friendliness that any NDoc user had come to expect. The Sandcastle Help File Builder tool goes a long way to rectifying this, but most of the focus is on the GUI tool. Until the current v1.8 release, command line builds were taken care of by the SandcastleBuilderConsole.exe tool; however, the latest release drops this, and instead uses MSBuild, which ships with the .NET Framework. This is a rather nice touch, in my opinion - a clever use of existing tooling, rather than writing another new tool.

However, the documentation about using it in a continuous integration environment is still a little lacking, so I'm documenting here the problems I came up against.

Installation

So far, it seems like neither Sandcastle nor SHFB have been designed with easy deployment in mind. I like to include my build tools within my source repository; this saves a lot of tedious installation and configuration whenever setting up a new developer PC. Both tools come as MSI packages, with Sandcastle deploying as a 220Mb install, so maybe that one you can do without in your repository! SHFB on the other hand is relatively lightweight, at around 3Mb for the files required by the build tasks. You will need to set an environment variable for it to run properly, though:

<setenv name="SHFBROOT" 
   value="${Sandcastle.dir}" 
   unless="${environment::variable-exists('SHFBROOT')}" 
   verbose="true" />

The SHFB files that you seem to require are:

• ColorizerLibrary.dll;
• ICSharpCode.TextEditor.dll;
• SandcastleBuilder.Components.Config;
• SandcastleBuilder.*.dll;
• SandcastleHelpFileBuilder.targets;

You'll also need the Help 2.0 Compiler tool hxcomp.exe, which ships as part of Visual Studio 2008 SDK; and of course, the SDK requires that Visual Studio 2008 is installed before it itself will install. Fortunately, you can pull out the contents of C:\Program Files\Common Files\Microsoft Shared\Help 2.0 Compiler\ and add that to your repository as well, bypassing that little pain-in-the-neck.

Configuration

To use SHFB within CC.NET with NAnt, you'll need the <msbuild> task that comes with NAntContrib. The syntax is as follows:

<msbuild project="${source.basedir}\Documentation.shfbproj">
   <arg value="/property:${HxComp.dir}" />
   <arg value="/property:SandcastlePath=C:\Program%20Files\Sandcastle\" />
</msbuild>

All the properties listed in the SHFB GUI tool can be set as above - just watch out for the need to escape spaces when hard-coding paths, which had me stumbled for an hour or two, until I found a post asking the same question.

Still To-Do

The one thing I really want to get done is programatically set the assemblies which will be documented; at the moment, you either use the GUI tool and relative paths, or edit the SHFB project file by hand. You could probably also use NAnt's <xmlpoke /> task to edit it, but I would prefer to be able to set it via parameters to the <msbuild /> task, so watch this space while I work it out.

On holiday in Victoria

Seeing as work was enticing us to be away from the office in January with free days-in-lieu, I thought I'd take the family away from the madness of Sydney in the summer (seriously, 38C the other day, and it was already hot and sticky by 9am), and head for the cooler climes of Victoria. We've only visited Melbourne the once, back in 2000 on our first trip to Australia, which after three years of living here, is bordering on the criminal. So here we are in Melbourne, meeting up with my dad and stepmother, who are on the return leg of their round-Australia-by-caravan trip, for a spot of Chinese dinner and a walk along the riverbank. Tomorrow we head inland for the goldfields. So far, the furthest inland that we've been is Canberra, so we're going to try and get away from the coastal metropolises (metropoli?), and take in some of those big wide vistas that Australia is supposed to be famous for.

Blogging on OS X

Some time back, I blogged about my dismay at finding no equivalent to Windows Live Writer for OS X. Well, since then I've been mainly using Blogger's web client to do my blogging, but the lack of a decent offline client has been a bit of a pain. For some reason, having to run Windows Live Writer from within a VMWare session, just grates a bit too much. So I thought I'd try out some of the Mac equivalents. OS X lacks a clear equivalent to WLW, which is as close to a perfect product as Microsoft is ever likely to release (not inspiring for a platform some 20 years old), and free as well. From what I garnered from the web, the best commercial products for OS X are ecto and MarsEdit. I downloaded both clients this evening, and ran through the setup routines. Ecto was a bit less friendly than MarsEdit, so I'm going to give MarsEdit a go first. This post is being written with MarsEdit, if you couldn't guess.