5 design patterns used in my new habit tracker app

Developer Daniel Roy Greenfeld built commitgraph, a Django + HTMX habit tracker app, and shared five design patterns from its development, including pure functions for streak logic, a 7-bit integer to represent weekly schedules, and use of Python's calendar module for month grids. The patterns aim to make code testable and maintainable, with examples such as a `longest_streak` function and a `shade` helper for calendar cells.

5 design patterns used in my new habit tracker app Shipping fast with AI but don't fully trust the code? I help developers 1:1 turn AI-built apps into something they understand and own. How it works → /coaching/ own-project There are plenty of habit trackers, but I wanted to build mine with constraints, a calendar view and habit streaks. So I built commitgraph https://commitgraph.app : a small Django + HTMX app. Here are five Python design and testing patterns from building it. 1. Pure functions Streak counting and calendar shading live in two plain modules. They take dates and return values. And work independently from Django, the database, or the user. That makes them easy to test. python streaks.py from datetime import date, timedelta def longest streak dates: list date , is due=lambda : True - int: days = set dates if not days: return 0 best = run = 0 cur, last = min days , max days while cur <= last: if is due cur : run = run + 1 if cur in days else 0 best = max best, run cur += timedelta days=1 return best Thanks to this boundary the streak logic is easy to unit test; no database nor user are needed. Another example: each calendar cell gets a shade from how much you completed that day. It is tempting to compute that in the template. Instead, I turned it into a helper function: php calendars.py def shade completed: int, active: int - str: if active == 0 or completed == 0: return "bg- var --g0 text-muted" frac = completed / active if frac = 1: return "bg- a84420 text-white" if frac = 0.6: return "bg- d97a4e text- 3a1c0e " return "bg- f6ddc9 text- 3a1c0e " assert shade 5, 5 .endswith "text-white" is again easy to test and it's reusable in different parts of the app. 2. A schedule is a 7-bit integer Claude suggested this nifty approach: a habit runs on a subset of weekdays. That is seven yes/no answers, which fit cleanly into a single 7-bit integer. class Habit models.Model : ALL DAYS = 0b1111111 every day WEEKDAYS = 0b0011111 Mon-Fri weekday 0-4 due days = models.PositiveSmallIntegerField default=ALL DAYS def is due on self, day: date - bool: return bool self.due days & 1 << day.weekday No join table, no seven boolean columns. Adding "weekends only" is a new constant, not a migration. The is due on one-liner treats due days as a 7-bit binary calendar , one switch per weekday, ordered right-to-left from Monday 0 to Sunday 6 . day.weekday gives 0-6 Mon-Sun . 1 << day.weekday puts a single bit at that day's position, and & self.due days is non-zero only if the habit is scheduled that day. bool turns that into True / False . 3. Let the standard library build the month grid A month grid can be tricky: leading blanks, trailing blanks, weeks that straddle two months. Python's calendar module already knows all of it. python import calendar for week in calendar.Calendar firstweekday=0 .monthdatescalendar year, month : for day in week: if day.month = month: ... a padding cell from the previous or next month monthdatescalendar returns real date objects, one clean list of weeks; no need to write any logic around how many days April has. 4. A query vocabulary on the model "Active habits" and "habits active on a given day" show up everywhere. Rather than repeating the filters in every view, I named them on a custom QuerySet so they are chainable: python class HabitQuerySet models.QuerySet : def active self : return self.filter archived at isnull=True def active on self, day: date : return self.filter Q start date lte=day & Q archived at isnull=True | Q archived at date gte=day class Habit models.Model : objects = HabitQuerySet.as manager Now Habit.objects.filter user=u .active is very readable and the relatively complex Q expressions are abstracted into the model. 5. "Done and due" is set algebra The Today screen needs habits that are due today and not yet checked off. Two sets and one operator. due ids = {h.id for h in habits} done ids = set HabitCompletion.objects .filter habit user=user, date=day .values list "habit id", flat=True & due ids The intersection drops any completion for a habit that is not due today, so a spurious record can't inflate the count. The logic is the math, not a nest of if statements. Here is a REPL snippet that demonstrates how set intersection & filters down to only the elements present in both sets: due ids = {10, 11, 12, 13} Habits scheduled for today completed ids = {11, 13, 99} Logged completions 99 is a stray record The '&' operator keeps ONLY IDs present in BOTH sets done today = completed ids & due ids print done today 10, 12 and 99 are dropped because they are not in both sets {11, 13} I have also seen this used in RBAC logic to cross-check user roles with endpoint permissions. The intersection of the two sets is the effective permissions a user has. Keep reading - Build the Simplest Thing That Works /blog/build-the-simplest-thing-that-works/ - Unsubscribe links without a login: Django signing /blog/unsubscribe-without-login-django-signing/ - Learning Rust Made Me a Better Python Developer /blog/rust-made-me-a-better-python-developer/ The thread running through all five patterns: when a piece of logic doesn't strictly need the database or a dependency, stick to this boundary. Fetch your primitive values, do the math in plain Python, so it's more testable in isolation. What is one function in your Django views that would be much easier to trust and test if you decoupled it?