Some Code I Deleted
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.Posted Tue, Feb 20, 2018

          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.

          
          

        