Icelab Singapore and RedDotRubyConf 2012

In May, Hugh and I took off to Singapore for a week of work capped off by the second RedDotRubyConf.

I recommend that you take a break from your usual work patterns and environment and do your job somewhere else. It needn't be somewhere exotic, but if you can manage it, all the better! For me, the week in Singapore was especially rewarding because it was a great chance to compare notes with Hugh about what we've been building lately and some of the techniques we're employing (not to mention a great chance to sample some coffee too).

RedDotRubyConf took place over the Friday and Saturday, and it was a great event. For me, a lot of the value in attending a conference is how I feel when it ends, and how that translates into actions that change my life and work. After a conference like Webstock, which I attended earlier this year, I was compelled to think about the longevity of my work and how I wanted to help shape Icelab. After Red Dot, I was motivated simply to become a better Ruby developer. For something I do everyday, this is a useful thing.

This was the first single-track conference I've attended, and I liked the structure a lot: no difficult choices and a single shared experience for everyone.

Some of the standout talks for me were, from Day 1:

  • Ilya Grigorik's Building a faster web: This was jam-packed with useful suggestions, and building for speed is something we should always keep in mind. Incidentally, I'd seen his slides online earlier, but picked up so much more seeing him speak. A good reason to come to conferences.
  • Danish Khan's The Ruby Community: A nice reminder about being good project maintainers and open-source citizens.
  • Sau Sheong Chang's Ruby, Rock & Roll: I love just-for-the-sake-of-it out there tech talks like this. We were treated to a walkthrough of the process of building a Ruby music synthesizer and DSL.
  • Wei Lu's A Journey into Pair Programming: An intro to pairing from one of the {new context} engineers. I'm still not convinced that pair programming is necessarily the best option for small studios with many concurrent projects, but it's still important to critically consider your working methods.

And on Day 2:

  • Obie Fernandez's Redis on Ruby: I've used Redis before, but not as extensively as Obie. A great eye-opener, showing a huge number of potential uses for the database. I predict more of this in my future.
  • Carl Coryell-Martin's Computer Scientist, Developer, or Engineer?: A reminder that we should measure our work against real human needs.
  • Darcy Laycock's API Driven Development: Nearly everything I build these days has an API, and there's a lot of new tools about to help make them easier to build.
  • Koz's Lessons From the Other Side: Effectively Contributing to Open Source: An interesting and funny insight into Koz's life as a Rails maintainer, along with some advice about contributing effectively. In particular: your contributions to Rails (or OSS in general) should be a by-product of your work.

There's also a complete list of talks and slides available.

For just a couple of days, there's a lot of good learning and inspiration. Andy Croll has put together a remarkable event and deserves many thanks. I'm looking forward to heading back next year.