This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment

JAX London 2012

Seemed like a quiet conference this year.  Not really sure why, maybe it was the layout of the massive (and extremely dark) main room; maybe it was the awkward L-shape of the communal space; or maybe this year people were more interested in listening to the (really very good) sessions rather than participating or meeting other people.  Whatever the reason, it felt quiet and almost low-key.

Performance seemed pretty high on the agenda, as you'd expect from a London conference, with a number of things on offer:

  • A great keynote from Kirk Pepperdine and Martijn Verburg, covering a massive range of things to care about when thinking about performance on the first night
  • A high-level talk about Java Performance from yours truly (which I may run again for the LJC if there's interest, but it's more likely to be a one-off)
  • A deep dive into writing lock-free coding by Mike Barker
  • And a talk from Kirk exploring your GC logs.

It was great to see a number of LJC regulars presenting, especially as my own schedule has been so crazy I haven't seen many of them for a long time.  So I missed sessions from Bruce, John, Sandro, Russell, James & Richard, but I heard good things about the sessions and was really pleased to chat to all of them.

The highlight of the conference for me though was Brian Goetz's keynote and subsequent session on lambdas.  I've been looking into lambdas because I think it's a really interesting addition to the language and I've heard a lot of noise about them.  What I thought was most interesting about Brian's talks though was less the information on what they were and how to use them, and more the challenges that face language designers when they have a language which is used by 10 million developers and has been going for nearly 20 years.  Ouch.  It's amazing they get anything done, let alone something like lambdas which the language was never designed to support.

In keeping with the new job, I went to a few sessions on the Big Data Con - frankly an unfortunate name I feel.  Brendan's Mongo & JVM talk was useful, especially given that I might actually be presenting that at some point.  What I'd love to see though is a more interesting story around the Java driver.  It seems people believe the Java driver needs a little love.

The other interesting NoSql talk was from Tim Berglund's NoSql Smackdown, which was a really great way of highlighting that the NoSql databases are not all solving the same types of problems.  The room was packed and the questions were intelligent, so it seems there's still a lot of interest in this kind of introduction to the technology.

Lessons learned:
  1. Commuting through Victoria Station sucks.  I knew this last year but it's just got worse.
  2. The iPad + stylus combo is not as precise as the graphics tablet, so I'm probably going back to that for illustrations.  But I'd still love to do free-drawing with the iPad on the projector at some point.
  3. Not everyone can follow the deep-dive tech talks, but they still prefer them to introductory talks, maybe because they feel like they're learning something (well, that's my opinion).
I took practically no photos because I kept forgetting I had my camera.  I think it's the weird subterranean effect of the hotel basement.  Either that or I've turned into a conference zombie - not an unlikely suggestion.  And I've still got Devoxx round the corner...

Comments

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the hea...
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at...
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously n...
Read more