I am fortunate to live near several forested parks with trails through the trees. For whatever reason, the trees in coastal Virginia are absolutely full of hollows. I find holes of all sizes and depths in trunks and branches.

These hollows are usually the result of decay resulting from past damage such as fire, a large branch breaking, water pooling on the bark, or woodpeckers pecking holes. Eventually, the tree may grow "woundwood", somewhat similar to scar tissue in humans. What is fascinating is that tree hollows can be a big boon to the critters and bugs in the ecosystem. They provide shelter from predators. They provide a place for fungi to thrive. They provide nice, cool, dark homes to vertebrates and invertebrates.

But, while that's all lovely, why do I love taking time for something weird like photographing tree hollows?

It's something creepy!

When I think of children's books and movies I loved the most, they include:

• The Berenstain Bears and the Spooky Old Tree

• The Funny Little Woman

• The Goonies

• All those creepy 70s and 80s kids movies that everyone says were traumatizing

From middle school onward I devoured anything I could get my hands on from R. L. Stine, Bradbury, Poe, and Lovecraft. Anything about the unknown or unknowable, whether ancient monstrous gods from the stars or creepy worlds hidden underground. I had a Norwegian great-aunt who infected me with a love for troll mythology (the tricky, frightening, oft-hidden mythological creature, not the singing, frizzy-haired monstrosity). And these days I particularly enjoy media and photography about the liminal or horrifically unexplained (e.g.: “This hole was made for me”).

To be clear I have never particularly enjoyed most of the "horror" genre - jump scares, ghosts, and demonic possessions don't really do much for me - but I loved (and still love) the hidden, mysterious, and the creepy.

As an adult in 2025, it sometimes feels like there is little left in the world that is mysterious, creepy, and exciting (or affordable) to explore. But it’s not true! There are hidden nooks and weird, gross, wonderful things all around us. But it can be hard to notice them. Isn’t that the biggest indictment of being a typical adult today!

Tree hollows are typically dark and creepy, and there is no telling what they might contain on a given day. Sometimes it’s a spider, a frog, a bird, or a mass of millipedes. Sometimes it’s just dark, soupy water or wood dust. Sometimes it’s a world of mushrooms, hidden in the dark. And what’s living there today might not be what’s living there tomorrow.

It's something fun to do with my pup

I made it a goal this year to do a lot more (and longer) walks and hikes with my pup, Lady Duchess. Lady is a Siberian Husky, and with that comes energy. Lots of energy!

While I love our walks, I found myself sometimes a bit bored when she’s having a particularly “sniffy” day. On these occasions we don’t get far very fast. So one day I was looking around me while waiting for her to finish sniffing, and I got curious about the hole in a nearby tree. And now I have thousands of photos (mostly really bad ones) of these holes and their contents.

Lady and I have developed a solid partnership. If I am patient with her about taking time to sniff, she is (to an extent) patient with me taking photos. Sometimes she gets frustrated or a bit confused about why I am hovering over a hole in a tree with no interesting smells, but overall we have a solid agreement about sharing our time together on our walks working on very different interests.

It's something that feels "real"

(Note: this entire post is self-written. Yep, an AI-free blog post in 2025!)

In America, “real” can feel foreign, uncomfortable, and absurd. We face the ‘rock’ of generative AI making it tiring and annoying to distinguish real from slop and the ‘hard place’ of wanting to escape the monstrous shifts, cuts, and intentional decay currently altering our Government.

While it might not be for everyone, taking photos of the weird, dark contents of tree hollows requires manual effort and time, being offline, traversing beautiful scenes in nature, some physical fitness, and spending time with someone I love dearly.

• It is challenging: There may be only moments to get a snap or two. I’m out varying in weather conditions. The photos are often taken in very low light and very close-up.

• It is fleeting: I don’t record where I took a given picture, and that has become a conscious decision. I like something about the chance and spontaneity of a great shot. I usually do not have the time to review the photos I take until after we return home from a walk, so it is a delight to find that I captured something great.

Doing something real with a portion of my time - something away from the computer, not emulated by AI, and not pushed by influencers or pundits - has been amazing for my well-being. I feel more grounded in our world because I take time to explore the wonders that remain around me.

It's something that (initially) cost me nothing extra

All of my photos for the past couple years have been taken with the lenses on my Samsung Galaxy 24 Ultra. There are some fantastic cameras on these phones.

I recently purchased a Fujifilm X-T5 **. This camera uses an APS-C sensor which is much smaller than a full-frame sensor, but much larger than the sensors on my phone. This means I will be able to capture more detail in low-light conditions than I can currently with my phone. Honestly it's more camera than I will probably ever be skilled enough to be worthy of, but it is a treat to use!

(** I should also note that buying a camera is a dangerous gateway drug to trying other types of photography. I’ve been trying my hand lately at street photography, and while I get no more than one okay shot for every hundred shutter presses, it is a lot of fun - maybe again because it involved capturing fleeting moments that you may never see again)

Now, go photograph tree hollows! Or find your thing!

Be on the lookout for the mysterious in your environment - whether in nature or an urban landscape. Find the unusual. Experience the lovely, creepy, or terrifying.

Most of all, find something “real”. Find something that allows you to spend time with friends or family. Find something to do that actually makes you happy, rather than just existing, being pulled around by politics, or “filling time”.

I can’t say whether photographing tree hollows is for you, but I hope you’ll find something as fun and fulfilling and Fey for you as this has been for me!

A few more photos for your enjoyment:

I don't script my talks, but I typically write a blog article that I use as a reference for my talk.

I love the idea - but I already gave this talk at DjangoCon US 2024 - so now I'm doing the reverse.

We all deal with challenging problems that sometimes seem impossible to solve, whether it's a Django error that makes no sense, an electronic device that won't power on, or a network connection that keeps dropping packets. In those moments, the difference between frustration and success often comes down to the way we troubleshoot the issue.

I've spent years programming, maintaining radar systems, and designing electronics, and if there's one truth I've discovered, it's that troubleshooting isn't just a skill - it's a mindset. A lifestyle even!

I'm the main programmer and managing director of Watervize, where we build data systems for irrigation districts. When I'm not working on the business, I serve as a Radar Maintenance Officer in the Marine Corps, supervising a team that keeps complex radar systems running. Between these roles, my background in electronics design, and my experience with Django development over the past six years, I've had plenty of opportunities to troubleshoot in various fields - from mechanical and power systems to digital electronics, RF systems, embedded software, and web applications.

I won't make you an expert troubleshooter in the time it takes to read this article. You may even already be an excellent troubleshooter. My goal is to give beginners some new tools for their toolkit, and to help experienced folks think through aspects of troubleshooting they may have forgotten, or may never have actually considered. At the end of the day, troubleshooting is a skill, and like any skill, the more you practice it and the better the tools you have, the more effective you'll become at it.

The Troubleshooting Mindset

Before we dive into practical techniques, let's clarify some terminology to add context for the discussion:

Problem solving is a broad term that covers any approach to resolving a problem or challenge. This could be a technical issue, a conceptual puzzle, or even a personal dilemma.

Troubleshooting is a subset of problem solving. It follows a specific pattern: recognizing that there's a problem, locating the cause of that problem, and then resolving it. It typically applies to tangible systems like hardware, software, or mechanical equipment.

Debugging is essentially troubleshooting specific to software and programming. When you're hunting down an elusive bug in your Django app, you're debugging.

A Cautionary Tale

Let me tell you about a bad troubleshooting experience I witnessed years ago. I was responsible for evaluating a team who were setting up a communication site in the desert. Their one goal was to establish communication to another location on an airfield not far away.

When I arrived, I discovered they had erected not one, not two, but four different antennas. They only needed to establish a single link, but had assembled four very different types of antennas - a loop antenna, a sloping-V, and others.

When I asked what was happening, they explained, "The first one we set up didn't work, so we moved on to set up a second one..." and so on. Looking at the antennas, I noticed obvious issues - incorrect wire lengths, missing grounding, and other fundamental problems that could have been identified with basic troubleshooting.

I asked the person in charge, "What are you using to build these antennas? Where are your manuals?" He looked at me with a completely deadpan face and replied, "Sir, I don't need manuals. I rely on experience!"

🤦

This is a classic example of what's called "shotgun troubleshooting" or "shotgun debugging." If you're familiar with marksmanship, you know a shotgun tends to scatter pellets widely. Similarly, this approach involves making changes randomly without a systematic approach, hoping something will 'hit the target' and solve the issue. It's inefficient and often ineffective.

With the right tools, techniques, and indicators, there's always a systematic way to troubleshoot a problem - whether it's in the Django web framework or any other field.

Troubleshooting is a Universal Skill

We all start learning troubleshooting at an early age. Consider the children's book "Curious George on a bike" - when George bends his bicycle wheel after crashing into a rock, he identifies the problem (the bent wheel), and devises a solution - riding a wheelie! This is the sort of basic troubleshooting we all learn as children.

Troubleshooting is everywhere in our lives:

• Medicine: Doctors use symptoms, tests, and medical knowledge to diagnose and treat health problems

• Aviation: Pilots and maintenance crews must quickly identify and resolve problems to ensure safety

• Military: Technical specialists maintain complex equipment in challenging environments

• Tech: Developers and engineers trace issues through multiple layers of software, hardware, and networks

The most successful troubleshooters share two essential qualities: persistence and curiosity. Some problems are easy to solve, others not so much. If you give up easily or aren't curious enough to explore different paths, you'll struggle to resolve complex issues.

Indicators and Resources

When it comes to the practical side of troubleshooting, the first key element is understanding what indicators - anything that can provide information about the context of the problem you're trying to solve - are available.

As Abraham Maslow once said:

"If your only tool is a hammer, then every problem looks like a nail." If you're using the same indicators for all your problems, or just sticking with the basics, you'll have limited context when tackling deeper issues.

Types of Indicators

We can categorize indicators in several ways:

1. Built-ins vs. Add-ons: Systems come with built-in indicators, and we can often add more to gain additional insights.

2. Alerts vs. Status: Some indicators proactively tell you when something's wrong, while others require you to check their current state.

3. Qualitative vs. Quantitative: Some indicators give you a general sense that something is good or bad, while others provide specific measurable values.

4. Affirmative vs. Negative: Some indicators tell you when something is working fine, others when something is wrong.

Indicators in Everyday Life

This concept applies to everything around us. Take a car, for example:

• Built-in: Dashboard lights, gauges, warning sounds

• Add-ons: OBD scanners, tire pressure gauges, diagnostic tools

Maybe an odd example, but to show that it applies to just about anything: houseplants have indicators:

• Built-in: Leaf color, wilting, soil moisture

• Add-ons: Moisture meters, temperature sensors

Even my dog, Lady Duchess, has her indicators:

• Built-in: Her level of cuddliness (if she's unusually cuddly, something's wrong - she usually wants her space), her rate of treat consumption (if she's not eagerly taking treats, something's definitely off)

• Add-ons: Her GPS collar that tracks steps, rest, and other activities

The point is, anything we might need to troubleshoot has built-in indicators we can observe, and often we can add indicators that provide additional context.

Django Indicators and Tools

The same principles about indicators apply perfectly to troubleshooting Django applications. Let's look at what's available to us as Django developers.

Built-in Django Indicators

Django comes with several powerful troubleshooting tools right out of the box:

Template Error Pages: When DEBUG=True in your settings, Django displays detailed error pages that show the exact error message, what Django tried to do, and suggestions for fixing the issue. If you're using the Django-Extensions package, you can also use Werkzeug, which gives you an interactive debugging console right in the browser.

# settings.py
DEBUG = True  # Enables detailed error pages during development

Error Reporting Via Email: When DEBUG=False on your production or staging systems, Django can email you the same information that would appear on the error page:

# settings.py
DEBUG = False
ADMINS = [
    ("Mary", "mary@example.com"),
    ("John", "john@example.com"),
]

The Checks Framework: This powerful but often overlooked tool runs a set of static checks when you start your server to verify that your configuration is correct. It examines your database setup, models, security settings, templates, URLs, and more:

python manage.py check

The checks framework will tell you if something is an error, a warning, or just informational.

It's also extensible - you can add custom checks for your specific application requirements. Here's a quick example of adding a custom check:

# yourapp/checks.py
from django.core.checks import register, Warning

@register()
def example_check(app_configs, **kwargs):
    errors = []
    # Check something important for your app
    if some_condition_is_not_met:
        errors.append(
            Warning(
                'An important setting is misconfigured',
                hint='Try setting IMPORTANT_SETTING=True in settings.py',
                id='yourapp.W001',
            )
        )
    return errors

(Also, take a look at the django-extra-checks package for more helpful additions to the checks framework)

Console and Logging: Django's shell and logging system provide invaluable context about what's happening in your application. You can increase the verbosity of most Django management commands with the -v flag:

python manage.py migrate -v 3  # Show detailed migration information

Add-on Tools for Django

When the built-in tools aren't enough, there's an entire ecosystem of add-on packages that can enhance your troubleshooting:

Django Debug Toolbar: This oft-recommended tool adds panels to your pages showing detailed information about execution time, database queries, template rendering, cache usage, and more. It's configurable and extensible too.

Performance Profilers: Tools like Django Silk can help identify performance bottlenecks by showing you exactly which views and database queries are slowing down your application.

Error Tracking and Performance Monitoring: Services like Sentry, Rollbar, New Relic, and others provide detailed error reporting and performance metrics. They capture the full traceback, request information, user context, performance details, and more. They can alert you when errors occur and help you prioritize issues based on frequency and impact.

For example, with Sentry integrated, you'll receive detailed error reports including:

• The exact error message

• Context around the event

• The complete stack trace

• Database and cache information

• User information (if available)

• Tags you can add to organize errors

Health Checks: Packages like django-health-check or django-watchman can monitor the health of your application components:

# urls.py
urlpatterns = [
    path('health/', include('health_check.urls')),
]

This gives you a quick dashboard showing the status of your database connections, Celery tasks, Redis, and other services your application depends on.

The package also simplifies the process of adding custom health checks.

Custom Admin Panels: You can also add custom panels to your project’s admin to monitor specific aspects of your application. For example, I once had intermittent issues with Celery processing tasks, so I created a simple admin panel that showed task processing rates compared to historical averages:

@admin.register(CeleryTaskStats)
class CeleryTaskStatsAdmin(admin.ModelAdmin):
    change_list_template = 'admin/celery_task_stats_change_list.html'

    def changelist_view(self, request, extra_context=None):
        extra_context = extra_context or {}

        # Get stats for current hour, day, week
        current_hour = get_task_count(hours=1)
        current_day = get_task_count(hours=24)
        current_week = get_task_count(days=7)

        # Get stats for previous periods
        previous_hour = get_task_count(hours=1, offset_hours=1)
        previous_day = get_task_count(hours=24, offset_hours=24)
        previous_week = get_task_count(days=7, offset_days=7)

        extra_context['task_stats'] = {
            'current': {
                'hour': current_hour,
                'day': current_day,
                'week': current_week,
            },
            'previous': {
                'hour': previous_hour,
                'day': previous_day,
                'week': previous_week,
            }
        }

        return super().changelist_view(request, extra_context=extra_context)

Breaking Down Problems

Once you've identified that there is a problem through indicators, the next step is breaking it down into manageable pieces.

Any big, challenging problem can be broken into a set of smaller, simpler problems you can solve.

Isolating Variables and Narrowing Scope

When faced with a complex system like a Django application, trying to hold the entire system in your head while troubleshooting is nearly impossible. You need to find ways to narrow the scope and isolate variables to identify exactly where the problem lies.

Here are some strategies for breaking down problems:

Make Your System Testable: Writing testable code naturally leads to better troubleshooting. When you make functions and methods idempotent (same input always produces same output), keep code blocks reasonably small, and focus each function on a single responsibility, you make it much easier to isolate and test components separately.

Use Breakpoints Effectively: Debugging has a long, interesting history. Betty Holberton, who worked on the ENIAC (one of the first digital computers), developed the concept of "breakpoints" by literally pulling cables to stop program execution at specific points. This fundamental technique is something all troubleshooters still use today - stopping execution to examine the state of your application at critical points.

In Django, you can use Python's debugger (pdb) or your IDE's debugging tools to set breakpoints and inspect variables:

def my_view(request):
    # Set a breakpoint
    import pdb
    pdb.set_trace()

    # Or using the new built-in in Python 3.7+
    breakpoint()

    # Your code continues...
    result = some_calculation(request.GET.get('value'))
    return render(request, 'template.html', {'result': result})

When execution reaches the breakpoint, you can examine variables, execute code line by line, and understand exactly what's happening at that moment.

Extract and Test Components: When you suspect a particular function or method is causing problems, extract it and test it separately:

# In your shell or a test file
from myapp.utils import problematic_function

# Test with different inputs
result1 = problematic_function(input1)
result2 = problematic_function(input2)

# Compare expected vs actual results

This approach helps you confirm whether the problem is in this specific function or elsewhere in your application.

Testing: While outside the scope of this article, it's always good to remember that proper testing (unit testing with pytest or unittest, along with integration testing and end-to-end testing) can reduce the amount of troubleshooting you end up doing later on as your codebase evolves.

Balance Narrowing Scope with Avoiding Tunnel Vision

While narrowing the scope is crucial, you don't want to prematurely focus on a specific function or line of code that might not be the actual source of the problem. It's easy to get fixated on something and spend hours troubleshooting a small block of code that turns out not to be the issue.

To avoid tunnel vision, periodically ask yourself:

• Did I make the correct assumptions when I started narrowing my scope?

• Did I miss something important that might have led me elsewhere?

• Am I considering all of the available indicators?

• Is the problem really what I think it is, and is it where I think it is?

• Could there be more than one problem happening simultaneously? 😱

Having multiple problems at once is particularly challenging, which is why having well-structured, testable code is so valuable. It allows you to verify each component independently.

Getting an outside perspective can be invaluable when you've been staring at the same code for hours. Sometimes, simply explaining the problem to someone else can lead to insights. This technique is often called "rubber duck debugging" - the act of explaining your problem to an inanimate object (traditionally a rubber duck) forces you to articulate the issue clearly, which often reveals the solution.

If you don't have a rubber duck handy, you can use a regionally appropriate animal - for example, Random Geek from New Mexico recommends a Javelina!

When and How to Ask for Help

There comes a point in every troubleshooting journey where you might need to reach out for assistance. Knowing when and how to ask for help can make all the difference.

Knowing When to Seek Assistance

Consider asking for help when:

• You're hopelessly stuck and frustrated: When stress levels increase, thinking quality decreases. Sometimes stepping away or seeking help is the most productive thing you can do.

• You want new perspectives: Sometimes you're on the right track but could benefit from someone who's seen similar issues before.

• You need a fresh pair of eyes: We all get tired and miss things that might be obvious to someone coming in fresh.

Remember, asking questions isn't a sign of failure - it's a skill in itself, and one worth developing. The ability to clearly communicate technical problems is incredibly valuable in development work.

How to Ask Effective Questions

For your questions to be answered effectively, you need to:

• Provide context: Explain the problem clearly, including how it started and what you've observed.

• Be specific: Share relevant code snippets and error messages. Don't assume the problem is obvious to others - even experienced developers need context when looking at unfamiliar code.

• Show what you've tried: Demonstrating the steps you've already taken not only prevents redundant suggestions but shows respect for the time of those helping you.

• Be open to suggestions: Sometimes the best solutions come from unexpected directions or approaches you hadn't considered.

Creating a Minimal Reproducible Example (MRE)

One of the most effective ways to get help is to provide a minimal reproducible example (MRE) - the smallest amount of code and context needed for someone else to reproduce your issue.

A bad example:

"I'm using Django and I want to upload a file. I've created a model and a form, but I get errors when I try to upload a file."

What's missing here? The version of Django, the specific error message, code snippets, and what the person has already tried.

A better example:

"I'm using Django 5.0 and I'm trying to create a form to upload a file. I created a model with a FileField and a form with a FileField, but when I go to the view in my browser, the form isn't shown. Here's my code:

models.py:
class MyModel(models.Model):
    file = models.FileField()

forms.py:
class MyForm(forms.ModelForm):
    class Meta:
        model = MyModel
        fields = ['file']

views.py:
def my_view(request):
    template = 'my_template.html'
    if request.method == 'POST':
        form = MyForm(request.POST, request.FILES)
        if form.is_valid():
            form.save()
            return redirect('my_view')
    else:
        form = MyForm()
    return render(request, template, {'form': form})

<form method="post" enctype="multipart/form-data">
    {% csrf_token %}
    {{ forms }}
    <button type="submit">Submit</button>
</form>

Now someone can quickly spot the issue - a typo in the template using {{ forms }} instead of {{ form }}. This is the kind of clear, specific example that gets quick, accurate help.

Where to Get Django Help

When you need help with Django specifically, there are several excellent resources:

• The "Using Django" section of the Django Forum

• The Django Ticket Tracker

• Social media platforms like Mastodon (and other places)

• Reddit communities like r/django and r/djangolearning

• Stack Overflow (with various Django-related tags)

• Django Discord

• #Django IRC channel on Libera.chat

Documenting the Process

The final critical component of effective troubleshooting is documentation. Writing down your process helps not only you in the future but also others who might encounter similar issues.

Why Documentation Matters

Documentation is especially important (and a kindness to future-you) when:

• You're working on a long-running or complex problem that might span multiple sessions

• The solution might be useful to others on your team or in the broader community

• The issue could recur, and you want to save future-you the trouble of rediscovering the solution

What to Document

An effective troubleshooting log includes:

• What was the problem? Describe the issue clearly, including any error messages or unusual behavior.

• What did you try? Document each approach you took, whether successful or not.

• Why did you try that? The reasoning behind your choices is often as valuable as the steps themselves.

• What did you expect to see? Your assumptions and expectations are important context.

• What was the outcome? The actual results of each attempted solution.

• What else might you try? If you had to stop troubleshooting, note your thoughts about potential next steps.

Writing down what else you were thinking about trying is particularly valuable when you need to step away from a problem and return to it later. Human memory is in short supply, and without documentation, you might lose valuable insights or approaches you had considered.

Sharing Your Solutions

Whenever possible, share your solutions with the wider community. This might be:

• A detailed comment in your commit message

• A post on Stack Overflow

• A "Today I Learned" blog post

• Documentation in your project wiki

• A contribution to official documentation

Remember, if you struggled with something, others probably will too. Your documentation could save someone (or future-you!) hours or days of frustration.

Review and Conclusion

Let's go over the key points to consider when making troubleshooting a lifestyle:

1. Understand and use indicators and tools: Learn what's available to help you identify problems and narrow down their causes. In Django, this includes error pages, the checks framework, logging, debug toolbar, and monitoring services like Sentry.

2. Break problems down into manageable chunks: Complex systems are made up of simpler components. Test them separately to isolate issues.

3. Avoid tunnel vision: Don't get so focused on one area that you miss the bigger picture. Periodically step back and reassess your assumptions.

4. Ask for help effectively: Provide context, be specific, show what you've tried, and use minimal reproducible examples.

5. Document everything: Write down your process, findings, and solutions to benefit both yourself and others.

The more effectively you troubleshoot, the better you'll become at it. Like any skill, it improves with quality practice.

At the end of the day, troubleshooting isn't just about fixing technical problems. It's a mindset that applies across all aspects of life and work. Whether you're dealing with a Django error, a hardware malfunction, or even a communication breakdown in a team, the systematic approach of identifying the problem, narrowing down the cause, and methodically testing solutions will serve you well.

Remember that with the right tools, techniques, and indicators, there's always a way to troubleshoot a problem that makes sense and will get you to a solution. Stay persistent, maintain your curiosity, and keep refining your approach - and you'll find that troubleshooting truly becomes a lifestyle that helps you in any area of life.

Bonus: Actively practice your Python troubleshooting skills with Eric Matthes' py-bugger, which inserts bugs for you to resolve. An excellent way to practice!

• Give credit where it's due.

• Take the blame when things go wrong.

• Fight for your people when they need you.

These ideas aren't new, but they're worth repeating—because too many people who should be leaders fail to follow them.

Give the Credit

Your team does the real work. A good leader recognizes this and ensures the right people get acknowledged.

Years ago, I worked for someone who would praise me privately for my work. But when I would build detailed, quality products or documents, that person would strip the email traffic and summarize the text as though the work originated solely from them. I can tell you that this was absolutely demoralizing. I didn't feel like I needed public acknowledgement for every task I accomplished, but seeing someone else accept the credit for my work was a huge discouragement from providing them with my best.

When someone on your team has a great idea, praise them publicly. Whether it's in a team meeting, a company-wide email, or a casual conversation, give them the recognition they deserve. It costs you nothing, but means everything to them.

If they send you an email with an insightful solution or well-executed work, don't just summarize it as if you came up with it. Forward their email, add a note highlighting their contribution, and CC them so they can see the impact of their work. It's as easy as writing, "This was [Name]'s idea. They put in the hard work to make it happen."

Why does it matter? Because when people feel seen and valued, they invest more in their work. They're more willing to take risks, share ideas, and go the extra mile.

And as a leader, when you consistently credit your team, it doesn't diminish your reputation, it enhances it! Having talented people producing quality work under your leadership is a testament to your ability to develop others—a hallmark of real leadership.

Take the Blame

Good leaders take responsibility.

As a leader, you're ultimately accountable for:

• How you train your team

• The processes you establish

• The culture you foster

• The guidance you provide (or fail to provide)

Nothing destroys trust faster than watching a leader throw their team under the bus when something goes wrong. We've all seen it before—some higher-up trying to save face by blaming an employee or a "communication failure." It might work in the short term, but the damage is lasting. Your people will never fully trust you again. And once you lose trust, you will never again have their full commitment or best work.

A real leader says, "That's on me. I should have caught that. I'll make sure it doesn't happen again."

Even if the mistake wasn't directly your fault, as the leader, it's your responsibility to own it.

Why? Because it...

Builds trust—When your team sees you standing up for them, even in tough situations, they'll know you have their back. They'll feel safe taking calculated risks, which is critical for innovation and growth.

Fosters accountability—By modeling accountability, you encourage your team to take ownership of their work. They'll be more likely to admit their mistakes and learn from them, rather than hiding them out of fear.

Protects your integrity—Blaming others might save face in the short term, but it diminishes your character in the long term. Taking responsibility, on the other hand, shows strength and humility.

It doesn't mean you ignore mistakes. You still need to address what went wrong, but that happens privately, within your team—not in a public blame game. Your job is to absorb the hit so your people can keep doing good work without fear.

Fight for Your People

Early in my military career, there was a pivotal moment where I failed to do this. In order to achieve a goal that had not been accomplished in previous exercises, our unit leadership decided on a course of action that had our Marines working in the desert heat for the entire day, displacing & emplacing large, complex equipment in a single day. It was far too much. And I should have known and ensured my Marines were taken care of. Instead, I pushed them to work an unrealistic number of hours under the hot desert sun until the point that my most mechanical-minded Marine torqued a bolt beyond the intended 90 foot-pounds to 350 foot-pounds instead - shearing the bolt head and seizing the steel shaft of the bolt into the aluminum frame it was seated in. We had no spare frames. At that point I demanded all work cease for the day. Exercises are important for learning and improving, but not at the risk of personnel and equipment safety. I spent nearly 8 hours the next day slowly drilling that bolt out of the frame so we could reassemble the equipment. And I learned an important lesson. As the leader, I was the one who should have been aware of my Marines' fatigue and diminishing concentration, and I should have had the courage to tell leadership that the demands we had placed on them were unrealistic and unsafe. I felt ashamed, and vowed never to make a mistake like that again. And I think I have succeeded in that goal.

Leadership isn't just about managing tasks—it's about protecting and advocating for your team. It's about caring for the people on your team as human beings.

A decade ago, a mentor of mine told me:

"When you get a promotion, the money and benefits are for you. But the rank is for your team."

That stuck with me. Leadership comes with authority, but that authority is meant to be used for the people you lead. Your position isn't just a personal achievement—it's a platform to advocate for those you lead.

If someone from another department is causing problems for a member of your team, step in. If upper management is making unrealistic demands, push back. If your team member is being treated unfairly, be the shield between them and the nonsense.

I recently became aware that our organization had made errors in the accession records for someone on my team. Because I had recently done the research to resolve a similar situation with my own records, I knew exactly what to do to fix the issue. We sat together for a while and combed through their paperwork, eventually submitting the required forms to headquarters. It took very little time and effort on my part, but it gave that person peace in knowing that their records reflected the correct values, and it resulted in a substantial amount of back-pay for them. For several weeks afterwards, I was living off the high of being able to help them!

When you use your position to:

• Shield your team from organizational politics

• Get them the resources they need

• Remove barriers to their success

• Stand up for them when they're treated unfairly

• Advocate for them when they are overworked or overlooked

• Provide growth opportunities, such as cross-training or certifications

• Demand that they get the awards and promotions they deserve

...you demonstrate that you value them as humans, not just resources. And you build a team that's willing to go the extra mile—not because they have to, but because they want to.

The Leadership Paradox

Leadership isn't about the title on your door or your position on an org chart. It's about how you show up for the people who trust you with their time, talent, and ambition.

In a world where "leadership" is often equated with dominance, having "winning cards", or self-promotion, embracing these ideas can feel counter-cultural. But here's the paradox: the more credit you give away, the more you receive. The more responsibility you take for failures, the more authority you earn. The more you fight for others, the stronger your own position becomes.

You might worry that taking the blame will make you look weak or that giving away credit will diminish your own contributions. But in reality, these actions demonstrate confidence, humility, and a genuine concern for people—qualities that inspire loyalty and respect. When you give credit, take blame, and fight for your people, you create a culture of trust, accountability, and mutual respect. Your team will be more engaged, more productive, and more likely to stick around. And as their leader, their success reflects on you.

So, the next time your team achieves something great, make sure the right people get the credit. The next time something goes wrong, step up and own it. And the next time your team needs someone in their corner, be that person.

It's not just good leadership—it's the right thing to do.

Putting These Ideas into Practice

If you're looking to implement these ideas in your leadership approach:

1. Start small—Begin by intentionally calling out one team member's contribution each week in a meeting, email, or during visits from senior personnel in the organization.

2. Create a "blame-free" environment—Establish a norm where mistakes are treated as learning opportunities, not just reasons for punishment.

3. Schedule regular one-on-ones—Use this time to understand your team members' challenges and identify where you can advocate for them. But also—just take some time to talk with your people! After all, you are also a person. It is okay to chat and interact with your team. You don't have to be "the boss" at all times.

4. Reflect regularly—This is my biggest struggle, but one I have worked hard to improve on. You can, too. Set a calendar reminder to ask yourself monthly: "Who on my team has done great work that I can award or praise them for? Were there recent situations where I took responsibility (or failed to)? How have I fought for my team lately?"

What are your thoughts on these topics? Have you seen them in action (or have you seen the fallout when leaders fail to do these things)? Any practical tips for implementing these ideas that I missed? Let me know!

For years, I admired the power of django-autocomplete-light (DAL). It’s a feature-rich library that integrates seamlessly with Django. However, its extensive scope brings complexity, and development can feel slow at times. Many developers also gravitate toward Select2, but now that neither Django 5 nor Bootstrap 5 require jQuery, I’m hesitant to reintroduce such a dependency just for a form widget. With modern JavaScript options available, I wanted a solution that could offer:

• A subset of DAL’s functionality—enough for most use cases, but simpler and easier to maintain.

• Widgets like Select2 but without the jQuery dependency.

A Discovery

While scrolling through PyPI (a daily ritual for me - more consistent than my social media habits 😄), I stumbled upon mizdb-tomselect. It uses Tom Select, and the description of that library caught my attention:

"Tom Select is a dynamic, framework-agnostic, and lightweight (~16kb gzipped) <select> UI control. With autocomplete and native-feeling keyboard navigation, it’s useful for tagging, contact lists, country selectors, and so on."

That said, mizdb-tomselect was written for a specific use case: the MIZDB app. Its author openly acknowledges that: “It was written specifically with MIZDB in mind.” This limitation was understandable—many of my own packages were created to meet my specific needs, with the hope that they might help others too.

Why Tom Select? Why Not Something Else?

You might wonder why Tom Select stands out over other options. Here are my favorite features:

• Lightweight and efficient: At just ~16kb gzipped, it adds minimal overhead.

• Modern design: Autocomplete, keyboard navigation, columns, remote data, accessibility, plugins, and more are built-in.

• Framework agnostic: It’s easy to integrate without requiring a specific JavaScript stack.

• Styling: Comes with styling support for Bootstrap 4 & 5, or plain styling, with the easy possibility of supporting other css frameworks.

• Plugins: Tom Select has several existing plugins, and development of new ones is very straightforward.

• No jQuery dependency: This aligns well with Django 5 and Bootstrap 5’s modern approach.

Forking

By mid-2023, I realized that while mizdb-tomselect had significant potential, it was not quite as flexible as the ideal package I was dreaming of. I forked the package and began evolving it into django-tomselect, aiming to:

• Remove app-specific constraints.

• Make it adaptable for a variety of Django projects.

• Provide a polished developer experience with more thorough documentation and examples.

However, my initial progress was hampered by time constraints, my less-than-optimal packaging workflow at the time, and gaps in my knowledge. Despite these hurdles, I continued using django-tomselect in my projects. Over time, its importance grew as I depended on it more heavily in business-critical applications.

A Breaking Point and a Breakthrough

By early 2024, I reached a breaking point. I needed django-tomselect to be more reliable and flexible, not just for my projects but for others who might rely on it. This realization coincided with two key changes:

1. Improved Packaging Workflow: Over the past year, I’d refined my process for building and maintaining Python packages, making it easier to implement changes quickly.

2. Prioritization: As django-tomselect became a more critical component in my business applications, I dedicated significant time in late 2024 to a major rewrite.

This rewrite touched every corner of the package. I added or updated:

• Improved flexibility: More configuration options to suit diverse use cases.

• Added hooks: It was important to me that the autocomplete QuerySet, the authorization, the templates, and the output data could all be overridden in a reasonable manner.

• Comprehensive examples: From the original few example which showed how to do single & multiple selections with or without a tabular layout, the package now has 15 different examples from basic to advanced with ready-to-use snippets to help developers get started. The final two examples are nearly complete applications in their own right.

• Better testing: Ensuring reliability across Django versions and various environments.

• More thorough auth integration: It is important that end users are provided with relevant options that are applicable to the functionality they have been granted.

• Media template tags: The django_tomselect template tag make it easier to include the Tom Select static content on base pages, especially when loading multiple forms or including forms with {% includes %} tags or via htmx. And you can specify the css framework to use and whether to use minified static, overriding the global settings if desired.

• Clearer documentation: I rewrote and reorganized the docs so users could adopt the package with minimal friction.

The Road Ahead

With django-tomselect now much more robust, I’m excited to continue building on its foundation. There is still room to grow—perhaps adding integration with Django’s admin, enhancing performance for very large datasets, or providing advanced theming options (Tailwind?). Feedback from the community will be crucial as the package evolves.

In the meantime, I encourage you to give django-tomselect a try. If you’re looking for a clean, modern way to handle dynamic form selections, it might be just what you need. And as always, I’d love to hear about your experiences and suggestions for improvement.

PS: If you’re not already browsing PyPI daily, I highly recommend it. You’d be amazed at the gems waiting to be discovered!

I wanted to make some quick improvements by squashing a good number of migrations, not to spend a huge amount of time optimizing or fixing broken migrations. So I made sure to thoroughly read the migrations page of the django docs to make sure I did things right. Django provides great tools for managing migrations, but squashing migrations in a production SaaS project can be a bit scary 😱.

To make things easy on myself, I thought through how I could minimize the risk.

Understand the Migration Graph

My first step was to understand how the migrations in my project related to each other. Django's migrations form a graph, but mentally visualizing its structure can be tricky, especially when there are lots of apps and models and relationships all around. So, I used the migrationgraph management command from the django-model-info package - one of several tools in the package that help in understanding, visualizing, and documenting the models in your Django projects.

python manage.py migrationgraph

This command outputs a detailed listing of all migration dependencies in a project, along with the code for a MermaidJS visual of the dependency graph. You can also filter to specific apps in your project if the resulting output is too large for a single graph. The MermaidJS visual helps us see both direct dependencies (migrations that must be applied before another) and indirect dependencies (migrations that are required through a chain of other migrations).

Here is an example of the output (I cut out the detailed listing to keep it more concise):

graph TD
    invitations_0002_logentry_remove_auto_add["invitations/0002"]
    orders_0006_require_invoicing_0002["orders/0006"]
    invitations_0001_initial["invitations/0001"]
    orders_0002_alter_permission_name_max_length["orders/0002"]
    orders_0008_alter_user_username_max_length["orders/0008"]
    orders_0009_alter_user_last_name_max_length["orders/0009"]
    inventory_0001_initial["inventory/0001"]
    analytics_0001_initial["analytics/0001"]
    sales_0001_initial["sales/0001"]
    orders_0011_update_proxy_permissions["orders/0011"]
    orders_0005_alter_user_last_login_null["orders/0005"]
    common_0001_initial["common/0001"]
    orders_0004_alter_user_username_opts["orders/0004"]
    invitations_0003_logentry_add_action_flag_choices["invitations/0003"]
    orders_0001_initial["orders/0001"]
    sessions_0001_initial["sessions/0001"]
    orders_0003_alter_user_email_max_length["orders/0003"]
    orders_0012_alter_user_first_name_max_length["orders/0012"]
    invoicing_0001_initial["invoicing/0001"]
    orders_0010_alter_group_name_max_length["orders/0010"]
    orders_0007_alter_validators_add_error_messages["orders/0007"]
    invoicing_0002_remove_content_type_name["invoicing/0002"]
    orders_0001_initial --> invitations_0001_initial
    orders_0011_update_proxy_permissions --> orders_0012_alter_user_first_name_max_length
    orders_0003_alter_user_email_max_length --> orders_0004_alter_user_username_opts
    orders_0002_alter_permission_name_max_length --> orders_0003_alter_user_email_max_length
    inventory_0001_initial --> analytics_0001_initial
    inventory_0001_initial --> sales_0001_initial
    orders_0006_require_invoicing_0002 --> invoicing_0002_remove_content_type_name
    invoicing_0001_initial --> invitations_0001_initial
    orders_0005_alter_user_last_login_null --> orders_0006_require_invoicing_0002
    invoicing_0002_remove_content_type_name --> orders_0012_alter_user_first_name_max_length
    orders_0004_alter_user_username_opts --> orders_0005_alter_user_last_login_null
    common_0001_initial --> sales_0001_initial
    common_0001_initial --> analytics_0001_initial
    orders_0001_initial --> orders_0002_alter_permission_name_max_length
    orders_0001_initial --> common_0001_initial
    orders_0007_alter_validators_add_error_messages --> orders_0008_alter_user_username_max_length
    orders_0006_require_invoicing_0002 --> orders_0007_alter_validators_add_error_messages
    orders_0008_alter_user_username_max_length --> orders_0009_alter_user_last_name_max_length
    invoicing_0001_initial --> invoicing_0002_remove_content_type_name
    orders_0009_alter_user_last_name_max_length --> orders_0010_alter_group_name_max_length
    invitations_0001_initial --> invitations_0002_logentry_remove_auto_add
    invoicing_0001_initial --> orders_0001_initial
    invitations_0002_logentry_remove_auto_add --> invitations_0003_logentry_add_action_flag_choices
    orders_0010_alter_group_name_max_length --> orders_0011_update_proxy_permissions
    invitations_0003_logentry_add_action_flag_choices --> invoicing_0002_remove_content_type_name

Based on this output, we can see that Django's migrations are a Directed Acyclic Graph (DAG). This is crucial because it means:

1. Migrations have a clear order of operations

2. There are no circular dependencies

3. We can safely squash any linear sequence of migrations without breaking the graph structure

Identify Safe Squashing Candidates

We can easily squash linear paths where each migration depends on only one other, and each migration is a dependent of only one other (excepting the last migration in the linear path, which can have multiple migrations depending on it).

An example might help. Looking at our migration graph, we identified these safe paths to squash:

1. orders/0002 through orders/0006: A perfect linear sequence where each migration builds on the previous one

0002 → 0003 → 0004 → 0005 → 0006

2. orders/0007 through orders/0011: Another clean linear sequence

0007 → 0008 → 0009 → 0010 → 0011

3. invitations/0002 through invitations/0003: A smaller but equally safe sequence

0002 → 0003

Important Constraints

Some key observations about what we don’t want to include:

• We don't include orders/0001 in our first squash because it has multiple dependencies and dependents. Including it would risk breaking the dependency graph.

• We don't include orders/0012 in our second squash because it depends on multiple migrations. This kind of "merge point" in the graph should stay separate to maintain the correct order of operations.

These constraints aren't arbitrary - they're important for maintaining the integrity of our project's migration history while also allowing us to easily optimize it. Django will allow you to, for instance, squash from orders/0001 to orders/0012, but you are much more likely to run into serious issues and broken migrations when you try to remove the old squashed migrations files. Then you either have to roll back or do a lot of extra manual editing of migrations - or the database itself!

Implement the Migration Squashes

After identifying our safe paths for squashing, we can execute the squash process. Let's walk through each step:

1. Create the Squashed Migrations

For each identified linear path, we run Django's squashmigrations command:

python manage.py squashmigrations orders 0002 0006
python manage.py squashmigrations orders 0007 0011
python manage.py squashmigrations invitations 0002 0003

This creates new migration files with names like:

• orders/migrations/0002_alter_permission_name_max_length_squashed_0006_require_invoicing.py

• orders/migrations/0007_alter_validators_add_error_messages_squashed_0011_update_proxy_permissions.py

• invitations/migrations/0002_logentry_remove_auto_add_squashed_0003_logentry_add_action_flag_choices.py

Each command creates a new migration file that combines the operations from the specified range of migrations.

Django tries to optimizing situations like when one migration adds a field and a following one removes that same field. In this case, the field would simply not be mentioned at all in the resulting squashed migration. Django also automatically handles the internal dependencies and places a replaces attribute in the new migrations files that lists all of the migrations this new file supersedes.

class Migration(migrations.Migration):
    replaces = [
        ('orders', '0002_alter_permission_name_max_length'),
        ('orders', '0003_alter_user_email_max_length'),
        # ...
    ]

    dependencies = [
        ('orders', '0001_initial'),
    ]

2. Update Servers

The trickiest part of squashing migrations is ensuring all your production servers are ready for the change. Here's the approach to use:

1. First, deploy the squashed migrations WITHOUT removing any of the original ones:

    git add */migrations/*_squashed_*.py
    git commit -m "Add squashed migrations"
    git push origin main
   

2. Deploy to all servers and verify they run the migrations successfully:

    python manage.py migrate
   

   The migrations system will skip over the squashed migrations if the individual migrations they replace have already been applied (this is expected).

3. Verify in your database that all the replaced migrations are still marked as applied:

    SELECT app, name, applied FROM django_migrations 
    WHERE app IN ('orders', 'invitations')
    ORDER BY app, name;
   

3. Update Migration Dependencies

Next, we update any migrations that previously depended on a now-squashed migration. Looking at our dependency graph, here are some examples:

1. orders/0012_alter_user_first_name_max_length depends on orders/0011

   • Update its dependencies to instead point to 0007_alter_validators_add_error_messages_squashed_0011_update_proxy_permissions

2. invoicing/0002_remove_content_type_name depends on invitations/0003

   • Update its dependencies to instead point to 0002_logentry_remove_auto_add_squashed_0003_logentry_add_action_flag_choices

...and so on.

Example of updating a migration's dependencies:

# orders/migrations/0012_alter_user_first_name_max_length.py
dependencies = [
    ('orders', '0007_alter_validators_add_error_messages_squashed_0011_update_proxy_permissions'),  # Updated dependency
]

This is just a matter of find/replace for each replaced migration in your system, and is potentially the longest part of this whole process.

4. Remove the replaces Attribute

Once all servers are updated and running the squashed migrations, we can remove the replaces attribute from our squashed migrations. This tells Django to treat them as normal migrations:

# Before:
class Migration(migrations.Migration):
    replaces = [
        ('orders', '0002_alter_permission_name_max_length'),
        ('orders', '0003_alter_user_email_max_length'),
        # ...
    ]

    dependencies = [
        ('orders', '0001_initial'),
    ]

# After:
class Migration(migrations.Migration):
    dependencies = [
        ('orders', '0001_initial'),
    ]

5. Clean Up Old Migrations

Finally, we can remove the original migration files that were squashed, and push these changes to the servers:

# For orders app
rm orders/migrations/0002_alter_permission_name_max_length.py
rm orders/migrations/0003_alter_user_email_max_length.py
rm orders/migrations/0004_alter_user_username_opts.py
rm orders/migrations/0005_alter_user_last_login_null.py
rm orders/migrations/0006_require_invoicing_0002.py

rm orders/migrations/0007_alter_validators_add_error_messages.py
rm orders/migrations/0008_alter_user_username_max_length.py
rm orders/migrations/0009_alter_user_last_name_max_length.py
rm orders/migrations/0010_alter_group_name_max_length.py
rm orders/migrations/0011_update_proxy_permissions.py

# For invitations app
rm invitations/migrations/0002_logentry_remove_auto_add.py
rm invitations/migrations/0003_logentry_add_action_flag_choices.py

Results

After completing this process in our real-world project, our migration count dropped significantly. We were able to replace 113 of our migrations with 15 new squashed migrations. That’s a reduction of nearly 40% of migrations! More importantly, we ran into zero issues or hiccups during this process and maintained a working migration history and stable deployments. A couple hours of work to remove almost 100 migrations. If we were to do it again after working through this, it would be much quicker.

Tips for Squashing

1. Identify linear paths in your migration graph before squashing. The django-model-info package can help make this relatively easy.

2. Avoid trying to squash migrations that have multiple dependents or dependencies.

3. Always deploy squashed migrations to every server and run the migrate command before removing any original migrations files.

4. Be sure to verify each step of the process in a staging environment prior to doing so in production.

5. As always, whenever making major changes like this, have backups of each of your servers and make sure they work BEFORE you make any changes.

Hope y'all found this helpful. This approach might take a tiny bit more time than just squashing everything at once, but it's much safer and prevents deployment headaches. And, really, if you’re avoiding issues that may require manually mucking with fixing migrations and your database, isn’t a few extra minutes on the front end well worth it? I think so.

The Problem

A situation I've encountered repeatedly when building B2B applications is that tenants need to collect information through forms, but each tenant wants their own spin on the options they show the end-user. But, you may need to ensure certain choices are always available across all tenants for consistency or compliance reasons, and some tenants don’t want to create a form’s options from scratch - they want default options that make sense to start with.

Here's a concrete example: Imagine you're building a coffee ordering platform for businesses. Each business (tenant) needs a form where their customers can select their preferred coffee type. Simple enough… but then it gets tough:

Tenant A has a traditional coffee shop and wants to offer: Drip Coffee, Espresso, and Cold Brew. Tenant B has a specialty café, preferring Pour Over, Espresso, and Horchata Lattes! As the platform owner, you want to ensure "Espresso" is always an option (maybe you get a kickback from the Espresso Guild for the number of espressos ordered through your SaaS app).

Some Approaches… and their Headaches

When I first encountered this problem, I explored several common approaches. Each one left me disappointed in the compromises I’d have to make.

A CharField with choices seems like the obvious first solution. It's simple to implement, and Django handles makes it easy to add to a form. But the moment a tenant asks for a custom option, you've got to create a new migration. Not great 🙄

The next thing to try might be a ManyToManyField with a custom through-model. This adds flexibility, but now you're juggling the complexity of maintaining default options and figuring out how to enforce mandatory choices across all tenants. Complexity grows quickly 😓

Some developers reach for JSONField at this point. It’s flexible, but you lose schema validation and referential integrity. They're great for storing json data, but not an ideal alternative for most django fields. And querying is a bit less intuitive than working with traditional models/fields in the django ORM 😬

And then there's the nuclear option: custom models per tenant. I can’t imagine a situation where this would end well. The increase in migrations alone should scare you away from this approach 🤢

So, django-tenant-options!

After wrestling with these approaches in my projects, I built django-tenant-options to solve the problem once and for all. The package provides a structured way to:

1. Define mandatory options that appear in every tenant's forms

2. Offer optional defaults that tenants can choose to use (makes it easier for tenants who don't want to spend time starting from scratch)

3. Allow tenants to create their own custom options

4. Maintain data integrity even when options change

Here's a realistic example - a financial document management system where employees upload statements and must specify the document type as part of the form. Let's assume you already have a Tenant model in your Django project.

In django-tenant-options, every "Choice" model is paired with a "Selection" model. Options at the things a tenant can choose from or create. Selections are the resulting subset of Options selected by each Tenant to be shown in their resulting form.

from django_tenant_options.models import AbstractOption, AbstractSelection  
from django_tenant_options.choices import OptionType

class DocumentTypeOption(AbstractOption):
    tenant_model = "yourapp.Tenant"  # Your tenant model
    selection_model = "yourapp.DocumentTypeSelection"  # Defined below
    default_options = {
        "Balance Sheet": {"option_type": OptionType.MANDATORY},  # Always shown
        "Cash Flow Statement": {"option_type": OptionType.OPTIONAL},  # Tenant's choice
        "Fund Flow Statement": {"option_type": OptionType.OPTIONAL},  # Tenant's choice
    }

class DocumentTypeSelection(AbstractSelection):  
    tenant_model = "yourapp.Tenant"  # Your tenant model
    option_model = "yourapp.DocumentTypeOption"  # Defined above

The magic here is in the simplicity. You define your options once, specify which ones are mandatory versus optional, and let your tenants customize from there. The package handles the complexity of maintaining these options and ensuring data integrity.

Behind the Scenes

What makes this package powerful is how it handles the complex cases that usually cause headaches in multi-tenant applications:

Soft deletion ensures that even if a tenant removes a custom option or a selection that was used in existing forms, historical data remains valid and queryable. This has saved me countless hours of data cleanup and maintenance.

Database triggers (optional but recommended) maintain referential integrity between tenants and their options. You probably want this guarantee at the database level.

The package integrates with Django's forms, limiting the code you need to write.

When Should You Use This?

While django-tenant-options might seem niche, I've found it valuable in several types of applications. It's particularly useful if you're building:

• A SaaS platform where different businesses need their own customized forms but you need to maintain some standardization, e.g.: HR systems, project management tools, or any B2B platform where form customization is important.

• Applications where you need to balance flexibility with consistency. The mandatory/optional system lets you give tenants freedom while maintaining control where it matters.

To get some ideas on the types of forms where this might be helpful, we have an Options Cookbook. While some of the custom options are a bit silly, I think you'll get the idea 😁

Getting Started

Installation is straightforward:

pip install django-tenant-options

The package has a good amount of documentation, and I've put significant effort into making it easy to integrate into existing projects. You can find the full documentation at django-tenant-options.readthedocs.io.

~ Fin ~

Building this package has taught me a lot about the challenges of naming projects (the package was originally named flexible-list-of-values), building multi-tenant applications, and the importance of finding the right balance between flexibility and standardization without adding too much magic 🔮. While it might seem like a niche solution, I've found it solves a real problem that comes up surprisingly often in B2B applications.

I'd love to hear your thoughts and experiences with similar challenges. Have you tackled this problem differently? Are there use cases you think this package could help with? Have recommendations for improvements? Let me know in the comments or open an issue on GitHub.

I rarely use BooleanField in a Django project. In nearly every case where I might be tempted to use BooleanField, a better alternative exists.

Two of the biggest benefits of BooleanField are its small size in the database and the simplicity of working with the field. But the size of one type of field compared to another is rarely a dealbreaker or a significant contributor to query time or other concerns in building an app for production. And while simplicity is nice, the use of BooleanField in the wrong place can lead to frustration.

As an example of the potential for things to go awry, consider a common situation django beginners experience.

A desire to track the state of something

Starting with a very basic example model:

class Comment(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    body = models.CharField(max_length=200)
    created_on = models.DateTimeField(auto_add=True)

One requirement for our Comment model is that we must track if the model is approved by the administrator. So a BooleanField is added.

class Comment(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    body = models.CharField(max_length=200)
    created_on = models.DateTimeField(auto_add=True)

    is_active = models.BooleanField(default=False)

Everything looks good. We can now approve user comments by setting is_active to True in any given Comment instance.

But another requirement is identified: We need to be able to archive comments as well. So, let's add another BooleanField!

class Comment(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    body = models.CharField(max_length=200)
    created_on = models.DateTimeField(auto_add=True)

    is_active = models.BooleanField(default=False)
    is_archived = models.BooleanField(default=False)

Now when we archive a file, we have to set both is_active as False and is_archived as True. If we unarchive something, we have to set both is_active as True and is_archived as False.

Each additional BooleanField we add increased the number of steps we need to take (and increases the potential risk we may get the combination of Trues and Falses wrong). What does it even mean if both is_active and is_archived are set to True? It is an undefined state 😧

Alternatives

There are two main situations where we might want an alternative to BooleanField

• When we are tracking state/status, we can use something that ensures only one valid state is selected at any given time

• When we want to track whether a single event or action has taken place, we can use DateTimeField

Let's discuss these in more detail...

Tracking state

Just as in the example above, it is common to need to track the state of a model instance.

Some examples include:

• Is an Order instance in cart, paid, shipped, completed, or canceled status?

• Is a Document in draft, submitted, published, or deleted status?

• Is an Appointment in requested, approved, confirmed, completed, or canceled status?

In each of these cases, only one status makes sense at any given time.

Alternatives to BooleanField in these cases include:

• Using either CharField or IntegerField along with choices to allow selection of each status. I am particularly fond of using TextChoices or IntegerChoices enumeration types, and wrote a small gist cheatsheet when these became available in django 3.0. This is a simple and effective approach when the choices for the status field will not change often, and the user does not need to add new statuses.

• Adding a ForeignKey to another model which contains the available state choices can make it possible for end-users to add new states, but adds increased complexity and another database table.

• Using django-fsm, django-pgtrigger, or other third-party apps to ensure state is correctly maintained. These tools help ensure that status transitions in the correct order from one state to another. This comes with added dependencies, which may be undesired, but both of the packages I mention here are fantastic!

I tend to use the first or last option, depending on the complexity of the business logic. If I am not concerned about the order in which a model instance transitions from one state to another, I tend to use CharField like this:

class Comment(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    body = models.CharField(max_length=200)
    created_on = models.DateTimeField(auto_add=True)

    class StatusChoices(models.TextChoices):
        NEW = "NW" _("New")
        ACTIVE = "AC", _("Active")
        ARCHIVED = "AR", _("Archived")

    status = models.CharField(
        max_length=2,
        choices=StatusChoices.choices,
        default=StatusChoices.NEW,
    )

Tracking a single event or action

When we want to track an event or action, such as whether a Notification has been read, we often first reach for a BooleanField.

But what if you could add context about the action without any significant effort? You can! Just swap BooleanField for DateTimeField.

Instead of...

class Notifications(models.Model):
    # Some fields...

    viewed = models.BooleanField(default=False)

Use...

class Notifications(models.Model):
    # Some fields...

    viewed = models.DateTimeField(null=True, blank=True)

When the action or event takes place (e.g., the Notification is viewed), set the field's value to timezone.now().

This tiny change to the model means that we can now:

• Show the user whether the Notification was read

• List all read Notifications

• Show the user when the Notification was read

• List all Notifications read within the last week

• Create a timeline showing the rate of Notifications read during each month of the year

• Calculate the average gap in time between the creation of a Notification and when that Notification was read

• etc.

With BooleanField, we could only perform the first two of those queries. Being able to query when events took place can easily add value to your end users, and can make it easier for you to audit activities and usage within your project.

When to use BooleanField?

BooleanField does have its use-cases. Here is where I would still use them:

• To determine whether a model instance is something or can be used for something, and it does not make sense to track when this state came to be. For instance, if we want to track whether an Asset is a spare part, we might use is_spares = models.BooleanField(default=False) Another example is whether the Asset can be checked out: can_be_checked_out = models.BooleanField(default=True). This use-case is squishy. It can be hard to tell when we might be better off tracking when these fields change or when simply keeping it to true or false is more appropriate.

• When we are using the field as a setting that does not have state or a particular occurrence time. Usually, this is when setting a value for a model instance that is not expected to change (or at least not often). I use these for configuring tenants in one of my projects. For instance, allow_tenant_to_place_orders = models.BooleanField(default=True). Here I do not care about when the decision to allow or disallow this tenant from placing orders took place, and there is no other state this decision might transition to. The tenant either can or cannot place orders, and that's it.

Conclusion

Hopefully, some of you find these notes helpful. BooleanField has its uses, but it is often over-used. The alternatives mentioned above can help to prevent spaghetti code as the number of potential statuses increase or help to add value when you may need to track when actions in your project took place.

Have thoughts or questions about these ideas? I would love to hear them 🙂

Day 1 - 0945 - Keynote

• Jay Miller @kjaymiller
• Melanie Arbor @melaniearbor

They both have faced struggles and challenges, personally and professionally.

Content

• Used analogy of swimming (and inexperienced swimmers) to coding (and folks new to coding and to our community)
• Country Clubs - historical racist foundations - used as a way to keep segregated spaces despite integration efforts/laws in the past
• Talked about PyCon Host City Diversity - are we as a community meeting the mark when selecting host cities that are diverse and not super-costly?
• Something like 7 times more likely for Black and indigenous children to drown vs white children - much due to lack of training opportunities
  • Similarly, the lack of educational opportunities for underrepresented groups keeps them out of tech
  • Studies show that racial and gender discrimination in tech has increased recently - we have a lot of work to do
• Stats show an overwhelming male/cis/straight/white population in tech, with the result being...
  • Policies are made with a focus on this population
  • Companies focus their marketing on this population

• Geographic separation, discrimination, and lack of opportunities > A trifecta hurting underrepresented groups

• How to protect those in AND around the water (tech)? LIFEGUARDS

  • Help people to feel that anyone can jump in the water (tech)
  • Add Code of Conduct in your projects and community events and actually mean it
    • Know
    • Use
    • Enforce
  • Watch out for sharks!!
  • Be a lifeguard - the greatest contribution to tech you can make is bringing someone new into tech!
• Shout-outs from the speakers
  • Marlene Mhangami - Diversity Chair, PSF
  • Naomi Ceder - Trans*Code
  • Iqbal Abdullah - Organizer in SE Asia
• Uplift other folks - If I have a way to assist with training/opportunities, share with folks in need
• When you're the swimmer, don't try to stay afloat by holding others down
• Code of Conduct is how we care for everybody in the community

Interesting company mention (among several others): Underdog Devs - employing formerly incarcerated folks in the tech world

Day 1 - 1030 - What IMPACT will you have?

Calvin Hendryx-Parker @calvinhp Co-founder & CTO at Six Feet Up

Content

• What impact could a decision you made 20 years ago have today? Django is now about 20 years old
• Six Feet Up goal to complete 10 impactful projects by 2025
• Talked about RevSys and Octopus Energy, Torch Box, Marine Conservation Society, Lincoln Loop
• Some projects they work on: mapping forest fire trajectories, predicting lightning strikes, and streamlining battery energy operations
• Be intentional about using technology for good and in ways that can be impactful to humankind

Day 1 - 1110 - The Django Admin is Your Oyster

Let's extend its functionality

Adrienne Franke (pronounced like "Frankie") @adriennefranke

Content

• Internal tool for trusted users

• Docs say to beware of over-customization, but Adrienne disagrees - go for it!

• Look at the demo repo for examples of things you can do

• Make good use of prefetch_related() & select_related() when querying relationships
• Use the clean() methods in Admin to provide validation
• Within the clean() method, we can add additional cleaned_data objects that can then be used in the save() method
• It's relatively easy to add a sandbox database, and use it from the same project Admin
• Customizing Admin Templates
  • templates > admin > appname > change_form.html
  • You can define a variable in the Admin, and then apply that variable to the template. Can be used to add extra help/context to each Admin page, for instance
• Admin actions - e.g. Apply a discount to a number of objects, hit an external API to update values for a number of objects, etc

Day 1 - 1200 - Documenting Django Code in 2022

Eric Holscher @ericholscher Co-founder of ReadTheDocs and WriteTheDocs

Content

4 Elements of Documentation

• Authoring
  • Structure
    • Diátaxis - A framework for thinking about documentation
    • Organized by User needs - not how the author thinks about it
    • 2 Axes of Diátaxis framework:
      • Study (learning) vs Work (doing) - Sometimes we are in one mode or the other
      • Practical (how to do something) vs Theoretical (state of things, ways to think)
    • The 4 Quadrants of Diátaxis framework:
      • Tutorials: Practical & Study (teaches)
      • How-to Guides: Practical & Work (shows)
      • Explanation: Theoretical & Study (explains)
      • Reference: Theoretical & Work (lists)
  • Tools
    • Sphinx - uses reStructuredText
      • Has good Markdown (with directives) support with MyST
      • Note: You can mix RST and Markdown in the same project
    • MkDocs - uses Markdown (check out Material for MkDocs)
• Theming & Design
  • Furo - a nice new Sphinx theme
• User Experience
  • sphinx-design - an extension with nice UI elements for docs
    • Bootstrap-based
    • Support for many themes
  • sphinx-tabs - Simple tabs display
  • sphinx-copy-button - Adds a code copy button to each code block
  • sphinx-hoverxref - Popup hover cards
  • readthedocs-sphinx-search - Live search in modal
• Deployment
  • RTD is adding lots of extensibility
  • build.jobs - Allows customization of build jobs with a number of hooks
  • build-commands - Override the entire build process

Day 1 - 1400 - Building a Dev-Focused Learner Management System with Django

Sheena O'Connell @sheena_oconnell CTO of Umuzi https://sheenarbw.github.io/pres-djangocon-2022-tilde/

Content

Umuzi

• Invests in people and teaches them tech skills
• Pays people to learn once they show that they would benefit from the investment
• Holistic education (not just the technical stuff)
  • Teamwork, professionalism, wellness, financial literacy

Then, COVID

Problems:

• Employee turnover
• 250 learners needing help
  • Couldn't just go home because they might not have the tools and structure there to complete the courses
• Don't want to let down students or the funding partners who had already invested

How to resolve this?

• Started with keeping attendance, mostly as a smoke detector (make sure students are getting what they need and taken care of)
• Started with a bunch of Google forms
• System was insufficient, didn't just need butts in specific seats at specific times...
  • Needed accountability mechanisms
  • Needed asynchronous interactions
  • Needed self-paced learning
  • Needed smoke detection tools
• Maybe a Learning Management System (LMS)?

Identified Needs:

• Integrate existing syllabus git repo without too much work
• Reduction in dependency of staff
• Simulate real-world work environments - treat learners like professionals
• Integrate with GitHub - limited support in existing LMS tools

So, they build Tilde:

• Kept it lean - laser focus on learners
• Deep GitHub integration
  • Repo Project cards automate Repo creation, protection of main branch, etc
• Includes Per reviews and improvement suggestions
• Essentially a Kanban workflow with review stages
  • If many learners mark a card good, but a trusted reviewer disagrees, then there is a knowledge gap that can be plugged
  • If a learner's card bounces between working and review, they may need additional help
  • If a particular project bounces between review and rework for all learners, maybe it needs revision
  • etc

Under the Hood:

• Keep it boring/simple
• Syllabus as code using Hugo for static site generation
• Generates a knowledge graph of learning which can be mined to better help learners move forward
• Architecture used
  • Hugo
  • Django/dramatiq/Postgres
  • DRF
  • Material UI / React / Redux / Saga

Success!

• Learners are doing fine
• Most learners who complete the course have found long-term jobs
• Have successfully run multiple cohorts of learners through this process
• Hires Juniors from within the Umuzi program, which helps simplify on-boarding

Day 1 - 1450 - Predicting Lightning Strikes with Django and AWS

Calvin Hendryx-Parker @calvinhp Co-founder & CTO at Six Feet Up

Content

• TampaBay has an inordinate amount of lightning strikes in the US
• Novel algorithm developed by Jason Deese in Jupyter Notebook
  • Takes in Radar data and outputs projected strike locations
  • Wanted to scale to cloud-native and low-latency request/response cycle
• Algorithm predicted lighting strike locations ~25 minutes before it actually happened
• LOTS of data - publicly available data from multiple NOAA Radars (up to 15 MB per sweep)
• Models need to be rebuild continuously with new data inputs
• Original Notebook took 30 s, got down to 500 ms
• Wanted cloud-native from the start
• Wanted to keep stack simple
• Developer experience
  • Keep things local for developer
  • Keep environment consistent
  • Docker/Slack/GitLab
  • Infrastructure as Code: using Terraform
  • Lambdas / S3 / ECR Repos / etc
  • Makes use of localstack.cloud to simulate a cloud environment locally
• Next stages - MLOps
• Lambdas can be used successfully for some things that may end up being very costly - they're no the be-all-end-all solution for everything. Use the right tool for the job.

Important note: be careful with Redis caching & serialization if you plan to use the data both with django and outside of django

Day 1 - 1550 - Miracles in Anarchy

Timothy Allen @FlipperPA Wagtail Core Team

Content

• "Anxiety is the key ingredient to Impostor Syndrome"

  • We imagine that others knows a lot and us a little, but in reality all of us understand pieces of the puzzle. See https://billwatts.org/the-imposter-syndrome/
  • None of us understand all the layers
  • Nobody can know it all

• There are so many dependencies, it's amazing that anything in the modern world works at all

  • The whole world relies on Python
  • Modern world relies on trust

• Adventures in Tim's career:

  • Building a custom bank service (and credit card) for David Bowie
    • Backend used Cobol, PHP 3, & MySQL3
    • Frontend was Flash
    • Bowie Bank!
  • Querying Company Codes
    • Used fusion code to query wide tables

• Stories from other companies:

  • The missing Windows 9
    • Because so many developers relied on things like (version starts with "9"), Windows 9 would break things across the ecosystem

• Your voice is as important and valid as anyone else's in the community

• Tim's analogies from the 12 Traditions

  1. We're at our best as a community when we work toward inclusion - we are greater than the sum of our parts
  2. Leaders are trusted servants - not governors
  3. If you want to be a member of the community, you are a member
  4. Each opensource community is an autonomous fellowship. More communities mean more people can get involved.
  5. Openly state the purpose of your organization/project/community
  6. Django is specific about how trademarks may be used
  7. Django is funded by those who use it (individuals and companies)
  8. When work transitions beyond volunteering, it should be paid
  9. Django has a number of committees focused on different ways of helping the community
  10. Django has to be careful about any outside politics/purposes lest we fail to be inclusive
  11. Public relations policy based on attraction rather than promotion - a good, enthusiastic community brings more good people to the community
  12. Principles before personalities - Django is not personality-driven

• DjangoCon is By the Community, For the Community

• Practice makes progress - Progress is where life happens

Day 1 - 1640 - Massively increase your productivity on personal projects with comprehensive documentation and automated tests

Simon Willison @simonw

Content

• Unit testing and internal documentation makes it possible to bring together engineers working across 3 continents - and can help you speed up and keep up with a LOT of projects

• The perfect commit: Implementation + Tests + Documentation + a link to an Issue thread

  • Implementation
    • A software Engineer's job is to change software (the software base usually already exists)
  • Testing
    • Prove that implementation works
    • Pass if correct, fail otherwise
    • Seems like a lot of additional work, but if you start with tests, adding incremental tests is really easy
    • Simon's rule: Every project starts with a test, not matter how small - what matters is that the test suite works
    • He generally starts with one of 3 templates
    • He uses GitHub actions and repository templates along with Cookiecutter to quickly build the foundation for apps
  • Documentation
    • Should live in same repo as the code
      • Otherwise, docs go out of date and people are less likely to contribute and trust the code
      • Can enforce doc changes through code reviews before committing
      • Bonus trick: Enforce that things are documented to validate that there are documentation sections for each feature (tests that check that headers exist for plugins, etc)
  • Everything links to an Issue thread
    • Use Issues more effectively. It's okay to 'talk to yourself' in Issue threads
    • Helps document future actions and explain past actions
    • Add links to documentation, inspiration, SO threads, etc
    • Add code snippets, false starts
    • Add decisions - why did we take this approach? What led to this decision? What else did we consider?
    • Screenshots. Animated screenshots are even better
    • When you close an issue add a link to the relevant docs and documentation

• Issues are Temporal Documentation, and can be used to document personal progress, research, and ideas justas you might for professional work.

  • Time-stamped and contextual
  • Nobody will be upset if you don't update this form of documentation in the future
  • Simon wrote about his trick for moving issues from a private repo to a public repo*, which is not something you can accomplish by default. This is particularly nice if you are writing

• You can quickly pick projects back up later, even if you forgot them completely

  • You don't have to remember anything
  • If you lose Flow state, this allows you to get back into it at a later time
• Use Issues for deep research tasks
• Simon keeps repos of personal projects and tasks, some public and some private

• Make a public-notes repo like simonw/public-notes

• If you do something, tell people about what you did!

  • It's so easy to skip this step
  • Taking an extra 30-60 minutes to write about it gives other people a chance to learn, and helps you recall later
  • Simon uses GitHub releases (with dates)
  • Mindset rule: "No project of mine is finished until I've told people about it in some way"
  • Get a blog
    • Nobody blogs anymore, but you should
    • It works for SEO again these days, because nobody is doing it
  • The enemy of personal projects is guilt
    • Avoid side projects with user accounts - that is an unpaid job, not a side project!
    • If we have documented and tested projects, we can live guilt-free about pausing/not committing 'enough' time to them each

• GitHub Projects v2 is something to look into - brings all of your Issues together

Simon's notes on this talk can be found at: https://github.com/simonw/djangocon-2022-productivity

DjHTML is a pure-Python Django/Jinja template indenter without dependencies.

It standardizes the indentation for Django or Jinja templates throughout your Django project. DjHTML (intentionally) only works on one file at a time. This simplifies DjHTML development and prevents issues with trying to support differences in directory navigation for each operating system. You can read more about DjHTML at it's GitHub repository .

In order to operate on multiple files or entire directories, we can use built-in tools to apply DjHTML to multiple files.

This short guide assumes you are working with Linux and that you have followed the installation instructions for DjHTML. If you are working with a different operating system, it may get you started in the right direction.

Using DjHTML on a directory of templates from the command line

Because DjHTML only takes action on a single file on its own, we need to combine a couple of built-in command line tools within Linux to use it with multiple files at once: find, xargs, and piping.

The find command lets us search for files that meet certain criteria. In our case, we want to search within the current directory (and any subdirectories) for all files that end in .html. The single period "." in the example below tells the find command to search starting from the current directory. You can replace the period with any valid relative or absolute path.

The -name argument of the find command is where we specify the criteria for the file names we want returned by the command. Here, we use the wildcard "*" to specify that we want any files that end in .html

We then use a pipe "|", which redirects the output of one command, program, or process as input to another. Here, we are passing any files found by the find command to the xargs command for further processing.

The xargs command allows you to build up and execute commands with arguments from standard input. Each output of the find command (each file that was 'found') will be passed as an argument to xargs, which will then apply DjHTML indentation to it.

Combining all of this, to apply DjHTML to all html files in the current directory, use the following:

find . -name "*.html" | xargs djhtml -i

Take a look at this issue on DjHTML's GitHub Issues and read through the links provided above on each command for more information.

Using DjHTML in PyCharm

Indent Whenever an HTML File Changes

PyCharm has a file watcher functionality that allows you to apply actions whenever a file changes and is saved. We can add a new File Watcher to automatically apply indentation when a changes are made to a file.

In order to identify the installed location of DjHTML, which you'll need below, use the following on the command-line:

whereis djhtml

To add the File Watcher, from the File menu in PyCharm select Settings. The Settings window will open with a hierarchical menu on the left side.

Within that menu, navigate to Tools and select File Watchers.

In the File Watchers panel, select the + button near the top and from the drop-down, select < custom >. The Create File Watcher dialog will open.

You should be able to use the settings below.

Name:              DjHTML
File Type:         HTML
Scope:             Project Files
Program:           * Full path to your install of DjHTML *
Arguments:         -i $FilePath$
Output Paths:      $ProjectFileDir$

Be sure that "Trigger the watcher on external changes" is checked.

It should look something like this:

Click Ok on the Create File Watcher and Settings dialog windows.

Any time you change an html file in your project and save it, DjHTML should automatically apply indentation.

Use External Tools to Apply Indentation as Needed

External Tools in PyCharm makes it easy to apply actions from third-party tools (like DjHTML) to arbitrary files or directories of files in your project.

From the File menu in PyCharm select Settings. The Settings window will open with a hierarchical menu on the left side.

Within that menu, navigate to Tools and select External Tools.

In the External Tools panel, select the + button near the top to add a new External Tool. The Create Tool dialog will open.

Because of oddities with entering arguments in PyCharm's External Tools, you'll need to pass the arguments to the bash command, rather than running DjHTML directly. If your copy of bash is at a non-standard location, you can identify the location by using the following command:

whereis bash

You should be able to use the settings below, modifying the path to bash, if needed.

Name:              DjHTML
Description:       Django/Jinja template indenter
Program:           /usr/bin/bash
Arguments:         -c "find '$FilePath$' -name '*.html' | xargs djhtml -i"
Working Directory: $ProjectFileDir$

What it should look like within PyCharm:

Click Ok on the Create Tool and Settings dialog windows.

Now you should be able to right-click on any directory or file in the Project pane of the PyCharm IDE, select External Tools -> DjHTML, and the selected files will be indented and saved.

Congratulations! Now you can easily standardize the indentation of all templates within your Django projects!

We want to allow users to set preferences on their profile page. We will look at two elements used for basic settings -- Checkboxes and Selects.

Traditionally there are two approaches to settings like these -- Django forms or traditional HTML forms -- both usually requiring a full page reload or custom JavaScript to post the values via Ajax.

Well... we want the benefits of Ajax form submissions without the pain of writing a bunch of JavaScript.

Background

htmx is a new player in town. The successor to Intercooler JS, htmx promises to allow you to "access AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext".

We're going to utilize htmx to implement some user settings using checkboxes for boolean values and select boxes for choices. This is something that might be used on a user's personal settings page to allow them to change values easily. In this example, users can select whether they want to receive messages (maybe from the system administrator or from other users?) via email and/or SMS, and also how often notifications about their orders should be sent. We are only implementing the preference selections here, not the messaging/notifications/order tooling that would back these up. This example also does not concern itself with security.

This article assumes you already know the basics of django. If not, check out these great resources to get started.

It also assumes your project has a custom User model -- something that's highly recommended for every django project.

User Model

We start with a basic user model, adding the following new fields:

users/models.py

 class User(AbstractBaseUser):

    # ... Ignoring existing fields ...

    receive_email_messages = models.BooleanField(
        _("Receive Email Messages"),
        default=False,
    )

    receive_sms_messages = models.BooleanField(
        _("Receive SMS Messages"),
        default=False,
    )

    class NotificationChoices(models.TextChoices):
        NONE = "NONE", _("None")
        IMMEDIATE = "IMMEDIATE", _("Immediately")
        DAILY = "DAILY", _("Daily Archive")
        WEEKLY = "WEEKLY", _("Weekly Archive")

    order_notification_freq = models.CharField(
        max_length=9,
        choices=NotificationChoices.choices,
        default=NotificationChoices.NONE,
        help_text=_(
            "How often do you want to receive notifications about your orders?"
        ),
    )

Basic Template

The following basic template gives us Bootstrap, htmx, and _Hyperscript. We will fill in the contents of the inner div as we go along. We also add a basic view and url to display the preferences. You won't see much yet if you navigate to this url.

preferences.html

<!doctype html>

<html lang="en">
    <head>
        <title>User Preferences</title>

        <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/css/bootstrap.min.css" integrity="sha384-MCw98/SFnGE8fJT3GXwEOngsV7Zt27NXFoaoApmYm81iuXoPkFOJwJ8ERdknLPMO" crossorigin="anonymous">

    </head>

    <body>
        <script src="https://unpkg.com/htmx.org@1.3.3"></script>
        <script src="https://unpkg.com/hyperscript.org@0.0.9"></script>
        <h3>User Preferences</h3>
        <div class="row m-5">
            <!-- Content will be added here -->
        </div>

        <script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
        <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.3/umd/popper.min.js" integrity="sha384-ZMP7rVo3mIykV+2+9J3UJ46jBk0WLaUAdn689aCwoqbBJiSnjAK/l8WvCWPIPm49" crossorigin="anonymous"></script>
        <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/js/bootstrap.min.js" integrity="sha384-ChfqqxuZUCnJSK3+MXmPNIyE6ZbWh2IMqE241rYiqJxyMiZ6OW/JmZQ5stwEULTy" crossorigin="anonymous"></script>
    </body>
</html>

users/urls.py

import logging
from django.urls import path

from users import views

app_name = "users"
urlpatterns = [
    path("preferences/", views.preferences, name="preferences"),
]

users/views.py

from django.contrib.auth import get_user_model
from django.contrib.auth.decorators import login_required
from django.http import HttpResponse
from django.shortcuts import render
from django.views.generic import TemplateView

User = get_user_model()

@login_required
def preferences(request):
    return render(request, "users/preferences.html")

Toggle Preferences

Let's start with the messaging preferences. We will have two checkboxes that allow us to set or un-set the User.receive_email_messages and User.receive_sms_messages model fields. Additionally, we'll add an alert div to notify the user whether the process was successful or not, and we will make it disappear after 2 seconds using _hyperscript.

There are several ways to approach this. We could have a separate view and url for every checkbox we want to toggle. I have opted instead to have one view and url that handles all toggles. Depending on the value of the preference hidden form field, the view determines which preference was submitted.

Insert the following into the inner

<div class="custom-control custom-switch col-lg-3 mt-3 mb-1">
    <form method="POST">

        <input type="checkbox"
               class="form-check-input"
               {% if request.user.receive_email_messages == True %}checked{% endif %}
               name="set_value"
               id="set_email_value"
               hx-post="{% url 'users:toggle_preference' %}"
               hx-trigger="click"
               hx-target="#email_response">

        <label class="form-check-label" for="set_email_value">Receive Email Messages</label>
        <input type="hidden" name="preference" value="email_msg">
        {% csrf_token %}
    </form>
    <div id="email_response"></div>
</div>
<div class="custom-control custom-switch col-lg-3 mt-3 mb-2">
    <form method="POST">

        <input type="checkbox"
               class="form-check-input"
               {% if request.user.receive_sms_messages == True %}checked{% endif %}
               name="set_value"
               id="set_sms_value"
               hx-post="{% url 'users:toggle_preference' %}"
               hx-trigger="click"
               hx-target="#sms_response">

        <label class="form-check-label" for="set_sms_value">Receive SMS Messages</label>
        <input type="hidden" name="preference" value="sms_msg">
        {% csrf_token %}
    </form>
    <div id="sms_response"></div>
</div>

hx-post="{% url "users:toggle_preference" %}"
hx-trigger="click"
hx-target="#email_response"

@login_required
def toggle_preference(request):
    if request.method == "POST":
        user = request.user
        successful_toggle = False

        # Set/un-set email messaging preference
        if (request.POST.get("preference", None) == "email_msg"):
            if request.POST.get("set_value", None) is not None:
                user.receive_email_messages = True
                user.save()
                successful_toggle = True
            else:
                user.receive_email_messages = False
                user.save()
                successful_toggle = True

        # Set/un-set sms messaging preference
        if (request.POST.get("preference", None) == "sms_msg"):
            if request.POST.get("set_value", None) is not None:
                user.receive_sms_messages = True
                user.save()
                successful_toggle = True
            else:
                user.receive_sms_messages = False
                user.save()
                successful_toggle = True

        if successful_toggle:
            return HttpResponse(
                (
                    '<div _="on load wait 2s then remove me" class="alert alert-success alert-dismissible fade show" role="alert">'
                    "<strong>Success! Your preferences were updated.</strong>"
                    "</div>"
                ),
                status=200,
                content_type="text/html",
            )

    # If we did not successfully toggle one of the preferences, notify the user of the failure
    return HttpResponse(
        (
            '<div _="on load wait 2s then remove me" class="alert alert-warning alert-dismissible fade show" role="alert">'
            "<strong>Warning! Preferences were not updated. Notify the webmaster.</strong>"
            "</div>"
        ),
        status=200,
        content_type="text/html",
    )

import logging
from django.urls import path

from users import views

app_name = "users"
urlpatterns = [
    path("preferences/", views.preferences, name="preferences"),
    path("preferences/toggle_preference/", views.toggle_preference, name="toggle_preference"),
]

<div class="col-lg-6 mb-1">
    <form method="POST">
        <label class="form-label" for="order_notify">Order Notification Frequency</label>

        <select class="form-control"
                name="order_notify"
                id="order_notify"
                hx-post="{% url 'users:select_order_notification_freq' %}"
                hx-trigger="change"
                hx-target="#notification_response">

            <option value="NONE" {% if user.order_notification_freq == "NONE" %}selected{% endif %}>None</option>
            <option value="IMMEDIATE" {% if user.order_notification_freq == "IMMEDIATE" %}selected{% endif %}>Immediate</option>
            <option value="DAILY" {% if user.order_notification_freq == "DAILY" %}selected{% endif %}>Daily</option>
            <option value="WEEKLY" {% if user.order_notification_freq == "WEEKLY" %}selected{% endif %}>Weekly</option>
        </select>
        {% csrf_token %}
    </form>
    <div id="notification_response"></div>
</div>

@login_required
def select_order_notification_freq(request):
    if request.method == "POST":
        user = request.user
        order_notify = request.POST.get("order_notify", None)

        if order_notify is not None:
            if order_notify in User.NotificationChoices.values:
                user.order_notification_freq = order_notify
                user.save()
            else:
                return HttpResponse(
                    (
                        '<div _="on load wait 2s then remove me" class="alert alert-warning" role="alert">'
                        "<strong>Warning! Preferences were not updated. Notify the webmaster.</strong>"
                        "</div>"
                    ),
                    status=200,
                    content_type="text/html",
                )
        else:
            user.order_notification_freq = User.NotificationChoices.NONE
            user.save()

    return HttpResponse(
        (
            '<div _="on load wait 2s then remove me" class="alert alert-success" role="alert">'
            "<strong>Success! Preferences were updated.</strong>"
            "</div>"
        ),
        status=200,
        content_type="text/html",
    )

import logging
from django.urls import path

from users import views

app_name = "users"
urlpatterns = [
    path("preferences/", views.preferences, name="preferences"),
    path("preferences/toggle_preference/", views.toggle_preference, name="toggle_preference"),
    path("preferences/select_order_notification_freq/", views.select_order_notification_freq, name="select_order_notification_freq"),
]

Updated 10 Oct 2022

Sometimes it is useful to have a condensed version of highly detailed information.

This resource is intended mainly for folks who are regularly building out models, are comfortable with the concepts of django models, and want a consolidated listing of the majority of things available for models. I use this quite often, and it saves me a lot of time since I generally don't need to look up the full documentation. I can see at a glance what a particular field, Meta class option, QuerySet, etc should look like.

I've previously posted prior versions of this elsewhere, so you may have seen something similar, but this is the latest and most up-to-date version.

import uuid

from django.db import models
# Use the import below instead, if using GeoDjango fields
# from django.contrib.gis.db import models

from django.utils.translation import gettext_lazy as _

from django.contrib.postgres.fields import (
    ArrayField,
    CICharField,
    CIEmailField,
    CITextField,
    HStoreField,
    IntegerRangeField,
    BigIntegerRangeField,
    DecimalRangeField,
    DateTimeRangeField,
    DateRangeField,
)
from django.contrib.postgres import ExclusionConstraint


def file_directory_path(instance, filename):
    # file will be uploaded to MEDIA_ROOT/my_files/{id}/{year}/{month}/{filename}
    return f"my_files/{instance.id}/{timezone.now().date().strftime('%Y/%m')}/{filename}"

def create_rand_value(app_label, model_name, prefix=None, suffix_len=10):
    """
    Just an example function, used to demonstrate overriding save()
    It generates an easily readable, unique string
    """

    code = ""

    if prefix is not None:
        code = code.join(prefix).join("-")

    while True:
        code = code.join(random.SystemRandom().choice("23456789BCDFGHJKMNPQRSTVWXYZ") for _ in range(suffix_len))
        Model = apps.get_model(app_label=app_label, model_name=model_name)

        try:
            present = Model.objects.first()
        except Model.DoesNotExist:
            present = None

        if present is not None:
            if not Model.objects.filter(code=code).exists():
                return code

# https://docs.djangoproject.com/en/dev/topics/db/managers/#from-queryset
class MyModelQuerySet(models.QuerySet):
    """Used to return a QuerySet that has been filtered"""

    def expired_items(self):
        return self.filter(expired__isnull=True)

class MyModelManager(models.Manager):
    """Used for table-level methods that do NOT return QuerySet"""
    def delete_expired_items(self):
        self.expired_items().delete()

    def get_queryset(self):
        # Limit every query used with this QuerySet / Manager to critical Items
        return super().get_queryset().filter(critical=True)

class MyModel(models.Model):
    """Comment about this model"""

    class CompanyType(models.TextChoices):
        PUBLIC_LIMITED_COMPANY = 'PLC', _('Public Limited Company')
        PRIVATE_COMPANY_LIMITED = 'LTD', _('Private Company limited by shares')
        LIMITED_LIABILITY_PARTNERSHIP = 'LLP', _('Limited Liability Partnership')
        __empty__ = _('(Unknown)')

    # Basic Model Fields
    # https://docs.djangoproject.com/en/dev/ref/models/fields/
    boolean_field = models.BooleanField(_("Boolean"), default=False)
    char_field = models.CharField(_("Character"), max_length=100, blank=True)
    char_field_choice = models.CharField(_("Character Choices"), choices=CompanyType.choices, default=CompanyType.__empty__, max_length=100, blank=True)
    date_field = models.DateField(_("Date"), null=True, blank=True)
    datetime_field = models.DateTimeField(_("DateTime"), null=True, blank=True)
    decimal_field = models.DecimalField(_("Decimal"), max_digits=5, decimal_places=2, null=True)
    duration_field = models.DurationField(_("Duration"), )
    email_field = models.EmailField(_("Email"), max_length=254, blank=True)
    file_field = models.FileField(_("File"), upload_to=file_directory_path, max_length=100)
    float_field = models.FloatField(_("Float"), null=True)
    generic_ip_address_field = models.GenericIPAddressField(_("Generic IP"), protocol='both', unpack_ipv4=False, null=True) # 'both', 'IPv4' or 'IPv6'
    image_field = models.ImageField(_("Image"), upload_to=file_directory_path, height_field=None, width_field=None, max_length=100)
    integer_field = models.IntegerField(_("Number"), null=True)
    json_field = models.JSONField(_("JSONField"), default=dict)
    pos_int_field = models.PositiveIntegerField(_("Positive Integer"), )
    pos_small_int_field = models.PositiveSmallIntegerField(_("Positive Small Integer"), )
    slug_field = models.SlugFiels(_("Slug"), max_length=50, blank=True)
    small_int_field = models.SmallIntegerField(_("Small Integer"), )
    text_field = models.TextField(_("Text"), blank=True)
    time_field = models.TimeField(_("Time"), null=True, blank=True)
    url_field = models.URLField(_("URL"), max_length=200,)
    uuid_field = models.UUIDField(_("UUID"), default=uuid.uuid4)

    # Relationship Fields
    # https://docs.djangoproject.com/en/dev/ref/models/fields/#module-django.db.models.fields.related
    oto = models.OneToOneField(AA, on_delete=models.CASCADE, null=True, blank=True)
    fk = models.ForeignKey(BB, on_delete=models.CASCADE, related_name="xxs", null=True, blank=True)
    mtm = models.ManyToManyField(CC, blank=True)

    # Automatic date fields
    # https://docs.djangoproject.com/en/dev/ref/models/fields/#datefield
    created = models.DateTimeField(_("DateTime Created"), auto_now_add=True, help_text=_("When this item was created"))
    modified = models.DateTimeField(_("DateTime Modified"), auto_now=True, help_text=_("When this item last updated"))

    # Postgres-specific Range Fields
    # https://docs.djangoproject.com/en/dev/ref/contrib/postgres/fields/
    integer_range_field = IntegerRangeField(_("IntegerRange"))
    big_integer_range_field = BigIntegerRangeField(_("BigIntegerRange"))
    decimal_range_field = DecimalRangeField(_("DecimalRange"))
    date_time_range_field = DateTimeRangeField(_("DateTimeRange"))
    date_range_field = DateRangeField(_("DateRange"))

    # GeoDjango Fields (for GIS projects)
    # https://docs.djangoproject.com/en/dev/ref/contrib/gis/model-api/
    point = models.PointField(srid=4326)
    multi_point = models.MultiPointField()
    polygon = models.PolygonField()
    multi_polygon = models.MultiPolygonField()
    linestring = models.LineStringField()
    multi_linestring = models.MultiLineStringField()
    geometry_collection = models.GeometryCollectionField()
    raster = models.RasterField()

    # Example Fields to demonstrate Manager, QuerySet, and Model methods below
    critical = models.BooleanField(_("Critical"), default=False)
    expired = models.DateTimeField(_("Expired"), null=True, blank=True)

    # Uses the `from_queryset` method to combine Manager & QuerySet
    # https://docs.djangoproject.com/en/4.1/topics/db/managers/#from-queryset
    CombinedMyModelManager = MyModelManager.from_queryset(MyModelQuerySet)
    objects = CombinedMyModelManager()

    # Optional additional manager with no query filter limitations
    unscoped = models.Manager()

    class Meta:
        # https://docs.djangoproject.com/en/dev/ref/models/options/
        verbose_name = _("My Model")
        verbose_name_plural = _("My Models")

        # abstract = True  # https://docs.djangoproject.com/en/dev/topics/db/models/#abstract-base-classes
        # proxy = True  # https://docs.djangoproject.com/en/dev/topics/db/models/#proxy-models

        db_table = 'my_model'  # https://docs.djangoproject.com/en/4.1/ref/models/options/#db-table

        # Specifies the default field(s) to use in your model Manager's latest() and earliest() methods
        get_latest_by = ['-datetime_field']

        # The default ordering for the object, for use when obtaining lists of objects
        ordering = ['-datetime_field']

        # These are Deprecated. Recommended to use Meta  UniqueConstraint and Indexes
        unique_together = [
            ['char_field', 'slug_field']
        ]
        index_together = [
            ["created", "char_field"],
        ]

        # https://docs.djangoproject.com/en/dev/ref/models/indexes/
        indexes = [
            models.Index(fields=['char_field', 'text_field']),
            models.Index(fields=['url_field'], name='url_field_idx'),
        ]

        constraints = [
            # https://docs.djangoproject.com/en/dev/ref/models/constraints/
            # Check that new/updated instances have an `integer_field` with value of 18 or greater
            models.CheckConstraint(check=models.Q(integer_field__gte=18), name='integer_gte_18'),
            # Prevent more than once instance sharing the same `created` and `slug_field` values
            models.UniqueConstraint(fields=['created', 'slug_field'], name='unique_slug_created'),
            # Prevent more than once instance where the `fk` field is the same and the Company Type
            #    is `LIMITED_LIABILITY_PARTNERSHIP` 
            models.UniqueConstraint(
                fields=['fk'],
                condition=Q(char_field_choice=CompanyType.LIMITED_LIABILITY_PARTNERSHIP),
                name='unique_llc_for_fk'
            ),
            # https://docs.djangoproject.com/en/4.1/ref/contrib/postgres/constraints/
            # Exclude new instances of this model for the same `fk` field where there are overlapping
            #    `integer_range_field` range values when the `expired` field is `False`
            ExclusionConstraint(
                name='exclude_overlapping_reservations',
                expressions=[
                    ('integer_range_field', RangeOperators.OVERLAPS),
                    ('fk', RangeOperators.EQUAL),
                ],
                condition=Q(expired__isnull=True),
            ),
        ]

    def __str__(self):
        # https://docs.djangoproject.com/en/dev/ref/models/instances/#str
        return f'{self.char_field} {self.char_field}'

    def save(self, *args, **kwargs):
        # https://docs.djangoproject.com/en/dev/topics/db/models/#overriding-model-methods
        # Here we create a random value and assign to the `slug_field` before actually saving
        if not self.pk: # this will ensure that the object is new
            self.slug_field = create_rand_value(
                app_label=self._meta.app_label,
                model_name=self.__class__.__name__,
                prefix="",
                suffix_len=10
            )
        super().save(*args, **kwargs)

    def get_absolute_url(self):
        # https://docs.djangoproject.com/en/dev/ref/models/instances/#get-absolute-url
        from django.urls import reverse
        return reverse('people.views.details', args=[str(self.id)])

    @property
    def char_slug(self):
        # https://docs.djangoproject.com/en/dev/glossary/#term-property
        return self.char_field.lower().replace(' ','-')

    def expire_item(self):
        # https://docs.djangoproject.com/en/dev/topics/db/models/#model-methods
        # Set the value of `expired` to `timezone.now()` for the current instance
        self.expired = timezone.now()
        self.save()

Example usage of the QuerySet, Manager, and Model methods:

# Returns all critical Items
Item.objects.all()

# Returns critical Items that are expired
Item.objects.expired_items()

# Expire a single Item
item = Item.objects.first()
item.expire_item()

# Deletes any critical Items that are expired
Item.objects.delete_expired_items()

Have any additional tips/recommendations? Share them. I love to refine this over time.