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:drew@d-b.ca" },
+#     { email = "mailto:hello@your_domain.com" },
 #     { 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-12T08:00:00-06:00"
+date: "2025-06-10T08: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? The truth is, my interests have shifted over the years, and I've been
-learning a lot. This site, while useful in its own right, is really a
-culmination of a personal platform I've developed over time.
+long? Over the years I've learned a lot, and I'm constantly experimenting with
+new ways of getting things done. This site, while useful in its own right, is
+a culmination of the platform I've developed to host it.
 
 ## History
 
@@ -23,10 +23,9 @@ 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. At the time,
-dynamically updating websites was a tricky thing. The most common way was
-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
+computers, so my friends could find me if they wanted to. The only way at the
+time that was available for generating dynamic content in a website was
+[CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface), and 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
@@ -35,29 +34,25 @@ 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. Learning by getting a system up and
-running works well for me. I also value the privacy and control that it
-provides. Plus, it's much cheaper for me in the long run!
-
-It really began when I was working at a local Internet service provider. I was
-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.
+I've always been an avid self-hoster. It began when I was working at a local
+Internet service provider. I was able to get a special deal on a
+business-class broadband connection at home, which included a small network
+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,
+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 PHP, which I used to publish a blog. It also integrated with mailing
+in PHP3, 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 wanted to
-incorporate the initials in my name, so I came up with `d-b.ca`. This was a
-compromise because someone was squatting on `db.ca` at the time, and, to my
-knowledge, they still are.
+one of my own, primarily so I could have a stable email address. I came up
+with `d-b.ca` because someone was squatting on `db.ca` – and still is, I might
+add.
 
 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
@@ -68,18 +63,15 @@ 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." Think of it like this: instead of creating web
-pages on the fly every time someone visits, Hugo takes all the raw content and
-turns it into a set of ready-to-serve files, much like a compiler turns code
-into an executable program. The resulting static resources can be served as
-regular files from any web service, without the need for dynamically
-generating content upon request from a database, as traditional CMS systems
-do.
+of a "Static Site Generator," which transforms a source description of a site
+into the static resources used to serve it – much like a compiler. The
+resulting static resources can be served as 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/). I like how it
-looks, and it supports the style of site that this is very well.
+selected here called ["Blowfish"](https://blowfish.page/).
 
 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
@@ -107,16 +99,9 @@ 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 the [Caddy](https://caddyserver.com/) web server.
-
-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:
+container image based on [Caddy](https://caddyserver.com/). This image
+contains everything needed to serve the website. The build container with Hugo
+is another image I maintain in this repository:
 
 {{< gitea repo="d-b.ca/hugo-builder" >}}
 
@@ -131,17 +116,10 @@ private staging site. Another definition:
 > bring the state of the operational system into alignment with the source
 > description.
 
-There are many benefits to managing infrastructure this way. Changes are
-automatically tracked because everything is stored in an existing code
-repository system that's specifically designed for managing and tracking
-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:
+When I want to publish the new version as the production site, I use my
+regular private production GitOps repository to update the image 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" >}}
 
@@ -192,7 +170,5 @@ flowchart TB
 
 ## Underlying Platform
 
-In future articles, I'll describe the evolution of the physical network and
-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!
+In my next article, I'll describe the platform this site is running on, and
+some of the history and decisions that drove its design.