Switching To Squarespace

If you happened to see this site around the time when the first post went up, you might notice that:

  1. The site looks very different now.

  2. A lot of what’s in that first post no longer seems to be true.

For example, this is not the Rusty theme for Hugo. Those technically savvy would also notice that the site no longer has the same DNS record value as laifu.moe where things were originally hosted. That’s because the site is no longer running on my own web server and is not created using Hugo. There were a few reasons for this. The main was just that I’m really bad at web design. The Rusty theme in Hugo is pretty light on imagery, which I’m cool with. Once we decided to actually make Unusually Pink into a thing and do a podcast, though, we had our amazing logos made by the uber-talented JPFDesigns. Integrating those into the Rusty theme for Hugo was a bit more than I was up for; CSS is legitimately the final boss of my life, and my life is (apparently) an NES Contra game; I couldn’t do it.

The other reason was just that it allows for much better reliability. The site isn’t beholden to my ability to not mess up my web server. Not that it’s particularly likely for me to do something to brick it (I’ve been using Linux and Nginx for my web servers for ages now), but it’s possible. I was also responsible for backups, which I’d prefer to take off of my own hands if possible.

The last reason was that the site really needed to be divided from one main section (e.g. the blog I originally planned just to do something with the domain) to two sections: a blog and a list of podcast episodes. While I was able to just dump a /podcast directory into my static folder for Hugo, it meant that posting podcast episodes and summaries was now an entirely manual process rather than something assisted by a CMS-esque system like Hugo.

Swapping to Squarespace allowed me to let someone far smarter than me figure out all of that within a theme; all I had to do was upload some images (Squarespace is awesome at scaling images for me, even when it needed to make one tiny for the favicon) and then swap around a few of the colors in the theme to get something unusually pink. I was also able to simply add two blogs to the site; one is a normal blog and the other will have posts for each podcast episode. In this way, both sections of the site are managed by a CMS rather than being done manually. Doing it manually may not seem like too big of a deal at first, but once you start to get too many posts for a single page, creating and manually updating the pagination after each new post would be enough to drive someone insane.

As for choosing Squarespace, it’s the one I’ve heard the most about through various avenues on the Internet. Their pricing was reasonable, and I figured it seemed like a safe bet since I know a few other people who have experience with them. The other recommendation I got was Wix, which I admittedly had never heard of previously. Looking at the pricing for Wix compared to the pricing for Squarespace, though, I think it’s clear that Squarespace is a better deal. The Wix $11 USD per month package is pretty lackluster, especially when you look at 2 GB of bandwidth and 3 GB of storage. To get something more comparable to Squarespace’s $12 per month package that includes unlimited bandwidth and storage, you’d need the $14 per month plan from Wix… and that still doesn’t give you unlimited storage.

Expect the site to still go through a few minor changes as we continue to tweak the layout, colors, and everything else. Feel free to drop any feedback to our Twitter profile!

Firebase Update Control Error

One of my websites (not this one) is hosted via Firebase. It’s a largely static site that I rarely need to touch. I manage it from their CLI running on a VPS that I do some coding on so that I can access it regardless of which of my numerous devices I happen to be using. Since I don’t touch the site regularly, though, the Firebase tools tend to get a bit out of date. I needed to push a minor change the other day and figured I’d check for an update:

sudo npm install -g firebase-tools

Instead of completing happily, though, I got the following:

npm ERR! path /usr/local/bin/firebase
npm ERR! code EEXIST
npm ERR! Refusing to delete /usr/local/bin/firebase: ../lib/node_modules/firebase-tools/bin/firebase symlink target is not controlled by npm /usr/local/bin
npm ERR! File exists: /usr/local/bin/firebase
npm ERR! Move it away, and try again.

I’m a bit embarrassed that I did a bunch of super unnecessary troubleshooting at first instead of just reading the error. When I finally got to that point because things like clearing the npm cache didn’t work, I saw noticed this:

File exists: /usr/local/bin/firebase
Move it away, and try again.

Okay, seems sensible enough. I first just renamed it in the same directory.

sudo mv /usr/local/bin/firebase /usr/local/bin/firebaseBKP

I re-ran the npm installation command, and sure enough it worked without any issues. I verified I could actually see firebase in my $PATH:

which firebase

And that it was the newer version:

firebase --version

With that out of the way, I simply deleted the file I renamed:

sudo rm /usr/local/bin/firebaseBKP

Then I could push the update to my site without any issues. To be honest I’m not entirely sure why or how that file wouldn’t be controlled by firebase or it couldn’t be removed by running the command under sudo, but I’m happy that it had a clear error message that allowed me to fix things easily enough… once I actually, you know, read the error message.

PSA: Get Ready For New Let's Encrypt Validation

If you’re using Let’s Encrypt, now would be a really great time to make sure that you’re ready for them to stop supporting ACME TLS-SNI-01 domain validation. I got an email a couple of days ago (as I assume everyone using Let’s Encrypt did) letting me know this change was coming. I had nothing to actually do, but going through the validation was super easy and is likely worth the time to ensure your site(s) aren’t impacted. March 13th is the deadline for ACME TLS-SNI-01 to no longer function, so there’s still a lot of time to take a couple of minutes and verify you’re in good shape.

*Note: I’m using certbot, which makes this whole thing super easy. If you’re not using certbot then your steps will be different.*

The Let’s Encrypt staging environment already has disabled ACME TLS-SNI-01 validation, so checking against that is a good test. As a certbot user, I also needed to validate that I was using at least version 0.28 of the application, which is simple enough to do via:

certbot --version    

That appears to be the latest version offered by the PPA: ppa:certbot/certbot

Testing a certbot run against the staging environment is toggled via the --dry-run switch. If you do a dry run of your renewal against the staging environment and everything comes back successful, you should be in good shape:

sudo certbot renew --dry-run

My certs all validated successfully, so everything is ready to go for the change. I presume if there are any failures then the dry run will alert you to what needs to be fixed; I can’t say for sure since I was lucky enough to not see any of those. Full instructions from Let’s Encrypt are available on their site, though.

Happy encrypting!