Staring to blog

I want to try verbalizing my thoughts more, and I figured blogging is a good way to do that. I’m expecting this to be mostly technical, but it might stray from programming specific things as well. I want to start a blog as both a technical exercise, but also a way to express myself.

One thing I know I need to get better at is getting something out there, regardless of how good it is. The main reason I say this is because I’ve wanted to put together a blog for a while, but I wanted to set up all the hosting myself and learn all the ins and outs. This has prevented me from actually producing anything. Perfect is the enemy of good.

There are a couple of features I want my solution to have. One is using markdown files, and the other is being hosted at blog.trevorsettles.com.

One feature that I want is to write markdown files and send them to the blog site as posts. This serves two functions:

I’m already familiar with markdown, so I won’t have to learn anything new. Anything new that I learn while editing blog posts in markdown will also translate into my personal markdown notes.
I will always have access to the source of my blog posts if any third party service disappears.

I’ll look at two different methods of creating this blog to evaluate them. Namely WordPress and Hugo.

WordPress

The source code for WordPress is freely available, so there are a lot vendors that will host your own WordPress site. I decided to have [SiteGround][https://www.siteground.com/] host my WordPress blog. The setup was easy and pretty straightforward.

Google domains hosts trevorsettles.com, so I had to set it up to point blog.trevorsettles.com to SiteGround. Within Google Domains, I was able to set an NS record to point to SiteGround’s DNS servers, so now blog.trevorsettles.com points to the blog at SiteGround.

Once those basic setup steps were done, I was able to log into the admin page and start customizing.

One of the biggest things I noticed right away is that the template I picked had a lot of default content. I picked a template for an artist, and every page was customized for that. This forced me to learn how to adjust things for my needs and gamified the whole process a little bit. Finding all of the artist mentions on pages gave me clear indications of what I needed to do to make the site my own.

As far as I can tell, there are some plugins to allow markdown files to generate new posts, but I’m a bit disappointed that it doesn’t seem to be working. I’ll dig into this more later.

After getting more familiar with WordPress, I found that it doesn’t suit my needs well. My main criteria is that I can write my blog posts with markdown. While WordPress technically allows this, you only have access to the markdown itself, not the markdown file.

This means that to write a new blog post I would just need to copy the markdown from somewhere else, negating the advantage of having control of my markdown files.

Hugo

I set up a local Hugo server to test it out. It seems to fit my needs much better. There was no default content that I needed to change and I can give Hugo the markdown files directly, so I can share them between projects as a git submodule. It’s time to deploy it on the itnernet.

AWS

I started going through Hugo’s docs on how to deploy it on AWS, which sent me down a rabbit hole of setting up AWS CLI to allow Hugo to push straight to S3. There seems to be more configuration than I needed to try out for a POC. In an effort of getting something out there, my solution for the meantime is to just manually upload the files to s3 directly.

This also seemed harder than expected. There is a lot of configuration that I wasn’t familiar with. There are layers and layers of security, which I didn’t need. I’ll try a different solution, and see if that fits better.

Render

I ended up deciding to try a separate service, Render which has great support for building static websites. It allows me to host my Hugo app there for free, no credit card required. It also automatically pulls new content and rebuilds as things are pushed to GitHub.

Wrap up

This solution works great for what I had in mind, to begin with, and now some of the roadblocks that made it hard to blog have been reduced. I can finally call this version done, and move on to other projects.

To me, part of working in an engineering style is working iteratively. During this process, I consciously made an effort to try and search breadth first. This means if something got hard or confusing, I had no qualms about switching to another method. This allowed me to look at more solutions and find something suitable.

In the future, I may come back to this and try adding more bells and whistles, but for now, it does what I need it to do.

With any luck, I’ll be writing more blog posts to share what I’ve been working on.