Anyway, when you’re writing software, it helps to have a bug tracker, sometimes called an issue tracker....

Id: 130

(groan)

For the past year or so I’ve been working on a new framework for this website… well, actually, it’s sort of the same “framework” I’ve already got, just cleaned up and refactored a bit to make it easier to modify and add on to. (Ease is generally a good thing, at least with computer programs.)

Anyway, when you’re writing software, it helps to have a bug tracker, sometimes called an issue tracker. Basically a glorified TO DO list for your program. There are plenty of these already out there, roaming the internet, and I did briefly consider signing up with Launchpad or installing Trac. Actually I tried it and couldn’t get Trac’s authentication to work properly. So much for being easy. (I’m sure I was doing something wrong.)

Now, as I said, one of the goals behind this new framework I’m building is that it should be easy to modify and add new features to it. Like, say, a bug tracker. And I figured, well, if I’m doing my job right, it shouldn’t be that hard at all. So why not try it? Well, it turned out not to be hard, but in a kind of “cheaty” way: behind the scenes, bug reports are pretty similar to blog posts.

Think about it: what’s in a blog post? At a minimum, any functional blog engine will probably have something like this:

• title
• date
• author
• category
• text
• tags
• comments

Now take a look at, say, a typical Bugzilla installation. There are a lot of fields but here’s a rundown of some of the most important ones:

• summary
• date
• reporter
• product
• description
• keywords
• comments

Look familiar? It’s practically the same thing as the blog post, just with different names for most of the fields.

Of course, there are a few differences — bug reports have fields for a status, and often some information about the software version and underlying system. But it’s easy enough to tack on code to handle those; it’ll be a lot like the code for the other fields. So basically, a lot of copy-and-paste (if you’re just hacking together something like I am), or better yet, factoring out common behavior into superclasses and using inheritance.

Which brings us to the polymorphism part of the title. A lot of the different things we do with websites these days are really not so dissimilar. This is something I sort of picked up on several months ago — in fact, it’s part of what inspired my new web framework — but still, it’s kind of cool to actually see it working out in practice. I was able to transform my blog code into a simple but functional bug tracker literally overnight. (with plenty of time left over for checking random websites to distract myself). It shouldn’t be too much of a leap from there to tweets, or “postlets” as I stubbornly insist on calling them (I still haven’t forgiven Twitter for, well, being Twitter). And after that, the possibilities are limitless: wiki pages, forums, mailing lists, who knows?