Still struggling to write that guide to OsCache. Hopefully I won't still be saying the same thing this time next year.

On the bright side I managed to write up a nice little visualisation script in Ruby. It basically takes your struts-config.xml file and turns it into a graph and spits out a .png image of that graph. It's available here and an example of the output is available here.I wrote it mostly to help me learn Ruby but now it's up on my site I realised that I seem to always end up playing with visualisation tools of one kind or another. I think I'll get myself one of Edward Tufte's books for Christmas.

Apropos of nothing I'm reminded of a C++/Program design exam at university where I found a bug in one of the questions. I'm still amused by the note I wrote. It was something along the lines of: if this did what you think it does the correct answer would be foo but due to this bug it actually does bar. I'll probably never know if I got any marks for that question. C'est la vie.

TDD (Test Driven Development) has a lot of benefits (it really helped me in writing strutsviz despite my almost non-existent Ruby knowledge) but it's blooming hard. Mainly because it's an indirect design process. I've tended to find that the first version of anything I write with TDD passes the tests but feels awkward, inelegant or contains duplication. At which point I usually re-realise that TDD requires iteration and refactoring as well. Of course the tests mean that you can transform the code incrementally without worrying too much about breaking things.

And sometimes on a good day all this comes together nicely. The code approaches ExtremeNormalForm and I find that the addition of extra functionality is actually shrinking the number of lines of code.