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.

Spock: Data Driven Testing

In the last two articles on Spock I've covered mocking and stubbing. And I was pretty sold on Spock just based on that. But for a database driver, there's a killer feature:  Data Driven Testing.

All developers have a tendency to think of and test the happy path. Not least of all because that's usually the path in the User Story - "As a customer I want to withdraw money and have the correct amount in my hand". We tend not to ask "what happens if they ask to withdraw money when the cash machine has no cash?" or "what happens when their account balance is zero?".

With any luck you'll have a test suite covering your happy paths, and probably at least twice as many grumpy paths. If you're like me, and you like one test to test one thing (and who doesn't?), sometimes your test classes can get quite long as you test various edge cases. Or, much worse (and I've done this too) you use a calculation remarkably like the one you're testing to generate test data. You run your test in a loop with the calculation and lo! The test passes. Woohoo?

Not that long ago I went through a process of re-writing a lot of unit tests that I had written a year or two before - we were about to do a big refactor of the code that generated some important numbers, and we wanted our tests to tell us we hadn't broken anything with the refactor. The only problem was, the tests used a calculation rather similar to the production calculation, and borrowed some constants to create the expected number.  I ended up running the tests to find the numbers the test was generating as expected values, and hardcoding those values into the test. It felt dirty, but it was necessary - I wanted to make sure the refactoring didn't change the expected numbers as well as the ones generated by the real code.  This is not a process I want to go through ever again.

When you're testing these sorts of things, you try and think of a few representative cases, code them into your tests, and hope that you've covered the main areas. What would be far nicer is if you could shove a whole load of different data into your system-under-test and make sure the results look sane.

An example from the Java driver is that we had tests that were checking the parsing of the URI - you can initialise your MongoDB settings simply using a String containing the URI.

The old tests looked like:
(See MongoClientURITest)

Using Spock's data driven testing, we changed this to:

(See MongoClientURISpecification)

Instead of having a separate test for every type of URL that needs parsing, you have a single test and each line in the where: section is a new combination of input URL and expected outputs. Each one of those lines used to be a test. In fact, some of them probably weren't tests as the ugliness and overhead of adding another copy-paste test seemed like overkill. But here, in Spock, it's just a case of adding one more line with a new input and set of outputs.

The major benefit here, to me, is that it's dead easy to add another test for a "what if?" that occurs to the developer. You don't have to have yet another test method that someone else is going to wonder "what the hell are we testing this for?". You just add another line which documents another set of expected outputs given the new input.

It's easy, it's neat, it's succinct.

One of the major benefits of this to our team is that we don't argue any more about whether a single test is testing too much. In the past, we had tests like:
And I can see why we have all those assertions in the same test, because technically these are all the same concept - make sure that each type of WriteConcern creates the correct command document. I believe these should be one test per line - because each line in the test is testing a different input and output, and I would want to document that in the test name ("fsync write concern should have fsync flag in getLastError command", "journalled write concern should set j flag to true in getLastError command" etc). Also don't forget that in JUnit, if the first assert fails, the rest of the test is not run. Therefore you have no idea if this is a failure that affects all write concerns, or just the first one. You lose the coverage provided by the later asserts.

But the argument against my viewpoint is then we'd have seven different one-line tests. What a waste of space.

You could argue for days about the best way to do it, or that this test is a sign of some other smell that needs addressing. But if you're in a real world project and your aim is to both improve your test coverage and improve the tests themselves, these arguments are getting in the way of progress. The nice thing about Spock is that you can take these tests that test too much, and turn them into something a bit prettier:
You might be thinking, what's the advantage over the JUnit way? Isn't that the same thing but Groovier? But there's one important difference - all the lines under where: get run, regardless of whether the test before it passes or fails. This basically is seven different tests, but takes up the same space as one.

That's great, but if just one of these lines fails, how do you know which one it was if all seven tests are masquerading as one? That's where the awesome @Unroll annotation comes in. This reports the passing or failing of each line as if it were a separate test. By default, when you run an unrolled test it will get reported as something like:

But in the test above we put some magic keywords into the test name: '#wc should return getlasterror document #commandDocument' - note that these values with # in front are the same headings from the where: section. They'll get replaced by the value being run in the current test:

Yeah, it can be a bit of a mouthful if the toString is hefty, but it does give you an idea of what was being tested, and it's prettier if the inputs have nice succinct string values:

This, combined with Spock's awesome power assert makes it dead simple to see what went wrong when one of these tests fails.  Let's take the example of (somehow) the incorrect host being returned for one of the input URIs:

Data driven testing might lead one to over-test the simple things, but the cost of adding another "what if?" is so low - just another line - and the additional safety you get from trying a different input is rather nice.  We've been using them for parsers and simple generators, where you want to throw in a bunch of inputs to a single method and see what you get out.

I'm totally sold on this feature, particularly for our type of application (the Java driver does a lot of taking stuff in one shape and turning it into something else).  Just in case you want a final example, here's a final one.

The old way:
...and in Spock:

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

JAX London & MongoDB Tutorial

In previous years, JAX London would have been an easy, local conference to go to.  This time it took me most of Sunday to get there, and not because of the Super Storm.  Still, that gave me the day to finish off the tutorial I was running there on Monday morning.  Not that I would be so unprofessional as to leave preparing things until the last minute, oh no....

But as in previous years, the main benefit of this conference for me was meeting most of the usual suspects from the London Java Community.  For example, presenting were: Andy Piper; Barry Cranford; Jim Gough; Peter Lawrey; Sandro Mancuso; Simon Maple; Martijn Verburg; John Oliver: John Stevenson; Richard Warburton. The Community Night in particular also drew a lot of LJC members (including some first-timers) to JAX, and it was a really good "networking opportunity" (i.e. chance to have free drinks, catch up with friends and make new ones).  I really enjoyed hanging out with everyone at JAX this year, I was tempted to write the names of everyone I spoke to and had fun with because it really made my conference, but I think that would make a very boring blog post.  But if I spoke to you at JAX, you made my journey from Spain worthwhile, thank you.

As well as the LJC-types, there were some other really big name speakers too, including MongoDB's Chairman Dwight Merriman.  Highlights for me were:

• Ken Sipe's Spock talk.  I saw this at GeeCON and that's why I started using Spock to test the MongoDB Java driver, but it was great to see it again and pick up some extra tips
• Ted Neward's talk at the community night about being a CTO at a startup.  It was really interesting, and nice to see a realistic view of the difficulties of that role.  
• James Governor's keynote on how Java got its Mojo back.  I like seeing facts and figures to back up a viewpoint, and as you'd expect from the founder of an analyst firm, this talk was full of them.

As James mentioned during his talk, the audience at JAX was, as in previous years, somewhat passive.  I'm not really sure why, as around 50% of the audience came from outside the UK so we can't even blame English reticence.  And in a conference full of outspoken LJC-types, it seems an odd thing to have an unresponsive audience.  Maybe it's the venue, the main hall in particular seems to lend itself to sitting quietly in the audience and expecting to be entertained.

I presented four times at JAX, because, well, on home turf one ends up doing more than one expects. 

• Firstly, a tutorial on the new Java driver for MongoDB (more on this later); 
• Secondly, a clinic for novice speakers.  This was a lot of fun, and I think it was useful for everyone.  I'd love to run this again (I probably will at the LJC Open Conference).  The aim is to give new speakers confidence, not focus on details like building a slide deck.
• Thirdly, the third time out for my "Design is a Process, not a Document" presentation.  It's a relatively interactive presentation, which I don't think worked so well at JAX, but it's a fun presentation to give.
• Finally, not only did I get roped into being on the panel for "How to start a community" at the community night, I ended up, somehow, moderating it.  That was fun, it was the first time I've been a moderator, it's a role I usually avoid as moderators ought to limit the amount of talking they do, which doesn't sound fun to me.

The tutorial materials are available on GitHub.  I haven't provided a lot of guidance on how to get started online, but the exercises are there, and the slides which present the concepts and suggest the order to tackle the tests in.  If people use these materials, please feel free to give me feedback on them, but be nice - they were designed for an in-person tutorial, not an online one.  But it is a good way to get a feel for the new MongoDB Java API (in its current, unfinished, state).

So, JAX London - great speakers, and a good conference to meet not only Londoners, but a lot of international people too.

LinkedIn Etiquette

For no reason other than LinkedIn communications are starting to irritate me, here's my personal LinkedIn Etiquette guide.  Feel free to disagree with it all.

1. I'm not going to accept invitations from recruiters.  Not just because I'm not looking for a job (who knows what the future holds?), but because I believe it shows a lack of respect to my network to bring recruiters one step closer to being able to contact them all.  It's not about Evil or Good recruiters, but I really don't want to make it easier for lazy recruiters to spam people I respect (caveat: there are people who are technically recruiters who I have added into my network, either because I know them personally or because they have proved their worth).
2. If I get an invite without an introduction message from someone who's name I don't immediately recognise, I'm going to check out that profile to see if we have employers in common or common connections, but usually I won't accept that invitation.  I know LinkedIn makes it easy to click one button and request a connection, but I think my LinkedIn network is valuable and made up of people I know (even if I only met you once at a conference), and a short introduction reminding me of where I know you from (or why you'd like to connect) is going to help my poor, beleaguered memory.
3. Endorsements - almost a total waste of time.  People I have worked with and respect have accidentally endorsed me for things they know I've never worked on, simply because LinkedIn makes it too easy to click a button and endorse someone for two things they've already been endorsed for and a third thing which, through some LinkedIn magic algorithm, is probably related to what you've done before and LinkedIn hopes is only accidentally missing from your profile.  If recommendations were too easy to game (and they were), endorsements are almost entirely valueless.

However, I do find LinkedIn enormously useful.  I value it more than I think many others do for a few reasons:

1. It encourages you to keep your CV/resume reasonably up to date.  I personally believe everyone should do this, not because you might want to hop jobs at a moment's notice (although it's nice to be able to do that), but because a) it's really difficult to remember what you did over the last 12 months, never mind a longer period - keeping your profile up to date means you can truly highlight the good stuff you've worked on, and b) if you've got nothing to add to your resume from the last 12 months, that's a good sign that you're not growing and your career needs a bit of love (if you think investing in your career is a Good Thing).
2. It's enormously useful for retaining a network of valuable contacts.  This is why, in my opinion, one needs to be reasonably selective about who one adds to that network.  If you were looking for a new job, for example, and you'd been selective about the recruiters you'd added to your network, those would be the first ones you'd contact, and you'd be reasonably certain of a quality service.  But regardless of that, because not everyone is constantly job-seeking, if you're looking for a specific person (for example, someone comes to interview for your company; or you're looking for a great speaker for your conference/event; or someone approaches you about a job or an event to go to; or someone randomly e-mails you out of the blue and you're not sure who they are) and they're either in your network or are connected to someone in your network, you know that you either know them or someone you know knows them.  That makes them a Real Human and not a spam-bot or someone who wants something from you without giving value in return.
3. It's not Facebook. Related to point 2, I am happy to add people I know only professionally (i.e. are not yet friends) to LinkedIn.  I'm even happy to add people I don't know personally if they don't fall under rules 1 and 2 in the "I won't add you if..." section.  In Facebook, I have two (main) rules: I have to have met you in person (there are one or two exceptions but those are people I have known for a long time only over the interwebs); I have to have spoken to you in the last year, or want to speak to you in the next 12 months.  This is for two reasons: 1) I want to keep my Facebook network relatively small so it's more intimate, and therefore 2) I can share more personal things on there without feeling self conscious or wondering who's going to see it.  I have to be able to speak honestly on Facebook.  On LinkedIn, I don't need to be so fussy - I can add you to my network if I like you but you haven't (yet) crossed into friendship; I can add you if I think I can be useful to you, or you to me; I can add you if I want a way to contact you (or want you to be able to contact me) but don't have a pressing need to stay in touch frequently.

So, that's an unnecessarily deep dive into my attitude towards LinkedIn.  It's probably not going to change anyone's behaviour, but I feel better for at least explaining why I won't necessarily add you back - all you need to do is type in the little invitation box to explain why we should be connected.  

I value my connections, and I want to see that you do too.

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:

Make the Future Java

I think this is a nice example of how to showcase technology and make it relevant and exciting for people.  Something with this approach could do more for increasing the number of people interested in programming as a career than any of the traditional approaches of getting kids and "minorities" interested in IT.

Kids These Days

I'm a great believer in getting kids to code early - after all, I'm of that generation that was taught 

at the age of 9.  There are quite a few approaches to teaching today's kids in an engaging way, but I'm a bit wary of the sandbox solutions that teach kids things like how to navigate a virtual thingie around the screen, or lets them create things in a limited virtual world.  I don't think kids will easily make the leap between these sort of games to seeing the full potential of programming - they're too limited and have no context for the kids.  It's just another game.

Kids need to understand how programming fits into their world, they need to understand the context of coding, if they're going to fall in love with it.

I like Jason Gorman's comparison of programming to music.  Most people learn an instrument because they want to make the sort of music they hear on the radio.  But you give them a recorder and teach them to play "snug as a bug in a rug" and they go off the idea entirely.

"So, is this a sexy tune, Mrs. Badcrumble? I just don’t think, Mrs. Badcrumble, that this is really gonna be a sexy tune.".

 - Eddie Izzard - Definite Article

Similarly, you give kids a sandbox environment specifically to learn programming for the sake of programming, and they're not going to see how this turns into Facebook or Google or the apps on their phones.  They're going to continue seeing computer programs as something that magicians in a land far, far away made just for them.  The same way breakfast cereal is grown in box only for them.  They don't see programming as something they can do, they don't see the computer as something they can influence.

Just the slightest hint, the slightest push, to show them that they can be the magician, that they can have power over this world. That's the way in.

Many of my generation of programmers learnt by coding those godawful choose-your-own adventure games.  They weren't pretty or elegant, but in a single lesson we learnt that a short magic incantation could create something that looked like those games we played.  With a bit of persistence we could truly create our own adventure, with a story that we created, not just follow someone else's paths.  And then we could inflict that on our little sisters.  It was such a short distance from the BBC command line to a game that many of us saw what programming could create, and that programming was something we could do.

There's an argument these days that computers got so complicated, so elegant, so perfected, that "kids these days" don't have that.

This is not true.

It's just not.  Don't be fooled by this.  Sure, PCs in the 1990s made it more tricky to simply program the thing.  And IDEs felt, to those of us who learnt from a blinking prompt, like cheating somehow.  Or, at the very least, they divorced us from the internals of the machine, provided us with too much separation (what nonsense, by the way - an IDE must be much closer to the command line than  BASIC is from ones and zeros).

But those days are waaay behind us.  Several more levels of indirection later, and actually it's much easier to write something that gives the immediate feedback, something that has real context, that will help kids get it.  This will help kids see why.  They're the same as us, they can't just be expected to do it because, they want to know what's the point.

And these days it's easier. You've got:

•  Raspberry Pi
• Arduino
• Lego mindstorms
• Facebook games
• Minecraft plugins
• Android apps

To name but a few.  That's not even including the fact that you can get coding web pages and python code pretty quickly and see instant feedback, or even use an IDE to create a UI in something like C#.

The first three items in the list are great for people who are very touchy-feely, who want to see something in the real world.  Can you imagine how exciting it would be for your kid to see that they wrote a program that closes the curtains?  It's a tiny, stupid thing, but you just gave them control of the physical world they live in.  Let their imagination do the rest.

The other ideas are probably more directly related to the stuff they use the computer for.  You're really providing them with a way to customise the tools they already use.  Who doesn't want to imprint a bit of themselves on the virtual world?  These sorts of thing let them control a world they understand - in the context of a tool they know (e.g. Facebook), they create a game or a plugin or whatever that works within that world.  And they start to see that this tool they use to talk to their friends, this tool that is there to fill their spare time, is something they can control.  Maybe they'll start small, but they'll soon learn that everything they use, everything they touch on the computer, is really only code that some other human has built.  They'll start to see that the computer-machine is influenceable, that they can tell it to do stuff and it will do it.

That is addictive.

That's what we want.  We want to open their minds to how their world is constructed, and show them that they can influence it. They can control it.  

They can change the world.

JavaZone, Oslo

For the rest of 2013, this blog will mostly be masquerading as a travel blog.

This week I've been in Oslo, and I liked it.  Actually, you'll be hard-pushed to find somewhere I've visited that I didn't like in one way or another, but Oslo does make my "definitely going back there" list.  If Seville, where I've been for the last month, is stuffed full of History, Oslo is overflowing with Geography.  I've noticed a pattern in that my favourite places were sunny when I visited them first, which subconsciously prompts me to love them (as a vitamin-D-deprived Englishwoman).  Oslo was NOT one of those places, it was overcast and extremely chilly compared to the south of Spain.  But the countryside around it is really pretty, and it's very green and mountainy and watery.  Not like Spain, or the UK for that matter.

I found the Norwegians really friendly, and as with all the Nordic countries their English is better than you'll find in an international and technically English-speaking city like New York or London (I'm not criticising New York or London, I love their diversity and international-ness, and the fact that London has more active spoken languages than any other city in the world, it's just the excellent standard of English in somewhere like Oslo is very noticeable).

Anyway, on to the point, the JavaZone conference.

Over the last two years I've been to a lot of conferences, and over the next month or two I'm probably going to double that number.  So I didn't give JavaZone the attention it truly deserved.  I was, rather boringly, preparing my talk and doing actual work while I was out in Oslo (and less boringly meeting up with old friends) rather than attending the conference.

However that's actually a shame, as from what I saw of the conference it was a really nice one.  Small enough to run into people you've met before or get talking to strangers, big enough to attract some great speakers and exhibitors.

Oslo Cathedral

The thing that struck me the most though is that it had by far the best exhibition space I've seen at a conference.  I'm not sure if it's a result of it being right in the centre of all the rooms, due to the layout of the venue, or if it was simply extremely well designed.  What I liked about it was that the stands for the exhibitors were located around the hall and interspersed with different types of seating for attendees to hang out in - cafeteria-style tables; lounge areas; bar-style high tables and stools; bean-bags; space for people to stand and chat.  This mix of exhibitor stands and social space made it feel a bit like a party.  And while the benefits to the exhibitors are obvious (they can chat really easily to the attendees and hand out freebies), as an attendee it seemed a more relaxed approach and less sales-y than being pounced on by the poor lonely people manning the booths in the sort of exhibitor's hall where you run through it to get to the food.

Speaking of food, JavaZone had the best approach to food I have seen at a conference.  There were loads of hot and cold food tables around the hall, with different types of food, served all day.  I spotted Italian, French, Sushi, American, cake, and the ever-lasting burger bar (a dangerous thing indeed).  This neatly avoids a lot of issues with "dietary requirements" (vegetarian, gluten free, low-carb etc) and gives us the impression of choice rather than having food foisted on us (see: JavaOne.  Sorry Oracle but your food situation seriously sucks).  Serving it all day avoids massive queues that steal away all your break time, and puts less pressure on you to eat when you have to.  I have no idea how much this set up cost, and I'm pretty sure it wouldn't work at most venues as they have their own catering arrangements, but it was something that seriously differentiates this conference and venue.

But my favourite thing about it was the quality of the coffee.  Yep, you heard me correctly.  It wasn't the great speakers (I didn't get to see many talks but Tim Berglund's talk was excellent, and Ken Sipe has had a bigger impact on the MongoDB Java Driver than he will ever know).  It was the coffee.  They had all sorts of different coffee stands dotted around the place.  Some sponsored by companies, I guess, and I think the Nespresso-style capsule coffees (that were sadly abandoned because the other stands with baristas were so popular) might have been the default conference coffee.  But being able to grab a really good quality cappuccino without having to leave the venue was a very welcome change from the usual conferences, and it keeps you in the exhibition area with everyone else.

Tim Berglund speaking in the... challenging... room 1

Just because if I don't mention it by now it's a bit unfair on JavaZone - they had a good proportion of women attendees.  Wherever you looked you could see at least one, which is (sadly) a lot better than many conferences.  I'd estimate it at around 10-15%, which is not bad at all.  I wonder if they did anything special, or if that reflects the normal proportions of women techies in Oslo?

OK so I'm clearly extremely superficial in my appreciation of conferences.  Maybe this is the result of having attended quite a few now.  But if you go to any Java conference (in particular, but maybe other types of tech conferences too) they're really focussed on getting great speakers with good presentations (as they should be).  So it's the details that will set your conference apart from another.

Of course, location plays a part of it.  If you're based in Oslo/Norway and a JVM person, JavaZone should clearly be your first choice.  But if you're in Europe and are going to have to fly somewhere to get to a conference anyway, you have quite a lot of choice now, and you might be tempted by this conference.

I wonder if one day I'll be able to do a "definitive guide to this year's conferences" in advance and be able to suggest the ones you should go to based on different sets of criteria?

I'd be remiss if I didn't mention my actual talk at JavaZone, since that was the point of me being there.  I unveiled a new talk, although the sharp-eyed amongst you will probably notice that I've re-purposed/re-written the "What do you mean, Backwards Compatibility?" talk from this year into a more general why-developers-should-care-about-software-design talk.  It turns out this was the perfect conference to do this presentation, as there were quite a few process-ish presentations suggesting that developers should do more than simply learn about technology.  These are challenging talks to give at technical conferences - there isn't always a "process" track, and if there is it's often not for developers.  It is assumed that developers want answers, and tools, and technologies, and often this is true (normal caveats apply around making gross generalisations, but for some developers and some conferences audiences this is true).  It was great to be able to give this talk to a good-sized audience of smart techies who, I think, got what I was trying to say.  I don't really know if I'm preaching to the choir or not though, or what people are really taking home with them.

Design is a Process, not a Document from JavaZone on Vimeo.

You can let me know in the comments (or via twitter or e-mail) what you think of the talk - what did you like? Am I just telling you what you know, or did you learn something specific? Or did it re-enforce your own beliefs?  

How to get started with the new MongoDB Java Driver

The second in my short series of blogs about the new Java driver is now available for your perusal.  In it, there's some guidance on how to get started using the new driver, whether you want to use the new (unfinished) API, the existing "classic" API, or a blend of both.

The post also shows that Gradle is prettier than Maven.  Sorry Maven.

If you are going to play with the new driver, please read all the caveats carefully.  I know it looks a bit like the warnings on your prescription medicine, but it serves the same purpose.  Short version: the driver is not finished yet, and should not be used in production.

We really want to hear your experiences with the driver - it is an open source project and MongoDB is very much driven by the community, we want to hear from you.  But only if you say nice things.  No, seriously, please tell us if you have problems, if functionality is missing, if your tests fail if you start to use it, etc etc etc.

Go play.

Interviewed by Stephen Chin about JavaOne 2013

Yesterday Stephen Chin, one of Oracle's Java Evangelists and the JavaOne content chair, interviewed me via a live stream about JavaOne, the new MongoDB Java driver, and my plans to Change The World.

It was a fun interview to do, and I really like the format of being interviewed over Skype and streaming my desktop.  There's a slight (OK, 25 seconds, not really low latency) lag between the screen and the speaking which means it's not a great platform for doing live demos, but I think I'd like to do more code demos in this way, if I can find a suitable platform.

Life on both sides of the interview table

InfoQ has posted the video of Dan North and I opining on the subject of hiring.  Most of the talk is spent on how to be a good interviewer, and touches on how to market your company to prospective hires.  We spend less time on how to do well as an interviewee, but in theory if you know what's going through the interviewer's mind, you should be in a much better position to take control of the interview and shine.

Hire Education - Making Interviews Rock

It's kind of funny because we talk a lot about hiring at ThoughtWorks (where we both worked, and which has one of the toughest interview processes in the industry) and LMAX, which learnt a lot off ThoughtWorks and shaped its own process for a smaller company that has different goals.  Yet neither of us work at those places now.  Still, we share stories from many of the places we've worked (or chose not to work), and if there's one take-home point, it's that hiring (and being hired) is not a simple thing to do well.

Autumn World Tour

It's nearly the end of August already (how is summer allowed to go by so fast?) so it's time to start thinking about the autumn conference scene.  It feels like I'm going to be at most of them this year, so hopefully I'll see you at one of them?

11-12th Sept - JavaZone, Oslo - Design is a Process, not a Document
16-20th Sept - New York - meeting and working with the MongoDB JVM and .NET teams in our shiny new office.

22-26th Sept - JavaOne, San Francisco - Design is a Process, not a Document (I'm in CA 20th - 27th)
30th Sept - 2nd Oct - GOTO Aarhus - Career advice for Programmers; Power Use of Tools.
17-18th Oct - GOTO Berlin - What do you mean, Backwards Compatibility?
28-30th Oct - JAX London - A workshop on the new Java Driver; Design is a Process, not a Document.  I should be in London all week.
December - YOW Melbourne, Brisbane, Sydney - What do you mean, Backwards Compatibility?