The Middle East for Geeks

From Tim comes The War on Terror. This one is probably for those with a sense of humour and a left leaning.

XINS

XINS looks like an interesting technology for simplifying web services, well, if its marketing lives up to the hype. They've just released a XINS Primer that takes you through building a web service using XINS. And for once, someone built a tutorial on a Unix platform ;)

Generalizing Specialists: Improving Your IT Career Skills

I believe that to become an agile software developer that you need to move away from being a narrowly focused specialist to become more along the lines of what I like to call a generalizing specialist. A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas. When you get your first job as an IT professional it is often in the role of a junior programmer or junior DBA. You will initially focus on becoming good at that role, and if you’re lucky your organization will send you on training courses to pick up advanced skills in your specialty. Once you’re adept at that specialty, or even when you’ve just reached the point of being comfortable at it, it is time to expand your horizons and learn new skills in different aspects of the software lifecycle and in your relevant business domain. When you do this you evolve from being a specialist to being a generalizing specialist. Generalizing specialists are often referred to as craftspeople or even "renaissance developers".

Source: Generalizing Specialists: Improving Your IT Career Skills

40 Things That Only Happen In Movies

This is golden! 40 Things That Only Happen In Movies. My favourites:

• Should you wish to pass yourself off as a German officer, it will not be necessary to learn to speak German. Simply speaking English with a German accent will do.
• If you are heavily outnumbered in a fight involving martial arts, your opponents will wait patiently to attack you one by one by dancing around you in a threatening manner until you have defeated their predecessor.
• Rather than wasting bullets, megalomaniacs prefer to kill their enemies with complicated devices incorporating fuses, pulleys, deadly gases, lasers and man-eating sharks.

Tripletest Report

Dave Wood reports on the results of the Tripletest Report, a report comparing Kowari and Sesame. This confirms Tucana's former internal performance testing. An interesting note is that they only tested up to 20 million triples, back in the day we were regularly testing up to 500 million during load and performance tests. Plans for the new backing store will increase this even further, if it's ever implemented...

What does "the simplest thing" mean?

Agile advocates often tout the adage do "the simplest thing". Indeed I've heard this phrase used as both justification for and criticism of agile methodologies (XP in particular). However, many agilers and non-agilers alike often have trouble knowing just what is the simplest thing. I often use the phrase within a given context, meaning the simplest thing given a number of healthy practices. Generally these include test driving, loose coupling, use of patterns) and other sometimes nebulous practices. Which practices are important comes mostly from experience, and I often find it hard to articulate just what practices are important.

To help, let's look at doing the simplest thing for a simple example, linking to an external API, in this case an XPath processor. The example comes from a recent project, actually, a lot of my recent rants come from this project. This project linked to an XPath API directly in over 300 places and when we needed to replace the implementation with a faster and less memory intensive processor, we were forced to change all of these lines of code, increasing the chances of new problems and regression.

Simplest Simplest

In order to hook into this API, I simply embed a call to the API directly in my code.

class ElementFinder {
    void findElement() {
        Element element = XPathAPI.findSingleElement("...");
    }
}

I'd say that this is the absolute simplest thing that you can do to link to this API. It's quick and does what is desired, but what are the downsides?

• Tightly coupled to implementation - If I was to use the same code in 300 classes, and then find I needed to change APIs (say as a result of performance testing), I'm stuck with changing 300 lines of code.
• Untestable - I can't test that my code does the right thing as I'm calling directly into the API I want to use. For example I cannot drop a mock in during unit testing.

Uncoupled Simplest

The next step in de-coupling our example is to remove the direct call, and hide it behind an API of our own.

class BetterXPathApi {
    Element findSingleNode(String xpath) {
        return XPathAPI.findSingleNode(xpath);
    }
}

class ElementFinder {
    void findElement() {
        Element element = BetterXPathApi.findSingleElement("...");
    }
}

The beauty of this is that whenever we want to call the external API we call through our own version, so if we want to changed the backing implementation, we just need to change one line. But what are the downsides?

• Tightly coupled to implementation - Even though we've pulled out the call to the external API we cannot change the call without changing code and I can't swap out implementations easily.
• Untestable - We still cannot test that our code does the right thing as we can't (easily) set a mock in place of our BetterXPath code.

Interface Simplest

To make this more adaptable, we can hide our implementation class behind an interface.

interface BetterXPathApi {
    Element findSingleNode(String xpath);
}

class XercesXPathApi implements BetterXPathApi {
    Element findSingleNode(String xpath) {
        return XPathAPI.findSingleNode(xpath);
    }
}

class ElementFinder {
    void findElement() {
        BetterXPathApi xpathApi = new XercesXPathApi();
        Element element = xpathApi.findSingleElement("...");
    }
}

This version is a lot better than the last, the implementation is abstracted behind an interface allowing us to swap implementations easily. But what are the downsides?

• Untestable - We still can't drop in a mock in place of our implementation to test that we're doing the right thing.

IoC/Dependancy Injection Simplest

To make this even more adaptable and easily testable, we can allow implementations to be dropped in using IoC or dependancy injection (we'll use the constructor form to make it easier).

interface BetterXPathApi {
    Element findSingleNode(String xpath);
}

class XercesXPathApi implements BetterXPathApi {
    Element findSingleNode(String xpath) {
        return XPathAPI.findSingleNode(xpath);
    }
}

class ElementFinder {
    BetterXPathApi xpathApi;
    ElementFinder(BetterXPathApi xpathApi) {
        this.xpathApi = xpathApi;
    }
    void findElement() {
        Element element = xpathApi.findSingleElement("...");
    }
}

What we've done is decouple our construction of the implementation with its use, delegating the construction to some other entity. So while this may seem more complex, it allows us to drop in implementations to suit our needs for example during unit testing or at runtime using an IoC container.

So now we've gone from one class to three and increased the lines of code from five to seventeen. But we've loosened the coupling between our code and the external API we're linking against, improved its testability and clarified its intent. So while this may not be the simplest simplest code, it's worthwhile taking a little extra time to build in some things which increase the health of the code.

JavaDoc Problems

Seems like the 1.5 version of JavaDoc won't generate documentation for classes that have package local (default) scope and are not referenced by source included in the JavaDoc command (i.e. they're only referenced in test code). Bug or feature?

Ping Pong Development

Back in my Suncorp days (sounds like the far past doesn't it ;), we did "XP with the notches turned up to 11." One of the really good practices we used was when pairing, we'd have one developer writing the test, and the other implementing the production code. This works well if the code writer tries to be as painful as possible by writing the absolute simplest code, thus forcing the test writer to improve the tests. And the cycle goes on...

So it seems that this technique actually has a name, it's called "ping-pong development". Mike Spille discusses it in Action Hippo Rangers! as well as some other things I've noticed with 180 degree turns. While I don't see the sense in going to the extreme he cites, the ping-pong nature of paired development works really really well. As for the 180 degree turns... well, I've seen both some good and some harm come from it.

JRDF 0.3.4 Released

Andrew has released JRDF 0.3.4. This release includes the updates I've been working on to integrate an SPARQL parser (and also some cleaning up of the build process). The current plan is to create a parser based on a dummy query layer in JRDF. Someone will obviously have to write a real layer, or, I've been thinking of plugging into something like ARQ (the new Jena-derived query engine). This should also enable easy integration into Kowari, where I'd originally planned to write the SPARQL parser.

There is no best practices...

James Blach writes about there being no best practice:

Dear Reader, I would like you to give up, henceforth, the idea of "best practice." Thank you. I want to stamp out "best practice" for several reasons...

I think in general when people say best practice they mean a practice that has been known to work within a given context, well I know I do. So it's technically true that there is no canonical "best" practices.

Patterns of Software Craftsmanship

Patterns of Software Craftsmanship looks like a promising site for those interested in staying in coding, something I'm not having that much luck with lately. I've worked with a few people like this recently, and in general they seem to be very comfortable staying in a coding role, some actively refusing roles and promotions.