I started this blog in 2012 as a platform to launch a writing career. That effort was wildly successful, and now I’m the Managing Editor of TidBITS, a Contributing Blog Editor at The Prepared, I’ve written for multiple publications, and I’ve written several books for Take Control. I’m now fortunate enough to afford for my wife to stay home with the children and I almost never have to leave the house.
But as my writing career ramped up, my blog fell to the wayside. It’s hard to make time to write for “free” when you’re getting paid to do it all day. Honestly, that was a rationalization: I spend entirely too much time tweeting, giving away ideas and content to a major tech firm that not only profits from my labor, but could turn around and kick me off the platform at any moment, for any reason.
Tweeting is a sucker’s game. So I decided to overhaul the site.
Owning the infrastructure
This site was originally hosted at Squarespace, which is a fine tool, but incredibly heavy and expensive for my needs, which are:
- Self-hosted and open so I’m not stuck on a proprietary platform
- Low maintenance
- Markdown friendly
I purchased a VPS at Vultr, which is not only cheaper than Squarespace, but lets me host any sort of services I want. (Use my referral link and you get some amount free for your first month). I could have moved my page to GitHub for free, but I want to own as much of the infrastructure as possible.
I followed Luke Smith’s video on setting up a website on Vultr, which is as clear a guide as I’ve ever seen. I followed his instructions on setting up an nginx server and setting up an SSL certificate, which was surprisingly easy.
From Squarespace to Jekyll
- It’s static, so no complex databases or other junk.
- It’s open source.
- It’s extremely well documented and supported.
- It’s responsive out of the box, so I don’t have to waste time tweaking HTML and CSS.
- It’s super portable. I could even host on GitHub if I wanted.
- There were existing tools to move my Squarespace blog to Jekyll.
Squarespace offers export, but only in a clunky WordPress XML file. Thankfully, there are several tools that can break this down into a usable format.
I used two scripts for the conversion. One was the wordpress-export-to-markdown script to download the entire site, including images. I had to modify the script to include the full URL path to images and other resources, but thankfully vim made that easy.
However, I couldn’t get it to export in a Jekyll friendly format. So I used Evan Walsh’s very simple import.rb to actually convert the posts. I had to edit the posts with images to cut out Squarespace junk and then relink the images by hand. Thankfully, I’ve never used images much on the blog, so that was pretty simple. I cut images out in some posts because they weren’t necessary and I’m lazy.
Another thing that didn’t carry over from the old site was the comments from Disqus. I could have done it, but it would mean more work, more maintenance, and I just don’t care that much. Also, it would have meant embedding some sort of cross-site tracking, which I’m purposefully avoiding on this site.
I’m not a big fan of major media sites cutting out their comment sections, as I feel it’s often to avoid accountability to their readers, but for this small personal site I don’t think comments are necessary. If there’s demand I might put up a forum, but I kind of doubt I’m that popular.
As for maintaining the site, I followed Marko Mudrinić’s guide to deploying Jekyll using Git Hooks. I may try to streamline it later, because I hate the fact that it compiles on the server end, which seems unnecessary, and it means having to deal with Ruby installations on at least two machines. I had to do some hackery to update the minima theme so that I could easily switch to a Dark Solarized skin.
I feel confident in choosing Jekyll, but I hate bloated scripting languages like Python and Ruby. If your scripting language has its own package manager, you’ve done something wrong. Dependencies and other things should be handled at the system level. Users shouldn’t have to track dependencies for every language their apps are written in.
But the nice thing about Jekyll is I’m not married to it. If I find something even lighter and well-supported later, switching shouldn’t be a big deal.