Following on from my last post, Jason Adam Young has some excellent advice to help you continually get better and better and building software and perhaps more importantly, be more and more valuable to whoever you happen to be working for.

This afternoon during an interview, a potential new hire at LMAX asked what LMAX could offer in the way of career progression. Since I’ve been thinking a fair bit about what comes next in my career now that I’m moving back to Australia I thought I had a pretty good answer and that it might be worth sharing here2{#footlink2:1323196996971.footnote}.

In most industries career progression is signified by ever fancier sounding job titles, but for a software developer, the fancier the title sounds the less likely you are to actually do any development. Essentially, career progression often amounts to career migration – into “architecture”1{#footlink1:1323196219398.footnote} or managements. If you really love developing software though you need to look at it a different way. If I spend the rest of my career as a “Senior Software Engineer” I’ll be pretty happy, so long as I can keep honing my skills and becoming more valuable to the companies I work for. Ideally I’d like the pay I take home to grow in line with that value.

After four years living in the UK, my wife and I have decided to move back to Australia mid-February 2012 to be closer to family. As such, I’m now starting to look at job opportunities back in Oz. If you’re hiring, I’d love to hear from you and discuss how we might work together. My CV is available online to give you an idea of my experience and of course the backlog of this blog shows some of my thinking and learning throughout the years1{#footlink1:1322426906768.footnote}.

A couple of little patterns for writing long-poll based JavaScript applications have evolved in some internal apps I’ve been working on lately so I thought I’d document them for posterity.

Simple Long Poll Loop

Peter Lawrey posted an example of using the Exchanger class from core Java to implement a background logging implementation. He briefly compared it to the LMAX disruptor and since someone requested it, I thought it might be interesting to show a similar implementation using the disruptor.

Firstly, let’s revisit the very high level differences between the exchanger and the disruptor. Peter notes:

This approach has similar principles to the Disruptor. No GC using recycled, pre-allocated buffers and lock free operations (The Exchanger not completely lock free and doesn’t busy wait, but it could)

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.