Kristian Glass - Do I Smell Burning?

Mostly technical things

2018 in Books

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.

Switch Statements - a C/Go Gotcha

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…

Three Tips to Get the Most Out of AWS Elastic Beanstalk

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.

How (Not) to Screw Up Hiring

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.

Containerised Home Server With Docker Compose and Traefik

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!

Handling .local Hostnames - Multicast DNS

DNS is great. Having to remember IP addresses sucks.

Being able to plug in a device to my home network, give it a name, then be able to reach it as $name.local? That’s great. (One day I’ll set up local authoritative DNS but realistically that’s unlikely to happen soon)

How does that work though? And what do you do when it doesn’t?