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.

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?!

The amount of effort I do to try and avoid using double parentesis is trully herculean.

I think that stuff is the product of a completionist/perfectionist mindset - as one is writting, important details/context related to the main train of thought pop-up in one’s mind and as one is writting those, important details/context related to the other details/context pop-up in one’s mind (and the tendency is to keep going down the rabbit hole of details/context on details/context).

You get this very noticeably with people who during a conversation go out on a tangent and often even end up losing the train of thought of the main conversation (a tendecy I definitelly have) since one doesn’t get a chance to go back and re-read, reorganise and correct during a spoken conversation.

Personally I don’t think it’s an actual quality (sorry to all upvoters) as it indicates a disorganised mind. It is however the kind of thing one overcomes with experience and I bet Mr Torvalds himself is mostly beyond it by now.

It was about as prescient as “640k is enough for everybody”, but in a good way.

I got an Orange Pi 5 Plus to play with smallish AIs (because it has an NPU) and I normally access it remotely, so I have to know its IP address to do it.

In order to easilly know the IP address of it, I’ve wired a little 128x64 monochrome OLED screen to it (Orange PIs, like Raspberry PIs have a pin connector giving access to GPIO and interfaces like I2C, Serial and SPI) which talks via I2C.

Turns out those interfactes aren’t active in Linux by default (I.e. no /dev/i2c-x), so I figured out that I had to add a kernel overlay to activate that specific interface (unlike with the Raspberry PI whose Linux version has a neat program for doing it, in the Orange Pi you have to know how the low level details of activating those things), which I did.

To actually render characters on that screen I went with an ARM Linux port of a graphics library for those screens I used before with Arduino, called u8g2)

Then I made a program in C that just scans all network interfaces and prints their names and IP addresses on that screen, and installed it as a Cron job running once a minute.

Now, as it turns out when you shutdown your Linux on that board, if you don’t disconnect it from power there is actually still power flowing through the pin connector to any devices you wire there, so after shutdown my screen would remain ON and showing the last thing I had put there, but because the OS was down it would naturally not get updated.

So the last thing I did was another small C program which just sends to that screen the command for it to go into power saving mode, shutting it down. This program was then installed as a Systemd Service to run when Linux is shutting down.

The result is now that there is a little screen hanging from the box were I put this board with Linux which lists its IP addresses and the info is updated if it connects other interfaces or reconnects and gets a new IP address. Curiously I’ve actually been using that feature because it’s genuinely useful, not just a funny little project.

The whole business model of Apple is to force a hardware upgrade cycle on you and force all your devices to be in that same ecosystem.

I mean, I can see the advantages of it on the short term, but on the longer term having stuff that keeps on working even as always even in older hardware (or you just install new hardware under it and it just recognizes it and keeps on working) is a massive benefit versus a $1500+ bill every two five years and having to migrate your stuff.

Having done the transition some months ago, there is still some stupid shit one has to deal with (especially, but not only, for games NOT from Steam) at times, more than in Windows, but it’s all so much better than it was before and by now quite close to the Gaming experience in Windows.

Then on top of that there are all the the longer term peace of mind things versus Windows: upgrading your Linux costs zero, changing your hardware won’t invalidate your Linux “OEM License” (plus it will probably just boot up as normal with if you just move your SSD to a whole new machine rather than throw you into driver nightmare), games that work in today’s Linux will keep on working in tomorrow’s and so on - this is actually massive advantage of Linux versus Windows which is seldom talked about: more often than not, hardware migration with Linux is to just move your SSD to a whole new machine, with all the stuff just the way you like it and all you files, and it just boots with and keeps on working.

(PS: Especially relevant for gamers who have to upgrade due to the increasing demands on hardware from the gaming side of things even though the hardware is fine for everything else they do in that machine, and who would rather that all those other things they’ve installed and kept on using rather than uninstall after “finishing the game”, just carry on configured just the way they like it and working just the way they’ve always did, even when they do upgrade the hardware because of games. People who are fine with hardware dedicated to gaming and with replacing the whole thing - hardware and software - for newer games, just get XBoxes or similar consoles, not PCs)

Linux not only saves you from enshittification, keeps control in your hands and preserves your privacy, it’s also a reliable and functional long term OS layer for your hardware that doesn’t force hardware upgrades on you.

At this rate the Year Of Linux On The Desktop will be 2033!!!

More generally: delegate anything critical to a 3rd party and you’ve just put your business at the mercy of the quality (or lack thereof) of their own business processes which you do not control, which is especially dangerous in the current era of “cheapest as possible” hiring practices.

Having been in IT for almost 3 decades, a lesson I have learned long ago and which I’ve also been applying to my own things (such as having my own domain for my own e-mail address rather than using something like Google) was that you should avoid as much as possible to have your mission critical or hard to replace stuff dependent on a 3rd Party, especially if the dependency is Live (i.e. activelly connected rather than just buying and installing their software).

I’ve managed to avoid quite a lot of the recent enshittification exactly because I’ve been playing it safe in this domain for 2 decades.

Also a lot of people were “on call” to handle any problems when the year changed, so the few problem that had passed unnoticed when doing the fixed and did pop up when the year changed, got solved a lot faster than they normally would.

I was already a dev in a small IT consultancy by the end of the decade, and having ended up as “one of the guys you go to for web-based interfaces”, I did my bit pushing Linux as a solution, though I still had to use IIS on one or two projects (even had to use Oracle Web Application Server once), mainly because clients trusted Microsoft (basically any large software vendor, such as Microsoft, IBM or Oracle) but did not yet trust Linux.

That’s why I noticed the difference that Red Hat with their Enterprise version and Support Plans did on the acceptability of Linux.

Just to add to this, early on there was no such thing as kernel modules, so you had to compile your own kernel with the hardware support you needed for anything beyond basic (if I remember it correctly, it was only basic processor stuff, keyboard and text mode VGA) hardware support.

CRT monitors internally use an electron gun which just fires electrons at the phosporous screen (from, the back, obviously, and the whole assembly is one big vacuum chamber with the phosporous screen at the front and the electron gun at the back) using magnets to twist the eletcron stream left/right and up/down.

In practice the way it was used was to point it to the start of a line were it would start moving to the other side, then after a few clock ticks start sending the line data and then after as many clock ticks as there were points on the line, stop for a few ticks and then swipe it to the start of the next line (and there was a wait period for this too).

Back in those days, when configuring X you actually configured all this in a text file, low level (literally the clock frequency, total lines, total points per line, empty lines before sending data - top of the screen - and after sending data as well as OFF ticks from start of line before sending data and after sending data) for each resolution you wanted to have.

All this let you defined your own resolutions and even shift the whole image horizontally or vertically to your hearts content (well, there were limitations on things like the min and max supported clock frequency of the monitor and such). All that freedom also meant that you could exceed the capabilities of the monitor and even break it.

In the early 90s all the “cool kids” (for a techie definition of “cool”, i.e. hackers) at my University (a Technical one in Portugal with all the best STEM degrees in the country) used Linux - it was actually a common thing for people to install it in the PCs of our shared computer room.

Later in that decade it was already normal for it to be used in professional environments for anything serving web pages (static or dynamic) along with Apache: Windows + IIS already had a lower fraction of that Market than Linux + Apache.

If I remember it correctly in the late 90s RedHat started providing their Enterprise Version with things like Support Contracts - so beloved by the Corporates who wanted guarantees that if their systems broke the supplier would fix them - which did a lot to boost Linux use on the backend for non-Tech but IT heavy industries.

I would say this was the start of the trend that would ultimately result in Linux dominating on the server-side.

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.