Developing CodeBurner — An Exercise in Exploratory Programming
As it turned out, developing for Firebug is not significantly different from developing any other Firefox extension. I’m indebted to Jan Odvarko for his series of posts on Extending Firebug, from which I got the basics that I needed to make it work — how to hook into Firebug’s scripting namespace, how to add controls to its user-interface, and how to make use of its available scripting objects.
But apart from a smattering of basic articles like that, Firebug’s API is essentially undocumented, and so I had to do quite a bit of what you might call “exploratory programming” — poking around in the source code to look for code that looks like it might do what I need. For example,
FireScope CodeBurner needs to be able to extract all the CSS properties that apply to a given element, so that it can search the reference for information about each one. We already know that Firebug can do that, because it’s right there in the Style panel, but how do we hook into the right processes to get the information where and when we need it? Fortunately, since Firebug is open-source, there’s nothing it can do that can’t be discovered eventually, even if it does take some hunting!
The process I use to find functionality like this is a kind of reverse-engineering, where you start from the end result, and work your way backwards. For example, I began by looking for code that addresses the part of the user-interface where I know that CSS information is displayed, and I can look in Firebug’s XUL files to find out where that is (XUL is the eXtensible User-interface Language used by Firefox to define its UI components). Once I’ve found that code, and find that it’s contained with a method, I can then look back further still, for places where that method is referred to. And so on, through method calls and references, until eventually I find the code that actually extracts that information from the CSS DOM.
Although intricate and sometimes confusing, this process of reverse-discovery allows me to work through the most intricate and abstracted code, and is what makes it possible to build tools like this, that rely so heavily on functionality from an undocumented codebase.
It’s not something that appeals to everyone, because it takes a lot of time and a certain kind of patience, but I find it incredibly satisfying when it does all work out — and that’s what makes the process enjoyable for me.
How about you? Do you enjoy this kind of programming task, or does the very notion leave you cold?