We’ve been switching pairs a lot in an effort to try to share knowledge between team members before and it’s been working really well. The downside to it though is that since the team owns the tasks and people swap between tasks so much (which is what gives the shared knowledge), there’s always the danger that you will get off track and start wasting time writing code that isn’t actually needed for the user story.

In order to write atomic tests for classes I’ve gotten into the habit of injecting dependencies instead of creating them inside the class. This makes it simple to mock the dependencies but means that those dependencies are now externally visible instead of being neatly encapsulated and it means that somewhere in your code, there has to be a place that actually creates all these instances and passes them in.

I have no idea how to test that bit of code.

If you want to reap the benefits of pairing in terms of sharing knowledge around your team, you need to make sure you change pair regularly. We’ve been working on the basis that one pair works on a story until it’s done – mostly because we only have a small number of engineers and a large number of projects that we need to work on.

The problem is, we’re not sharing knowledge enough. Instead of one person knowing about that new section of code, now two do, but the rest of the team still doesn’t so we tend to want to get one or both of those two to fix any issues that come up or add any improvements. It’s not a team ownership thing anymore, it’s a pair ownership.

We’ve begun testing out Hamachi at work as a substitute for our defunct VPN and it’s showing a lot of promise. It sets up a peer-to-peer VPN which is quite clever and simple to get working. When combined with installing Bonjour on the Windows boxes (Macs have it pre-installed) and tweaking the DNS settings to add .local to the search domains, the DNS look-up works brilliantly cross-platform as well.

I’ve now got access to all the important stuff from work to tinker with my little side-projects while still being able to store them in the work subversion repository so others can join in if they want. It’s an awful lot simpler to work with than the old VPN stuff too.

The Rabbit Hole: Smooth JList Target Animation

There’s a JTree animation in the next post too. Cool, but the code is awful so it’s probably better to just reimplement the generic technique.

David Berlind has an interesting post about the potential of Derby as an offline storage mechanism for thin-client web-apps. I can see the potential and an awful lot of difficulties as well. Might I suggest the perfect integration point for this kind of thing is a really cool Java WYSIWYG editor?

Hey Andrew (CEO of Ephox and a big fan of offline editing), can I have some time to try and prototype this on Ephox’s internal wiki? You could edit your wiki pages offline easily…

Setting the system look and feel is a common task in applications and if you’re shooting for 100% test coverage, it’s problematic because it uses two static methods and has checked exceptions. Typically you have something like:

void setNativeLookAndFeel() {

    try {

        UIManager.setLookAndFeel(

        UIManager.getSystemLookAndFeelClassName());

    } catch (Exception e) {

        // Handle exception somehow.

    }

}

As far as I know, there’s no way to write a test that doesn’t also exercise UIManager, so we’ll have to live with that, but we can test that the UI is set and the exception handled.

When you work with legacy code, it’s easy to fall into the trap of thinking that because you can’t atomically test it that you should refactor it and add tests. This is a mistake. You should write integration tests, then refactor it, then write atomic tests. Even when the refactoring seems simple, it’s still possible to stuff it up.

Most code can have integration tests written for it, even when it wasn’t designed for testing. In some cases the tests may not be able to cover everything but should give you at least a foundation to work from. Just make sure that as you write the tests you note down the things you couldn’t write an automated test to cover and make sure you do add a test for them after your refactoring.

The basic principle of TDD is that you write the test first and then write the code required to make that test pass. There’s more to it though if you expect to see all the benefits. If you drive your development from integration tests instead of atomic tests, you’ll wind up with highly coupled code again and because it grows gradually without up-front planning, it’s often harder to understand.

If however, you drive your development by atomic tests, you are very strongly encouraged to decouple your code whenever possible because mocking out dependencies is so annoying and time consuming (plus the more you have to mock, the more brittle your tests tend to be).

I’ve finally gotten around to upgrading to WordPress 2. Mostly I held off because it was going to destroy my integration of EditLive! for Java (I didn’t bother learning about plugins, just edited the WordPress source code). This time around I’ve integrated ELJ via a plugin, but the plugin API doesn’t make it particularly simple. Why is there no action for generating the editor? Shouldn’t it have been reasonably obvious that people might want alternative editors?

There seems to be a great demand for HTML documents that don’t include white-space between paragraphs – similar to going into the paragraph formatting in Word and setting space before and space after to zero. This is very simple to achieve in HTML, but people just keep coming up with strange ways to attempt to achieve it.

The most common way people try to get around the problem is by putting their entire document in one P tag and using BRs. You can pick these people because they set their HTML editors to insert a BR on enter instead of inserting a new paragraph. The end result looks right in all browsers but destroys the semantic structure of the document. I imagine it would be much harder to navigate through the document using a screen reader too, since skipping paragraphs seems like a nice way to skim. The problem people most often run into with this approach is that their editor still treats the whole big block as a paragraph, so when they apply a heading style the entire document becomes a H1 tag with a bunch of BRs.

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.