How to Utilize Puts Debugging in Rails
As an introduction to debugging in Rails, we're going to analyze how to utilize the "puts" debugging process to fix a data query bug in our application.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

To start this section on the course, I'm going to open up pivotal tracker and drag the debugging section and click start. Let's see what kind of tasks we have. This is going to be a little bit different type of section than the other sections. We were able to build features and add on to the app. This time we're going to take a little bit of a step back because this is going to be a very important item. The reason why I'm including this in the course isn't to build a specific feature but instead, it is to help give you a valuable skill.

One of the most critical items that developers and hiring managers are looking for when they're looking to hire a new developer is how good are they at debugging. If you're a good debugger, you're going to be able to work through problems. If you just stare at the screen when the application isn't doing what you want then you are going to struggle. I want to teach you in this section is what you can do when your application isn't doing exactly what you expected.

We're going to cover

  • puts debugging
  • byebug
  • pry
  • error management

Let's start off with the most basic one.

Switch to the terminal and let startup the rails server. I'm going to switch into the codebase.

Puts debugging is a very old school way of debugging an application. It's OK for certain circumstances, however, I think you're going to see that there are much more advanced ways of doing it.

With that being said, Aaron Patterson who is probably one of the Rails developers I respect the most in the world, claims that he is a puts debugger.

I'm going to open up app controllers and open up the blogs controller. In the index action let's imagine that we have something that was not working properly such as something like the blog.limit(2). If I save this and I run this in the application, you can see it only pulls up 2 blogs.

Obviously, we introduced this kind of bug into the application but this can give us an idea of how we can figure it out. Imagine that you expected to see 20 blogs here but you only saw two. Inside of the index action, you could put some put statements

def index
    @blogs = Blog.limit(2)
    puts @blog.inspect
    @page_title = "My Portfolio Blog"
end

You could do this and you can test this out is by coming back to the page hitting refresh. Then coming to the terminal, you can see that we have to kind of figure out where this code is actually being printed out.

large

You can see it is being printed out but it's not very clear. It kind of gets mixed in with the rest of the code and all the other things that are being put in the log file in the terminal.

More of a standard way of doing this is to put some things around this so I could say

def index
    @blogs = Blog.limit(2)
    puts "*" * 500
    puts @blog.inspect
    puts "*" * 500
    @page_title = "My Portfolio Blog"
end

If I come back and hit refresh on the index page and come to the terminal.

large

Now it's much more clear exactly what's going on. We have all of these asterisks so we know that that puts blog inspect is going to lie between these two items. We can say that OK this is the data coming through. The other thing this is how we could figure out the bug is let's say we have select blogs from blogs, everything here looks normal except oh wait a second there is a limit statement. In the limit statement says two and that is the problem. Obviously, you can see that the limit statement is right here. Imagine that we did something like this.

Pull up blog.rb and let's say that we created a scope. which is something we'll walk through how to do later on but for right now we'll give just a base case. I'm going to say

def self.special_blogs
  limit(2)
end

We can call this method right here (blogs_controller.rb) @blogs = Blog.special_blogs this is a very standard way of having these scopes.

Hit refresh, everything's still working. If we come in the terminal here we can see.

large

OK wait, here is this limit statement and it's limiting it to two. It's a little bit more practical because here you wouldn't have the code right in front of you. Then that would tell you OK I need to come look at the scope for special blogs and fix it to say

def self.special_blogs
  all
end

If I come back, hit refresh, now we have fixed our bug.

That is how you can implement puts debugging. There are a number of limitations to this. One is that you can really only pick out certain items that you print out and you have to do all of it manually. I had to come here, I had to grab blogs.inspect type everything out and it worked in this one case but in most instances, this is not the best way to do it. I will show you in the next few guides some other more automated more modern ways of performing debugging.

With all that being said, this is still a nice skill to have. If I'm in a rush and I know what element that I want to go take a look at then I can just slide it right in here and it's no problem at all.

That is how you can become a puts debugger.