Aaron K. Hawkins

The elevator door opened and I stepped inside.  It’s was kind of like if you’re at Disneyland and you find yourself standing alone in an elevator with the real Mickey Mouse, only you can’t remember his name.  You’re positive that you’ve seen his face before and maybe subscribe to his blog and that he probably is important or famous or something.  Who would pass up an opportunity to strike up a conversation?  Only it turns out that Mickey Mouse was really Donald Duck - you just didn’t recognize him.  And thats how I learned that Michael Koziarski isn’t Thomas Fuchs.

Despite my embarrassment, I still attended Optimizing Rails, a talk given by Michael Koziarski at RailsConf 2008.  This talk wasn’t about optimizing your rails application.  It focused on how to optimize the Rails Framework itself.  Optimization is a scientific process which requires profiling followed by fixing, repeated many times.  Short circuiting the process is the equivalent of guessing - and when we guess we are always wrong.  

He told a story about their Trac installation for Rails.  Their installation was above and beyond the normal traffic usage patterns of other projects and they were  having crazy performance problems.  Naturally they looked to the community for help.  People suggested lots of things.  They upgraded the database driver - no effect.  They tweaked some settings - no effect.  Finally they dug into the code to see what was going on and discovered that the svn revision number was stored in the database as a string.  Turns out there is code called multiple times on every page to calculate the most recent svn version.  Calculate is the correct word.  Instead of doing a simple sql query to get the max reversion number there was a method that would calculate the latest version number from a string (Hey - someone may want to use a Version Control System someday that uses strings as keys for revision identification - right?)  This implementation, combined with their high load was enough to bring the site down.  So they hacked it to store an integer and the performance problems went away.  The key lessons were that everyone else knew what the problems were but it wasn’t until they measured and profiled, and used a  scientific method that they found the real problem.  

This principle applies to optimizing Rails.  You can’t just guess and most people know that.  So naturally, they look for something to serve as a benchmark - and that’s the problem.  What is a good benchmark for Rails?  Many of the posts deriding Rails’s performance build a trivial hello world app and then benchmark it.  Michael showed a couple of different examples of benchmarking against a trivial program and the results.  Then he compared benchmarking one of his client’s applications and the results.  As you may guess, they were quite different.  What was a huge performance hit (say 15%) in the trivial case was completely irrelevant in a more representative application.

The Core Team does work on optimizing Rails by using their own applications as benchmarks.  While working on these real applications they find problems, bring them back to the group for discussion and finally add them to Rails if it seems like it might be a good fit.  He hinted that their time was limited, so it might be better spent working on tangible tasks like documentation, feature requests, etc, rather than blindly looking to optimize the framework.  I agree with this approach.  

We know that Rails was extracted as a framework from a real application.  I like the fact that the optimizations added to Rails are also extractions from real applications instead of just making theories and going with their gut to find performance improvements.  So the next time you think - “man Rails is inefficient or bloated or slow - why don’t those guys fix it” - go ahead and benchmark your application and see if the Framework is really the limiting factor.  You may be surprised by the results.    

In his keynote at RailsConf 2008, David Heinemeier Hansson referenced one of the core tenants of rails: convention over configuration.  In that discussion, he expounded on the paradox of choice.  Generally we intuitively believe that choice is good, desirable, and laudable.   However, while we honor the ideals of choice and flexibility, we are quick to forget or even ignore the accompanying complexity and cost.  So in the heat of the moment when the crunch is on and we come face to face with choice and flexibility, we turn and seek solace from someone, anyone who can tell us which to choose.  At that instant, we regret it.  When it really comes down to it - we don’t want choice - we want a solution.  And Rails provides one.

Yet, I am increasingly buffeted by those singing the siren song of choice and flexibility.  It manifests itself in the form of a discussion over breakfast with some DataMapper developers.  ”DataMapper is faster.  It uses less memory, it’s more efficient, it isn’t as opinionated - you can configure it.”  Ding Ding Ding, that is the problem.  I don’t want to configure it.  I don’t want choices.  I don’t want to research, evaluate, and decide.  I don’t want Java and its infinite flexibility.  I do want to create killer applications.

The song doesn’t stop. It just changes channels, and guess what’s playing - Jumpin’ JQuery Jazz. “But JQuery is so much cleaner, it plays nice with others, it’s smaller, it’s built on css selectors, it’s unobtrusive.”  Wow - that’s really cool but what you didn’t mention is that it doesn’t work with the rails views and javascript helpers. And like a loving father who sorrowfully watches a wayward child wander in darken paths, Rails will let you override its defaults, constraints and conventions and wish you luck as you set out on your own.

By the time the Rspec retro reggae hits my ears - I just turn the radio off.  The music is giving me a headache.     

There is a reason that java developers are famous for developing frameworks rather than actual applications - they all get bogged down in the decision-making process.  I mean it is completely overwhelming.   They have to choose a web framework, a presentation layer, a database access strategy, a build system, a testing framework, a development environment, and find a way around or out of the train wrecks that are EJB and JSF.  Luckily, being excellent computer scientists they recognize the limitations of the current offerings and set off to fix them.  And that, ladies and gentlemen, is why we have Ten Thousand Java Frameworks And Counting.

So I proudly declare it.  I’m not a computer scientist.  I’m an application developer and entrepreneur.  I solve business problems.  I’m a Rails Disciple.  I embrace its constraints and conventions.  I love that it makes many choices for me.  I’m not blind and oblivious to new technology and I don’t claim Rails the victor in the discussion of technical superiority.  However, I will outsource many technical decisions to Rails and sleep all the better for it.  After all, if it works for 37 Signals, surely it can work for me.  

Ok, its not as big as Christmas Eve, but I’m still excited for the conference to start tomorrow.  This will be my second time attending and I’m excited for different reasons this time.  RailsConf 2007 was my first conference that wasn’t run by No Fluff Just Stuff so I think my expectations were unrealistic.  The NFJS conferences that I attended were more intimate due to the limited number of attendees.  The speakers were all fantastic and people I had heard of and looked up to.  Many were published authors.  I sat in multiple classes taught by people like Dave Thomas and Justin Gehtland.  The chance to eat with them and talk in the hallway was just as valuable as the sessions.  ’Brain Fatigue’ is an adequate description of my brain’s condition at the end of the day.  However, I left feeling renewed and inspired. 

In contrast, I left RailConf 2007 with mostly a headache.  I was expecting a similar experience like those from NFJS- minus the small conference like atmosphere.  I think the biggest surprise were the vendor land-mind talks.  You know the ones - they have titles like “scalability” etc but really are about a specific product.  I wasn’t really aware of this trap, and took for granted the NFJS policy on not allowing vendor presentations, and inadvertently spent more time that I would have liked in vendor sessions.  My goal is to avoid unintentionally wandering into those this year.

It also seemed like the presentations just weren’t up to par - both the topics and the skills of the presenters.  RailsConf sold out quickly last year - and to address the increased demand the conference added another track late in the process.  I’m not sure if that was the cause, but I suspect it played a part in the feeling that overall things just weren’t polished.  Now there were definitely exceptions, but I felt that out of the 3 days - almost an entire day of sessions could be categorized as ‘meh’.  Maybe it was just a manifestation of the growing pains exhibited in the community as a whole.  Maybe I just didn’t know, like in college, which were the do not miss, in contrast with the avoid at all costs, presenters.  

This year, I’ve grown up a bit with rails.  I’m more familiar with the technology.  I have some experience under my belt and am able to ask better questions.  I think the speakers have also had the time to prepare their thoughts and polish their presentations.  I’ve done some homework on the speakers and am looking forward to hearing what they have to say.  I’m also excited to meet fellow developers and broaden my horizons.  My outlook is a bit different,  I have a better idea of what to expect, and I’m optimistic that this is going to be a great event.  Here’s to a great RailsConf 2008.