If changing one line of code regularly requires me to update mocks in 100 test cases, those test cases may have negative value.
653 karma · joined October 19, 2015
If changing one line of code regularly requires me to update mocks in 100 test cases, those test cases may have negative value.
1. Unit tests for code with no side effects (code that takes well defined input and produces well-defined output) are easy to write, easy to understand, and I've never regretted writing them.
2. I've had good experiences transforming as much error-prone logic as possible into code with no side effects.
3. Integration tests that execute in an environment that is similar to production have proven to be incredibly valuable, especially when refactoring. When possible, I prefer to make technology-stack choices that make such an environment quick to setup and teardown such that these tests can run in seconds.
4. Many bugs occur because team A makes bad assumptions about how team B's system behaves, and they encode these assumptions into their (passing) test cases.
5. Unit tests with lots of mocks should be avoided; their cost-to-benefit ratio is terrible. Sometimes the best solution is to delete these tests. Relying on mocks for a few error-case tests that are hard to reproduce on the real system is ok.
6. If they cannot be avoided, fake implementations should be written by the same team that writes the real implementation. They understand how it actually behaves much better than their users, and are in a good place to reuse critical logic from the real implementation in the fake to make it more realistic.
7. If my project includes firmware running on custom hardware, building an emulator for the hardware that can run on standard computing infrastructure is valuable for writing test cases against.
8. More tests or coverage is not always better. We have a finite amount of time to improve our systems, and it is our duty as engineers to ensure that the benefit we get from adding a specific test-case is higher than using that time to make some other improvement to the project.
https://www.sfgate.com/bayarea/article/COVID-San-Francisco-s...
For what it's worth, I've been trying to find evidence of hospitals running out of ICU beds due to Omicron, but I'm not seeing it anywhere in North America, even in places that appear to have peaked. Staffing shortages due to quarantine policy seem to be a much bigger problem.
The vaccines really do seem to be working, and Ontario has a lot of vaccinated high risk folks compared to most US states.
Also:
""In ICU” numbers include people testing positive for COVID-19 and people who are in ICU for a COVID-19-related illness but have since tested negative."
It's not clear from the text that they are excluding people in the ICU with a positive test but are there for another reason.
https://covid-19.ontario.ca/data/hospitalizations#hospitaliz...
Over those same 4 days, a significantly increasing number of the folks in those beds are testing positive with Covid, but it's not clear to me whether that is the reason they're in the ICU. The hospitals need to provide better data about the reason these patients were admitted.
Rust doesn't rely on reference counting unless explicitly used by the program, and even then you can choose between atomically-reference-counted pointers (Arc) vs non-atomic-reference-counted pointers (Rc) that the type system prevents from being shared between threads.
Point number 2 excludes pretty much all network-connected software, and that's intentional. I suppose single-player games are ok to write in C or C++.
1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript.
2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++.
3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage collector, like Go or Java.
4. Is there anything left besides Rust?
Other languages may be more ergonomic or have more batteries included, but none of them can offer the holy grail of memory safety without garbage connection.
To make this happen we'd have to build new homes like crazy while keeping the interest rates low.
I left for a big-tech job in the bay area, but I still miss elements of the Calgary lifestyle. In particular, the insanely low mortgage payments compared to wages led to a feeling that I could feasibly bootstrap a business without taking a huge financial risk.
"The GeekBench running score before changing the location to France is 286,632. However, after changing the location to France, the running score is 298,321."
I have a hard time caring about a 4% difference in performance.
I'm willing to personally donate 10k a year to projects like these to liberate myself from crappy vendor tools that I can't improve.
I've switched most of my personal projects over to Rust and so far I'm not looking back...