Django 3.2 is just around the corner and it’s packed with new features. Django versions are usually not that exciting (it’s a good thing!), but this time many features were added to the ORM, so I find it especially interesting!
Every few months we get an alert from our database monitoring to warn us that we are about to run out of space. Usually we just provision more storage and forget about it, but this time we were under quarantine, and the system in question was under less load than…
If you work with databases you are probably familiar with B-Tree indexes. They are used to enforce unique and primary-key constraints, and are the default index type in most database engines. If you work with text, geography or other complex types in PostgreSQL, you may have dipped your toes into…
Many developers think that having a critical bug in their code is the worst thing that can happen. Well, there is something much worse than that: Having a critical bug in your code and not knowing about it!
To make sure I get notified about critical bugs as soon as possible, I started looking for ways to find anomalies in my data. I quickly found that information about these subjects tend to get very complicated, and involve a lot of ad-hoc tools and dependencies.
I’m not a statistician and not a data scientist, I’m just a developer. Before I introduce dependencies into my system I make sure I really can’t do without them. So, using some high school level statistics and a fair knowledge of SQL, I implemented a simple anomaly detection system that works.
In my latest article for RealPython I share three ways to tackle one of the most challenging tasks involving Django migrations: moving a model from one Django app to another.
The article covers some exotic migration operations and many of the built-in migration CLI commands such sqlmigrate, showmigrations and sqlsequencereset. In the article I also demonstrate important migrations concepts such as reversible migrations, migration plans and introspection.
It can be very challenging to test a system that rely heavily on a third party service such as Twilio. In this article, I show how to organize your code in a way that would isolate your bushiness logic and make it easier to test separately. The article demonstrate useful testing patterns using Django’s RequestFactory, unittest.mock, Pytest fixtures, build-in django-pytest and many more.
The source code for this article and the previous one can be found here.
Last year my team and I worked on a very challenging IVR system. After almost a year in production and thousands of processed transactions, I teamed up with the great people over at the Twilio blog to write an introductory tutorial for developing IVR systems using Django and Twilio IVR.
Aside from “making your server talk” and diving into the cool speech features, I found the most challenging part working on IVR is designing the views. Unlike APIs and Forms, IVR is very limited in the type of input it takes (DTMF tones, transcribed speech), and the amount of data it can communicate and process is limited.