Welcome

Reading through some common Django books and tutorials, you will come upon the advice to encapsulate your ORM-related business logic inside custom model managers and custom querysets. In this article, I will try to persuade you no to. Or at the very least, to persuade you that the bar should be very high for introducing those constructs. What are custom managers / querysets? TODO The stated benefits: DRY principle High level logic is clear Codifies field semantics of a model – you can see how to interpret certain fields My beef with them Beef #1: Mixed semantics If you app grows beyond the starting phase, you model will certainly be used in multiple apps. E.g. if you have a content taxonomy model, it might be used for recommending similar content, and it might be used for determining user’s interests. ...

Having no documentation is often less harmful than having inaccurate documentation. Like code, documentation degrades over time. What was once accurate may now be obsolete. And practices we once ignored might now be part of our daily workflow. Unless maintaining documentation is an intentional process, it will rot, maybe beyond saving. In this article I’ll outline a few guidelines that worked well for me in the past for keeping the developer documentation usable. They’re certainly not universal, but they are a good starting point for a small team of experienced developers. We’ll skip the philosophical debates and focus on real-world practices that work for small, fast-moving engineering teams - the aim is to get the most value with the least effort. Documentation doesn’t pay the bills. ...

What’s CSRF? Cross site request forgery is a type of attack where a malicious website tricks a user into performing actions on another site where they’re authenticated. This is usually done by embedding a form in the malicious site, and submitting it to the target site. An example of this would be a card game website where, when you hit the “Play” button, it sends a POST request to another site with the payload to change your login email address to the attacker’s. Since you’re logged in to the target site, the request goes through and you lose access to your account. ...

Every engineer that loves Django and has a blog has at least one of these posts. Django’s ORM is excellent, but given enough time it’s easy for approaches that weren’t mistakes to grow into mistakes This is a great thing, because it usually means your company didn’t go bankrupt, you’re still here and can fix things, and the company is doing well because the scale increased (hopefully your compensation as well). ...

@property decorator is an excellent way to reduce the readability of Python code. It obfuscates a perfectly good function call and tricks readers into thinking they’re performing a regular attribute access or assignment. Unless there’s a really good and explicit reason to do this, don’t. List of Good and Explicit Reasons: Refactoring That’s pretty much it. If you need to turn something that (rightfully so) started out as a simple attribute, but with time accrued some more complex logic, @property is a good way to gracefully transition from attributes to function calls. ...

Instead of def do_something(a, b, c): return res_fn( fn(a, b), fn(b), c ) I do: def do_something(a, b, c): inter_1 = fn(a, b) inter_2 = fn(b) result = res_fn(inter_1, inter_2, c) return result The first version is much shorter, and when formatted properly, equally readable. But the reason I prefer the second approach is because all intermediate steps are saved to local variables. Exception tracking tools like Sentry, and even Django’s error page that pops up when DEBUG=True is set, capture the local context. On top of that, if you ever have to step through the function with a debugger, you can see the exact return value before stepping out from the function. This is the reason why I even save the final result in a local variable, just before returning it. ...