Holy shit. That is not even a "pull down menu" as previously reported.
Good to know. This means that in Hawaii, you should only think about taking action if the magic FALSE ALARM notice never appears.
If the FALSE ALARM notice doesn't appear within an hour, it might just be that the false alarm guy is on lunch break. If it doesn't appear in 8 hours, it might mean that a shift change occurred without proper hand-off. If it fails to appear in 24 hours, a nuclear attack might actually be imminent, and you should check other sources, to determine if the alarm was, in fact, real.
This protocol ensures that archaeologists will receive a valid record, omitting the false alarm notice in the rocks on the other side. Eventual consistency ensures that before the archaeological record is written, a false alarm notice will appear, if the alarm was indeed false. In all other cases, the alarm is effectively revealed to history to be a true alert, at some point in the future, as yet to be determined.
Gross. It sounds like a total failure to correctly model reality.
Like measuring how blue the sky is, based on how much "blue" is left in the universe. The idea they attempt to quantify is improperly described in terms of qualities. e.g. Do colors even work that way?
(...and keep your planck unit, M theory, quantum field eigenstate, history-of-the-big-bang, age of the universe remarks away from this hypothetical example, please. You know what I mean when I describe the sky as either blue or not blue in the colloquial sense.)
Well of course it sounds ridiculous when you use an absurd analogy. A more reasonable analogy was something like muscle fatigue, or even mental fatigue, and it seems reasonable to believe that willpower can be depleted in a similar way. In fact, there were many published studies consistent with this hypothesis (as the abstract states).
That Napster is depicted as a footnote is pretty inaccurate, considering the title. Paint his story as the story of a kingpin, but this is not "the dawn of" anything beyond his personal tale.
And this is why I don’t pay for a Netflix subscription.
What is it with engineers willing to brainwash themselves regarding what constitutes a “good compromise” within the context of what their paycheck depends on?
Networked resources have listeners. Listeners have ears. Ears have wax.
A unit test verifies that your Q-tip is made of cotton, and that the cotton is soft and small enough to fit inside an ear to a depth that will fetch wax. Another unit test might confirm that a swabbed substance is actually ear wax, by reporting the qualities of a verified sample of earwax, and maybe also a sample of candle wax as a true negative.
An integration test verifies whether you are allowed to swab a specific person's ear, that they still HAVE at least one ear (but check for both, YES. EVERY SINGLE TIME.), that the ear is healthy enough to tolerate a cotton swab, that the person will hold still, and wait for you to finish swabbing (and emergency procedures for what happens if they violently react to suddenly getting stung by a bee in the middle of being swabbed), and that the ear in fact HAS wax to swab, before swabbing.
One preliminary unit test tells you that you're not holding a knife. The integration tests do almost everything else. You need to authenticate (ask first, maybe this alone tells you they have ears... OR NOT), connect to the network resource (reach your arm out with Q-tip in hand, and approach the ear), start the transaction (apply pressure to someone else's ear), complete the transaction (extract a sample of ear wax), and check the response for your request (inspect the earwax specimen). One last unit test to make sure you got back wax, and not blood.
Sounds disgusting, right? It is. And you can keep a rubber ear in the cabinet, as a stub test target, sure. We all understand the textbook definition of the noun (earwax, integers, money).
That's an interesting choice of analogy given that boxes of Q-Tips warn you to never try cleaning your ears with a Q-Tip and so do most professionals: http://time.com/4290668/q-tip-ear-wax-removal/
Current professional wisdom is that you shouldn't even bother cleaning your ears because wax buildup is healthier and the body's own wax removal process is good enough.
Fascinatingly, you are probably suffering thus due to very specific genetics, not bad hygiene, personal variation in earwax, or an inherent quality of earwax: https://en.wikipedia.org/wiki/Earwax#Physiology
This was a good metaphor but I don't understand the last line. Our tests can never 'really' clean 'real ears' can they? [Actually, that's kind of an interesting idea. Send a real order thru your inventory, order management, etc. systems ...]
Payment processors frequently conduct "no-capture" test transactions for authorizations of possibly $1, before tokenizing CC info. Arguably, this follows the pattern of an integration test.
Ecommerce providers often follow a process of cycling an immaterial test product through a real credit card for pennies, with a petty cash credit card, to exercise the purchase/refund cycle, end-to-end, depending on the activities of the project. A runaway batch process with an infinite loop of purchases is bad, infinite refunds is even worse.
Sometimes these tests are needed to ensure that the service account exists on the third party system, is recognized, and has limited permissions for a fixed, restricted set of API calls. The tests might be run only during a release deployment, against live production, but more frequently against a third party sandbox host while coding. This is a very common pattern.
> Ecommerce providers often follow a process of cycling an immaterial test product through a real credit card for pennies, with a petty cash credit card, to exercise the purchase/refund cycle, end-to-end, depending on the activities of the project.
That sounds familiar. I'm sure that was being done at the last place I worked, an e-commerce 'agency'.
If you aren't sending real orders through your systems.. you are waiting for your customers to find and report all problems. Right?
This is actually a strength of a QA team. They can build test plans and execute them on a different technology than your Dev team built the system with and on. This is also why acceptance testing is so important. You want to get as close to possible as capturing "in the wild" users using your system as you can.
I have tests that do this :-) Well, not for an order, but with a sort-of-monolith sort-of-microservice system with email, dashboards, reporting, a JS SPA and a lambda/flask/zappa based API thats decoupled from the admin app, we want one live, round trip of all the data flowing and actions along the way... we can point it at staging, production, and I think dev (via docker-compose, but that part wasn't done last I worked on this). It relies on some special hard-coded/pre-setup accounts and stuff, but they're real, just marked as test related in their names so everyone knows not to touch them.
I think the point was to notice the continuum between completely fake stubs that only have enough "real" behavior to facilitate unit tests and a full-fledged production scenario. Integration tests are not the same as production, but they are much closer than unit tests. In integration tests as much is real as possible vs. unit tests where as little is real as possible.
Maybe this article just "isn't very interesting" and suddenly there are better things to discuss elsewhere.