Debugging Ruby on Rails

Ruby on Rails gives us so much out of the box but there are times errors occur or we need to re-invent the wheel for a specific feature of some type. This video/article is my own take on debugging ruby on rails.

If you’ve developed with Ruby on Rails before you probably already know it is a command line driven environment where you use “generators” to create an element within your app. Everything from the creating database tables to scaffolding action views is supported. For a quick intro about the Rails CLI check out another article I wrote called Understanding the Ruby on Rails CLI.

The Ruby on Rails console (irb)

With the irb console environment, you can traverse your data to your heart’s content. Accessing it is as simple as running rails console inside your application via your terminal of choice. There you can create queries of many varieties to inspect the type of data you’re after and/or modify it directly.

A fun hack is to pass the flag --sandbox to when you run rails console. This will perform “fake” changes to your data but ultimately rollback anything you manipulate. This might be worth running in the production environment to try to inspect errors before you’re positive of a change you’ll commit to.

Logging

It’s pretty obvious when you start a local version of your rails app that you’ll see an active list of everything happening in your terminal. This alone is a huge help in identifying requests, params, and more when performing operations on the front end. I’ll often use logs to verify stripe payment data during a POST method as I’ll need those params to pass through to the stripe gem and ultimately make a charge on a given thing I’m selling to a user or subscribing them to.

The <%= debug(object) %> method

This is a life-saver for me when it comes to outputting data on a front-end view.

Say we have an @article instance method at our disposal. In the show view we could add the following:

<%= debug @article %>
<p>
  <b>Title:</b>
  <%= @article.title %>
</p>

This would output something similar to the following:

--- !ruby/object Article
attributes:
  updated_at: 2008-09-05 22:55:47
  body: It's a very helpful guide for debugging your Rails app.
  title: Rails debugging guide
  published: t
  id: "1"
  created_at: 2008-09-05 22:55:47
attributes_cache: {}


Title: Rails debugging guide

debug renders our instance method as yaml which is much more readable when trying to debug.
This is great for instances where you might need to get nested data or remembering the name of a field for example. I use this all the time.

Web-Console gem

The web-console gem is a useful tool that makes an appearance on any error view you get in your Rails app. You can add <% console %> in your view to get the console to appear. Where you add it really doesn’t matter.

If you find yourself debugging a lot and would rather do it in the browser, web-console gives you an entire CLI in your views. I don’t make a ton of use of this but I do feel good about it being there by default in Rails apps for those that may require it. Ultimately it’s less configuration which is the essence of the Ruby on Rails framework as a whole.

byebug gem

The byebug gem takes debugging to a whole other level. Think of it as a way to add breakpoints within your controllers as bugs arise. Byebug allows you to go step by step to see where things may or may not be going well with your ruby code. This too comes by default in Rails in your development and test groups inside the Gemfile.

The video above shows off its functionality. You can virtually pause your app on command to debug a given instance of some buggy code.

Pry Gem

The pry-rails gem is a useful replacement for your default Rails irb console. Pry gives you a bunch of methods for exploring your app (i.e. show-routes, show-models, etc…) and syntax highlighting. Curious why you’d use pry? Check out this article.

Closing

There is no perfect way to debug. Being so convention-based, Rails doesn’t have a “defined” way you should debug your code. This is a good thing I think because many developers approach errors differently. I’m a very visual person so I often reach for the debug helper and my logs to find out what went wrong (or right) when developing an app. Use this stuff to your advantage! The more you do the more quickly you will be able to resolve future issues that may seem familiar.