Is a gem you’re using not behaving the way you expect or giving a cryptic error you don’t understand? If you’re comfortable diving into the gems your app depends on, you’ll be able to track down and fix a whole new class of bugs that you might otherwise have to work around.

There’s no wrong way to debug an issue so long as you eventually figure out the problem. I’m going to outline how I go about tackling these kinds of issues, but if you have or find a way that works better for you, go for it. My goal is to show you how to get started debugging issues that fall outside of your application’s codebase so that you can expand the kinds of issues you can solve, as well as give you a path to start contributing back to the open source community. Where you take it from there is up to you.

Prying Things Open

I do almost all my debugging with Pry. Pry is a great debugger for Ruby that gives you a REPL with super powers.

Once you’ve added Pry to your project, put binding.pry somewhere in your code. When your app executes that line, it will open up the Pry REPL, which is similar to IRB (what the command rails console uses by default.)

For example, if you have a controller in Rails and you need to look at what’s happening inside its index action, you’ll add a call to pry like this:

class ThingsController < ApplicationController
  def index
    @things = Thing.all
    binding.pry
  end
end

With that in place, when you hit that action either with your browser or with an automated test (using something like RSpec or minitest), the execution of the program will stop and drop out to a Pry REPL. For example, when I visited localhost:3000/things with my browser and switched back to my Rails server, I saw this:

From: /Users/jardo/Codes/thing_app/app/controllers/things_controller.rb @ line 4 ThingsController#index:

    2: def index
    3:   @things = Thing.all
 => 4:   binding.pry
    5: end

[1] pry(#<ThingsController>)>

You can type any Ruby you want to evaluate into this REPL, but unlike rails console, it all evaluates as if you were running it right where the call to binding.pry is. If you want to see the value of that instance variable, you can do this:

[1] pry(#<ThingsController>)> @things
=> []

If that wasn’t the value of @things that you expected, you might want to examine the SQL that was getting run when you ran Things.all:

[2] pry(#<ThingsController>)> Thing.all.to_sql
=> "SELECT \"things\".* FROM \"things\""

If At First You Don’t Succeed, Try Pry Again

So far I’ve only shown you the features of Pry that IRB has too. Pry has four features that I find extremely handy and wouldn’t want to live without.

The first is ls. Typing ls into Pry will list all the constants, methods, variables, and instances variables in the current context. If I run it inside the binding.pry console inside my ThingsController I get a huge dump of information.