How This Site Is Built

Current Philosophy and Design

The current site is really pretty simple, based on a couple of lessons learned in the past (see below).

First, the site itself does not require an application server. It's just static files served up by a boring HTTP server (lighttpd at the time of authoring). The web server configuration is kept pretty simple, but most of it is optional. This also means it'll run on any architecture and operating system. I can also rely on the web server's builtin handling for web cache validation.
I author content in vi using markdown syntax.
When I make a change, I run one of a couple of short python scripts that renders part of the site from templates. I am careful what modules I use so I don't get into a position where I depend upon something that's problematic to get running.
Backups involve calling tar and scp via cron.
Restoring from backup then is of course just untaring a backup, and maybe deleting any files I don't want around any more.
Encryption is provided by the letsencrypt project, with automated handling of certificate renewal, also through cron.

Overall it's working out well. The resource requirements are trivial, and migrating/upgrading/etc is easy. I don't even require a shell account as I could just as easily author the content somewhere else and sync it over via whatever means were provided. I could host the site anywhere I want, and on any hardware or operating system that suits my fancy.

Site History

I originally launched this site back in 1999 as a weblog. I think the initial software behind it was ColdFusion (then owned by Allaire) with a Microsoft Access database running on Microsoft Windows (maybe an early preview of Windows 2000 - I don't remember but that's likely), but I recall that only lasted a few months before I moved it over to PHP3+MySQL on Linux (Red Hat 5.2?). That more or less lasted for a few years excepting upgrades to Red Hat, MySQL and PHP but it eventually moved to Apache Tomcat and MySQL on Debian where it lived until I quit updating it around 2010. It was a good run.

During most of that time I was employed as some sort of software engineer - either fulltime, as a side duty, or via contracts - and most of that software was web based. I grew a lot in that time, going from static websites, to sites with some clientside javascript, then to CGI and dynamic content to application servers with databases behind them and on to AJAX and the like.

And where did we end up here? Back to static content - mostly. Kinda.

What Sucked Along the Way

ColdFusion

ColdFusion was honestly some pretty great technology at least at the time I used it. I think the reason I quit using it was because it didn't run on any of the free UNIX systems of the day (I think it might have had a Solaris SPARC port, but I didn't have access to any SUN hardware running Solaris then). Looking at it now, I suppose I don't like how it encouraged mixing presentation and application logic, but with some careful attention one could avoid that. It was also commercial and that didn't help. From what I gather it's still a product with a loyal following - just not me.

PHP

The good: it makes the already easy absurdly easy (but keep reading...). It's free and open source.

The bad: Google "PHP Sucks". A good amount of what you'll see is right on. If you disagree, I'd like to politely ask that you not tell me why.

Tomcat

Tomcat was a nice step up from PHP as far as promoting good design and organization. I actually like Java as a language (though not necessarily as a runtime), and what SUN did with JavaServer Pages and custom tags to lower the barrier for entry to model-view-controller was really very nice.

That said, as is often the case with Java apps, getting it all working from a fresh start (say, hardware update, or an OS reinstall) was difficult. The database data had to be imported and authentication configured for the right db and tables. I had to install a JRE - but not just any JRE - along with packages for Tomcat. Then a datasource had to be defined in various XML files for Tomcat to be able to connect to the database which matched what I had in my app, the webapp itself had to be installed, and various Java libraries dropped into specific locations. Apache had to be configured to forward a couple paths to Tomcat via a connector service - and probably more stuff that I'm leaving out. Every time I'd get it working, I would update a text file I kept around for the steps with what new twists were involved this time, and then carefully back away from the whole mess. At one point I started hosting it on a VM and I'd just drag the virtual machine image around, converting it to work in different hypervisors and hoping that security updates would still apply cleanly. And that's assuming that I hadn't made any updates to the app itself!

There was also a long time where getting a JRE to run that was compatible with Tomcat on platforms that weren't mainstream was difficult or impossible. Sure, Java ran fine on Windows, Linux x86, and Solaris SPARC - but not much else - and I've always had a penchant for using odd setups like NetBSD on 32bit SPARCs, IRIX via MIPS, or Linux ARM. Those were mostly a no-go. I hear this is not an issue now as Java itself is much more free and available than it used to be - but back in the day that wasn't the case which was really pretty sad considering "write once, run anywhere" was one of Java's slogans.