Symphonious

Useful tool for writing performance tests: Japex.  Must remember to use that when we do our next round of profiling. Doug's suggestion is that once we identify a bottleneck in the code, we write a performance test for it with Japex then try to optimize it until we reach the desired performance level. I'm not sure that our codebase is likely to see performance regressions in the same area again (I can't ever recall having to reoptimize the same section of code), however having the test would be able to quantify how much of a performance benefit we get which would be a useful metric to know.

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.

We plan to go live in the UK for a time, and if we happened to move over there and want another picture of our wedding to hang on the wall, we'd have to call back to Australia and have it printed over here, then shipped to us in England - not to mention paying ridiculous prices for the extra copy. If we owned the copyright and had the negatives or full resolution digitals, we could just go to any printer to get copies.

There's no indication in the conditions of how long our photos will be stored and made available to us for reprints. If in twenty years our house burns down and our wedding album is lost, there's no guarantee we'd be able to replace it, even if the photographer is still in business because he may have deliberately deleted the photos or just lost them because his backup strategy wasn't good enough. If we owned the copyright and had the full resolution originals we could just have it remade - particularly so if we had all the layout/design work that went into the actual album as well as the pictures.

It sounds like the best approach will be to pay a photographer to come and take the pictures, thus making it a work for hire so that we actually own all the copyrights. It will be interesting to see what the cost difference is, both up front and over the longer term.

I just have to wonder how many people have been caught out by things like this.

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.

Having good integration tests and acceptance tests helps here, but only if you run them regularly and since they tend to take a while, they generally aren't run regularly. I talked about using acceptance tests this way previously in Acceptance Test Driven Development and that approach definitely helps, but nothing helps as much as regularly running your actual application and seeing what's happening in real life. It makes me think that before you do a check-in you should run the actual application and test it as if you hadn't been doing TDD just to be sure you know where you've been going.

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.

In fact, most View instances do a lot of layout work, interacting with the model, CSS styles, passing on event notifications and converting between view positions and model positions. There's a lot of stuff you can test in there. The key problem is the number of mocks you wind up having to create for a View.

For instance, I've currently got a mock child view, mock parent view, mock element, mock document and mock stylesheet. That's a lot of mocks. Fortunately, you can push them all down into a common super-class that is used for testing all your views so there's a lot of reuse, but it can be hard to keep straight what everything should be doing. The advantage of this effort though is that views are exceptionally complex to write, so having tests describing how they should interact and ensuring that all the right notifications are sent etc is invaluable when it comes to making changes.

On the down side, TDD doesn't guarantee you'll cover every case and I seem to have missed an important interaction as deleting content will every so often cause a stream of exceptions. I'll have to look into that first thing Monday morning - sorry to those using our internal wiki in the mean time. If you switch to code view and back things straighten themselves out again.

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