I don‘t like dismissing technologies on the basis of being „magic“, since the magic could often just as well be called abstraction, and the line between them is often personal preference.
The abstracted-away logic in a Laravel application can either be called magic or abstraction, but so can the optimizations of a database query planner.
I think often you still need to know the underlying mechanism, but it is still useful to get the innards out of the way.
It's useful to get "glue" code out of the way while building, but to the point in the article it all becomes very difficult to debug and maintain once there are problems in the that layer.
Spring Boot and other similar frameworks come to mind; by forcing huge amounts of indirection you lose a lot of visibility of your call stack because the convenient "glue" code is now orchestrating everything at runtime, but that code isn't yours, and it isn't easily inspected or fixed.
Generally, they're on the lines of "regulations hurt my capacity to make unlimited money at whomever's in my way's expense.", except with less candidness.
The larger cables tend to have strength members with higher physical bend radius restrictions, i.e. you can't bend the steel or kevlar elements that tightly without breaking things.
The exclamation mark has a reason: if the newly created records fails validations, an exception is raised. Without the exclamation mark, the error is silenced (and the method returns a falsey value). This is a convention across Rails.
Ruby itself mostly uses it for mutating methods (e.g. #gsub("a", "b") replaces the character a with b in a string and returns a new string, but #gsub!("a", "b") mutates the original.
> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day.
I agree that it can be useful, but I fear that in the future, we will have many more online platforms that require an ID than we currently do.
In the past, things like age verification required users to upload a scan or photo, and someone had to verify it. Because that was too much work for the platform operators, they didn't do it (or only with the banner "Are you over 18?").
With the e-ID instead, this will be much simpler to implement. And I expect it to become much more widespread in the future.
Even though I am for the eID I do share your worry but I don‘t think it‘s hopeless. Both politically and socially there are avenues to combat such over-identification. Still, most uses will probably more private than sharing copies of your ID so I am not sure what the gain for companies will be as it might just limit the customer base without much data gained. That does not seem in the interest of those companies. It‘s easier for the government to enforce certain checks, which is also not ideal but still there are avenues to fight this if it happens.
Quite a few actually do require ID-scan-through-email (which is horrible). Or, they simply delegate to a third party video ident service, often in another country (because cheaper).
How exactly is the status quo not much worse than "I give you a cryptographic hash proving that I am over 18, but nothing else, and without the state knowing that this transaction happened"?
The status quo is that companies which are required by law to have this information (banks, telecommunication providers etc) do require an ID scan (and often video identification as well).
All the others don't really care and just let you register with whatever name and birthdate you want, because the ID scan method is too cumbersome and expensive to them.
I expect those to move to eID, effectively requiring people to have an eID, with no way to provide false information.
The abstracted-away logic in a Laravel application can either be called magic or abstraction, but so can the optimizations of a database query planner.
I think often you still need to know the underlying mechanism, but it is still useful to get the innards out of the way.
reply