The Rails console is an extremely useful tool and most Rails developers use it all the time for debugging or experimenting with code and also as an interface for modifying the application’s data. In this episode we’ll give you some tips on how to get the most out of the console.

The console can be opened from a terminal window by running rails console, or the shorter alternative rails c, in the application’s directory. We can pass a number of options to this command; some useful ones are production, which will start the application in the production environment, and --sandbox which will wrap the console session in a database transaction so that any modifications we make are rolled back. This second option is handy if we want to experiment with something without permanently changing the database.

In this example the ProductsController’s index action is run. This is a great way of seeing what database queries are performed for a given request. The app method is an instance of ActionDispatch::Integration::Session which is something normally used for integration testing but it works perfectly well in the console too.

If we look at the Rails Guide for integration testing we’ll see some more of the methods that we can call on app. We can run app.cookies to see which cookies are set, or use app.response.headers and app.response.body to see the headers or body of the last response. We can even inspect the instance variables that were assigned by the controller in the last request by calling assigns and passing in the variable’s name as a symbol.

console

> app.assigns(:products).size
=> 22

A similarly helpful method is helper. This gives us access to the view context and we can execute helper methods on it to test them out.

console

> helper.number_to_currency(12.34)
=> "$12.34"

We can also call the custom helper methods that we define in our application. One thing that won’t work, though, is the params hash so if we have a helper method that references the request parameters then calling it here will raise an exception. To fix this there’s another method that the console provides called controller that returns a new ApplicationController instance. For some reason this isn’t hooked up to the helper but we can set it manually, along with its parameters which will then be available to the helper.

Another useful console method is called reload!. This picks up any changes we’ve made to our application since starting the console. Let’s say that the Product model’s to_param method isn’t working the way we want it to. We can make the necessary changes in the model file then run reload! in the console. When we run to_param on the product again the changes will have been picked up. This is a handy trick but it does have the occasional issue so if you want to be absolutely sure that the changes have been picked up it can be better to stop and restart the console.

Customizing The .irbrc File

Ever since Rails 3.1 ActiveRecord logs its SQL queries to the console which is very useful. If we want to disable this feature we can do so by setting the logger level to anything above zero.

To make this the default behaviour in the console we can set it in the .irbrc file in our home directory. We can put any Ruby code into this file and it will be evaluated when either irb or the console are loaded. We have some code in this file already to enable tab completion and a save history feature that keeps up 1,000 lines of history between sessions.

When we reopen the console now and run the code below, TextMate will open up the source code at the correct line.

console

>> helper.mate(:number_to_currency)

Gems That Work With irb

There are a lot of gems designed to work with irb. A good one is Hirb which will display ActiveRecord data in a table. We can install this gem in the usual way.

terminal

$ gem install hirb

If we open the console now and run require 'hirb' this won’t work, however. This is because Bundler locks down the gems that we can use in our Rails app to those listed in the gemfile. We could add a reference to Hirb at the bottom of our app’s gemfile for just the development group but we’d have to do this for every Rails app that we want to use Hirb with. Also other developers working on the same project may not want this installed. This is something we want to add to our development environment rather than to specific applications. Thankfully there’s a hack we can add to our irbrc file that can help with this.

This checks to see if Rails is defined then requires and enables Hirb if so. Note that we rescue any LoadError just incase we switch to another version of Ruby that doesn’t have the Hirb gem installed.

Other useful gems include Awesome Print, which gives us an ap method that will show models’ attributes nicely formatted and with colour. The Clipboard gem enables us to interact with the system’s clipboard by giving us Clipboard.copy and Clipboard.paste methods. MethodFinder is another handy gem that can help us if we know there’s a method that does something but can’t remember what it’s called. For example if we know that there’s a method on the String object that will return “ABC” when we pass it “abc” we can use MethodFinder to find it.

The Wirb gem will colourize output, too, if you want that. There’s a compilation of many of these utility gems called irbtools. Even if you don’t install this gem there’s a great list of other utility gems listed in its README.

Finally, we can’t finish without mentioning Pry. This is a replacement for irb with many extra features. It was covered in episode 280 and there’s much more information about it there.