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](https://kolosek.com/rails-bundle-install-and-gemfile/). 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.*

![byebug](https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/ff3fb15714e3dfd81f497a25b86c2d30/byebug.png)

This Gem offers a huge set of **commands**, you can find the whole list [here](https://github.com/deivid-rodriguez/byebug#byebugs-commands). 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](https://github.com/pry/pry). If you are a [beginner programmer](https://kolosek.com/ruby-programming-beginners-guide/) 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](https://rollbar.com/). The **rollbar** provides error tracking software, and it can be integrated into ruby as well, you just need to [install it](https://kolosek.com/rails-bundle-install-and-gemfile/). The whole purpose of the rollbar is to provide you with useful **logs of errors** which occurred in production.

![rollbar](https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/ee89a254dc51999c69950074d18eae25/rollbar.png)

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](https://kolosek.com/rails-rspec-setup/) and/or [Capybara](https://kolosek.com/rails-capybara-setup/)! 

### 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!

**Hunting bugs or hunting for new articles, everything can be an adventure once you subscribe!**