DEV Community: Adam Hill

Checking Django Settings

Adam Hill — Thu, 12 Feb 2026 15:57:58 +0000

I still keep coming back to this "the settings file still feels like a lot" concern in https://jvns.ca/blog/2026/01/27/some-notes-on-starting-to-use-django/#the-settings-file-still-feels-like-a-lot. What I was thinking about before was a LSP (Languge Server Protocol) which basically gives an IDE more metadata about the code it is parsing.

I have a prototype of that here: https://github.com/adamghill/django-lsp. It works pretty well for settings files, however I also wanted to approach this problem from another angle.

Could Python type hinting be used to alert the developer when they misconfigured a setting?

Type-checking settings

For example, a common one that has bit me in the past is something like this:

from os import getenv

DEBUG = getenv("DEBUG")

If you run DEBUG=False python manage.py, your DEBUG setting will be a string, not a boolean. Then, something like if settings.DEBUG: will evaluate to True. Why? Because the string "False" is truthy. But, obviously, that is unintended and a bug.

If we define the types for all Django core settings, e.g. DEBUG: bool, DATABASES: list, etc. then we can at least validate that the setting is using the correct Python type.

One downside is that this doesn't help the developer when writing the code, i.e. this is not autocomplete in the IDE. However, it can be used as a runtime check as part of Django's check system. This would automatically alert the developer they are using the wrong type when runserver starts up.

Handling dictionaries

The above type check seems useful for simple settings, however another problem is that some settings are lists of dictionaries or dictionaries of dictionaries.

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": "db.sqlite3",
    }
},

This can be very error-prone for developers because the keys like "ENGINE", "NAME", etc. are just strings. One approach here might be to provide helper methods which can guide the developer to use the correct functionality.

from django_settings_check import DATABASE

DATABASES = {
    "default": DATABASE(
        ENGINE="django.db.backends.sqlite3",
        NAME="db.sqlite3",
    )
},

DATABASE is actually a function with defined args which means the IDE can autocomplete the acceptable options. And then it returns a dictionary which is what Django expects for settings.

There are a few other libraries for Django that provide cleaner ways to specify settings, but I have shied away from them in the past because they seem too "different" than regular Django. Maybe there is a way to implement this without changing too much about the default Django setup.

Looking for feedback about these ideas or if developers think this might be useful.

Setup Dozzle with Auth on Coolify

Adam Hill — Tue, 11 Nov 2025 12:37:55 +0000

I have been using Coolify for over a year to self-host on Hetzner and I am a big fan. However, I wanted a lightweight way to see how all of my websites were performing.

I had used Dozzle in the past as a way to see logs, but it has drastically improved and can now show real-time resource information now as well.

Adding authentication to Dozzle is not too challenging, however, I had to cobble together a few resources, so here is a step-by-side that I did for future me.

In your deployed Coolify app, Resources->+ New
Type "dozzle" in search bar
Click Dozzle With Auth
Update Service Name to "dozzle"
Click Save
Click Persistent Storages in the left side bar
Click Files in the tab bar
In a terminal on your local machine, run docker run -it --rm amir20/dozzle generate admin --password YOUR_PASSWORD --email YOUR_EMAIL_ADDRESS and copy the output
Paste the output from your terminal into the Content text area under the Files tab in Coolify
Click Save at the bottom of the text area
(optional) Under Services, click Settings and update Domains to point to whatever domain you set up
Click Start/Restart

Dozzle dashboard:

Dozzle logs:

Making Time

Adam Hill — Sun, 10 Aug 2025 12:44:35 +0000

I get asked how I "do so much" sometimes when I meet people in the context of starting new side projects, releasing open source libraries, or being active in a community. None of this is prescriptive -- everyone has to decide what they want for themselves, but I have self-reflected on this question a decent amount.

But, first a caveat: one lesson I have learned over time is to try to not judge myself compared to others -- especially those I do not know well. I have gone through seasons of my life (a term I first heard on a Startups for the Rest of Us podcast a long time ago) where I mostly consumed instead of created. I have taken sabbaticals where I did not think about or write any code at all. I have taken vacations where I have completely disconnected from the digital life. To me, that's healthy and everyone gets to decide what makes them the happiest. However, if you are interested in "making more time" in your life to work on a side project (either for a short amount of time or longer), I do have some ideas.

Cut out everything extraneous

Time with family, day job, health (working out, sleep, cooking). Those are my priorities (and my current priority order) and I stick to them, but everything else is negotiable. You should make your own list! What isn't on my list: watching TV, sports, video games, etc. All things which tend to eat. up. time. If the goal is to make more free time in your day, I (mostly) avoid things that will suck up lots of it with minimal return on investment.

But but but, I hear you say, I like video games! That's fine, make your own list. But, know there is only so much finite time in the day so you are making an implicit trade-off.

Your trade-offs will change over time as well. When I was younger I could get less sleep to free up more time, but I cannot do that anymore without wrecking my next day. So, sleep became a non-negotiable, but other things got de-prioritized.

Consume

It might sound counter-intuitive after the last point, but one way I get exposed to different ideas is to consume more media. However, it needs to be a specific type which inspires me -- for me that is podcasts, books (mostly around business, bootstrapping, UX, and design), and (maybe surprisingly) social media.

Podcasts

The benefit is that I can listen to podcasts when I'm already doing something else: mowing the lawn, doing dishes, driving, grocery shopping, etc. I curate my subscriptions religiously, but I tend to listen to tech or business-focused podcasts -- here are the ones I prioritize:

Startups for the Rest of Us (tactics for bootstrappers, some interviews, some Q&A)
MicroConf On Air (conference talks about bootstrapping)
Mostly Technical (2 guys talking, bootstrapping, somewhat Laravel-focused)
Notes on Work (off-the-cuff Caleb Porzio, creator of Livewire and Flux)
Soft Skills Engineering (not business at all, but I love it)
The Town (the business of Hollywood)
My First Million (somewhat bro-y business dudes)
Lenny's Podcast (product-focused, but can feel "big tech"-heavy)
The Pragmatic Engineer (can feel AI-heavy)
Django Chat (interviews with Django folks)

I have tried listening to audio books, but I could never get into the habit for some reason. In my opinion, most podcasts are shorter and are easier to jump into and out of, so maybe that's why.

Books

I mostly read before I go to bed as a way to wind down. I tend to go back and forth between fiction (creativity! fun!) and non-fiction (learn! new ideas!).

Social media

With the death of Twitter (yes it died, no I'm not on X 😂), I have switched to Bluesky and Mastodon which I use similarly. With both, I heavily curate my feeds to tech and business folks. If someone is consistently a downer -- unfollow. If someone always posts about politics -- unfollow. If someone only posts about technology I don't care about -- unfollow. I don't feel bad about it and neither should you.

People get to post whatever they want, but I also get to unfollow them if I want. 🤷

Social media exposes me to ideas and thoughts from outside of my bubble which can be useful. And since Bluesky and Mastodon don't have aggresive algorithms boosting rage-inducing posts all the time, it's mostly pleasant.

Limit innovation tokens

"Innovation tokens" are a concept from Choose Boring Technology which resonated strongly with me when I first read it and I think about constantly. It is basically a way to reduce risk by using technology where you already know the trade-offs. It applies to my dayjob, but it is especially important for side projects when time is limited.

Be explicit about your goals -- if the goal is to learn a new technology, then use as many innovation tokens as you want. Go bananas. Spend 4 weeks setting up a kubernetes cluster because you read a blog post about it. However, your users do. not. care. Probably. 😉

For every new side project, I limit the number of new technology I try to incorporate -- and stick with my "boring technology stack" for everything else. However, my goal is normally to launch something as fast as possible. However, I also think it's important to play with new tech -- that is part of what makes it fun to me personally.

De-scope to de-risk

To me, the ability to launch new side projects fast is tied to de-scoping and prioritization. What is the minimal amount of features so that someone else can try your thing? It's different for every project and it's where you get to demonstrate your personal taste. I've released a new open source library that is literally one function. I have launched (along with Sangeeta) a "social network" where you can only sign up and add links to a profile.

I tend to put things out in the world that solve one particular problem without thinking about it too much. Do people seem to like it? Are they sharing it, giving it stars, etc? Are you getting feedback? Does this thing resonate?

Steve Blank says "No plan survives first contact with customers". In the same vein, I think "Projects that never launch never progress". You need to launch to get feedback, so launching as fast as possible is one of my expicit goals.

Repeatedly roll the ball forward

Consistently working on one thing and making small iterative improvements based on a highly prioritized list are the compound interest of side projects: it stacks up over time. After a month you can look back and think, "how did I get from 0 to here with only an hour a day?!" But, it's true and I have seen it happen over and over again.

Repeatedly showing up and focusing can build amazing functionality over time. Start small, iterate, and improve.

Conclusion

Again, I'll reiterate that what works for me probably won't work for you -- everyone is in a different stage of life and gets to prioritize their life as they want. However, hopefully some of this has been helpful or given you some ideas about how to make time in your life if you want to work on more side projects or launch that new open source library!

Thank you to Tim White and Sangeeta Jadoonanan for proofreading and edits.

Request for maintainer(s) for django-unicorn

Adam Hill — Tue, 03 Jun 2025 00:38:38 +0000

After starting building django-unicorn in July 2020 and spending probably 3-4 years diligently adding features, fixing bugs, and driving the project forward, I have decided I need to officially look for other maintainers to help out with the project.

django-unicorn is an interactive component library for Django. It sort of works similarly to Livewire for Laravel.

Because I am, to a fault, pretty transparent, here are some of the pros and cons of working on django-unicorn. 🦄

The good

django-unicorn has over 2.5k stars on GitHub, so I'm pretty sure it is solving a pain point for Django developers.
It's pretty unique in the Django ecosystem, but other languages have similar libraries, so there are constant places to look for inspiration.
Pretty high test coverage, the use of Python types, etc.
It is used in production by a number of companies AFAIK.

The bad

It's complicated: there is both a custom JavaScript reactive library and Django back-end code.
The backend in particular does some ✨ magic ✨ with undocumented Django APIs.
Replicating user bugs can be a challenging experience.

The ugly

Some features probably need a re-think, e.g. child components.
Requiring a cache for components was useful, but probably not a great approach going forward.
HTMX seems to have "won" for frontend libraries (that aren't React/Vue) in the Django ecosystem (no shade here -- I'm a fan of HTMX as well).

The future

Ideally, one (or more!) people would be interested in helping me work on django-unicorn going forward. I'm not sure I can commit to working on it forever, but I do pledge to help others ramp up, work through issues together, and help guide the project forward.

I do think there are lots of opportunities to improve the project (I have a list of pie-in-the-sky ideas if anyone is interested), but even if someone was willing to help triage and write tests for issues that would be a good start.

Why would you want to help?

A chance to work on a project that already has some traction, improve it, and help out the Django community to build cooler (read: more interactive) websites quicker.

Do you have ideas about how to build better websites in Django quicker? I'd love to hear from you. Please DM on Mastodon (adamghill@indieweb.social) or in this discussion: https://github.com/adamghill/django-unicorn/discussions/746.

More context

Documentation

The journey

The definitive guide to using Django with SQLite in production 💡

Adam Hill — Sat, 18 Jan 2025 19:02:13 +0000

I have been running Django sites in production under heavy load for over 10 years at my day job. We started with a MySQL database backend but, after running into a few issues, switched to PostgreSQL which has been rock-solid. I tend to use the same stack for side projects. Especially because, initially, most of my projects were hosted on Heroku and they had stellar support for PostgreSQL. Now, having bounced from Heroku to Render to Fly.io to Digital Ocean (with CapRover) to Hetzner (with Coolify), I am re-evaluating my default choice of database.

I currently have a managed PostgreSQL database at Digital Ocean which has worked well, but I have been looking into using SQLite in production to reduce server costs and network latency. And, since I'm not particularly DevOps-y, I do not want to be on the hook for maintaining my own PostgreSQL database. So, I have been investigating other solutions for my newest side project, filmcliq.com.

The promise

There has been a lot of conversation about using SQLite as a production database for websites for the past few years, espeically in the Rails community with Litestack. And now, in the latest version of Rails, SQLite has become the defacto backend for many parts of the stack.

The Rails 8 release notes details a lot of the "why" for using SQLite in production. But, mostly it comes down to: reduce the complexity of building and maintaining a website.

No separate database server, e.g. PostgreSQL
No separate cache server, e.g. redis
No separate queue broker server, e.g. RabbitMQ

Especially for side projects with limited traffic requirements and scaling concerns, the promise of SQLite is that it can remove a lot of ongoing hassles. Without a separate database, cache, or queue, there is less network traffic (because the SQLite file is local), and less servers to manage, maintain, and backup.

Some mild concerns

It's not all gravy, though. There are a few things to watch out for when using SQLite in production.

One container to rule them all

Because the SQLite file is typically local to the container, it is not straight-forward to have multiple containers share the same database. Usually that will not be a problem for low to medium traffic sites because they might not need to scale horizontally beyond a single container. Increasing the number of worker processes in gunicorn (or other webservers) and/or increasing the amount of CPUs available to the container can mitigate this restriction.

There are also a few other options that attempt to scale SQLite across multiple hosts. I have not investigted any of these fully, but wanted to mention them just in case.

SQLite Cloud: Cloud-based SQLite database service (Django quick start)
Turso libSQL: A fork of SQLite that supports distributed databases (django-libsql)
rqlite: The lightweight, user-friendly, distributed relational database built on SQLite
marmot: A distributed SQLite replicator built on top of NATS

Deployment downtime

Because of the "only one host" issue, no-downtime deployment is a little tricky. I detail an approach for limited downtime during deployment below using Litestream to replicate/restore the database, which seems like an acceptable trade-off for many projects.

Django settings

Django has great initial support for SQLite and, with a few tweaks, it can serve production traffic for the database, cache, and queue broker.

Database

Django has built-in support for SQLite and the default settings.py uses SQLite, so you have probably seen something like this before.

# settings.py

...

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    },
}

These settings will work okay for local development, but they are not optimal for production. When running under any sort of load you will run into the dreaded database is locked error. To prevent this issue, change the "default" database to include the following options which are based on best practices from Rails. I also tend to put the database in a separate directory (configured with the "NAME" key) called "db" to keep the root directory clean.

The settings below are only applicable in Django 5.1+. If you are running an older version see Anže's article for another approach.

# settings.py

...

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db/site.sqlite3",
        "OPTIONS": {
            "transaction_mode": "IMMEDIATE",
            "timeout": 5,  # seconds
            "init_command": """
                PRAGMA journal_mode=WAL;
                PRAGMA synchronous=NORMAL;
                PRAGMA mmap_size=134217728;
                PRAGMA journal_size_limit=27103364;
                PRAGMA cache_size=2000;
            """,
        },
    },
}

You might wonder if the foreign_keys PRAGMA would be useful. Lucky for you, Django already includes it for SQLite databases!

Cache

Django has a built-in database cache. You can enable it by adding the following to your settings.py file.

# settings.py

...

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.db.DatabaseCache",
        "LOCATION": "cache",
    }
}

However, that will use the "default" database configured above. Depending on your needs, you may want to use a separate SQLite database for the cache. I like this approach because I tend to think of cache as ephemeral, therefore I do not want the cache database table to be backed up along with the main database.

Update databases settings

# settings.py

...

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db/site.sqlite3",
        "OPTIONS": {
            "transaction_mode": "IMMEDIATE",
            "timeout": 5,  # seconds
            "init_command": """
                PRAGMA journal_mode=WAL;
                PRAGMA synchronous=NORMAL;
                PRAGMA mmap_size=134217728;
                PRAGMA journal_size_limit=27103364;
                PRAGMA cache_size=2000;
            """,
        },
    },
    "cache": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db/cache.sqlite3",
        "OPTIONS": {
            "transaction_mode": "IMMEDIATE",
            "timeout": 5,  # seconds
            "init_command": """
                PRAGMA journal_mode=WAL;
                PRAGMA synchronous=NORMAL;
                PRAGMA mmap_size=134217728;
                PRAGMA journal_size_limit=27103364;
                PRAGMA cache_size=2000;
            """,
        },
    },
}

Add a cache database router

Because the cache database is separate from the "default" database, we need to tell Django about it with a database router.

Create a new file called routers.py and add the following to it. I put it in a directory named "project", but it can go anywhere.

# routers.py

DJANGO_CACHE_APP_LABEL = "django_cache"


class CacheRouter:
    """Route cache queries to a separate "cache" database."""

    def db_for_read(self, model, **hints):
        if model._meta.app_label == DJANGO_CACHE_APP_LABEL:
            return "cache"

        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == DJANGO_CACHE_APP_LABEL:
            return "cache"

        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        if app_label == DJANGO_CACHE_APP_LABEL:
            return db == "cache"

        return None

Then add the following to settings.py.

# settings.py

...

DATABASE_ROUTERS = ["project.database_routers.CacheRouter"]

Cache table creation

You will need to call createcachetable as part of the deployment process to create the cache table like the following.

python manage.py createcachetable --database cache

Queue

In the past, there were specific services like RabbitMQ that were used for queueing tasks. However, there are a few Django libraries that can use the database (and by extension SQLite) to queue background jobs.

Deployments

As mentioned above, because SQLite is just a file in the same container as the webserver, when a new container spins up with a deployment, the current state of the database will be lost.

Thankfully, there are a few approaches to handle this. One is to replicate the continually current database state to an S3 bucket and then restore it during new deployments.

The basic idea is:

Replicate the current state of the database to an S3 bucket while container 1 is serving traffic
When a new deployment starts, spin up container 2
Container 2 downloads the current state of the database from the S3 bucket
Switch traffic from container 1 to container 2
Container 2 starts serving traffic and replicating the database to the S3
Container 1 shuts down

With something like Coolify, the switch from container 1 to container 2 will be handled automatically for you. There will be a slight blip during deployments, but it will be very minimal -- that's the trade-off for less complexity and a simpler infrastructure setup. And with a CDN like Cloudflare or Fastly serving the website, the downtime potentially can be non-existent.

Litestream is the gold standard for replicating SQLite databases to S3. There are many S3-compatible storage options available. I currently ship a replica to both Cloudflare R2 and Hetzner Object Storage just in case. Backblaze B2 is another option, as is AWS S3, obviously.

First, I install Litestream as part of my Dockerfile.

...

# Install wget and Litestream
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked --mount=type=cache,target=/var/lib/apt,sharing=locked \
    apt-get update --fix-missing && \
    apt-get install --no-install-recommends -y wget && \
    wget https://github.com/benbjohnson/litestream/releases/download/v0.3.13/litestream-v0.3.13-linux-amd64.deb && \
    dpkg -i litestream-v0.3.13-linux-amd64.deb

ENTRYPOINT ["./entrypoint.sh"]

Then, in the entrypoint.sh file, I add the following to restore the database from S3, collect static assets, migrate the database, create the cache table, and finally, start the webserver.

#!/bin/sh
set -eux

echo "Setup database..."
mkdir -p "db"
chmod -R a+rwX "db"
litestream restore -config litestream.yml -if-db-not-exists -if-replica-exists "db/site.sqlite"

echo "Collect static files..."
python manage.py collectstatic --noinput

echo "Migrate databases..."
python manage.py migrate --noinput

echo "Create cache table..."
python manage.py createcachetable --database cache

echo "Start litestream and gunicorn..."
litestream replicate -config litestream.yml -exec "gunicorn project.wsgi --config=gunicorn.conf.py"

The -exec argument for replicate starts the gunicorn process and allows litestream to do simple process management for the webserver.

In the litestream.yml file, I have the following configuration.

dbs:
  - path: db/site.sqlite3
    replicas:
      - name: my_s3
        type: s3
        endpoint: s3-endpoint.com
        access-key-id: ACCESS_KEY_ID
        secret-access-key: SECRET_ACCESS_KEY
        bucket:   bucket-name
        path:     site/site.sqlite3

The access-key-id and secret-access-key can be read from environment variables to prevent checking in secrets to version control.

Conclusion

With the above setup we have accomplished a few things:

Reduced complexity: no separate servers for database, cache, or queue broker
Reduced network latency: the SQLite file is local to the container so there are no network hops
Lower cost: no managed servers to pay for
Less maintenance: less servers to manage, keep up to date, and backup

Hopefully this was helpful if you are looking to use SQLite with Django in production. Please reach out to me on Mastodon or Bluesky if you have any questions or feedback!

More resources, documentation, and details

Thank you to Tim White and Sangeeta Jadoonanan for proof-reading this article.

Photo by Jan Antonin Kolar on Unsplash

So you want to make a podcast

Adam Hill — Fri, 31 May 2024 12:50:48 +0000

On my drive home from DjangoCon 2023 I came up with a wild idea.

I should make a podcast about Django.

But, I didn't want to make a podcast by myself! However, I had just worked with my coworker and friend, Sangeeta, to create quirky stickers to give out at DjangoCon, and she would be the perfect co-host.

There are already a few podcasts about Django available, but I thought we could do a fun spin on it. And similar to when we decided, spur of the moment, to sign up to give a Lightning Talk at DjangoCon, the idea was half-exciting and half-terrifying.

We both listen to a lot of podcasts so we already had some ideas about what makes good content and what doesn't. And between the Django stickers and an internal work presentation we co-created in the past, Sangeeta and I know how to work well together on a creative project.

We talked about a few other topics we could make a podcast about, but we kept coming back to Django -- we both use it daily, have lots of production experience with it, have opinions about it, and it seemed like a nice way to give something back to the Django community.

From inception (October 2023) to the first episode launch (March 2024) of Django Brew, it has been a huge learning curve. We knew what we wanted the podcast to be like, but we didn't know how to create it. We still aren't professional podcasters or anything, but we are three episodes in, so we know more now than we did at the beginning!

Decisions, decisions

First, decide on what sort of content you are uniquely qualified to talk about. Lean into your "unfair advantage" because that will resonate best with the audience. For us, we are passionate about Django and the community. I think all of those qualities come through in the podcast. If we didn't care as much the audience would instinctively know.

Then, decide on what kind of podcast you want to make. There are interviews, news, tutorials, long-winded opinion shows, and lots of things in-between. We knew of a few interview shows for Django, but fewer where developers talked about their experience building with Django.

And decide why your podcast will be different than all the others. Our goal was to make the podcast like two friends talking about Django -- we wanted it to be funny, full of excitement, and a little bit goofy. We try to capture our personalities while talking about a framework that we love. I couldn't (and wouldn't!) want to make a podcast by myself. My favorite podcasts have 2 hosts because the dynamic completely changes with a second person -- I'm definitely not engaging enough to host a podcast by myself. 😂

Equipment

Originally, we tried iPhone Bluetooth mics, laptop mics, and a few other corded and cordless mics. But, the sound quality wasn't great and we kept reading that a better mic would help, so we decided to splurge and each got a dedicated microphone.

Microphone

The Samson Q2U came highly recommended from Reddit and Transistor's podcast equipment guide. We've been pretty happy with the sound quality -- they aren't super high-end (we can't all be Wes Bos!), but for $100 for a mic, boom, shock mount, and pop filter it seemed reasonable.

Software

We tried a few different software setups before settling on our current setup. I am sure there are less time-intensive ways to record a podcast, but this is the software and process we currently use. For other types of podcasts (or more seasoned professionals!), it might be completely different.

Notion

Sangeeta and I use the free tier of Notion to brainstorm episode topics, write scripts, and keep a rough outline for each episode.

Riverside

We use the free tier of Riverside to record the actual podcast audio. One benefit over Zoom is that there is no time limit for the "meeting". It also has the ability to export each person's audio separately which makes the editing of the final audio easier. We don't use any other features in Riverside other than recording audio, but might look into it more in the future.

There is a limit in Riverside for how much recorded content can be stored every month, but we don't currently hit that limit.

Audacity

After recording each session, I export each audio track as a WAV and import it into Audacity. There is a little bit of a learning curve with Audacity, but it is free and rock-solid. For the limited things I want to do (i.e. cut/copy/paste, silence, limit, fade-in, and fade-out) it works great.

For a 20-30 minute episode, we tend to record 2-3 hours of audio over multiple sessions (that includes lots of re-takes, general chatting, and some planning of what to talk about next)!

I do rough cuts of all of the audio together and then I send drafts to Sangeeta for her to listen to and give me notes. We'll go back and forth over multiple drafts, making notes for each other, and deciding on different parts we want to change or re-record. It probably takes at least a few hours to do all of the editing.

As part of the editing process, I also grab anything particularly goofy and keep another project with all of our episode bloopers.

Ableton

Once we get close to a finished product, I send the episode and bloopers to Sangeeta who uses Ableton for the final edits. Ableton is not free, but Sangeeta had used it before for other projects and had already paid for it.

She adds the intro and outro music (from Pixabay) and goes through the episode one more time to tweak audio levels and do a general clean up.

Then, she edits all of the bloopers together (side note: this is my favorite part of every episode). Most episodes have 5+ minutes of unedited bloopers, but she grabs only the best ones and stitches them together.

After that's all done, Sangeeta exports the final cut and uploads it to Buzzsprout.

Buzzsprout

Buzzsprout is where we host the podcast episodes. It pushes new episodes to all of the podcast aggregators, stores the podcasts, provides a handy embeddable player, and podcast analytics. Personally, I am not sure how accurate the podcast analytics are, but it is nice to get a sense if people are listening to the episodes.

Coltrane

We used the built-in Buzzspout hosted website for a little while, but eventually wanted more control over the styles and content. I grabbed all of the HTML and CSS from the hosted site and used my own mini web framework, Coltrane, to build a static site. We have a few ideas about potential further enhancements for the site in the future, but for now it's good enough for our purposes.

Process

For most of our episodes it's taken around a month to decide what to talk about, record, and edit. That's a long time! However, we only work on it nights and weekends because we have day jobs and other life priorities also tend to get in the way!

For some episodes we have written out a basic script for what we wanted to talk about. For others, we had an outline, but it was recorded more "off the cuff". I don't think we have nailed down a perfect process yet, but we are still working through it. I think we'll also get better at talking "on-mic" over time, but like with most things practice makes ~~perfect~~ better.

Publishing

After we upload the new episode to Buzzsprout, we write custom show notes with links to everything we talked about. The new episode will automatically show up on the website once it's published, but we also write a post for Twitter and Mastodon to notify people on those platforms.

Conclusion

That's our current process to record the Django Brew podcast! I'm sure we'll learn new techniques and the process will change over time, but we've been pleasantly surprised by the community engagement and we look forward to creating more podcasts in the future!

If you are interested in Django at all, please check out Django Brew and let us know what you think. Or just listen to our bloopers and see how often we mess up while recording. 😉

Thanks to Sangeeta Jadoonanan for reading the first draft and giving some helpful feedback. And also being my podcast co-host.

Photo by Austin Distel on Unsplash

Django Roadmap 2024

Adam Hill — Sun, 21 Jan 2024 16:39:36 +0000

I saw Sarah's request for "what people want for Django" which included a link to Paolo's post and blog article with details. I'm glad this was brought up by @thibaudcolas in this forum post.

Turns out I have a few thoughts. 😅 Caveat: this is mostly "pie in the sky" sort of thoughts and I'm conveniently ignoring what would actually need to happen to make any of these ideas happen.

This is also not meant to degrade any of the excellent work that has made Django what it is today. I ❤️ Django, use it for all of my projects, and just want the best for it so it continues to thrive long-term.

One side note: I wonder if the annual Django survey could be leveraged for potential roadmap ideas? Something like: collect ideas, core devs whittle down the ideas to the top 20, and then the community votes. It wouldn't be binding or anything, but it might give insight on ideas from multiple different perspectives?

In true roadmap fashion, I'm also going to try to include goals or metrics for the high-level things I'm thinking about.

Marketing

As I mentioned in my reply to Sarah, I'm not sure if it's a "roadmap item", but in my opinion Django needs better marketing more than it needs new features. So, I'm going to focus on that first. Don't worry I also have my own pet features I would like to see in Django core. 😉

Metrics

Number of downloads goes up
Developer use goes up (based on StackOverflow developer survey maybe?)

Homepage

I'm going to ignore all of the JavaScript web frameworks and I'm mostly going to focus on Ruby on Rails and Laravel because I think they are closest to the current use-case of Django. They share the same downside of needing to know an additional language after JavaScript, are mostly server-side rendered, and database-centric.

The Django headline is "Django makes it easier to build better web apps more quickly and with less code." which isn't bad per se, but doesn't hold a candle to the punchier Rails H1 "Compress the complexity of modern web apps."
Both RoR and Laravel prominently showcase the companies that use them -- Django makes no mention of the huge companies that are built on top of it
Rails has a 35 minute (!) video on the homepage which seems like overkill, but people do love seeing how something works, as opposed to just a bunch of words
both talk about the features included in the framework: database modeling, authentication, etc.; Django has all these things (and more!)
both talk about the number of contributors and community; Laravel even has user testimonials (similar to a SaaS product)
both prominently say they are a "full-stack" framework
both mention how to build SPA-like applications (Hotwire and Laravel, respectively)
both show actual code to give people a sense of how "beautiful" it is

Overall both of the Rails and Laravel homepages "feel" modern, fresh, and exciting. Django should take some inspiration and make the framework feel fresh and inviting.

Documentation

Django's documentation is best in class in my opinion -- it is vast and covers everything I have ever needed to find. I think an aesthetic refresh of the docs site would be useful, but I don't have any specific tweaks, although Paolo mentioned a few things in his article.

However, when I search on Google or Kagi djangoproject.com doesn't always show up first in the results. I wonder if there are some SEO tweaks so that search results consistently point to djangoproject.com?

Evangelists

Django needs a constant drumbeat of people talking about it, saying how great it is, and advocating for it. Django needs companies that utilize it to shout about how it's helping their business. In short, Django needs evangelists. Lots of tech decisions are made word of mouth.

Modernize

Generally, look at the current most-used packages for Django and incorporate them into core. Again, I'm totally ignoring why this is a bad idea and how it creates extra maintenance burden, reducing how often fixes can be released, etc. But, in general if you say that a framework is "batteries included", but then 80% of new installs add the same 5 packages, then... maybe they should just be included by default? Solve the 80/20!

Another approach would be to have "blessed" framework configurations ala Laravel Starter Kits to reduce the amount of code that would go into core.

Metrics

Reduce the number of additional packages needed for different Django use-cases (i.e. what is needed for a web app, what is needed for a backend API, etc)?

Serve static assets

Just include whitenoise.

Asset management

Almost every site will need to use and bundle JavaScript and CSS, so it should be included. I use django-compressor, but whatever... just pick one.

Create APIs

A huge use case for Django currently is as an API backend, so let's make it easier. Bundling DRF maybe is overkill (maybe not?), but the closer to a frictionless API the better. DRF is probably closer to current Django, but I personally like what django-ninja is doing here, but it's probably because of my affinity for FastAPI/Pydantic.

Background tasks

I tend to use django-q2, but again I don't really care. I just want something supported and straight-forward to use.

Conclusion

I am sure there are features that Django should add, but as it is, it solves huge use-cases for the majority of web applications. But, people don’t know all of its features or they have a feeling it’s “outdated”. With better marketing and a few core additions Django would be used (and loved) by even more developers.

Python Package Manager Comparison 📦

Adam Hill — Mon, 13 Nov 2023 13:52:59 +0000

This article started as a random thought and then this post on Mastodon.

If you haven't read Hypermodern Python from 2020, it is a good companion to this article and apparently will be a released as a book in 2024.

Introduction

It feels like Python packaging has changed pretty substantially over the past few years. When I started creating Python packages the preferred approach was with setup.py and (what felt like) a myriad of other random files that were needed like MANIFEST.in, setup.cfg, etc. I basically found a guide once and then copied and pasted files around once I seemed to get something working.

I was an early adopter of pipenv with the primary appeal being lock files which promised consistent deployments. My early excitement got me burned multiple times and I looked around some more.

I remember Poetry being the cool, new upstart at the time. It completely eschewed setup.py, requirements.txt, and other disparate files -- it had one pyproject.toml file to configure a project, developer-friendly tooling to add dependencies, a lock file for consistent deployments, and an algorithm to make sure that a tree of dependencies was all compatible with each other (which was not possible with that version of pip at that time).

I was in love. There were definite rough patches and there were a few bugs that caught me here or there, but overall Poetry has been my go-to for a while.

However, in the past few years, Python packaging seems to be going through a new era of innovation. pip released a dependency resolver in 2020 that now complains when dependencies conflict. Also in 2020, PEP 621 and PEP 631 standardized pyproject.toml as the new normal for Python packages instead of setup.py. PEP 517 and PEP 660 created standards for Python build systems.

Based on those PEPs, Poetry isn't the only forward-thinking package manager anymore. pipenv is still around (and I presume more stable at this point!), but Hatch, PDM, and Rye all promise a pleasant developer experience when creating Python packages.

Benefits

Most of these package managers are of the "all in one" mentality and provide similar benefits: adding dependencies from the command-line, lock files, building, and publishing packages. If you want to do this manually Packaging Python Projects lays out the steps necessary. Reducing the number of tools required to create new Python packages means there is only one place to look for documentation and keep up to date.

Poetry

My first modern Python package manager. I would say the documentation is still the best available, although it might be too "designed" for some. It does a lot -- maybe too much? -- but, in my opinion, it pioneered a lot of features that are now expected in other Python package managers. I get the feeling it sometimes pushes forward without waiting for official PEPs, although I think that has changed over the past few years.

Occasionally lock files are not backwards-compatible which can be challenging when working in a team -- everyone needs to update their Poetry install at the same time.

Another annoying feature lacking in Poetry that is available in every other option is the ability to define "scripts". For example, poetry run dev as an alias for poetry run manage.py runserver 0:8000. That is not available in standard Poetry, although I use poethepoet (a Poetry plugin) to provide that functionality.

Hatch

Hatch never deviates from the Python PEP standards and brings a few innovative features to the table, including being able to group dependencies and scripts into custom environments. The hatch new [project] command is surprisingly opinionated and has settings for ruff (my new favorite Python tool), pytest, and coverage. I'm here for all of the tool choices, but I would be lying if I did not say it was a little surprising.

Under the PyPA GitHub organization which probably gives it more of a sheen of officialdom than other tools.

PDM

PDM for some reason feels like the sleeper option compared to the rest. I have not used it too much other than to set up a new project and play around with it a little bit. Dan Sloan chimed in on Mastodon pointed out that PDM follows all of the current PEP standards, has good support for cross-platform lock files, and also includes a useful pdm export command to output a standard requirements.txt file.

Rye

rye seems to have had a quick and meteoric rise. It was developed by the creator of Flask, Armin Ronacher, based on his opinionated approach to building Python packages. It reminds me of black a little bit in which a respected developer made an opinionated tool and it caught fire in the community. Rye also provides an overview of its philosophy here.

Rye has multiple cautions in the docs that it is experimental and not production-ready, although I did not see any glaring issues with my simple testing. Rye is a little different than the other options because it mostly consolidates a set of other tools (pip, pip-tools, etc.) into a particular workflow. Another distinguishing factor is that it handles multiple installing Python versions directly -- Poetry recommends using pyenv to deal with the same use case.

GitHub Stats

I do not believe GitHub stats are especially useful, but the number of stars do give some indication of the community engagement with a particular tool (current as of 2023-11-12).

Conclusions and takeaways

Personally I have multiple libraries using setup.py and Poetry, one using Hatch, and now one using Rye. The next one might use PDM. 😎 I like trying new tools to see how they work and to improve my workflow.

One could look at all of the options for Python packaging and be frustrated by the paradox of choice. I understand that viewpoint, but I also appreciate that all of these tools are making different trade-offs and pushing the state of the art forward in their own ways. Maybe at some point in the future there will be one "approved" Python package manager ala NPM or Cargo, but I am doubtful. There are pros and cons with multiple options, but I tend to think it's useful overall.

I personally have not used each package manager extensively. But, I have started a new project from scratch with each, did some simple tasks, and read through all of the documentation. Each project is relatively mature, so you can just choose any of the options and you would be fine. Standardizing on pyproject.toml means that the conversion from one package manager to another is usually just updating some TOML. So, choose the package manager that speaks to you (or try them all!) and improve your developer experience henceforth. 🛠️

Photo by Claudio Schwarz on Unsplash

Best tools for Mastodon in 2023

Adam Hill — Sun, 19 Mar 2023 16:34:31 +0000

Here are the best tools for Mastodon I have found and personally used.

Finding Servers

fedi.garden: Discovering nice servers on Mastodon and the fediverse. Made by @FediGarden.
instances.social: A guided wizard that helps pick the right Mastodon instance for you. Made by @TheKinrar.

Following Accounts

Followgraph: Find awesome people on Mastodon by looking up who you follow on and surfacing who they follow. It expands your connection graph based on who you are already connected to. Made by @gabipurcaru.

Timeline Summaries

fediview: Aggregate the most popular posts from your timelines to get a personalized view of posts. Made by @adamghill.
Feedseer: See the most popular links that have appeared in your Mastodon feed over the past day.

Web Clients

Because Mastodon has a robust API anyone can create a different interface for browsing your network.

Elk: A web-only interface for Mastodon that feels very similar to Twitter.
tooty: An experimental multi-account Mastodon web client that is all client-side (no server needed!).
Phanpy: A minimalist, opinionated Mastodon web client. Made by @cheeaun.
Cuckoo: A GooglePlus-Like third-party web client for mastodon.
feditrends: Aggregates what is trending across the fediverse.
Pinafore: An alternative web client for Mastodon, focused on speed and simplicity. Made by @nolan, but unmaintained.

Desktop Clients

Whalebird: Slack-like UI for browsing Mastodon.
Sengi: A multi-account Mastodon desktop client.
Elk Native: Still alpha, but a super slick desktop client from the same folks that build the web Elk client.

Other Networks

These social networks bring something unique to your social network by focusing on a particular niche. They all integrate with Mastodon because they all use the same ActivityPub protocol.

BookWyrm: A social network for tracking reading, talking about books, writing reviews, and discovering what to read next. Made by @tripofmice.
Pixeled: A network to explore and share beautiful photos and videos.
PeerTube: PeerTube is a tool for sharing online videos.

Technical Tools

For a longer list of (more technical) tools for Mastodon I have found this awesome-mastodon fork by hueyy to be the most up-to-date.

Photo by Battenhall on Unsplash

Marketing for Developers

Adam Hill — Sun, 26 Feb 2023 17:54:41 +0000

I can sometimes view the world in idealistic ways. I want to believe in meritocracy and that marketing is unnecessary, but even for developer tools, marketing is necessary for people to find and use your code. Writing the code and clicking the Public radio button when creating the repo in GitHub is just the first step.

Here is a list of other steps to make sure that others discover your code, use it, and contribute back. Not every suggestion is necessary and they are roughly sorted from easiest to hardest to implement.

I mostly know the Django ecosystem, so that's what I focused on, but I'm sure other programming languages have analogous approaches.

Make the repo public

You made a thing! That's awesome! Make sure it's public, otherwise your code will just sit around being sad and lonely.

Give your repo a succinct, but descriptive tagline so people know what it is. Then add tags to the repo so your repo can be found easier when searching in GitHub.

Create a `README.md`

First impressions matter for code just like everything else. Only the most die-hard developer will delve through your code without some basic information. The least you can do is create a README.md in the root directory and include things like:

a longer description of what your library does
a list of features
installation instructions

If you really want a stellar README.md take a look at some of the examples in awesome-readme for inspiration!

Submit your library

There are a few websites where you can easily submit your library for others to find.

Django Packages: the O.G. site to find libraries for Django.
libhunt: a list of Python open-source projects; submitting here will sometimes get you included in the Awesome Python newsletter.
awesome-django: a curated list of awesome Django projects; submit your own by making a PR.

GitHub Discussions

Creating posts in GitHub Discussions are an easy to way to engage with the community. Personally, I have found it's hard to generate a lot engagement in here, but maybe with bigger projects or a more deliberate strategy it could be a valuable tool.

One thing I have experimented with in some repositories is disabling the creation of GitHub Issues and using Discussions for that instead. One thing I like about this approach is it allows users to engage in a way that feels less aggressive. A user is not creating a problem for you to solve, they are creating a topic to talk through.

Write blog posts

Writing a blog posts is definitely marketing! Write about why you created your library, the challenges you overcome, lessons you learned, or tutorials for how to use the library.

dev.to and Medium are good places to post technical articles which have some built-in search and promotion capabilities so others can find your writing.

Social media

Twitter and Mastodon have technical audiences, but you will get more traction once you have more followers. Be generally helpful to the community and learn to use these tools that isn't against the grain. Also, use hashtags in Mastodon when posting to increase the odds that others will find it.

Some sub-reddits also have technical audiences, but reddit seems to be less tolerant of self-promotion. Again, the more active and helpful in these communities you are, the more tolerant they will be. I have also mentioned my tool at the end of an answer for relevant questions -- but always provide help first.

The official Django Forums has a specific Show & Tell section. I have used it before, but it doesn't seem to be as active as the Django sub-reddit in my opinion.

GitHub is also technically a "social platform" so other developers will follow you there. It's much more passive, though so you cannot directly message them. They will see notifications when you do certain actions. You can send updates to GitHub Sponsors via email if that's something you end up doing.

I've never set up an email newsletter, but that would be another way to "own" the relationship with users without relying on a third-party like Twitter.

In general, don't be overbearing and do not be spammy and it will usually be ok.

Create a documentation site

After you have created a rad README.md you might notice it gets pretty long with numerous sections. This will be especially true for any library with lots of functionality. Breaking up the README.md into multiple pages can help with organizing the content.

Sphinx is the go-to tool for documentation. It took me a while to understand how to use Sphinx, but I now have a decent workflow with MyST which allows me to write all the docs in markdown. My sphinx-markdown-docs repo shows an example of what I do.

ReadTheDocs is a free way to host your open-source documentation.

diataxis is a systematic framework for technical documentation authoring which I keep meaning to read through more carefully and implement. It might be useful as you build out your own documentation to keep it in mind.

Create screencasts

Some people learn better visually and some libraries greatly benefit from being shown. Animated gifs or short mov files can be especially useful for simple interactions. I use Kap (free) to create these simpler screenshares.

For longer screencasts I have used Screenflick (currently $35 one-time fee). It allows you to only capture a portion of the screen or a whole application, record audio, includes some simple editing capabilities, etc. There are some free options (e.g. OBS), but I found them difficult to setup and deal with. Screenflick was easy to use and totally worth the one-time fee.

Personally, creating a compelling screencast takes me a long time: deciding what to showcase, creating the sample code, writing a (loose) script. With practice I'm sure this goes faster, or if you are used to podcasting or streaming already.

Go on podcasts

Once you've hit influencer status 🫣 you might get invited to go on a podcast to talk about your library. Podcasts are great to "get the word out" and "brand awareness", however most people are listening to podcasts in their car, doing the dishes, etc. Make it compelling and provide easy calls to action for people to re-find you or the library once they get back to a computer.

Give a conference talk

Most conferences will not accept a long talk strictly about your library, however, making a talk about a general problem or a specific technical solution that is applicable is always welcome. Mentioning your library as part of the conference talk will be ok. Some talks can just be about being seen as a go-to resource in the community, as well.

Creating a conference talk is hard. My one and only real conference talk took 40-60 hours to create and record. Not for the faint of heart, but it is a good experience to do at least once in my opinion.

Shorter "lightning" or "attendance" talks are another approach. They are usually in the 5-15 minute range so are much more focused, just stressful, and talking about a specific tool seems ok in this context.

In summary

Creating a repository that others know about and will use is way more involved than just writing code and it requires some marketing from the developer. Hopefully this provided some ideas about how to promote your awesome library and help people find what you make!

Photo by Clément Hélardot on Unsplash

Musings on Twitter and replacements for serendipity

Adam Hill — Sun, 06 Nov 2022 12:19:10 +0000

Navel gazing

I joined Twitter in February 2009 and I'm not exactly sure why. I do remember the fail whales and the early tweeting of what people ate for lunch, though. Even though I have accounts on other social media platforms, I rarely engage with them -- over the years the tech community seemed to coalesce around Twitter and so did I. It became a self-reinforcing cycle, especially because my job (and my hobby) is so centered around words on a screen.

For a long time I only read tweets, but rarely created my own. I could "listen" to personalities that I have never met in person "talk out loud" about topics I was interested in. Brilliant thinkers like Camille Fournier, Charity Majors or Adam Johnson didn't need to create a conference talk or a whole article. At its best Twitter allowed me to read what smart people were thinking about and surface other interesting people.

This created a bubble (in the best sense). I got information from people I trusted (and they surfaced information they trusted). But, there was also a sense of discovery and newness. And I had the tools to silence most tweets that invaded that pleasant experience by aggressively muting, blocking, and unfollowing those who disrupted my bubble.

Over time I built up a few hundred followers of my own once I started tweeting primarily about tech topics. "Niche-ing down" to what I was most interested in, Python and Django, allowed others who were also interested in those topics to find me and follow me. They knew what to expect and I rarely strayed from that path. Writing an entire article can feel self-indulgent (present article very much included), whereas a tweet could be posted on a whim. I had nice interactions with people who "knew" me and with so few followers there was little incentive for bots or trolls to join in. Twitter was a low friction way for people to reach out to me with questions or comments about what I was putting out into the "public square".

Musings on the business of social media

I liked Twitter so much I was one of the suckers who paid $3/month for Twitter Blue. I didn't use any of the features (and the ad-free articles never seemed to work -- R.I.P. Scroll), but I wanted to support the service and do what little I could to keep it around. Honestly, I probably would have paid more.

I realize I'm idealistic, but I viewed Twitter as a utility -- it was enabling information to be spread in a new way. Trying to balance the common good with the requirements of a VC-backed, stock market-fueled company seems incredibly challenging. Wikipedia is extraordinarily successful in this endeavor and its non-profit status seems to be a key factor. The only business model for social media platforms is to create an ad platform to monetize eyeballs or to sell user's personal data.

The common good and the requirements of capitalism are in direct opposition. Companies chasing engagement metrics and ad revenue creates incentives where whoever is the most incendiary wins. That isn't a platform that I personally want to engage with or support.

Now what?

Having a public square where anyone can type into the void and random people can read it created serendipity and chance encounters which would not have happened without Twitter. I don't think I can actually replace it.

However, for the discovery of new information I'm going to lean even harder on a few things that I already use now: email newsletters and RSS. These decidedly old-school technologies are more focused on longer-form content and that's... probably good for my brain anyway? Preventing the quick-hit endorphin rush of endless scrolling has to be a net societal positive.

I already subscribe to a few newsletters, but I'm going to create a new email address (thank you email aliases with Fastmail) which will be dedicated to them. That way I will have a dedicated place they will "live" and they aren't interspersed with personal emails.

For RSS, I'm doubling down on NetNewsWire and trying to find more diverse feeds to follow. iCloud integration across my laptops and iPhone keeps what I've read synced across all devices.

Reddit feels like a completely different model. The niches are there with sub-reddits, but it's less personality-focused which has its pros and cons. It feels stuck in the forums of a by-gone age, but I'll probably be spending more time there than previously.

I have also set up a Mastodon account, but I've been... underwhelmed so far. It isn't fair to compare a brand new social media account to 10+ years of accumulated interactions with another platform. I know I need to follow more people to make it worthwhile, but in the short term having less social media in my life doesn't seem all that bad.

Maybe eventually I'll swallow my disappointment with Twitter's apparent new direction. Or maybe Twitter will stumble onto a different business model. I'm not holding my breath for Twitter to change, but I'm hopeful that something else arises that provides some of the same benefits and more closely aligns with my perspectives.

Why I built another static site generator: A love story

Adam Hill — Sun, 20 Mar 2022 03:51:16 +0000

Does the world need another static site generator? Honestly... no. But, does it deserve another one? YES!

It all started from this tweet:

I have used a few static site generators over the years including Hugo, Jekyll, and Pelican to host my personal blog. And I have experimented with a few others including Lektor and Gatsby.

All static site generators do basically the same thing, but they each have their own idiosyncrasies. Since I have a lot of experience with Django (and a predilection to want to improve the Django ecosystem) when I saw the tweet above I thought, "why wouldn't you use Django for this?"

The reasons to use Django:

it's already solved a lot of tablestake features:
- creating RSS feeds
- sitemap.xml generation
- auto-reloading dev server
a nice CLI management command system
Django template language with lots of built-in template tags
there is a huge ecosystem of other functionality

The reasons not to use Django:

it's "big" and "heavyweight"
it's over-complicated

No programming language or framework is perfect, but the one I have the most experience with is Django. I love most of the Django, but I wanted to see if I could build an opinionated framework on top that hid all of the complexities of a normal Django site (e.g. serving static assets, complicated settings files, setting up URL routes, etc).

I wanted to make Django even more lovable by creating a simplified content framework that served markdown files in an intuitive way. So, coltrane was born.

First, I used django-microframework as inspiration for a simple app.py that could be used instead of the potentially overwhelming files Django normally uses for a site. Then, I added in automatic reading of .env files to override Django settings that shouldn't be committed. I used markdown2 to automatically render markdown files into HTML. And built a way to load data from JSON into templates to be used as variables (since a database is not available when generating a static site).

Then finally, I built a management command that output the whole site as static HTML. The result is "yet another" static site generator, but a key differentiator is that it tries to be as simple as possible with sane defaults. There are only three commands:

poetry run coltrane create to create a new static site
poetry run coltrane play to start up a development server
poetry run coltrane record to output a static site

After the site is created, just start adding markdown files into the content directory and they will be rendered as HTML using filename as the URL slug.

coltrane won't ever solve every use-case, but right now it solves two specifically for me:

It generates the static site of https://alldjango.com (building automatically on every git push by render.com).
It is used to serve https://devmarks.io/articles, as a Django app in an existing Django site

So, maybe the world doesn't need another static site generator, but hopefully coltrane is a fresh take on static site generators.

I would love for you to try it out for your next project and star the coltrane repo if it looks useful!