Docker is an invaluable tool that makes things like setting up your local development environment, continuous integration, and deployment a breeze. Docker is good to set up early on for any application, but it is never too late. With the help of Docker Compose, we are going to set up a Django application to install and deploy itself on any machine with only one command.Continue reading How to Dockerize Django and Postgres
Marginal gains are minor improvements that are relatively easy to make. A single marginal gain does not have a meaningful effect, but several can aggregate into significant progress. I first read about this concept in James Clear’s Atomic Habits, and was inspired to apply this philosophy to software development. For a better understanding of what marginal gains are, read this excerpt from the book.
The most worthwhile marginal gains are the ones that take a little effort to implement and no (or almost no) effort to maintain. I like to think of these as small upfront time investments for guaranteed, long-term returns. This is especially relevant to software development. Marginal gains can be earned by making common tasks easier, altering your workflow, or even simply shifting your mindset.Continue reading Marginal Gain #1: Make Common Tasks Easy
The combination of Django and the Django REST framework is powerful. With just three classes (a model, a viewset, and a serializer), you can have a basic CRUD endpoint up and running. Although it is easy to get set up, it is also easy to end up with a view that makes hundreds of unnecessary database queries. As database queries are relatively slow, we want to avoid them as much as possible. In order to do this, we will follow Tip #4 from my Django ORM Optimization Tips post:
Continue reading How to Optimize Your Django REST Viewsets
prefetch_related()when you will need foreign-key/reverse related objects.
Functions are the building blocks of many applications. Most software developers, current or aspiring, have some experience writing functions. Everyone writes them differently, and there are different approaches to getting the most out of your functions. Bad functions are hard to maintain, more unstable, and lack reusability. Writing better functions will make your application more stable, easier to read and maintain, and make future development easier.Continue reading Write Better Functions
Django views are an essential part of most Django applications. They carry out user requests to perform actions and return different types of data. Django provides two distinct methods for creating a view: function-based and class-based. Many discussions have been had over the benefits of using one over the other. I believe that the benefits of using one or the other is highly circumstantial. In this post, I will outline the guidelines I use to determine which option is better for different circumstances.
When dealing with models with nested relationships, it may initially make sense to serialize them in a nested format. However, you may soon discover that this has a couple of potential issues.
- This structure can result in a lot of duplication in the serialized data, especially for many-to-many relationships.
- Since those objects are nested, you don’t have them all in one place for easy referencing or updating. Working around this requires tedious iteration and transformation.
How are houses built? Do you finish the bathroom, with tiled floors, a sink, and even a shower curtain, before you even start on the master bedroom? Of course not. You prepare the site, construct framing for the entire house, finish the exterior, install infrastructure (plumbing, electrical, insulation, etc.), and continue to add detail and flesh out different parts of the house until it is complete.
In this post, I will make the case that this is not only the right way to build a house, but the right way to write software as well. Like a house, software is composed of different parts or components. These components need to come together as soon as possible to facilitate good design, prevent unnecessary rework, and enable a steady, stable progression.
When it comes to optimizing an ORM, your greatest weapon is your understanding of how your ORM works under the hood (at least at a high level). This makes understanding all of the rules and guidelines for creating a speedy application much easier. Therefore, I highly recommend reading through the Django docs on the subject at least once. My goal for this post is to condense these tips and tricks into an easily-referenceable compilation, as well as adding some of my own. Also check out my Django ORM Optimization cheat sheet for an even more condensed version.
If you are trying to figure out how to create a case-insensitive field for your Django models, there are several ways to go about it. If you don’t care about preserving the actual mixed-case version, you can simply convert your strings to lowercase before they get saved to the model. If you are using PostgreSQL and don’t mind a database-specific solution, you can use CITextField or similar. Otherwise, read on.
Some solutions online involve adding or customizing manager or queryset functions. While this may work okay at a basic level, it isn’t a complete solution, and doesn’t actually prevent you from inserting a duplicate case-insensitive value.
I have discovered a solution that is clean, enforces case-insensitive uniqueness, and works for all Django lookups that have case-insensitive versions.