John Nunemaker offers drop-dead-simple debugging tips

(written by Lawrence Krubner, however indented passages are often quotes)

Since I’m fairly new to Rails, this kind of basic debugging advice is really helpful to me. It’s nice to know how to do everything in the simplest way, before diving into complicated IDEs that try to be helpful but actually hide too much from me.

There are all kinds of fancy debugging tools out there, but personally, I get the most mileage out of good old puts statements.

When I started with Ruby, several years ago, I used puts like this to debug:

puts account.inspect
The problem with this is two fold. First, if you have a few puts statements, you don’t know which one is actually which object. This always led me to doing something like this:

puts “account: #{account.inspect}”
Second, depending on whether you are just in Ruby or running an app through a web server, puts is sometimes swallowed. This led me to often times do something like this when using Rails:

Rails.logger.debug “account: #{account.inspect}”
Now, not only do I have to think about which method to use to debug something, I also have to think about where the output will be sent so I can watch for it.

Enter Log Buddy
Then, one fateful afternoon, I stumbled across log buddy (gem install log_buddy). In every project, whether it be a library, Rails app, or Sinatra app, one of the first gems I throw in my Gemfile is log_buddy.

Once you have the gem installed, you can tell log buddy where your log file is and whether or not to actually log like so:

LogBuddy.init({
:logger => Gauges.logger,
:disabled => Gauges.production?,
})
Simply provide log buddy with a logger and tell it if you want it to be silenced in a given situation or environment and you get some nice bang for your buck.