LinLog

This past week I finally decided to migrate to a new bug tracking system for my personal projects. Granted, my projects aren't particularly big (in most cases, I'm probably the only user), so it's not like I'm flooded with bug reports. But in my last two jobs I lived and died by our ticket tracking system and found the use of a good bug tracker to be extremely helpful for my development process.

For the last few years, I've been using Mantis BT for my personal bug tracking needs. Mantis is actually a very capable bug tracker and worked fairly well for my needs. However, Mantis is just a bug tracker. It doesn't have a wiki or much in the way of project planning tools, release management, or anything else, really. It has some basic roadmapping features and a changelog generator, but that's about it. And since I've become used to working with the likes of Jira, Trac, and Phabricator, I've come to want a little more than that.

On a side-note, the other thing about Mantis is that it's a bit cumbersome to work with. The UI is a bit...antiquated, for one thing. In fact, I've heard people refer to it as a disaster. There's a reason that the Mantis site only shows screenshots of the mobile app, as seen from the issue reporting screen below. The workflow is also a little weird when it comes to things like the changelog and roadmap features. It centers on fixed-in and target versions for individual bugs, which presupposes a more organized type of release planning than I'm looking to do.

So if not Mantis, what to do for an issue tracker? Obviously, the simple answer would be to install one of the popular project management packages, like Trac or Redmine. However, there are a couple of problems with this:

1. I run this site on a shared hosting account. A really cheap shared hosting account.
2. I'm kinda lazy.

To expand on the "cheap" part, my hosting provider is really targeted more at simple PHP-based sites that are administered through their control panel. So not only do I not have root access to the server, I don't even have shell access - just the control panel and FTP. So anything that requires running interactive commands for setup is out. And while my host does "support" Ruby and Python, in the sense that the interpreters are installed and accessible, it only does so through CGI and has a rather limited set of libraries installed.

This all leads into the second point, i.e. laziness. I could just get a more full-featured hosting provider. However, I've been happy enough with my current one, they're very affordable ($6/month), and frankly, I can't be bothered to go to the effort of moving all my stuff to a new server. I also can't be bothered to figure out the non-trivial steps to set up a semi-supported package like Trac or Redmine on my current host. It just isn't worth the time and energy to me.

So I decided to do a little more research. After some Googling, I ended up settling on The Bug Genie. So far, it seems to be a pretty decent compromise between Mantis and something like Trac. In addition to ticket tracking, it has an integrated wiki module, release and milestone tracking features, and even source control integration.

The initial setup was not as intuitive as I might have hoped. For starters, there was no easy way to migrate my data from Mantis to The Bug Genie. I ended up just migrating the issues themselves, minus comments, by using Mantis's CSV export. A highly sub-optimal solution, to say the least, but it wasn't important enough to me to make a project out of the migration. Second, the permission and user system, while it seems pretty powerful, is a bit more complicated and granular than I need. Lastly, the source control integration was a bit of a pain to set up. The actual configuration wasn't that difficult once I figured out what I needed to do, but I had to go to the project team blog to find the documentation I needed. Honestly, the worst part was the particular format of commit message needed to trigger the integration - it's quite verbose and not at all intuitive.

It's only been about a month of fairly light use, but so far I'm pretty satisfied with The Bug Genie. The UI has its quriks, but is modern and easy to use. It's pretty configurable and well documented, allowing you to customize project pages using the wiki module. Things like the release tracking and VCS integration are nice touches and seem to work quite well. All in all, it pretty much does what I wanted and does it reasonably well. I'm pretty happy with it.

It seems that Microsoft has decided to be a bit nicer about testing old versions of Internet Explorer. I just found out about modern.IE, which is an official Microsoft site with various tools for testing your web pages in IE.

The really nice thing about this is that they now provide virtual machines for multiple platforms. That means that you can now get your IE VM as a VMware image, or a VirtualBox image, or one of a few other options.

When I was using Microsoft's IE testing VMs a couple of years ago, they were only offered in one format - Virtual PC. Sure, if you were running Windows and using Virtual PC, that was great. For everyone else, it was anywhere from a pain in the butt to completely useless. This is a much better arrangement and a welcome change. Nice work, Microsoft!

With the imminent demise of Google Reader, and FeedDemon consequently being end-of-lifed, my next task was clear: find a new RSS aggregator. This was not something I was looking forward to. However, as things turned out, I actually got to solve the problem in more or less the way I'd wanted to for years.

The thing is, I never really liked Google Reader. The only reason I started using it was because I liked FeedDemon and FeedDemon used Google Reader as it's back-end sync platform. (And if you've ever tried to use a desktop aggregator across multiple systems, you know that not being able to sync your read items across devices is just painful.) But I seldom used the Reader web app - I didn't think it was especially well done and I always regarded the "social" features as nothing but a waste of screen space. Granted, the "accessible anywhere" aspect of it was nice on occasion, but my overall impression was that the only reason it was so popular was because it was produced by Google.

The other issue with Reader is that I don't trust Google or hosted web services in general. Paranoia? Perhaps. But they remind me of the saying that "If you're not paying for the product, then you are the product." And while I know a lot of people aren't bothered by that, I think that Google knows far too much about me without handing them more information on a silver platter. Furthermore, you can't rely upon such services to always be available. Sure, Google is huge and has ridiculous amounts of money, but even the richest company has finite resources. And if a product isn't generating enough revenue, then the producer will eventually kill it, as evidenced by the case of reader.

What I'd really wanted to do for some time was to host my own RSS syncing service. Of course, there's not standard API for RSS syncing, so my favorite desktop clients wouldn't work. But with FeedDemon going away as well, and having no desktop replacement lined up, I no longer had to worry about that. So I decided to take a chance on a self-hosted web app and gave Tiny Tiny RSS a try. I was very pleasantly surprised.

The installation for TT-RSS is pretty simple. I use a shared hosting account, and though the documentation says that isn't supported, it actually works just fine. The install process for my host consisted of:

1. Copy the files to my host.
2. Create the database using my host's tool.
3. Import the database schema using using PHPMyAdmin.
4. Edit the config.php file to set the database connection information and a couple of other settings.
5. Use my host's tool to create a cron job to run the feed update script.
6. Log in to the administrator account and change the default password.
7. Create a new account for myself.
8. Import the OPML file that I exported from FeedDemon.

That's it. Note that half of those steps were in the TT-RSS UI. So the installation was pretty much dead-simple.

In the past, I wasn't a fan of web-based RSS readers. However, I have to say that Tiny Tiny RSS actually has a very nice UI. It's a traditional three-pane layout, much as you would find in a desktop app. It's all AJAX driven and works very much like a desktop client. It even has a rich set of keyboard shortcuts and contextual right-click menus.

As an added bonus, there's also a pretty nice mobile site. While the latest release (1.7.5) actually removed the built-in mobile clientweb site, there's a very nice third-party JavaScript client available. It uses the same API as the mobile clients, so the installation pretty much consists of enabling the API, copying the files to your host, and editing two settings in the config file to tell it the path to itself and to TT-RSS.

But who cares about the mobile site anyway? There are native Android clients! The official client is available as trial-ware in the Google Play store. And while it's good, I use a fork of it which is available for free through F-Droid. In addition to being free (as in both beer and speech), it has a few extra features which are nice. And while I may be a bit cheap, my main motivation to use the fork was not the price, but rather the fact that the official client isn't in the Amazon app store and I don't want to root my Kindle Fire HD. This was a big deal for me as I've found that lately my RSS-reading habits have changed - rather than using a desktop client, I've been spending most of my RSS reading time using the Google Reader app on my Kindle. The TT-RSS app isn't quite as good as the reader app, but it's still veyr good and more than adequate for my needs.

Overall, I'd definitely recommend Tiny Tiny RSS to anyone in need of an RSS reader. The main selling point for me was the self-hosted nature of it, but it's a very strong contender in any evaluation simply on its own merits. In my opinion, it's better than Google Reader and is competetive with NewsBlur, which I also looked at.

Last summer I learned a new acronym, courtesy of Chinmay. He asked for a developer to put some estimates on the outstanding technical tasks needed to make a demo production ready. So I fabricated a few numbers, slapped them on the wiki page, and dropped a note in the project chat room saying that I'd put up some grossly inaccurate estimates. Chinmay replied by thanking me for the SWAG - Sophisticated, Wild-Ass Guess.

The reason I like this acronym so much is that it pretty much sums up all the software estimates I've ever seen. I mean, it's not like there's no methodology to it - you look at the task, break it down into pieces, and apply some heuristic to attach a number of hours to each piece. But really, at the end of the day, it's all just guess work. The "heuristic" usually just comes down to a gut feeling of how long something ought to take based on your knowledge of the system. In other words, a guess.

And it's not like there aren't more organized ways of doing this. We could use COCOMO models to come up with our estimates, for example. The problem is, approaches like that require you to have actual data to use as a basis for comparison, and most teams don't have that. Or they do have it, but the data is useless - corrupt, fabricated, poorly defined, etc.

The reason it's hard to get good data on developer productivity is obvious to anyone who has ever worked in a pathological development shop - because it can be dangerous. In a good organization, such data would be used to estimate costs and schedule and to help make better decisions about what projects to do and where to allocate resources. In a pathological organization...not so much.

In a pathological shop, measurement is used against you. If the measurement is number of hours needed to complete a task, then you'll be judged to be incompetent or slacking off if a "simple" task takes you "too long" to complete - where what counts as "simple" and "too long" are determined by a non-technical manager who really has no idea what you actually do. Or perhaps you'll be required to account for all eight hours of your day, down to five-minute increments. Because heaven forbid you should "cheat" the company by taking a bathroom break.

When I think of pathological examples of measurement, I always think about my last job with an online advertising startup. At one staff meeting, our VP of Engineering announced that he new expectation was that engineering would deliver on its estimates with 90% accuracy based on 80% definition from the product manager. So we were required to be 90% sure how long a task was going to take, even though we were only 80% sure exactly what it was we were building. And based on previous experience with the product manager, calling the specs he gave us "80% definition" was really generous - I'd say it was more like 50%.

In that case, the productivity measurement was being used as a tool to force the VP of Engineering out of the company (and it worked - he put in his notice the next week), but the principle applies to anyone - if a measurement can be used against you - even if that use is unfair and out of context - assume it will be used against you. That's a very sad reaction to have, but it's natural if your experience is primarily with unhealthy shops. And while I don't endorese such a paranoid attitude, having been in such a shop more than once in the past I can certainly understand it.

One of these day, I'd really like to work in a shop where performace metrics were used as a real tool in project planning. Even in healthy shops, this sort of thing seems to be uncommon. That seems to be something of a comment on the state of "software engineering" as a discipline. The differentiator between quality and pathological shops seems to be the absence of bad practices as opposed to the precense of good ones. Even in good shops, building software seems to be less engineering and more art or black magic.

Personally, I'm not convinced that that is a necessary or desireable state of affairs. I'd just like some first-hand evidence to support that suspicion.

Two quick humorous items that came up in the last couple of days.

First, some animated GIFs describing moments in the life of a programmer. They're funny because they're true.

Second, a joke that evolved during a two-hour conference call I had on Tuesday:
VP of Engineering: "There are really only two problems in programming: cache invalidation and naming things."
CTO: "And off-by-one errors."
<Laughter slowly builds as people start to get the joke.>

I have a new side project. It wasn't one I was really planning on, but it's the fun kind - the kind that scratches an itch.

You see, I've become a big fan of the Roku set-top box. I have three of them in my house. And in addition to using them for Netflix and Amazon Instant Video, I also use them to stream video and audio from my desktop PC (which has become an ersatz home server). For this I use an application called Roksbox. It allows you to stream videos from any web server. So since I already had IIS running on my PC, all I needed to do was set up a new website, symlink my video directory into the document root, and I was ready to go.

The problem with Roksbox is that it's a bit basic and the configuration is a little clunky. For example, if you want to add thumbnail images and metadata to the video listings, you have two options:
1) Put all the information for every video in a single XML file.
2) Turn on directory listings for your server and use one XML file and thumbnail file per video.
The problem with the first option is that it's ludicrously slow. By which I mean the interface can freeze for upwards of 30 seconds while Roksbox parses the XML file. And the problem with the second method is that you end up littering your filesystem with extra files.

This was particularly the case when I looked at adding thumbnails for a TV series. All I wanted was for each episode to have the season's DVD cover art as a thumbnail image rather than the default image. Unfortunately for me, in order to do that Roksbox wants you to have one image file for each episode. So I either needed a bunch of redundant copies, or a bunch of symlinks, and neither of those options appealed to me.

So I decided to try something - faking the directory listing. That is, I wrote a couple of simple PHP scripts. The first read the contents of a directory and simulated the output of the IIS directory browsing page, but inserting thumbnail entries for each video. So, for example, if there was a video "Episode 1.mp4", the script would add an "Episode 1.jpg" to the listing. The second script worked in conjunction with a rewrite rule for non-existent files. So since the "Episode 1.jpg" didn't exist, the request would be sent to the second script, which would parse the request URL and then redirect to an actual, existing thumbnail image. The result was that I had my images for every episode in the season and I didn't have to create any pointless links or files.

This worked so well that, naturally, I took it to the next level. I started branching out and added more support for customizing listings, such as hiding and re-ordering directories. Then I started getting really crazy and wrote code to generate listings for entirely fictitious directories in order to create video playlists. I even started writing admin pages to provide a GUI for configuring this stuff, built an SQLite database to save the information, and created an ad hoc application framework to help manage it.

I think the reason this little project really caught my interest is that it's something that I actually use on a daily basis. I've been trying for a while now to find a side-project that I can use for picking up new languages or technologies, but nothing ever seems to stick. I'll play with something for a while, but them lose interest pretty quickly when some other obligation comes up. I think that's because those projects are just excuses - I'm doing them because I need a project in order to learn something new, but I have no particular interest in that particular project. But even though I'm not using anything new for this project, it grabs my attention because it's something that I want for myself. That's something I haven't had in a while, and I really like the feeling.

If anyone is curious, the current code is in my public mercurial repository here. I'm planning to put up a proper release of it when it's a bit more together. For now, I'm just having fun making it work.

This is just another "note to self" post, so that I have something to refer back to later when I forget this again. Nothing to see here - move along.

Without further ado, here's a link for how to configure ISC BIND on Windows. This should have roughly the important details, with the exception of file locations. Per the company guide, I have my BIND files in C:\Windows\System32\dns. Note that this is restricted to admin accounts, so it won't show up in explorer with my regular account. I lost 15 minutes figuring that out the other day. Also, here's a link on the managed-keys-zone error I was getting in the event log. That turned out to be the fix for my problem where BIND was starting, but DNS queries weren't working.

If you're not me and you're still reading this, the motivation for this post was configuring a new development VM for work on my home Windows box. Normally, we're a Mac shop, and the company provides MacBooks for anyone who requests a computer. However, mine broke down and is in the shop, so I had to set up my Windows box with the development environment.

There are just two problems here:
1) Our codebase, despite being PHP running on a Linux VM, is actively Windows-hostile.
2) We require wildcard DNS for subdomains.

The use of BIND is to address the second problem. For the occasions when someone tries to run the VM on Windows, BIND is used to send the DNS queries for our development domain to the VM. Of course, we could just set the Windows DNS server to the VM itself, but that has the down side that your DNS breaks when you shut off the VM.

And if you're curious about the first problem, all you need to know is that our codebase is full of directories named "v.", which is just fine on UNIX-based systems, but is an invalid directory name on Windows. There's a good reason for that - trust me - but it's too long to explain without the relevant context. (Of course, there's no reason that it has to be "v." - the guys who came up with that could have just used a different naming convention. But they didn't, and now we're stuck with it.)

I finally had a "new tech" adventure last week - I dabbled in Mozilla extensions for the first time.

I've been using ActiveState's Komodo Edit as my primary editor for PHP, Python, and JavaScript for the last few years. One of the extensions I always used was the TabSwitcher. I've found that I depend on that extension even more heavily now that I'm with deviantART simply because of the size of our code-base. While the Fast Open extension is great and has similar functionality, it simply doesn't fill the same role for me. Our code-base has thousands of file, many of which have similar names, which results in Fast Open slowing down and giving me too many results to be useful. Because TabSwitcher operates on a much smaller data set, it's much better for the common case where I have 20 or 30 tabs open and am actively switching back and forth between 8 or 10 of them.

The only problem is that TabSwitcher isn't compatible with Komodo 7. That's actually part of the reason I hadn't bothered to upgrade Komodo on my work computer yet. So I decided to remedy that by porting it to Komodo 7. While I was at it, I added a couple of small enhancements, such as updating the bookmark list when a bookmark is added.

You can download the extension here:
tabswitcher-1.0.0-ko.xpi
If you want to look at the source, it's in my Mercurial repository here:
http://hg.skepticats.com/tabswitcher/

This was my first exposure to XUL or Mozilla add-ons, so hopefully everything will work the way it should. I haven't seen any problems so far, at least.

Author's note: This one from the archives was written back in March 2008. This is something I've seen a couple of more times since then. A new developer, usually fairly young, comes in and wants to rewrite everything using whatever technology or method he's most familiar with. It seems to be not so much a problem with learning the new codebase as it is developer hubris. "My chosen way is obviously the right way, so clearly that's how we should be doing things." The people who do this don't seem to stop and think about whether their chosen method or tool might not be the best choice in the current situation, or whether implementing it might just be more trouble than it's worth. Perhaps it's just a lack of experience - they haven't had enough rewrites go south to realize that this isn't always a good idea. Either way, enjoy the rant!

Here's a little tid-bit for you young, aspiring developers out there: When you start a new job, it's usually a good idea to wait until your second week before you suggest rewriting the entire existing codebase.

I say this because we recently hired a new developer. He's obviously very bright and knows his stuff, but his first suggestion, on his first day, was that we should rewrite our entire codebase from a custom PHP framework to Symfony. After all, it would probably only take a couple of months.

Now, I don't know much about Symfony, but I have nothing against against it. And, in all fairness, our current framework is a bit of a mess. So I'm not dead-set against the very notion of switching. However, the current framework has been tailored to our needs and it is perfectly adequate. I'm sure that Symfony is very nice, but it's not immediately obvious what compelling advantages it would offer. After all, we already have an application framework that does what we need and which all three of the established developers are very familiar with. Given that we already have a full plate as far as projects go (hence hiring a new developer), it's hard to imagine how you could make a business case for spending 2 or 3 months learning Symfony and converting the whole site to use it. And if the new guy things that we're going to convert in parallel with adding features to the existing codebase (which he actually mentioned), he's out of his mind.

The thing that really bothers me about this, though, is that the new guy suggested this on his very first day. As far as I know, he hasn't even written a line of code yet and he's already writing up the business case for switching to Symfony. Even though he's barely looked at our codebase and so couldn't possibly have any idea what kind of effort this would entail.

So, to all the developers out there, next time you start a job on an established development team, at least take the time to learn what technology they're using and why before you suggest replacing it. Do a project or two with the current stack. Talk to the other developers about the history of the codebase and the company culture. Pushing to replace major technologies before you've even written a single line of code just makes you look like a tool.

Author's note: In yet another installment of "From the Archives", here is a little entry that I wrote up back in September of 2007, but never bothered to publish. It's a little dated, but sadly it still has the ring of truth to it. Of course, there has been some improvement. A lot of hardware doesn't come with a CD anymore - they just give you a pamphlet with a link to the crappy software instead. But anyway, I thought this entry was based on an interesting quote, so here it is.

On an episode of Hanselminutes a month ago, Scott and Carl spoke with Jeff Atwood of Coding Horror fame about the "ultimate developer rig" he built for Scott. During the course of discussion, Jeff uttered what is, undoubtedly, the best quote about software developers that I've ever heard.

Nobody hates software more than software developers.

Not only does it sum up the feeling of true software geeks everywhere, but it also offers a sad commentary on the state of the computer hardware business.

This quote was uttered in the context of a discussion about "mouse software," i.e. those useless CDs full of crap-ware that get thrown in the package with even fairly standard mice. They typically include drivers, a control panel applet, some kind of tool that runs in the system tray, and probably a few other things.

As Jeff and Carl rightly pointed out, the reason they, myself, and many other programmers hate such software is that it is, quite simply, useless. Nobody needs to install the software that comes with a standard wheel mouse because their operating system (no matter what it is) already supports it. In fact, Carl went so far as to say (half-kidding, I hope) that if he caught any of his employees installing "mouse software," they'd be fired on the spot. Any half-competent programmer or IT person should know better.

Sadly, this phenomenon isn't just limited to mice. USB media devices seem to be the worst offenders. Cameras and MP3 players in particular always seem to come with some kind of software that's supposed to help you move files onto or off of the device. Of course, as it's always third-rate crap-ware, as the vendor makes their money on the hardware and just throws in the software as an after-thought. But the worst part is that there's no reason you should even need it, because any decent MP3 player or camera really ought to "just work" as a USB mass storage device (with the notable exception being the iPod, which is decent, if overrated).

So really, it's not that software developers hate software, it's that we hate crappy, unnecessary software. That's probably because we know what we need and can easily judge the value of a program. We can tell when all a program does is the digital equivalent of busy-work. Being handed a CD of code that doesn't do anything useful feels like being condescended to. That angers us.