Making of the Site
It seems appropriate that the first ‘real’ post here should be a walkthrough of the architecture that underlays the site. This is primarily where my interest in creating the site came from afterall, the challenge of executing a personal project from scratch using some of the technologies I use every day at work. The resulting site costs about 50 cents a month plus the annual domain name fee.
Note: While I have no financial association with any of these products, I do use AWS regularly in my day job, so I’m much more familiar with it than the alternatives. There are undoubtedly numerous other options for each of the products used here.
Build - AWS CodePipeline / CodeBuild / Hugo
This site is built using the static site framework Hugo. The content pages (like this one) are written in Markdown. The structure of the site is built in Hugo’s template language, allowing modularization of http that underlays all websites. Themes can be used to abstract away the http almost entirely, but I’ve been having fun tweaking and adjusting the structure to my whims. I’ve had limited pervious practice with http and css, but referencing existing free themes and copious googling has gotten me to the site you see before you.
Now comes the trickier part. Building a Hugo site locally and uploading the resulting site to an S3 bucket is an easy and totally doable option. But I’m a Release Engineer and automation is my jam, so I was not satisfied with this option. I’d looked into a few other solutions previously, but never finished putting the time into getting them working. Recently I learned more about the AWS CI/CD tools, and realized these would be the perfect solution. I found this AWS blog post discussing the exact situation and within short order had the basic premise working. The general gist is that the base file are stored in AWS CodeCommit; any changes to the site are made by pushing a new commit, which triggers an AWS CodePipline which runs the Hugo conversion in AWS CodeBuild and then deploys the site to AWS S3.
Pitfall: As of this writting, AWS CodePipeline does not support git submodules, as discussed here. This is rather annoying, because Hugo themes are usually kept as submodules. It’s simple enough to check the theme in directly rather than maintain the reference, but it’s an unfortunate limitation.
Modify - Git Extentions / Visual Studio Code / Working Copy / Obsidian
Locally, I use Visual Studio Code to write and modify the markdown, html, and css files, with a local instance of Hugo’s server live-updating to immediately see the changes. Once I’ve got something ready to push publicly, the files are pushed to CodeCommit via Git Extentions.
I found Working Copy to be a rather expensive, but well crafted iOS / iPad git client and simple editor. There are surprisingly few options in this area, and this one was by far the best that I saw. I haven’t used it a ton yet, without Hugo running on the iPad it’s pretty limited to Markdown changes, but once the basic structure of the site is more settled, I’m looking forward being able to write and update from the iPad.
Since starting this site, I’ve switched to using Obsidian as a note keeper and project management system. Since Obsidian is a markdown based system, it only made sense to add the site’s source markdown to my Obsidian Vault so it can now be easily modified from my phone as well. I will need to remember to occasionally sync the Obsidian files with the git repo, so the actual site gets updated.
Pitfall: When pushing via ssh to AWS CodeCommit, I’ve been unable to get the IAM user name to work. I’ve always needed to upload the SSH key and then use the Key name as the git username.