Ruby Conf Australia 2013 in Review - Lessons Learned
Ahh RubyConf. Ever since it was announced, I’ve been building up expectations, and there was always the chance that I’d been unrealistic, and would emerge disappointed.
I didn’t. It wasn’t.
Rather, it was exactly what NetEngine needs right now. It was nothing more or less than 3 days of conversations between peers, sharing advice, war-stories, and proving that there’s a passionate human-being behind all those tweets, and all those wonderful little open-source toys we enjoy so much.
It gave us sense of place in the greater Australian ruby community - a bit of reassurance that we’re not alone in the challenges we face, and in our endeavours to push the state of our art forward, in those tiny increments we’re always recommending to our clients.
Here’s a snippet of a conversation I had more than once..
me - “So I was checking out this awesome gem called ‘x’ the other day..” them - “Oh great, I’m glad someone’s finding that useful..” me - “You wrote that? Seriously? I love it. Thank you so much.” them - “You’re very welcome. Had any ideas for other stuff it should do?”
Where else do you find people like that? Incredible.
Between these conversations, I saw some great presentations. Here’s some highlights.
Refactoring from Good to Great by Ben Orenstein by @r00k.
I’ve been following Ben on his excellent thoughtbot podcast every week since they kicked it off in the middle of last year, and I, like just about every other rubyist uses thoughtbot tools everyday (factory-girl, paperclip, bourbon etc).
I saw this talk back on Confreaks after Aloha RubyConf, and I’ve been recommending it to people ever since. Some of the biggest lessons -
- Your code isn’t finished.
- The public interface is where your peers will spend most of their time reading
- You should make it as simple to understand as possible.
- They’re concerned with the intentions of your code.
- What it does, not implementation details.
- That it works, and how it behaves is a concern for your tests.
- A method doesn’t need to be longer than a single line
Other things to look out for..
- Nil, when you should have a null object.
- This can make a big difference to views, in particular.
- NullUser being the biggest absentee.
- Arguments that are always passed together. Should they be a value objects?
Realtime Rails and Ruby by @tobehede.
With the upcoming release of Rails 4 (in beta as I write this), I’ve been very keen to play with ActionController::Live.
You’ll recall it from the excellent post by Aaron Patterson. The basic concept is that you can now leave a connection open, and use server sent events to continue to push data to the browser - without setting up something like Faye for websockets.
class MyController < ActionController::Base
include ActionController::Live
def index
100.times {
response.stream.write "hello world\n"
}
response.stream.close
end
end
Tobe’s talk was great - full of examples of how this can be done today, what you’ll need to do in the browser to make this useful, and some other gems he’s explored lately to similar effect. His lightning talk was also great - well deserving of the prize he received.
bundle install Y U SO SLOW: Server Edition by @hone02.
What I really enjoyed about Terence’s talk was the insight it gave into the decision-making process at a place like Heroku.
The Setup: Managing an Army of Laptops with Puppet by @wfarr.
What could I add, that Rob hasn’t nailed? Fascinating.
Lessons from the Masters by @topfunky.
Geoffrey has certainly had an interesting couple of years. The behind-the-scenes stuff for Peepcode was great.
The take-aways?
- The “masters” make mistakes.
- They get confused.
- They jump into the docs, and into the source.
- They take a step back from the brick-walls, and think about the problem from a new perspective.
- They come back into the problem with a new plan.
- The new plan is often simpler, and cleaner.
- Keep practicing
Using Ruby for iOS development (RubyMotion) by @toamit.
It seems RubyMotion has come a long way in a short time.
We took a look at -
- A comparison with native Objective-C
- Testing
- Debugging
- Gems
- Cocoapods
The outcome? Our next iOS app will be a no-brainer.
Web scale for the rest of us by @johnbarton.
It’s great reading blog posts about how a team of 10 guys do incredible things with unlimited money, but John’s talk was exactly the opposite - something we can use.
Some of his practical advice
- That thing you’d like to play with (Riak)? You don’t need it.
- Concerning infrastructure, if you can’t afford 2, you can’t afford 1.
- Scaling is about avoiding the pain of the trickiest transitions.
- This is almost always about separating a server with too many roles.
- Or moving from one of something to many of something.
- The single responsibility principle, and other good programming practices can be applied here.
And how we’ll use it
- No co-location of app and database servers.
- Every app starts with a load balancer, 2 app servers and 2 database servers.
- Anything for which this is overkill isn’t worth building.
I understand that the bulk of the conference was filmed, and is due to be shared on Confreaks. I’m looking forward to checking out some of the other presentations, particularly @brifairley’s Immutable Ruby.
Until then, we should all rewatch Refactoring from Good to Great by Ben Orenstein by Ben Orenstein aka @r00k. I’ve seen it a couple of times now, and each time I pick up a little more; and think of a couple of other places it could improve what we’re all trying to build.
See you all at the next conference,
Update
The videos are now available here on Vimeo