I moved this blog from WordPress.com to Octopress in 2013.

Moving from a “blog service” to a static site generator has been great:

• Hosting static content is pretty easy
• It’s backed by git, so I get all the benefits that brings: history, branches, diffs, etc.
• Security-wise, the attack surface is much smaller - the production site is just static HTML/CSS/JS, so there are entire classes of vulnerabilities and threats that I don’t have to worry about

However, it’s possibly come with a little complacency - I looked back recently to find I’d not actually updated the framework itself since my very first commit ~6 years ago. Slightly embarrassing (as someone who regularly talks about the benefits and importance of regular incremental updates) but not exactly surprising: “the cobbler’s children have the worst shoes” after all…

I like a lot of light at my desk. It gives a better picture when I’m on video calls, and I think the light increase helps my mood too.

Now, I’m a bit of a lighting Philistine. I have friends who definitely have Opinions about colour temperature and brightness, whereas I grab a pack of cheap LED bulbs from Amazon whenever I need some and as long as they vaguely match what I have already then it’s fine for me - but I figured I’d just make a stab at something on my own, and then get feedback afterwards from people who know better. So here’s what I’ve got:

Last year I wrote “My 2017”, inspired by Always Improve, Never Stop, Never Pause, Never Appreciate: things I did; not necessarily “achievements”, but happy and/or notable things.

I’m glad I did, so I’m doing it again. So, in no particular order:

As per last year, some things I read in 2018, with some brief opinions/recommendations.

All categorisations are approximate at best and will probably cause some kind of contention.

As of yesterday, I have a newsletter: Burn After Reading.

One of my side-projects at the moment involves me porting an old-ish (20+ years) large-ish (100,000+ lines of code) network game server from C to Go.

Thanks to cgo, similarities between C and Go, and the power of (some horrific) Vim regular expressions and macros, this is less epic than it might initially sound!

However, one thing has repeatedly stood out in the process, and will inevitably have me tearing my hair out in future due to the subtle bugs I’ve introduced as a result…

AWS Elastic Beanstalk is one of my favourite Platforms as a Service - essentially it’s Heroku but with more levers.

I’ve used it for tiny personal projects (though nowadays I’d probably use Lambda and a framework like Zappa or similar), and I’ve used it as the production platform handling significant traffic at previous jobs.

I think it’s a massively under-appreciated AWS service. All too often people seem to skip over it in favour of more powerful but more complex services like ECS or EKS, and I think they’re missing a trick.

Here are some tips for getting the most out of Elastic Beanstalk.

The US National Institute of Standards and Technology have produced a Blockchain Technology Overview (NISTIR 8202) with an excellent flowchart addressing “Do You Need A Blockchain?”:

This is a written version of a talk I gave in the main hall at PyCon UK 2018 based on prior talks, advice, and feedback I’ve given previously. Accompanying slides available on Speaker Deck.

Hiring is hard to do well, but easy to do badly.

Determining exactly how to do it well is hard and requires nuance and context. But avoiding common mistakes is much easier.

Fundamentally, hiring processes reflect the organisation.

If you’re on the hiring side, think hard about what you’re putting in front of people who want to join you, if that will attract and select for the people you want, and correctly filter those you don’t.

If you’re on the other side of the table, think about the people who created the system you’re going through, the kind of things they’re setting up for success and failure, and the kind of people who’ve likely got through the process before you.

I’m a big advocate of using services like Heroku or AWS Elastic Beanstalk rather than running your own servers where you can, but sometimes it’s the right thing to do. For my home automation setup, I want to keep as much of it on the local network as possible, so this was definitely one of those situations.

So I bought an Intel NUC - it’s small, fairly quiet so I can run it indoors, and yet fairly powerful (Core i5, 4GB RAM, 1TB HDD in the one I bought).

I want Infrastructure as Code. I want a documented reproducible version-controlled setup. One perspective is that this is overkill for “just a home server” - my position is that it’s even more necessary, because I’m going to fiddle with it sporadically, it’s highly unique, and it’s only me maintaining it. However I still want a fairly minimal setup.

In the past I’ve done things like writing a bunch of Puppet or Ansible and/or running a suite of VMs, but this can get tedious fast - hoping that a module exists, handling dependencies, encoding installation instructions as config management, etc.

What I really want is akin to a self-hosted PaaS that I can easily deploy on a single box, and that allows me to define apps declaratively.

Thanks to Docker, Docker Compose, Traefik, and a bit of systemd config, that’s fairly straightforward!