additional edits: new-website

config/_default/languages.en.toml

@@ -22,7 +22,7 @@ title = "Drew Bowering"
   headline = "IT Architect, Developer, Canoeist, Tubist"
 #  bio = "A little bit about me"
   links = [
-#     { email = "mailto:hello@your_domain.com" },
+    { email = "mailto:drew@d-b.ca" },
 #     { link = "https://link-to-some-website.com/" },
 #     { amazon = "https://www.amazon.com/hz/wishlist/ls/wishlist-id" },
 #     { apple = "https://www.apple.com" },

content/posts/new-website/index.md

@@ -1,6 +1,6 @@
 ---
 title: "New Website"
-date: "2025-06-10T08:00:00-06:00"
+date: "2025-06-12T08:00:00-06:00"
 description: "There's finally a new website at d-b.ca."
 summary: "I've published my personal website. A brief history of some past endeavours, and some details on the technology behind the new site."
 ---
@@ -8,9 +8,9 @@ summary: "I've published my personal website. A brief history of some past endea
 I've finally published a proper website at [https://d-b.ca/](https://d-b.ca/).
 The last time I had anything live on this domain was over 20 years ago,
 according to the [Wayback Machine](https://web.archive.org/). What took so
-long? Over the years I've learned a lot, and I'm constantly experimenting with
+long? The truth is, my interests have shifted over the years, and I've been
-new ways of getting things done. This site, while useful in its own right, is
+learning a lot. This site, while useful in its own right, is really a
-a culmination of the platform I've developed to host it.
+culmination of a personal platform I've developed over time.
 
 ## History
 
@@ -23,9 +23,10 @@ Internet technologies and their applications.
 
 That early site included one interesting feature. I developed a mechanism to
 automatically update a page every time I logged into one of the school's
-computers, so my friends could find me if they wanted to. The only way at the
+computers, so my friends could find me if they wanted to. At the time,
-time that was available for generating dynamic content in a website was
+dynamically updating websites was a tricky thing. The most common way was
-[CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface), and the
+using [CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface), which is
+like having a tiny program run every time someone requested a page. The
 university did not allow student sites to use it. So, I wrote some shell
 scripts that were called as part of my login and logout scripts that would
 generate the static HTML file and write it to my web content directory. It
@@ -34,25 +35,29 @@ always get triggered, so I'd have to keep an eye on it for stale entries.
 
 ### Self-Hosting
 
-I've always been an avid self-hoster. It began when I was working at a local
+I've always been an avid self-hoster. Learning by getting a system up and
-Internet service provider. I was able to get a special deal on a
+running works well for me. I also value the privacy and control that it
-business-class broadband connection at home, which included a small network
+provides. Plus, it's much cheaper for me in the long run!
-block (a `/28`, consisting of 16 IP addresses) that I could use. I dedicated
+
-my most powerful machine as my server and developed several services,
+It really began when I was working at a local Internet service provider. I was
-including a new website.
+able to get a special deal on a good broadband connection at home, which
+included a small network block (a `/28`, consisting of 16 IP addresses) that I
+could use. I dedicated my largest machine as my server and developed several
+services, including a new website.
 
 My website at that time wasn't fancy, and was geared primarily towards
 experimentation. I developed a simple content management system from scratch
-in PHP3, which I used to publish a blog. It also integrated with mailing
+in PHP, which I used to publish a blog. It also integrated with mailing
 lists, another area I was exploring at the time.
 
 ### D-B.CA
 
 I hadn't registered a domain name of my own in those early days, so everything
 resided under a friend's domain. In late 2002, I decided to finally register
-one of my own, primarily so I could have a stable email address. I came up
+one of my own, primarily so I could have a stable email address. I wanted to
-with `d-b.ca` because someone was squatting on `db.ca` – and still is, I might
+incorporate the initials in my name, so I came up with `d-b.ca`. This was a
-add.
+compromise because someone was squatting on `db.ca` at the time, and, to my
+knowledge, they still are.
 
 Early on, I focused mostly on operating my email services and other
 experiments, with little attention paid to a website. There were a few test
@@ -63,15 +68,18 @@ pages at times, but nothing substantial.
 One of the projects I've been following is [Hugo](https://gohugo.io/). I've
 seen and worked with various web content management systems in the past, and
 they often feel cumbersome and present security concerns. Hugo is an example
-of a "Static Site Generator," which transforms a source description of a site
+of a "Static Site Generator." Think of it like this: instead of creating web
-into the static resources used to serve it – much like a compiler. The
+pages on the fly every time someone visits, Hugo takes all the raw content and
-resulting static resources can be served as regular files from any web
+turns it into a set of ready-to-serve files, much like a compiler turns code
-service, without the need for dynamically generating content upon request from
+into an executable program. The resulting static resources can be served as
-a database, as traditional CMS systems do.
+regular files from any web service, without the need for dynamically
+generating content upon request from a database, as traditional CMS systems
+do.
 
 Using Hugo is much easier with a solid base template. There are
 [many to choose from](https://themes.gohugo.io/), including the one I've
-selected here called ["Blowfish"](https://blowfish.page/).
+selected here called ["Blowfish"](https://blowfish.page/). I like how it
+looks, and it supports the style of site that this is very well.
 
 Another benefit of a static site generator is that all the sources for the
 site can be treated like software code, making it simple to use development
@@ -99,9 +107,16 @@ changes are made to the source repository. What does this mean?
 The CI portion is triggered by a push to the
 [`web`](https://git.brds.ca/d-b.ca/web) repository. It runs an automated
 workflow that builds the site and packages the resulting artifacts into a
-container image based on [Caddy](https://caddyserver.com/). This image
+container image based on the [Caddy](https://caddyserver.com/) web server.
-contains everything needed to serve the website. The build container with Hugo
+
-is another image I maintain in this repository:
+A container image is like a pre-packaged software environment that ensures the
+website runs consistently regardless of the underlying infrastructure. The
+resulting image contains everything the website needs to operate and can run
+on any infrastructure that can support it, such as my own laptop or my server
+cluster.
+
+The build container with Hugo is another image that is only used to create the
+website container. I maintain it in this repository:
 
 {{< gitea repo="d-b.ca/hugo-builder" >}}
 
@@ -116,10 +131,17 @@ private staging site. Another definition:
 > bring the state of the operational system into alignment with the source
 > description.
 
-When I want to publish the new version as the production site, I use my
+There are many benefits to managing infrastructure this way. Changes are
-regular private production GitOps repository to update the image tag, and the
+automatically tracked because everything is stored in an existing code
-rest happens automatically. The CD repository for the staging site is public,
+repository system that's specifically designed for managing and tracking
-you're welcome to check it out here:
+change. Problematic changes can be reverted easily by reverting the change in
+the repository. Automation keeps things in sync at all times - any changes
+made manually outside of this system are immediately spotted and removed.
+
+When I want to publish the new version as the production website, I use my
+regular private production GitOps repository to update the image version tag,
+and the rest happens automatically. The CD repository for the staging site is
+public, you're welcome to check it out here:
 
 {{< gitea repo="d-b.ca/db-cd" >}}
 
@@ -170,5 +192,7 @@ flowchart TB
 
 ## Underlying Platform
 
-In my next article, I'll describe the platform this site is running on, and
+In future articles, I'll describe the evolution of the physical network and
-some of the history and decisions that drove its design.
+systems this site is running on, and how they enabled me to build a
+[Kubernetes](https://kubernetes.io/) cluster to scale this site and run other
+services, all on hardware I assembled myself!