fidzu : django

🔗 Links

• Foxley Talent
• Foxley Talent YouTube
• People or Code show on YouTube and Spotify

📚 Books

• The Infinity Machine by Sebastian Mallaby
• The Concept of Mind by Gilbert Ryle [Carlton]
• The Go-Giver by Bob Burg and Jon Mann

📦 Projects

• FarhanAliRaza/prongs - run just the tests you edited
• justinmayer/django-benchmark - Django performance benchmark profiler

🎥 YouTube

• YouTube Channel: @djangochat

14 Oct 2026 3:00pm GMT

I first wrote about this idea in day 287 where I framed it under the name of django.contrib.beginners. The idea (as a quick reminder) is that if I wondered if we could have a package that added extra warnings or safeguards for beginners that meant they would not make common foot-gun mistakes with Django. I've since expanded on the idea a bit and formalized two concepts that I've called Guardrails and Scaffolds.

Guardrails being those warnings, those limiters that are stricter defaults that prevent beginners from committing those common mistakes when starting with Django that we know to avoid. They can be opinionated, and we can choose whether to turn them on and off, and silence them, or that kind of thing.

Scaffolds on that other, which are pieces of code that at times prevent the rabbit hole or make things easy to get started. A really good example of this is that django.contrib.auth, doesn't ship with a user registration view & url because there are an infinite combinations of what you could do with registration in a project. But that often causes a new developer to jump down the rabbit hole of the auth documentation and become confused. And so the scaffold could be a simple register view and URL that gets included. Let's be clear, these scaffolds are not whole projects, but starting points for specific points in a project.

One key concept for the whole package is that it's supposed to be outgrown. It's something you start using, and then as you hit those walls intentionally and you understand why that warning exists and why you need to disable a check or move code into your project, it's at that point that you start to uninstall the package and install alternatives e.g. take the register view, you install allauth or django-registration as more complete solutions.

However, the core question I've come to recently is whether I could build this package (and I fully intend to build this package!) as I see it, as a valuable aid to the community. But I wonder, due to its nature, once the core infrastructure of the package exists, or even building out the core infrastructure of the package, I wonder if this could be built as a group or as a community or as a smaller team within the community. Rather than a solo contributor maintainer, the default being starting as a group, as a group of people, rather than, and this happens before a line of code is committed. I'm a solo contributor, so I'm just wondering how do I go from an idea with some design documentation to getting people on board, to code being written, committed, reviewed and published.

I see two parts to contribution in this package. First is to build out and maintain the core infrastructure. Second, due to the nature of the package of there being a long potential list of smaller contributions in the forms of new guardrails and new scaffolds. How do I garner those contributions, which then may elevate people up into maintaining the first set, which is the core code that enables them to be used. I don't have any solutions to this. I'm going to start building it when I have some free time (or some free agent time). But I welcome your thoughts and opinions as a community as to what my first or next step should be, and if you're interested, that could be get in touch. But what would that next step be? And I'm thinking partly from asking people to be involved, but also do we have a Discord channel, or server, where we start collaborating on this? How do we create that shared collaboration environment in a disparate community that's physically disparate and can be on desperate online because not everybody hangs out in the same place. I would be curious to hear people's thoughts. Thanks!

P.S. One final point on the package itself, I do intend this to also allow as a place for small changes to be experimented with that could be candidates for core changes in core Django, but don't perhaps warrant a full package in themselves if they are so small and fall with the concepts of the guardrails and scaffolds.

14 Oct 2026 5:00am GMT

String.prototype.replace() with a global regular expression and a function has iterated over the interesting parts of a string since 1999, long before array extras like forEach() and filter(). It is rarely the best tool today, but it is still in a lot of code, for historical reasons and for a certain technical beauty. Let's see how it works, what it is good for, and what it costs, so that a replace() whose result goes unused makes sense when we meet it.

13 Oct 2026 10:00am GMT