final edit: new-website

config/_default/params.toml

@@ -24,9 +24,9 @@ disableTextInHeader = false
 defaultBackgroundImage = "img/BG_Jasper.jpg" # used as default for background images 
 # defaultFeaturedImage = "IMAGE.jpg" # used as default for featured images in all articles
 
-# highlightCurrentMenuArea = true
-# smartTOC = true
-# smartTOCHideUnfocusedChildren = true
+highlightCurrentMenuArea = true
+smartTOC = true
+smartTOCHideUnfocusedChildren = false
 
 giteaDefaultServer = "https://git.brds.ca"
 forgejoDefaultServer = "https://v8.next.forgejo.org"
@@ -74,7 +74,7 @@ forgejoDefaultServer = "https://v8.next.forgejo.org"
   showPagination = true
   invertPagination = false
   showReadingTime = true
-  showTableOfContents = false
+  showTableOfContents = true
   # showRelatedContent = false
   # relatedContentLimit = 3
   showTaxonomies = false

content/posts/new-website/index.md

@@ -1,6 +1,6 @@
 ---
 title: "New Website"
-date: "2025-05-16T13:16: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."
 ---
@@ -16,23 +16,30 @@ a culmination of the platform I've developed to host it.
 
 My first personal website was developed while I was a student at the
 [University of Alberta](https://ualberta.ca), near the end of the previous
-century. The web itself was still quite young, but the university provided
+century. The web was still in its early stages, but the university provided
 students with the means to publish web content. It was mostly a novelty at the
 time and didn't last beyond my time at school, but it sparked my interest in
 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.
+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
+needed to handle cases like multiple logins, and the logout script didn't
+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
 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`, or 16 IP addresses) that I could use. I dedicated my most
-powerful machine to be my server and developed several services, including a
-new website.
+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
@@ -62,35 +69,105 @@ 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 good base template, and there are
-[many to choose from](https://themes.gohugo.io/). I've chosen one called
-["Blowfish"](https://blowfish.page/) for this site.
+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/).
 
 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
-tools like Git for version control. I keep the sources for this site in a
-public repository on my own Git server. Feel free to take a look:
+tools like [Git](https://git-scm.com/) for version control. I keep the sources
+for this site in a public repository on my own Git server. Feel free to take a
+look:
 
 {{< gitea repo="d-b.ca/web" >}}
 
 ### CI/CD
 
 I've also set up a CI/CD pipeline to build and deploy the site whenever
-changes are made to the source repository. The CI portion is triggered by a
-push to the web repository. It runs a workflow that builds the site and
-packages the resulting artifacts into a container image based on
-[Caddy](https://caddyserver.com/). The build container with Hugo is another
-image I maintain in this repository:
+changes are made to the source repository. What does this mean?
+
+**CI** = *Continuous Integration*
+> This is the practice of frequently integrating changes into a source
+> repository. The changes are checked, assembled, and packaged through
+> automated processes. [More information](https://martinfowler.com/articles/continuousIntegration.html)
+
+**CD** = *Continuous Delivery*
+> This is the capability of being able to take new changes (such as the
+> outputs of the CI process) and getting them deployed and running
+> automatically. [More information](https://continuousdelivery.com/)
+
+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
+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" >}}
 
-Next, the workflow updates the CD GitOps repository to deploy this new version
-to a private staging site. When I want to publish the new version as the
-production site, I use my regular GitOps repository to update the image tag,
-and the rest happens automatically.
+After the workflow has built the container image for running the website, it
+updates the CD GitOps repository to deploy this new version immediately to a
+private staging site. Another definition:
+
+> **GitOps** refers to the practice of managing infrastructure automation by
+> keeping machine-readable descriptions of the intended infrastructure in a
+> version-controlled Git repository. A CD system will monitor the repository
+> for changes, immediately adding, modifying, or removing infrastructure to
+> 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
+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" >}}
 
+#### Pipeline Diagram
+
+{{< mermaid >}}
+flowchart TB
+  subgraph GIT [Git Repository]
+    WR[(Web)]
+    CDR[(CD)]
+  end
+
+  WP(Push Web Updates)-->WR
+  WP ~~~ HBI
+
+  subgraph CI [CI Workflow]
+    CIP[Pull Source
+        Repository]-->BWI[Build Web
+                          Image]
+    BWI-->PWI[Push Web
+              Image]
+    PWI-->UCD[Update CD
+              Repository]
+  end
+
+  PWI-->WI
+  WR-->CIP
+
+  subgraph DOCKER [Image Repository]
+    HBI((Hugo
+         Build))
+    WI((Web))
+  end
+
+  HBI-->BWI
+
+  UCD-->CDP(Push Image
+            Update)
+  CDP-->CDR
+  CDR-->CDPull
+
+  subgraph CD [CD Process]
+    CDPull[Pull Source Repository]-->DWI[Deploy Web Image]
+  end
+
+  WI-->DWI
+{{< /mermaid >}}
+
 ## Underlying Platform
 
 In my next article, I'll describe the platform this site is running on, and