Nearly a year ago I decided to divest myself of Google as much as possible, partially for the usual privacy concerns, but mainly I was concerned that too much of my life was tied up in a free service whose customer service is nearly nonexistent; if somehow my Google account got borked I had no recourse. So I decided to switch to paid services wherever I felt the service offered was valuable enough. Email was one of them, and I've been very happy with Fastmail ever since I've switched. They offer all the usual protocols, have a webmail interface every bit as good as Gmail's (including fast search with a rich query language), and a whole bunch of other features I'll never use but I'm glad exist. Also, the one time I needed customer service, it existed.

My one quibble with their webmail client is there's no way that I've found (maybe it's hidden somewhere) for plaintext emails to render in a monospace font. I get a lot of diffs via email where monospace is important for legibility, and frankly I kind of find monospace more readable in general, although I know that assertion is provably false.

All this is going a long way around showing off a small CSS hack to get plaintext email rendering and composition to be done in a monospace font in Fastmail's web client. I used Stylish for Google Chrome, but pretty much any CSS-hacking extension of your browser of choice should work:

@-moz-document url-prefix("https://www.fastmail.fm/mail") {
  .message pre {
    font-family: monospace;
  }

  .TextView textarea {
    font-family: monospace;
  }
}

The snippet is also in a gist or you could install it directly into Stylish from userstyles.org

In closing, you should put two spaces after a period. drops mic

Taskwarrior, my to-do list software of choice, recently released the taskd task server to sync tasks across multiple devices.

Prior to this, your choices were to sync with Dropbox, which worked for the most part but didn't have real conflict resolution if multiple clients wrote at the same time, and a special "merge" command, but merging only really worked between exactly two peer clients and did not really support an arbitrary number of clients talking to a canonical server.

taskd fixes all this, so I wanted to migrate as soon as possible. Unfortunately, the blessed way of migrating to taskd only migrates tasks you have not yet finished; your already completed tasks are not synced. I have several years of completed tasks I'd like to keep, so I looked for a solution. Luckily, it is pretty simple to modify the import procedure to import both pending and completed tasks.

On your first import, the documentation says you should run:

task sync init

Instead of doing that, you need to trick taskwarrior into initializing with both your pending and completed tasks. To do that, all you need to do is append your completed.data file to pending.data; the task client just sends pending.data, but the two have the same format and the server knows how import completed tasks just fine. Put simply:

cp -r ~/.task ~/.task.backup # For safety
cd ~/.task
cp pending.data pending.data.old
cat completed.data >> pending.data
task sync init
mv pending.data.old pending.data

That should import everything. If you're like me and you have a huge history with taskwarrior, the server may complain that the request is too large. If you get an error like this, all you need to do on the server is increase the request size limit in your server's taskdrc:

request.limit=10485760

You should then be able to import a larger backlog. The paranoid will probably want to undo this change to request.limit after the initial import to protect server resources once at steady state.

You can now reconstitute both completed.data and pending.data on a fresh client by running:

task sync

Of course, you'll need to get the proper keys and certificates installed on the new client before syncing.

Have fun doing tasks!

I use meld as my git merge tool, and the latest version of Ubuntu (13.10) changed its interface, breaking my merge workflow.

Previously, I had a .gitconfig containing:

[merge]
    tool = meld-autoresolve
    defaultToUpstream = true
[mergetool "meld-autoresolve"]
    cmd = meld --diff $LOCAL $BASE $REMOTE $MERGED

Which shows a 3-way diff, automatically picks all nonconflicting changes, and writes the resolved file to the correct location.

Meld 1.7 changed its CLI UI (thanks, GNOME), so to get a 3-way diff which writes to the correct file and also auto-picks nonconflicting changes, the proper invocation is now:

[mergetool "meld-autoresolve"]
    cmd = meld --output $MERGED $LOCAL $BASE $REMOTE --auto-merge

One year ago I went to a Python meetup where William Bert made a presentation on gensim, a "topic modelling" library for Python. One of the most practical uses of topic modelling is finding similar documents from a large corpus. For example, where Google search takes a query as an argument and returns documents based on that query, Google News tries to organize stories from multiple sources into clusters based on the same topic or event.

In memory of Google Reader shutting down tomorrow, I present rsscluster, a small script which demonstrates the usage of the gensim library. One of the problems I ran into with wanting to play with gensim was finding a large corpus of documents with which to populate the database. When Google Reader announced it was closing and I looked for a new home for my feeds, I found a great corpus to play with.

My typical set of feeds contains about 3000 stories, which isn't a huge corpus, but enough to play with. Crucially, there are a number of feeds I subscribe to which are likely to produce "similar" documents. For example, Ars Technica and The Verge will probably both have stories about the latest Apple keynote, while The Washington Post and NPR will both cover recent Supreme Court decisions.

You can see how well rsscluster did in finding stories similar to those in my feeds published today (June 30th) here. For as little effort I put in and considering how small the corpus is, it did a pretty good job of detecting clusters around recent events (Edward Snowden and the NSA, a presidential tour of Africa, John Kerry speaking on the Middle East). It did a slightly worse job categorizing Supreme Court stories, as they've been pretty active lately and ruled on a lot of disparate issues. Gensim decided to cluster those up more than it should have. Finally, some of my feeds are just not very semantically rich, and it decided to cluster a bunch of Steam sales together. One feed is particularly degenerate in that it only contains the word "NO" in each entry. Gensim dutifully clustered all of those documents together, but those documents probably don't belong in the corpus at all.

Again, this is a really naive use of gensim (I spend more time parsing command line arguments than actually exercising the library), but it let me get gensim testing out of my system and it demonstrates how easy it is to set up a pretty powerful document similarity search engine. Hopefully someone else can also be inspired to play with it, and will find a better scenario with which to exercise it.

See it on github.