Ruby on Rails Guide to Debugging

Even the best Rails developers in the world have to debug their code from time to time. Unlike other frameworks, Rails makes it easy to debug your code, so you can limit your downtime and get your applications up and running. Debugging has never been easier!

Byebug

Let's start our debugging session by installing the byebug gem. This gem enables you to temporarily stop the code execution at a breakpoint, which is marked with the keyword byebug inside the code. When execution reaches the breakpoint, a marker will be pointing to the current line, and you will be able to type in commands.

With the byebug, you can see values inside variables defined before the breakpoint, simply by typing their name. The same logic applies to all of the methods accessible in the given code block.

This Gem offers a huge set of commands, you can find the whole list here. We will just mention the most useful ones:

• next command enables you to go to the next line, skipping all of the methods invoked by executing current line (unless inside any of them different breakpoint exists),
• step command is pretty similar to the next command, with the difference that step will go into each invoked method (step-by-step),
• break command stops the execution of the code,
• continue command continues the code execution.

All of the debugging gems provide similar functionalities but use a slightly different syntax and semantics. Another popular debugging gem in Rails is pry. If you are a beginner programmer be sure to check it out as well!

Debugging in Production

Debugging gems shouldn't be used in the production - they should be used only in the development mode. You install it as a dev dependency. ==So, how to debug in production?==

Rollbar

One way to do this is by implementing a rollbar. The rollbar provides error tracking software, and it can be integrated into ruby as well, you just need to install it. The whole purpose of the rollbar is to provide you with useful logs of errors which occurred in production.

There are multiple reasons you would want this in your application:

• It reports* all of the unhandled errors and exceptions.
• It allows manual logging.
• It stores a bunch of useful information, like http request, requested users, code which invoked an error and many more.
• It sends email notifications each time some unhandled exception happened on your production server, as well as with scrum software so that each new entry will be automatically transformed into the bug, issue or whatever notation supported scrum software uses.

Manually

If you don't use a rollbar, an alternative is to manually go through error logs when bugs happen. This approach is a bit slower since there is no notification that something went wrong, and it can be harder to reproduce the bug on your local machine just by looking at log files.

Even if there are no annoying bugs showing in your code, it is not a time to rest! To make it sure everything is still working as it should, be sure to write some test using RSpec and/or Capybara!

Tips and Tricks

• You shouldn't fix production errors directly on the production site, it should first be reproduced and fixed on the local machine before pushing to the production.
• You can fix production errors on the production site only if the error is caused by some server configurations, specific dataset or deeper code bugs from the production database.
• Backup each production version before pushing a new one, so in the case of emergency, you can simply revert back to the previous version.
• Use staging (test) servers to check and test your code in a production environment.

Hope this article will help you in your future bug hunt!

This article is originally published on Kolosek Blog.