I’m making progress on the latest Thonk order, but kitting is taking a little longer than planned, broken up over the course of days, as parts arrive, or inaccuracies in BOMs reveal themselves (notably - when multiple suppliers are involved). So I push forward, doing what I can when I can, and spending the rest of the time on other work.

That other work has included overhauling some of my websites - and where, and how they’re hosted. I’m trying to work out I can offload to simpler hosting setups in order to reduce my workload and responsibilities. That’s included porting a few sites from Wordpress to Hugo and moving to CDN-style hosting, through services such as Netlify.

Of course, by moving to flat files, I’m not locked in to those services: HTML is HTML, and can be hosted almost anywhere. So the work to simplify and strip down actually means I can be confident that should my hosting needs change, hosting them anywhere else is also straightforward.

Hugo’s been really satisfying to work with. I’ve poked at a fair few static site generators in my explorations before settling on this. The decision making came down to a few points:

• I’d love incremental-build (where only dirty changes are compiled) to be working, but even SSGs that say they support it don’t really. So, rather than prioritising incremental build, why not prioritise pure speed? Hugo is very, very fast.
• I like that it’s a compiled Go binary; it works “everywhere”, is easily portable, and doesn’t require huge module dependencies just to run.
• Because it’s precompiled, it doesn’t have a dynamic plugin structure. That may sound limiting. But, in fact, it forces me to do more with ‘just template language’. The Go template language is a bit idiosyncratic, but I like templating languages a lot, and it forces me to think about markup and structure, rather than just bodging everything with dynamic code. I mean, I used to work with Velocity a lot, so I’m used to getting a lot out of limited tools. (I should note - Velocity was… 13 years ago. I’d rather not ever use it again now…)

And, of course, by getting me to reduce content to Markdown and templates, not only is the output easily portable, but the source code is also relatively easily portable - if I ever move away from Hugo, obviously templates will need rebuilding, but the content is in a neat portable format - not tied up inside a database schema that will need exporting.

So that’s been productive, and largely changed my opinion on SSGs for my own personal use.

I greatly enjoyed playing with Ableton’s Learning Synths earlier in the week. Not just because I’m interested in the subject area, either! It made lots of smart pedagogical choices that I really enjoyed, as someone thinking about explanation and education a fair bit:

• before introducing anything technical, start with abstract tools and aesthetic output. In Ableton’s case, that meant: boxes that make noises as you drag around. Things that sound satisfying. Descriptions of things you’ve heard. Supply the learner with context for what you’re about to present.
• only then is it time to start mapping those things to terminology such as pitch or timbre.
• using pitch to illustrate modulation options - envelopes and LFOs - makes it very easy to hear their input. Even though other controls are more common destinations for modulation, starting with pitch makes understanding the metaphor clearer, quicker.
• making all the later examples Just Work with any attached keyboard attached is a superb idea

There’s so much care in the implementation of the project, too, from the delightful animations through to the richness of the tools. And, a common strand with Ableton: note their willingness to promote applicable knowledge, rather than their own tools, in their education work.

Full marks, and ideas I’m sure I’ll keep thinking about.

And that was Week 338.