…about maps, open data, Git, and other tech.
(Credit: Flickr’s Carine06, CC-BY-SA)
Here’s my method of keeping track of stuff to do. Other tools just didn’t work for me. Most to-do list tools make two assumptions, I think:
My work, technology for academics, tends to involve coordinating lots of little projects with lots of different people. At any given moment, there are few tasks “in my court”, and they tend to be small. My primary responsibility is to keep all projects moving, and ensure that projects aren’t held up by a task being with me too long.
So, I ran with the ball in my court / ball in your court metaphor. It’s useful when:
“Projects” here can be very small, and often include very early stage proposals that haven’t formed into anything very concrete.
Trello Tennis in (fictious) action
To start with, the two most important columns:
The goal each day is to move projects from the “my court” column to the “their court” column. I periodically review “my court”, placing the most urgent items at the top. I also review “their court”, checking whether I should follow up or offer assistance.
More columns, that turned out to be useful for me:
Trello works really well for this.
The name of each card consists of both the project name, and a quick summary of my current task (if in my court), or what I’m waiting on if in theirs. Examples:
What’s particularly fantastic about using Trello is that each card can also track all the work on that project. Changing the title automatically creates a history trace, or I can add comments to record more information. Need somewhere to record a server name and login details? Use the card’s description field.
You can also use coloured labels to group projects, such as tagging by university in my case.
Of course, each individual project frequently has its own task tracking system: perhaps another Trello board, Github issues, Pivotal Tracker, Google spreadsheets etc. I link to them from the card’s description, ultimately tying together all information systems for all projects under a single roof.
Each day (or whenever):
To make this natural, I order the columns from left to right as follows: Wut, My Court, Blocked, Their Court, All Good, SEP, Archive. Stress is on the left, calm is on the right.
The goal is to get your board to look like this blissful fantasy:
A totally successful day in Trello Tennis land.
These examples are actually tiny compared to (my) reality. By the end of 2013, I had 21 active cards, plus another 10 inactive (SEP and Archive). If you find this technique at all useful, or have any improvements, I’d love to hear about it.
(Added 4 Feb 2014)
Sometimes it gets daunting looking at the huge mounds of work in front of you. Filtering can help cut through the distraction. Two types have worked for me:
Are you working for a particular client today, and don’t want to see anything related to any other clients? Assign one label per client, then turn on the filter!
To focus on just one or two tasks that you need to finish, first assign yourself to those cards. Then, filter to only show cards that you’re assigned to. This feature is intended for collaboration, but it works nicely.
I run lots of Linux servers. I create them, install some stuff, mess around with them, forget them, come back to them…and forget my credentials. My life used to look like this:
$ ssh -i ~/steveko.pem steveb@115.146.83.268 Permission denied (publickey). $ ssh -i ~/steveko.pem sbennett@115.146.83.268 Permission denied (publickey). $ ssh -i ~/stevebennett.pem steveb@115.146.83.268 Permission denied (publickey). $ ssh -i ~/steveko.pem ubuntu@115.146.83.268 Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-26-generic x86_64) ...
This got really tedious. You can’t memorise many IP addresses, so you’re constantly referring to emails, post-its or even SMSes. Then you rebuild your server, the IP address changes, and you’re lost again.
And because some of the servers are administered by other people, I can’t always choose my own user name, so more faffing around.
So, here’s my solution:
Give each server a name. Ignore the actual hostname of the server, or what everyone else calls it. My convention goes like this:
<infrastructure>–<project>[–<purpose>]
Examples:
The key here is minimising what you need to remember. If I’m doing some work on a project, I’ll always know the project name and whether I want to work on the prod or dev server. Indeed, it’s an advantage to have to specifically type “-prod” when working on a production machine.
When I create a server, or someone tells me an IP, I immediately give it a name, and store it in /etc/hosts. The file looks like this:
## # Host Database ## 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost 115.146.46.269 nectar-tunnelator 136.186.3.299 swin-bpsyc-dev ...
This has the huge advantage that you can also put those names in the browser address bar: http://nectar-tunnelator
If a server moves location, just update the entry in /etc/hosts, and forget about it again.
The SSH configuration file can radically simplify your life. You have one entry per server, like this:
Host latrobe-vesiclepedia-dev User steveb IdentityFile /Users/stevebennett/Dropbox/VeRSI/NeCTAR/nectar.pem Port 9022
Notice how we don’t need to spell out the IP address again. And by storing the access details here, we can connect like this:
$ ssh latrobe-vesiclepedia-dev
So much less to remember. And because it’s so easy to connect, suddenly tools like SCP, and SSH tunnelling become much more attractive.
$ scp myfile.txt latrobe-vesiclepedia-dev $ ssh latrobe-vesiclepedia-dev sudo cp myfile.txt /var/www
In reality, it gets even simpler. Most of my NeCTAR boxes are Ubuntu, with a login name of “ubuntu”. The “nectar-” naming convention proves valuable:
Host nectar-* IdentityFile /Users/stevebennett/Dropbox/VeRSI/NeCTAR/nectar.pem User ubuntu
That means that any NeCTAR box using that key and username doesn’t even need its own entry in .ssh/config:
$ ssh nectar-someserver
Steve Bennett blogs 
Recent Comments