How the site is built (terribly)
Consider this a small behind-the-scenes of how I build this website. You'll surely have noticed that it looks and feels very primitive. That's in part by design, and in part by laziness. As described in low effort, I enjoy the simplicity, speed and efficiency of a static HTML page. It's nice to serve a web page that's just a slightly formatted document, like ancient times. As for being lazy, I simply don't want to make something more complex, because I make these all by hand:
Really hand-made; every line of HTML is hand-written. The modern way would be using static site generator or similar. Which of course would produce much better looking results for a fraction of the effort, and be future-proof; pity the future me that decides to change the layout of the website in any significant way and has to search-replace his way through the entire back-catalog of posts...
I also don't have any 'smart' infrastructure set up for deploying updates to the site. It's borderline manual. The whole process is pretty simple, though convoluted in its own way: I'm offending a fair few web devs both in how the site is made, and doubly so in how it's deployed.
As an example, here's the outline of my current process when I need to add a new post like this one:
- Write the actual post: I draft it in a Markdown document, but how the text comes to be is ultimately not that important. I do like keeping all the "originals" in Markdown files separately from the actual files served so that the content is kept separate from the final formatting. Allows me to make/use tooling more easily down the line to process the files.
- Convert to HTML document: I've made a template files for these blog posts which I "fill in" by manually reformatting the Markdown original into HTML. This step is definitely the most readily automated, I just haven't bothered.
- Commit changes to server repo: All the static server files and configuration files are version controlled of course. As it happens, the repository origin is stored on the server itself.
- Synchronize files locally: Final step is to SSH into the server, synchronize the git repo locally in a user directory, then copy all the new/updated files over to the actual directory that nginx services. New visitors to the site will see the update immediately. The actual copying over is pseudo-automated, handled by a script with an rsync command with a little bit of 'safety' code to display the impending changes before asking for final confirmation.
There's the horrible process laid out. Notice that there's (at least) three duplicates of each document at any given time: One in the local git repo, one in the 'remote' git repo (which is served from the same machine), and the actual copy being served by nginx which lives isolated from git. Almost entirely manual work from end to end. And I kind of like it this way, to be honest. I might simplify the workflow one day, but with how often (not at all) I actually make any changes it's fine. Keeps me in touch with the machine gods.
There is one advantage to doing at least part of this stuff manually: Since I literally write every single page, I can break the rules on a whim much more readily than with a site generator or the like. Like making the background color of this post a tad different from the rest of the website.