Between the back button issues and the horrible sluggishness on many repo and pull request pages, the React switchover has seriously degraded what used to be a great experience. Not just on mobile, but on desktop as well.
I have never used a CI system more flaky and slow than GitHub Actions. The one and only positive thing about it is that you get some Actions usage for free.
The Azure machines GitHub uses for the runners by default have terrible performance in almost every regard (network, disk, CPU). Presumably it would be more reliable when using your own runners, but even the Actions control plane is flaky and doesn't always schedule jobs correctly.
We switched to Buildkite at $DAYJOB and haven't looked back.
I think the solid understanding of the product and its users is the important part, not whether you’re an engineer or not. That understanding (or lack thereof) can and does transcend role.
For very simple username/password authentication, what Rails 8 provides is probably sufficient. But the moment you need other auth providers, 2FA, etc., Devise is very much still useful.
This is perhaps what you were hinting at when you said “wouldn’t be ideal”, but Active Record validations on their own are subject to race conditions with concurrent requests. The only truly safe way to ensure integrity of your data is to enforce validations/constraints at the database level.
IME you usually want _both_ the Active Record validations, and the database-level validations, because you get better error messages from the former, and the latter is just a safeguard.
Sure, I’ll grant you that at huge companies it’s probably easy to lose track of who is responsible for what and when resources ought to be cleaned up. But for small/medium-sized companies, using Terraform is sufficient. And while you can also use Terraform to manage resources on k8s, there’s a lot more friction to doing so than using YAML + `kubectl apply`. It’s far too easy to `kubectl apply` and create a bunch of garbage that you forget to clean up.
I truly do not believe that many software engineers are going to lose jobs to anything resembling the current crop of LLMs in the long run, and that’s because the output cannot be trusted. LLMs just make shit up. Constantly. See: Google search results, Apple Intelligence summaries, etc.
If the output cannot be trusted, humans will always be required to review and make corrections, period. CEOs that make the short-sighted mistake of attempting to replace engineers with LLMs will learn this the hard way.
I’d be far more worried about something resembling AGI that can actually learn and reason.
Said more neutrally, Safari is far behind all the other major web browsers in standards implementation and dev friendliness. As an outsider, I also assumed this was to preserve app store revenue. If it's not, could you share some insight on why it happens?
“Far behind” is perhaps an overstatement, especially today. Things have rapidly improved in recent years, with a _lot_ of time and energy being spent on spec compliance and interop (see https://wpt.fyi/interop-2024).
I certainly hope it's not true. But I can also understand how it's hard not to be a little salty. After a decade of development experience, it certainly feels like IOS Safari has consistently made life more difficult when developing web apps.
Don’t believe ones lying eyes eh? There is plenty of reason to believe this may be the case and your refutation offers nothing to make anyone think otherwise. I am willing to listen if you’re willing to speak?
reply