It’s the most boring thing of the technical side of the job especially at the more senior levels because it’s so mindnumbingly simple, uses a significant proportion of development time and is usually what ends up having to be redone if there are small changes in things like input or output interfaces (i.e. adding, removing or changing data fields) which is why it’s probably one of the main elements in making maintaining and updating code already in Production a far less pleasant side of job than the actual creation of the application/system is.

True - the US of late has been a great inspiration for what NOT to do.

That explains the US, but that’s about it.

For example Europe there are no movements towards making abortion illegal, quite the contrary.

That’s because when talking to tribalist types, you’re seen as either with them or against them and in a system with 2 political parties “against them” means “supporting the other guys”.

There is no independent thinking amongst the “party supporter” masses, only following and parroting of the party messages, so the idea of somebody being a genuinely independent thinker guided by personal principles rather than following some tribe or other is anathema to them.

Liberalism isn’t the same as Left. It’s not even in the same political axis.

You can’t really read “more liberal” as being the same as “more leftist”.

Left would be something like: “I want the greatest good for the greatest number”.

Liberalism would be something like: “I want people to have the most freedom to do whatever they want”.

You might notice that these two things collide in things like the existence of the super-rich, were for a liberal that’s a good thing (they have maximum freedom) whilst for a Leftie it’s a bad thing (wealth concentration reduces the access to resources for the many hence it directly goes against the greatest good for the greatest number).

Similarly centralizing control of part or the whole of the Economy (which decreases trade freedom) to achieve greater equality is absolutelly valid within the Leftwing principles and entirely against Liberal principles.

it’s only in places like the US, were the entirety of Leftwing is about 4 congressmen, that Liberalism gets confused with Leftwing.

How much would that be in Libraries Of Congress if written down?

I disagree: as a Bachus of Programming I have successfully managed to at the same time both be a God of Programming AND having no clue what’s going on.

(The real joke behind the joke is that today I’m doing Shader programming so that’s quite close to reality and I could definitelly do with large amounts of wine or at least beer).

Here too the Schrödinger’s equations apply: a programmer’s state during coding is a superposition of both of these states until actually trying to run the code, at which point it collapses into one of the two states.

I’m starting to like this AI thing…

Sound like a critical race condition or bad memory access (this latter only in languages with pointers).

Since it’s HTTP(S) and judging by the average developer experience in the domain of multi-threading I’ve seen even for people doing stuff that naturally tends to involve multiple threads (such as networked access by multiple simultaneous clients), my bet is the former.

PS: Yeah, I know it’s a joke, but I made the serious point anyways because it might be useful for somebody.

I suspect indirectly both variants come from the same source or maybe even it’s the La Haine that’s indirectly the source for my variant (though I learned this joke a long time ago, possibly before 1995).

By the way, that’s excellent film intro.

Reminds me of the joke about the guy falling from the top of the Empire State Building who, half way down, was heard saying: “Well, so far, so good”

Who needs integration testing when we have users who will do it for us?!

“Will horrors never cease?!”

Yeah, the tools are still there to figure out the low level shit, information on it has never been this easy to come by and bright people who are interested will still get there.

However growing up during a time you were forced to figure the low level details of tech out merely to get stuff to work, does mean that if you were into tech back then you definitely became bit of a hacker (in the traditional sense of the word) whilst often what people consider as being into tech now is mainly spending money on shinny toys were everything is already done for you.

Most people who consider themselves as being “into Tech” don’t really understand it to significant depth because they never had to and only the few who actually do want to understand it at that level enough to invest time into learning it do.

I’m pretty sure the same effect happened in the early days vs later days of other tech, such as cars.

Rebrand Github as an MMO were people fight for code dominance.

If it’s part of the Requirements that the frontend should handle “No results found” differently from “Not authorized”, even if that’s just by showing an icon, then ach list of stuff which might or not be authorized should have a flag signalling that.

(This is simply data analysis - if certain information is supposed to be shown to the user it should come from somewhere and hence the frontend must get it from somewhere, and the frontend code trying to “deduce it” from data it gets is generally prone to the kind of problem you just got because unless explicitly agreed and documented, sooner or later some deduction done by one team is not going to match what the other team is doing. Generally it’s safer just to explicitly pass that info in a field for that purpose to avoid frontend-backend integration issues).

Authorization logic is almost always a responsibility of the backend (for various reasons, including proper security practices) and for the frontend it’s generally irrelevant why it’s authorized or not, unless you have to somehow display per-list the reason for a it being authorized or not, which would be a strange UI design IMHO - generally there’s but a flag in the main part of the UI and a separate page/screen with detailed authorization information - if the user really wants to dig down into the “why” - which would be using different API call just to fill in that page/screen.

So if indeed it is required that the frontend knows if an empty result is due to “Not Authorized” rather than “No results found” (a not uncommon design, though generally a good UI design practice is to simply not even give the user access to listing things the user is not authorized to see rather than let the user chose them and then telling them they’re not authorized to do it, as the latter design is more frustrating for users) that info should be an explicit entry in what comes from the backend.

The JSON is indeed different in both cases, but if handled correctly it shouldn’t matter.

That said, IMHO, if all those 3 fields in your example should be present, the backend should be putting a list on all 3 fields even if for some the list is empty, rather than a null in some - it doesn’t matter what the JSON is since even at the Java backend level, a List variable with a “null” is not the same as a List variable with a List of length 0 - null vs empty list is quite a common source of mistakes even within the code of just the one tier, though worse if it ends up in API data.

Who is wrong or right ultimately depends on the API design having marked those fields as mandatory or optional.

That sounds like an error in the specification of the client-server API or an erroneous implementation on the server side for the last version: nothing should be signaled via presence or absence of fields when using JSON exactly because, as I described in my last post, the standard with JSON is that stuff that is not present should be ignore (i.e. it has no meaning at all) for backwards compatibility, which breaks if all of the sudden presence or absence are treated as having meaning.

Frankly that there isn’t a specific field signalling authorized/not-authorized leads me to believe that whomever has designed that API isn’t exactly experienced at that level of software design: authorization information should be explicit, not implicit, otherwise you end up with people checking for not-in-spec side effects like you did exactly for that reason (i.e. “is the no data being returned because of user not authorized or because there was indeed no data to retunr?”), which is prone to break since not being properly part of the spec means any of the teams working on it might interpret things differently and/or change them at any moment.

If I remember it correctly, per the JSON definition when a key is present but not expected it should be ignored.

The reason for that is to maintain compatibility between versions: it should be possible to add more entries to the data and yet old versions of the software that consumes that data should still continue to operate if all the data they’re designed to handle is still there and still in the correct format.

Sure, that’s not a problem in the blessed world of web-based frontends where the user browser just pulls the client code from the server so frontend and backend are always in synch, but is a problem for all other kinds of frontend out there where the life-cycle of the client application and the server one are different - good luck getting all your users to update their mobile apps or whatever whenever you want to add functionality (and hence data in client-server comms) to that system.

(Comms API compatibility is actually one of the big problems in client-server systems development)

So it sounds like an issue with the way your JavaScript library handles JSON or your own implementation not handling per-spec the presence of data which you don’t use.

Granted, if the server side dev only makes stuff for your frontend, then he or she needs not be an asshole about it and can be more accomodating. If however that data also has to serve other clients, then I’m afraid you’re the one in the wrong since you’re demanding that the backwards compatibility from the JSON spec itself is not used by anybody else - which as I pointed out is a massive problem when you can’t guarantee that all client apps get updated as soon as the server gets updated - because you couldn’t be arsed to do your implementation correctly.

Indeed.