Development Blog: Post

Mark Cornick, Web Developer, April 21, 2008 3

Rails application deployment has gotten a pretty bad rep. Legitimate Rails developers and blog trolls alike have bemoaned the lack of something equivalent to mod_php, which would make Rails applications "just work" when uploaded to a web server, as we got used to doing in the PHP days.

So Passenger made a big splash when it was released this month. It promises to make deployment "a breeze" and says "No Ruby on Rails-specific server configuration [will be] required!" Furthermore, the developers' own benchmarks show it being a little faster than Mongrel.

After a decade-plus in IT, I'm skeptical of hype and twice as skeptical of benchmarks. But even though I've mastered the sometimes-confusing realm of Apache and Mongrel, I'm curious to see just how easy it is to use, and just how fast.

Continue reading "Passenger: Let It Ride?"

Mark Cornick, Web Developer, April 04, 2008 0

A little over a year ago, the open_id_authentication plugin for Rails made its debut, intending to make OpenID authentication simple. And it did, for a while. But, like Rails itself, OpenID is a moving target and the OpenID specification, as well as the ruby-openid library, have both moved on to version 2.0 since then. The API changed enough that the plugin wouldn’t work with the newer library, effectively leaving applications that use it in the OpenID 1.0 world.

This all changed last Thursday. After much deliberation, a new version of open_id_authentication has landed, with support for ruby-openid 2.0.x, and OpenID 2.0 along with it. The upgrade process is pretty painless; a few database tables need attention (the new plugin will generate a migration to take care of those) and you’ll need to tweak any mocks you’re using in your tests/specs (you are using mocks, right?) It took me about half an hour last night. If you’re doing OpenID in your application, or if you think you want to, now’s a great time to take another look at this plugin.

David Eisinger, Web Developer, March 28, 2008 5

If you’re anything like me, you’ve used cURL to download a batch of MP3 files from the web, or to move a TAR file from one remote server to another. It might come as a surprise, then, that cURL is a full-featured HTTP client, which makes it perfect for interacting with RESTful web services like the ones encouraged by Rails 2. To illustrate, let’s create a small Rails app called ‘tv_show’:

rails tv_show
cd tv_show
script/generate scaffold character name:string action:string
rake db:migrate
script/server

Fire up your web browser and create a few characters. Once you’ve done that, open a new terminal window and try the following:

curl http://localhost:3000/characters.xml

You’ll get a nice XML representation of your characters:

<?xml version"1.0" encoding="UTF-8"?>
<characters type="array">
  <character>
    <id type="integer">1</id>
    <name>George Sr.</name>
    <action>goes to jail</action>
    <created-at type="datetime">2008-03-28T11:01:57-04:00</created-at>
    <updated-at type="datetime">2008-03-28T11:01:57-04:00</updated-at>
  </character>
  <character>
    <id type="integer">2</id>
    <name>Gob</name> 
    <action>rides a Segway</action>
    <created-at type="datetime">2008-03-28T11:02:07-04:00</created-at>
    <updated-at type="datetime">2008-03-28T11:02:12-04:00</updated-at>
  </character>
  <character>
    <id type="integer">3</id>
    <name>Tobias</name>
    <action>wears cutoffs</action>
    <created-at type="datetime">2008-03-28T11:02:20-04:00</created-at>
    <updated-at type="datetime">2008-03-28T11:02:20-04:00</updated-at>
  </character>
</characters>

You can retrieve the representation of a specific character by specifying his ID in the URL:

dce@roflcopter ~ > curl http://localhost:3000/characters/1.xml

<?xml version="1.0" encoding="UTF-8"?>
<character>
  <id type="integer">1</id>
  <name>George Sr.</name>
  <action>goes to jail</action>
  <created-at type="datetime">2008-03-28T11:01:57-04:00</created-at>
  <updated-at type="datetime">2008-03-28T11:01:57-04:00</updated-at>
</character>

To create a new character, issue a POST request, use the -X flag to specify the action, and the -d flag to define the request body:

curl -X POST -d "character[name]=Lindsay&character[action]=does+nothing" http://localhost:3000/characters.xml

Here’s where things get interesting: unlike most web browsers, which only support GET and POST, cURL supports the complete set of HTTP actions. If we want to update one of our existing characters, we can issue a PUT request to the URL of that character’s representation, like so:

curl -X PUT -d "character[action]=works+at+clothing+store" http://localhost:3000/characters/4.xml

If we want to delete a character, issue a DELETE request:

curl -X DELETE http://localhost:3000/characters/1.xml

For some more sophisticated uses of REST and Rails, check out rest-client and ActiveResource.

Clinton R. Nixon, Senior Developer, March 24, 2008 0

We’ve been flirting with behavior-driven development here at the Labs recently, and have tried out RSpec and test/spec. Both have advantages, but I like test/spec a little more: it works well with existing Test::Unit tests and has a syntax I find more natural.

Somewhere along the path to Rails 2, test/spec stopped working well for me. New test classes — ActiveSupport::TestCase, ActionController::TestCase, and ActionMailer::TestCase — were introduced to eliminate repeated code in Rails tests, and test/spec classes, which inherit from Test::Unit::TestCase, suddenly didn’t transparently work.

Working on a personal project this weekend, I decided to figure out how to use test/spec again. Digging through its code, I found this gem:

def context(name, superclass=Test::Unit::TestCase, klass=Test::Spec::TestCase, &block)
  (Test::Spec::CONTEXTS[self.name + "\t" + name] ||= klass.new(name, self, superclass)).add(&block)
end

So now, if I want to use test/spec in my Rails tests, I just put the superclass after the context name, like so:

# For models
context "User", ActiveSupport::TestCase
  ...
end

# For controllers
context "User Controller", ActionController::TestCase
  ...
end

# For mailers
context "User Mailer", ActionMailer::TestCase
  ...
end

Ben Scofield, Senior Developer, March 18, 2008 0

Migrations are a huge step forward for many developers new to Rails – versioning the database is not all that common in, say, PHP. Over time, however, migrations can get unwieldy – as you accumulate more and more they can slow down, and early migrations can create conflicts with later code changes.

We’ve been experimenting with one approach to deal with this with some success of late: consolidation. Basically, we develop with migrations normally, creating (for example) files numbered 001-010. Once the iteration is solid, we then push everything out to stage for testing, and assuming that passes we push it all to production. After the production release, we then consolidate the existing migrations into a single file that has the same number as the last migration file. In the example already mentioned, we’d create 010_consolidated_migration_for_[date].rb. All of the individual changes in the migrations get rolled up into the consolidated file, so that it represents a single step to initialize a new database.

Subsequent iterations work much the same – new migrations are created in development on top of the consolidated migration (say, 011-015). Once they’re tested and released, we consolidated again, merging 010-015 into a new 015 file.

There’s an obvious downside here – rolling back in production is made much more difficult after a consolidation. For our processes, that’s not a huge problem, since we place a high priority on never rolling back the production DB. You could minimize the risk, however, by keeping a rolling window of consolidated migrations (so you’d have two or three consolidated files on production, each with the appropriate self.down methods). Even then you wouldn’t need to keep too many files, however, since you should rarely need to roll back more than one release.