Side Projects

I’ve been working on a few side projects lately that I’ve neglected to mention here, so I’ve decided to rectify that.

Working Week JS

This is the latest project. It’s a port of the C# WorkingWeek library that I mentioned a while ago to JavaScript. It’s functionally identical, except that it includes a TimeSpan class (JavaScript doesn’t have one) and it doesn’t include the custom iterators. JavaScript 1.7 apparently includes these, but as only FireFox supports this version (and even FireFox wouldn’t recognise the “yield” keyword) I replaced them with a more traditional approach.


This is a little C# framework for creating console applications with a UI like Mercurial. Mercurial lets you perform all manner of shortcuts to get at the commands you want:

hg sta
hg help sta

These are automatically translated back to:

hg status
hg help status

MurkyCommando lets you achieve the same thing. It includes the help functionality and will pre-parse command line arguments into argument/value combinations.


BugBare is a distributed bug tracker that uses MurkyCommando to present a very Mercurial-like command line UI. It’s written in C#, and works in both .NET and Mono.

There are quite a few distributed bug trackers out there. For example:

They all have problems, though:

  • Bugs Everywhere doesn’t work in Windows
  • DITrack only works with Subversion
  • Distract has vanished from the net
  • pitz doesn’t have a UI and requires you to use the Python interpreter and its object model to create bug reports
  • ditz was abandoned 2 years ago and doesn’t work with the latest version of Ruby
  • Fossil logically separates bugs from code, so bugs cannot be branch-specific

I haven’t used Artemis yet, so I can’t comment on that one.

BugBare is designed to allow Windows developers (or anyone else who doesn’t mind installing Mono) to get in on the distributed fun.

Distributed bug tracking sounds terribly complicated, but it’s not at all. All but Fossil in the list above work the same way. They create a sub directory within the source repository and add bugs as human-readable text files. This makes merging bugs trivial for most source control systems. Fossil is only different because it’s backed by a SQLite3 database.

One of the main aims I had for BugBare was to make logging bugs as easy, or easier, than just updating a text file. A few years ago I went to the FogBugz World Tour in Cambridge to hear former uber-blogger Joel Spolsky speak. The one thing that really struck me about FogBugz was just how easy and fast it was to enter a bug into the database. Spolsky noted that most developers use a text file to log bugs because it’s quick. I do the same - if I spot a bug whilst I’m in the middle of coding something, I really don’t want to spend 5 minutes filling in dozens of tiny boxes in trac and lose my concentration in the process. I just want to note the bug down somewhere and forget about it until later. Developers don’t want a high-friction bug tracker.

Logging a bug in BugBare (which is entirely command line based, like all of the other trackers mentioned, barring Fossil (again)) takes just one command:

bg add "Something went wrong."

Assuming you’re using a command line DVCS, it is extremely easy to work BugBare into your work flow. For example:

hg pull
hg update
hg commit -m "Made some changes."
bg add "Found a bug somewhere."
hg add
hg commit -m "Made some more changes, added a bug."
hg push

It’s as quick as using a text file, but you get extra benefits:

  • You can add comments to bugs
  • Bugs store the date they were logged/modified
  • Bugs store the user who logged them, which defaults to the logged-in user
  • Bugs can be open/closed/rejected
  • Bugs can have several different priorities (low, normal, high, critical)
  • You can search the database for bugs based on various criteria

Sounds great! However, I’m not entirely convinced that distributed bug trackers are the way to go. Imagine you’ve downloaded a new version of your favourite open-source program; FireFox, for example. You spot a bug and want to report it. However, FireFox has switched to using git and Bugs Everywhere. To log the bug, you have to:

  • Install git
  • Learn the basics of how it works
  • Clone the FireFox source repository
  • Install Bugs Everywhere and its dependencies
  • Learn how to use Bugs Everywhere
  • Log the bug
  • Commit it to the repository
  • Send a patch to the FireFox team that contains the bug (you won’t be able to push to their repo)

From an end-user’s perspective, distributed bug trackers are awful. For most open-source projects, which rely on the “many eyeballs” way of identifying bugs, they just won’t work. It gets worse when you consider that each branch of each different repository clone can have its own separate bug database. Even if someone wrote a web front end to a distributed bug tracker, to allow it to be used by non-developers, it would quickly become confusing if it had to provide access to all bugs in all branches of the repository.

This is probably why most of the trackers listed in this post see very little activity these days. They’re a great idea, and fantastic for individual developers and small teams, but they’re extremely counter productive for open source projects.

So where does that leave BugBare? I’m announcing a new program and at the same time saying that using it probably isn’t a great idea. Perhaps I should get a job in marketing? Personally, I don’t think I’ll use it much. BitBucket’s bug tracker is fairly quick. More importantly, anyone can see it and add bug reports with little effort.


More Mini Projects

I’ve been tinkering with a few mini projects lately, all of which are available from my BitBucket page:


Networked Pacman

Though I released this ages ago, I published it as a zip archive instead of hosting the code in a source code management system. I’ve rectified this and added it to BitBucket:

Networked Pacman


This is a simple implementation of the logic of Scrabble, written in Python 3. It doesn’t have a UI, so it’s not terribly exciting for anyone but Python programmers, but perhaps someone will write a front-end for it. This was written in a couple of days and was an exercise in trying to think “Pythonically”. Whether or not I achieved this I’m not sure…



Finally, this is a C# library that provides date functions that operate on a user-defined working week. For example, you can define a week of 9:30am to 5:30pm shifts (with time for lunch, natch) and use the functions provided by the library to determine whether or not a given date/time falls within a shift, or how many working hours there are between two dates, etc. It does some neat things with custom iterators and the yield statement to condense a lot of fiddly logic into a couple of very powerful methods.