I constantly call out juniors who do things like ignore warnings, completely unaware that the warning is going to cause serious tech debt in a few months.
But Ive also unfortunately shrugged after seeing hundreds of warnings because to update this requires me to go through 3 layers of departments and we’re still waiting on these six other blockers.
Yeah I’m one of the “I only want to write this fucker once so I will make it as solid as I can” types… and my manager/team-lead/principal dev (all the same person - that’s a whole other story) is the “yolo send it” type.
We do not get on well. I’m probably going to switch teams or jobs soon.
Sure, Java can tell the difference. But that doesn’t mean that the guy writing the API cares whether or not he adds a key to the dictionary before yeeting it to the client.
That’s the thing though, isn’t it? The devs on either side are entering into a contract (the API) that addresses this issue, even if by omission. Whoever breaks the contract must rightfully be ejected into the stratosphere.
That’s exactly not the thing, because nobody broke the contract, they simply interpret it differently in details.
Having a null reference is perfectly valid json, as long as it’s not explicitly prohibited. Null just says “nothing in here” and that’s exactly what an omission also communicates.
The difference is just whether you treat implicit and explicit non-existence differently. And neither interpretation is wrong per contract.
Omission means it’s not there and I’m not telling you anything about it.
There is a world of difference between those two statements. It’s the difference between telling someone you’re single or just sitting there and saying nothing.
If there’s a clear definition that there can be something, implicit and explicit omission are equivalent. And that’s exactly the case we’re talking about here.
At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”. Conflating that with “this value does not exist” is very dangerous. JavaScript, the closest thing there is to a reference implementation for json serialization, drops attributes set to undefined, but preserves null. You seem to be insisting that null only means “explicit omission”, but that isn’t the case. Null means a variety of subtly different things in different contexts. It’s perfectly fine to explicitly define null and missing as equivalent in any given protocol, but assuming it is not.
Is SQL an API contract using JSON? I hardly think so.
Java does not distinguish between null and non-existence within an API contract. Neither does Python. JS is the weird one here for having two different identifiers.
Why are you so hellbent on proving something universal that doesn’t apply for the case specified above? Seriously, you’re the “well, ackshually” meme in person. You are unable or unwilling to distinguish between abstract and concrete. And that makes you pretty bad engineers.
If your SQL model has nulls, and you don’t have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn’t have to be keeping nulls distinct from missing values in the json schema, but it’s certainly the most straightforward way.
The world has more than three languages, and the way Java and Python do things is not universally correct. I’m not up to date on either of them, but I’m also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.
I am not the other person you were talking to, I’ve only made one comment on this, so not really “hellbent”, friend.
Yes, I am pretty sure I read the comments, although you’re making me wonder if I’m missing one. What specific comment, what “case specified above” are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don’t see any context that changes that. If you can point it out, specifically, I’ll be glad to reassess.
At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”.
Null at the SQL means that the value isn’t there, idk where you’re getting that from. SQL doesn’t have anything like JS’s undefined, there’s no other way to represent a missing value in sql other than null (you could technically decide on certain values for certain types, like an empty string, but that’s not something SQL defines).
I (think, at least) the point they’re making is that unless the API contract specifically differentiates between “present and null” and “absent” then there is no difference. (Specifically for field values.)
The point I’m making is kind of the opposite, unless the contract explicitly states that they’re the same they should not be treated as the same, because at a fundamental level they are not the same thing even if Java wants to treat them as such.
Kinda, I guess we all can agree it’s more typical to deserialize into POJO where theres is no such thing as missing field. Otherwise why would you choose Java if you don’t use types. This great precondition for various stupid hacks to achieve „patching” resources, like blank strings or negative numbers for positive-only fields or even Optional as a field.
Speaking of rate limits: Github recently blocked me because I went over a ‘secondary rate limit’ by visiting the site for the first time in a month. Has anybody experienced this?
Nah, hackthebox and many other red team simulation type sites have strict rules of engagement. You’re there to solve a puzzle as defined by hackthebox, not get around the puzzle by hacking hackthebox.
Oh no, just like if you were actually hired to do a red team simulation for a business! They would have strict rules of engagement and certain systems would potentially be defined as off-limits.
How terrible of Hackthebox to *checks notes… promote industry standard Red Team practices.
It is possible though to get newer versions using flathub or somethibg, right? (I know very little about linux, but I’m thinking of switching from win10 to debian next year.)
For normal desktop users, yeah Debian Stable + Flatpaks is a winning combo for picking the software that you want to be cutting-edge and leaving the rest to rock-solid stability. Normally Linux distros keep a full ecosystem of packages that interop and depend on each other, but solutions like Flatpak have their own little microcosm of dependencies that can be used independently of the host distro. There are also Debian Backports for when you want native Debian packages that are more cutting-edge but still compiled to work with your older base system. Backports are not available for most packages but sometimes the important ones are available, like the Linux kernel itself. You can also try to compile your own backports, but you’ll be responsible for updating it.
Yes there are ways of acquiring the latest packages even on Debian stable. Usually I end up compiling that stuff myself
If you’re at all unsure if you want to deal with Debian not pushing the latest and greatest updates you do have options such as running Debian Testing or MX Linux (which itself is based on Debian Testing)
Sure thing. Just remember its better to do things you want to do rather than waiting for things to be perfect. Lord knows its something I need reminded of sometimes
I am a little biased because I’ve been using Debian professionally for many years now but we don’t deserve Debian. It is fantastically stable and reliable and makes an excellent platform for running your services off of. If you are at all interested in offering some time and energy to the open source community, consider adopting a Debian package!
but seriously, modern FOSS distros (yes, debian is modern, damnit!) are amazingly good. you have an exceptionally high probablility of switching and staying switched.
Side note: anyone got recommendations for business software? I’ve started browsing the FOSS community here for ideas but I’m not sure what QuickBooks alternatives exist
A quick Google shows Quickbooks to be cloud-based accounting software. For FOSS accounting, GnuCash exists so you could try that (it can also run on Windows and macOS). However, it’s unlikely to have feature parity so if you like the added convenience that Quickbooks offers, see if you can use Quickbooks in a browser. Being cloud-based, they would probably build a browser version before building a Linux desktop app. If they don’t and you need to run a Windows desktop app on Linux, you can probably do this using Bottles (which uses Wine and Proton under the hood, the tech that enables the Steam Deck).
I mean yeah, but specifically I’d like something built for Linux that’s good for just basic spreadsheet stuff. I’m an electrician so I mostly just need to track jobs and accounts.
Most of (what we call) Linux OSes are formally GNU/Linux. GnuCash is as close as it gets to “made for Linux”. If you don’t want an accounting-specific application, but just generic spreadsheets, check out LibreOffice.
I highly recommend GnuCash for accounting though: a fellow board member cleaned up an org’s accounting by putting it all in GnuCash, where it was a bunch of error-prone Excel sheets before. That really made it easier to keep track and to do it right.
The best accounting software will be the one your accountant uses.
When clients are on the same platform that I use internally everything just matches up and it’s beautiful and elegant and amazing.
When clients are using something else it just doesn’t fit our workflows and it’s just more of a fuck around, which of course the client gets charged for.
That’s how I feel about arch, it’s not “stable” but the few issues I’ve had they typically have it fixed with an update within hours.
I do have to clarify when I switched to arch from windows my entire computer was brand new and practically no other distro booted or if it installed it dumped me to a black screen.
After running my server on archlinux with the stable kernel for 7 years I did install Debian on my new server. Zfs just required an older lts kernel than I could get on arch without a ton of hassle. I didn’t need it on my Mac mini with an external hard drive plugged in. From my experience it’s not very different to maintain compared to arch but it’s nice having built in automation instead of writing my own.
Man it’s weird using a system of what I can guess is a bunch of bash scripts on Debian to set things up compared to just using the tools built into and written for systemd.
“stable” in this case means that it doesn’t change often. Debian stable is called that because no major version changes are performed during the entire cycle of a release.
It doesn’t mean “stable” as in “never crashes”, although Debian is good at that too.
Arch is definitely not “stable” using that definition!
Yeah, I know the definition. I knew someone would quote it verbatim, someone always does. I quoted it because it’s not the word I would use. I like scheduled or versioned releases better but someone always disagrees with me. As far as I’ve seen it’s a major/minor version release cycle anyway.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.