Rails et al

When I first started working in Rails, I went with TextMate on my Mac.  I really like TextMate, but trying to debug problems was really, really painful and time consuming at first.

A few tips would have gone a long way:

• I really did not understand how to use “script/console” to debug problems; now, I use it all the time.
• I did not know how to use “yell”; instead, I spent a lot of  time searching for statements in really large log files.
• I did not know how to leverage the console to see what was happening and which controllers were getting invoked.  Once I understood these things, debugging got to be a lot easier.

Now, I really do not miss having a debugger. As someone who has used Eclipse and similar environments for the last 15 years, I find this shocking!  I did a trial of Aptana, and after that was unable to re-install the non-professional version.  I now have Rubymine, but I rarely need debugging help.

Tonight, however, I needed a debugger to be more productive.  Instead of firing up RubyMine, I decided to give RDebug a try.  Though it is limited as a command-line debugger, I am very impressed.

I simply added require ‘ruby-debug’ to the top of my file.  For my breakpoint, I added the statement debugger, and then executed the program.  When it hit that line, it dropped into a command-line debugger.

There are a number of commands, but the following took care of what I needed:

• (p)rint.  Prints out variables:  p foo.id
• (n)ext.  Kind of like step over
• (s)tep.  Kind of like step into
• (c)ontinue.  Self explanatory
• (e)valuate.  Self explanatory

At least 80% of the time, you won’t need a debugger.  When you do, the above should cover what you need for 80% of that.  Which means you should rarely need a more powerful debugger than ruby-debug.