What's a done list? Think of it as an anti-TODO list: your DONE list is where you write down everything that you've, well, done. You know that little dopamine kick you get from filing a neatly-tagged TODO or marking off something that you've finished? A done list is just that, and the only way to use it is to train yourself to stop organising and just get stuff done.

Try keeping your own done list for a week, and you'll be amazed at how you can hack your brain into actively looking for projects you can finish and tasks you can check off, just so you can write down one more thing as DONE. You don't need fancy tools to write down a list, but if you're like me and you like having fancy tools check out https://donel.ist -- the fast, easy-to-use done list tracker I built for myself. It's 100% free (no ads, "pro" tiers, or feature unlocks). And if you want to automate your done list or use it to automate other things, there's an easy-to-use REST API too.

Fast forward to 2020, and even though I've been out of the games industry for almost a decade (I did, in fact, win my own personal October challenge) that idea of the October challenge has stuck with me ever since. After leaving Palantir (I was, ahem, fired -- let's not mince words, there) I spent the next year getting, well, basically nothing done. I kept Quail ticking over, responded to a zillion bug reports and requests for help, and generally kept things on an even keel. But no new projects really made it out into the world.

Turns out being fired, even from a job you hate, can really knock the professional/creative stuffing out of you. Who knew?

But from March 2021, that's changing! To kick myself back into entrepreneurial thinking I'm setting myself a possibly-unrealistic goal of launching 12 projects in the next year, one per month from April 2021 until at least April 2022. I'm two months into this meta-project, and so far I'm two for two:

• in April 2021 Chris and I launched Sandpiper -- an inventory tracking tool for people who hate inventory tracking.
• in May 2021 I conceived, built, and launched Saascast -- a neat little tool that shows you your Stripe dashboard, but from the future.

...and so far I'm on track to ship Donel.ist in June 2021 -- a place to throw away your TODOs and track your done list (sneak peek at a public list here: donel.ist/u/doches).

Are these amazing business ideas? No, not really. Are they flawlessly executed, investor-ready products with product-market fit and a knockout marketing story? Of course not. But designing them, building them, and getting them out the door (plus marketing, feedback, maintenance, &c) is forcing me to work out muscles that I've let atrophy for far, far too long. Forward to 2021 -- let's mint some new Founders, shall we?

A couple of years later we came across Yeoman, a general-purpose tool for scaffolding new projects. It made our cumbersome git repos look amazingly cumbersome by comparison — and just a few months after I refactored our standard repositories into Yeoman generators, we were getting serious results. People were experimenting with new projects, structuring code in a sane way instead of cutting corners and just sticking it in some place that already worked. We started moving faster, and — true miracle — we noticed a few months later that we weren’t getting bogged down in anything like as much technical debt as before.

Ever since then, I’ve tried to maintain a similar set of standard generators for myself. At the moment, my preferred tech stack for personal projects is deeply boring: Java+Dropwizard on the backend, and Typescript+React on the frontend. Pretty much any new project I start, or new idea I want to play around with, starts with either:

yo dropwizard-gradle

…for a backend service that’s turnkey-deployable, or:

yo tfountain-webstack

…for a bare-bones single-page web app that’s ready for hacking. If either of those sound like your cup of (instant) tea, you can grab respective Yeoman generators from doches/generator-dropwizard-gradle and doches/generator-tfountain-webstack, or just install ‘em with yarn global add generator-dropwizard-gradle generator-tfountain-webstack.

But what I’d really suggest you do is look at ‘em as meta-templates, and maintain your own personal generator. Just the act of keeping these two up to date has forced me to stay on top of upgrades, changing trends, and new technologies that I might have missed otherwise. And those changes get more-or-less automatically rolled into everything I do over time.

Also, Yeoman’s just a dude.

     _-----_     
    |       |    ╭──────────────────────────╮
    |--(o)--|    │        Welcome to        │
   `---------´   │    tfountain-webstack    │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |     
   __'.___.'__   
 ´   `  |° ´ Y ` 

The trick, of course, is to rely on git.

This first bit is optional, but I like to maintain a master branch that always reflects what’s actually deployed in production. Pushing commits to this master branch logically means that those commits should be immediately deployed, but programmers are lazy and I realised long ago that if I could simply automate away the devops-y step of “ssh into the host, build a distribution of static files, and update nginx” then I’d never forget to deploy a finished release again.

So. Let’s automate this puppy.

First, you’ll need a git host running on your production server (I like Gitolite because it also relies on a git-push-to-deploy model, but your mileage may vary). In the project you want to auto-deploy with git, add this host as a new remote:

git remote add production git@<your production host>:<repo>.git

In your remote repository (e.g. <repo>.git/ wherever you’ve set up Gitolite on your host) you’ll find a directory called hooks. Git hooks are an incredibly powerful tool that I won’t go into the details of, but basically they’re scripts that are triggered by events happening in your repository. Create a file called post-receive in your <repo>.git/hooks directory with the following (obviously replacing <repo> with a more helpful name!):

#!/bin/bash
sudo -u integration /home/integration/<repo>.sh

Because we’re sudoing, we’ll need to add an exception to /etc/sudoers to allow our git user to execute this script (and only this script!) as the integration user. Add the following to the end of /etc/sudoers:

git ALL=(integration) NOPASSWD: /home/integration/<repo>.sh

I like to keep my git hooks super-simple, so the above simply runs another script as a lower-privilege user that we’ll use to actually do the work of deploying our pushed application. Go ahead and create that user (sudo useradd integration) , then become them (su integration; cd ~). Clone the repository you just created (git clone git@localhost:<repo>.git — you may need to set up key authentication for the integration user in Gitolite), then create the script we referenced in your post-receive hook at <repo>.sh:

#!/bin/bash

REPO=<repo>
INTEGRATION=/home/integration
PUBLISH_DIR=/srv/www/<deploy directory>/public_html

# Publish master branch to <deploy directory>
cd $INTEGRATION/$REPO

# Fetch the latest production push
git checkout master
git pull origin master

# Compile a distribution
yarn install
yarn compile

# Remove the existing distribution
rm -rf $PUBLISH_DIR/*

# Copy the compiled static files into a place where nginx can serve them
cp -R dist/* $PUBLISH_DIR

# Update permissions on the published files
chgrp -R nginx $PUBLISH_DIR/*
chmod -R 775 $PUBLISH_DIR/*

Obviously your commands to turn your uncompiled code into static assets will differ.

And that’s it! Work happily on your develop branch, and when it comes time to push code to production just commit on master and git push production master. You’ll see the forwarded output from your <repo>.sh above (in my case, the output of yarn install and yarn compile, and — assuming everything compiles properly — your production-ready assets will be pushed out all the way to where your web server can serve ‘em.

Writing succinct, helpful commit messages is the VCS equivalent of eating your vegetables — everyone knows they should be doing it, but it’s really hard in the moment to keep up a good habit. My personal trick for training myself in good habits like this is, like all lazy programmers, to try and automate it as much as possible — and when I can’t automate, I try to have my tools at least guide me in the right direction.

To that end I’ve been collaborating on a nifty editor for commit logs called Komet:

Komet highlights messages that are too long, and automatically formats your commit messages to conform to some (very low-touch) norms that will make your (and your collaborators’) git logs much more informative. Check it out!

The last time I was doing considerable web work, I kept my working knowledge of how to set up a project and start developing in the form of a Yeoman generator that I called Chassis. That repo evolved over the couple of years I used it, from a basic directory structure and starter Gruntfile to a full-fledged multi-page application in Coffeescript built by a complex Gulpfile.

All things must end, however, and I’ve made a pretty clean break with most of the technologies and best practices encoded in Chassis. For one thing, I’ve started building my web apps in a single repo for both server and client; for another, the technologies on the server side have completely changed. To that end, I’ve put together a new Yeoman generator for bootstrapping full-stack web projects, unimaginatively called: dropwizard-angular-gradle.

The technologies it relies on are basically right there in the name: the API server is built in Java 8 using the lovely Dropwizard framework, with dependencies and distribution handled by Gradle; the client is written in Typescript using Angular.js (1.x), with dependencies handled by Bower and building/live-reloading handled by Gulp. You can go from zero to fully working, deployable, testable application with just:

$ npm install -g yo
$ npm install -g generator-dropwizard-angular-gradle
$ mkdir awesome
$ cd awesome
$ yo dropwizard-angular-gradle

The generator will fetch some baseline Java, Node, & Bower dependencies, and set up an Intellij project for the API. You can start the server from within Intellij or using ./gradlew run; start a live-reloading auto-compiler for your Typescript and Less files with cd awesome-app; gulp watch. When you’re ready to deploy, build the whole kaboodle into a distribution with ./gradlew distZip.

Now if you’ll excuse me, I’m going to go bash out another couple of sweet prototypes. Shouldn’t take more than half an hour or so :).

As an example, suppose you had a DAO like:

public abstract class JdbiDatabaseBackend {
    @SqlUpdate("INSERT INTO users (username, email) VALUES " + 
        "(:username, :email) RETURNING id")
    public abstract int createUser(@Bind("username") String username, 
        @Bind("email") String email);

    @SqlUpdate("INSERT INTO ACCOUNTS (user_id, created) VALUES " +
        "(:user_id, current_timestamp)")
    public abstract void createUserAccount(@Bind("user_id") int userID);
}

and you wanted to chain these two queries together into one logical ‘create-user-and-account’ call:

// In e.g. a Jersey resource:
int userID = databaseBackend.createUser("ahamilton", "ahamilton@treasury.gov");
databaseBackend.createUserAccount(userID);

The above works fine, but I ran into the case where the second query (createUserAccount) could sometimes fail, leaving me with an orphaned row in my Users table. How much better would it be if I could ensure that either both queries succeeded or neither did?

Enter JDBI’s handy @Transaction annotation! Create a new method on your DAO that represents the transaction, and make your queries there:

public abstract class JdbiDatabaseBackend {
    @SqlUpdate("INSERT INTO users (username, email) VALUES " + 
        "(:username, :email) RETURNING id")
    public abstract int createUser(@Bind("username") String username, 
        @Bind("email") String email);

    @SqlUpdate("INSERT INTO ACCOUNTS (user_id, created) VALUES " +
        (:user_id, current_timestamp)")
    public abstract void createUserAccount(@Bind("user_id") int userID);

    @Transaction
    public void createUserAndAccount(String username, String email) {
        int userID = this.createUser("ahamilton", "ahamilton@treasury.gov");
        this.createUserAccount(userID);
    }
}

…replace your previous separate calls to createUser and createUserAccount with a single call to the transactional createUserAndAccount:

// In e.g. a Jersey resource:
databaseBackend.createUserAndAccount("ahamilton", "ahamilton@treasury.gov");

…and you’re good to go! No more orphaned rows, as JDBI will roll back any successful updates inside a method annotated with @Transaction if anything fails.

This will not do.

With that, I’d like to introduce Show Notes, a podcast search and recommendation engine. Recommendations are driven by a mix of natural language queries (keywords, episode titles, descriptions), social recommendations (what combinations of shows have other users looked at?), and curated lists (5by5, RelayFM, ‘Shows featuring John Siracusa’, etc.). You can pre-register to get notification when the final results go live, or to become a list curator.

If you’re feeling brave, you can even check out the beta.

And so I present to you rTypeset, a typographic pre-processor for HTML written in pure Ruby. Check out the code for rTypeset on Github, or install it yourself and have a play around with the output by installing the gem:

gem install rtypeset

That’s literally all it takes to get started. require the typeset gem and you’re good to go to produce beautiful, typeset HTML from your Rails apps or Jekyll blogs:

require 'typeset'

raw_html = <<HTM
<p>Yjarni Sigurðardóttir spoke to NATO from Iceland yesterday:
"Light of my life, fire of my florins -- my sin, my soul.
The tip of the tongue taking a trip to 118° 19' 43.5".":</p>
HTM

# Output beautifully-formatted HTML
puts Typeset.typeset(raw_html)

If you’re a hobbyist iOS developer with a few spare apps sitting in iTunes Connect (like me), then The App Classifieds can help you turn those apps into something useful by connecting you with like-minded app buyers. There are plenty of markets for apps, sure, but most of them are either borderline scammy, auction-only, or too expensive to make sense for smaller apps. The App Classifieds is a place to list apps that you’d be willing to sell but aren’t necessarily looking to auction right now — and listing an app is totally free. Promoted listings are also available, if you want to maximise the number of potential buyers who see your app — use the code SWIFTALICIOUS (a reference to my iOS developer blog) to get promoted listings for just $1.25/month (50% off of $5/month).

I wrote a little more about why we need a better way market for apps over at The App Classifieds blog; check it out for a better introduction. And if you’ve never sold an app or taken over someone else’s, I’d give it a shot. You’ll be surprised!

Download

One of my least favourite things in life is converting between units of measurement, especially when cooking. All my mum’s recipes use imperial units, you see, yet my kitchen’s supply of measuring widgets is exclusively metric. Constantly launching a web browser and running the conversion through Google is just tiresome — but having just made the switch from Quicksilver to Alfred, I decided to have a go at building an Alfred Extension to do quick unit conversions using Google’s calculator API.

To use it, download the extension and install it via Alfred’s preferences window. Summon Alfred as usual, then make unit conversions with:

convert AMOUNT UNIT to UNIT

It can handle anything Google knows about, so queries like

• “convert 500 grams to lbs”
• “convert 375 fahrenheit to celsius”
• “convert 2 cups to liters”

will work just fine. For brevity’s sake, you can omit the ‘to’. Happy trans-cultural baking!

My usual workflow for research-oriented coding involves prototyping a tool or model in Ruby (fast to write, easy to understand), then porting the final, working version into C for use with real data (my models are usually trained on massive statistical corpora, something Ruby is, unfortunately, ill-equipped to handle). This is all well and good, but I always miss the usability that I can so easily sprinkle into the Ruby version. OptionParser is one such gem; Ruby/ProgressBar is another.

In a moment of frustration, I re-implemented Ruby/ProgressBar in pure, unadulterated C99. If you’re interested in that sort of thing, you can grab a copy from my GitHub repository:

git clone git@github.com:doches/progressbar.git

For comparison, here is how you use a progressbar in Ruby:

require 'rubygems'
require 'progressbar'

progress = ProgressBar.new("Loading",100)
(0..99).each do |i| 
  # Do some stuff
  progress.inc
end
progress.finish

…and in C:

#include "progressbar.h"

progressbar *progress = progressbar_new("Loading",100);
for(int i=0;i<100;i++) {
  // Do some stuff
  progressbar_inc(progress);
}
progressbar_finish(progress);

More examples, including custom formatting and indeterminate progress, are in test/progressbar_demo.c.

Fountain, T. & Lapata, M. (2010). Meaning Representation in Natural Language Categories. In S. Ohlsson & R. Catrambone (Eds.), Proceedings of the 32nd Annual Conference of the Cognitive Science Society. Austin, TX: Cognitive Science Society.

Squee.

The work I presented deals with whether corpus co-occurrence can be used as a stand-in for norming data, at least in the context of a categorization task; as part of that work I collected a rather large amount of data that I am now making publicly available. The dataset extends the McRae et al feature norms by grouping the words in forty-one categories, and includes norming data, integrated into the standard McRae features, for each of the newly-added category labels.