There are cases where you don’t want to run your entire Rails test suite. From your Rails application directory run the following command:

ruby -I lib:test test/integration/dealer_admin_test.rb

A small but useful tidbit.

I recently got a new MacBook Pro and had problems creating a new database for my Rails app on Snow Leopard. Running rake db:create left me with the following useless error:

Couldn’t create database for {“username”=>”root”, “adapter”=>”mysql”, “database”=>”delete_me”, “password”=>nil, “socket”=>”/tmp/mysql.sock”}, charset: utf8, collation: utf8_unicode_ci (if you set the charset manually, make sure you have a matching collation)

Although I could manually access MySQL via command line and create the necessary databases, rake continually failed. It turns out that the MySQL gem needed to be compiled for a 64-bit OS as mentioned in this post:

http://weblog.rubyonrails.org/2009/8/30/upgrading-to-snow-leopard

The key command to run is:

sudo env ARCHFLAGS=”-arch x86_64″ gem install mysql — –with-mysql-config=/usr/local/mysql/bin/mysql_config

Then you should be able to run your rake tasks and ultimately get Rails talking to your MySQL database.

While upgrading our Rails app to version 2.3.2 I ran into a painful bug when running our unit tests. Previously, we defined ActionMailer instance variables to be used in our views like this:

@body["name"] = user.name
@body["feedback"] = feedback
@body["when"] = Time.now

I had to refactor this to use a hash as the ActionMailer documentation suggests:

body {:name => user.name, :feedback => feedback, :when => Time.now}

It turns out this doesn’t work and generates an error. So I removed the hash and did the following:

body :name => user.name, :feedback => feedback, :when => Time.now

Now all is well. It cost me an hour of my day and hopefully it will cost you much less now that you’re informed. If you can share any information why the hash doesn’t work then please feel free to share. Thanks!

This was the error I received when deploying a Capistrano deployment from github. Keep in mind to even get your submodules deployed you’ll need to add the following var to deploy.rb:

set :git_enable_submodules, 1

It turns out that I had git 1.5.2.5 and submodule support did not come until 1.5.3. So I was forced to upgrade. The process went something like this:

sudo apt-get update

sudo apt-get build-dep git-core

sudo apt-get remove git-core

wget http://www.kernel.org/pub/software/scm/git/git-1.6.2.tar.gz

tar xzf git-1.6.2.tar.gz

cd cd git-1.6.2

./configure

make

sudo make install

Type “git submodule” and you should see the appropriate error, meaning it recognizes the submodule parameter. There’s a chance that git won’t be in your path so just do the following:

export PATH=$PATH:/usr/local/bin

You should be good to go!

This was a beast of an error to get around, but finally I did in a not so clean manner. I’ve been working with Rails Engines and the approach was to make all controllers in my engine path “unloadable” per the last comment in this thread:

http://dev.rubyonrails.org/ticket/6001

Not the cleanest approach, but it will work until I can actually understand the core problem and refactor my code. This should at least buy you some time so that you can focus on creating modular Rails Engines!

If you’ve developed in Rails for a decent amount of time then you’ve most likely needed to use the interactive console: ruby script/console. This has saved me within our production application on many occasions. As you probably know, when using the console in production mode, logging is disabled. Sometimes it’s useful to see the queries generated by ActiveRecord, which brings me to my scenario from yesterday. I badly needed to see what query was being gererated by one of my model methods and stumbled across this snippet of code:

ActiveRecord::Base.logger = Logger.new(STDOUT)

Be sure to restart your console before running this command and when you execute a statement like User.find(1) you’ll be presented with some handy debug info.