When it comes to computers, here’s how I like to work:
* I like the things I make to look good and right. If they don’t, I get frustrated and dissuaded from creative work.
* I prefer to put in a lot of thought and extra work on the front end in order to get repeatable, high-quality results with a minimum of fuss later on.
* I don’t have time for bullshit maintenance work: stupid repetitive tasks that merely keep things working vs. actual creative work.
These priorities mean that I try to select tools (computers, software, workflows) that
* are reliable
* don’t depend on any one company or person
* can be automated
* have <em>appropriate simplicity</em> for the job
I use [http://pollenpub.com|Pollen] as the framework for organizing writings and publishing them as HTML and as printed books.
Pollen gives me a clear framework for defining my own markup language, and for specifying exactly how that markup gets translated into HTML, LaTeX, or any other format. This means I’m not dependent on other peoples’ Markdown processors and I don’t need to rely on flaky hacks or beg them to implement functionality I need.
Pollen’s author [https://practicaltypography.com/how-this-book-was-made.html|describes his rationale for creating it]:
<blockquote>It occurred to me that what I wanted was not a simple but regimented system like WordPress—it just wouldn’t let me work with the sophistication and detail I needed. Instead, I wanted <strong>a flexible tool for describing complex HTML & CSS layouts with simpler, high-level notation.</strong>
In short: I wanted my own programming language.</blockquote>
Pollen is free software (LGPL licensed).
Version control is inherently complicated, but its [http://fossil-scm.org/index.html/doc/trunk/www/whyusefossil.wiki|benefits] make it an essential part of any programming project, even a small one with only one developer.
My reasons for picking Fossil for this job have to do with my personal tastes (see above) and specific reasons described in [Why Fossil?]
Because Pollen produces static HTML files, the website is pretty agnostic about most aspects of the server stack.
* Server: I use Apache on Linux. It’s easy to install on any distribution, and Apache has more than adequate performance to serve a static site with minimal or no tuning.
* RDBMS: No database client/server system is needed.
* Backups: The use of static HTML along with distributed version control (Fossil) mean that I always have a local copy of everything. My local copy (along with everything else on my personal computer) is backed up locally and to a cloud backup servce; and if the hosting service provides automated backups, I use those.
For certain mildly interactive aspects of the web site, such as contact forms, I am not yet certain whether I will use PHP or if I will attempt to implement them in Racket for purity’s sake.
The server configuration is maintained with Ansible, so it is the work of a few minutes to spin up and configure a new server if necessary.