development

You might have noticed that it has been a little quiet around here of late. We haven’t gone anywhere and we certainly haven’t stopped improving Guestlist. On the contrary, we’ve actually rewritten it.

A little while ago Guestlist quietly cut over to a shiny new Rails 3 application. We did this without downtime and without anyone even noticing.

Wait, Guestlist wasn’t already Rails?

Many people probably thought Guestlist was already a Rails application. This is *almost* true. We built the original Guestlist using Merb, a Ruby framework that emphasizes modularity and performance. Because the Ruby web framework community is so fantastic we were able to make use of many Rails components even though we were using a different framework.

Why?

While the two frameworks were originally competing for mindshare, over time Merb became an important influence on Rails. In fact, the projects ended up merging and a number of core Merb committers did a huge amount of the work involved in making Rails 3 a reality. We were incredibly pleased with how well Rails 3 turned out and decided that we should invest the effort in upgrading our app in order to take advantage of all it has to offer.

How we did it

We were able to make the upgrade seamless by leveraging many of the great libraries that the Ruby web community has produced. We had Guestlist running on Rack and Unicorn even before they were part of a stable Merb release. We had been very early adopters of Bundler from back when it was still a Thor script that came packaged with Merb. Over time we replaced many Merb components with Rails-compatible Rack middleware. In early February we started swapping out major parts of the infrastructure, getting our large automated test suite to pass, and repeating.

When it came time for the final release we made our Merb and Rails deployment environments identical. This included the database schema, Nginx and Unicorn configurations along with all of the daemons, watchdogs and other monitoring infrastructure. We already use Unicorn for seamless, no-downtime upgrades so rolling out the Rails rewrite release was no different than a bugfix deploy.

Some stats:

• 242 commits, 903 files changed, 18771 insertions, 32006 deletions.
• 26 gems added, 23 gems removed, 33 gems upgraded, 27 gems unchanged.

It has been a lot of work but we’re very pleased with the results. We are already starting to make use of many Rails 3 goodies and will be announcing some of the great features we are building on them shortly.

When we sat down to build the Guestlist website, we thought we’d try using Jekyll, a “blog aware” static site generator written in Ruby. The basic idea is that your website is composed of a number of layouts, pages, and blog posts, which Jekyll stitches together into a set of static files during a single build step – not at runtime. This gives us a couple of neat advantages over traditional hosted publishing software like Wordpress, which generates pages dynamically.

Static files are fast

With Jekyll, you are serving your website content directly from the file system, instead of handing off to a dynamic process (in Wordpress’ case, PHP). Serving static files is fast – as fast as it gets. This means we don’t have to worry about being Techcrunched or getting hammered with traffic because our web server can stand up to it.

Source control friendly

Instead of managing all your content inside Wordpress’s database, it’s being managed via source control – in our case, Git. That means we can work on the website when we’re offline, seamlessly share changes, and browse history online via GitHub. And since Git repositories are distributed, backing up our data isn’t a concern.

Less security concerns

Since Wordpress is hosted software operated over the web, it means dozens of potential injection vectors are publicly accessible to would-be attackers. And as you’re probably aware, vulnerabilities have been discovered. Contrast this with Jekyll, which does all its work offline and off the server; it’s a tougher nut to crack.

Easy to deploy

Unlike Wordpress, I don’t need to install Jekyll on a single server – just my local development machine. Our deploy process is to build the site locally, then rsync the result to a remote server. The whole process takes seconds. Compare this to having to manage multiple Wordpress installs on multiple servers, keeping them all up to date, backed up, and humming smoothly. That’s a lot of maintenance.

Use your favourite editor

I don’t know about you, but editing blog posts in a 300 x 300 textarea isn’t my idea of fun. With Jekyll, I can fire up TextMate and write away, complete with spell checker, Textile syntax highlighting, and other useful goodies. Using the same editor to write blog posts as I write code also gives me a warm, fuzzy feeling - for whatever that’s worth.

So, those are some compelling reasons to use Jekyll. There are downsides, of course – what happens when you want to insert dynamic content, for starters? But that’s an article for another day.