At the Forge - Debugging Rails Applications
and you're set to go!
Under most circumstances, ruby-debug will do absolutely nothing. It won't affect your code, execution or anything else. But if you drop the method:
into your Rails application, the application will halt when it gets to that line and will give you a true debugger, looking something like GDB. You get a few lines of context around the current line, you can print current values (or any other expression) with the p command, and you can move forward in the program on a line-by-line basis with the n command. Your Web browser, which presumably triggers the debugger when it invokes a particular controller action, will hang while you are using the debugger, stepping through the code and inspecting the environment.
To explore things more fully, you can drop into irb at any time, getting another version of the Rails console. This is good when you want to do something more than just examine variable values—exploring the database, for example, or drilling down into the innards of the system.
Note that because of the nature of ruby-debug, it's really only practical for use with HTTP servers that you run in the foreground, such as WEBrick. But there's nothing stopping you from having two different application instances (one using Phusion and one using WEBrick) running in the same environment or working on the same database—just make sure to run them on different ports and be sure to keep track of multiple tabs that you might have open in your Web browser.
I've only begun to use ruby-debug seriously in the past few months, and I'm already wondering how I ever got along without it. If nothing else, exploring my application from the inside gives me many insights that I would never have had otherwise, and it gives me a chance to look at things actively, rather than just using logfiles.
Finally, you might want to try one or both of the commercial Rails services that have sprung up, and which provide monitoring and notifications for Rails applications. I should make it clear that both of these are hosted by for-profit corporations, and that although they are offering free versions of their products, their ultimate goal is presumably to make money.
New Relic RPM is a performance monitor that you install into your Rails application as a plugin. Every few minutes, the plugin reports your current application status back to New Relic's servers, where the data is then made available in an easy-to-understand format. New Relic's basic offering is free, and although it is much more limited than the commercial versions, I have found it to be highly useful in giving me a snapshot of the current system performance and bottlenecks. If and when your site brings in some money, it might be worthwhile to pay for one of New Relic's commercial products, which provide not only an indication of controller and server performance from the last 30 minutes, but also from the last few weeks, as well as more detailed analyses of memory, database and CPU use, among other things.
Hoptoad, a service run by Thoughtbot, is similar to New Relic RPM, in that it has a free version as well as a commercial one. Hoptoad is similar to many notification systems, and it sends you e-mail when an exception occurs in your application. However, it keeps track of the entire stack trace and request context, and it also keeps a log of it on Hoptoad's Web site, keeping similar errors together. You also can indicate when you have resolved a problem, using it as a primitive sort of bug-tracking application. (Although I find it annoying that you receive e-mail only the first time a particular error manifests itself, until you mark it as resolved.) Hoptoad has made inroads into many Rails projects on which I have worked, and I have found it to be more reliable and easier to use on my projects than simpler exception-notification systems.
Debugging Web applications has never been easy, but the Ruby on Rails community has managed to create a set of useful and powerful tools that can make a big difference to average Web developers. Whether you are a new developer or an experienced one, having these tools in your toolbox can make you more effective at finding bugs and at getting your application, bug-free, out the door for your customers.
A good introduction to the whole subject of debugging in Rails is in the Rails Guides series, specifically the article on debugging: guides.rubyonrails.org/debugging_rails_applications.html.
A slightly out-of-date tutorial on ruby-debug, but one that is straightforward and easy to understand, is by Patrick Lenz at articles.sitepoint.com/article/debug-rails-app-ruby-debug.
Amy Hoy, as often is the case, has many entertaining and useful things to say on the subject: slash7.com/articles/2006/12/21/secrets-of-the-rails-console-ninjas.
Reuven M. Lerner, a longtime Web/database developer and consultant, is a PhD candidate in learning sciences at Northwestern University, studying on-line learning communities. He recently returned (with his wife and three children) to their home in Modi'in, Israel, after four years in the Chicago area.
|diff -u: What's New in Kernel Development||Sep 04, 2015|
|Android Candy: Copay—the Next-Generation Bitcoin Wallet||Sep 03, 2015|
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
- diff -u: What's New in Kernel Development
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- The True Internet of Things
- September 2015 Issue of Linux Journal: HOW-TOs
- Firefox Security Exploit Targets Linux Users and Web Developers
- Concerning Containers' Connections: on Docker Networking
- Android Candy: Copay—the Next-Generation Bitcoin Wallet
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects