> one that broke the test runner, and ignored a number of tests
That's unfortunate! For the project I'm working on, we've "solved" that by showing the number of test and the difference to the number of tests that ran on main.
FWIW, at previous jobs, upgrading Java dependencies was a major pain because they were all outdated and the latest versions introduced too many breaking changes for us.
At my current job, we pretty much instantly merge all PRs from dependabot
because we trust our CI. Upgrades rarely introduce problems and if they do, they are easy to fix.
> What I've noticed in practice however, is that occasionally, this process will allow an upgrade to a dependency that will pass the automated build and test step, but introduce the wildest runtime error into the application. Usually at the time when we aim to deliver something.
Sounds like dependabot is very useful for uncovering insufficient test coverage or missing integration tests :)
I wonder how you deal with restarting changefeeds? The last time I checked you'd have go through every document again after losing the connection to rethinkdb or restarting the server.
Do you have any data on that? We found that using transit could actually increase overall throughput because it does some minimal compression/deduplication.
It can be the same hardware but I believe that not usually meant with "hardware based encryption". The point is that the private keys never leave the hardware of the phone, thus making it secure. So they could employ the same hardware but the hardware does not have the necessary keys.
Not the same, CS majors in Germany have to choose one "Anwendungsfach" that consist of a subset of classes of natural-sciences, humanities or engineering majors. You have to choose one and stick with it. Also there is the "Nichttechisches Wahlpflichtfach" (probably the most german words I know) which can be a language class or mentoring first-semesters or something similar. So I feel like we get a lot of interdisciplinarity.
The issue seems yo be that writes in Fractal trees always go through the root node. This would lead to a situation similar to small B-Trees where writes will most likely access the root node and contend.
The render function only renders to the virtual DOM, which React diffs with the previous rendered virtual DOM to decide what changes to the real DOM have to be made. That's why the render function is, or should be, efficient.
That's unfortunate! For the project I'm working on, we've "solved" that by showing the number of test and the difference to the number of tests that ran on main.
FWIW, at previous jobs, upgrading Java dependencies was a major pain because they were all outdated and the latest versions introduced too many breaking changes for us. At my current job, we pretty much instantly merge all PRs from dependabot because we trust our CI. Upgrades rarely introduce problems and if they do, they are easy to fix.