AndreasHae

It’s still ridiculous to me that version pinning isn’t the default for npm.

The first thing I do for all of my projects is adding a .npmrc with save-exact=true

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.

0: https://github.com/dependabot

1: https://docs.renovatebot.com/

Thanks for sending me into that rabbit hole.

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.

Source in German: https://presse.oebb.at/dam/jcr:f87d6627-602c-47d6-bec7-f5682...

Here’s the HN post of the official announcement: https://news.ycombinator.com/item?id=37494605

Kotlin ticks all of your boxes, plus you benefit from the vast ecosystem of the JVM.

Super nitpick, but you meant profit, not revenue, right?

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.

The industry is now even legally making money on many things that would've been considered outright malware just a decade ago.

Sounds a bit over the top. Can you name some examples?

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.

[0] https://www.ory.sh/keto/ [1]: https://auth0.com/developers/lab/fine-grained-authorization

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.

Sam Altman himself failed with his original startup (Loopt)

I wouldn’t exactly consider being acquired for $43M a failure.

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.

Reminds me of Flammkuchen: https://en.wikipedia.org/wiki/Flammekueche

The kind of middle manager you’re describing is one I wouldn’t like to work with anyways, so it doesn’t seem like much of a loss.

everyone over there is possibly a few steps away from being drafted into war

Why do you think so? Might be different in Eastern Europe, but as a Central European I think it’s quite unlikely that a direct conflict is going to happen.

Coincidentally that was a few weeks after I saw a comment here on HN about someone who hired someone from Facebook, and the guy would change the tests so he could push to production, rather than fixing the bug that the tests pointed out ...

Can't blame him, he moved fast and broke things /s

Not exactly. I disabled my router‘s built in DHCP server so that they don’t conflict with each other. Luckily it didn’t have _that_ option locked down :)

You can also configure PiHole as a DHCP server that sets itself as the DNS server. This way you only have to configure it once and devices should accept it as the default DNS. Had to do that to sidestep my locked down ISP router config…

Can you think of any FAANG scale orgs that haven’t run into having a fragmented product landscape? Maybe there’s just a hard limit of how much complexity one business unit can handle before it stops being able to scale up. With that in mind, decentralized teams with tight product+tech collaboration seem to be a successful model. Otherwise we would probably already have seen an example of a successful tech company with centralized product/tech departments.

I‘m interested in the reasoning why API pagination is hard to add later, or rather what the benefit is of „leaving space“ in the API response while in reality returning all items at once.

Wouldn’t have to adapt the way the frontend consumes the API either way, keeping track of the current list state? Or is that what the author meant, that you should always write your list UIs as if they consumed a paginated API?

Would love to see this!

I‘m curious about your reasons to decide against Kubernetes and instead opt for plain VMs + Packer, especially when already familiar with the platform.

A lot of this could be solved by inferring the time zone by location of the appointment. If you know the event occurs in a specific place at a specific time, you almost certainly want it to be the standard time zone of that place. If that place uses DST, I couldn’t think of any reason to ignore it and opt for standard time regardless.

Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.

Earlier discussion (2020, 600 comments): https://news.ycombinator.com/item?id=22244750