It looks a lot like in a way History is repeating itself: the Democrat Establishment in the US (who are a hard neoliberals, not lefties) fielded directly and without a Primary a guy like Biden who is less than in his prime and even supports an ethno-Fascist regime commiting Genocide (and, more importantly, is unwilling to walk back on that support even to improve his odds of winning against Trump, which is what we are being told is the most important thing in the World) all of which is making it far more likely that the Fascists will get power.

There are vast contradictions between what we are being told is the danger of Trump getting elected and the DNC and Biden persistently making choices that increase the chances of Trump getting elected and not walking back on those.

Surelly if “Stop Trump” is the most important thing in the World for them, the Democrat Establishment too would be walking towards the wishes of the electorate not just trying to push the electorate to do all the walking towards the wishes of the Democrat Establishment.

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.

Real Life^TM is a Role-Playing Multiplayer Game with the best graphics resolution in the Industry.

Sadly, it suffers from severe game play balance problems, most notably that most of game play time is spent in boring tasks which should’ve been simplified into just the core gameplay element for a better gaming experience, plus it’s heavy reliance on grinding, to the point that most players literally have to spend at least 8h per day in the game grinding merelly to not lose the game.

And don’t get me started on it’s Pay To Play elements.

To add to both your posts, a pretty good general rule is: don’t confuse famous with knowledgeable.

The only knowledge they’ve proven is of “how to become known in a specific domain”, which at least in social media is mainly about self-promotion (and more generally it’s about grifter skills) rather than specific domain knowledge.

So yeah, the likes of Andrew Tate will do it by looking confident whilst telling tons of bullshit and plenty of female influencers will do it by looking good and showing some skin - they’re good at self-promotion online but that doesn’t mean they know shit about anything else.

It would be especially appropriate for a horse funeral were the animal was used to bring contraband over the Sierra Morena.

Not really in a bolt tightenning domain, but I have done technical interviews for a lot of devs including junior ones, and them asking all those questions about the task is something I would consider a very good thing.

At least in my domain the first step of doing a good job is figuring out exactly what needs to be done and in what conditions, so somebody who claims to have some experience who when faced with a somewhat open ended question like this just jumps into the How without first trying to figure out the details of the What is actually a bad sign (or they might just be nervous, so this by itself is not an absolute pass or fail thing).

Also that newspaper is called “The Fatherland”.

It’s a pretty good hint of where they stand in the whole Left-Right political spectrum.

I have this wonderful memory back when I lived in the The Netherlands and worked near Amsterdam of people outside in an open shopping area, sitting down on a table and eating patates (big chunky chips) and a starling on the ground looking at them and seemingly giving them a long speech.

I always imagine it was some “poor me” speech on how he had 8 starving young ones at home and would they thrown a patate his way.

For some reason in that place starlings were much comfortable around humans thanwhat I’ve seen elsewhere, and like sparrows would be going around on the ground looking for scraps.

It’s not about debugging tools.

Different, high level software designs (i.e. architectural designs) which are normally imposed by the game engine, have different probabilities of the developers who are making the code for those to produce bugs, because of lots of factors including things like of how they approach error validation and handling in the engine itself and in which domains does the engine leave the most freedom to coders and which ones does it leave less - some things are pretty safe to leave in the hands of even bad developers, others are not.

The example of multi-threading in Unity should’ve been clear: put a game engine that doesn’t impose a single thread pattern in front of somebody with little or no experience in multi-threaded programming and you will have a huge rate of bugs (mainly critical race conditions) and as it so happens most developers out there have little or no experience in multi-threaded programming. Yet multi-threading can yield far more performance in modern CPU since they’re all multi-core. For that specific game engine a software architectural choice was made to go with a structure that is not as performance but significantly less likely to lead to a higher bug rate when used by the average coder, probably because Unity targets less experienced coders.

Good Senior Designers and Technical Architects don’t design the high level structure of the software for themselves as coders, they do it for the kind of coders that are likely to be coding for it.

Of course the developers themselves also have different capabilities and hence different baseline rates of creating bugs, hence why I said “both”.

It’s both.

The architectural decisions are at the engine level and that stuff has a massive influence on the likelihood of bugs in the code running in that engine.

For example, traditional Unity (not ECS) runs all game code (so the code provided by those coding the game) in a single thread, which avoids A TON of multi threading bugs (as that’s one of the hardest parts in programming to master) but is very bad for performance in multi-core CPUs. Game programmers can fire up separate threads using the standard libraries of the programming language itself and manage them, but everything in the development framework that’s part of the engine pushes them to use that single-threaded model, so only advanced devs bother and only for very specific things.

Also the choice of programming language forced by the engine itself has a huge impact in the likelihood of bugs, but since I don’t want to start a Holy War I’m not going to star pointing fingers at specific languages and criticizing them ;)

The EULA part is the fishy one, since EULAs are not valid in most of the World - sellers can’t just after the sale force a change of the implicity contract which is the sale itself (worse, refuse to provide access to the functionality of purchased software after the buyer has fullfilled their part of the contract) so EULAs legally mean nothing except (apparently) in a handful of US states.

The only “licensing conditions” that legally apply here are the ones agreed between seller and buyer before the sale - determining by payment having been given and accepted - not after the sale.

(Online services get away with TOS changes because it’s an ongowing service rather than a product sale, so the rules are different).

The fishy part is the “taking in account the EULA” since EULAs are not legally valid documents in most of the World.

Licenses explicitly accepted by the buyer before the purchase, sure, EULAs, no, since they’re treated as an attempt to, after the implied contract which is the sale, unilaterally change the contract.

The court order makes some sense because that’s basically to do with inheritance and who gets to inherit what, but the EULA “consideration” is complete total bollocks.

You’re confusing your own familiarity and experience with a general human rule.

My mother tongue (Portuguese) has the same order when saying numbers as English (i.e. twenty seven) and indeed when I learned Dutch it was jarring that their number order is the reverse (i.e. seven and twenty) until I got used to it, by which point it stopped being jarring.

The brain doesn’t really care beyond “this is not how I’m used to parse numbers” and once you get used to do it that way, it works just as well.

As for dates, people using year first is jarring to me, because I grew up hearing day first then month, then year. There is only one advantage for year first, which is very specifically when in text form, sorting by text dates written in year-month-day by alphabetical order will correctly sort by date, which is nice if you’re a programmer (and the reason why when I need to have a date as part of a filename I’ll user year first). Meanwhile the advantage of day first is that often you don’t need to say the rest since if you don’t it’s implied as the present one (i.e. if I tell you now “let’s have that meeting on the 10” June and 2024 are implied) so you can convey the same infomation with less words (however in written form meant to preserve the date for future reference you have to write the whole thing anyway)

Personally I recognize that it’s mainly familiarity that makes me favour one format over the other and logically I don’t think one way is overall better than the other one as the advantages of each are situational.

Android development app that runs on a PC and can connect to an Android device via USB to control it.

Lets you do way more than what you can do directly in the Android device itself.

GMO + Capitalism = Plants modified to be resistant to specific pesticies and herbicides, increasing their use; farmers being sued due to their plants being polinized by GMO plants and so on.

The problem is not GMO, it’s GMO under low or no regulation Capitalism: it’s guaranteed that it’s going to be used in all the wrong ways even if a handful of examples are actually not (and even Golden Rice is patented, which opens the door to abuse if its use becomes widespread).

Most distrust of some powerful new tools of Science is due to how the political and economic environment we live in tends to shape the use of such tools, much more than of the tools themselves.

Well, the universe was create 6000 years ago so obviously domesticated animals have always been as they are. /s

Seeds Against Watermellons and Catholics?

Just make it a LJM (Large JSON Model) capable of predicting the next JSON token from the previous JSON tokens and you would have massive savings in file storagre and network traffic from not having to store and transmit full JSON documents all in exchange for an “acceptable” error rate.