JavaOne: User Group Sunday

Well this is exciting! JavaOne 2011 is the first conference I spoke at, so this the first time I've covered the same conference two years running. I think.

It's very nice to be back at JavaOne. Last year it was my first opportunity to meet so many people - the guys at Oracle who work really hard to make sure Java has its own identity; the JUG Leaders and Duchess folk; the JCP EC committee members; and loads of people who live and work in the area who I wouldn't normally get a chance to speak to in person.

This year I'm here with several other London Java Community people, and it's great to be a member of the Alumni, to have the privilege of showing other guys around and introducing people to each other. It's nice to run into people I met here for the first time last year, some of whom I've had a chance to see at other events this year.

Today, Sunday, is an interesting day. The focus is on community, so I get to hear what other JUGs are doing, some of their pain points, and learn some of the things they're doing that maybe we should think about.

The day started well, with Jim and Richard de-mystifying the business and technology terminology we're bound to come across at this conference. 8:15am is a really harsh time to have to do your first presentation, but it had a good turnout and was a great way to kick off the conference.

I followed this with a talk about why you would open source your secrets, a short presentation detailing the benefits to your business of opening up parts of your codebase. It went better than expected, given my voice has all but disappeared due to a stupid cold and plane travel and jet lag (and noisy bars). I had contingency plans on how to present via typing or drawing on my iPad, but in the end I managed even despite the microphone not being turned on. Doh.

There were a series of presentations on how to make your JUG successful and how to run Adopt a JSR/OpenJDK programmes in your user group, before Ben and I had to dash off to the public EC meeting. This was not as well-attended as last year, but it meant that I had a chance to talk to all the EC members, and to drink more free champagne than one really ought to in the afternoon.

Next on the packed schedule was a trip to yet another location (seriously, that's 4 different locations just on Sunday) for the keynotes. Note: next time I say "it's not far, let's walk" in San Francisco, hit me with sticks. That's the second time in as many days I've been hit with a vertical distance that was further than the horizontal. At least this time I wasn't wheeling my luggage up the hill like I was on Friday.

The keynotes were definitely better than last year. I really enjoyed how the technical keynote put the shiny new stuff into an everyday context - seeing JavaFX running on all the platforms, including embedded, and seeing lambdas used in anger, was really engaging. In my mind, it's much more likely to get "real" developers using these things. I particularly enjoyed the interplay between Mark Reinhold and Brian Goetz, it's great to see people like that so passionate about what they're doing, it really humanizes them and their projects.

The last trip of the day was back down the hill to one of the many parties scheduled this week. Of course, it's not in every party that you get given an award, so this was particularly sweet - the London Java Community has been honoured with a Duke's Choice Award. This is the first year a community has won a "Dukey", and it's amazing to be part of a group of people who are actively contributing to the language I work with daily, and to be recognised for this. So yes, I was on stage getting an award again. It's addictive.

So, a really great kick off to this year's JavaOne, and I'm back at the apartment well before my coach (well, Uber) turns into a pumpkin and resting my voice in time for my Disruptor presentation tomorrow.

The Strange Loop

Last week (was it only last week?) I was at Strange Loop, presenting a workshop on the Disruptor.

I didn't really have any expectations from the conference, I've never been before and, if I'm honest, hadn't heard of it before. So everything was a pleasant surprise.

It's a very geeky conference. I mean that as a compliment, of course. Lots of very smart people talking about stuff that's waaaay more advanced than you frequently get in the conferences employers would be happy to pay for. The themes I mostly saw were functional programming and the (insert horribly abused term) Big Data space.

Continue reading "The Strange Loop"

Strangeloop Disruptor Workshop Materials

Slide: An Introduction to the LMAX Disruptor

On Sunday I gave my very first workshop on the Disruptor. The aim was to give people some hands-on coding experience using the syntax. Because time was limited (you can't get people to build an entire application architecture in 2.5 hours) the example is somewhat contrived, and needs a big leap to make it into a proper application context. But the workshop should:

Continue reading "Strangeloop Disruptor Workshop Materials"

Overheard: Development Myths

Continuing the theme of Things I Have Heard I Don't Think I Agree With.

To developers technologies are everything

I can't remember the context of this, but I hear the same sentiment in different guises over and over again. Often from non-techies, but more alarmingly from developers.

Is this true?

It's true for a certain tribe of techies, sure. And creating and effectively using new technologies is an important part of what drives the current information age forward. But I'd be worried if I thought that 99% of developers were like this.

In our day jobs, and also if we want to create something that makes any money, we need to be interested in solving people's problems and creating solutions. Sure, we'll use technology to do that. But if we were all only motivated by technology, we'd always be trying out the Next Big Thing when our customers wanted a simple CRUD web app. Any organisation that encouraged this sort of technology um, infidelity? playing the field? might find themselves with lots of fascinated and broadly-educated developers, but not a lot of productivity.

I always thought developers were drawn by wrestling with the machine to solve a particular problem, or to do something that hadn't been done before. I didn't think we liked learning Ruby because we didn't study it at university, or switching to a functional language simply because that's the way the whole world is going.

We can train The Business to speak our language

I've heard a number of people talking about the Holy Grail of having business owners write acceptance tests. At LMAX we have a (Java-based) DSL that theoretically could allow technical-ish non-developers to write our automated acceptance tests. However, is this the right thing to do? To make our jobs easier, and our code better quality, we need the business to become almost developers?

Our (very difficult) job as developers is to act as translator between the ones and zeros a computer speaks and the real life doman language our business guys (and girls) use. Forcing the business to become more technical is just, well, lazy.

So if our business people shouldn't be forced to become more technical, how can we bridge the gap? Is there anything that we as developers can do to move closer to the business?

A Ubiquitous Language is a good start. When a business user talks about an order, a developer should be thinking about the Order class, or something that implements an Order interface. When the business talks about placing an order, a developer shouldn't be thinking "place order translates into the execute method", they should assume there's a placeOrder method somewhere they can use as a start point.

We certainly shouldn't be training the head of sales to start talking in terms of Java classes or technologies - "I want the Resin tier to validate the order while the OrderMatcherImpl checks for availability". That would be silly.

Development is hard, that's why they pay us. And part of that hard job is learning the business model we're implementing so we can mirror and support the business. We shouldn't be inflicting our technology on the business.