Two features, one post. One command, even.

One problem that occasionally, but repeatedly, comes up is that Django's startproject command doesn't really do enough. You will always need to run startapp as well, and then you need to add the app to the INSTALLED_APPS. Or, does it actually do too …

I'd love to say I'm writing this a few days late because I've been thinking carefully about what to say. Sadly not, this will be as off the cuff as ever.

It was an interesting election this year. There were four seats up for grabs, and three of the four …

Recently, Andrew Miller, also known as nanorepublica on Discord and through his consultancy, Software Crafts, recently wrote a blog post on django.contrib and another on its future. I'm not sure how I feel about Mr. Miller's suggestions, but I do agree with him that it's quite confusing and does …

You might as well timestamp it was a post doing the rounds a few years ago. It suggests using timestamps rather than booleans just to have the extra data point of when something happened.

Lately I found myself in a different, but related situation. I had something like the following …

Almost invariably when I start to work at a new company, I look at the project configuration and find something like this:

[tool.coverage.run]
branch = true
omit = ["**/migrations/*"]

[tool.ruff]
exclude = ["**/migrations/*"]

My suspicion about how prevalent this is is confirmed by GitHub Copilot suggesting it to me the …

Some bugs are hard to even notice. For example, what if you forgot to add a title to one of your web pages? Oops! You're probably left with a generic title of only your site name, or worse, no title at all. And it's very tricky to spot this. Most …

You probably already know the value of testing your code. Your Django migrations are code, therefore you should test them. However, testing data migrations in particular can be tricky, and there's no documentation on how to do it.

Typically your schema migrations don't need any testing as your migrations are …