The "doing things correctly" mentality is the root of so many problems. Bureaucracy, "German engineering" (overengineering), cargo-culting, CYA, error culture, ...
By the logic of the article, a circuit breaker for the DB query would act as a fallback for the fallback. A path that would be executed in production even less frequently, and which would be more difficult to test for its effectiveness. Surely, you can test whether the circuit breaker is triggered, but would it reduce DB load enough to keep the fulfillment system running?
Eye roll. The UN are pointing out that the AI hype is literally burning the planet. Just because they have Google Analytics on their site doesn't mean they are participating in the destruction.
This is like calling out environmentalists that took a flight.
But you’re not carrying around your own water treatment mechanism either (unless you’re out hiking). It is relatively easy to install air purifiers or UVC lights in offices, schools, grocery stores, etc. The problem is that people don’t care enough about air quality and the ROI isn’t clear. Increasing the ventilation rate in an overstuffed co-working space has cost implications for the operator, but it doesn’t increase revenue.
Europe is not a country or a single place. In central Spain, where 40 ºC is more likely, you'll find more air conditioning than in the UK, where people think that 25 ºC is hot.
It’s possible to verify age without disclosing identity. The German national ID (smartcard) allows this, but I’m not aware of any online service making use of the feature. I suppose it’s used offline by cigarette vending machines though.
For Omada devices, you need a "Controller". You can run the Omada Controller software on an existing computer, get one of their controller devices, or use their cloud-based service, which should be free at your scale.
He's not denying that there is demand, he just has a different view on what's happening:
When developers say that LLMs make them more productive, you need to keep in mind that this is what they’re automating: dysfunction, tampering as a design strategy, superstition-driven coding, and software whose quality genuinely doesn’t matter, all in an environment where rigour is completely absent.
They are right. LLMs make work that doesn’t matter easier – it’s all monopolies, subscriptions, VCs, and lock-in anyway – in an industry that doesn’t care, where the only thing that’s measured is some bullshit productivity measure that’s completely disconnected from outcomes.
...
One group thinks this will make the world ten times richer. The other thinks it’ll be a catastrophe.
It depends on how much caffeine is in your cup. Rather than measuring the size of a cup, I would go by the amount of coffee, as in the weight of the beans, used to brew it. The actual amount of caffeine is not as easy to measure, and even for the same kind of beans, there is natural variation.
For a traditional Italian espresso, about 7g of coffee beans are extracted. For a third-wave double espresso, it's usually 18g or more.
In my opinion, 10x7g is a lot. 2x12g is more than enough for me.
Manual dependency injection is fine, but it doesn't scale. Especially when you start refactoring things and dependencies need to be moved around.
The other issue is dynamic configuration. How do you handle replacing certain dependencies, e.g. for testing, or different runtime profiles? You could try to implement your own solution, but the more features you add, the closer you'd get to a custom DI framework. And then you'd have an actual mess, a naive non-standard solution for a solved problem, because you didn't want to read the manual for the standard implementation.
By the way, Spring dependency injection is mainly based on types. Annotations are not strictly necessary, you can interact with the Spring context in a procedural/functional manner, if you think that makes it better. You can also configure MVC (synchronous Servlet-based web) or Webflux (async web) routes functionally.
When a bean is missing, the app will fail to start, and you will get an error message explaning what's missing and which class depends on it. The easiest way to ensure this doesn't happen is to keep the empty @SpringBootTest test case that comes with the template. It doesn't have any assertions, but it will spin up a full Spring context, and fail if there is a configuration problem.
The only complicated part about Spring Boot is how the framework itself can be reconfigured through dependency injection. When you provide a certain "bean", this can affect the auto-configuration, so that other beans, which you might expect, are no longer automatically created. To debug this behavior, check out the relevant AutoConfiguration class (in your IDE, use the "go to class" shortcut and type something like FooAutoConfi..., e.g. JdbcAutoConfiguration).
In a good codebase, the configuration itself would be tested. For instance, if you did something a bit more complicated like connecting two JDBC databases at the same time, you would test that it read the configuration from the right sources and provides the expected beans.