Cross-border price differences have been a major point of public debate in Austria recently. Particularly supermarket prices are often up to 50% more expensive for the same item than in neighboring countries, even if the product has been produced in Austria by an Austrian company.
This shows that the EU still has a long way to sufficiently integrate its markets, despite free movement of goods having been established ages ago. Projects like this may help facilitate the transition to a more unified market.
The hate is more geared towards SPAs in general, but there are some shining examples that show that a well-made React/Angular/whatever app can have great UX - Clockify being one of them.
I don’t think the culprit apps would have substantially better UX if they were rendered on the server, because these issues tend to be a consequence of devs being pressured to rapidly release new features without regard to quality.
Fantastic article! It seems to me that the flexibility of low-level git objects would lend itself to be embedded in other software systems for version control purposes (e.g. tracking changes in a CMS)
I think the idea is that for minor updates or patches, any potential breakages should be caught by the build pipeline or rolling deployments with automated rollback strategies (if you’re at a scale where this is feasible). Major updates will probably fail in the pipeline and require manual intervention either way.
I don’t think it makes sense for every project, but if recovery options are cheap then I don’t see anything that speaks against it.
Nowadays there are automated tools like Dependabot (0) or RenovateBot (1) that make it simple to keep dependencies up to date. I can imagine the need originated from the JS ecosystem, but from a security standpoint it makes sense for almost any stack.
So according to the company’s 2022 annual report, they source power from 8 hydroelectric and 6 solar power plants, all of which they operate themselves, as well as 4 partnering hydroelectric plants. The rest of their electricity needs is acquired from the market but checked for proof of origin.
Obviously this only covers railway infrastructure in Austria as they have no influence over other countries.
After a quick check on crates.io, Axum stands at over 5,000,000 „recent downloads“ which is 5x as much as the next most popular contender, actix-web. Seems to me like the Rust community is already converging towards Axum as the default choice.
Might depend on the team or moderator, but in my experience 5 Whys can help uncover the exact systemic issues you are talking about. The key is that it’s not about how to make sure this specific problem cannot reoccur, but more broadly, how to make sure a problem of that kind can never happen again. Your last paragraph puts it really well. 5 Whys helps with that by making you go deeper.
You're implying that putting capital towards having the "best" railway is the most optimal use of that capital. I think it's much more complicated than that, and coincidentally, market mechanics are one way of crowdsourcing the decision of how capital is put to best use.
I'm not saying it's always the best solution and free markets going unchecked can for sure cause more harm than good, but I think you're making it out much simpler than it really is.
We successfully used a Relationship-based Authorization System based on the Zanzibar paper at my last job building a B2B SaaS leaning heavily on cross-company integration.
The flexibility in defining rules through tuples helped us iterate rapidly on new product features. We used self-hosted Ory Keto [0] instances as the implementation, though we would have preferred a managed solution. We were checking out Auth0 Fine Grained Authorization [1] but it was still in Alpha back then.
Would love to hear your experience on why that‘s the case. Sounds like an idiot proof value proposition to me, considering the damages that could be avoided.
Code doesn’t have to be perfectly maintainable and „elegant“. It just has to be useful i.e. good enough. If it solves your user‘s problem, that’s good enough. If your development speed can keep up as you add new requirements, that’s good enough.
Doesn’t mean you should ship untested code because that would decrease both the value to the user and your development speed. There are projects out there that go into the other extreme, entering the realm of premature abstraction and accidental complexity. In my experience that’s even worse because in that case it’s hard to convince stakeholders that there even is a problem.
It‘s a tough pill to swallow for devs with perfectionist inclinations like me, but at the end what matters is providing value to the user. In fact, I think technical debt will always be present as long as requirements change, and as the saying goes, change is the only constant in software engineering. It‘s not something to be completely avoided as that’s impossible. It just needs to be managed in a pragmatic way to keep up velocity.
The first thing I do for all of my projects is adding a .npmrc with save-exact=true