Web Tester
The hardest bugs to fix in software development are often concurrency problems. That is, bugs which are hard to find as they rely on multiple events occurring at overlapping intervals - often impossible to recreate reliably.
With web applications, such as ours, the most straightforward way of replicating these problems so that they can be observed and fixed is to use a load testing tool. Given that such tools have been around for many years, we initially thought that this would be a more or less trivial kind of testing to implement. We were wrong.
Trying freely available software, such as The Grinder, LoadRunner and a few other alternatives yielded little success after grappling with configuration files for a considerable stretch of time. On the other hand, the commercial solutions up for offer don't seem to be priced in proportion to what is on offer.
So, following my Neanderthal instincts , I made a tool. Besides, this would give me a chance to brush up on basic concurrent programming (normally hidden from us by a veil of ASP.NET). To make things more interesting , this would be the firsthand 'from scratch' program I had built after reading through Bob Martin's excellent Agile Principles , Practices and Patterns .
The web tester (imaginative name) works by reading URLs to retrieve from a simple text file, hitting said URLs and recording the results. There's really not much more to it than that.
The interesting components at the core of the Web Tester are the asynchronous request maker/handler and the input parser. the former being interesting due to heavy use of the framework, the latter interesting because of the lack thereof.
Writing the tester was a great refresher course in basic 1.1 asynchronous development. While easy to dismiss as boring, this is still relevant often enough to justify revisiting once in a while .
For anyone with a background in computer science , the immediate reaction to hearing the word 'parser' is to launch into yacc or antlr and rough out a grammar. For those with a more practical background, a pre-made technology or tool such as XML or Lua may come to mind. I, however, decided once again that reinventing the wheel would be the best option. The result came after a few hours of work, and considerably less pain than would be expected. Having said that, I would not recommend hand rolling a parser for anything more complex or any format intended for public consumption.
In all, such a tool is a great little helper for day to day use. It's an example of making a simple tool, a good practice for any developer. I'll post the source code if it's okay with the powers that be (my boss).