Some people blog their way through Knuth or SICP. My attention span
is somewhat shorter lately. I’ve recently begun watching Gary
Bernhardt’s excellent Destroy All Software screencasts, and I
thought it’d be fun to blog my way through it with a series of short
posts on what I learned from each episode. I’ve watched a few as I
start this, and I think that if you write software and care about
writing good software, you should probably go buy DAS now.
I watched Episode 1 on my way to OSCON about a week ago. In it Gary
works through building a small bash script to calculate some
statistics on a git repository (for example, how many lines of code
there were at given points in time). The git plumbing bits were pretty
interesting, but it was the actual process that was really educational.
One of the first things he also does is map a key to save and then run
his script. I almost found myself coveting Vim for a moment, because
it seems obvious now that having an immediate feedback loop is
actually superior to switching between Emacs and a terminal.
As Gary builds out the script, he points out a few things, like using
set -e, and “always quote your arguments”. (It makes a missing
argument fallback to an empty string, which programs like grep are
perfectly happy with.) That sort of casual, fingertip knowledge is a
joy to watch. I guess I haven’t written enough in bash to know
better than to check my exit codes manually for things. set -e is
obviously better. Way better.
And have you ever considered that bash control structures like
while and for have a stdin and stdout? They do. It
seemed obvious once I saw him do it, and when I think about the way
bash works, it makes sense in a consistency sort of way. But until
now I’d never considered piping the output of, say, grep to a
Watching DAS S1E1 I learned a few things about shell scripting that
seem really fundamental, which I wish I’d have known about for, well,
years. I also realized that I have this weird mix of git knowledge: I
understand that it’s a directed acyclic graph and a bunch of the
underlying structures. I also am proficient at using magit to
manipulate a repository within Emacs. The git porcelain? Not so much.
Finally, I thought it was interesting to see and listen to Gary
refactoring a bash script using some of the same principles that I use
when looking at Python code. Specifically, wanting to make code easy
to read, not just execute.