I’m available for work from now, so if you’re looking for a freelance that can code, coach and teach, pop me an email.

Someone last week mentioned that Java was now getting static methods defined on interfaces. We’ve had that capacity, through extension methods, since C#3, and is one pattern I keep on reusing.

An interface, at core, is a contract of extensibility between me and other developers: Implement method Bla() and I promise you will be called whenever that stuff is needed. The problem with such an approach is that some functionality is repetitive and makes implementing the interface more complicated.

Let’s take the example of an interface that’s part of OpenRasta…

public interface IDependencyResolver
{
    T Resolve<T>();
    object Resolve(Type serviceType);
}

Because both generic and non-generic methods are needed by the consumer, your initial reaction is to impose the implementation burden on the person implementing the interface.

Using static methods, we can take all that work away, and provide overloads and added funcitonality on any implementation of an interface. And it’s as simple as doing the following.

public interface IDependencyResolver
{
    object Resolve(Type serviceType);
}
public static class DependencyResolverExtensions
{
    public static T Resolve<T>(this IDependencyResolver resolver)
    {
        return (T)resolver.Resolve(typeof(T));
    }
}

I now do most of the work, and the people wanting to implement the interface only have one method to implement. And everyone is happier.

Earlier this week, I attended the Scotch on the rocks conference. The organizers had the brilliant idea to invite developers from other communities with Amnesty tickets, to come and see what was happening in the ColdFusion world.

I’m very grateful they did, as this event has been an eye opener for me. I arrived with preconceptions of script people afraid of real languages hacking together un-maintainable solutions. I should know, I’m still hosting one of those for one of my clients. But this picture is inaccurate, or at least incomplete.

A community split in two

One of the sessions I attended, presented by Peter Elst, highlighted the source of some of my earlier concerns: an assertion was made that a flex developer could easily pick up ColdFusion and deliver the whole backend, without developer intervention. Without a specific scenario in mind, this assertion makes every warning sign in my synapses go red. I do believe however that this is reflective of one part of the ColdFusion community.

On the other end of the scale, Mark Drew presented multiple MVC frameworks available for ColdFusion, and talked about many of the same subjects we talk about in the .net community, including convention over configuration. The excellent Peter Bell talked about software estimation, in which TDD practices, and even Lean approaches to software development were discussed. And there is a vibrant open source community, through the use of IDE tools integrated in Eclipse (CFEclipse), and even an open-source implementation of ColdFusion, called Railo, presented by the excellent Gert Franz (can’t find a blog to link to).

From my discussions with quite a few developers after the event, this impression is widespread. While there are quite a few terrible developers and code being produced, there’s another side of the community that works on best practices and use modern approaches to software development.

In a word, exactly the same configuration as what we have on the Microsoft side of things.

Components, scripts and best practices

And indeed, I learnt much about the traditional ColdFusion development. Best practices have been described to me as a split in components, for which the signature is described in the html derivative we have all seen in the past, with the implementation being done in CFScript.

One particular thing a developer told me was that, once you add attributes to your java / c# code, it doesn’t look that much different from writing the same thing in html. And while I have a personal issue with the context switch involved, I can’t refute that there is ground to the argument.

We’re not that different

What I’ll take away from the event is the confirmation of something I’ve given a lot of thoughts about for a while: good developers are good, whatever platform they adopt. It is now my absolute belief that it is time for communities to build bridges and share knowledge of their craft, with no regard for the actual framework they use. Good ideas are worth knowing about, wherever they come from.

I’ve invited a lot of people I met to the next AltNet beers, as they are exactly the reason for my dropping the dot from the name. I really hope they accept the reciprocal invitation and help us build bridges between communities.

Footnote

Here’s a video interview done at the end of the conference, after quite a few beers.