I once found a confirmed bug in SQLite one time, and it’s the highlight of all my OSS bug reports.
Interestingly enough I found it while fuzz testing a query builder and cross testing it against PostgreSQL, MySQL and an in-memory filtering engine I wrote.
Has anyone ever implemented a schema where you define a view to return the latest instance of each resource, and it maps INSERT, UPDATE and DELETE to an append only table underneath?
I’ve done some of this with an event sourcing system, but not the query rewriting. All my reads use the “latest view”, but the app uses functions to write to the underlying scheme rather than doing “simple” DML.
I wondered if keeping the storage as append only under the hood would keep the app layer simple.
The end result is almost the same as an audit table except there's much more work to do at read time, and some queries simply cannot scale as they need to with this approach.
In general for most apps you'd rather have 2 writes (write to table and write to audit table) than 1 write to the event log and hard to scale reads.
Its usually leadership who are the problem if a whole department is failing. If they started firing from the top down they'd eventually reach competent people who stayed with the department out of loyalty or because they felt responsibile to hold things together. Seems such a waste to fire those people too.
Unfortunately most companies don't operate as a meritocracy. Leadership is almost never fired because it becomes a club/brotherhood. The first people who are fired when things go badly are those not in the club (individual contributors).
There are always exceptions, but they are rare. People are innately tribal and political.
I think the point the GP message is making is that, prior to review/merge you extract atomic commits from your WIP that tell a clear, concise story of how the change was made. The reviewer has less built up context so by chunking it like this they can step through each commit one at a time.
IMHO the expectation is that each commit would 100% pass CI, so if you decided to extract some commits and merge that early you can. This is especially useful when a 6 commit PR is reviewed, and the first 3 commits are fine but there is more feedback on the last three. The reviewer can split the first 3 good ones out, get them merged and whittle down the PR to the remaining three. The subsequent follow up will be less.
IME team velocity goes up with this too, and it encourages small and easy to review commits like a Remove to be extracted and merged early.
Since PRs are always as large or larger than commits, I would much rather have a specific commit flagged than have to wade through the whole PR diff. If the PR is not familiar to me, I want to increase my effectiveness narrowing down the cause, so I can fix it faster.
Yes but wouldn't be great. The problem is that these ultra low level assembly languages actually throw away a lot of information that is useful to parallelism. Recursive functions are great for HVM, but when compiled to assembly, that structure is lost.
I suppose it’s not always lost, but the call graph needs to be inferred, and you might risk applying low-level optimisations that only apply to CPU, which may break the ability to infer the highly parallelizable structure in the high-level language. Compiling to CPU assembly is sort of a step back.
Also, why don't they share the lists with each other? They don't need government help to do this.
If there are privacy issues then they could just share a list of hashes and if someone's legal name hashes to something on the list then you deny them.
Interestingly enough I found it while fuzz testing a query builder and cross testing it against PostgreSQL, MySQL and an in-memory filtering engine I wrote.