The Problem

Incremental feature development against existing systems frequently involves rethinking and rebuilding existing components. If it’s possible, the easiest way to add support for your new feature is to introduce a new, optional attribute on a model (or in the case of a relational database, adding a NULLable column to an existing table, or adding a new table). Sometimes, though, that either isn’t possible, or wouldn’t be the best design going forward, given your new knowledge of the feature set of the product at hand. You’re left with the uncomfortable realization that the best design would be something completely different that isn’t backward-compatible with current systems.

When there are multiple systems that consume a given data model (say, a front-end webserver, an API, tons of cron jobs, and many backend daemons, like in the case of Twitter’s Ads systems), you can’t just “stop the world,” ALTER your tables, and deploy all the new code. That’s fine if it’s you and another nerd in a garage, but when you’ve got paying customers, you don’t want to give them an excuse to spend their money elsewhere.

In shutting down the AdGrok servers (talk about bittersweet…), I stopped the instances, but then remembered I wanted to shred the files first, so I clicked “start,” and was greeted by the following error:

The requested Availability Zone is no longer supported. Please retry your request by not specifying an Availability Zone or choosing us-west-1b, us-west-1c.

This last Friday I taught my “it really is rocket science” class to another hundred children (Kindergarten through 5th grade). Last year PTO Today wrote an article about Arts and Science day, and interviewed me. This year, the kids were great, I had tons of help, and the new rocket launcher designs let the kids experiment with different pressures and different launch angles. Good stuff!

Update January 2012: since originally writing this post, I’ve recanted my love for rails plugins — having a stubbed rails app in your plugin’s test directory is just too funky. If you need an example of a rails 3.2.x plugin that uses rspec 2 and has Travis CI integrated, check out closure_tree. But even that setup feels to heavyweight.

The original post follows.

There are a lot of posts on how to build rubygems. With Rails 3.1, though, they’re all old and busted.

The new hotness is built right into rails now. Just incant

Ruby

1

railspluginnewAPP_PATH

You’ll get:

a .gemspec and Gemfile to get started

a dummy rails app to integration test your new gem against

a (deprecated) RDoc rake task

When you run rake, you’ll see “rake/rdoctask is deprecated. Use rdoc/task instead (in RDoc 2.4.2+)”. To remedy, follow these steps.