Seems to me that if Congress would prefer that any disputes arising from the implementation of their laws be handled by the admistrative agency charged with enforcing it, all they need to do is say so in the law. Not sure how the courts could get around that.
Difficulty: Congress almost never passes substantive laws anymore.
No way you’re getting a with-teeth EPA law, for example, through a modern Congress until we’re back to smog clouds over our cities and burning rivers and creating new, large cancer districts and superfund sites. And that’ll have to go on for a while before it happens. Then, maybe.
We’ve been coasting on good laws from the 70s and earlier, mostly, while weakening regulation has been eating our foundation like termites (especially Chicago-school-driven judicial rulings on how the executive is allowed to enforce anti-trust, in the late 70s, and later removal of media ownership consolidation rules). Now they (people who wish they could hurt people while making money and not be told to stop) can attack those good laws directly.
Like any other law, they rule it as unconstitutional. Appeal its way up to the SCOTUS, and they will ultimately decide if they want to keep the power or give it back to the regulatory agencies.
I think whats more harmful than unit tests are code coverage metrics for unit tests that devs feel compelled or are required to achieve. The easiest way to achieve code coverage goals for tests is to write lots of small tests that test individual methods, but test very little of the interaction between them.
I feel that the goal of unit testing should be to test the largest unit possible without requiring external dependencies. In the language of domain driven design, this means to test the domain model. If you can get extensive coverage of the domain model as a whole, system tests can be used to test the complete system.
Alas, I have seen very few software systems with high quality domain models. It is not an easy thing to achieve.
You need to spend $16,666 just to cover the $500 annual fee. That’s a lot for many people especially when many low end retailers don’t accept AmEx. As already state rewards cards are a subsidy for the rich, or at least for people who spend a lot.
If you conceptualize it as "Annual fee minus reward credits" it's far more reasonable than that. For example, Amex Platinum is $695/year, but the Walmart+ and Digital Entertainment credits are $395 combined. Compared to the next highest card in Amex's line - Gold @ $250 - this makes more sense that you might originally think.
Often the $500/year cards have near immediate rewards that cover the cost - if you use those rewards. For example, the CapOne X gives a $400 travel credit every year.
Yeah $500/yr fee is ridiculous. I think my card is 1/4 of that and I’m sure I break even the first month since almost everything I pay for goes through that card. Utilities, cell phone bills, after school program fees (and before that daycare), all other recurring bills besides mortgage/car, restaurants, groceries, anything else I want or need to buy go through the same card. Always pay the balance in full each month no matter how painful.
They can but they generally won’t. Use of the chip on the card shifts fraud liability from merchant to issuer. Burner card numbers are for card not present transactions.
It is different because this way all possible results and failures are known as type information. How to handle erroneous state is the responsibility of the result consumer, given the availability of rich API to unwrap, bind or transform error variants.
That’s not true. Java has 2 types of exceptions checked and unchecked. Checked exceptions are what this thread has been calling errors, and unchecked exceptions are what this thread has been calling exceptions. Maybe it was a mistake to call them both exceptions, but Java also has 2 types of errors.
I'd say Java named them appropriately. While you are right that they almost cover the same intent, error state is not dependent, whereas checked exceptions force a dependency on the caller[1]. They are not quite the same thing.
[1] Ish. If we are to be pedantic, technically checked exceptions are checked by the exception handlers, not the exceptions themselves. If you return a 'checked' exception rather than throw it, Java won't notice. However, I expect for the purposes of discussion we are including exception handlers under the exception umbrella.
Checked exceptions are NOT like errors-as-values. It's only resemblance is that checked strictly forces the exception to be handled, similar to errors-as-values. But the handling itself is still the same as regular exceptions: out-of-band and not composable with anything else.
Here is an example. Go let’s structs be passed by value or by reference. The programmer needs to decide, and that adds complexity that is largely irrelevant for modeling complex business logic. Java does not provide a choice, which keeps it simple.
Simple, but with an inherent performance issue and GC load; note also that Java's Valhalla project adds value types with more stack based semantics, so there too you as a developer get a choice.
In the Lost Updates section, a more straight forward solution is to use the FOR UPDATE clause in the first select statement. This locks the record and prevents concurrent updates.
When you're incrementing by using UPDATE ... SET value = value + 1, the database holds the locks for the minimum time needed. Everything else is less efficient.
In more complex scenarios, FOR UPDATE is the solution.
When there's a big chance of multiple tasks grabbing the same rows, processing them, then updating them, marking them for update since the beginning is better. E.g. a message queue like structure where messages should be processed only once.
