This website

Where it started

The first version was an Eleventy project. Posts were written in Markdown, which Eleventy turned into HTML inside a base layout, and a deployment script pushed the generated dist/ folder to an LXC container. The first Markdown post explains why that was appealing: plain text to write, instant builds.

Recovering it

At some point only the published HTML remained: no Eleventy source, no Git history. The recovery note covers the method: snapshot the production directory, hash every file, rebuild as a separate project, compare, and commit the matching output before touching the design. All 20 deployed files matched byte for byte.

The redesign

This version was built separately from the recovered baseline, so the live site was never the thing being experimented on. The design question was how to show that hardware, services, projects, writing and lessons are all connected without making a visitor learn an interface first. The answer was the layered map, with a plain list behind it for anyone who prefers text.

Decisions

• Static, and boring on purpose. Nothing to patch, nothing to log into, nothing that can fail at request time.
• Documented, not live. The diagrams describe architecture. No page here reports live CPU, memory or uptime, because none of it is measured.
• Gaps stay visible. Where the documentation doesn’t say which machine runs a service, the diagram shows it unattached rather than guessing.
• Old links keep working. URLs from the previous site redirect to their new homes, and the feed is still at /feed.xml.
• One source of truth. Projects, articles, lessons and technologies live in structured data, and the map, indexes and related links all derive from it. The map’s data is validated at build time, so a collision or a broken link fails the build instead of shipping.

What it taught

Take a baseline before changing anything you only have the output of. More on that lesson.