This is really cool, looking forward to trying it out.
Obligatory mention of Neon (https://neon.com/) and Xata (https://xata.io/) which both support “instant” Postgres DB branching on Postgres versions prior to 18.
Aurora clones are copy-on-write at the storage layer, which solves part of the problem, but RDS still provisions you a new cluster with its own endpoints, etc, which is slow ~10 mins, so not really practical for the integration testing use case.
I don’t understand what you mean, sorry. If you are manually copying a password, then you are not using passkeys? There is nothing to copy/accidentally leak with passkeys.
I guess it will be a while before passkeys are the _only_ option that websites accept
Hi @tudorg - do the Xata copy-on-write branches work like Neon in that you effectively get an isolated Postgres cluster, allowing you to test roles, extensions, creating/dropping DBs, altering schema & data of existing DBs, etc? I looked in the docs but it wasn’t clear to me.
I switched from Pinboard a year or more ago after using it for many years, mainly because I found the iPhone app and integration (eg share feature, to save bookmarks) to be flaky.
Raindrop has been great - imported seamlessly from Pinboard and the iPhone and Desktop app work well for me.
I’ve switched recently from asdf for managing language & tool versions and the ergonomics are much nicer (eg one command vs having to manually install plugins, etc., more logical commands) It’s also noticeably faster.
Regarding the env vars features, a couple of relevant Mise issues around people trying to integrate env var secrets using SOPS, 1Password, etc.
Is saying “most of something” a universal generalisation?
The comment didn’t say “you’re not a crypto enthusiast _unless_ you believe X”. It just made an assertion (which, for what it’s worth, I think is incorrect) that the majority have a certain belief.
There’s an awkward gotcha/incompatibility between “Required status checks” and workflows that get skipped [1], eg due to setting a “paths” property of a push/pull_request workflow trigger [2].
The checks associated with the workflow don’t run and stay in a pending state, preventing the PR from being merged.
The only workaround I’m aware of is to use an action such as paths-filter [3] instead at the job level.
A further, related frustration/limitation - you can _only_ set the “paths” property [2] at the workflow level (i.e. not per-job), so those rules apply to all jobs in the workflow. Given that you can only build a DAG of jobs (ie “needs”) within a single workflow, it makes it quite difficult to do anything non trivial in a monorepo.
Yes, absolutely! I loved listening to the Reith lectures many, many years ago, when Vilayanur Ramachandran gave them. You can still listen to them here, http://www.bbc.co.uk/radio4/reith2003/
In Lecture 4 (Purple Numbers and Sharp Cheese) he talks about the Kiki / Bouba effect. His enunciation is amazing.
Obligatory mention of Neon (https://neon.com/) and Xata (https://xata.io/) which both support “instant” Postgres DB branching on Postgres versions prior to 18.