Static site migration – starting the optimisation, already

Now that I’ve got the static site up and running, it’s obviously time to switch over immediately, right? Not to fast. After QA’ing my deployment process in production, it was time to check how the two compared from a performance perspective. I like to use several different tests, starting with Pingdom, then using PageSpeed Insights for more details.

The Pingdom speed test gave it a thumbs up, but they’re not running the currently dominant search engine. Fortunately said search engine also offers performance check tooling. This wasn’t quite the thumbs up I had hoped for, though. While the mobile performance is similar – in other words, equally unimpressive – the desktop performance is pretty good for both sites. The WordPress site still has a slight advantages, but after some initial tweaks like disabling highlight.js (the static site uses the basic Hugo highlighter), the static site is pretty close.

PageSpeed Insight comparison of the static (Hugo) site vs the old WordPress site. Both are in the low 50s.
Mobile site comparison – static vs WordPress
Side by side comparison of the PageSpeed results for the new static site vs the existing WordPress site
PageSpeed insight for new static site vs WordPress (desktop)

Clearly, in both cases the static site needs work. Admittedly I have neglected the mobile performance for both sites somewhat. It’s not like anybody ever looks at sites like this on their phones or tablet, right? Oh, wait. Might want to do something about that.

I got to the numbers above after I made a few tweaks to the theme already – adding a canonical link and adding support for Google and Bing site verification. Neither should affect performance. The only performance tweaks so far were disabling the use of highlight.js. I use Hugo’s built in highlighter and overlooked at the theme’s default config.toml from its exampleSite also enables highlight.js

The PageSpeed analysis indicates to me that the two big issues are the font and JavaScript downloads, with the fonts being the larger and harder to fix issue. The servers – well, VMs – I am running these on are also not the same size and type. Unsurprisingly the WordPress VM has more cores and more RAM compared to the static site.

While I’m no front-end web developer by any stretch of the imagination, trying to improve this theme for my needs might prove a useful learning experience. I apologise in advance for more meta blogging posts.

Static site should be fixed now

Ah yes, the guy who used wear the “I don’t often test my code, but if I do, I do it in production” T-shirt in an ironic way followed his own advice, unironically.

The deployment script was ultra efficient and mainly removed the static site when updating it. Think about all the bandwidth this conserved!

Anyway, the static (beta) Hugo site should now be available and accessible. Feedback is still appreciated :).

Moving this blog to a static site – this time I’m serious (because org-mode)

I have been toying with the idea of migrating this blog to a static site to simplify its maintenance for some time. While WordPress is a great tool, this blog is a side project and any time I have to spend maintaining WordPress gets deducted from the time I have to write for the blog. Keep in mind that I’m self-hosting this blog and it’s actually running on a Linux VM that only handles the blog. That is yet another server that I need to administer, and it’s the odd one out, too, as all of the others are FreeBSD or OpenBSD servers.

Oh, and one of the big advantages of using a static site generator is that the whole site can be put in version control, archived there and also quickly re-generated from there should I manage to spectacularly mess up the host. A WordPress restore is a fair amount more work, as I found out about two years ago.

The only parts that don’t back up that well are the comments, especially if I use a self-hosted system for them.

Migration is fine, but what to?

For that reason, I had experimented with moving the blog to Jekyll for quite a while. In fact, I have maintained a parallel Jekyll blog for years now. For a smooth switch over, the devil was in the details though, and I was never happy enough to actually migrate and shutdown the WordPress site.

After another patchapalooza, I revisited the idea of converting the blog to a static site and looked at several other static site generators. I also decided to resurrect an experiment I had started with Hugo. My first attempt hadn’t been very successful, so I stuck with Jekyll. This second attempt however is a lot more successful as it addressed a couple of the issues that kept me from being happy with Jekyll:

  • Hugo builds the site much faster than Jekyll
  • I found a theme that I’m really happy with.
  • It looks like some of the details that I found hard to get right in Jekyll are already handled nicely in Hugo. This is mostly around the RSS feed generation – Hugo by default generates category feeds in addition to the regular “full” feed. It also looks like the category feeds are very similar path-wise to what WordPress uses, so hopefully the RSS feeds should continue working with the couple of aggregators that picked up this blog.

Fortunately, this time I succeeded in importing the site from Jekyll into Hugo. It took some work to clean up some of the artifacts that originated in the WP-to-Jekyll conversion, and then I had to convert the Liquid template code to Hugo shortcodes. The latter was pretty easy, but a bit tedious. Just not tedious enough to write a script to do it.

Hugo can render org-mode files (and so can Jekyll, apparently)

Another nice feature is that my workflow can still use org-mode for when I want to use it to write longer posts. Shorter posts I usually crank out in Markdown, but for the more complex posts it’s nice to have org-mode as an option. Especially if the post contains source code.

While the setup I described before with using org-mode to post to WordPress is mostly working, it’s a bit clunky especially if you’re using more than one computer to work on blog posts. Both Jekyll and Hugo can handle org-mode files directly – in fact, even though this file would be as effortless to write as Markdown, what you are currently reading is actually a processed org-mode file. Assuming that you’re reading this on the static site, that is.

What’s left to before the actual cutover?

There are two fairly large items I have to tick off the todo list before I can cut over for good.

  • Migrate the comments. Now this blog doesn’t get a ton of comments, but I appreciate all of them and am trying to migrate them over to this blog. As I believe in self-hosting everything, I’m experimenting with isso, and I need to redo some of the experiments with Hugo as so far, they’ve been completely focussed on Jekyll. Hugo does have built in support for disqus, plus this theme has support for staticman, but neither of the two are my preferred alternatives.
  • QA the site, especially the RSS feeds so that they hopefully keep working as they do right now.
  • There are still some minor tweaks to be done, analytics integrated and all that, but those are probably going to happen slowly after the cutover.
  • Oh, and the last item is all of the draft posts that have accumulated on WordPress that I somehow never got around to finishing.

The beta of the static site is here if you want to have a look. Any feedback is welcome.

Configuring MongoDB Java driver logging from Clojure using timbre

I’ve mentioned in the past how you can configure the MongoDB Java driver output from Java. Most Clojure applications that use MongoDB use a database driver that wraps the official MongoDB Java driver. I personally use monger for a lot of my projects, but also occasionally created my own wrapper. The methods described in this post should be applicable to other Clojure MongoDB drivers as long as they wrap the official MongoDB Java driver. They should also work if your application directly wraps the MongoDB Java driver itself rather than using a more idiomatic driver.

The MongoDB Java driver helpfully logs a lot of information via slf4j under the assumption that your application configures its output to an appropriate place. That’s all very nice if you already use slf4j and have it configured it accordingly. However, if you use Clojure (or you’re me) that’s probably not the case. At least I didn’t set up slf4j in any of my Clojure code.

Enter timbre. Timbre is a logging library for Clojure that optionally interoperates with Java logging libraries like slf4j. You can use the interop for slf4j via the slf4j-timbre library and most importantly for me, control the slf4j logging output from Clojure directly.

The timbre configuration for timbre 5.1 that I use in some of my Clojure projects  that interact with MongoDB is as follows:

(timbre/merge-config! {:min-level `[[#{"org.mongodb.*"} :error]]})

This configuration sets a minimum log level of error for any log output from the org.mongodb namespace. This is the namespace the Java driver uses for logging. Normally you wouldn’t just configure the minimum log level for the MongoDB Java driver, but for several different tools. As a result the timbre configuration for my projets tends to look more like this:

(timbre/merge-config! {:min-level `[[#{"org.mongodb.*"} :error] [#{"clj-ssh.*"} :warn] [#{"*"} :debug]]})

The configuration above sets a default minimum log output level of :debug. It also sets two additional log levels specific to the org.mongodb and clj-ssh namespaces. Obviously if you use other tools or have other namespaces that require special handling, you would add those to the configuration settings as well.

Note that using timbre and slj4f-timbre requires the following dependencies in project.clj:

:dependencies [[org.clojure/clojure        "1.10.0"]
               [com.taoensso/timbre        "5.1.0"] 
               [com.fzakaria/slf4j-timbre  "0.3.14"] ;; Attempt to send all log output through timbre
               [org.slf4j/jul-to-slf4j     "1.7.14"]]
My Timex 1000/Sinclair ZX81

I bought the first computer I ever wrote a program on

I don’t usually do Happy New Year posts, but given how “well” 2020 went I thought it was appropriate to start 2021 with a whimsy post.¬† This post is probably going to date me since it’s been a few years – OK, decades – since these were current.

Well, it’s not the actual computer, but the same model. I was first exposed to computers during the personal computer heyday of the early 1980s. Back then, my school had two computers, one TRS 80 Model 3 and one Sinclair ZX81. The ZX81 was used to teach pupils rudimentary programming. I wouldn’t be surprised if one of the teachers actually built it from a kit as that was the cheapest way to get into one.

Keep in mind that I grew up in Europe where computers like the Apple ][ were very expensive and didn’t gain much traction in the educational field. Or with hobbists, either. Yes, there were some around but you saw a lot more VIC20s, C64s or Ataris. A lot of schools including mine bought European manufactured computers like Sinclairs and later, Amstrad/Schneider CPC 464s.

Read More