If there are no humans in the loop, sure, like for data transfer. But for, e.g., configuration files, i’d prefer a text-based solution instead of a binary one, JSON is a nice fit.
What I’d like for a configuration language is a parser that can handle in-place editing while maintaining whitespace, comments, etc. That way, automatic updates don’t clobber stuff the user put there, or (alternatively) have sections of ### AUTOMATIC GENERATION DO NOT CHANGE###.
You need a parser that handles changes on its own while maintaining an internal representation. Something like XML DOM (though not necessarily that exact API). There’s a handful out there, but they’re not widespread, and not on every language.
Is a very good idea providing much needed fixes to the JSON spec, but isn’t really what I’m getting at. Handling automatic updates in place is a software issue, and could be done on the older spec.
Hmm, maybe I am missing the point. What exactly do you mean by handling automatic updates in place? Like, the program that requires and parses the config file is watching for changes to the config file?
As an example, Klipper (for running 3d printers) can update its configuration file directly when doing certain automatic calibration processes. The z-offset for between a BLtouch bed sensor and the head, for example. If you were to save it, you might end up with something like this:
<span style="color:#323232;">[bltouch]
</span><span style="color:#323232;">z_offset: 3.020
</span><span style="color:#323232;">...
</span><span style="color:#323232;">#*# <---------------------- SAVE_CONFIG ---------------------->
</span><span style="color:#323232;">#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
</span><span style="color:#323232;">#*#
</span><span style="color:#323232;">[bltouch]
</span><span style="color:#323232;">z_offset: 2.950
</span>
Thus overriding the value that had been set before, but now you have two entries for the same thing. (IIRC, Klipper does comment out the original value, as well.)
What I’d want is an interface where you can modify in place without these silly save blocks. For example:
Since we’re declaratively telling the library what to modify, it can maintain the AST of the original with whitespace and comments. Only the new value changes when it’s written out again, with a comment for that specific line.
Binary config formats, like the Windows Registry, almost have to use an interface like this. It’s their one advantage over text file configs, but it doesn’t have to be. We’re just too lazy to bother.
It’s entirely disingenuous because who the hell is throwing JSON into YAML without converting it? Oh wow, I changed the file extension and it still works. I’m so glad we changed to YAML!
Until someone cannot tell the difference between tab and space when configuring or you miss one indentation. Seriously, whoever thinks indentation should have semantic meaning for computers should burn in hell. Indentation is for us, humans, not computers. You can write a JSON with or without indentation if you want. Also, use JSON5 to have comments and other good stuff for a config file.
I use JSON. I have used Avro for things in Kafka but I’m not sure the benefits outweigh the negatives. Avro is much more complicated than people think and most folks don’t really have a strong desire to learn how it should be used and do stuff incorrectly. Everybody knows JSON and it works with everything though. (Example: so many people just hear that Avro schemas can be backwards compatible but have zero idea that you still need the schema that wrote the message even if you want to read it into a newer one.)
Interestingly, I take the meme as saying a dev is using the wrong types in their serialization format (using strings to store integers) which was my biggest problem with Avro. Mostly from people not using logical types or preferring to use ISO 8601 datetime strings instead of the built-in timestamp-millis type.
Hell, no. If I wanted to save bytes, I’d use a binary format, or just fucking zip the JSON. Looking at a request-response pair and quickly understanding the transferred data is invaluable.
My experience is exactly the opposite. I don’t work for a FAANG but I’ve been around the block a bit. Its always the junior devs that try and add new warnings etc to the code base. I always require warnings to be cleaned up even if that means disabling specific instances (but not the whole rule) because the rule is flagging a false negative.
That’s why I said false negative. The medical test is testing for the presence of a disease. So if they find the disease is considered a positive test (it found what it was looking for). For static analysis on code, its the opposite. Its testing if your code is free of issues that it can detect. If it finds no issues, then the test was positive. If does find issues, the test failed and each issue is a negative that contributed to the test failing.
You could say “A static analysis tool is testing for the for the presence of defects” or “a medical test is testing if your body is free of diseases that it can detect” to change how you’re looking at either of the tests in the previous comment.
By your logic it would be a positive for your code to have errors/warnings. And on the latter, that would appropriate if there was a test that determined if you are free from all known diseases (or at least those that it can detect).
Is it a positive to have pathogens that cause dengue/malaria in your blood? Yet we still say that someone tested positive for dengue if they have the virus.
Static analysis tools don’t test for all known issues either, no?
I’m not debating. It is not a matter of opinion. I’m doing you the courtesy of informing you how the entire rest of the world uses the term.
If action A looks for thing X, and it finds thing X, then the test is positive. If action A fails to find thing X, then the test is negative.
If action A claims to find thing X, but later confirmation determines that thing X is not really there, then this situation is called “false positive”.
If action A claims fails to find thing X, but later confirmation determines that thing X is actually there, then this situation is called “false negative”.
That thing X may subjectively be considered an unwanted outcome has **nothing ** to do with the terms used.
It boils down to desensitization/normalization. Warnings (and errors, of course, but tests as well) exist for a reason. If you don’t care about these gauge constructs are telling you, then they have no real diagnostic value. Getting into a place where you’re not looking at how your systems are actually running is generally a bad idea, especially in the long run.
The “what do we even pay you for?” is just like with projects:
“why isn’t this finished yet?”
We have to add tests and make sure we’ve tried to cover our bases.
“that’s not necessary, if it works now, just release it” That’s not-
“I don’t care, I pay the bills”
Sure thing boss. a few weeks later “This thing doesn’t work”
Yeah, it’s what we wanted to test.
“Well why didn’t you?”
😐
This person, nay, this legend, has reached across language barriers and opened up entire new worlds to people who suffer from lacking or outdated documentation.
If you or your loved ones are afflicted by bad documentation, please voice your grievances to whatever ticket or email chain deserves to be told their documentation is absolute ass.
Yes, I can read the code API, now delete that old ass mess. If you don’t want to communicate it, let someone else have those search engine results.
I have a friend who works for a local, but widespread bank, and got to head up their digital security and IT stuff. Not sure what all it encompasses, but he quickly found out that it was a lot, and the previous guy quit because he had had enough bullshit.
Long story shorter, after a particularly bad week, he decided to just… Stop doing his job.
Kept all their legal stuff and sensitive info under lock and key, but the smaller stuff, he just let it go. Went on vacation, turned everything off, didn’t do everything for a temporary replacement (which isn’t even his job, it’s hr’s) and spent a week playing video games and spending time with his wife and baby.
Several employees just in his building basically ended up doing nothing by the end of the first day because they had locked themselves out of the system.
By day 3 there were several lines that couldn’t be used by the tellers in every branch, older employees were bricking their systems so fast, construction workers started taking notes.
By the end of the week they had people showing up at his door to try and contact him since nobody could get ahold of him. Some legit thought he was dead.
His first words when he got into the office on Monday, we’re “THAT is why you pay me.”
And after that, he was given 3 people to help out (he had been asking for 4) and they had a company come in and redo a lot of the computer systems that year.
Still works for the bank, still has a team although I think they’re bigger now since they’ve opened a few more branches, and still tells that story at every gathering after his one single beer gets him tipsy.
Is it just me, or do programmers only come in “lightweight” and “Rivals Þor in trying to drink the oceans dry” varieties?
Is it just me, or do programmers only come in “lightweight” and “Rivals Þor in trying to drink the oceans dry” varieties?
Somehow I manage to be both. My alcohol tolerance is very high (which is great… I like a little buzz but never want to be actually drunk), but for me, one toke is over the line.
Two cocktails will get me tipsy, two beers if they’re strong, but I can drink an entire bottle of vodka (over the course of 2-3 hours) without blacking out. Or at least I could in college, I’m not looking to try again.
If you’re branching logic due to the existence or non-existence of a field rather than the value of a field (or treating undefined different from null), I’m going to say you’re the one doing something wrong, not the Java dev.
These two things SHOULD be treated the same by anybody in most cases, with the possible exception of rejecting the later due to schema mismatch (i.e. when a “name” field should never be defined, regardless of the value).
It gets more fun if we’re talking SQL data via C API: is that 0 a field with 0 value or an actual NULL? Oracle’s Pro*C actually has an entirely different structure or indicator variables just to flag actual NULLs.
Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.
Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you’ve created.
There’s a huge difference between checking whether a field is present and checking whether it’s value is null.
If you use lazy loading, doing the wrong thing can trigger a whole network request and ruin performance.
Similarly when making a partial change to an object it is often flat out infeasible to return the whole object if you were never provided it in the first place, which will generally happen if you have a performance focused API since you don’t want to be wasting huge amounts of bandwidth on unneeded data.
The semantics of the API contract is distinct from its implementation details (lazy loading).
Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn’t rely on that misfeature.
As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn’t have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.
Tell me how you change the name without knowing the age. You fundamentally cannot, meaning that you either have to shuttle useless information back and forth constantly so that you can always patch the whole object, or you have to create a useless and unscalable number of endpoints, one for every possible field change.
As others have roundly pointed out, it is asinine to generally assume that undefined and null are the same thing, and no, it flat out it is not possible to design around that, because at a fundamental level those are different statements.
Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).
I.e. waste a ton of bandwidth sending a ridiculous amount of useless data in every request, all because your backend engineers don’t know how to program for shit.
It’s about making APIs more flexible, permissive, and harder to misuse by clients. It’s a user-centric approach to API design. It’s not done to make it easier on backend. If anything, it can take extra effort by backend developers.
But you’d clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.
Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching
Bruh, there’s a difference between the one or two serializing packages used in each language, and the thousands and thousands and thousands of developers who miscode contracts after that point.
Only if using JSON merge patch, and that’s the only time it’s acceptable. But JSON patch should be preferred over JSON merge patch anyway.
Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.
JSON patch is a dangerous thing to use over a network. It will allow you to change things inside array indices without knowing whether the same thing is still at that index by the time the server processes your request. That’s a recipe for race conditions.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.