So my company’s looking at switching from using the beastly Bugzilla bug tracking software to using something called FogBugz. It seems a decent enough piece of software, though the install process went as follows:

1. Download and untar install files.
2. Learn from the readme that it requires a PHP extension, a daemon, and (for me) a PHP upgrade. This is all rather more intrusive than most bug software I’ve seen, though to be fair, Bugzilla also has a lot of dependencies.
3. Upgrade PHP.
4. Run a script at the command line to make sure dependencies are all worked out.
5. Start the daemon.
6. Run a wizard on the Web to set up the database, etc.
7. Buy and submit license key.
8. Worry about importing bugs from old bug tracker into new one.

This last item is the one that’s taken up some four hours of my morning today. FogBugz apparently ships as an asp application, but there’s a PHP version that we’re using. For the Windows version, there’s a script to import from Bugzilla, but it’s hosed on Linux. It seems to tap into stuff set in the PHP extension that’s Windows-specific or something. So I worked a little magic using some PEAR classes and was able to connect to Bugzilla’s xml interfact to retrieve bugs.

But I was getting authentication errors. Apparently, if you’re not logged in, you can’t see bugs using Bugzilla’s xml interface. I tried a couple of things and finally just used links at the command line with the -source flag to get all of our bugs as text files. I had to browse to our Bugzilla install using links and login first, though, so that the cookie would be set and subsequent connections would be able to see the xml data rather than the “NotPermitted” error.

So, now I’ve got 700ish bug reports in a directory. Time to hack the import script to make it work using my data rather than the obfuscated methods available through the Zend extension. This was just a little tedious and mainly consisted of finding objects and function calls and replacing them with arrays and keys that hold the corresponding data from my parsed xml. That is, the shipped code gets an xml file and creates objects to hold the data, while my code slurps in the xml and creates a nested array for each bug; I had to make the import script read my arrays rather than looking for objects. There were a couple of little hitches that were easily fixed, and before too long, I had my 700ish bugs imported into FogBugz.

But I noticed when reviewing my new bug list that I had a bunch of bugs that weren’t mine, and others had bugs that should have been mine. Moreover, most of the bugs were assigned to just two of us. Why this happened I have no idea. To fix it, I wrote a script that reconciles user ids between the two systems and changes bug assignment in FogBugz for each bug to what the assignment in Bugzilla originally was. For example, say user X in Bugzilla has numeric id 5, while he has numeric id 22 in FogBugz (just because of the way the users were imported). Luckily, both systems use the email address as the login, so I could query both databases, get the numeric id for each, and then do a query for each bug that says (in English) “Change the assigned-to field for bug 700 to the numeric id 22 because the numeric id for assigned-to in Bugzilla is 5, and user 5 in Bugzilla corresponds to user 22 in FogBugz because they map to the same email address.”

And voila, my bug list is as it should be. I’m sure we’ll find problems here and there, but by and large, I’d say it was as successful an import as could have been hoped for.

A couple of nice people (db48x and gavin) on #developers at irc.mozilla.org pointed me to some docs that helped me unpuzzle myself. First, the idl file for nsITreeview, which clued me in to the fact that the second parameter is no longer a string. Second, a link to a mailing list posting about the change.

Basically, the change was implemented in order to do away with the necessity to give treecols an id. By generalizing the function a bit to expect an nsITreeColumn, Gecko can now figure out which column to use in a number of ways. For example:

tree.columns.getColumnFor(treeColElement);
tree.columns.getNamedColumn(treeColID);
tree.columns.getColumnAt(index);

In my recent case, I knew the column name, so I passed tree.columns.getNamedColumn(‘identifier’) rather than just ‘identifier’ to the getCellText() function and it worked like a charm.

I post this pretty much for my own later reference.

• You must already live near or be willing to relocate to Silicon Valley.
• You must have a minimum of five years of application development, with a focus on the following skills, in descending order of importance:
  • Mozilla application development
  • XUL
  • XPCOM
  • C++
  • javascript
  • CSS
• Experience developing on two of the following three platforms: PC, Mac, Linux
• Experience working on Open Source Software projects is a plus.
• All the usual buzz words (self-starter, team-player, etc.) apply.

Send me a resume at abcdefg@hijklmnopqrstuvw.xyz (but replace abcdefg with my first name and hijklmnopqrstuvw.xyz with learnhouston.com) if you think you’re the person for the job. If you’re not the person for the job, but you might know who is, have that person send me a resume and include your contact information. There’s a small reward for whoever turns up a person we ultimately hire. Please don’t apply or send me resumes for those who don’t meet the criteria listed here.

My latest iteration breaks new ground in UI design. If you look carefully, you’ll see that there’s a little green bullet sort of thing (an icon squished down) and then a button wrapped around this small button in the shape of a sideways “U.” If you click the wrapping button, sure enough, you get the popup. If you click the inner button, you get the default behavior. I fully expect this sort of button to begin appearing in software packages very soon.

But let’s say I want to force an update (or at least prompt the user to let him or her know that a new version exists. Supposedly, there are some configuration options you can set to cause extensions (and Firefox itself) to automatically update (thanks to Nigel McFarlane’s Firefox Hacks for this):

That didn’t work for me, presumably because there’s some sort of timer. It seems to me as if I’ve heard at some point that different versions of Firefox do their updates at different times once a week. But say I have an important security release for my extension and want to prompt people to upgrade immediately, whether they’ve just installed it two days ago or whether they’ve had their browser open for three weeks without a restart (a tempting method for checking updates would be on browser load).

Luckily, Firefox’s mechanism has interfaces exposed that allow you to tap into some of the functionality. Unfortunately, there’s not enough exposed to be extremely useful, but there’s enough to get by. Specifically, there’s a function available through the nsIExtensionManager component that allows you to display the extensions manager wizard, as follows:

The trick, then, is to check the current and remote versions of the extension and to display the wizard only when there’s a discrepancy. Else you wind up showing a blank wizard. This is easily enough managed by querying the extensions RDF for the version number and then polling a remote script that serves up the current version of your extension (I use a different output source here than the updateURL RDF because all I really need is the number, and I want to conserve bandwidth. I could find no way to check the remote version using built-in interfaces without spawning the update wizard, though I may have overlooked or misunderstood some code. In pseudocode, the routine runs as follows:

Naturally, you kick this off in an onload handler so that any time your browser is started, it checks immediately for updates and then checks periodically for as long as the browser’s open.

>> “What do you do?” they’ll ask.
<< “I program stuff.”
>> “What do you program?”
<< “Web services.”
>> “What’s a Web service?”
<< “It’s something that allows another application to access your data.”
>> “But isn’t your company tied up in Firefox somehow?”
<< “Yes. I write Web services that we hope will help enhance the browsing experience.”
>> “How?”
<< “I can’t really say very much about it right now. I’m writing extensions to go along with the Web services.”
>> “How’s your company going to make money?”
<< “Nice weather we’re having today, huh?”

Well, we finally launched our Web site yesterday after a lot of work by a guy named Joel Apter, whom I hooked up with as a developer resource on the Spread Firefox project, and a designer named Bryan Bell who’s great at icon work in particular and who can be contracted for pretty darned reasonable rates. These guys did the bulk of the site so that I could work on my mysterious Web services and extensions with limited distractions. And I think they did a great job.

I spent some time the night we launched doing some benchmarking and tweaking to make sure our site scaled pretty well, and I’m happy to say that we weathered a slashdotting with aplomb, the site hardly affected by the heavy traffic.

For now, our site doesn’t say a whole lot about what we do. Out of the gate, our offering is sponsorship of several popular Firefox extensions. Basically, we’ve given money and other resources (server infrastructure) to these developers both to support their great work and to attach our name to their popular products. We have a lot more on the horizon, and with a little luck and a few more twelve-hour days on my part, we’ll have a beta release of what we hope will be a pretty exciting extension near the end of the month.