Code Kills

One of my big beefs with DVCSs is their version numbers.

For example, take two changesets I committed today: 6899 and 02a9. Which one is more recent? How many changesets separate them? Without access to a repository, there's no way to tell… But that sort of information can be useful to have.

Two of the three DVCSs I have experience with, bzr and hg, both take steps towards solving this problem.

bzr tries "really hard" to give everything a sequential ID, and uses those IDs in the UI (as far as I can tell) all the time (it does use unique hashes under the hood, but they aren't shown very much):

$ bzr log
------------------------------------------------------------
revno: 3
message:
  A merge
    ------------------------------------------------------------
    revno: 1.1.1
    message:
      A conflicting change

hg assigns local aliases for each changeset, and displays those aliases along with hashes:

$ hg log -r 4:6
changeset:   4:658109dca65b
description:
A merge

changeset:   5:bd8053bf02f1
description:
A conflicting change

And, of course, git doesn't stand for this sort of frivolity and shows pure, unadulterated, hashes:

$ git log
commit aa55884d693c92da6dc96eb7a45c9ecd774fefc2

    A merge

commit 8e47937468071ae29d385b76ff925d231c65b97b

    A conflicting change

I'd like to see this taken a step further, though: I'd like the changeset hashes themselves to encode some basic information about where they live in the repository.

For example, one way to do this could be using the first two bytes of the hash to store the distance from the root*, and the next two bytes to store a "repository id", which is generated once, when a repository is first cloned or initialized.

So, for example, one of these changeset hashes might look like this: 0afc53bf02f1, and committing again to the same repository would produce 0bfc109dca65.

Of course, this scheme doesn't guarantee anything - it's entirely possible to generate two completely different changesets with the exact same four-byte prefix… But in the general case, this sort of scheme could make it significantly easier to figure out how arbitrary changesets relate to one another.

*: Doug Philips suggested this - thanks.

Be very, very wary of anyone who suggests that "self documenting" code can replace comments.

Case in point: I consider myself a mediocre programmer, who is usually capable of producing mostly coherent code.

Below is a hunk of the code I wrote today - keywords are blue, variables are white, comments are green:

I don't think I could take much away from that without doing a serious disservice to the poor person (probably me) who will be tasked with fixing the inevitable bugs in the above code.

There are a few things I do every time I start a new Django site, and one of those things is add my path lambda to the top of settings.py:

    import os
    ROOT = os.path.abspath(os.path.dirname(__file__))
    path = lambda *args: os.path.join(ROOT, *args)

From then on, it's drop-dead simple to create absolute paths which are relative to the root of the project (or, at least, the directory which contains settings.py). For example:

    >>> path('media/')
    '/Users/wolever/code/review_anywhere/media/

And some other places where it is useful:

    DATABASE_ENGINE = 'sqlite3'
    DATABASE_NAME = path('db.sqlite3')
    ...
    TEMPLATE_DIRS = (
        path('templates/'),
    )
    ...
    DATA_DIR = path('data/')
    ...

(this is a post intended for Google - sorry for bothering you, faithful RSS readers)

I've been setting up encrypted backups for my Linux machine, found that cryptsetup gives a really cryptic and unhelpful error message:

$ cryptsetup luksFormat /dev/sda3 ~/.backupKey
WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify
that /dev/sda3 contains at least 133 sectors.
Failed to write to key storage.
Command failed.
$

Google will suggest lots of things… But none of them solved my problem.

What was I doing wrong? I needed to run cryptsetup as root.

D'oh.

I picked up an Arduino yesterday, and I was quite dismayed by how much work it took to build/flash from the command line.

After some hours of Googling, though, I finally found an up-to-date Makefile, and it didn't take too much to make it "just work" with the default install of Arduino.app on the Mac.

To use this Makefile, simply drop it into the project sketch directory, then run make then make upload. You may need to tweak some variables (eg, it assumes Arduino.app is located at /Applications/Arduino.app), but that is fairly straight forward.

Get the Makefile from: http://gist.github.com/273821.

Just a note: I haven't had much time to tinker with this system yet, so it may have some serious issues... If so, drop me a comment below.

Also, leave a comment if you want me to let you know if (when?) I update this.