This is so important if you want to avoid incredibly gnarly race conditions. In particular for us: jobs being run even before the transaction has been fully committed to the database.
We utilise a decorator for our job addition to external queues, such that the function that does the addition gets attached to Django's "on transaction commit" signal and thus don't actually get run until the outer database transaction for that request has been committed.
Dependabot is based on releases from the various package repositories; running of main is pre-release - hence they’re probably using GitHub Actions to pin their Gemfile-defined Rails version to a commit hash.
I remember working with SagePay as a payment provider back in 2008 (before we knew of Stripe!) and finding it interesting that card address validation was only done on the numbers in a full address.
For example, from "20 Windsor Road, London, SE1 6JH" it would extract 2016 and validate that against the banks details.
I thought that was quite a smart way as UK addresses can come in all forms, shapes and sizes (as the post shows) – but the minimal bits required to be correct are indeed the numbers as all postcodes have them and an incorrect number would mean a incorrect postcode.
Edit: the funny bit was that they made you work this out and send it along with the request rather than just handling it internally :)
This seems to me like a combination of multiple foot-guns, first being the Docker one - followed by the fact Mongo was not configured to authenticate the connection.
Heroku by default run PostgreSQL open to the world (which is problematic for other reasons) but they get away with it by relying on PG's decent authentication.
My default is to prefer to build systems with multiple layers of security, such that there is no reliance on a single issue like this.
Yes! And it’s actually not either/or for us, we still use Docker Compose to run our services (Redis, PostgreSQL, etc) that don’t require file syncing with the host. It’s good at that.
As a Mac-using Python shop, we had serious file-sync performance issues when mounting our codebase inside a container via docker-compose. Nix completely freed us from them and allowed us to develop with Python natively speedily and without all the serious faff & headaches that usually comes with getting reproducible builds on everyone machines.
If you'd like to know more, I spoke at DjangoCon Europe late last year [1] on our setup; it's still paying serious dividends for us!
Yes, running pytest with the --pdb flag will drop you into the debugger on an unhandled exception which gets a comparable workflow but it's not quite the same as, a) writing tests to file first is not repl-driven development, and b) you generally have to think about doing it first.
In an ideal repl-driven world you could write the test in the repl entirely and commit it to disk once you're ready.
Anthropic have bought out a tool their competitor used too, they even have an OpenAI case study still on the Stainless website.