RailsConf 2008 – Sunday Morning Summary

Dispelling the Myths about Rails performance

Lewis Cerne – NewRelic

This was another vendor talk that I decided to attend. I’ve been betatesting the New Relic RPM system for awhile. I decided to attend to see if they would talk about upcoming features that may change my opinion on what NewRelic has to offer. Lewis started by comparing a lot of the FUD about Ruby & Rails performance/scaling to the same statements made about Java and other technologies 10 years ago. He noted the key truth that Rails developers are always using to back up their product: “It’s okay that Ruby is slower. We make up our gains in other areas”. He also highlighted some key observations that I’ve heard myself say many times before: You need data to know what optimize. Otherwise you’re wasting time and money and often just making things worse.

Lewis moved on to describe the the systems that power RPM. Nothing surprising, but it looks to be a solid and scalable architecture (as it should be since their goal is to help you scale your app). Of course, none of this is a surprise given that their cluster is run by EngineYard. He highlighted a great point about putting Rails apps into production: “Testing is important but not enough – You can’t predict or reproduce what will happen in production”. This is an important lesson to remember because good testing/test coverage has nothing to do with how your app will handle load. Bugs and load are very different issues and you must handle them in different ways.

I really started to get interested when Lewis mentioned that you can build your own custom data handling for targetting performance that is very specific to your app. This starts to sound a lot like plugins for ScoutApp, munin, etc. It’s not clear just what kind of custom data you can collect (are you able to run any Unix command for data collection, or are you limited to something inside Rails?), but it certainly sounds like a step forward.

Lewis concluded by noting that they really eat their own dog food and use nothing but Rails for both their collectors and their ui. The collector portion was especially surprising given how easily this type of data collection function lends itself to using a much more specialized setup instead of Rails. So good for them.

Ward Cunningham, of the original WikiWiki and now AboutUs.org came up to talk about his experience in switching from PHP to Rails and using NewRelic to monitor their performance. He relayed a great story about doing a 10 minute live switch from PHP to Rails and then using the data collected by RPM to find out what the problems were with their deployment. After fixing those problems, they were able to run the site effectively and easily. Although I believe AboutUs could have done the same thing with FiveRuns or ScoutApp, the key is that this style of performance monitoring is critical to deploying any Rails app.

Overall, a good presentation and I’ll still be watching NewRelic closely because performance monitoring continues to be a critical part of developing Rails apps.

Oh the Fail I’ve known

Adam Keys

Adam produced absolutely one of the best talks of the conference. He presented a lot of ideas about how best to use fail, accept that it is the best way to learn, and protect yourself when you do fail. He started by mentioning some different types of failure:

• Learning failure – The knowledge was out there already and you didn’t know about it.
• Technological Failure – Not having a tool that can do what you need to do, or not choosing the correct tool.
• Solve the right problem – Yak shaving. Adam specifically mentioned extracting pieces out as a framework when there is no need to: 3 strikes before you refactor.
• Inappropriately applying the wrong technology – There’s a better tool out there and you’re not using it.

Adam then keyed in on the core of his talk: Learning. He said there are only kinds of learning: Learning from others & Learning by doing. You only learn by falling down. Nobody gets everything right the first time. Set yourself up to rapidly trying things until you find what’s right. Just like you don’t play hockey without padding: don’t develop without padding. Unit tests, exception notifier, cheap branching/merging in git, fast deploy with capistrano are all padding that mean you fear less and can try things that might hurt you because you can fix them fast.

Adam then moved on to some ways to ‘supersize’ your learning by mistakes:

• Make bigger mistakes – Because you’re going to make mistakes anyway, you mind as well swing long so that when you do succeed: it’s spectacular (This is a great sentiment that I think applies very well to running a business too).
• Getting into the groove – We all have issues with getting into the groove when programming without being distracted. Adam recommended that you need a jumpstart, because once you get started, you are likely to continue coding. Set small goals or fix a few small bugs to get the ball rolling.
• Layer up, Layer down – Adam also mentioned that the best way to expand your learning scope is to work with things adjacent to your main area of work. He addressed specifically other parts of the Rails production stack: SQL, Web servers, etc. Again we find ourselves talking about being jack-of-all-trades by knowing about more than just our tiny little slice of the computing stack.
• Learn a new language every year – The grass is always greener on the other side, so explore that ‘other side’. Know if there is a better way of doing something, or at least be sure that you’re still using the best tool out there
• Passive Mentors – Adam talked about ‘shadowing’ many great developers, in IRC, on blogs, whatever. Learn what they have to share, how they operate, the mistakes they’ve made, etc.

“Beside writing code, learning is what we do as software developers” – Adam Keys

“Hurry up and lose your first 50 games.” – Go proverb presented by Adam Keys