Welcome

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. ...