I started writing this blog post on 2012/1/10 at 11:04:00 AM. Over a year ago!

It began:

I've been reading a book called Code, researching Bloom Filters and generally thinking more about bits. I don't think about bits very often. I do most of my programming in Python and bits are a few levels of abstraction below my typical operating plane.

A fair "bit" has changed since then.

I finished that book. It was fantastic, and gave me more of a general appreciation of the electronics that underly so much of what I get to do.

I'm now fairly comfortable operating at a lower level of abstraction; namely coding in C. I've had a hand in a number of C codebases over the past year. First was extending a k-d tree library with range query support. Then it was helping to build an application that made use of the library. Most recently I've been retooling that k-d tree library to support disk-based persistence and tinkering with writing a Python extension module in C. Oh, I also released a silly utility called preptime that prepends a timestamp to lines of input that are fed to it.

I don't have too much more to say about that. I mostly just thought I should finish this poor blog post when I saw it sitting there all lonely and unpublished.

cw

At most coffee shops and restaurants there is a sign in the restroom that says:

Employees must wash hands before returning to work.

That's great. I'm glad that employees must do that.

I think we should aim higher though. I'd like to see a sign that says:

All human beings must wash their hands before leaving this room.

To start, I'm going to post that sign in the bathroom at home. After all, there are some human beings at home that could use that reminder.

cw

There was some discussion amongst friends and family around the dinner table tonight about the Internet. Someone quipped that our kids were going to grow up in a world where the idea of no Internet is silly. It's just there.

The thought was disturbing to some, but to me, I am the one who grew up with the Internet. Let me explain.

Ever since I watched WarGames when I was a kid and saw that computers could be used to connect to each other, I was hooked. I had to connect computers and the people at either end.

When my family finally got a PC clone with a modem, I remember dialing up to a friend's computer, just so we could type back and forth to each other. Of course, only one of us could type at a time. But right there we had independently invented the Internet, social networks, IM, etc.

Later I picked up some long-distance BBS phone numbers from some pirated C64 games. Despite the penalty for unauthorized long-distance calls in the house, I had to connect to these BBSes. It was amazing, and while connected, I found phone numbers for local BBSes. I could connect without fear (but not without the good chance of someone picking up the phone and ruining my connection!).

So it turned out that there were nerds like me out there who wanted to connect their computers and their experiences with each other. There were message boards, multiplayer BBS games and pirated software. There was Fidonet for messages between BBSes, and lo-and-behold, one of the local BBSes offered a real Internet email address and Usenet access for a one-time $10 fee.

Eventually I got a hold of a dial-in number to a Kent State University mainframe. It had a Gopher client installed and I think it was CERN that offered a Gopher-to-WWW gateway or something. Anyhow, my first experience browsing the web was using Lynx via Gopher over a 2400bps modem. I think I get some nerd points for that.

By this point I was connecting to computers and people all over the world. It was/is awesome. Since then I've learned to program thanks to countless open-source devotees on the Internet, met some people who have become great friends over the Internet and I do 99% of my work remotely over the Internet.

To bring this in for a landing, I think it's cool that at Bump (where I work) my job is to write software that lets people use the Internet to connect in new ways. The Internet is not this scary, far-away place. It's right there in your hand, helping you connect with people just like it always has.

cw

Here's a test post now that I've moved my blog to Blogofile. The blog looks pretty shabby right now. I need to pull out some CSS voodoo and ditch the boilerplate template.

I'm up and running though. Hopefully new posts will commence now that I'm rid of Wordpress.

cw

I have this laptop stand. It puts my laptop at a nice height when I am using it at my desk.

I have this laptop. It has the headphone and microphone jacks at the front edge of the body.

I have these headphones. They don't play nicely with the laptop when it is in the stand.

So I hacked the laptop stand with my Dremel.

Before (cameo by my fingers, holding the front edge of the laptop up)

From 2010-12-09 (by Eye-Fi)

The Problem

From 2010-12-09 (by Eye-Fi)

After

From 2010-12-09 (by Eye-Fi)

cw

PS - These macro shots reveal to the world that my desk needs to be dusted. How embarrassing!

I blogged a couple years ago about Code Farming (tl;dr - the web is a more organic programming environment than packaged software). That post was mostly a commentary on another post I had read.

This past weekend I read "The Biology of Sloppy Code". It touches on some of those same ideas that inspired me to post about Code Farming.

Despite the title, it's less about sloppy code than it is about attempting to categorize different types of software development according to more traditional sciences.

I don't have any specific comments on the article, other than suggesting you read it. I will say that I particularly enjoyed the references to abstraction, Play-Doh and a few zingers the author threw in (real programmers vs. sissy Nancy-boy bedwetters).

cw

I've been reading the recent posts on CodeTalker with interest. I've written a handful of parsers using two different parser generators for Python: PLY and SimpleParse. My most recent work with parsing has had me gravitating toward SimpleParse so I thought I'd see how it stacks up against CodeTalker.

First I checked the web to see if someone had written a JSON parser using SimpleParse. I found Rob Lanphier's JsonOrder. It at least had a grammar that I could yank as a jumping off point.

The result after about an hour of coding and benchmarking is spjson.py. At first I tried to adapt Rob's version but I switched back to SimpleParse's dispatch processor model. Pretty much the only thing that remains from JsonOrder is the tweaked grammar.

How does it measure up to CodeTalker's JSON parser?

It's a bit slower. I added a simple timeit benchmark to the spjson.py file. I used the same JSON file that Jared (the CodeTalker author) used in his benchmarks. Here are the results of running it against the latest version of CodeTalker at the time:

CodeTalker 0.0484498786926
SimpleParse 0.0623928356171

In terms of lines of code they are nearly identical. I didn't do anything fancy to omit docstrings or comments (neither module has many of either).

$ # use 'head' to strip the 'if __name__ ...' section
$ head spjson.py -n 71 | grep -v '^\s*$' | wc -l
55
$ cat src/codetalker/codetalker/contrib/json.py | grep -v '^\s*$' | wc -l
55

The style is the biggest difference. SimpleParse uses an EBNF defined in a string to create the parser. CodeTalker uses an EBNF defined using Python code.

Both libraries let you write specialized processors for the grammar. This is one thing that I really value in SimpleParse over PLY. Your grammar and the code to act on the parse tree (or token stream) are neatly separated.

I'm still quite happy with SimpleParse. I like having the grammar in a nice contained EBNF rather than defined with Python + syntactic sugar. I'll probably give CodeTalker a look next time a new parsing task comes up though. It's great to see how the options for parsing in Python are expanding.

cw

I had a situation at work the other day where I had made a number of local commits to the default branch of my repo. I wanted to push them upstream to our central server but the feature was incomplete and I didn't want to break anything in case someone needed to make a tweak to the current code in the default branch.

I had the idea to use the `hg rebase <http://mercurial.selenic.com/wiki/RebaseProject>`_ command to move all my local commits to a new branch before pushing. It worked, and here's how I did it.

1. hg clone localrepo temp-localrepo. I always try crazy ideas in another local clone in case I trash the repo.
2. hg up to the revision before my local commits that I want to put in a branch.
3. hg branch newbranchname && hg ci -m "Branching for reason foo." This creates a new branch and head that can be used as a rebase destination.
4. Now for the rebase. I needed to rebase the first changeset in my series of local changes onto the newbranchname changeset. Something like hg rebase --source 94 --dest 105.

That's about it. After verifying that it did what I wanted all that was left was to repeat the steps in my main local repo and push to the central server.*

cw

* Of course what I actually did was push these changes to my main local repo and then to the central repo. Woops. That left me with the changes both in ``default`` and in ``newbranchname``.

Don't do that. Repeat the steps after you've tried them in another local clone. I leave recovering from such a situation with ```hg strip <http://mercurial.selenic.com/wiki/Strip>`_`` as an exercise for the reader.

In an application I'm working on at work I want to be able to display various bits of version information in the UI. This goes for both production deployments from Python EGG files and in development running straight out of the repository.

We use Mercurial for revision control so it is a logical choice for a version information source. The result of some hacking is my first Mercurial extension and commit hook.

Mercurial Version Info Plugin.

See the README file rendered at that link for the details. Click here to download version 1.0.

cw

I noticed the same question on c.l.p that Steve Ferg responded to on his blog. I was feeling too lazy to respond to the thread earlier but I thought I'd throw my idea up on the ol' blog before wrapping up for the day.

I think this is a classic use-case for class methods. Here is my implementation.

class Vector(object):
    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

    @classmethod
    def from_sequence(cls, sequence):
        return cls(*sequence)

    @classmethod
    def from_vector(cls, vec):
        return cls(vec.x, vec.y, vec.z)

    def __repr__(self):
        return "Vector(%s, %s, %s)" % (self.x, self.y, self.z)

if __name__ == '__main__':
    print Vector(1,2,3)
    print Vector.from_sequence([4,5,6])
    print Vector.from_sequence((7,8,9))
    v = Vector(10, 11, 12)
    print Vector.from_vector(v);

Here is the output from running the script:

Vector(1, 2, 3)
Vector(4, 5, 6)
Vector(7, 8, 9)
Vector(10, 11, 12)

I like the classmethod route because it is obvious what the code is doing, it makes it easy to add new from_\* methods and keeps the general __init__ method clean.

cw