What kept me away all those years probably was the fear that these kind of events just act as a sort of trade fair showing off some products or new technologies. Thankfully, that wasn't the case and the majority of talks weren't about what to work with but about how we work. It was truly inspiring (a word I'm sure will crop up again in this post) in that it reminded and reaffirmed me about the things I like about writing software.
I’m not sure I learned anything totally new – it was more an affirmation of things I’d thought / heard / read about – and a chance to see some of these things out in the wild. The speakers ran from big conference names to academics through some front-line experts, so a real range. I don’t think I attended a single sales pitch, and although a few named products slipped through the net, they were all OSS projects, not commercial products. All-in-all it seemed to stay true to the “for programmers by programmers” promise.
Throughout the conference there seemed to be a few common threads that popped up to me in every other talk. Some of it might be obvious but even then I found that it helps to step out of the day-to-day and get reminded about it...
- TDD - if you're not doing it, you're doing something wrong
- Expect change - accept that you will be wrong about some of your design decisions and prepare for it by making it easy to change your design
- Take small steps - I don't know how often I have to relearn that "rewrite everything" with some nice big upfront design is completely pointless
- Craftsmanship - treating software development as more than just a means to an end
- Relational DBs are not always the best tool for the job - even outside the NoSQL track this popped up in a lot of other talks
- State matters - whether it's the Actor model, RESTfulness, CQRS or whatever the work is in describing and figuring out state
For me personally the main point was
- "The jury is in on TDD" with which Bob started his bits on testing. I see the usefulness of TDD still being discussed at times and it's nice to realise that there seems to a common consensus that there really is no point to arguing about it any more.
The first talk I went to was by Ross Mason on when to use ESBs and when not to (slides). I took a few notes that should be of help for some of the integration issues we're likely to face in the coming months. Some funny slides on when not to use ESBs and I especially liked the term Resumé Driven Development, that Ross picked up from somewhere. He then gave a quick intro to Mule iBeans which looks pretty interesting.
What I took away from it:
- Don't use an ESB if you're only doing point-to-point communication and just need it to transform content
- I don't know enough about the ESB options out there
- I want to take a look at iBeans
The talk had an impenetrable title but thankfully I didn't let that scare me. Jason talked about how he tried to systematically help a group of developers learn good habbits (in this case TDD). The group agrees on a set of rules and while pair-programming checks each other on whether these rules were broken. This is done regularily over the course of about half a year at which point people test each other in a half-hour session. I'm not doing it justice and it should be pointed out that this is not at all limited to TDD as the subject.
What I took away from it:
- Practise makes perfect and having that put into a system that encourages pairing and verifying each others progress (without it turning too personal beacuse the goals are clearly defined) is a really good idea.
Emil gave a pretty good introduction to the various NoSQL options out there (at least I feel I have a better understanding now) and eventually turned to talking about Neo4j specifically.
(The Slides are pretty nice although Emil didn't get to a lot of it during the talk.)
As an aside, everyone was always quick to point out that NoSQL is an unlucky choice of a term and should rather be seen as "not only SQL".
And here's what I took from it
- Neo4j goes on the list of things to check out
- I immediately got curious about two specific problems at work and how they might be helped by a graph DB
I always liked the notion of seeing software development as a craft. Take pride in your work, try to learn from others and try to pass on your own knowledge to others and just have fun building cool things. So this talk really hit home for me. Bob Martin had already pointed to the Software Craftsmanship Manifesto and Corey also picked up parts from that.
- I'll have to put some more thought into that whole topic. It was a lot of food for thought.
- I like the focus on getting out and trying to see how other people work
The day ended with a presentation by Dan Ingall. Alex Blewitt also sums that up nicely. It was truly inspiring and humbling to see someone with so much skill and experience have so much obvious fun with programming.
We then went out for drinks and somehow ended up in a rag-tag group of Norwegians and Poles and only got home around 2am. It was a really fun time talking to people about what they were working on and how uniformly everybody seemed to really enjoy the conference.
Getting up for Day 2 was a bit of a struggle and so we ended up being just a tad late for Ralph Johnson's talk. I remember I liked it but I didn't take notes. It was about maintaining and refactoring old code, flossing, root canals and leaving a legacy.
Ian gave an update on the work he and Jim Webber are doing writing their book on REST in practice. I thought I was pretty up to date on the subject but I took a few new points from it.
- You need to either be open in your operations or your resources (around page 6 in the slides)
- how you break up your application state into resources is the main work with REST (slides 24 ff.)
- Need to look up the draft of the book
- Caching is hard (that might not be so new :))
Oren Ayende Eini Rahien
The man with the alias. I mostly went to this talk because his posts keep showing up as shares in greader. But he's a pretty funny, hands-on guy and, as can also be seen on his blog, he's got a good eye for writing readable code.
- People tend to always underestimate performance
- I shouldn't be so surprised by how much more efficient in-memory lookups are
- some people write their own graph DBs just for fun
This was definitely the highlight for me. I may go into the why of this more deeply at another time. Takeaway points where plenty and I really hope the video of this shows up on QCon sooner rather than later. This talk from last year goes into a somewhat similar direction but I'd say this year's talk was more polished.
- Optimise for Ease of Change
- We're wired to complicate things
- Just the other day I was talking to my brother about how we sometimes irritate people by stopping mid-sentence and going "oh, nevermind, I've got it now". Dan sees this way of talking to work out a thought as a useful tool and a nice side-effect of pair programming
- If you don't have someone to talk to, talk to a bath duck
- Avoid yak-shaving by timeboxing. Other talks also mentioned the Pomodoro Technique
- Avoid decisions until the latest point possible (might have also been from another talk from someone else but it fits here, too)
I was a bit tired and so listening to him being so incredibly calm was actually pretty hard. But I see that as entirely my fault. The talk was initially about what was going to change by 2015 (not much) and then used that as a starting point as what I'd call career advice (by way of his career as an example)
- make a conscious bet on some new technology that you think will be big and run with it
- most basic principles (like e.g. dependency injection) will probably not change
- Cloud Rest etc. bla bla
- just turning off the slides mid-talk was pretty cool
Instead I went to see Udi Dahan talk about CQRS. I had read some of the recent blog posts about this and was really intrigued and this talk solidified that. The ticket booking example in particular was really illustrative (alas, the slides are one of only a few that are passworded).
- "Capturing user intent" is a really good description of how to approach this and it is indeed strange that this seems to happen so relatively little
- Be upfront about stale data and users won't (terribly) mind
- Maybe I can use this as a starting point to clear up some of the terrible anemia going through our model at work
Despite being pretty beat we managed to show up at the NNUG user group meeting. But since we got there pretty late we didn't really get to socialize. A bit of a shame since there seemed to have been some interesting people and conversations. How great is it to be in some average english pub and overhear people talking about 4GLs? Pretty bizarre.
And on we went to the last day. I started out with Stefan Norberg's talk on Domain-Events. He started out with explaining the concept and then giving a few examples of how they used this at Unibet.
- I really need to get started digging deeper in the available technologies. My cursory experience with JMS just doesn't cut it
- Events are a really nice way to handle cross-cutting concerns and to flexibly grow an infrastructure
- Events are a good way to improve sustained throughput when bursts of traffic would otherwise limit you to the speed of your slowest component
- They use Google's Protocol Buffers for serialization of their events. Probably worth it to finally read up on that
- look up CEP
On to a talk about testing asynchronous testing. Based on a few real-life examples, Nat described ways to test more complex architectures.
- Incorporate integration tests in your TDD cycles. I.e. have a larger integration test cycle around the smaller test cycles for the individual parts
- when checking asynchronous systems, instead of asserting correctness poll for success and time out to fail; succeed-fast instead of fail-fast
Rod talked about Spring Roo and then coded away with it and they've come a pretty long way. Not much to say that others haven't already said.
- There really is no reason not to use Roo to set up new projects
- Aspects to get rid of getter/setter boilerplate has me swooning
Some people, when they want to learn a new language, go and implement it in the JVM. He was trying out a new approach to slides and maybe that made him a bit uneasy in the beginning. That was unnecessary though, as I greatly enjoyed the talk and prefer if it's not just a reading off of the slides.
- Kresten sees the Actor model as an equally important shift in thinking as that brought on by OOP
- it's important to make a distinction between functional/computational concurrency and interactive concurrency
- processes are cheap
- I have some real learning to do
Dylan is a funny guy and was good-natured about some dojo v. jquery ribbing early on. He was also someone that sweared repeatedly, which I dearly appreciated.
- Dojo had just had a security vulnerability for the first time in years (so I had some updating to do on monday)
- fucking IE6,7 need to die a bloody death
- every other browser seems to auto-update and do so frequently (overtaking, e.g. flash or other plugin update cycles)
- I was the only one in the crowd still using Firefox 3 (at least I thought I was. Turns out I had actually upgraded to 3.5 at some point. QED, I guess)
- a lot of interesting points on browsers, flash, open source and healthy ecosystems
It was a minor culture shock coming back into work on monday and it took quite a while to let all this settle but I do feel invigorated.
So, thanks a lot to the organizers and the speakers and the other nice people I got to talk to.