> Apple takes QA very seriously and invests in high quality QA engineers
Willing to bet this is worth 80% of the value to the task, especially if your QA testers can write enough code to have good instincts about why something might break & control for a test environment / create novel test situations.
From my personal experience: system languages are really, really good at interacting with operating systems. When you have things deployed on a server that machine generally has one task, and it makes sense to optimize as many layers as possible. For example on a windows system I used MS's `FILE_FLAG_SEQUENTIAL_SCAN` flag to triple read performance; you could of course do the same in python by dipping into ctypes but it doesn't make for a pleasant development experience.
The big trade-off is you're specifying the task more precisely and as a result of that extra labor you get better performance for the life of the tool. SQLITE has a good story of putting together dozens of small optimizations, each <1% performance change, and at the end the library's throughput doubled in pretty much all tests. It's not worth it for research, but it is everywhere else.
My favorite variant of this is copyright issuance costs double/multiply by some X>1.0 every year after some N years of a flat rate. If your product is actually amazingly profitable you'll have the money to keep the copyright longer than most people, but eventually the costs will catch up with you. Unless you've invented a product that can double in price every year, guaranteed.
Mozilla has to make statistical assumptions about their users, and statistically any random person's DNS will be set to resolve using their ISP. Mozilla may see this as predatory (ISPs in general are not exactly great companies who care for their customers), and so from their perspective comparing "Average DNS use" to "We vetted a company & trust them & we feel good making this decision for our users" sounds worth doing. There may be some latent assumptions about "well power users will just turn this off like they do everything we build" which would also support the action taken.
With that defense in mind, it's still a shitty thing to do to your users. I don't like it, but 99% of the world doesn't even understand what the change means.
Lame but powerful option: `tail -f /logfile.log | grep -A10 -B10 <interesting thing>`. (prints 10 lines before & after search lines). The most powerful feature I've had in log management is the ability to search for what was interesting, and no tool can provide you a "this is interesting" button. If you've got performance concerns ripgrep is a drop-in grep replacement that's very fast.
Nope, never. I run Arch Linux with projects under nspawn containers, the only AV tool I keep around is ClamAV so when coworkers have USB drives I can slap `clamscan /mnt/auto-sda1` and let them know if it's clean.
I love this! computer science is all about abstractions and guarantees, and it's great to have an option for more control. One thought about graceful degradation: would it be easy/possible to build in configuration to "when guarantee cannot be met, only throw an error x% of the time"? This keeps the situational awareness (errors about different query plans) while having an escape hatch: if postgres is updated & the new version decides to never generate good queries, the queries will still happen for some ~95% of users, just slower until the team can read through the new version's instructions to get the plan they need.
If they're escaping, it raises interesting questions about where they might be going / possibly merging? What a strange view of the universe if two particles under pressure could combine and have different attributes (less mass?).
The QA team brings something significant that developers (myself) will never have: their machines closely represent the customers machines. They use a well-polished methodology to push the models we ship to their limits and provide relatively detailed information about how to reproduce failures.
I can't count the number of times I've tested something 5 times, convinced myself that the code handled tons of error cases, shipped it, and in 10 minutes a customer types "five" into a field expecting an integer which causes the next step to use "0" for processing.
Important distinction to make, most people just think "more money means interest" but the mechanics of the two financial instruments differ and this is the entire selling point for these ISAs, and the reason why one may be a good / bad idea in a situation.
I'm not familiar with the UI, but often for high(er) risk operations we in the CS field ask users to fully type the name of something; in this scenario, instead of autocompleting would it have helped to ask the nurse to fully type in the name of the drug?
This will not help the overworked state and the next issue I can see is confusing two drugs (marketing _loves_ to confuse people, given enough phonemes it would be easy to type the full name in wrong); potentially asking for a brief description of what the caregiver expects to happen, with a quick NLP pass comparing the "effect description attached to drug" paragraph and the 2-3 sentence "expected effect description from caregiver". Yes more paperwork, but saving lives is usually worth the extra effort. Everyone already knows the long-term overwork solution is cut down on admin & hire more personnel.
This is the ideal design, along with an office whose job it is to manually move data from the public side to the private side. These offices usually have a server on the public and private side to make it seem like it's an automated transfer (like putting a file in Dropbox on the public and then seeing it show up on the private side), but in reality you have a security guard making sure nobody's copying up `MSOfficeOfficialThisTime.msi`.
They mean "fewer people willing to cross the bid-ask spread to buy a stock than the number of people willing to cross the bid-ask spread to sell a stock"; what matters is who is crossing the line? if it's the buyer side of the transaction, price trends up. If the seller is accepting a small % loss on the sale, the price trends down.
Willing to bet this is worth 80% of the value to the task, especially if your QA testers can write enough code to have good instincts about why something might break & control for a test environment / create novel test situations.