I have several Django projects, like my timebox or chore tracker project.

Two fields I will often add to most models is some kind of description/memo field and a url/more field.

from django.db import models

class Project(models.Model):
    # most of the model specific bits
    ...
    # common fields I add.
    description = models.TextField(blank=True)
    url = models.URLField(blank=True)

I will typically allow either to be blank, since both are intended to be optional.

A name/title might be enough as a quick hint or label, but often having a longer description/memo field is essential to provide extra detail once you have enough objects. I have mostly kept it as a plain text description (I will often use {{ obj.description|linebreaks }} to allow a bit of formatting), though other times I will consider allowing a full markdown description.

A friend recently wrote “our personal database , about how they maintain a postgres database for various projects. I wrote something similar when I wrote about my personal api , though Rubenerd’s post made me want to write a little bit more about it.

Since I am already using django for various projects, my personal API is also built on Django. While I could modify thing directly using something like pgAdmin, building on Django means I can take advantage of the models and admin built in to Django.

There have been a few times while working with Django , where I have wanted to triger something only if the instance changed. Since Django provides a robust signals system, I decided to use that for my prototype.

First we need to import the packages we will use.

from django.db import models
from django.db.models.signals import post_save, pre_save, ModelSignal
from django.dispatch import receiver
from django.forms.models import model_to_dict

Next, we want to handle our pre_save signal. We want to store a snapshot of the original object so that we can compare it later.

One advantage of having my own personal api is that I can put various useful scripts under a single repo and have them run. I have been using raindrop for several years, to collect bookmarks to read later. Often, while researching things, it would be useful to automatically group things into collections, so I wrote some celery tasks to help with this.

I have long been inspired by Aaron Pareki and his pk3 tool for his website. With some searching, one can find other kinds of personal management systems on GitHub or other developers writing about their own personal api with links to other examples. As a developer myself, I have my own personal API that I am able to add to as wanted.

In the interest of choosing boring technology my personal api is powered primarily by django and celery .

Django comes with support for MIDDLEWARE and provides several useful ones by default. I usually try to make my projects as useable as possible, and some debug middleware is only useful when development.

Example Middleware

Since the order and layering often matter, I’ll usually configure all my optional middleware in the correct spot like bellow, with a short comment.

MIDDLEWARE = [
    "debug_toolbar.middleware.DebugToolbarMiddleware",  # Only enabled for debug
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",  # Used primarily for docker
    "django.middleware.locale.LocaleMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

Then I’ll use other conditional checks to see if this list (or other variables) need to be modified.

I’ve been using hugo for my blog for a while, and while I appreciate being able to write posts in anything that supports Markdown, I’ve never enjoyed making sense of their template system. My site curently uses a fork of hugo-bootstrap (to fix minor bugs) with some other customizations from hugo-worklog that I wrote.

Ideally I would like a system where I can use django for the site, but maintain the same editing flow I have for my current site.

Our goal when packaging up a Django application, is that we can use it as part of an existing application, or we can run it by itself in a standalone mode. To this end, I have over time, started to package my django applications in the following way. You can see diffs of all the commits in the example-django repository.

Start with a Makefile and setup files

Instead of using tools like Poetry and Pipenv , I find it easier to just create a basic Makefile to use as the entrypoint.