Print

Colophon

Jul 22, 2020

Every so often, I describe what I do to make this site a reality. For the four of you who like to watch me gaze at my navel, I have good news: today is one of those days. For the rest of you, I’m sorry. It’s one of those days. You can move on. I won’t be offended.

Okay, here goes.

Production

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 yet.

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 commit and deploy 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 quarter, I rotate one of the backup drives to an off-site location.

Design

The site was originally designed in 2004 and it shows. Boy, does it show. But it’s functional and there always seems to be some other priority getting in the way of a redesign.

The biggest challenge for me in originally making the site was my complete lack of web design skills. (Software engineering, yes. Graphic design, no.) Sitepoint got me started and A List Apart carried me through. I borrowed liberally from Jeffrey Zeldman in creating the sidebar, as permitted by comments in his CSS.

For the color scheme, Jason Beaird’s "Color for Coders" article helped me get started and Visibone’s Color Laboratory allowed me to pick web-safe colors. (I don’t think we have to limit ourselves to 216 “web-safe” colors any more, but... did I mention the site was designed in 2004? I cheated a bit for quotes, though.)

I also took advantage of some royalty-free icons. The RSS feed icon (sample icon) came from Feed Icons; the Twitter icon (sample icon) is resized from an icon I got from Productivedreams.com; the print icon (sample icon) came from graphicPUSH; the star icon (sample icon) came from 1ClipArt; and the spinner (sample icon) came from Andrew Davidson.

Finally, lots of trial and error got me to the result I have today. W3Schools’ CSS Reference was invaluable for making it work, but these days I prefer MDN. Eric Meyer’s "Going to Print" article provided the finishing touch for my print stylesheet by showing me how to automatically insert URLs after printed links.

Hosting

The site is hosted by Heroku and runs on a custom content management engine written 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.

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.

History

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.