My hovercraft is full of eels

Having been berated for bashing subversion based on heresay and rumour, it was about time to make the switch and actually see for myself what life without CVS was like.

As luck would have it, the guy who does all my hosting had already been considering providing SVN support so that when I asked him he was more than happy to make a guinea-pig out of me ;-)

As I didn't do the conversion from CVS to SVN myself, I can't comment on what is involved but I can say that it appears to have gone seamlessly and without fault. I installed the latest SVN client on my mac and was up and running within minutes.

Initial impressions are good: The command line application is very straight-foward and somehow seems more intuitive than the CVS equivalent; It certainly runs faster than CVS (or at least appears to) as it only sends diffs to the server (based on checksums); and; It will really come into its own in a week or so when I will need to perform a bulk rename of files for the book - the real reason I needed SVN in the first place.

The only mildly dissapointing thing is the rather less than wonderful support in IntelliJ: Even in the latest EAP versions it seems to be much slower than the command line application and doesn't have an option for hiding the .svn directories. No doubt all of these will be "fixed" soon...right?

The best part for me is the repository versioning: every commit increases the repository version number so in effect you get a new tag with every commit. This will come in particularly handy for some code analysis tools I've been developing that track metrics over time. Previously I had to go through hoops to try and work out what changed and when in CVS. Now SVN gives me this information for free!

So all in all it's happy sailing on the SVN ship. That is of course until my repository becomes corrupted. JUST KIDDING!

Posted by Simon Harris at 04:40 PM | Permalink | Comments (5)

Sometime ago I wrote about my experiences pairing with James and the effect that listening to your code can have on the naming of variables, methods, classes, etc. Then last night, I had a very interesting discussion with Owen Rogers about, among other things, the effect that TDD has on your code.

One of the observations was that, in order to write a test (and by inference mainline code) that is understandable, you need to name your methods very carefully. The specific example that Owen gave was a factory method for creating an XmlWriter. The usually accepted convention is to name the method createXXX or newXXX as in:

public class XmlWriterFactory {
    public XmlWriter createWriter() {
        ...
    }
}

Which would then be used something like:

order.write(factory.createWriter());

The problem with this is that it doesn't really flow particularly nicely. To illustrate, let's re-write this last line of code into English:

order (dot) write, factory (dot) create writer

Reading the this aloud seems a little unpleasant and requires you to think a little too much about what is going on, even with such a simple line of code.

The suggested improvement was to buck the "trend" and rename some of the methods so that the code would look something like:

order.writeTo(factory.xmlWriter());

This can then be converted plain English that reads something like:

order (dot) write to , factory (dot) xml writer

Much nicer! Written this way, it's much easier to get a feel for what is going on and for that matter to ignore the occasional syntactic noise such as "dot" (and for that matter "factory"). Interestingly however the necessary changes to the factory class make the class itself seem a litte odd:

public class XmlWriterFactory {
    public XmlWriter xmlWriter() {
        ...
    }
}

If you looked at the modified factory class in isolation it might not be obvious what the method xmlWriter was doing. Because there is no verb attached to the name, we have lost some of the meaning of the method when viewed on its own. And, to me, this is one major difference between a traditional design-your-classes-up-front approach, versus a more design-your-classes-as-you-need-stuff strategy.

It seems there is a trade-off between understanding a class in isolation versus understand its use in context and the nice thing about simple, readable tests, is that they give you that context as well as all the other benefits associated with good quality unit tests.

Of course this doesn't help much if you're building an API that needs to be used by someone else. Chances are you probably don't distribute your unit tests and even if you did, people still feel less comfortable reading test code than mainline code or JavaDoc. Having said this, it has always been my experience that no matter how good the documentation is it's usually almost impossible to work-out how a library should be used (especially one that is composed of many small objects) unless you have concrete examples - code presented in context.

There are obviously many other factors that affect the readability of code and naming is but one however I do find all this particularly interesting as it challenges many of the assumptions, habits and conventions that I, and plenty of others, have formed over the years.

Even more interesting to me is that some approaches favour understanding by novices while others seem to benefit more experienced developers - what seems like the simplest thing™ to one person is completely unobvious to another.

Posted by Simon Harris at 02:05 PM | Permalink | Comments (4)

I was doing a little reading on different types of rule engines today and stumbled upon this article. As I was reading through it, I had an eerie sense of dejavou; I was sure I had read this somewhere before. In fact, it almost sounded like something I might have written.

A quick search through my blog and there it was, an entry posted in September 2004.

The thing that amuses me most about copying someone elses stuff word-for-word is that you inevitably end up copying all their (or in this case my) mistakes as well. So whilst I'm flattered that someone with obviously unquestionable integrity would even consider re-using my thoughts (and even spruce them up a bit in the process) I would have thought that bloggers, armed with trackbacks and hrefs, and indeed developers in particular, would have left copy-and-paste re-use behind.

Posted by Simon Harris at 01:18 PM | Permalink | Comments (6)