How to Handle WTFs

On today’s episode of Ruby Rogues we are chatting about WTFs. On our panel we’ve got Dave Carmona, Brian Hogan and I’m Charles Max Wood. We talk a bit about some of the recent WTFs we’ve encountered and some of our tricks for handling it, including talking to a Rubber Duck. It’s a fun episode so check it out!
WTF’s in Two Flavors

Charles starts out the episode inquiring to the panel about two different kinds of WTFs. The whats and the whys. WTFs that happen and developers don’t understand what the WTF is, and then on the other hand WTFs that happen and the developer doesn’t know why it’s happening.

Unreadable Perl and the Rubber Duck

David talks a bit about how hard it is sometimes to read and understand what is happening with Perl code, even if you wrote it yourself. Sometimes debugging Perl codes many years later, running into syntax errors end up being a ‘Why’ WTF. He introduces a method to use for ‘Why’ WTFs that he calls the ‘Rubber Ducky Debugging’ method. The ‘Rubber Ducky Debugging Method’ is when you place a rubber duck on your desk, and when you encounter a WTF you can simply talk through the issue to the duck to help you think through your issue. Brian and Charles add that this method works fine with real people as well and have done it many times with their wives, even for issues that don’t involve code.

Blaming it on Past Brian

Brain mentions that sometimes when working with someone else’s code, it’s easy to blame the previous developer. Unfortunately in his case, Brian finds that “Past Brian” has often been the culprit.

Dave and Code he Doesn’t Understand

When encountering classes that are really big with many different methods, find the entry point. If it doesn’t have a traditional initializer or call method for the entry point, you can look around other relevant parts of the code to try and figure it out. Sometimes if it’s obfuscated, you can go through variables and rename them to more relevant names to identify what they are doing to help understand the method at hand.

Puts Debugging

Aaron Patterson had written an article on his blog about ‘Puts debugging’ that turned Dave onto the the untraditional debugging method. Dave will sometimes write a separate debugger class to separate puts into a different log to keep it organized.

Brian’s Version of Puts Debugging

Brian mentions that when working on a rails application he will sometimes raise the object he wants to inspect. Errors in Ruby are often something you wouldn’t expect and being able to quickly inspect the object using raise .Using raises the whole stack including the object, session, and cookies , etc.

Dave’s Ruby Lifesavers

Dave also adds that adding the gems to your development better_errors, and then en binding_of_caller are lifesavers. It allows for a more interruptive session with raised errors. Also, in Rails 4 the console feature was added, allowing you to tweak things and play around to debug. Also, Pry is really useful for loop through and investigate. Dave also notes that Pry, while being a great tool, can sometimes be a bit annoying if you have a large number of loops.

Crazy Bug Story - Brian

Brian talks about how in Elixir the declaring of methods is very similar to Ruby but at the end of Elixir method calls you add keyword do. If you do this in Ruby, the interpreter’s error message is unusual and doesn’t give any information that helps you find the issue, making it very hard to find the issue. This could be very time consuming for the debugger. He adds that having a second pair of eyes helps with issues like these.

Crazy Bug Story - David

David talks about working on a personal project late into the night. Using Rails 5.1.1, he thought that maybe his issue with the enumerators. He considered that maybe the issue was with Rails 5.1.1 being that is newer. To test to find out if he caused the error, he recreated a simple bit of code that uses enumerators and saw that it worked, then created the same projec