Sunday, 2011 November 06

Everyone who knows me can attest to the fact that I'm a serial maker of todo lists. This doesn't mean I'm particularly well organized, mind you, just that I have a habit of creating (and then often ignoring or abandoning) todo lists. Over the years I've tried a lot of different techniques and technologies, trying to find a system that I'll actually stick with.

I'm still searching. But several years ago I read David Allen's "Getting Things Done". As you might expect, I was very intrigued and decided to adopt it. Or rather, I'd adopt a system of my own devising that was heavily influenced by the GTD methodology.

The first phase was good old-fashioned index cards. In my professional life my team uses a scrum methodology. So I treated each index card as a 'story' and would make post-it note 'tasks'. At the start of the month I'd pick which stories I was going to attempt that month.

Actually coming up with stories was easy, and tasking things out was also pretty straightforward. At least most of the time. I still had a stack of old lists that I didn't know how to convert to stories and tasks, but I figure I captured about 80% of what I felt like I should be doing over the next few years on those index cards.

This system lasted about three months. In those months I don't think I managed to finish more than one or two stories. I just wasn't disciplined enough to make consistent progress. I'd come home from work and end up doing something completely unrelated.

Recognizing the failure, I decided I needed to write some software to automate the process. I got maybe 10% of the way there and gave up. It turns out that I couldn't define the process I wanted well enough to actually write software to support it.

So I decided to back off. The problem, as I saw it, with both the story/task approach as well as the software I had in mind was that the process was too heavy and too inflexible. So I decided to check out some lighter-weight software written by other people.

The one system that really appealed to me was Tracks. I installed it on one of the linux boxes in my house and used it for a while (probably several months). It generally worked pretty well and I was reasonably happy with it. But the more I used it the more I suspected it was losing data. It also seemed to me that the developers were moving at a snail's pace.

At about this time the computer I had been running Tracks on died. This was also the DVR in the living room. My wife (fiancee at the time) was living with me at this point and we decided to try out Windows Media Center on the new DVR I built up. My main desktop, which usually runs Linux, was also running Windows at the time so my wife could play some games on it. This meant that there really wasn't a good computer on the network to install Tracks on. So I grabbed the old sqlite DB (so I could extract the data) and started searching for another solution.

I settled on Todoist.com, a free, lightweight todo list web application. I've been using it ever since, but I never found it completely acceptable. It's flaky; at one point the entire site was down for 24 hours (give or take) and it was painfully apparent that it was being run by amateurs. I also missed some GTD features.

And so this morning I installed the latest version of Tracks on brutallogic.net. That was a battle in and of itself, but at this point it's up and running and I'm happy. Coming back to Tracks is like becoming reacquainted with an old friend. It's entirely possible in a few months I'll be off and looking for another solution. But maybe not. Maybe this time it'll stick.

If you're interested in the technical details of the problems I had with installing Tracks, read on.


All of brutallogic.net is running off of a single instance of Apache. Besides the website I have a wiki, Roundcube for my email, Trac, and now Tracks. I also have PostgreSQL running, installed under /opt/. When I set up Trac, using mod_wsgi, I configured all of the projects I migrated over to use this PostgreSQL instance. I could not for the life of me convince the python process to look in the appropriate /opt/ directory to find those libraries. I tried setting LD_LIBRARY_PATH prior to starting Apache. I tried hacking up all sorts of files in Python and Apache. Nothing worked. So I cheated big-time - I added the appropriate path to /etc/ld.so.conf. That did. Sure, there were some warnings and stuff when Apache started, but no big deal, right?

Well, kind of a big deal today when I installed Passenger to serve up Tracks. It uses some of the libraries that PostgreSQL ships. And those libraries were incompatible in odd ways with the system libraries. It boiled down to I had a choice: I could run Tracks or I could run Trac. Not both.

Again I tried a bunch of different things - nothing would work. I ended up cheating again but in a different fashion. This time I symlinked the three PostgreSQL libraries that mod_wsgi needed to talk to the database to /usr/local/lib. I feel dirty, but everything is working again.

Sunday, 2011 October 23 Saturday, 2011 November 19