The website launched! This week I published this very website, after doing a little fighting with git submodules, DNS, and git submodules again. Let’s get into it:

AWS Amplify Setup

I’ve used AWS Amplify in the past for static sites built with Hugo, and I’ve found it to be one of the simplest publishing platforms to set up sustainably (as long as you’re familiar with git and DNS configuration). The biggest upsides from my perspectives are that I don’t have to maintain the infra: Amazon sets up the underlying storage, a CloudFront distribution to handle traffic, and SSL setup. Plus, I can connect it to the GitHub repostitory and Amplify will watch for pushes on my main branch and rebuild automatically. All of this ens up costing less than $1/month.

But there were a few problems I ran into. First off, I originally had delegated the DNS for hollis.computer to Linode, my VPS host, but Linode doesn’t support ANAME records, which are necessary for pointing the “naked” domain at a CloudFront distribution. To get around this, I migrated from Linode’s DNS manager to AWS Route 53. I mostly followed Amazon’s instructions, except I ignored the parts about fiddling with the TTL since I didn’t care about continuity of service (nobody reads this yet!).

The full migration took about 2 days waiting for various caches to expire after the initial configuration, but in the mean time I could at least test out building the site on the testing domain Amplify sets up. However, I found only blank pages. After reviewing the build logs, I discovered that the clone step was failing to pull in the submodule that contained the site’s theme–it was cloning over ssh, and they key it was using wasn’t set up as a deploy key in panr’s repo. Even if I could somehow get the public key (I found some suggestions about modifying the build config to print it out), I can’t imagine panr wants to be in the business of adding random strangers' ssh keys to their repo.

However, I did find one suggestion to fetch it over https instead. Fortunately since the repo is public, I didn’t have to manage any secrets, I could just update my .gitmodules:


[submodule "themes/terminal"]
	path = themes/terminal
-	url = git@github.com:panr/hugo-theme-terminal.git
+	url = https://github.com/panr/hugo-theme-terminal.git

And with that, it worked!

Modifying the Theme

The next step was making a few changes to the theme: adding Scala support to the syntax highlighter, and adding a purple color scheme. For the former, since it’s possibly more widely applicable than just on my blog (Scala’s a popular enough language!), I opened a PR to contribute that upstream. For the latter, I elected to just branch off my Scala support branch and add it there (once my PR is merged I can rebase my theme branch). I fought a little with JavaScript tooling, but eventually got my change built and committed.

Now I had to point the submodule in the site repo to the right place. I made another .gitmodules change:


[submodule "themes/terminal"]
	path = themes/terminal
-	url = https://github.com/panr/hugo-theme-terminal.git
+	url = https://github.com/davidhollis/hugo-theme-terminal.git
+	branch = purple-theme

and made a corresponding change to the repo config in my local clone. But to my frustration, git wasn’t showing any available submodule changes. After poking around, I discovered that my working copy had the submodule reified and still had its origin pointed at panr’s version. So I popped into that directory and

git remote set-url origin https://github.com/davidhollis/hugo-theme-terminal.git
git fetch origin
git checkout purple-theme

So after setting the appropriate upstream in no less than three different places, I now finally had managed to turn the site purple.

Project Pages

Next up, I wanted to be able to tag each post with a project (this one’s tagged site), and also to write a brief description of each project with some helpful links. I accomplished this by creating a new taxonomy called project. Terms in that taxonomy are project ids, and values are posts in which I describe progress on that project. Metadata for a given project can then be associated with a term index page (the content is a brief description, and there’s a links param that lists links related to the project, such as a GitHub URL).

To get all of this presented in the site, I just needed to create two now templates: one for the taxonomy itself that lists terms, and one for a term that lists associated posts. You can see what that looks like here (project list) and here (project page). There is a lot of code copied and pasted from other templates the theme provided, so at some point I’d love to migrate the rich taxonomy templates back into my fork of the theme and factor out some of the more complex stuff into partials, but what I have works for now.

Up Next

Over the next week or so, I’d like to take a look at the persistence layer in Happening, and ideally get sqlite persistence working in dev. Then just knock out writing as many model<=>table mappings as possible.