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.

Well, the more light you reflect out the better (I would expect that, for example, darker color curtains would be a problem) and ideally you want that whatever light does get converted into heat does so outside.

As it so happens, were I live the heat has been a problem in the Summer since well before AC was invented, so roll-up external shades are standard for all houses and apartments and that stuff definitely works if used as I described it.

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.

Around here, Portugal, were every Summer the temperature exceeds 40 C for at least some days in August, we have outside rollup shades on every window, so one of the tricks is to keep the shades down and and the windows closed during the hottest and sunniest parts of the day, at the very least the afternoon.

Then at night you open the windows and let the cooler night air in (even better if you do it early morning, around sunrise, which is the coolest time of the day).

Note that this doesn’t work well with curtains or internal shades, because with those any conversion of light into heat when the light heats the shades/curtains (as they’re not mirrors and don’t reflect all light back) happens inside the house and thus that heat gets trapped indoors.

A USB DVD Reader/Writer costs 15 bucks. (I’m too used feel like that meme, and then at some point I needed to find a way to get a Mini-PC to read CDs, and as it turns out it’s quite simple - I reckon it was more a case of “can’t be arsed to do it” than a case of “can’t do it”).

Well, since I will also browse Lemmy quite literally “at Work” it makes sense to check the Profile option that blurs the Not Suitable For Work stuff even if having the Show NSFW content also ticked.

Explicitly going back and forth changing the option depending on where you’re accessing Lemmy from is a recipe for mistakes, at best embarassing but, depending on where one works, which can go all the way up to being fired for cause.

It also depends on the sorting used under All.

In my instance you generally need to scroll a lot before finding NSFW stuff when sorting by Top for anything longer than Day.

Ticking the option in user settings to “Show NSFW content” because of scientific curiosity…

You were supposed to have an antenna.

That would make it plagiarism, which ethically is a whole different matter than merelly copying that which is free to copy.

For starters, bulk copying a person’s documents without their approval sounds like mass copyright violation.

Since the user did not approve it, it sounds like mass copyright violation to me.

Not in the EU it doesn’t, unless they got the user to review that Agreement and agree before the sale took place.

After the implicit contract which is the sale has been agreed to by both parties (the buyer gave the money, the seller took it), one of the parties can’t force the other party to agree to a new contract before they’re allowed to get the contractual benefits of the original contract (i.e. the buyer getting to use the product they bought, the seller getting to use the money they got).

It doesn’t matter if the seller has such power de facto - legally they most definitelly can’t blackmail the buyer by denying them their side of the contractual rights they got in the Act of Sale by blocking their use of the product they bought until they agree to a new Agreement from the seller.

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.

Well, if you tip because you care enough about the person on the other side, you might want to try and come up with a way to leave them a tip somehow so that there is no risk it’s taken away from them, assuming that you can. Put $5 under the rug and let them know, or something.

If you can’t, you can’t, and I’m hardly going to criticize you for not wanting to catch an airborne infectious disease.

I was pretty miffed in the UK (years ago) when it came out that lots of companies (there it was mainly restaurants) were just keeping the tip money when people payed by card and filled-in a tip amount, so I very much made an effort to as much as possible make sure the actual people got the tip directly - even if I stood out from the crowd by doing it - as I don’t see the point in tipping the company.

When I tip the driver in a delivery I literally just give them cash when they deliver (and only if they actually arrive with some promptness, not if they come half an hour late with a cold pizza).

It’s a habit I got into when living in the UK because there, like in the US, lots of companies just take the “tip” money and keep it if you tip whilst paying with card.

Granted, I like to pay stuff with cash, both for privacy reasons and because it has actually been shown that people in average spend less if they pay in cash (something to do with the feeling of giving something physical away), so I almost always have some cash to pay and tip.

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

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).