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

London Java Community Open Conference

Saturday was, hopefully, my last conference of the year.  My lucky readers should start to see some posts which are not simply me gushing about another opportunity to hang out with awesome people and learn about interesting "stuff".

Who wants to propose a session?
In many ways the London Java Community Open Conference was my favourite one so far, and not just because it's near home and I helped to organise it.  One of the awesome things about both Java One and Devoxx was the opportunity to travel, to see new places and to meet people you might not meet in London.  The scale, and the opportunities to meet key players in the Java world, were the things I probably appreciated the most from both of those conferences.  And you can tell from my posts I really enjoyed them.


But the LJC conference was probably perfect as my last one for 2011:
"How do you spell 'lightning'?"
  • Being on home turf with awesome people who have really helped drag me kicking and screaming into the conference scene really brought home to me what an amazing year this has been.  This time last year, I felt I barely had the credentials to be a behind-the-scenes organiser for the LJC, and I didn't attend last year's conference because I wasn't sure how much I would get out of it.  This year, I'm at the conference giving two sessions, having made my international début already.
  • With 120 people you feel like you can talk to everyone at some point if you want to.  I don't think I managed that, but I probably chatted in one way or another with maybe half the attendees.  The great thing about this is you see the wide variety of things people are working on - the technologies, the business problems, the team and company sizes, the methodologies. It's eye-opening and quite exciting.
  • It seemed that a small, open conference like this drives content based on relevance.  We had no vendor pitches, although John was contractually obliged to mention Atlassian at least once every half hour (but as they paid for the beer, this was only fair).  People vote with their feet, and attend the sessions that they will get the most out of.  I liked this format a lot.
  • I presented alone for the first time, not hiding behind Mike or Martin.  I found this surprisingly liberating.  I love working with those guys, but without them providing a safety net I actually found my confidence increasing as I realised I was perfectly capable of answering things I would probably have let them field.
  • My second session was more workshop-like, and I wanted the audience to guide what we covered.  I thought it went really well, I loved letting the audience guide it, and I enjoyed giving it.
  • I was honoured (and terrified) to be asked to be part of a Meet the Experts panel with people who actually know what they're talking about.  I was very very pleased to get away with not being asked any questions about being a girl or the length of my skirt.  We had a great discussion around writing high performance code, about different technologies and their applicability, and about the future of Java and JVM-based languages.
  • I loved the venue.  The rooms were a nice range of sizes, all with projectors of course, but also whiteboard space and flip charts.  It looked like a 1960s version of the future - all shiny white surfaces and curving lines.  But it felt like a space to create and innovate in.
  • Mike's Hacking the Open JDK session in the morning was excellent.  Again, this was another example of a workshop format working really well.  He gave some good background to compilers in general, and a good walk through of some of the code that's there at the moment.  He was happy to share stuff he'd learnt the hard way, and it made me want to get more involved in that side of things.
  • The food was awesome.

Clearly people haven't had enough coffee yet.
My sessions were User's Guides to the Disruptor - a beginner's and a more advanced one.  The beginner's was an updated summary of the Disruptor stuff already covered in this blog - the ring buffer, writing to and reading from it, and configuration.  The second session covered  more advanced ideas: you don't need a ring buffer any more; cache lines and false sharing; worker pools; aggregate event handlers. This session was a lot less prepared and more collaborative, and I loved giving it.  Maybe that's my teacher-genetics coming out.

The aim of both sessions was to give people an idea of how to actually use the Disruptor - developers are definitely interested in how and why it works, but we've been evangelising a lot and now there are very sensible questions being asked about how to get it to do various things.  I'd like to run some more of these sessions in future, and to add more material to the blog.


And finally, a proper meal before more beer.
Back to the conference.  Were there any downsides?  Personally I had none.  If I had to suggest an improvement for next year, it's that we would like to see more novice speakers presenting.  The LJC has always been about nurturing this talent, and a small conference like this one with a friendly audience, many of whom you may already know, is a great place to practice.  The lightning talks showed the great variety (and abilities) of our members, it would be nice to expand this to full sessions.  As I found, filling a 30 minute session is not anywhere near as hard as you think!

I'm really looking forward to next year's LJC conference, and I'm totally buzzing from the positive vibe from this year's.
The LJC Associates modelling their lovely new t-shirts.  Mine fits!

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