Favorite Rails and JavaScript debugging tips

Rails
1

Rails debugging.

Starting with the debugger is often WAY to slow. Way faster to put in print statements, but sometimes you want to poke around.

Here’s a cool hack: Add an intentional syntax error, and get the better_errors console to poke around!

WAY faster than debugger!

And check out pry.

See my Pry tips here:

2

@dylangrafmyre Pointed me to this article, which has lots of great commands to use in the better_errors console.

http://www.shopify.com/technology/17370004-theres-more-to-ruby-debugging-than-puts

3

My favorite debugging resource is a little book called Debugging, available from Amazon. It contains 9 rules that cover any situation where you have to find and fix a problem, but of course, it specializes in software debugging. Info about the book, including a poster that lists the 9 rules, is available at http://debuggingrules.com.

1 Like
4

Most of the time using print statements seems to be the fastest way to debug things, however sometimes it really is worth rewriting part of the code if the error just seems to make no sense. A few times I accidentally used ‘=’ instead of ‘==’ and that is one of the simplest errors that cause cause a lot of wasted time.

5

Not quite about debugging, but about testing: http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf . That article goes very deeply into the pragmatics of what should be tested and why, and is an excellent read.

6

I’ve been using this gem a bunch, and it’s very useful when it’s too slow for the RubyMine debugger to start.

7

Here’s a great article summarizing many tips that I already use and that I have to go over with newer developers:

Debugging Rails Applications in Development

8

Good tip from Efficient Rails book.

Screenshot_7_4_15__10_30_AM.jpg1025×1419 258 KB

9

Be sure to see this topic:

10

This is a useful article on the topic:

The Art of Debugging

I missed these shortcuts in Chrome:

$_ - the result of the last expression
$0 - the currently selected DOM node in the elements panel

There’s many other blackbelt JS debugging tips in the article.

11

Here’s one for when you’re really stuck tracking down why a test or web request fails. I had to use this for figuring out an very hard to debug Rails 3 to Rails 4 migration bug. I’ll use RAILS_3 and RAILS_4 to distinguish between the two branches of code that I’m debugging.

  1. Be able to reproduce the passing operation on RAILS_3 and see the failure on RAILS_4.
  2. Clear out the logs on both both envs with rake log:clear
  3. Set both envs to have logging set to :debug. Be sure that you can see the SQL being logged.
  4. Run both branches, and save the log results of running both (and only the single operations) to 2 text files, which we’ll call rails_3.log and rails_4.log.
  5. Open those files up in your text editor and search and replace using this regexp to strip out the leading timestamps: ^\[.*\]. This filters out messages like this:
[DEBUG 11-18 14:06:53.463]    (5.6ms)  TRUNCATE TABLE `versions`;

Depending on how you’re doing logging, you might need a different regexp. The key is to strip out anything that causes every line to differ.
6. Then use your favorite diff tool to compare the files. I use ediff within spacemacs. Any good diff tool should work.

And then you’ll be able to see some very interesting details regarding where your positive case differs from the failing case.

I’ve resorted to this when using the awesome pry debugging tools fails to help me successfully dive deep inside of the Rails save process.

Here’s my overall order of debugging:

  1. Print statements (see above tips), especially “fenced debug statements”.
  2. Examining the failing log file in addition to what’s on the console.
  3. Using pry especially with my setup, which I’ve shared.
  4. Log comparison discussed in this post.
12

Here’s a couple more bullets for debugging:

  • You can put binding.pry inside of a Rails view.
  • You can put binding.pry inside of Rails libraries.

The same goes for fenced debugging statements.

Later, be sure to undo changes. You can run gem pristine <gem_name> to get back to the correct version.

13

Here’s a good article:

Ruby Debugging Magic Cheat Sheet by Schneems

I often accomplish much of what’s in this article using pry.