As of this morning, the Disruptor Wizard has been merged into the core LMAX Disruptor source tree. The .NET port had included the wizard style syntax for quite some time and it seemed to be generally popular, so why make people grab two jars instead of one?

I also updated it to reflect the change in terminology within the Disruptor. Instead of Consumers, there are now EventProcessors and EventHandlers. That better reflects the fact that consumers can actually add additional values to the events. Additionally, the ProducerBarrier has been merged into the ring buffer itself and the ring buffer entries are now called events. Again, that better reflects the fact that the programming model around the disruptor is most often event based.

The one problem I’ve found when upgrading to Lion is that suddenly iCal couldn’t sync to my Google Apps Calendar account – instead it repeatedly asked for the password. I’m still not really sure what caused this, but my solution was to simply delete both ~/Library/Preferences/*iCal* and ~/Library/Calendars. You really only want to do that if you exclusively use Google Calendar. If you have local calendars deleting ~/Library/Calendars will delete them.

Martin Fowler has posted an excellent overview of the LMAX architecture which helps put the use-cases and key considerations that led to the LMAX disruptor pattern in context.

Good to see some focus being put on the programming model that LMAX uses as well. While convention suggests that to get the best performance you have to make heavy use of concurrency and multithreading, the measurements LMAX did showed that the cost of contention and communication between threads was too great. As such, the programming model at LMAX is largely single-threaded, achieving the best possible performance while avoiding the complexities of multithreaded programming.

The LMAX disruptor is an ultra-high performance, low-latency message exchange between threads. It’s a bit like a queue on steroids (but quite a lot of steroids) and is one of the key innovations used to make the LMAX exchange run so fast. There is a rapidly growing set of information about what the disruptor is, why it’s important and how it works – a good place to start is the list of articles and for the on-going stuff, follow LMAX Blogs. For really detailed stuff, there’s also the white paper (PDF).

As my colleague and favorite debating opponent Danny Yates noted:

We got into a bit of a debate at work recently. It went a bit like this:

“Gah! Why do we have this interface when there is only a single implementation?”

(The stock answer to this goes:) “Because we need the interface in order to mock this class in our tests.”

“Oh no you don’t, you can use the FingleWidget [insert appropriate technology of your mocking framework of choice here – e.g. JMock ClassImposteriser]! I’m smarter than you!”

Joyously, it looks like iOS 5 fixes the issues with contentEditable not working correctly in Mobile WebKit. A patch has landed in TinyMCE to enable the editor to work there. Great news.

Hopefully the changes to WebKit can flow through to Android as well.

With Agile and Continuous Integration becoming popular, a significant number of development teams are using information radiators – mostly focussed on showing the latest build status. Information radiators are a very powerful way to aid communication and subtly adjust a team’s behaviour and attitude. The catch however is that it can be quite hard to control how you subtly adjust the team’s attitude because the pressure to change is so subtle.

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.