Recent

I frequently consult the docs of Django's set of default template tags and filters and there's one part I often forget about, because it's not enabled by default: django.contrib.humanize. Here's a reminder.

Continue reading »

Django uses the name of the form field as the name attribute of the corresponding form element in HTML. If you ever need to change it, here's how (Django 5.2+).

Continue reading »

Django 6.0 introduces a built-in background tasks framework in django.tasks. But don't expect to phase out Celery, Huey or other preferred solutions just yet.

Continue reading »

We probably all know the ins and outs of Django models, and the settings we need to tweak before heading to production. But Django's packed with tiny bits of useful, lesser known constructs and functionality you can safely reuse. Like SimpleLazyObject.

Continue reading »

I'm often finding myself being afk for a few minutes, while some process is running. Got to stretch those legs, you know?

I've started using nfty to send me a notification on my phone as soon as a process has completed, so I can actually go ahead and step away without having to check in. And it really couldn't be easier.

First: set up your ntfy account and a topic.

Second: add something like the function below to your .{bash,zsh}rc. Or turn it into a script.

function ping_me () {
    local default="FYI: that thing you triggered just stopped."
    local message="${1:-$default}"
    # $ntfy_topic_url is something like 
    # https://ntfy.sh/yoursecretishtopicname
    curl -sf \
        -H "Title: laptop" \
        -d "${message}" \
        ${ntfy_topic_url} \
        > /dev/null || echo "Ping failed"
}

Third: use it!

Now running just docker-build docker-push && ping_me means Docker can have some fun while I go grab a coffee, check on the laundry, or walk around aimlessly trying to figure out what I was planning on doing.

Something that always made me wonder: why doesn't the IntegrityError raised by a database (driver) include some actual actionable data?

I don't know. I do know that it doesn't have to stay that way! With Rootcause you'll be able to gather all necessary information when you violate the most common types of constraints in Django.

import rootcause

try:
    ... # something violates a constraint
except IntegrityError as e:
    cause = rootcause.resolve(e, model=MyModel)
    if cause.is_check(name="max_amount"):
        raise MaxAmountExceeded()
    if cause.is_unique(name="payment_reference"):
        raise AlreadyPaid()

The goal of Rootcause is twofold: provide more information and eliminate differences between databases.

Rootcause has been tested with recent versions of SQLite, PostgreSQL and MySQL, and requires Django 5.1 or better.

Go check it out over on GitHub and fetch it from PyPI.