It's about making APIs more flexible, permissive, and harder to misuse by clients. It's a user-centric approach to API design. It's not done to make it easier on backend. If anything, it can take extra effort by backend developers.
But you'd clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.
Used in English translations of the Bible, so if you grew up Christian you probably have heard it before.
Visual... programming languages? Yikes.
Yeah, interoperability. Like every software implementation of natural numbers that include 0.
Sure... That"s what libraries are for. No one hand-rolls that stuff. You can do all of that just fine (and, actually, in a lot less code, mostly because Java is so fucking verbose) without using the nightmare that is Spring.
The answer to smooth jazz is to play some real jazz instead.
It's currently the best tool for doing UX/design work.
No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.
If you had branched like this:
A -> B -> C (master)
\
\ -> D (feature)
It would like this after merging master into your feature branch:
A -> B -> C (master) -> E (feature)
\ /
\ -> D -------------------> /
And it would like this if you instead rebased your feature branch onto master:
A -> B -> C (master) -> D' (feature)
This is why it's called a "rebase": the current state of master becomes the starting point or "base" for all of your subsequent commits. Assuming no conflicts, the diff between A and D is the same as the diff between A and D'.
If you're working with csv data, https://www.visidata.org/ >>>>> excel (assuming you're comfortable with terminal UIs, anyway). You can very rapidly slice and dice data and for formulas and such, you can just write Python.
If you instead made your lobby field a HashMap<String, MatchId>, then whenever you get an event from a known player, you can lookup the match they are in from the lobby map and use that to lookup other data about the match (such as the other players) via the matches field (assuming that was also changed to be a hashmap as described in my previous comment).
"Lemmy" (the software) doesn't have any data. It all resides on servers owned by people other than Lemmy's developers. They have the user data and would absolutely be subject to GDPR.
Again, no matter what Lemmy's devs put in place, it doesn't matter because the instance admins can do whatever they want.
That's what the If-Match header is for. It prevents this problem.
That being said, I generally think
PUTs are preferable toPATCHes for simplicity.