YOW

December disappeared in a rush of vacation and a fleeting tour of Australia.  It's hard to believe that it's the eve of Christmas Eve already, it's almost impossible to feel Christmassy when you're getting sunburnt on a boat and seeing people in swim-suits wearing santa hats.  A mid-winter festival (complete with trees and fake snow) just feels very odd in summer.

I cannot take Christmas seriously in this weather

YOW! is a unique conference, in that it's the same agenda in three different cities: Melbourne, Brisbane and Sydney.  It seems to me that this is a great way to attract speakers from a long way away (and everywhere is a long way away from Australia) but make it cost effective - although you have to shuttle the speakers between the cities, you have the speakers for nearly two weeks and get the material three times in the three different locations.

I suffered a lot for this conference...

As a speaker, it's awesome - not only do you spend the better part of the month in the sun when your hemisphere is nearing mid-winter, but you also have the opportunity to really get to know the other speakers - you're sharing bus journeys, flights and dinners together for a week and a half.  Also, because you're at the same conference three times, you have the chance to see a lot more of the talks.  I admit I missed most of them in Melbourne because I was re-writing and practicing both my talks (note to self - next time, only commit to one talk), but by Sydney I saw the talks that I wouldn't normally get around to - talks on technologies I'm not currently using and probably won't get a chance to.  But it was great to see other approaches to problems, and the variety of presentation styles.

Since I saw most of the talks, I thought I'd give a run down of those I watched (now I feel bad I didn't get a chance to see everyone's, if I missed you it's not because I don't love you):


Computing Like the Brain: The Path to Machine Intelligence

Jeff Hawkins (@numenta)

I've seen Jeff talk on this subject twice before - an earlier version of the talk at Strangeloop 2012, and then the keynote at GOTO Aarhus.  It's a really fascinating approach to machine learning that's different to traditional Artificial Intelligence approaches.  It's waaay beyond my comprehension level, but reminded me why I studied AI at university.  If you get a chance to see it, I recommend it.  There's a video available of the Aarhus talk.

Safety Not Guaranteed: How Successful Teams Ignore the Rules to Create Successful Products

Jeff Patton (@jeffpatton)

A thought-provoking talk on how agile teams succeed.  Mostly it talks about how a process is not going to save you, that you need to find your own approach from all the practices that are available.  I liked the message because it's very Lean Startup-ish, and I think the approach of getting feedback and learning from it is the best way to succeed.  My take-home points:

• Change from a delivery-focussed organisation to a learning organisation
• Even if you're on time, you're probably wrong
• When we think "process" we rarely think collaboration and team
• Those guys aren't high-fiving because they hit a deadline.

A Little Graph Theory for the Busy Developer

Jim Webber (@jimwebber)

Even if you're not using Neo4J or other graph databases, it's worth seeing this talk just to understand what sort of problems graphs are good at solving.  Also to see how graph theory could have predicted the first world war (not sure if this was funnier or more awkward when Jim presented this in Berlin...).  A great talk if you're interested in Data Structures or the NoSQL space.  Not so good when Jim feels compelled to make Mongo Is Web Scale jokes because he sees yours truly in the front row.  Will we never get over that?  Jim's a great presenter and therefore this theoretical talk is very approachable.

Take home points:

• With graph databases your query emerges from the structure of the graph itself
• It seems like another interesting way of modelling your domain
• Most databases are tuned for size because traditionally size impacts the cost of querying
• In a graph database, query latency is proportional to the size of the graph you want to explore (not to the whole database).

Beyond JVM

Charles Nutter (@headius)

Quite an in-depth talk about how the JVM could evolve to support more than simply Java-the-language.  Interesting at an abstract level for us Java developers to see how our language is not the be-all and end-all, and get a glimpse of things we might need to care about in the future.  Not too many take-home points for the every day developer, but definitely interesting for those more interested in how a language is built and what goes on behind the scenes.

NoSQL & NewSQL - The Empire Strikes Back?

Dave Thomas (@daveathomas)

A look at the whole landscape - past, present and future - of RDBMS/SQL, NoSQL, NewSQL.  It's a good way to step back and see what's going on there, not to blindly follow the new trends.  The thoughts that occurred to me:

• NoSQL solutions might not be the silver bullet solution, but by offering lots of different persistence options we're challenging perceived best-practices and having conversations around how to store and access our data
• SQL was never actually evil.
• Joins suck; the O/R Impedance Mismatch; two phase commits are expensive
• Map/reduce is the best way to query NoSQL stores?

Five Years of DevOps: Where are we now?

Michael Nygard (@mtnygard)

Michael gave a really great talk on where the DevOps movement started, what it's all about, and tackled some of the fears and obstacles that people and organisations face that can prevent them doing things in a more DevOps-y way (and problems that you keep seeing when you separate Dev and Ops).  I saw a lot of things in this talk that resonated with my experiences, and it was another example of how the hard stuff in our jobs is all about the people and the politics, not the technologies.

• What if you measured Ops on the number of features going into production, and Dev on the stability of production?
• Performance is a feature.
• You'll never teach yourself out of a job, the more you teach, the more people will rely on you
• A failure-inducing system is a system that lets people fail.  Don't blame the people.
• Your development tools and environment are part of production, because they are on the critical path to production, and should be treated as such.

The SOLID Design Principles Deconstructed

Kevlin Henney (@kevlinhenney)

Given my interest in Software Design this year, this was a talk that was close to my heart. It looked at each of the SOLID principles, where they came from, what they are, helped us understand why we need to care about them (or not).  It became clear to me that as we become more experienced, as we grow, we need to continually re-visit the things we think we know, or the basics of what we're trying to do, as you'll find things there that surprise you - things you thought you understood, or things that you didn't understand before and now have more context for.  In particular, I learnt another argument against using inheritance willy-nilly (one of my current favourite bug-bears)

• Writing software is like writing fiction.
• Experts say "it depends" because they know a number of rules which might be applicable.
• You can't change published interfaces because other people are dependent upon your code (pretty much the entire basis of my Backwards Compatibility talk), but if you own the code you can change it to your heart's content.

Creating Observable APIs with Rx

Ben Christensen (@benjchristensen)

Netflix are doing some really amazing stuff with architecture, design and code, and what I love the most is that they're willing to share it with the rest of us. Rx and reactive programming are big buzz words at the moment, and the event-driven, asynchronous approach is something that we embraced at LMAX and is now, to my mind, an "obvious" way to create scalable systems.

I liked Ben's visualisation of the events in the system using marble diagrams, and I liked that he showed us code and walked through it.  There were a number of things to get your head around in the talk, and I personally would like to see it again to see what I missed first time around.  Definitely worth watching if you're interested in this way of coding, I think it's a paradigm that will be used more and more.

Hiring (or Growing) the Right Agile Coach

Lyssa Adkins (@lyssaadkins) and Michael Spayd (@mspayd)

I don't know why it never occurred to me that you could create a framework for professional development for agile coaches.  Lyssa and Michael have done just that, and having something a bit more formalised helps figure out what a coach needs to do in order to develop further.  Agile coach, scrum master, iteration lead... all these titles do not currently tell anyone how good you are at the job or what your strengths and weaknesses are.  The Agile Coach Competency Framework seems like a good starting point for conversations around: the coaches you have; the coaches you need; your current skills as a coach; the direction you want to go in as a coach.  If you need to hire or develop an agile coach, or if you are a professional in this space, this is worth looking at.

Disruptor 3.0: Details and Advanced Patterns

Mike Barker (@mikeb2701)

I was so pleased to hang around with my old LMAX colleague during YOW that I totally failed to take the time to see all of this talk.  Depending upon the city it either clashed with mine or was immediately before.  However, it's a must-see for fans of the Disruptor, Mike goes into detail about what's in the latest version of the Disruptor, how and why these things work.  I'll definitely be watching the video when it's online.

Angle Brackets, Curly Braces, JavaScript & Assembler

Scott Hanselman (@shanselman)

A funny, polished, brilliant keynote.  Honestly I can't remember anything about it other than something-something-Microsoft-cloud, and push things down to the client because there's power there, but don't let that put you off - I did not write notes, I simply sat and enjoyed every minute of it.  It was a great performance, and a reminder of how much practice it takes to become a truly good keynote speaker.

Programming In Time - Live Coding for Creative Performances

Andrew Sorensen (@digego)

I have only one word in my notes for this talk:

Awesome.

It was the best presentation of the conference.  Different to anything I'd seen before, engrossing, creative, fun.  Sure, watch the video, but if you get a chance to catch this at any other conference, I highly recommend seeing it in person.

Handling Uncertainty with Behaviour-Driven Development

Liz Keogh (@lunivore)

I nearly didn't go to this talk, because we did BDD at LMAX and I'm trying to lead us towards this at MongoDB and I know all this stuff blah blah blah.  I'm so glad I did go - not only is it nice to have your opinions confirmed and the concepts you try to live by repeated to you again, but there were things in here that should help me push the BDD approach more.

One of the things I remember Liz for is explaining the use of the word "should" at the Lean conference at Bletchley in 2010.  In this talk I was struck once again how important the words we use are: should, given/when/then, and so on, giving us a framework for thinking about a problem.  It's one of the reasons I wanted to move towards Spock, because it forces the use of some of these words.

I wrote lots of notes:

• Assume you got it wrong
• Is there a context in which the event will create a different outcome? (Your account is empty, the ATM is out of cash, you have a pre-approved overdraft)
• Don't think of the software that will solve the problem, assume it will be done by pixies (like Pratchett's Iconograph), forcing us to stop thinking of solutions when we're trying to outline the problem.
• Not all user stories are about the user, they might be about other stakeholders
• Acceptance criteria vs scenarios - "Can you give me an example?"
• Ask why a change needs to be made or why something is a bug, if I've messed up this feature I might have messed up something else
• Testers do think differently to developers, they have a process of deliberate discovery
• BA/Dev/Tester huddle - the three amigos
• If a project has no risks, don't do it
• Complicated/Complex/Chaotic/Simple projects/systems.  Some types of systems don't lend themselves well to BDD
• All the risk is in Complex problems, and this is also likely where the value is.  This is the area that developers tend to like to live.

Afterwards I questioned Liz on her separation of Devs and Testers in the talk - this seems contra to the current trend of hiring developers-in-test or other moves to make QAs and developers one-team-one-dream.  She pointed out that it's less of a job description and more of a role that people take in a team.  Then she suggested I was currently in a tester role, not developer, as my mindset is very much focussed around proving our code quality rather than jumping in and implementing features.  I think it was meant as a positive thing...

Practical Considerations For Microservice Architectures

Sam Newman (@samnewman)

"Microservices" is another one of these buzz words doing the rounds at the moment.  There was a lot of discussion amongst the speakers about how micro is micro, and one definition I liked was "a microservice is a service that does one thing and one thing only".   In Sam's talk I got an idea of why microservices are a Good Thing, and how you might go about moving in that direction.  There was practical advice on things you should be doing if you're using this kind of architecture:

• Align your services with your organisational structure
• Microservices let you deploy independently and move faster, and you can run each service in whichever technology / language is right for the job
• Standardisation vs autonomy - standardisation between services, autonomy within.
• Pick conventions and stick with them
• Try not to support distributed transactions
• You need to get better at monitoring
• Can create tracer messages that flow through the system
• Create templates that do the right thing, make it easy for people to do the right thing.

Google Earth Engine: Enabling Science with Novel Software

Mike Dixon

I saw this because I'm interested in geolocation and geo-stuff at the moment, but this talk wasn't really about the sort of thing I'm playing around with.  It was (to my mind) really interesting material though - using satellite images from the past few decades to spot patterns and predict things.  It's really nice to see applications of technology that could potentially impact the whole world, rather than just things that make money for companies.  My Dad, who's a geography teacher, would have loved this talk.

Cloud Native Architecture at Netflix

Adrian Cockcroft (@adrianco)

Really interesting talk, always to a packed room, about how Netflix has created a scalable architecture.  As I said earlier, I'm really impressed with what they're doing, I'm particularly interested in their chaos monkeys and primates.  I definitely recommend seeing this presentation.

Move Fast and Ship Things

Joel Pobar (@joelpob)

A look under the covers of how Facebook ships things.  It's a very interesting contrast to the Netflix, microservices approach.  It's great to see the different approaches at the same conference, maybe it gives people an idea of the pros and cons of each way forward.  

What I particularly liked from Facebook was that the teams seem to be set a goal, and then they're free (to some extent) to pick what to work on in order to meet that goal.  There's definitely an experimentation side to things (very Lean Startup again), a lack of fear of trying new things, some stuff will work and some won't, that's life.  But at the end of the day there's a definite measurable that will tell you if you're doing the right thing or not.  On the VM team, the aim is to get CPU cycles down, that's it.  This is a very different approach to having a backlog of stories that's prioritised by the business.  Interesting and useful stuff in this talk.

Lessons Learned from Adopting Clojure

Jay Fields (@thejayfields)

I'll be honest, I went to this talk because I chatted to Jay a number of times throughout the travelling circus, and I liked him - I have almost zero interest in Clojure at this moment in time.  But I'm really glad I went, because I learnt loads of stuff that's relevant for my day job (who knew?).  This presentation is basically about how to introduce a new language into a company/team, and he's able to show the process over a period of several years, which in our industry is a life-time - many talks are around the latest, shiniest thing a company has introduced.  He speaks frankly about the cost of introducing a new language, gives some good advice on the approach to take, and personally made me wonder if I might have bitten off more than I can chew by sneaking Groovy into the Java driver via Spock and Gradle.

• Don't force people to use a different editor AND a different language - if you take away both comfort zones you'll meet resistance
• Keep the other tools in place too - ant, maven, etc.
• Choose non-production code to try it out on
• Choose code that showcases the power of the language, its strengths
• Choose something that you're willing to keep in the old language, in case it all goes horribly wrong and you have to go back
• When you've introduced a new language, you've just given yourself a second full-time job - supporting that language, training people, etc.  
• You need to know everything - you are the expert.  Read everything.
• Get a budget for training and support
• "It's practical to get your career sorted before playing with new technologies" (I wrote that down and now don't remember the context, but it's an interesting point)
• There's so many things you can do by innovating and adopting a new language.

Focusing the Core Domain: Domain-Driven Design Case Study

Eric Evans (@ericevans0)

I always love meeting people who's books I've read (or at least, started).  I've been really interested in the Domain Driven Design stuff since the guys were banging on about it at LMAX, and I've tried to use some of the concepts to drive the design of the new Java driver for MongoDB. This presentation was a specific (anonymised) case study of applying Domain Driven Design.  My main take away point is that not plunging into development, that asking questions, that waiting, is sometimes the best thing you can do.  

Mobile Web Whirlwind Tour of PhoneGap, Cordova & Topcoat

Brian LeRoux (@brianleroux)

I'm not doing mobile development at the moment, so this is another talk I went to because I met Brian at the various speakers events and wanted to see his talk.  It was another talk I really enjoyed - very well presented, technical, code-y, entertaining.  And it also blew away my preconceptions about PhoneGap, an opinion I had formulated during my very short stint working at ThoughtWorks three years ago.  If you're in the mobile space, or even in web development, definitely worth watching.  If not, then maybe just give it a watch to see what's happening out there.

• "We're web developers, we don't need tests"
• Cadence and project heartbeat really important
• "Performance first", but actually it's about the people
• Find one thing and do it well
• Measure everything
• Build a real app and extract out the components, instead of doing enterprise architecture
• Help pages with example code templates: "developers copy and paste, at least this way they'll be copying the right stuff"

What colour is your backlog?

Philipe Krutchen (@pbpk)

Scrum-type methodologies tend to focus on user stories and feature delivery.  This presentation talks about physically colouring the different types of work that you have in your backlog (tech debt, bugs, stories, architecture) and understanding how to prioritise each of them.  This talk is worth seeing if you are in a Scrum-ish environment, and you have a backlog of stories.  If you're struggling to find time to address tech debt, this is probably applicable too.  For me, the take-away point was simply having visibility of the different types of work - often the backlog only contains stories, and the other stuff is missing.  From there, you're in a better position to work out how to prioritise things.

No App is an Island

Stewart Gleadow (@stewgleadow)

More and more people are talking about APIs, especially as we now have lots of different ways of getting to data/applications, even if you just think web/phone/tablet.  Stew gives very solid advice on how to build APIs so that you can correctly separate back- and front-end, and create (specifically) great iOS apps.  There's a good intro to what REST really means too.

• Different devices don't have to share the same API if it doesn't work well for them
• On Objective C: "It's like ugly Ruby, or beautiful Java"
• From day one send the information about the client version, the handset etc. to the server
• You must worry about backwards compatibility because there's a very long tail on app upgrades
• Libraries that bind your JSON have tight coupling
• You can ship client code that checks if a feature is available on the server and ignore it if not - that lets you turn on the feature at the server-end
• Encourage upgrades to the new version, by doing things like "if you had version 347 you could use this feature"
• The phone application is the hardest thing to change so it should not be your integration point
• You need an anti-corruption layer, your phone should not be pointing to the internal systems.  This will be your mobile API, and can include caching and security
• If your logic is in the client, it's in the place that's hardest to change.

And then there's my talks.  Like I said, I was foolish enough to say yes to giving two of them, but the great thing was I got the chance to do a fluffy talk and a technical talk.

Career Advice for Programmers

Dave Thomas saw me give a talk with this title at Aarhus, and asked me to present it at YOW.  I was really pleased to get this chance, because conferences often find it hard to excuse a talk that might suggest you get a new job when your employer probably paid for your ticket.

I wasn't that happy with the Aarhus version, if I'm honest - I was trying to squeeze everything I'd learnt about managing my career over the last 15 years into an hour's talk, and I failed horribly.  I re-wrote it almost entirely for YOW - it's clear there is a lot of stuff I'd love to talk about that I didn't get a chance to cover, but hopefully this talk is more broadly useful for everyone.

YOW might not have been the best audience for it, as most people had my level of experience or more, and a number of people said "I wish I'd known that 10 years ago", but my experience seems to tally with other people's, so maybe it will be helpful to more people over time.

It's kinda weird to stand there and talk about all the choices you made to get to where you are, the mistakes you've made and explain some of the choices.  Especially weird if some of my ex-employers ever see the talk.  But I did learn a lot of things the hard way, and I didn't end up here by accident, I want other developers (especially those in the early stages of their career) to learn things the easy way.

What do you mean, backwards compatibility?

So yes, I've given a talk with this title a number of times this year.  It morphed from the original version into two different talks - "Design is a Process, not a Document" and a more MongoDB-focussed one, which I reused the original title for.  This newer, MongoDB-focussed one is what I gave at GOTO Berlin, and I decided to use this for YOW as it's a technical (ish) talk that goes into some detail about MongoDB, and they do pay my rent.

The really great (or possibly, bad) thing about YOW is that because it's the same conference at three venues, only a few days apart, it gives you a chance to put your Lean Startup knowledge into practice - you can experiment, get feedback, and improve.  Like the GOTOs/QCons, they have a Green/Yellow/Red feedback system from the audience so you can get a feel for how they liked your talk (the Aussies are a bit non-committal, they were keen on the Yellow button - commit one way or another!! (or don't, I don't want more reds)).  So decided to A/B test my talk - at Melbourne, I gave the GOTO Berlin one; at Brisbane, the original one with updated code and design diagrams.  Since the Brisbane one got a higher score, I went with that with some minor tweaks for Sydney.  The upshot is, people like hand-drawn pictures of monsters, and are less keen on understanding the internals of MongoDB.  That's useful to know.

But the talks aren't the only things that make a conference.  And YOW got the other stuff right too:

• I loved the drinks receptions in the evenings, that's a great place for people to come and ask you questions about your talk, stuff they might not want to share in front of everyone.  Note to attendees - if you do see a speaker at a drinks/network/mingle event, feel free to chat to them.  We're there for you guys, and we're only people ourselves and like the company.  At many events, the speakers know very few people.
• Sydney had an outdoor eating area, which was awesome - if you're going to spend weeks in a conference hall, it's nice to get outside for food.
• There was a, um, misunderstanding about appropriate dress code for one of the vendors.  The conference organisers were on this immediately, and, to their credit, the vendor acted swiftly with no fuss.  A great example of how to handle this sort of thing at tech conferences.
• Having all the travel and accommodation, particularly for this complicated trip, arranged by very capable and approachable people made the speakers' lives really easy, and I think that helped us to be more prepared and relaxed for our talks.
• A speaker's excursion (on a boat!) at the weekend was an amazing way to bond with the other guys.

I loved YOW, I hope I can go again.

First presentation at the Virtual JUG!

Yesterday I had the privilege of presenting the very first session for vJUG, a new virtual Java User Group that allows us to span geographies when sharing talks and stories.  I'm really interested in the vJUG idea, especially now I'm not in London - if we can find good ways to share knowledge without having to travel, that will help us reach people who don't normally go to conferences or don't have a local user group to go to.  Not to mention cutting travel costs and saving the environment.

See the event, and the record of the IRC chat, here:

 

The slides are also online, but obviously they're part of the video as well:

Design is a process, not a Document from Trisha Gee

JavaOne 2013

So, I thought a few months ago that my blog would become more of a travel blog than a tech blog because of the amount of conferences I was going to.  Turned out that I was so busy writing / updating / practicing talks and workshops and, er, travelling, that I never got around to doing retrospectives on the events I'd been to.

So, JavaOne, again, my third year there.  I'll always have a fondness for it - because of Martin Thompson, it was the first conference I presented at.  I know people always start with "it's not what it used to be" or "why isn't it in the Moscone?".  But not having ever been in the good ol' pre-Oracle days, I don't have that to compare it to.

I do have the previous two years to compare it to, however.  This year, I think the quality of the presentations was much better compared to the previous two years (although I can't accurately speak for last year as I spent the whole time running between my presentations and other LJC presentations).  I learnt something in all the talks I went to this year, in particular:

• Designing with Lambda Expressions in Java - Venkat doesn't simply cover the syntax of lambdas, but how they encourage us to use different design patterns to those we commonly use. Very informative.
• Lambda: A Peek under the hood - Brian Goetz goes into detail of how lambdas are actually implemented.  Not something an everyday developer needs to know in order to use them, but extremely useful if you want to understand things like their performance, and why they're not simply syntactic sugar.  Despite thinking I understood this stuff, I still had to watch this twice (once at JavaOne and once at GOTO Aarhus) before I could say I understood it.  Totally worthwhile making the effort.
• Making Java Groovy - A great, engaging talk about how Groovy and Java can live side by side, and showcasing some of the nice features of Groovy.  I found this particularly helpful now we're using Spock and Gradle, and learnt some new tricks.
• MongoDB for Hibernate/JPA developers - Obviously Justin is my colleague, so I should give him a shout out.  But what I like about this talk is that it does what it says on the tin - introduces MongoDB for those of us who are/were used to working with out databases in a particular way.

I also liked Martijn & Ben's Lean Startup Ninja talk, even if they weren't terribly complimentary towards MongoDB.  The talk doesn't seem to be on Parleys yet, but keep an eye out for it - it's a nice, realistic view of the trials and tribulations of running a startup.

These great sessions were really a bonus for me.  The main reason to go to JavaOne in my opinion is to meet people - it's west-coast, and I don't get a chance to get to California very often.  You see or meet those who are working to advance Java-the-platform and Java-the-language, and there's a big focus on community so you also get to meet as many of the Java User Group leaders as can make it out there.  In addition, there's the folks working hard on the java.net website and those involved in the JCP process, deciding the standards of the language.  Although there's some overlap between all these groups, by spending some time with all of them you get to meet a really wide range of people. You get to hear what people are working on, what's coming down the line, and often get a chance to influence that too by giving your opinions (nicely, of course!).

Of course there's the parties too, although I've been threatened with being removed from the invite list of the Zero Turnaround party next year since I failed to show up this time.  My favourite was the JCP party - great food, and amazing views of the city.

There's some other conference going on at the same time, over in Moscone. Something called Oracle Open World. A few of us snuck over there to take a look at the massive MongoDB stand there (in the heart of Relational-Database-World!).  Open World is a scary place filled with people in suits, looking to sell or be sold to.  It's also massive.  We chatted to our mates there and then ran off to eat burritos.

A bunch of us also got a chance to go to the Google offices in San Francisco. We slid on their slide, tried Google Glass, got photos taken in their photo booth, ate their food and drank their drink.  I was pleased to see it wasn't anything like The Internship (a film I tried to watch on the plane on the way over and could not finish - I was really disappointed with the enforcement of industry stereotypes, and the portrayal of elitism.  But maybe it's just me). They also have amazing views of the bay.

In Summary, JavaOne is as relevant as it ever was.  The themes of this year were definitely Java 8 (lambdas in particular), alternative JVM languages (which now seem to be used enough in mature systems to be viable for more conservative organisations), JavaScript on the server, and as always there's a lot of noise around front end and web, although I'm still not sure Java has a really nice, easy way to create a web application.  

JavaOne is still the place to go to hear what's in the pipeline, to meet the people working on this pipeline, and to influence the future of Java.

Oh, and I gave a talk:

Devoxx UK 2013

Last week was the first Devoxx UK, bringing the brand from Belgium and, more recently, France.  And I think it was a HUGE success.

Of course, disclaimers first - I was on the programme committee, so I might say that the whole thing was awesome.  Although in all honesty, even being slightly involved in the organisation of a conference is a lot of work, and you can't wait to see the back of it (and I didn't do half as much as some people).  Note to self - never speak at a conference you're on the programme committee for, it's too much work.

As a speaker and attendee though, Devoxx was really brilliant - great speakers, interesting content, awesome friendly atmosphere, good venue, parties with free drink and good opportunities to speak to people.  There were downsides: limited coffee availability, no free croissants, um... I'm really struggling to think of anything else, and none of those are show-stoppers (especially when the venue is in Islington, so you can step outside and get whatever you want).

All throughout the run up to the conference we kept hearing it was a conference "for developers, by developers" until I was nearly sick of it.  But it was a mantra that kept us on track when we were deciding on content, and it really came through on the two days of the conference.  Pretty much everyone on stage was, or had been, a developer, the talks were a good balance between "useful" stuff for our day jobs and "interesting" stuff for techies <insert joke about some being "useful" and "interesting">.  The future track excited us with things like like hacking on the Raspberry Pi, and the rest of the conference had a good mix of Java SE, EE, methodology and Other Stuff.

For me, the highlights were:

• Kevlin Henney's keynote, reminding us that Developers Are Human.  Who knew?
• Sandro Mancuso's walkthrough of OO principals, and how they apply to us in our actual day jobs.  Sandro did a good job of taking quite a dry topic, that many of us dozed through at university, and showing us why we already use these principals and how understanding them will make us better programmers.
• Mazz Mosley had an entertaining talk about the Dark Side of Agile, walking us through the agile practices in The Government and highlighting many of the unanswered questions that teams have after switching to agile.
• Colin Vipurs's talked about Test Driven Development from the trenches - he managed to give a good intro for those who might not have done it in practice, but for those who may have been doing it for a while, this a) was a good reminder of good practice and b) gave a good insight into why we do it.  On top of that, he had solid advice on how to write better tests, that we could all take home with us.
• Martin Thompson gave the talk I was attempting to give at JAX London last year - what is performance and how do we achieve high performance in Java?  Where I failed, Martin really rocked it.  I'll be leaving that to the professionals.
• It would be rude of me not to mention this point - what a diverse conference!  We had developers of all shapes and sizes, from the suits to the mohawks, of all colours, and (by technical conference standards) lots of women.  Watch the video below and I think you can see it.  I was so proud to have been a part of it.
• ...and meeting everyone.  What an awesome conference for networking!  Of course, there was a large number of London Java Community people there (speaking, volunteering, and attending), and quite a few familiar faces from Devoxx Antwerp - it was brilliant to see them in London.  But I was also very pleased to run into people I've worked with in the past, some I haven't see for ages, and some I still see regularly.  And I met dozens of new, interesting people - you guys really made the conference for me.

I was giving my new presentation, What Do You Mean, Backwards Compatibility?  In this talk I share some of the experiences I've had in helping to develop the new MongoDB Java driver.  This is not really a MongoDB talk, although there are some examples from the new driver, it's more a talk about design, and how we as developers make design decisions every day, something I don't think we recognise very much.  As always, I'll post a link to the video when it becomes available.  However, I am hoping to give this presentation a number of times this year, so if you missed it there will be another opportunity to see it.

As usual, my take-away theme from a conference is probably influenced by the sessions I attended, so is as much a function of what I think is important right now as it is an indication of what themes are emerging in the industry.  But I came away from Devoxx feeling like there's a desire to focus on the basics - the OO principals that have been around for years; the good design practices that have been written about many times; and, most of all, a reminder that developers have a difficult job - we don't simply turn requirements into code, we are constantly doing tricky stuff like system design, and even trickier stuff like working with other people.

I loved Devoxx UK, and I wasn't alone in feeling a bit empty when it was all over.  To re-live a tiny amount of the event, or get a good feel of what it was like, watch this video by the awesome Roy van Rijn.

Devoxx UK 2013 - Long mellow version from Roy van Rijn on Vimeo.

As with all Devoxx events, the talks will be available on Parleys.  If you watch nothing else, watch Kevlin's keynote.

My First Official MongoDB Appearance

Yesterday I had the nerve-wracking dubious alarming great pleasure of presenting my first official MongoDB-shaped talk.  This was in the form of a webinar, which is an interesting and different format.

I naïvely assumed it would be like a presentation but without the visible hand-waving, but it isn't really.  For a start, you can't easily poll the audience to find out what their level of experience is, and taking questions is quite tricky, even with the technology to support it.  Also, because you're not standing in front of people, I think the "rules" around making sure your slides don't distract from you are a little different - it strikes me that webinars are more like a set of slides with a narrator and a fixed time, than a presenter with a set of slides to emphasise points.  This puts the medium in an awkward position between an infodeck and a talk (yes, I am reading Presentation Patterns at the moment, and it's making me very conscious of all my slides and presentations).  So my slides are more info-heavy than my usual style.

I actually learnt a lot while I was putting together this webinar, so whether you're completely new to NoSQL/MongoDB, or just starting to use it from a language running on the JVM, it's worth checking out.

(Or see the webinar and slides together)

As always, feedback very much appreciated - I think there's great material in here, but I already have some ideas for improvement.

Introduction to the Disruptor Slides

I've produced a very cut down version of the presentation I've been giving at a lot of conferences, giving a high level overview to the Disruptor.  This serves as a quick intro to the concepts behind it.

Introduction to the Disruptor from Trisha Gee

My slides are usually pretty useless without me (or someone else) talking over them, so for more context don't forget there's always my original blog posts (the Magic Ring Buffer, Reading from it, Writing to it, Wiring it up), which are now pretty dated, and the Java Magazine article I wrote at the start of the year.

The birth of a new community

Topping off my mini-tour at the end of May, I was invited to Rotterdam to present to a brand new community of developers.  I was really interested in attending because my experience with user groups is pretty much limited to the London Java Community, and I knew this would be different due to being a) across a wider range of technologies and b) shiny and new.

It was hosted (rather awesomely) in a brewery, and until then I'd never given a presentation in a pub.  Frankly it's something I'm keen to do more of.  Due to a total technology fail on the part of all of us, we couldn't get the projector working with any of the various laptops.  However, with 30-odd techies, free wireless and slides available on Slideshare, we managed a novel and collaborative presentation approach, with people clustered around the laptops with the largest screens, and someone at each one valiantly keeping up with my quick pace through over 100 slides of stick-men drawings (a review of the evening is available).

I really enjoyed it, it was quite a change of pace from the conferences - my first attempt at presenting after imbibing probably a little toooo much wine, and a much more intimate venue which encouraged a lot of questions and discussion.  It's actually a format that worked, and maybe there's a way to get it to work even more smoothly, if the slides on all the laptops were synchronised, and there was some way for me to gesture wildly at the appropriate parts of the slides like I do when I'm on stage.  Hmmm, maybe that's actually a webcast now I think about it.

So I had an excellent time, thanks to the hospitality of the rather awesome Rotterdam-ians.  What I found fascinating  - as well as the venue and the novel presenting style - is the formation of a group of people with broadly similar interests.  One of the great strengths of a place like London is its size - you will find a number of people here with interests like yours, and sites like Meetup make it ridiculously easy to find them.  One of the weaknesses of London, however, is its size - there are so many people you could attract that you end up narrowing your search field.  You pick a very specific technology, a tiny geographical area, a single interest, to build a community around.

I've been thinking for a while it would be nice to have a community of people who aren't all the same, who share overlapping but different passions.  But how do you create something like that?  You need a single thing to draw those people together, otherwise they'll never find each other.

In smaller cities the geography limits the numbers, so you can have a broader range of interests represented.  In London, I can see something as (relatively) specific as a Java User Group becoming even more specific.  With nearly 2500 members, you could easily spin off Java-for-banking, Java-for-gaming, Java-in-west-London-zone-2 etc etc.  In fact, we've already spawned off a number of groups like the Graduate Developer Community, the London Scala Users' Group and so forth.  With nearly 2500 members, you cannot possibly meet them all, you can't even get a feel for what everyone's into.  How do you get the intimacy from a smaller user group without narrowing the scope so much that all of you might as well be clones?  The awesome thing about user groups is coming across new ideas, seeing solutions to problems you didn't even know existed, hearing about things people are working on that never occurred to you.  For that, you need diversity.

And one of the nice things about a city as large as London is you get plenty of diversity.  But how do you pull together that diversity?  How do you create a group that is diverse, when by necessity you need something central for those people to gravitate towards?  And if the diversity creates a large group, how do you create intimacy and feel personally involved, the stuff that comes for free if you belong to a smaller group where you know everyone?

In Rotterdam, at the Girl Geek meetup, I saw the advantage of using something other than a specific technology to gather together a group of interesting people - you get a wider range of experiences and passions.  How you can achieve this without using geography or genetics to select your participants?

Is it even possible to build a community when your goal is diversity?

Why Open Source Your Secrets

Here's a video of my Open Conference session on the business benefits of open sourcing your software.  Given that the conference was at a weekend and had a very intimate feel, I think I was a teeny bit more honest than I usually am.  Enjoy.

Why Open Source Your Secrets

View more presentations from Trisha Gee.

New Disruptor Presentation Unveiled to the LJC!

A few weeks ago, I presented my new "User's Guide to the Disruptor" talk to the London Java Community.  Since it was very kindly hosted at Skillsmatter, there is a video of the presentation available, and the slides are below.

Concurrent Programming Using the Disruptor

View more presentations from Trisha Gee

The presentation is a little different to the ones we've done before.  Previously we've gone into how it works and why it's fast.  This time I wanted to step back a little from the internals and show how real developers might actually use it.  The example is somewhat contrived, but the idea is to give some hints on how to break your problem down into something that will work with a Disruptor at the heart of it.

I thought the event went really well.  It was a tiny bit completely intimidating, as there were no lightning talks and I was the only attraction.  Seeing over a hundred people turn up after work, before beer, to hear you talk is a humbling experience.  Fortunately, I think the audience was perfect for the presentation - they had heard of the Disruptor but hadn't seen anything very detailed about it, so my walkthrough of how you might use it seemed to go down well.  I certainly got a lot of very sensible questions (which hopefully I've remembered to repeat for the benefit of the recording), and people had some good ideas about how and when to use it.

I ran the same presentation to a different audience at QCon London a week later, I'll post a link to that if/when it becomes available.

JAX London - I learn stuff and meet people

A couple of weeks ago, I was at JAX London along with a number of the London Java Community regulars (Martijn/Ben/John/Sandro/Simon/Zoe I'm looking at you....)

My purpose for attending was largely to present the Hardcore Concurrency for Beginners talk that Mike and I debuted at an LJC event a few weeks back. Almost as important was catching up with the aforementioned LJCers and meeting with as many people as would talk to me. After the disappointment of the sessions at Java One, sitting in a room being talked at was quite low down on my list of priorities. Sometimes it's nice to be wrong.

The sessions at JAX were of a very high standard, and I learnt something from every one. I was pleasantly surprised by the calibre of international speakers that were there, and the sessions seemed to be pitched right for me personally, which was nice.

Downsides:

• I'm going to cover these first because I like to end on a high note.  Firstly, although I was interested in the Open JDK session at the community night, it was really on way too late (and after too much beer - i.e. more than none) to get the most out of it.
• It's a bit of a shame that our session was the last presentation on the final day, by that time people's brains are fried and we didn't get as many questions, or as much interaction, as we usually would.  Maybe that's because everyone understood and agreed with us.  But we did get great feedback so I could be scraping the barrel for things to complain about.

The following sections outline the main takeaway points for me.

Software Craftsmanship / Design

Sandro did a great job emphasising that Software Craftsmanship is about professionalism, not beauty.  We should be doing the right thing because we want to, because it makes everyone's lives easier in the long run, and because it is the right thing to do, not because some process dictates that we do it.  The other thing that really struck me was how having a craftsman's mindset leads to us taking ownership of our career and investing in it.  He also challenged us to stop being miserable and negative.  If we're happy, we'll attract more (presumably happy) people into our circle.

Jason Gorman's Slow and Dirty presentation showed that ignoring quality slows down delivery not just in the long run, in terms of maintainability, but also in the short run - a TDD exercise of approximately 30 minutes took less time to get right when done in a test driven fashion, despite that fact that we all still think writing tests takes too much time. He pointed out that Twitter and Facebook are statistical aberrations - not every startup can afford to assume they will be bought out of their scalability problems. There was lots of interesting stuff here about quality, which was pretty inspiring at the time but in retrospect, as a team that already does Test Driven Development almost to the extreme, I wonder what's next for us to improve our quality even further.
Simon Ritter's keynote stated that code should be a joy to read, not simply easy to read, and Adam Bien's presentation talking about simplifying code: thinking about design, and not getting bogged down in unnecessary design patterns in order to implement something simple.

Concurrency / Parallelism / Performance
Russel Winder's session around message passing had me thinking. It was particularly interesting to see him say things that are possibly the opposite of what we (the LMAX/Disruptor types) are preaching. For example, that programmers shouldn't care about the low-level details; that we should be using models (i.e. abstraction) to deal with parallelism; that you should let the JVM deal with thread management. However, I think he's fundamentally coming from the same place as us: "concurrency" in the past was not a good model, it was designed for old hardware that was trying to run multiple processes on a single core. With multi-core systems you need to be running code in parallel instead.

Dan Hardiker's performance testing presentation was another one that reinforced that testing first, finding what the real performance is, profiling and then targeted experimentation are all fundamental to getting good performance. There was a lot of good advice to how to write good performance tests too.
Another point from Simon Ritter's keynote reiterated that the performance free lunch was over, and we need to get better at writing parallel code.

Workshops
Both the Open JDK session and Ben and Martijn's "Spring cleaning your code base with Java 7" had me attempting to do things with my mac I never intended to do (i.e. write code). Thanks to Ben and Martijn's patience, I finally got IntelliJ playing nicely on the mac with Java 7, which was a challenge but I'm pretty pleased I've achieved it. The Open JDK one was not as successful for me personally, but I got a good feel for the process of building it (i.e. it's hard and it takes a very long time).

Other great stuff:

• The keynote by James Governor from Redmonk was really thought-provoking.  So thought-provoking I wrote no notes and can't remember any of it.
• As last time, the Community night was really great.  I met new people and I hung out with some old favourites.  Dear God I must stop drinking with those guys. Hotel bars are particularly awful for losing track of time.
• I heard about the Java 7+ features enough times from various people to be able to give an overview of the release plan to my geek friends in the pub on Friday (hey, they asked).
• I learnt how to use twitter to bridge that gap between me and other attendees, and made new friends without having to do the scary thing of approaching strangers.
• The lunches we rather good.
• Going to a conference 20 minutes from home is a bonus.  Nice to meet other London devs as well as the European ones too.
• To me, it seems as if the relevance of the JCP is starting to seep out into the real(er) world.
• The tables for laptops at the front of the rooms was an awesome idea.  For a start, it encouraged people to get into the room early to get one of those seats.

I had a great time at the conference, I learnt stuff and met people, which is all I really want.

For once, the photos aren't mine. Images courtesy of JAX London.

First public appearance caught on video

Remember a while back I talked about my first public appearance?

Well, I chased down the video, because I'm masochistic, and here it is for you all to enjoy.  Pleasingly my mannerisms are slightly less of a camp man trapped in a woman's body, which was my impression the last time I saw myself presenting.  It helps that YouTube has made the video so dark you can't see me.

Slides are available for all to enjoy.

Special thanks to Playfish for hosting the event - as always, their hospitality was awesome.  The fact that they didn't serve wine is probably a Good Thing.

My first public appearance

I'm finally moving up from working behind the scenes to actually doing a (short) presentation for the LJC. I'm going to be giving a lightning talk on Wednesday at the AWS Elastic Beanstalk event, on the JCP - what it is and what our election to the executive committee means.  Ben and Martin's post gives a little more background on the subject.

Another LMAX LJC member Mike will also be giving a lightning talk, on Project Coin.

Now all I have to do is write it...