Before making the switch, I recommend to run your Cucumber tests to ensure all tests pass:

$ cucumber features

As usual when adding new dependencies, you have to modify the Gemfile of your app. Replace the Webrat entry with:

gem "capybara", "0.3.9"

and run:

$ bundle update

With Capybara installed, you have to setup Cucumber to use Capybara by running one of the following commands:

// Rails 2.3.9
$ script/generate cucumber --rspec --capybara

// Rails 3.0.0
$ rails generate cucumber:install --rspec --capybara

Now, you are ready to run the tests again. If you are lucky, all tests pass, which means there is nothing more to do. However, I think it is more likely you will get a bunch of errors and maybe even some failing tests.

The errors I got were “undefined method” errors. They are relatively easy to fix by replacing the no longer existing Webrat methods with their Capybara counterparts. In the following code block I list some examples:

# Webrat
field_with_id('openid_identifier').value.should =~ /invalid OpenID/
# Capybara
find_field('openid_identifier').value.should =~ /invalid OpenID/

# Webrat
response.should contain('Previous')
# Capybara
page.should have_content('Previous')

# Webrat
assert_have_selector('.author', :count => 1)
# Capybara
page.should have_css('.author', :count => 1)

# Webrat
assert_have_xpath("//span[@id='#{id}']", :content => expected_count)
# Capybara
page.should have_xpath("//span[@id='#{id}']", :text => expected_count)

The trickiest part to fix was the failing test. To test some “remember me” functionality I manually set a cookie, and this no longer worked with Capybara:

cookies[:remember_me_id] = remember_me_id

After some searching I found a Gist from Nicholas Rutherford in which he dealt with cookies. Thanks to his code I could set my cookie with the following snippet:

cookies = Capybara.current_session.driver.current_session.instance_variable_get(:@rack_mock_session).cookie_jar
cookies[:remember_me_id] = remember_me_id

And with that, my switch to Capybara was complete. Any questions?

After following the instructions for creating a new Rails 3 app (using the –database=mysql parameter for the “rails” command) I noticed that the application tried to access the (not existing) production database. That was a bit strange, because I expected it to access the development database as I set the RailsEnv option of Passenger accordingly:

# for example in /etc/httpd/conf/httpd.conf
RailsEnv development

The reason this doesn’t work is because the generated application contains a “config.ru” file. In this case, Passenger treats the application as a Rack application and not as a Rails application. And so the RailsEnv setting is ignored as it is Rails-specific…

There are two ways to run the application in development mode: you can either remove the “config.ru” file (and keep the RailsEnv setting) or you can set the RackEnv option:

# for example in /etc/httpd/conf/httpd.conf
RackEnv development

Have fun with Rails 3 :)

Here an example from the API:

# app/views/posts/index.atom.builder
atom_feed do |feed|
  feed.title("My great blog!")
  feed.updated(@posts.first.created_at)

  @posts.each do |post|
    feed.entry(post) do |entry|
      entry.title(post.title)
      entry.content(post.body, :type => 'html')

      entry.author do |author|
        author.name("DHH")
      end
    end
  end
end

The code should be self-explanatory (if not, please leave a comment).

Recently, I had two such views which were almost identical, the only difference was the feed title. And that’s of course not really DRY.

One possible approach to fix this “issue” is to set an instance variable with the feed title in the controller and render the same view in both cases. As I don’t like to set view titles (resp. feed titles in this case) in the controller, I decided to use a partial.

And so I put the code from above into a partial (plus changing the instance variable “@posts” to a local variable “posts” and introducing a new local variable “feed_title”), and tried to use this partial (app/views/shared/_feed.atom.builder) in the following way:

# app/views/posts/index.atom.builder
render :partial => 'shared/feed', :locals => {:feed_title => "My Posts", :posts => @posts}

Well, it didn’t work. No output was generated.

After experimenting a bit I found the following solution by moving the outer-most block definition from the partial to the views:

# app/views/posts/index.atom.builder
atom_feed do |feed|
  render :partial => 'shared/feed', :locals => {:feed => feed, :feed_title => "My Posts", :posts => @posts}
end

I don’t know whether this is the best solution (probably not), but it is definitely better than what I had previously ;-)

undefined method `^' for "b":String (NoMethodError)

Fortunately, I am not the first one who encountered this issue, and so it is already fixed in the Rails git repository. To fix it on my local installation, I simply had to replace /<path_to_ruby_gems>/activesupport-2.3.4/lib/active_support/message_verifier.rb with the corresponding file from the git repository. And with that, my applications started to work again :)

With the “whenever” Ruby gem you can define those cron jobs directly in your Rails application.

After installing the gem (with “gem install javan-whenever”) you either have to create the file “/config/schedule.rb” manually, or you can use “wheneverize” to generate this file (call “wheneverize .” from your project root). You can then add your application-specific cron jobs to this file.

For example, let’s say you want to clean up the users table and remove all users who didn’t activate their accounts, then you would write something like:

every 1.day, :at => '2am' do
  runner "User.cleanup_inactive_users"
end

This will execute the “cleanup_inactive_users” method of the “User” model daily at 2am (you could also use “every :friday do” to run it every friday, or “every 2.hours do” to run it every two hours, and so on) . The “runner” keyword allows you to execute Ruby code (it uses “script/runner”, hence the name). You can also use “command” to execute command line tools, or “rake” for running rake tasks.

So far we simply described our cron job, though no cron job is active yet. To change this, we have to tell cron about our cron job with:

whenever --update-crontab example

“example” is a unique identifier for our application, and is used by “whenever” to determine which cron jobs it has to modify when you update “schedule.rb” and re-run the above command. It is probably best to put this command in the deployment script of your application to keep your cron jobs up-to-date.

With “crontab -l” we can see the job(s) added by “whenever”:

# Begin Whenever generated tasks for: example
0 2 * * * /home/dho/projects/example/script/runner -e production "User.cleanup_inactive_users"
# End Whenever generated tasks for: example

With that, our cron job should be executed like any other cron job on our system.

I hope I could give you a short overview about this quite useful gem, for more information see:
http://github.com/javan/whenever
ASCIIcasts “Episode 164 – Cron in Ruby”

And those are the things I had to change (though most changes seem to be optional):

• Renaming app/controllers/application.rb to app/controllers/application_controller.rb
• Replacing config/boot.rb, as it was slightly modified
• Adding the new “reconnect” option for MySQL databases to config/database.yml (see the release notes)
• Moving the settings for “config.action_controller.session” and “config.action_controller.session_storage” from config/environment.rb to the new file config/initializers/session_store.rb
• Changing the value of RAILS_GEM_VERSION from 2.2.2 to 2.3.2 in config/environment.rb
• Copying config/initializers/backtrace_silencers.rb to my project
• Adding the setting “config.action_view.cache_template_loading = true” to the production and testing environments (config/environments/production.rb resp. test.rb)
• Removing the dispatch scripts from the “public” directory, the script/process directory (and its content), plus the “request” script from script/performance

A detailed overview of the changes/new features of Rails 2.3 can be found in the release notes.

$ rails example // Rails 2.x
$ rails new example // Rails 3.x

is that by default a generated project is configured to use a SQLite database. And so the configuration file for the databases looks as shown below (I omit the configurations for the “test” and “production” environments, as they are almost identical):

# example/config/database.yml
development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

This leads, of course, to an error as soon as you try to access the database while there is no such driver installed ;-)

To avoid this small problem, you have to specify the database type when using the “rails” command:

$ rails -d mysql example // Rails 2.x
$ rails new example -d mysql // Rails 3.x

This command then generates the following database.yml:

# example/config/database.yml
development:
  adapter: mysql  # Rails 3.x uses the mysql2 adapter
  encoding: utf8
  database: example_development
  pool: 5
  username: root
  password:
  socket: /var/run/mysqld/mysqld.sock

Happy Rails baking!

Update 2009-03-23: An alternative approach in Rails 2.x is to define the variable RAILS_DEFAULT_DATABASE with:

$ export RAILS_DEFAULT_DATABASE=mysql

Update 2011-02-20: Adapted for Rails3

dho@tumulux:~/projects/myrailsproject$ ./script/plugin install git://github.com/rails/open_id_authentication.git

The example command from above will download the OpenIdAuthentication plugin from GitHub and put the plugin in the vendor/plugins directory. Quite handy.

In the CakePHP world there is currently no equivalent. However, John David Anderson (aka _psychic_) recently published an early version of a Plugins shell console application to manage plugins.

Happy working with plugins!

In CakePHP, the names of those “magic” columns are:

created
modified / updated

In Rails, on the other hand, the respective column names are:

created_at / created_on
updated_at / updated_on

Fortunately, the other database-related naming conventions seem to be the same in both frameworks.

As I currently use Apache2 for both, Rails (using mod_rails) and CakePHP, a virtual host entry in /etc/apache2/sites-available/default looks like:

<VirtualHost *:80>
    ServerName myproject.localhost
    DocumentRoot /<path_to_document_root_of_myproject>
</VirtualHost>

If you have a CakePHP project, the path to the DocumentRoot is usually something like:

DocumentRoot /<path_to_the_projects>/myproject/app/webroot

With Rails, on the other hand, the path to the DocumentRoot is something like:

DocumentRoot /<path_to_the_projects>/myproject/public

After a restart of Apache you should get the welcome screen of the respective framework if you go to http://myproject.localhost (assuming you already “baked” the project structure and added an entry to the /etc/hosts file).