Nordic Ruby 2011
Here are some rambling notes on the themes and connections – intended and mostly otherwise – I saw in the material presented and discussed in the halls at Nordic Ruby.
In Tom Preston-Werner's opening session, he talked about TomDoc, his alternative to YARD and RDoc, which he created to have a documentation language whose audience is human code-readers, instead of machine code-generators.
Anthony Eden's talk about API design continued the theme, suggesting that we pay more and better attention to the audience for whom we write our public interfaces. I particularly loved his suggestion of writing APIs on multiple levels – one for "I just need it to work"-types, another for "I want more details"-types.
Jakkob Mattsson asked us to consider the things we can't do easily in Ruby – it's not really supported to metaprogram operators, or change the way expressions are evaluated to suit our own needs. Elise Huard illustrated the Actor Pattern, and asked if we might like to see better support, as in primitives, in Ruby for concurrency.
This being an rather international crowd, there were also some interesting sidelines about the Swedish language, and the challenges inherent in translating code, concepts and web sites from one language to another.
Data & Metrics
It seems rubyists love data. Keavy's talk featured some fascinating ideas about driving athletics performance through personal metrics, and both Randall Thomas and Joseph Wilk talked about collecting and scrutinizing data. I especially like Joe's ideas about analyzing code performance metrics, and using that analysis to focus and prioritize our test systems.
I found the hallway discussions heavily featured data. From Forward's Developer Anarchy concept, to how we're using things like StatsD to help us better track important data at Shopify, there were all sorts of interesting discussions about the use and acquisition of data.
Both Chad Fowler's incredibly inspiring penultimate session and Aaron Patterson's painfully funny presentation featured nearly identical slides showing – full screen – the cover for Michael Feathers' Working Effectively with Legacy Code. But where Aaron talked about strategies for mitigating the difficulties – code that is often untested and poorly understood can be challenging to refactor – Chad asked us to ponder the up-side of legacy, and made me wonder whether code I write will still be useful in one, let alone 5 or 25 years.
Both Keavy McMinn's and my own presentation asked the audience to "step outside their comfort zone". I asked the crowd to defy stereotypes, and deliberately cultivate variety and "weirdness" in their daily lives. Keavy challenged us to push ourselves toward our goals with heart, to deeply engage with our fears and limits, and build a process by which we may overcome them.