I had a similar stance on this until I went through macOS -> linux with i3 -> back to macOS transition. i3 window and workspace operations on a maxed-out Dell XPS were truly instantaneous, and after moving back to macOS, there is no way to unsee the slugishness of the native window operations.
I'm using Aerospace at the moment, and it gets pretty close, but still isn't as nice as i3.
I don't really understand the captcha hate, it's table stakes for any public-facing form. You need to pick a point on the "Ease of signup" vs. "Security" curve, and email signup + captcha seems to be the sweet spot.
I haven't seen any proof that the big ones (Google, CF) can be easily and automatically bypassed, and would love to learn more if someone has evidence to the contrary.
A couple of years ago I had to evaluate A/B test and feature flag providers, and even then when they were a young company fresh out of YC, GrowthBook stood out. Bayesian methods, bring your own storage, and self-hosting instead of "Contact us for pricing" made them the go-to choice. I'm glad they're doing well.
Yeah, that Cursor blog post is a bit iffy since they just brush over the "ripgrep is slow on large monorepos", move on to techniques they used, and then completely ignore the fact that you have to build and maintain the index.
On a mid-size codebase, I fzf- and rg-ed through the code almost instantly, while watching my coworker's computer slow down to a crawl when Pycharm started reindexing the project.
Product engineer with 10 years of experience. I love Python and Django (8 years and counting), have worked
extensively with Celery and Postgres, have some React/Typescript experience, as well as some exposure to Docker, GitHub
Actions and MLOps workflows.
I am comfortable owning products end to end: backend architecture, data models, async workflows, monitoring, and
collaborating with business, product, and ops teams. Interested in roles that value ownership and strong engineering fundamentals.
This is not specific to Django, but to any project using a database. Here's a list of a couple quite useful resources I used when we had to address this:
Generally it's also advisable to set a statement timeout for migrations otherwise you can end up with unintended downtime -- ALTER TABLE operations very often require ACCESS EXCLUSIVE lock, and if you're migrating a table that already has an e.g. very long SELECT operation from a background task on it, all other SELECTs will queue up behind the migration and cause request timeouts.
There are some cases you can work around this limitation by manually composing operations that require less strict locks, but in our case, it was much simpler to just make sure all Celery workers were stopped during migrations.
After working with Django for 8 years, I find it hard to move on to anything else. It's just the right amount of magic, and just the right amount of flexibility, and it's just such a joy to work with.
Re: Django is OK for simple CRUD, but falls apart on anything complex - this is just untrue. I have worked in a company with a $500M valuation that is backed by a Django monolith. Reporting, recommender systems, file ingestion pipelines, automatic file tagging with LLM agents -- everything lives inside Django apps and interconnects beautifully. Just because it's a Django app doesn't mean you cannot use other libraries and do other stuff besides basic HTTP request processing.
Recently I had the misfortune of doing a contract on a classic SPA project with Flask and sqlalchemy on the backend and React on the frontend, and the amount of code necessary to add a couple of fields to a form is boggling.
This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college?
What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team?
I understand we can talk and exchange our concrete life experiences, same as I would talk to and listen to any other person, but the word "coaching" implies one party is superior to the other in one very concrete area.
Well they still claim it is impossible to connect different masked emails together. If you as a sender can reliably determine the target email
address, then that claim
is untrue as well.
I have created a ticket with the Fastmail support asking them more details about the vulnerability you mention in your thread, I’m curious to see their response.
Celery is the worst background task framework, except for all the others.
There are bugs and issues, but because so many people are using it, you’re rarely the first to stumble upon a problem. We processed double-digit millions of messages daily with Celery + RabbitMQ without major obstacles. Regardless of what people say, it should be your first go-to.
Very relatable to a recent interview experience I had with a popular freelance platform for the backend developer position.
I never worked at a FAANG-ish company, and in the course of my 10-year career I spent most of my efforts on stopping the organizations from building the wrong thing in the first place, not on "making things scaleable" from the get-go. My view is that if you have product-market fit, you can throw money on the problem for a very, very long time and do just fine, so everyone in the org should focus on achieving PMF as soon as possible.
The question of "How would you scale a Django service to 10M requests per day" came up, and my answer to just scale components vertically and purchase stronger servers obviously was not satisfactory.
Type hints in Python add a great amount of visual noise to the code, and I actively avoid them wherever possible. If static typing is a must, use a language where static typing is not an afterthought, and let Python be Python.