Readit NewsIt is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time.
That's exactly how I've worked for the past decade or so.
Having to rebase again and again is a symptom that a dev branch is living for too long.
Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP
Absolutely everything gets easier when you lower your work in progress.
If you have any questions I'll be sure to answer them.
We recently crossed a massive usage milestone with over 3M weekly downloads (we're nearly at 4M!) - see https://www.npmjs.com/package/@electric-sql/pglite
While we originally built this for embedding into web apps, we have seen enormous growth in devtools and developer environments - both Google Firebase and Prisma have embedded PGlite into their CLIs to emulate their server products.
If so then supporting the network protocol so it could be run in CI for non-JS languages could be really cool
I'm not clear from the doc which of these scenarios is what they're calling the "leak"
Where you store the .duckdb file will make a big difference in performance (e.g. S3 vs. Elastic File System).
But I'd take a good look at ducklake as a better multiplayer option. If you store `.parquet` files in blob storage, it will be slower than `.duckdb` on EFS, but if you have largish data, EFS gets expensive.
We[2] use DuckLake in our product and we've found a few ways to mitigate the performance hit. For example, we write all data into ducklake in blog storage, then create analytics tables and store them on faster storage (e.g. GCP Filestore). You can have multiple storage methods in the same DuckLake catalog, so this works nicely.
0 - https://www.definite.app/blog/duck-takes-flight
ie. Running it like a normal database, and getting to take advantage of all of its goodies
The key quote was something like "You want your software to be like surgery - as little of it as possible to fix your problem".
Anyway, it doesn't seem like this blog post is following that vibe.
... is that gambling sites are except.
I may need to prove my age to visit Reddit (and soon Wikipedia) but not to visit Bet365, Ladbrook's, Paddy Power etc etc.
Need I tell you who some of the biggest lobbyists and political donors have been?
Visiting a gambling site isn't restricted, but signing up and gambling is.
> Significantly smaller than JSON without complex compression
Although compression of JSON could be considered complex, it's also extremely simple in that it's widely used and usually performed in a distinct step - often transparently to a user. Gzip, and increasingly zstd are widely used.
I'd be interested to see a comparison between compressed JSON and CBOR, I'm quite surprised that this hasn't been included.
This is especially useful when you're using them for customer or user IDs - being able to easily spot your important or troublesome customers in logs is very helpful
Personally I'd go with a ULID-like scheme similar to the one in the OP - but I'd aim to use the smallest number of bits I could get away with, and pick a compact encoding scheme