We look at a few different ways Ruby on Rails developers can debug their code, including methods built in to Ruby and external, third-party tools.
Join the DZone community and get the full member experience.Join For Free
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!
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 point 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:
nextcommand enables you to go to the next line, skipping all of the methods invoked by executing the current line (unless different breakpoints exist inside any of them).
stepcommand is pretty similar to the
nextcommand, with the difference that
stepwill go into each invoked method (step-by-step).
breakcommand stops the execution of the code.
continuecommand 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 development mode. You install it as a dev dependency. So, how can you debug in production?
One way to do this is by implementing Rollbar. Rollbar provides error tracking software, and it can be integrated into Ruby as well, you just need to install it. The whole purpose of Rollbar is to provide you with a useful log 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 requests, 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 the supported scrum software uses.
If you don't use 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.
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, a 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!
Published at DZone with permission of Nesha Zoric , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.