I have two daughters and I like to read a lot, so I don’t feel I have the time to do any serious coding on any pet projects. If I mysteriously found a couple of weeks with nothing to do under my pillow, this is what I’d hack together.

1. iCrash
I went so far as to register a SF project, but I didn’t work on it enough to do any real progress. The idea is simple – whenever your application finds itself in a state it shouldn’t end up in, it can report this to a central bug database. A bit like Gnome’s bug-buddy, and Microsofts crash reporting system, but it would be called from inside your application and not from the outside. I worked for a while on MediaPortal, and something like this would have really helped us target the problems most users run into. The reports would include stack traces, crash dumps, .NET versions, and more, to help the developers fix problems easily.

2. Continuous Unit Testing
Continuous Unit Testing is an old dream of mine. This is to unit testing, like CC is to continuous integration – the chance to make asynchronous. The idea is that whenever your typing away, and you pause for more than a couple of seconds, the CUT-system would fire of a background job that compiles the code and runs the tests. A systray alerter would let you know if the system is in a red or green mode, and when a test fails, it would maybe show a little tool tip saying which test that failed and the exception. Of course, it would be clickable, and that would take you to the failing test. I know Eclipse has something like this, but for us in .NET land this is just a dream so far. A few weeks ago I got so far that I now have some bits that run on my laptop, but not enough to be useful to anyone else.

3. Dead Lock Inspector
I’m kind of proud that I still hold the Google #1 for “sql locking“. At one point in my career, I focused a lot on the internals of SQL Server, and specially the locking. Doing that, I learned a lot about locking as a concurrency control mechanism in general, and I know that there is a least one way to find possible dead locks without having to actually run into them. So I envision a system that would take a NUnit assembly, and inspect it, and point out possible dead locks. What you would do is to create one test fixture for every test you wanted to run. The individual tests in the fixture would then represent work that runs in separate threads. The inspector would log any locks taken and released, and use this information to find problems.

I love consulting, but I wish Thoughtworks would give me a week or two between projects to play around with stuff like this.

Posted by Andres on Tuesday, February 20th, 2007 at 23:23.