Keeping an Eye on Your Development

In case you didn’t know, a Debug Toolbar (I don’t know if that’s the universal name for it but it makes sense to me) is a nifty little widget that allows for easy access to all sorts of info on your web program. Since I work primarily in php that’s what I’m going focus on; I’m sure they’re available in other languages. Like most things; Google is your friend on this.

Usually, a Debug Toolbar contains information on included files, any sessions and cookies available, the database calls with timers and a breakdown of memory usage and performance.

Debug Toolbars usually work by encapsulating different code blocks or functions around “timer” functions to record the time it took for a block to run. All the Debug Toolbars I’ve used also included a memory component; really helps to see where the spikes are. There’s also the database integration; it’s just good sense to know where the bottlenecks are in a project.

As I said in the intro var_dump() is a handy little tool for debugging issues in php scripts. It works pretty well for small scripts but, the thing is, on larger projects it just becomes unpractical. Not only is it limited to arrays and objects but you have to manually place the call in the code and depending on the issue, you can get a HUGE amount of data back in a horrible tangle of strings. Makes XML look good.

Instead, using a Debug Toolbar, you get a nicely formatted unobtrusive way to keep an eye on how your code is performing while creating it. Needless to say, these are handy little tools.

PHP_Debug

A little disclosure: My first experience with a debug toolbar was with a really early, think pre alpha, version of PHP_Debug. PHP_Debug, at that time, worked by displaying the debug information at the bottom of a page in a table. This was definitely a step up from using var_dump(), to be sure, but it was still a little painful to decipher. Clients would complain.

Then PHP_Debug pretty much innovated the Microsoft way and copied a feature from another application; Symfony. (I kid, I kid.)

Seriously though, PHP_Debug does claim inspiration from the Symfony which I think is pretty classy of them; it seems too many times credit goes unsaid.

Keep in mind, this was the first time I saw anything like a debug toolbar. I don’t want to break down to hyperbole but to say the sky parted and angels sang would be a fucking understatement.

PHP_Debug Toolbar

PHP_Debug is perfect for those stand alone projects that are started from scratch. It’s not impossible to integrate PHP_Debug into an existing program, I’ve done it a few times, but unless you’ve abstracted out a good deal of the logic it’s going to be a little painful. Put aside a few hours if you’re going to attempt it.

The script displays the output in 2 different ways; through a floating div at the top of a page or as an HTML table displayed at the bottom of the page. Installation is pretty easy and straightforward, either as a PEAR module or as a stand alone script.

ZFDebug

ZFDebug is a plugin for the Zend Framework that acts pretty much like PHP_Debug except with a simple and easy integration into the Zend Framework and it’s quite a bit slicker. Smooth animations, version details, sticky states and full of detail. If you use the Zend Framework I can’t recommend it highly enough.

ZFDebug

There are some installation instructions which at the time of this writing are just broken though. Follow the linked instructions but use the below code in place of the code provided in the instructions:

protected function _initZFDebug()
{
    $autoloader = Zend_Loader_Autoloader::getInstance();
    $autoloader->registerNamespace('ZFDebug');
 
    $options = array(
        'plugins' => array('Variables', 
                           'File' => array('base_path' => '/path/to/project/'),
                           'Memory', 
                           'Time', 
                           'Registry', 
                           'Exception')
    );
 
    # Instantiate the database adapter and setup the plugin.
    # Alternatively just add the plugin like above and rely on the autodiscovery feature.
    if ($this->hasPluginResource('db')) {
        $this->bootstrap('db');
        $db = $this->getPluginResource('db')->getDbAdapter();
        $options['plugins']['Database']['adapter'] = $db;
    }
 
    # Setup the cache plugin
    if ($this->hasPluginResource('cache')) {
        $this->bootstrap('cache');
        $cache = $this->getPluginResource('cache')->getDbAdapter();
        $options['plugins']['Cache']['backend'] = $cache->getBackend();
    }
 
    $debug = new ZFDebug_Controller_Plugin_Debug($options);
 
    $this->bootstrap('frontController');
    $frontController = $this->getResource('frontController');
    $frontController->registerPlugin($debug);
}

Using ZFDebug is as simple as that. Once installed you’ll have a div laying at the bottom of the page with all the details you could want. Plus, it comes preinstalled with the hooks for database and cache profiling. It’s still possible to manually insert timing blocks but the hard part is already done for you.

Symfony

If you’re using Symfony you’re in luck (and none of this is probably news to you); Symfony comes with a Debug Toolbar (the original maybe?) preinstalled and read to use. All you have to do is either hit up frontend_dev.php in a browser or change:

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);

to

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', false);

in your bootstrap file.

Symfony Debug Toolbar

It’s not as robust as PHP_Debug or ZFDebug out of the box (oddly, there’s no included file reference) but it does allow for customization so it has the potential to be very informative and useful.

One last thing about Web Debug Toolbars; they aren’t a replacement for good practices. You can’t rely on them too much and sometimes your instinct will contradict the output of the toolbar. In my experience you should trust that instinct. A Web Debug Toolbar should only be used to provide insight not replace common sense.

One thing to keep in mind is to not focus too much on the

Fiddler Web Debugger

In FireFox I use a couple plugins to help make HTTP debugging a little less painful; HttpFox and the venerable FireBug. There’s also a cool tool called Fiddler written by Eric Lawrence of Microsoft.

Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and “fiddle” with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more.

First, it should be noted that Fiddler is covered under a Microsoft license. That might matter to you or your company…

Anyway, in order to get Fiddler to work with anything other than IE, I’m talking about programs like FireFox or similar, you have to do some tampering and configuring of Windows, including the registry, along with the program you want ot send requests from, so for now I only tested it using IE (this can’t last though; I’m just NOT going to develop in IE).

Fiddler does the basic HTTP sniffing you’d expect but it also has tools to inspect and tamper with the data in the traffic; this is where HttpFox and Firebug drop the ball. Fiddler allows you to see the basics as you would expect any HTTP sniffer to allow but also displays out an XML rendering as well as the Hex view (if you need that sort of thing).

You can mess with a bunch of the different parts of the session including the session itself using custom built “rules”. These rules are written in JavaScript and contain commands that extend Fiddlers UI to allow for extensibility. Needless to say, this is a cool part of the tool.

Another really cool feature of Fiddler is that it can hook into the session for pretty much any Microsoft program that connects to the Internet like Microsoft Office. (I’d always been curious what connections Office makes while open and finding that out scratched a long standing itch.)

It’s definitely worth a look if you need to debug any HTTP traffic (AJAX anyone?).

DiffMerge

Then, mysteriously, the page stopped working in IE. Really frustrating because, well, fuck man, it WORKED. Why it happened doesn’t matter; I did something pretty stupid.

What is important is that it was fixed. For that, I went through my source (SVN) repository and found the file that worked. Easy really.

This still left the issue of why it happened though.

Quick aside: I don’t understand people who just accept that something works (ie; it broke, I fixed it, I’m done). How can you not need to figure out what happened? How will you prevent this from happening again?

To solve that little mystery I busted out my trusy diff tool; SourceGear’s DiffMerge.

I’ve tried a bunch of diff tools, on both Windows and Linux, but at this point I’m really digging DiffMerge. According to the site:

• Diff. Graphically shows the changes between two files. Includes intra-line highlighting and full support for editing.
• Merge. Graphically shows the changes between 3 files. Allows automatic merging (when safe to do so) and full control over editing the resulting file.
• Folder Diff. Performs a side-by-side comparison of 2 folders, showing which files are only present in one file or the other, as well as file pairs which are identical or different.
• Configurable. Rulesets and options provide for customized appearance and behavior.

It’s a really great diff tool totally worth checking out.