3,784 karma · joined March 21, 2018
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
On top of that now Google backs those up for you too.
User sends message via client. Client fumbles the recipient id. Message ends up at the wrong recipient.
Examples: incorrect recipient ID attached to contact in list where users selects recipient. Buggy selection of multiple targets in the selection UI due to incorrect touch event handling. Incorrect deletion of previously selected and then deselected recipient from recipient array of multitarget message. Or if working low level even a good old off by one error and reading out of bounds data for the recipient list (though that one hopefully should trigger a faulty send request due to other stuff no longer matching). There is endless examples.
The server can't really safeguard against the client providing a legitimate send request even though the user intended to send it to another recipient.
So I keep wondering if we just save time by introducing more unknown bugs using GPT?
I guess this also has a lot to do with what code is written. I would be much more concerned with a system level C++ library than some JavaScript CRUD.
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
This is an international issue and a national answer doesn't solve it.
For what it's worth my first name is also not accepted correctly (it contains a hyphen) and I never had a problem so far. But every time an airline asks me to put my name exactly as in the passport I cringe.
His points are based on conventions that exist because we use local time zones and he uses a lot of English centric bias in his argument.
His first point of am/pm is already a bad start considering a 24h clock is simply advantageous and used throughout most of the world.
Finding out if he can call his uncle would be as easy as looking up daylight times instead of time offsets/local times. And even then the cultural conventions of your country might not map to his and it was still inappropriate to call.
The problem with business hours and overlapping days is entirely made up, because he wants to stick to previous conventions that worked well with local time. If a night club opens Saturday from 19:00 to 05:00 it's perfectly clear that means it's open till Sunday 05:00. It would work similarly for business hours. The regular business hours also differ vastly in different cultures and jobs! The day name is of course UTC based and wraps at 00:00UTC.
I play an international online game that wraps days at 00:00UTC and we communicate in UTC. If I say Wednesday 14:00 UTC it's perfectly clear what that means and you get used to that very quickly. If we would change the system the next generation would grow up with that system and it would be natural. And I find it much easier to remember that my Korean friends are available from 23:00 UTC till 16:00 UTC than to remember what time it is there right now compared to here, because that requires mental math or a lookup.
Like an English satirical poem to perfect German. Changing the literal translation to keep the meaning and sarcasm of the poem.
if you click the history it says 98.452% over 365 days.
The reality is a lot of systems (especially simple ones) run perfectly fine on a single server with next to no downtime and all the additional redundancies we introduce also add additional points of failures and without the scale that makes these necessary you might actually end up reducing your availability.
It feels like they just tried to be concise and not just throwing them in there to sound smarter.
Menarche = first menstrual period