GitHub Copilot

When working on external integrations, we often implement basic error handling. Most of the time, we just use resp.raise_for_status() and leave it for your future self to handle. Quite often, we don’t handle errors because we genuinely don’t know how the external system will behave and what types of errors to expect from it. Indeed, it can be...

To KISS or not to KISS I remember how, several years ago at Doist, we talked about integrating with external services, like email providers or analytics tools. The question was whether to use a simple function or an abstraction layer. We ended up with having two groups. KISSers. The first one advocated for following the KISS principle and calling...

In the update API endpoints that allow for partial updates (aka PATCH updates), we need to know if a model field has been explicitly set by the caller. Usually, we use None to indicate an unset value. But if None is also a valid value, how can we distinguish between None being explicitly set and None meaning “unset”? For example, let’s say we...

How to provide coding guidelines for GitHub Copilot and influence GitHub Copilot suggestions. In my project, I use naming conventions for models. I have different suffixes for different model types, and I subclass my models from various base classes. It would be awesome if I could let GitHub Copilot know about my conventions, so it can suggest...

Services are a missing layer in the Django architecture. Django does not provide guidance on where to place complex logic for modifying multiple models, but many development teams have chosen to follow the clean architecture pattern and introduce a service layer. This layer acts as a middleman between interfaces such as views or API endpoints,...