Blog

Animated GIFs 2020-08-09

You will notice something new some of the upcoming posts about Mega Man X4 - animated GIFs.

I found myself wishing I could demonstrate certain parts of all the MMX games in motion, in particular the weapons or boss patterns. I finally found software that can convert a video to animated GIF, and thankfully the Switch can capture video. It’s a painstaking process of capturing, transferring, creating the GIF, etc, but I think it will be worth it in the end.

Lost and Found 2020-08-02

Hey, remember back when I said I felt so excited to get back to writing, and that I had so many ideas and inspirations?

Yeah, about that … sometimes the road to hell is paved with good intentions. I ended up running into a bunch of roadblocks that made the month of July a bit of a dry spell for content. Yeah, there were some Mega Man X2 pieces posted at the start of the month, but those were technically written in late June; I just didn’t slap the screenshots in until July. This is the only piece I technically wrote during the month.

So what happened? In the words of “Diamond” Joe Quimby, it can be - and was - two things.

State of the Blog 2020-06-13

In February of 2019, I made some major changes to this blog. I chose a new static site generator to build the site with, and I also changed where I hosted it. At the time I was very excited, as I believed these changes would make it easier for me to publish content, and that this in turn would motivate me to post more. The blog had gone into dire straits at the time - my post count was sporadic in 2017, and I didn’t post a single thing to it in 2018¹. Of all my personal flaws, my inability to consistently blog has been one of the most frustrating for me to accept, and to fix (which is not the same as saying I think it is my worst flaw. It’s not - it’s just been one of the most annoying).

It’s been 17 months since I made that migration, and I thought it was time to do a “State of the Blog” post to see whether these changes helped as much as I hoped they would.

Relaunch Postmortem - Using Netflify CMS 2019-02-12

Netlify CMS is an open source tool written by folks at Netlify that adds CMS features to your static website. Before I continue, I understand how hypocritical it sounds to add a CMS to a Static Site Generator, but the way Netlify CMS works is different than what you might think.

First off, the only assumption Netlify CMS makes about your website is that you are writing your site content as Markdown files containing frontmatter. Beyond that, it has no concerns regarding how you build your site or where you host it. If you are hosting on Netlify, the configuration process is much easier, but there are options available to help you hook it in to any other process. That is great in terms of flexibility, but it is also great because it drives the way the tool is designed.

To use Netlify CMS, all you need to tell it are where your posts are stored, what you put in your frontmatter, and what naming scheme you use for your post files. Then you grant it authorization to hook into github/gitlab’s REST API to make changes to your repository, and you are off to the races. This is what allows it to work with any build/hosting solution, as those concerns are independent to what Netlify CMS is trying to do.

Relaunch Postmortem - Moving to Netlify 2019-02-11

The site is currently being hosted on Netlify, a newish service for hosting websites. It can be a bit hard to parse through all the marketing speak, but Netlify basically exists to make it easier to host static (and static-ish) websites by supporting multiple build tools and technologies, and abstracting away pain points surrounding topics like hosting, HTTPs, servers, etc. Basically, if you have your site’s code hosted on Github/Gitlab/Bitbucket, and you are using any sort of popular Static Site Generator (or a common node.js-based build system involving Grunt or Gulp), you can get your site to be built and deployed on Netlify as soon as you push your latest commits. And even on their free tier, your code is hosted on a CDN with extremely fast response times.

For me, the biggest benefit to using Netlify is the reduced maintenance requirements. The only thing I need to tell Netlify is which version of Hugo I am using; when I push site updates to my Gitlab repo, the service loads up that same version of Hugo, builds the site using the default command, and serves up the content from the default public folder. Easy peasy.

The nice thing about this is that since Hugo is a static executable, there are little to no security risks involved with supporting older versions. I imagine I will be able to keep my current Hugo version locked in for quite some time without any issue. I also like that this makes it extremely easy to know how the site is going to look and work on Netlify, since it is running the same commands that I am.

Netlify also provides a nice web UI for configuring how your site is deployed. I haven’t had much use for all of the options, but they make sense and I find them potentially helpful.

All in all, the experience of using the service has been extremely pleasant, and I hope it continues to get better rather than worse. With modern, VC-funded services, you can never be too sure as to when the party stops and things start to get crappy, expensive or both.

Relaunch Postmortem - Moving to Hugo 2019-02-10

For this relaunch of the blog, I started using Hugo as my static site generator. Hugo is written in Go, and it is unlike much of its competition in many ways.

The biggest difference is that Hugo comes in the form of a single executable. It has no dependencies, and it does not require you to install any sort of programming language. The implications of this one difference are staggering. In addition to making it easier to install and get started, as well as easer to update and maintain, Hugo’s single-executable means that it is trivial to place the executable file into your git repository. Doing so means that as long as you can clone your Git repository, you can reproduce your entire build environment on any computer. This is an extremely big deal for me. One of the minor reasons why I stopped working on the old iteration of the blog was that the build environment was set up on my oldest, slowest laptop. I didn’t like getting on it all that much, and I did not want to spend a ton of time replicating the environment on another box. With Hugo this is no longer an issue.

Another consequence of Hugo’s design is that it changes the way it interacts with external tools. By default, it tries to provide as many features out-of-the-box as it possibly can, so much so that for most use cases, you likely will not need to seek out external functionality. As a result of this, it doesn’t have that many hooks into, or awareness of external tools. Even when it does, it tends to be simple and deliberate. For example, Hugo is able to provide syntax highlighting for code blocks out of the box. It also allows you to use the Pygments tool to do it instead, but it is up to you to install Pygments and make sure that the executable is on your system path. The documentation is very clear in telling you a) that you have to do this, and b) how to do it, so there is no guesswork involved.

Relaunch Postmortem - The Problems with Heroku 2019-02-09

The problem with using Heroku to host a static website is that it is the kind of thing that you can technically do, but probably shouldn’t. One reason is that it adds an extra level of maintenance requirements on you. You have to worry that whatever programming language and server software you are using to run the site are supported by the Heroku platform, and that you keep them properly up to date.

You have to download a bunch of tools that allow you to simulate the Heroku stack in order to ensure that your website will deploy and run properly.

Your site is deployed to Heroku by pushing your code to a Heroku-hosted Git repository. If you want to take advantage of the benefits of a platform like Github or Gitlab, you will have to make a mirror of it on one of those sites, and keep it updated as well. One more step in the publishing process that honestly isn’t necessary.

If you want the site to load instantly for users, you need to install some Heroku plugins and tweak them so that your site never goes to “sleep” and is able to serve requests immediately.

Long story short, a service like Heroku is a bit too heavy duty for a static site, and requires more work than I am (and I imagine most people are) interested in taking on.

Relaunch Postmortem - The Problems with Middleman 2019-02-08

I wrote a whole post about how my old Static Site Generator, Middleman, let me down, but as I was in the process of relaunching the site I found this old post in which I basically said the same things, back when the problems and pain were fresh. I like what I wrote back then, so I edited this post to remove any repeat content. I suggest you go back and reread that old post, then come here for some newer, additional thoughts.

Relaunch Postmortem - The Problem with Static Site Generators 2019-02-07

When I moved off of Blogger and created cmwolfe.net, static site generators were all the rage. They were a reaction to all the heavy platforms like Wordpress and the aforementioned Blogger, as well as a reaction to the proliferation of big, Javascript frameworks and Single Page Applications. For many people, all of these tools were too heavyweight for a simple personal blog that needed little more than some HTML, CSS, and a smidge of Javascript.

Static site generators allow you to automate the process of churning out plain HTML pages for all of your blog posts. They also almost universally allow you to write your actual post content in a format such as Markdown. Thus they allow you to create a blog made up of lots of simple, individual HTML pages without all the pain of having to hand write them all.

For many use cases this sounds perfect. And indeed they can be! But static site generators can also be hell. Here are some of the general lessons I learned about static site generation, which I feel can be applied to most tools of this ilk:

Relaunching Blog 2019-02-06

Hello again! This is my second attempt at recreating my personal blog, and the first time trying to recreate and revitalize cmwolfe.net in particular. Just like the previous time this happened, I wanted to write a bit about what went wrong, and what I am doing to try and make it better. Unlike the last time, I want this one to be more of a postmortem, in which I try to identify what went wrong and what went well in an attempt to learn and improve. When I launched cmwolfe.net my first few posts were less “postmortem” and more “the past sucked, everything is awesome now, and I’m feeling way more smug than I should about all of this”. I’d like to think I’ve learned some humility since then.