My PC wouldn’t boot, didn’t even make a sound. I traced the problem down to a particular mounting screw, but there was nothing to indicate that this screw was problematic. It was a perfectly fine screw, correctly installed in the right place. How did I figure this out? Debugging!
Read more on Debugging Techniques: #1 Break the System into Small Pieces…
debugging
Debugging ES6 Code in Node.js
I recently decided to use Node.js for my current project, and I also thought it would be a good idea to start off using ES6 (properly known as ECMAScript 2015). ES6 was a major addition to the language, and it was just formalized in June 2015. Since then, there has been a lot of effort to add ES6 compatibility to browsers (and Node.js). Until there is unanimous support for ES6, which will likely be quite some time yet, developers who use ES6 are required to run their code through a transpiler in order to transform it into valid ES5 for browser compatibility.
Read more on Debugging ES6 Code in Node.js…
Improving Analysis with C# 6 Exception Filters
C# 6 recently added support for exception filters, which enable a few helpful scenarios. In this post, I’ll demonstrate how they can be used to improve debugging and crash dump analysis. Read more on Improving Analysis with C# 6 Exception Filters…
Spying on Your WPF Applications with Snoop
If you’re developing WPF applications and do not have Snoop installed; install it now. I’ll wait. Installed? Good.
Snoop is an open source tool for spying and debugging a running WPF application. It can be used to inspect your running application and make changes while your app is still running. I’ve found it to be very useful for finding missing bindings and tweaking layout parameters when you can’t use Designer. (don’t ask, that’s a blog post for another day.)
Here are a few tips to get you started:
Selecting Your App
After installing and launching Snoop, drag the cross-hairs from the Snoop window to your WPF application. You’ll see your application tree on the left and a property editor on the right for whatever component you have selected.
Debugging with Ember Inspector – Ember’s Chrome Plugin
When creating a single-page site using a technology like Ember or AngularJS, debugging code can become an issue. Firebug and the Chrome debugger quickly lose their power as you have to dig through Ember models and other representations of your application.
Thankfully, from the creators of Ember comes a plugin for Chrome debugging — Ember Inspector — which gives you quick access to Ember objects and data.
Tree View
The tree view visually allows you to walk through the different parts of your Ember application. This is useful for debugging but also helps to gain an understanding of how an Ember application is built up.
Read more on Debugging with Ember Inspector – Ember’s Chrome Plugin…
Tools for Debugging Running Ruby Processes
Let’s assume that we have a daemon running on some kind of POSIX system written in Ruby that works great most of the time, but every few months gets “stuck” and needs to be restarted. We might tolerate this failure rate, or we might set up something like monit to automatically restart the daemon when it becomes “stuck.” But wouldn’t it be better to get to the bottom of the issue?
Next time the daemon gets stuck, what tools might we use to figure out what’s happened to it? If you’re still developing, you might have included the pry gem or you might even be using pry-rescue to catch exceptions. But on a production system, you probably won’t have such luxuries available.
Luckily, since a Ruby process is still a process, there are actually quite a few POSIX utilities at our disposal. Let’s find the PID of our our process and see what we can learn. Read more on Tools for Debugging Running Ruby Processes…
Easier Debugging with capybara-screenshot
This is one of those Rubygems I wish I’d known about a long time ago: capybara-screenshot.
As the name suggests, when a capybara test fails, the gem will automatically take a screenshot of what the browser rendered. I don’t normally need this level of information, as the error is usually fairly obvious. But a handful of times now, the extra information has helped to work through those times where I’m scratching my head and can’t figure out why a test is failing.
I did change the stock behavior of the gem a bit — I don’t have it automatically take a screenshot. Since I don’t normally need that, I didn’t want it cluttering up my filesystem. Instead, I tag scenarios with a little piece of metadata when I want a screenshot. Here’s how I did that:
Troubleshooting Yourself in the Foot
What makes some programmers better than others? I’m sure you can find a couple of popular software industry bloggers that have strong opinions about this, but I’m more interested in specific empirical answers to the broad question.
I once found some answers in a humble-looking library book, titled _Empirical Studies of Programmers: Papers_ by Elliot Soloway. Read more on Troubleshooting Yourself in the Foot…
Perspectives on Bugs
There are two perspectives on bugs and every software company has to juggle them. From a user’s perspective, a bug is unexpected behavior. From a developer’s perspective, a bug is unintended behavior. There’s a very subtle difference here, but it’s important to consider and value both perspectives.
The Destination
The reputation of an application relies on the user’s perception and expectations. The code can be ugly, unmaintainable, inconsistent and flat-out wrong, but it can all work together and make perfect sense to the user. It’s also easy to imagine a scenario where the code perfectly conforms to elegant logical rules that simply don’t match the user’s logic. From the user’s perspective, the second example is buggy, and the first is correct. At the end of the day, this is all that matters.