As I wrote about earlier, I’ve just finished moving this blog from Pelican to Hugo. I was so impressed with Hugo after setting up Slipstream to use it, that I fancied trying it here as well. Not that there’s really anything wrong with Pelican — it’s a great system, with a lot of flexibility. It’s just that Hugo has two big advantages, the first of which is particularly useful to me, as I’ve got such a large site: speed.

Pelican wasn’t exactly a slouch, but it took about 10 seconds to build the site. Considering I now have more than 1500 articles, that’s impressive, but not as fast as it could be. Hugo builds the same site in 1.5 seconds¹. Since you can leave the hugo server command running in a terminal, and a live reload script (included in Hugo) takes care of reloading your webpage automatically when it notices changes to the files making up the site, you can (as I am doing right now), have a browser window open as you write and see a live preview of your article. It’s pretty nifty.

However, the main advantages of this speedy site generation are that building and deploying on the server itself is so fast that visitors should barely notice any issues, and that as I continue to accumulate content at a steady rate, building the site will not become unmanageable for many years yet.

Building and deploying

The second advantage is that Hugo uses a pre-built binary, and does not have other complex dependencies. Pelican depended on having a working Python environment, and a few libraries, which meant it needed to be carefully managed if you wanted to build the site on the production server itself. For Hugo, all you need is the hugo binary. The way I build this site now is by writing the content or editing the templates on a git repository checked out on any computer I happen to be using. I can use the hugo server command to check all is well with the content and formatting, then I commit the changes to the repository. I then push them to my origin repository (hosted at Bitbucket), and also — this is the clever bit — to a bare repository on the Linode that serves this site. There, a post-receive git hook detects when a new commit has been pushed and runs a script which checks out a working copy in another directory on my Linode, builds the site using Hugo to the public/ directory inside the working copy, then uses rsync to copy any new or modified files (deleting orphaned ones) in the web root of this site. It all works smoothly, and remarkably quickly.

I thought I would take the opportunity to clean things up a bit while I was shifting over to Hugo. Here’s what I’ve changed.

Pagination

I used to have pagination on the index page, so that you could keep browsing further and further back through the archives, 10 posts at at time. This was a nice idea, but with more than 1500 articles, that’s more than 150 extra pagination pages, which are mostly unused, and change every time I write a new post. So I made the decision to drop pagination from the index page. You’ll notice that at the bottom of the home page, there’s a link to view the archives, which lists every article I’ve ever written, chronologically. You can still move from article to article by going to the single post page (i.e. clicking the linked title on the index page), and then using the ‘Older/Newer’ links at the bottom of the page. I often find myself using that other people’s sites, particularly if I am new to their website, and want to get a feel for their writing. This makes building somewhat speedier, and substantially cuts down the crufty files on the server.

Sass and responsive design

I had been meaning to learn to use Sass to write my stylesheets, as it seems to be more actively developed, widely used and somewhat better featured than LESS, which is what I used before. Sass (and LESS) allow you to write CSS in a more abstract and efficient way, using variables and functions to reuse bits of styling. This helps a lot with consistency, and makes it easier to maintain. While I was mostly happy with the visual appearance of this site, I wanted to clean up the styling a bit, particularly in relation to how it looks on smaller screens and devices, which was somewhat sub-optimal before.

Rather than using a complete framework like Bootstrap, I decided to go a more minimal route, and used Bourbon mixins, and the related Neat framework (for grids) and Bitters (for a basic set of styles for typography, etc.). Once I had got my head around using these, they were terrific. The Neat grid framework is particularly easy to use, and the @include media($screen-size) mixin was incredibly useful for writing concise media queries nested inside the elements to which they refer, rather than being dumped at the end of the stylesheet. Sass and Bourbon handle creating correct and efficient CSS from your Sass code very neatly.

I wouldn’t say that I have completely finished tweaking the styling of the site on other devices and screen sizes yet. There are places where it still needs a bit of refinement, but it is a lot better and more usable than it was, particularly at very small sizes (like on a phone).

I’m in love with Sass and Bourbon now, and will use it when I come to redesign other sites I think.

Bigfoot footnotes

I’m now using a different style for the Bigfoot footnotes, as I could not for the life of me get the numbered style to work properly after the redesign. It’s more than likely a conflict between styles somewhere deep in a stylesheet, but sometimes you have to pick the battles you are going to fight. I think the ‘sheet at the bottom’ style looks quite nice and is functional, so that’s what I’m sticking with for now.

Prism syntax highlighting

I don’t have highlighted code blocks in articles all that often, but when I do (and don’t use an embed from Github Gists), it’s nice to have it properly syntax highlighted. I decided to give Prism.js a go, and it works nicely. All you need is a little Javascript, and a stylesheet, and then codeblocks set up as fenced blocks in Markdown and labelled with a language get highlighted appropriately. For example, here’s a snippet of CSS:

input,
select {
  display: block;
  font-family: "ff-tisa-web-pro", "Helvetica", "Times New Roman", serif;
  font-size: 0.66667; }

RSS feed

As I mentioned earlier the one thing I did have to change (and probably break) is the feed URL. If you subscribe to the feed, you might want to check that you’re using the new URL. RSS feeds are hard.

Wrapping up

I think that covers most of the changes. There are a few tweaky things I’d like to work on gradually, but by and large, this site should look and function much the same as it has for a few years (albeit hopefully being a bit more usable on small devices). If you notice that anything isn’t working properly or as you expect, do drop me a line or comment, and I’ll try to fix it.

Overall, I’m happy with the way it has turned out, and feel that it is cleaner and more manageable for the future. If you scroll down the bottom of the Archives page, you’ll see that I’ve been writing here since October 2002, more than 13 years ago. Here’s to the next 13 years at but she’s a girl…