I finally tried out Passenger (mod_rails) and Ruby Enterprise Edition. Two words come to mind: easy and awesome!

For those of you that don't know, Passenger is an apache module that makes Ruby on Rails deployment super easy in the same way that deploying php can be super easy. You simply point apache at the public directory of your Rails application and you're good to go. Ruby Enterprise Edition is written by the same folks as Passenger and it improves Ruby's garbage collector and memory allocator. They claim that with Ruby Enterprise Edition your Rails apps will use 33% less memory.

I highly recommend checking it out.

Most applications display lists of various things and they usually display these lists in slightly different ways. In my opinion, there isn't a one-size-fits-all solution to building these lists, but there is a pattern that seems to work pretty well. It consists of three parts: the list, the list-item, and the item. In addition to partitioning your lists into smaller pieces that are easier to deal with, it also makes it very easy to add both css styling and ajax behaviors to your lists.

About a week ago I stumbled across an option that you can pass to the submit_tag form helper in Rails — :disable_with.

Now (thanks to some automatically injected javascript) when you press this "Save" button it will disable itself, change its text to "Saving...", and then submit the form. Cool, right?

Yeah, most of the time it's cool. It's nice to do anything that gives the user an indication of what's going on — especially in a way that prevents them from repeatedly pushing a button on a form that takes a second or two longer than it should.

However, there is one time it's not cool! It's not cool if you have a form that contains more than one submit button and you expect to do different things depending on which button is pushed. A button is simply an input tag just like any other input tag in a form. It has a type, "submit" in this case, a name and a value. The GOTCHA is that, like any other input field, if it's disabled it doesn't get posted to the server. Oooops! So much for using :disable_with on this particular form!

Surely you use the Rails generator script to create your models! You fill in the blanks in the migration for the new model, run the migration, work on the model and its tests, and then commit to Subversion. Right? And, surely after you've worked on a project for a while you've needed to remove one of these models. You write a new migration to remove the table that maps to your stupid_model and then you...

script/destroy model stupid_model --svn

Ooops! See what just happened?

D         db/migrations/002_create_stupid_model.rb

You conveniently used the --svn switch to delete the files from subversion and it not-so-conveniently deleted the initial migration for the model. It may not be obvious at first, but the next time someone tries to rake db:migrate through your series of migration scripts from start to finish it will fail when it tries to drop a table that never existed in their database (assuming it didn't fail earlier).

This morning I needed to remove a model and rather than doing it by hand (to avoid the above problem) I thought I'd take a quick look through the generator source to see if it would be easy to add an option that told the destroy model script to skip the migration. Turns out it's already there (--skip-migration) it just isn't documented!!

script/destroy model stupid_model --skip-migration --svn

Perfect! However, it might be nice if this were the default behavior...

I recently started working on a project that needs to integrate with Basecamp. 37signals provides a ruby script, basecamp.rb, to ease the use of their API, but it hasn't kept up. Specifically, they expanded the API to expose the time-tracking functionality in Basecamp.

Being fond of monkey patching I thought I'd create a Ruby on Rails plugin so I can easily add whatever methods I need without having to alter the actual basecamp.rb file. I'm sure I'll be adding more methods in the near future, but right now the plugin just contains one method for grabbing time entries.

You can grab this plugin from svn:

svn co http://svn.jthopple.com/plugins/monkeycamp

Or, install it directly from the root of a Rails project:

script/plugin install -x http://svn.jthopple.com/plugins/monkeycamp

Check out the documentation for more information.

Code readability is an undisputed contributor to increased programmer productivity. Ruby on Rails shines in this department by effectively using two main pieces of Ruby — the hash and the symbol. These two things are used all throughout Rails, but most importantly as method parameters. There are two keys to keep in mind when writing methods:

1. When passing multiple data parameters to a method, pass a hash
2. When telling a method how to behave, pass a symbol

Ruby on Rails migrations rule! They're easy to get started with and have changed the way I approach database-driven application development. However, I was recently shocked when I used capistrano to deploy a new version of an application and one of the migrations exploded. It turns out that using ActiveRecords in your migrations can lead to unexpected results, but by following two simple guidelines you can ensure that your migrations will remain reliable throughout your application's life-cycle.