James Turner:

Unneeded interfaces are not only wasted code, they make reading and debugging the code much more difficult, because they break the link between the call and the implementation. The only way to find the implementing code is to look for the factory, and see what class is being provisioned to implement the interface. If you’re really lucky, the factory gets the class name from a property file, so you have to look another level down.

Robert Burrell Donkin:

ThoughtWorks are opening their new office right in the center of Manchester with a conference. The cost is £75 and places limited to 50.

I’m particularly looking forward to Dave Farley on continuous delivery…

It’s nice to read things like this and be able to think – meh, I already have to listen to him everyday at work. :) Basically, I’m really enjoying constantly having the feeling that I’m the dumbest person in the room because there’s always a ton of learning that comes out of that experience.

The current competition in the smart phone space between Android and iPhone is both fascinating to watch and provides for some quite vigorous and entertaining debates. I find one pair of arguments particularly entertaining:

1. Apple is abusing their monopoly with iPhone
2. Android has more market share than iPhone and is selling at a faster rate

It’s interesting how often the same person will attempt to leverage both of these arguments (or likely better worded variants thereof) without ever realising that by definition, they can’t both be true. If Android is outselling iPhone, then it would be impossible for Apple to have a monopoly and thus can’t abuse it1{#footlink1:1305386215210.footnote}.

One of the things I really enjoy about the software development teams I’ve worked with is their relentless focus on improving their overall productivity – producing more business value in less time and with less cost each every iteration. It’s largely this drive for productivity that drives developers to focus on quality – buggy code is hard to maintain and delivers little or no business value. Similarly it makes developers really care about the tools they use – the programming language, the OS, the IDE or editor, continuous integration, source control and all the other tools or systems they have to work with. When it comes to tools, nothing is ever good enough and we always want more. So long as that desire for perfection is balanced by careful, realistic prioritization it’s a fantastic thing to have in a team.

The last couple of weekends I’ve been fiddling with a skunk-works project to improve one of the internal web apps at work. Since it’s an internal tool and the entire development team run on Linux I’ve had the luxury of completely ignoring IE support. Previously I’ve felt liberated when I could drop support for IE6 but web development is a whole new world when you’re prepared to drop IE altogether – even IE9 wouldn’t have some of the things I’ve been happily using.

For the past three months I’ve been settling into my new role with LMAX developing a high-performance financial “exchange”1{#footlink1:1301173295622.footnote}, hence the silence on the blog lately. One of the things I’ve found extremely impressive about LMAX is the impressive acceptance test coverage and the relative ease with which they are maintained. Normally as a set of acceptance tests gets to be extremely large they can become an impediment to being agile and changing the system since a small change to the UI can affect a large number of tests.

i18n trap #1: I should have a simple way to map an Enum to a presentable string.

This seems eminently reasonable at first glance – there are many cases where you have one of a set of things and need to inform the user which one you have. Unfortunately human language, unlike their computer language counter-parts, are context-dependent. So that single Enum value in code could well be presented with many different words when presented as part of different sentences or in different contexts.

You may have heard something about Chrome dropping support for H.264 from it’s Video tag implementation in favour of WebM. The reactions are unsurprisingly strong and partisan. From my point of view I see that:

• From a normal user’s point of view there is no discernable difference between a video that is played using the embed tag and one that uses the video tag. Advanced users may notice the performance difference or some of the particular behaviours of either Flash or the video tag but ultimately, both view the video perfectly successfully1{#footlink1:1295131564706.footnote}.
• Essentially the only users who can play video via the video tag but not Flash are iOS users.
• Before Google’s announcement, 99% of the web could view a video encoded in H.264 due to it’s support in Flash. About 40-50% could view one in WebM.
• Since every version of Chrome includes Flash, Google’s announcement did nothing to change those figures.
• There are already a variety of excellent libraries to allow the use of both the video tag with a Flash fallback.
• In order to maximise their potential audience, and thus business, content producers are going to supply video in the most widely supported video format.
• Since supporting two video formats simultaneously is expensive in terms of storage and bandwidth, content providers will avoid using a second format unless it is the only reasonable way to address a significant part of the market.

As a result, the only company who can exert any serious leverage on web video formats is Adobe. If they ship a version of Flash that supports WebM, suddenly it has traction very nearly equal to that of H.264 (but H.264 would still have the advantage of also working on iOS devices). For WebM to have the advantage Flash would have to support WebM and disable support for H.264.

There has been a trend over the past few years for open source projects to routinely ask for “donations” through a donate button on the site and increasingly in the software itself. I put “donations” in quotes because in the vast majority of cases these aren’t payments to a charitable organisation — they go straight into the pocket of the one and only developer.

Now it’s important to be clear, there are quite a number of open source organisations that are set up as actual charities or at least are independent organisations where the money donated actually goes towards the open source projects supported by that organisation. For example, when you donate to the Apache Software Foundation they use that money to pay for servers, bandwidth, legal advice the projects need, subsidising conferences around the projects and so on1{#footlink1:1294312313194.footnote}. These are great places to donate your money or time to — they handle donations very professionally as the funds directly benefit the projects and ecosystem around the projects.

CSS3 introduces the very handy columns support which is implemented in WebKit and Firefox browsers going back a fair way and degrades gracefully in all browsers that don’t support it (which appears to include IE9 sadly). The downside however is that support for the corresponding column-break property to control where column breaks are allowed to occur doesn’t appear to exist despite documentation suggesting it should. So for example1{#footlink1:1293713493905.footnote}:

<div style=”column-count: 3”>
  <div class=”item”>
    <h1>Heading</h1>
    <p>Content</p>
  </div>

  <div class=”item”>
    <h1>Heading</h1>
    <p>Content</p>
  </div>
</div>

Since column hights are always equal, the two items above will be split across the three columns. To keep each item together in a column, we should be able to use column-break-inside:

Many browsers include user preferences to select preferred colours for text, backgrounds and links. This is intended as an accessibility feature so that people with limited vision, dyslexia or other disabilities can choose a colour scheme that makes it easier for them to read web pages. In theory it’s a great idea. In practice however it seems to be nearly useless.

There are two “modes” these colour preferences can be used in:

I joined Ephox back in May 2002 and over the past eight-and-a-half years have had the pleasure of working with some of the most talented, dedicated, passionate and supportive people I’m ever likely to work with. It’s been an incredibly exciting time doing my small part to grow the company from a small team in Brisbane, Australia, though some very tight times to a very rapidly growing team with offices on three continents that’s firing on all cylinders.