I have a number of "static" microsites, in the sense that they're just plain old HTML with a minimum of Javascript supporting their operations. The oldest one is the Journal Entries site, which has been a Markdown archive of my vast and adult space opera since 1995 or so... which is quite a long time! It's had a number of generations since then; the first version had a simple perl-to-html converter, the output of which I would hand-edit, along with the index page. In 1995, Markdown didn't exist, so I was using an ad-hoc definition that I colloquially referred to as "Usenet emphasis mode," since it was more or less the same syntax I used when posting the stories to the text-only Usenet forums.

It's next life was in Emacs Muse, with a lispy header (semicolons in the first column) to describe the content, and now it's Zola Markdown in its current form, which is simply that every story has its own Markdown file with a TOML-based header to describe the story's metadata: title, publication date, order in the series, and so forth.

I was looking for a replacement tool when I found Zola. I've been growing steadily disillusioned with the quality of Python3's backward compatibility, and the breakdown I experienced trying to get Python3.10 to run the generator made me insane. I considered Hugo, but settled on Zola, if only because it's written in Rust rather than Go, and I'm a partisan about those two languages.

The Python to Zola distinction is huge; generating the site went from two minutes to nine seconds, and there's auto-reloading when in development mode.

I'm preparing another, more technical, document for many of the things that I learned while I was doing the conversion, but I wanted to capture some process notes here, if only for myself.

Continue Reading



In software development, Agile is the most popular form of project organization and Jira by Atlassian is the most common tool used to keep track of that organization. But two different ideas from two very different places and times have convinced me that Agile is the primary cause of developer burnout.

Continue Reading



I make it a habit to never respond directly on The Orange Site, but a recent post there caught my attention and I wanted to respond to the poor guy. He said that he was on his third startup since getting out of university, but he'd never worked at "a big company" and feared that he'd somehow made it to 30 (OMG!) without ever learning "the right way to do something."

So here's the scoop: While I've never been in a FAANG, I have been at four middling-large corporations, the ones with "real" HR personnel nicked from Microsoft or Amazon or Google and "real" programmers lured away from Netflix and Apple: AOL, F5 Networks, Isilon/EMC, and Splunk. I've also been at a half-dozen startups, and here's the basic truth:

There is no right way.

Every company, hell, every team, has to learn on their own how to move forward in their environment. This world changes fast when it comes to management and when it comes to deployment. In the past twenty years, on the front end I went from raw Javascript, to Prototype, jQuery, Backbone, React, and now NextJS, learning a new "how you do the front-end" framework every four years. On the back, I went from C to Perl, Python, Node, and now Go.

The only skill that hasn't changed in all that time is SQL. It's gotten richer and faster, but it's still pretty much SQL.

Continue Reading



I recently had a chance to finish up a major refactor of the codebase for BFDLang (Bureaucratic Form Design Language), a hefty (and now Turing-complete) language for describing, well, bureacratic forms to web documents. I work at an insurance company, and BFDLang gives the administrative staff the power to describe a form in a spreadsheet and immediately see what it would look like as a web document; it's a powerful, in-house no-code solution for them backed by a ton of code, mostly written by myself and two junior developers. The refactor was huge, and complicated, and I couldn't have done it with JavaScript. TypeScript saved me weeks of work.

Continue Reading



Psychologists know what makes someone a creep. A "creep" is a person who makes you feel uncomfortable or vaguely threatened, but who you are obliged to be near for professional or social reasons. You don't like being around him or her, but you can't leave the room because your professional or social situation require that you be there.

By this definition, Apple is a creep.

Continue Reading