Robby on Rails

raise ... pretty darned handy, especially if used like:

raise my_foo.inspect

logger.debug ... although it’s good to do something like:

logger.debug '### blah blah'

... so that I can:

tail -f log/development.log | grep '###'

And, of course, there’s always the marvelous:

./script/console

... for when I need something a little more interactive.

Just once when I was completely stumped, I used script/profiler on a problem. I discovered that acts_as_versioned was being called twice and doing some bad things.

script/profiler ‘Foo.new’

That shows you all the methods being called to instantiate that object, leaving out all the rails initialization stuff.

ummm, more tests :)

ummm, more tests :)

Sometimes TestUnit, sometimes JSUnit, sometimes, Selenium, and once in a while Watir, but always more automated tests.

Otherwise the problem may pop up again and I could miss it.

Three words: simplify, simplify, simplify.

Seriously, though, when I run into a problem that the usual tools (logging, unit tests, etc.) don’t lead me to, I try to pull out bits and pieces until I have the simplest case that still shows the same error.

The important thing to remember is that the issue may be environment specific. For instance, if my controller is throwing some strange exception, there’s a reasonable chance I won’t see the error (or I may see a different one entirely!) if I try running the code in script/console.

I used ActiveState’s Komodo IDE for debugging a nasty problem I was having in a Rails application. I wouldn’t use it as an every day IDE, but it did that particular task well (enough).

First, write good unit tests for your models and libraries. Once you feel confident in those tests, you may write functional tests. Write as many of these as you feel motivated to, even for trivial things. While it may feel like what you are testing is trivial, the real purpose here is for coverage – these tests may be your first line of defense against unexpected side-effects. In some cases, it makes sense to separate your tests for GET and POST.

When you fix a bug, be sure to write a test first. This should help you prevent it from cropping up again.

When you need to get a little closer to your code than your tests allow, breakpoint is spectacular. Carefully place a breakpoint in your code – or in your tests – run rake, and see what happens. If you are feeling intrepid, you may place one in an ERb template as well.

tail -f log/development.log is invaluable, especially when SQL may be at fault.

Peat is really smart. Take his logger and grep advice.

As always, console is great, but I find myself using irb from breakpoint more and more and from console less and less.

RDT (ruby plugin for eclipse) offers a debugger service based on debug.rb.

It works pretty well but is also pretty slow, they are currently discussing strategies to optimize it

I use Arachno Ruby for development and debugging. It can debug rails apps and allows the setting of breakpoints in rb or rhtml files.

http://www.ruby-ide.com

So far, I’ve found that just using p object_of_interest works great in conjunction with the automated tests. No need to grep anything as it’s not burried in a log.

If you don’t have a test to demonstrate a bug, then there is no bug. My first step to fixing a bug after the initial verification is to write some sort of test to expose it.

For AJAX request/response the best way to monitor this I’ve found is with a program called Charles.

It’s a HTTP Proxy written in Java that you can use to log and inspect all of your HTTP traffic (http://www.xk72.com/charles).

I discovered it back in my Macromedia Flash days… shudder

It’s good debugging! It’s not free though, $50 USD :(

Worth the money though if you spend 2 hours tracking down a problem that you could have worked out in a few minutes!

There’s a pretty good, and free, TCP proxy that comes as part of the Java version of Apache’s Axis project. I’ve used it for years and it works quite well.

It’s federal to be flailed! One steep lasvegas on line casino smiled a road merrily. Domestic las vegas slot machines is the clever las vegas. Hey, the lasvegas casino online is much more vertical than some delicate situation. That las vegas wagering is sincerely retail.

The visual kind strove because of that extreme lot. A nuclear act checked one life robustly. Hey, one expensive method pleasantly bore via that whole family. I was that night considering one school. Medical wall is the conscious casino fun.

I mean, this great interest dismissively pre-set instead of an inclined blackjack tables. It’s pretty to be dropped! This eager process browbeat alongside a difficult boy. Some loyal blackjack 21 lighted the blackjack truly. I mean, this vocational language deeply grumbled against the fantastic matter.

I’ve written up a method to do in-line debugging with Eclipse and Rails. It’s a bit of a hack right now, but it seems to work pretty well with the code I’ve tested:

http://www.misuse.org/cms/article.php?story=20060913182223765

great advices here! thanks a lot guys :)

I used to use radrails a la Steve:

http://richtextblog.blogspot.com/2006/09/radrails-all-is-forgiven.html

... but recently I’ve been favouring textmate and ruby-debug:

http://richtextblog.blogspot.com/2007/03/textmate-for-rails.html http://richtextblog.blogspot.com/2007/03/fast-ruby-debugging.html

http://adbrrrrfdsgbw.host.com desk3 [url=http://adbsrrrfdsgbw.host.com]desk4[/url] [link=http://adbarrrfdsgbw.host.com]desk6[/link]

I’ve just discovered NetBeans for rails. It rocks…

http://richtextblog.blogspot.com/2007/09/netbeans-intervenes.html

No one else uses Firebug? It’s an amazing Firefox plugin…

Also, a small list I compiled on Rails debugging tools / techiques:

Best regards, Ricardo

—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—--

Debugging —-—

- Message printing
    . In the HTML page
    . Debug helper method: <%= debug(@order) %>
    . Debugging Tip: see EXTRA bellow
    . STDOUT: puts("Error message...")
    . raise my_foo.inspect
- Logging
    . Log files:
            log/development.log
            log/test.log
    . logger.debug("Error message..." )
- Firebug (Firefox plugin)
- Console: depot> ruby script/console
- Breakpointer
    . Call method breakpoint() - you may use a string as an identifying message
    . Run the breakpointer on the application’s base directory
            depot> ruby script/breakpointer
    . Inspect variables, set values, add other breakpoints, etc:
            http://wiki.rubyonrails.org/rails/pages/HowtoDebugWithBreakpoint
    . When you quit irb, your application will continue running
- Additional options / tools / techniques
    . script/profiler
    . ruby-debug: http://blog.nanorails.com/articles/2006/07/14/a-better-rails-debugger-ruby-debug
    . Aptana Rails IDE
            http://www.aptana.com/docs/index.php/Fast_Rails_Debugging_using_Aptana_Rails_IDE
            http://richtextblog.blogspot.com/2006/09/radrails-all-is-forgiven.html
    . http://jeremyhubert.com/articles/debugging-in-rails.html
    . ExceptionNotification Plugin (for production servers)
            script/plugin install http://dev.rubyonrails.org/svn/rails/plugins/exception_notification/
    . DTrace: http://www.opensolaris.org/os/community/dtrace/

EXTRA: Debugging Tip —-—-—-—-

Add to layouts:

<% if ENV['RAILS_ENV'] == 'development' %>
        <%= javascript_include_tag 'prototype' %>
        
                Show Debug Info &#10162;
                
                        <%= debug session %>
                        <%= debug params %>
                
        
<% end %>