I really like Django. Django is fast, featureful, secure, scalable, and versatile. It works well with a variety of workflows, approaches, tools, platforms, and libraries.

But sometimes you can have too much choice.

I’ve spent a lot of time working with Django, and supporting other users via IRC in #django on Freenode. In that time I’ve seen a lot of the same questions come up again and again.

Django doesn’t provide official answers to many of these questions, and I don’t think it should - its versatility is one of its strengths. Here are my answers though - all of which are broad and given without knowing exactly what you’re doing - they’re not universally correct, but in the absence of knowing better, if you’re facing an unclear choice, then they should provide some clarity.

Good luck!

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.