Some Code I Deleted

I recently deleted a couple non-trivial scripts from my dotfiles and I’m proud of that.

As I have been porting some of my scripts to go I have tried to be careful to avoid spending effort on scripts that are not worth porting. Here are a couple examples that I recently avoided porting by deleting entirely.

🔗 live-email

I try my best to stay in a terminal at all times. My text editor is vim, I use a console based slack and irc client, and my email is handled with mutt. Unfortunately though, my local view of my email can be a minute behind when I am connected to the internet. This means that if I need to reset a password or fill in a token that was emailed to me I need to just wait.

I don’t like waiting, so I wrote live-email.

The general idea behind live-email is that you want to be able to immediately list what’s in your inbox and then examine the contents. I figured because it was basic it would be fast and thus useful. I did use it a few times, but sadly due to a bug in the Python standard library, it was rendered almost worthless, because it could only work for one of my two google hosted email addresses. Furthermore it’s not fast because IMAP is generally not fast.

I was looking forward to fixing this while migrating to Go (ignoring the fact that all of the Go based netrc parsers have the exact same bug as the Python one.) I considered how I might improve on the original live-email interface, which was basically one-shot commands that print to standard out.

My idea was to write the emails downloaded via IMAP to a directory and immediately invoke mutt, pointed at the directory. Sounds pretty great; it’d be fast after the initial download and the interface would be pretty much what I’m used to.

But then I rememered that mutt has built in IMAP support. Why write code to sync IMAP, surely with bugs, and no documentation, and no tests, when something that already works exists?

So I did a little research and added a parameterized mutt profile to do IMAP based email. I also added a little wrapper script so that I could just run imap-mutt to see a live view of my inbox. Far superior.

🔗 graph-by-date

Another tool I made, over half a decade ago at this point, is something that will graph data by date. I don’t use it super often but I do use it; here’s an example invocation (against this blog):

$ git log --pretty=%ai |
  sort |
  cut -f1-2 -d' ' |
  group-by-date -d |
  graph-by-date -i '%F %T'

And the resulting graph:

Now on the one hand, this script works well. Impressively the underlying graph library, which pulls in something like three dozen libraries on CPAN, has never been hard to build and I don’t think has ever failed tests. That’s awesome. On the other hand it’s 70 lines of barely documented, untested Perl. Given my recent flirtations with gnuplot, I decided to just deleted it and document some gnuplot boilerplate.

Using the boilerplate mentioned above I wrote this gnuplot script:

#!/usr/bin/gnuplot

reset
set terminal png

set xdata time
set timefmt "%Y-%m-%d"
set format x "%Y"

set xlabel "Time"
set ylabel "Commits"

set title "Commits per Day"
unset key
set grid

plot "./out.csv" using 1:2

and this shell script:

$ git log --pretty=%ai |
  sort |
  cut -f1-2 -d' ' |
  group-by-date -d -o %F |
  sed 's/,/\t/' > out.csv
$ gnuplot example.plot > foo.png

And the resulting graph:

Honestly I can’t call either graph clearly better, but the latter one uses a purpose built tool that requires less than a quarter of the lines of code to get something more or less just as good.

One of my friends is fond of saying “no code is better than no code”. I tend to agree. Code is fun to write, but it’s such a liability, especially if you have less time than when you initially wrote it. This is why I think so much time can be spent on automation or documentation; because it helps out future me. But the most foolproof way to win is to just not play, given the option.

(The following includes affiliate links.)

The Pragmatic Programmer is a book that has this kind of philosophy in it. I’ve mentioned this book before. I can’t stress enough that, for people who are early in their career or even just stuck, this book is a great resource.

It’s hard to recommend a programming book that shows how to delete code. I would humbly suggest From Bash to Z Shell, if only because shell is so flexible and, when written well, can reduce huge amounts of code by reusing much more well specified individual pieces.

If you're interested in being notified when new posts are published, you can subscribe here; you'll get an email once a week at the most.