The BBC has an excellent radio programme called ‘A Good Read’. It first started 1977, and there have been hundreds of episodes, each of which has several celebrities and authors recommending a book each along with the host. Many episodes (though not all, the online archive goes back to roughly the early 1990s) are hosted for free to listen to on the BBC Sounds website. I often like to listen to it, but couldn’t find anywhere that the books had been recommended were listed online.

Go first came onto my radar about 9 years ago when I came across MuMax during my PhD studies. While I’ve touched it briefly, I wouldn’t consider myself to have used it in anger until recently, when I started a job that uses it as one of it’s primary languages for API development. I’ve had experience in writing C and C++ code, but more recently I’ve done a lot of Python, so going back to Go has felt oddly like a throwback to those compiled languages I’ve used before, with a bit of modern sparkle.

When writing numerical software in Python, there is a somewhat overwhelming array of options for tackling performance issues. From experience, it’s very hard to actually evaluate which of these options is “best” for performance without actually trying them in a specific scenario, and to understand what is happening requires an understanding of both the Python, NumPy, and lower level language’s call stack, the input arguments of the particular routine, and the system on which the code is designed to run on.

Alpine Linux is a distribution that is designed to be lightweight. In particular, it’s seen a lot of use in Docker images because the resulting image bundles are considerably smaller than those generated by other minimal distros. However, in the context of building a Docker image for a Python application, it’s worth thinking carefully before using Alpine, as it can often result in slower builds and counterintuitively it can even result in larger images occasionally.

Django REST Framework has two methods for writing APIs - function based views (similar for people coming from other frameworks like Flask or FastAPI), or class-based views (which is more like the patterns in the ASP.NET and Spring frameworks). Class-based views seem to have won out within the Django community, and so here we will focus on those, but even after making this choice, developers still need to decide which type of class-based view is appropriate.

Writing good software is an art rather than a science, and often decisions made quickly lead to a lot of pain down the line, because it is difficult to see the impact of them. With that said, here are a few of the rules I try and stick to when writing software in order to keep it maintainable and to allow course correction straightforwardly later. 1. Abstract away complexity The KISS principle is well known among software developers, but it’s all too common to see people try and incorporate clever solutions into their code bases.

Django migrations can be very powerful, and allow you to effectively execute arbitrary code to modify your database, by migrating your database from one schema to another. A common pattern that beginners in Django often get wrong is to do something like: from app import MyModel def my_migration(apps, schema_editor): objects = MyModel.objects.all() # Some code that then modifies the objects... What is wrong with this is not immediately obvious. When you run code like this the first time, it will likely certainly work correctly, and you’d be inclined to think that it’s correct.