This post originated from an RSS feed registered with Ruby Buzz
by David Heinemeier Hansson.
Original Post: What Highrise has meant to Rails
Feed Title: Loud Thinking
Feed URL: http://feeds.feedburner.com/LoudThinking
Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp
Highrise is coming up on its 1-month anniversary. It was a fantastic relief to finally get it out and it has been a wonderful experience to see it become the fastest selling product we've ever launched.
We had been working on/off on this application for more than a year. Which in 37signals terms is pretty close to an eternity. Sure, this included a more than 6-month break and a scrap-it-and-start-over process, but still.
While the application itself has been a long time in the making, most Rails developers have long been reaping the benefits of its development. A gallery of high-profile Rails features were specifically developed through my work on Highrise and extracted into Rails along the way. Here are three big highlights:
Polymorphic associations
To be able to tag both people and companies (and later to come, cases and notes), I had to come up with a way to refer to the other end of an association as a role. An abstract, polymorphic target. So in Highrise, tags are linked to "taggables". Before polymorphic associations, the conventional Rails wisdom before this was a join table per-tag association. So companies_tags, people_tags, etc. Yuck.
The trial balloon for this became the acts_as_taggable plugin, which we later abandoned for Highrise as we simplified tagging and realized that the polymorphic associations now made the implementation so trivial that it wasn't worth abstracted any more.
Eager loading
The first version of Highrise had a horrifically complicated permissions system that caused nasty N+5 issues on the primary pages of notes. Early benchmarking caused me to chase eager loading as a way around it.
It ended up being a blind alley (the system was still a mess), so we scrapped the ultra-flexible setup we had and went with something far simpler. Eager loading was no longer a necessity, but never the less a welcome consolation prize for time wasted.
RESTful loving
From day one, I wanted Highrise to be born with an API (which also spawned AR#to_xml), to be at home with feeds (which spawned the resource_feeder plugin), to speak and listen to CSV. After spending way too much time adding these things to Basecamp, I never wanted it to be a hack-on job again. Neither on the server-side nor on the client-side (the latter intention gave birth to Active Resource).
So we started with the assumption that the application itself should be the API. That blossomed into a full-fledged love affair with HTTP and a big bet for Rails that REST would turn from seed to flower fast.
Ironically, Highrise launched without a documented API — but it should follow soon as I wrap up documentation of what is already there under the covers and polish the last sharp edges.
The little things
While the three major features and themes above are easy to point to, I'm actually even more satisfied by all the little things. When I look back through the changelogs, I see the tiny tweaks, the pretty polish, and I can trace almost all of these commits back to a corresponding Highrise checkin that used these changes.
Making what we have better, simpler, more beautiful is pure joy. And a strong reminder why I still love working on Rails. Even after all these years. Hardly a day's worth of real work goes by without discovering some nit worth correcting.
Simply Helpful, OpenID, and Active Resource
And Highrise continues to be a strong driver for my personal improvements to Rails. The banner of Simply Helpful (one of the themes for Rails 2.0), the charge to make Rails and OpenID a dead-easy cocktail (currently seeing experiments in the open_id_authentication plugin), the drive to get Active Resource to 1.0. All themes that I work on because I need to.
Previous Topic
