- Read Tutorial
- Watch Guide Video
In the last guide, we walked through what it means to implement puts debugging. I also included a link to Aaron Paterson's guide where he talks about how he is a puts debugger. Additionally, he goes into much more detail on how he implements his own puts debugging kind of strategy. I definitely recommend for you to go back and read that guide.
I'm going to delete this because in this guide we are going to use the byebug debugger.
If you open up your gemfile and you come down you can see that by default rails 5 gives us access to byebug. This gem it only gets run during development and the test environment modes. It is kind of similar to what we did with puts. Except now what we can do is say byebug, this gives us a working breakpoint. If you have never used breakpoints before, they are very common in languages such as Java or any of the types of iPhone languages like Swift or Objective-C. It's very important to be able to isolate where data is coming from and then be able to work with it. Whenever you have a bug you want to know at what stage the bug is occurring.
def index @blogs = Blog.special_blogs byebug @page_title = "My Portfolio Blog" end
Let's open up Google Chrome and hit refresh, byebug works much differently than puts in how it processes the data. Instead of where puts simply ran the application and then the console printed out what we asked for it to print out. Notice that our web server is actually hanging, it is not rendering the page. What is occurring, switch to the terminal, what happens is right at the spot where byebug is called here it creates a breakpoint. What is happening is it actually stopped the operation of the application and it is not showing. It's now giving us a console where we can start typing away and we can look for anything that we want.
I can type @blogs and this brings up all of the blogs just like we did it in Rail's admin or something like that. This is helpful but we kind of printed this out when we did put. What's the big deal? We don't only have access to things such as blogs. We also have access to everything else. I could type in session and you remember when we printed out the session on the page. You have access to the session right here in byebug. You can type session and it pulls in all of the session data, you can type params and it gives you all of the params. This gives us all of the things that we would need.
To get out of byebug, I can type continue and if we come back to Google Chrome it will come back and it will run everything else.
I'm going to open up an incognito window and pull this up and let's pretend that we had an issue with our tracking system. For blogs I'm going to implement our ?q=facebook and this works and you are now on the blog layouts
Let's pretend that we had a little bug where we had created all these links for marketing purposes and instead of q we pressed r. If I do this and let's do it exactly like that. I'm going to get out of this and open it up again, the problem is the q value we tested would have already been in the session. I want to mimic that Q is not in session and that we made a mistake like putting r in here for the link. This seems to work, the page loads but come down here and you can see it's not showing our tracking link. What gives? If you see this happening you could go back and look at your links and I can promise you even though this may seem obvious it's obvious because I pointed it out. I promise that there will be times where you miss one character and you gloss over one character and that causes a bug in your application.
The way that we can figure this out using byebug is let's come into the code here and I'm going to pull this out of the index action and I'm going to put it inside of the application controller. Right here I can just say byebug and hit save. Try to refresh the page with the link. It's going to freeze and we can open up the terminal and right down here it's going to show where byebug is. Like I said, we could type in session and there is no session yet. If I do params it hasn't gotten to the stage of params. The reason why I'm starting here is because I want you to kind of think of this methodically. Don't just stick byebug anywhere. Have a plan for where you're putting it. OK params are not available yet for the application controller, that is perfectly fine.
I'm going to delete this and I'm going to go to the blogs controller. we are on the blogs index page but let's put byebug back here and come back to the terminal and type continue. Come to the browser, hit refresh again and it goes into its hang mode here. Now if I type session, this works. If I type params this works, look at that, that is our problem right there. We have "R" for our params.
Let's pretend that we didn't see that. The next thing that I might do is I would come in and I could open up the code for our tracking system. For set source, I can look up set source and I can do exactly what we have going on right here. Except I may leave out the if statement and just copy this. Come to the terminal. Paste this in. And that shows me that's nil. That tells me that's what the problem is.
The session source is not being set because params queue isn't set and we can filter this down even more. Copy params Q, OK that's nil and then take a look up here. OK that is the problem. It is set to R. Then you can come back. Fix this little link. Now everything will be working. We can say params q and there we go. It's showing Facebook.
That is how you can leverage byebug to be able to access data and how you could use it to perform debugging on our session tool.
Byebug is fantastic, it ships with Rails. Tons of developers all over the world use it and so it is a great option. I use it quite a bit myself especially because it's nice and handy because it ships with rails.
In the next guide, we are going to go through another option in the debugging sphere and it's one of the most popular tools out there for debugging and it's called pry.
I will see you in that guide.