(All tags.)
Hitting “refresh” to see your changes is an instinct many web developers develop. But it’s a small waste of time that adds up to many hours per year spent waiting. It’s a sub-optimal development experience (DX).
Developer Experience (DX) is a catch-all term for anything that can improve your development workflow. Such improvements can help you write better code, faster, with fewer bugs.
functools.partial() in DjangoI remain convinced that Python’s functools.partial() is underappreciated. Following my previous post, here are three more ways to use partial() with Django.
Django 4.0 had its first alpha release last week and the final release should be out in December. It contains an abundance of new features, which you can check out in the release notes. In this post we’ll look at the changes to testing in a bit more depth.
Django deprecates a small list of features with every feature release, requiring us to update our projects, which can be monotonous. Today I’m announcing a new tool I’ve created, django-upgrade, that automates some of this drudgery for us all.
I released my book “Speed Up Your Django Tests” over a year ago, in May 2020. Since then, we’ve seen two major Django releases, including a whole bunch of test-related changes, some of which I worked on as part of the book.
A “magic number” is the anti-pattern of using a number directly rather than storing it in a descriptive variable name. In web code HTTP status codes are often used as magic numbers, perhaps because web developers memorize common codes such as 200 and 404. In Python, we can avoid such magic with descriptive references from the standard library’s http.HTTPStatus enum.
I released my book Speed Up your Django Tests (SUYDT) just over a year ago, on the 18th May. It’s had a great reception, with 379 customers so far, many writing in to say how it has improved their test suites’ performance and readability.
A common way to receive data in a web application is with a webhook. The external system pushes data to yours with an HTTP request.
Another way to use database constraints via Django’s CheckConstraint class.
functools.partial() in DjangoPython’s functools.partial is a great tool that I feel is underused.
Google has started rolling out FLoC, currently to 0.5% of Chrome users, and some sites are already disabling it. In this post we’ll cover what FLoC is, who’s disabling it, why, and how to do so on a Django site.
Here are three new security headers on the block:
heroicons is a free SVG icon set for your websites, from the creators of tailwindcss. SVG icons are great - they’re small, they sit inline in your HTML, and you can scaled and colour them with plain HTML and CSS. And heroicons is a great icon set - minimal, clear, and consistent.
I created django-feature-policy in 2018 allow Django projects to control the draft security header Feature-Policy. Feature-Policy allows your site to restrict which origins can use some sensitive browser features, such as the the payments API or access to the webcam. This is valuable if you’re using any third party JavaScript. Whether such JavaScript comes from npm or an external script tag, you can protect against it doing some bad things with your users.
TestCase from using setUp() to setUpTestData()Django’s TestCase class provides the setUpTestData() hook for creating your test data. It is faster than using the unittest setUp() hook because it creates the test data only once per test case, rather than per test.
Another way to use Django’s CheckConstraint class to ensure your data is valid. Based on my answer to a question on the Django forum.
IPython is an improved Python shell for interactive use. It has many great features such as syntax highlighting, autocomplete, and powerful “magic commands”. I love it, use it on every project, and use the IPython prompt for examples on my blog.
It’s now a long-running tradition that each Django release has an associated “code word”. This is used by the release manager in the announcement blog post to describe the list of features coming in the next version.
Django 3.2 had its first alpha release a couple of weeks ago and the final release will be out in April. It contains a mezcla of new features, which you can check out in the release notes. This post focuses on the changes to testing, a few of which you can get on earlier Django versions with backport packages.
Yet another use case for creating a database constraint with Django’s CheckConstraint class.
Here’s another use case for creating a database constraint with Django’s CheckConstraint class.
I recently optimized a client project’s test suite, and in the process found a test whose runtime had crept up ever since it had been written. The problematic test exercised an import process from a fixed past date until the current day. The test’s runtime therefore grew every day, until it reached over a minute.
For my new Django project, DB Buddy, I’m using CloudFlare as my CDN. It has a bunch of useful features that would otherwise take extra work, such as DDoS protection, HTML minification, and analytics.
A client project recently was suffering from an N+1 queries problem in a complicated Django admin page. Many measures had already been taken to prevent N+1 queries, such as use of django-auto-prefetch and some manually tuned select_related() / prefetch_related() calls. The remaining N+1 in question was a bit resistant to those methods because it came through several layers of admin code and many-to-many fields, making it harder than normal to find the place to modify the QuerySet construction.