There’s a very persistent (and very stupid) referrer spammer pummelling my blog and I’m getting sick of it – not least of all because at one point it actually managed to completely overwhelm the tiny little virtual server my blog runs on so that nothing else could access it. Given that I’m using WordPress with Apache, what’s the easiest way to block it?

Someone really needs to sort this out once and for all. It’s pretty simple to get Java installed so that you can run it – getting it installed so that the packaging system is satisfied that it’s there involves various bits of voodoo and integrating it so that you can use applets in Firefox is still a pain. Can we just decide on a standard location for the plugin file so that it can be auto-installed, or maybe even just a standard config file that tells the JRE installer where the Firefox plugin directory is?

Quite some time ago, I argued that unprivileged users were too annoying to be usable in Windows. Today I took shipment of a shiny new computer and figured that for once I might actually try applying all these ideas that are meant to make Windows secure. Previously I’ve just kept Windows safely behind a firewall and done my web browsing and email on my Mac – essentially eliminating any way for unvetted code to get to my PC.

Often when you define an interface there is a series of generic tests which can be applied to every implementation of that interface. For instance, the java.util.List interface carefully defines the behavior that all implementations must have. A simple way of testing these behaviors are present is to use JUnit’s ability to inherit test methods. Define a base class with a test method for what you want and an abstract method to create the actual instance:

It occurs to me that there’s no way to stop trojans from working – there will always be a way to disguise it so that it looks like a valid application – if by no other means than by making it a valid application. There is also no way to allow the user to get their work done and prevent trojans from doing any damage or being annoying – even with privilege separation, the trojan has access to all the user’s files.

Refactoring without tests is hard and really, really scary but sometimes you’ve inherited (or perhaps written yourself) a big ball of untestable mud and the only way out is to refactor and make it testable. One of our engineers found himself in that situation today so we sat down together to try and make sense of it. I tried to follow a few simple rules: Go slow. No big sweeping changes.

I’ve come to discover a really annoying trend among blog statistic services – they all seem to show graphs of vistors by day, week or month instead of showing the past 24 hours, 7 days or 30 days. The difference is quite substantial, by viewing by the past 24 hours you always get a useful graph, by viewing by the day at the start of the day there’s just a blank graph.

Doug suggests that XP isn’t a solution to your problems. Mostly I agree, however XP does make you feel bad – and in this case, feeling bad is good. As Doug points out, XP brings things out into the open which makes people feel bad about them. The lack of tests for your product – oh, that’s not good. Not doing continuous integration – tut tut tut. Your build is regularly broken?

There’s a big difference between code you write when you’re fresh and code you write when you’ve just had enough. I obviously had a relaxing weekend, because today my approach to coding was surprisingly well behaved – even when I had to modify legacy code that had no test coverage I made sure I wrote new tests before I touched it. Getting into TDD for new code is one thing, building up the discipline to add tests to existing code before making even a simple change is really tough.

As you spend more and more time developing good unit tests as part of TDD, you regularly find yourself writing the same thing time and time again. Fortunately, TDD also includes a refactor step to remove this duplication again. I’ve found it quite interesting that over a few weeks of this, we’ve actually developed a complete language for asserting the correct output. For example: assertStartTagSpec(HTML.Tag.HTML); assertStartTagSpec(HTML.Tag.BODY); assertStartTagSpec(HTML.Tag.P); assertContent("Hello World!"); assertLineEnding(); assertEndTagSpec(); assertEndTagSpec(); assertEndTagSpec(); assertEndOfSpecs(); Even without the domain knowledge, it should be fairly obvious what is expected.

Chuq Von Rospach has some interesting thoughts on tagging – must come back to this and have more of a think about it.

It seems I finally pestered Doug into blogging again, so for his side of the story check out Experiments in Software Design.