From the job description:

We are seeking a Software Developer who is experienced in creating sophisticated, highly interactive, JavaScript applications. Ideally we desire someone that has experience in TinyMCE or has experience working as part of an open source project. The right person will have the ability to work remotely in a highly collaborative manner with virtual teams.

I’m pretty excited about this new opening within Ephox. Lots of great stuff to come out of it hopefully, but in particular helping Ephox to start working better with Open Source communities and developing some awesome stuff with JavaScript. While TinyMCE experience is something we’re particularly keen to have “ready to go” if possible, whoever fills this role is going to become a web content editor expert in general from Tiny to CK, Dojo and of course our personal favourite EditLive!

The position is open regardless of your location in the world, though if you happen to be near Brisbane, Maidenhead or Palo Alto we have nice offices you can come in and work from if you like.

If you have a method like:

String getParameter(String name, String defaultValue)

where defaultValue is returned if the parameter isn’t specified, it can be challenging to get the right behavior in JMock without just hard coding what the defaultValue should be. Fortunately, a custom match which doubles as an Action can solve this pretty easily:

import org.hamcrest.*;
import org.jmock.api.*;

public class CapturingMatcher<T> extends BaseMatcher<T> implements Action {
	public T captured;

	public boolean matches(Object o) {
		try {
			captured = (T)o;
			return true;
		} catch (ClassCastException e) {
			return false;
		}
	}

	public void describeTo(Description description) {
		description.appendText("captured value ");
		description.appendValue(captured);
	}

	public Object invoke(Invocation invocation) throws Throwable {
		return captured;
	}
}

It can then be used like:

context.checking(new Expectations() {{
	CapturingMatcher<String> returnCapturedValue = new CapturingMatcher<String>();
	allowing(mockObject).getParameter(with(equal("expectedParameterName")), with(returnCapturedValue)); will(returnCapturedValue);
}});

The matcher is used both for the parameter value (which it stores) and the return action, so it acts like a back reference would in a regex. The same class be be useful alone as a matcher to let you interrogate the parameter value using normal assert statements rather than building a custom matcher.

I really should investigate what the describeTo function really should do though – I’m sure it would generate pretty weird messages at the moment.

There’s been a lot of new innovations going on in programming languages and development techniques in general lately, but there’s a really key missing element: metrics.

Seeing posts like Stephan Schmidt’s Go Ahead: Next Generation Java Programming Style and the response from Cedric Otaku really should make any professional software engineer concerned about the future of their craft. Not because either of them are necessarily right or wrong, but because two highly skilled engineers are engaged in debate based purely on pure personal preference. There’s barely even any anecdotal evidence provided, let alone actual measurements to see what impact on productivity, quality or other desirable qualities the proposed approaches have.

A while back I stumbled across the slides from Greg Wilson’s presentation Bits of Evidence. It’s almost a shame that the slides are well designed because they really are a short summary and I’d love to have heard all the extra information Greg spoke about around those slides. Even so, they really highlight the fact that we’re rushing off down all these new paths basically just because some guy said to. One of the side notes sums it up really well:

Please note: I’m not disagreeing with his claims – I just want to point out that even the best of us aren’t doing what we expect the makers of acne creams to do.

It would be easy to dismiss the importance of this because in your own experience technique A works better than technique B and with regular Agile retrospectives you’d notice if it had failings and worked to overcome them. Unfortunately, you’re very likely to fall victim to the same selection bias that makes psychics believable. People inherently remember the “hits” and forget the “misses”1, so even personal experience isn’t something you should depend on to make decisions unless it’s backed up at least partly by real hard data.

I like playing with new technology as much as the next person, but at the end of the day I have to wonder if the benefits are always as compelling as we’d all like to think. Probability would suggest that some of the new approaches really are a big improvement, but it would also suggest some of them are a mistake. Without metrics to judge them on, how are we going to know the difference?

1 – Wikipedia claims this was first raised in Broad, C. D. (1937). The philosophical implications of foreknowledge. Proceedings of the Aristotelian Society (Supplementary), 16, 177-209. ↩

There’s a huge amount of new technology pouring out into the world these days – lots of it focussed around the web and consumers and the key term that keeps being talked about it ubiquity. Flash brought video to the web because it was ubiquitous, HTML5 will kill flash once it’s ubiquitous, mobile web access is becoming ubiquitous etc. The most striking thing in all of this is just how quickly these new technologies are actually finding their way into real world usage.

The path to ubiquity is suddenly an awful lot shorter than it ever has been. Take for example the rate of upgrades from IE 6 to IE 7, compared with IE 7 to IE 8. Flash support for H.264 is comparatively new but it’s now ubiquitous. Anyone supporting FireFox 1.0 anymore? What about 2.0? The upgrade cycle is so fast that the range of older tech needing to be supported has shrunk dramatically in the past few years.

How has all this happened? Auto-update became standard.

When IE 6 was first release, I’m not sure if Windows Update existed or not, but it certainly wasn’t turned on by default. Not so long before that, downloading software updates was really quite uncommon – you went to the store and bought the upgrade. These days, it’s expected that software includes an auto-update function and you assume it will be on by default or at least ask on first start up.

The best example of this that I know of is actually Java. EditLive! still supports the ancient and no-longer-supported-by-Sun Java 1.4, not because we like it but because it’s a key customer requirement and it keeps showing up in real usage. Java 1.4 didn’t include an auto-update mechanism, so it’s users had to take specific action to upgrade it and most of them didn’t care. Java 1.5 on the other hand, did add auto-update and as a result, while it still turns up a fair bit, it’s almost always at the latest 1.5 release and the same goes for Java 6. And that’s with the terrible upgrade experience Java provides.

The thing is, this rate of upgrading is only going to increase. iPhone software for example is updated incredibly rapidly because it all comes through the App Store and the more users see upgrades happening smoothly and successfully, the more they trust it to happen so the more frequently they’ll do it. Not to mention the more they’ll be willing to accept software that just silently updates itself.

For developers, this changes the way to view the world. It’s actually viable in many cases to target just the latest version of many new technologies because it’s easier for users to upgrade and more likely they’ll do it either now or at least very soon. It also means that things like the Flash vs HTML5 debate change quite significantly – the time required for the HTML5 tech to become ubiquitous enough is probably shorter than most people expect, much of it is already there. So the argument that Flash will have moved on by the time HTML5 catches up is a lot weaker than history would make it seem.

Look out a bit further than today and start thinking of the power that this auto-update brings. Imagine the world in say 5 years time – it’s likely that by then IE 6 market share will be small enough to be ignored by most or all people. So everyone would have upgraded to a browser of today’s standard or better – significantly, with a solid auto-update program. How likely do you think it will be that there’s significant market-share for anything but the latest and maybe second latest major release of a browser? That would mean that new web technologies would be rolled out to effective ubiquity within one or two years. Potentially much quicker if they’re released in a minor update which is also increasingly common.

The same thing is being outside outside of web technologies as well – in roughly everything except desktop OS’s. The bottom line is that developers have never had it better and can leverage newer and better platforms sooner to deliver more features, more easily. All thanks to the unnoticed workhorse that is auto-update.

Emmanuel Lécharny – Pick good names for your methods/data structures…

5 years later, when I come back into this crap, I have *no* bloody idea about what is what. Is Twix for the frontend or the backend ?

When you pick a name, and when you think it's funny, just think about those, and probably you, who will not have fun at all when it'll be time to fix some code in this area, with no clue about what Twix and Snickers are…

Oh yeah, been there, got burnt by that…