After 15 years, this site has finally received a long overdue design refresh. Here’s everything I do to make it a reality.


I use a 13” MacBook Pro with a large external monitor to compose all of my essays. Years ago, my Windows laptop died and I decided to see if life was better on the other side. I’ve come to like MacOS, after some initial frustrations, and now I have a hard time imagining going back.

I write my essays in hand-crafted HTML using Webstorm. The files are served using a custom content management engine (CME) I originally wrote for my Let’s Code JavaScript screencast. It’s a polyglot engine, so I could theoretically use other markup languages, such as Pug, Markdown, or AsciiDoc, but I’m used to HTML and I haven’t bothered setting up the alternatives.

Everything required to make the site go, including all the content, are stored as static files in a git repository. I run my CME locally for testing, then push to my web host when I’m ready to go live.

I’m paranoid about backups and revision control. There’s decades of work here. That’s why all of my essays are written in a text editor and stored in git. Most blogging engines save your work in the cloud. Easy, but not fault tolerant. I’ve been writing for nearly two decades and plan to continue writing for several more. My stuff has to be easily scripted, version-controlled, backed up, and trivial to deploy to another web host when (not if) my host goes under... which it already has. Twice.

My site is backed up many times over. First, in the git repo on my laptop. Second, in a copy of the git repo on my web host. The computer itself is backed up to two redundant drives with Time Machine every hour. I also make a bootable whole-disk backup using SuperDuper! every day. Once per quarter, I rotate one of the backup drives to an off-site location.


The site was originally designed in 2005. For 15 years, it had a very... “classic” look, and it didn’t work well on mobile. In 2020, I finally redesigned the site. I’m very happy with it, and particularly proud of its dark mode support and custom print styling1.

1Try it out! Click the “Print” button at the top of this page, or just tell your browser to print the page.

I’m not much of a graphic designer, so I took a page from great artists: I stole whatever I could. Dave Liepmann’s Tufte CSS, based on the work of Edward Tufte, was my principal inspiration. The home page was inspired by Michael “GeePaw” Hill’s website.2

2GeePaw Hill is super smart and thoughtful about Agile engineering practices. Go read his stuff.

The site’s fairly monochromatic, but there’s bits of color here and there. The colors are based on my Let’s Code JavaScript site, which was professionally designed by the talented folks at Primate.

Icons3 are in SVG, which I want to love, and probably will someday. After they make it better. I purchased my icons from The Noun Project. Their tagline is, “Icons for Everything,” which certainly seems to be true. I also use emojis as icons4 in a few spots, mostly because they’re so much easier to work with.

3 Subscribe icon Twitter icon Search icon Print icon

4 ⭐️ 📖

Fonts come from Adobe. I’m using Utopia for my main serif font, Cronos for my sans serif buttons and some links, and good old Courier for monospace—or Menlo, if you happen to have it installed.

Finally, lots of elbow grease got me to the result I have today. MDN, the Mozilla Developer Network, was invaluable for figuring out the style sheet. CSS has improved a lot since 2005, and I think I might even... like it? Well, almost.

Nearly all of the original design has been wiped away, but one I did keep one of my favorite aspects: printed URLs. I learned that from Eric Meyer’s “Going to Print” article.


The site is hosted by Heroku and runs on a custom content management engine I wrote in Node.js. Logging is handled by Papertrail, which also sends me email and text message alerts when things go wrong. I use Pingdom as a backup alerting system. TierraNet makes sure that my domains point to the right place. Google handles my analytics. (Sorry about that.) I use DuckDuckGo for my site search and Google Groups for update emails.

This combination of custom source code and outside services gives me total control over the code behind the site while outsourcing a lot of the complexities of modern software stacks. It’s a nice tradeoff that allows me to focus my attention on more important things. The code is very well tested, so it almost never fails. Because there’s no database—everything’s in static files—and minimal service dependencies, my uptime is the same as Heroku’s, and requires no effort from me.


In the very beginning, the site was rendered by a very simple static site generator I wrote in Ruby. But for 15 years, from February 2005 to July 2020, the site was rendered by the ultra-minimalistic Blosxom. That’s when I started blogging in earnest; you can see my very first entry here.

Back in the day, Blosxom was the only blogging software I could find that actually allowed me to store entries locally, in files that I could back up and put in version control, rather than on a database on the server. (Nowadays, of course, static site generators are a dime a dozen.) Blosxom ran on Perl 5. It did the job, but my volume of content caused performance problems, and it had a lot of idiosyncracies. It was low maintenance, but also constrained what I could do. I’m happy to finally be rid of that technical debt.

Colophonem adidi.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.