June 2006
I've finally gotten around to writing a script that let's me publish photos much more simply. That means this month I've had time to get a load of pictures from Vertigo, a bar in central Bangkok. A lot of these pictures were taken with Shiv's Canon EOS camera.
Near the beginning of the month I published what has been my most popular article to date, a tutorial on getting started with templates in C++ to show they could be used to help with the common programming task of encapsulation. I've started a follow-up to this about encapsulation. It seems to me that many people are losing sight of what encapsulation is really about in their rush to follow the rules. And of course the rules they're following aren't necessarily universaly applicable.
I also managed to get around to the first draft for the introduction to Enterprise systems for geniuses and there's also a short piece on the importance of Unicode on the Internet (and in software in general).
Vector bowling
The test object used for the project
Most interesting (at least to me) was my response to a challange laid down by Ron Jeffries (Editor of XProgramming.com, a site about Extreme Programming) to implement a particular algorithm for adding up bowling scores.
My C++ version of his Ruby code then got picked up by Christopher Smith who, although he missed the point of what Ron and I were trying to do, did remind me of the real reason why I generally dislike these sorts of programming challange. Let me explain.
Ron spent a lot of time building up tests in order to ensure that the solution he came up with was correct. It was his description of this process that I especially liked and wanted to replicate when I went about the problem in C++. As nice as the solutions were it was the fact that we had shown that our solutions worked that gave us confidence to show them to the world, and at least for me, reading Ron's approach to building the solution was more interesting than the code that he actually ended up with.
This is what I tried to replicate, and in fact in a short exchange of emails I had with Ron about what we'd done most of our discussion was about the difference in testing approach. It was this focus on testing that Christopher missed. Christopher's two solutions are elegant, but at least one is flawed and the jury is still out on the other. Clearly he'd missed the point of testing properly* [*I'm maybe being a little unfair to Christopher here as this end-of-month roundup is just a day or so after he published his solution. I've only posted my corrections to one of his solutions a few hours ago so he hasn't managed to respond to that yet.].
So the lesson is that if you want to write up some neat bit of code you've crafted then any solution is only clever if you can prove it and this means showing how you tested it and giving the test results. Now this leads to longer and more nuanced write ups where maybe the extreme coolness of your idea isn't so obvious to a casual reader who is only going to spend thirty seconds glancing at it—but at least you'll have confidence in your method.
So why do I dislike these programming challanges? Because normally they result in code that can't be used in a production environment and at heart I consider myself a software engineer with the emphasis on the engineer. This means having software that works, is maintainable and is neither over nor under engineered.
