Codenoble

My experience with debugging code has come a long way. Many of you probably share in my painful memories of throwing echo lines into one PHP file after another. Ah, those were the bad old days.

Thankfully, we rarely ever have to resort to that in Ruby. But Ruby does have its own aspects that make debugging tricky. One of the hardest things for a new rubyist to deal with is when the problems go beyond the comfort of your own hand-written code and into the endless abyss of third-party gems. Once you've crawled your way up the stack trace and hit lib/active_support/how/many/directories/are/there/in/this/gem.rb, many throw their hands up and head to Stack Overflow. But don't click that Ask Question button just yet. Exploring other people's code (especially good code) is one of the most rewarding things you can do as a programmer and as a member of the open source community. So let's get our hands dirty and maybe learn a little something along the way.

Handy Tools

One great gem I recommend for any web project is Better Errors. When an exception occurs in your Ruby web app it gives you a great web interface with a irb-like terminal to see into each level of your stack trace. Rails has started to include something similar in recent versions but I still tend to prefer Better Errors, plus it will work on your non-Rails web apps.

Better Errors only triggers on an exception occurs. So if you want to inspect some arbitrary line of code, just add something like raise 'pry' and Better Errors will kick in.

Warning: Don't ever install better_errors in your production environment. That's a huge security risk. It should be a development only tool.

First Steps

Whenever I've got to get to the bottom of some unexpected behavior in my code, the first thing I turn to is Pry. Pry is a great tool. I can't recommend it enough. And even though Rails' new error page and Better Errors can replace it to a certain extent, I still find myself using it often.

Using Pry is simple. Add gem 'pry' to your Gemfile, bundle install, and add a binding.pry line to your code anywhere you want a breakpoint. From there you'll have a command line with the full context of your code at that point in it's execution. You can see and change anything at this point. And when you're done, just type exit and your code will continue on it's merry way.

Note: You can do things to make Pow and Prax work with Pry. But it's probably easier to just use rails server or rackup.

Digging Deeper

Using Pry is great, but what happens when you've got to dig beyond your own code. How do you add binding.pry to third-party code. Well, Bundler has a trick up it's sleeve to help you out.

With the path option you can git clone the repository to your filesystem and then change the line in your Gemfile to git 'gem_name', path: '/path/to/your/cloned/repo/'. Now just add those binding.pry lines to the cloned repo and you can dig as deep as you want.

When All Else Fails

Sometimes, Pry by itself just isn't enough to get to the bottom of things easily . A quick search for "pry" on rubygems.org will bing up pages of gems that you can use along with Pry to make your life easier. A couple that I've had good luck with and would recommend are pry-stack_explorer and pry-rescue.

• pry-stack_explorer allows you to climb up and down the stack trace to different points in the execution. Which can save you a ton of time compared to moving that binding.pry line manually and rerunning your code every time you want to poke your head some place new.
• pry-rescue will automatically halt execution when an exception is raised which can sometimes save you from having to git clone projects like I mentioned above.

So those are some of the tools and tricks I've used to get my code to "do what I mean, not what I say". Being comfortable around debugging tools and other people's code is the first step to writing pull requests to other projects. And giving back to open source is something everybody should strive for. Because let's face it, open source has given us our community and our careers. Plus hacking on open code is both fun and rewarding.