Playing with Coder (on Ubuntu)

Coder from Google Creative Lab looks really interesting:

Now I’ve got a Raspberry Pi, and I will set this up for my kids to try out, but I wanted to try it out now (and downloading ~1GB on my rural ADSL connection takes time).

Coder itself is Node.js, so you can try it directly on you computer. These instructions are for Ubuntu (naturally), but you should be able to adapt them.

First make sure you have node installed:

$ sudo add-apt-repository ppa:chris-lea/node.js
$ sudo apt-get update
$ sudo apt-get install nodejs

Next create a pi user (Coder looks for this):

$ sudo sudo adduser pi

Now check out the Coder repository:

$ git clone https://github.com/googlecreativelab/coder.git

Install the dependencies:

$ cd coder/coder-base
$ npm install

…and run it:

$ sudo npm start

(You need to run with sudo because it changes the password for the pi user.)

Now visit https://localhost:8081 (it only runs over SSL), accept the self-signed certification, and play away!

Writing better commit messages

I was browsing Twitter last night when Thoughbot linked to their post about commit messages.

This was quite timely as my team has been thinking about improving the process of creating our release notes, and it has been proposed that we generate them automatically from our commit messages. This in turn requires that we have commit messages of sufficient quality, which – to be honest – we don’t always. So the second proposal is to enforce “good” commit messages as part of reviewing and approving merge proposals into our projects. See this post from Kevin on my team for an overview of our branching strategies to get an idea of how our projects are structured.

We still need to define what constitutes a “good” message, but we will certainly use both the article from Thoughtbot and the oft-referenced advice from Tim Pope as our basis. We are also only planning to apply this to commits to trunk because, well, you don’t need a novel – or even a short story – for every commit in your spike branch!

Now, back to the Thoughtbot article, and this piece of advice stood out for me:

Never use the -m <msg> / --message=<msg> flag to git commit.

Since I first discovered -m I have used it almost exclusively, thinking I’m being so clever and efficient, but in reality I’ve been restricting what I could say to what felt “right” on an 80 character terminal. If nothing else, I will be trying to avoid the use of -m from now on.