As part of planning our wedding next year, the lovely Janet and I have begun looking into photographers. It seems that at least some photographers apply the same dodgy lock-in practices as software companies do by holding onto the copyright of the pictures they take at your wedding and forcing you to go back to them for reprints.

Apart from the fact that I’m somewhat uncomfortable with anyone owning the photographic memories of our wedding, the terms and conditions from one particular photographer are just ridiculous. This particular photographer will quite happily provide you with a DVD of all the photos they take in high resolution – you just have to wait two and a half years after your wedding and pay an extra $750. I’m not sure what happens if he happens to be hit by a bus in those two years or if for some other reason he goes out of business.  As we left our meeting with this photographer I felt quite uneasy about this terms – just feeling that something was wrong, however as I thought more about it, I thought of more and more situations where it would really come back to bite us.

There is one major problem with test driven development – it makes it easy to get lost. When you don’t use TDD, you tend to run your application a whole lot to see what effect your latest code has made. With test driven development, you run your atomic tests a whole lot instead. The trouble is, if your unit tests are taking you in the wrong direction, it can be a long time before you find out.

I’ve been developing some custom views (javax.swing.text.View subclasses) in the last few days. These are right up the alley of GUI code that people tend to find difficult to test but I’ve been pushing forward with test driven development with a fair bit of success. The main approach I’ve been using is to mock out pretty much everything the view interacts with and test it’s logic more than it’s actual rendering. In fact, this particular view doesn’t do any rendering of it’s own, but it does do a lot of layout of child views etc.

Note to self: I must read up on Andy Roberts’ Delta Web proposal and get involved. It looks decidedly useful.

Most code bases have some kind of code debt associated with them, legacy code bases tend to have lots of code debt. The good news is, paying back that code debt isn’t a complete time sink – it has definite advantages too. Obviously, reducing code debt tends to make the team go faster, but it also tends to fix bugs.

Quite often where there is debt, there is not just a lack of maintainability but actual bugs that are frustrating your users. By cleaning up the code, you will often fix those bugs without any special effort to do so – it just happens because of the simplified design.

In an effort to reduce the ridiculous amount of time wasted on April Fools day, the USA will be separated from Canada and Mexico and towed westward across the international date line, thus making April fools day start first in the US and letting them post all the pointless drivel to the internet prior to the rest of the world waking up. With the current location of the US, Australians have to put up not only with 24 hours of their own stupid April fools jokes but with an extra 12-16 hours of the US’s jokes the next morning.

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. Note that this only applies to trojans, not to other types of malware – viruses for instance can be prevented by writing secure code.

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:

1. Go slow. No big sweeping changes. Keep the way it does things the same and just break the code down to make it more readable and create multiple small balls of mud instead of one big one.
2. Use the automated refactorings in the IDE unless you absolutely have to make manual changes. We discovered a number of bugs in Eclipse this way where it didn’t detect identical code – who knows why not. In once case I managed to convince it the code was identical by repeatedly trying the extract method until it picked up the duplicate block but in a second case I had to revert to manually replacing the duplicate code.
3. Use the simplest refactoring that could possibly make it testable. Mostly this meant applying extract method with a smattering of extract local variable to pull out the differing pieces so duplicate code could be merged. In hind-sight I may have been better off leaving the duplicate code in and writing tests for it separately, it would then have been easier and safer to remove the duplication.

All in all I think it went really well, slow going but effective and we now have half as much code and it’s much easier to test. There’s still a lot more work needed to stop that code from smelling but it’s a start and that’s enough for one day. You can’t spend all your time refactoring legacy code, new features have to be added – just make sure that you’re constantly improving and eventually you’ll get there.