- Item 9: Set Yourself Up for Debugging Success
- Item 10: Enable the Efficient Reproduction of the Problem
- Item 11: Minimize the Turnaround Time from Your Changes to Their Result
- Item 12: Automate Complex Testing Scenarios
- Item 14: Consider Updating Your Software
- Item 15: Consult Third-Party Source Code for Insights on Its Use
- Item 16: Use Specialized Monitoring and Test Equipment
- Item 17: Increase the Prominence of a Failure's Effects
- Item 18: Enable the Debugging of Unwieldy Systems from Your Desk
- Item 19: Automate Debugging Tasks
- Item 20: Houseclean Before and After Debugging
- Item 21: Fix All Instances of a Problem Class
This chapter is from the book
This chapter is from the book
This chapter is from the book
Item 18: Enable the Debugging of Unwieldy Systems from Your Desk
Jenny and Mike are comparing notes regarding their debugging experiences. “I hate it when I work on a customer’s PC,” says Jenny. “My tools are missing, I don’t have my browser’s bookmarks, it’s noisy, I can’t access my files, their key bindings and shortcuts are all wrong.” Mike looks at her with disbelief: “Key bindings? You’re lucky, you have a keyboard!”
Indeed, having to work away from your workstation can be a major drain on your productivity. Apart from Jenny’s complaints, other nuisances can be constrained Internet or intranet access, an awkward setup (from the screen to the chair, via the mouse and keyboard), a need to travel to a humid, hot (or cold) location in the middle of nowhere, and undersized computing power. These problems are quite common and will become even more widespread as our industry embraces mobile devices and the Internet of Things. Cases where you may need to debug software away from your cozy desk and powerful workstation include cellphone apps, devices with embedded software, problems that occur only on a customer’s computer, and crises that occur in the data center. There are workarounds so that you can continue working with your favorite keyboard, but you must plan ahead.
For cellphone apps and some embedded devices, there are device emulators, which you can use on your PC to troubleshoot the failing application. However, these typically don’t offer much help in the way of debugging, other than some enhanced logging facilities. True, you don’t need to fumble with a touchscreen’s keyboard any more, but you also can’t run your symbolic debugger inside the emulator. Still, you have convenient access to the source code and your editor from the same screen, and you can quickly experiment with code changes and see the results without having to deploy the software on an actual device.
A more powerful approach is to create a software shim that will allow you to run the key parts of the application you’re debugging on your workstation. Unit tests and mock objects are techniques often used for this (see Item 42: “Use Unit Tests”). The setup typically excludes the user interface, but can easily include tricky algorithmic parts where a lot of debugging may be required. Thus, you hook up the application’s algorithms with some simple (e.g., file-based) input/output, so that you can compile and run the code natively on your PC, and then use your powerful debugger to step through and examine the operation of the tricky parts.
As an example, consider a cellphone app that imports into your contacts the pictures of your social network friends. A difficult part of this app is the interaction with the social networks and the contact matching. Therefore, your shim could be a command-line tool that takes as an argument a contact’s name, and uses the Facebook/LinkedIn/Twitter API to retrieve and locate matching friends. Once you debug this part, you can integrate it into the cellphone app as a class. Keep the ability to compile and run it again as a stand-alone command (perhaps via a main method) in case a problem occurs in the future.
For troubleshooting problems on customers’ PCs, arrange for remote access. Do that before a crisis strikes because this typically requires administrator privileges and some technical expertise. Many operating systems offer a way to access the desktop remotely, though support people often prefer the use of a dedicated application, such as TeamViewer. Also, consider deploying at the customers’ PCs other data and tools that may simplify your debugging. This could be a viewer for your application’s binary files or an execution tracer. If I’d have to choose one debugging tool to have on a third-party computer, I’d select the Unix strace or truss command. Incidentally, remote access can also simplify the troubleshooting that all of us who work in IT are routinely asked to do for friends and family.
A lot of back-end computing is nowadays done through commercial cloud offerings, which offer nifty web interfaces for debugging and console access. If the server you may end up debugging isn’t hosted on a shiny cloud but in a cold, noisy, inaccessible data center, you need to plan ahead again. If a problem occurs before the server establishes network connectivity, you normally need to access it through its physical screen and keyboard. A solution to this problem is a KVM over IP device. This offers remote access to a computer’s keyboard, video, and mouse (KVM) over an IP network. By installing, configuring, and testing such a device, you can conveniently debug problems in a remote server’s boot process from the luxury of your desk.
Things to Remember
Set up a device emulator so you can troubleshoot using your workstation’s screen and keyboard.
Use a shim to debug embedded code with your workstation’s native tools.
Arrange for remote access to customers’ PCs.
Set up KVM over IP devices to debug remote servers.