February 20, 2015 by Daniel P. Clark

Some Basic Ruby Tools for Sniffing out Errors

Needing to know what’s going on under the hood is a big part to solving problems and challenges.  For the longest time I only ever used print statements to output to the console the state of something at a specific point.  That’s all I ever used in Python.  But sometimes you need to do a bit more within a specific problem area.


Pry is an excellent tool that will let you stop the code right where you put it and then give you an irb console to experiment with.  This is helpful for experimenting when something doesn’t work to try and find what does work.  You can learn all about how to use it at: http://pryrepl.org/  Basically to have your program open up an irb shell in the middle of the code you use binding.pry


I have found that sometimes when calling pry from my Rails project with binding.pry that it doesn’t work.  This lead me to lookup the Rails documentation on debugging and they recommend a gem called Byebug.  It works in a very similar way to pry, but it worked where pry didn’t.  You just put byebug in the code where you would have put binding.pry.  One of my favorite features of Byebug is that you can step through your code in the current scope by typing next and hitting the [enter] key.  You can see more info at: https://github.com/deivid-rodriguez/byebug


Pry has a lot of addons/pluggins available for it that can improve your debugging/experimenting experience.  pry-byebug is a gem that allows you to combine the best of both worlds of pry and byebug.  See the git repo at: https://github.com/deivid-rodriguez/pry-byebug


I haven’t branched into the realm of threads much.  But when running tests on a project they each run in their own thread.  Pry and byebug don’t break open with your terminal in this situation.  This I found rather annoying.  I haven’t found the solution to this quite yet, but I have found an equivalent solution as printing current state to the command line.  I use system alert messages to print out whatever variables I need to know.  On my Ubuntu box the command to send messages is notify-send.  So wherever I want I put in back-ticks to run a system command and put my string in.

`notify-send “My custom message #{my_var_1} and #{my_var_2}.”`

This queues the messages up to pop up one at a time.  The alert messages are only so many characters; probably between 180 to 300 characters.  I don’t see in the documentation any way to make them longer, but it’s more than enough for me.  The messages may go by too quickly, in that case add a time option with -t <milliseconds> and your good.

So now you have a modern puts test for threads!


If you’re using rails than you’re probably already familiar with the better_errors gem.  It will let you see your Rails environments state at the point of when an error was raised.  When used in combination with the binding_of_caller gem you get an interactive irb prompt in the browser where you can test and experiment as you would in irb.  You can check it out at: https://github.com/charliesome/better_errors

Have Suggestions?

I’m sure there are plenty of other tools out there, loggers, messaging services and other thread safe debugging tools.  If you know of any good suggestions then please leave a comment with some detail about it.  It will be most helpful to me and to others who read this.

I hope you enjoyed this!  Please feel free to comment, share, subscribe to my RSS Feed, and follow me on twitter @6ftdan!

God Bless!
-Daniel P. Clark

Image by trpnblies7 via the Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic License.

P.S. I found en excellent conference talk on using Pry