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.
'The wind keeps blowing my wifi signal away ' is more than enough information to diagnose the problem, and 'the computer forgot my password' is now a real thing since password managers started coming baked into browsers.
We are so far beyond parody of ourselves that i have no idea how the onion stays in business.
How could you be simpler than keepass? Like, there’s more advanced features, but for basic function, its just a password to access a list of passwords.
…its just a password to access a list of passwords.
Unless you never thought of, implemented, regularly did and regularly tested your backup of the database. Or… try to use it on more than one device - maybe even at the same time.
That’s the main problem with KeePass. It’s nice to have it offline, fully under your control and out of the cloud, but that comes with some responsibilities on your end. And now think of how the average user solves this. If you’re tech savvy enough, KeePass is great!
You technically only need it on one device if you don’t want to be able to copy/paste or use the autotype feature. Which works fine until you lose or break that one device or upgrade to a new one and forgot you needed to transfer your passwords or delete your database because you didn’t remember what it was and wanted to free up space.
And Bitwarden has scary things like “self-hosting”.
Setup syncthing between the computers. If the person is not tech savy enough, they can always force the tech savy enough person they know to set it up for them. The are no problems with the tech, people just dont know it exists. Even if you don’t or can’t use syncthing (iOS users), you can just be stupid and put it in the cloud.
"What do you tell someone to type when you want them to send you an email?" should work if the person has irl or phone social connections, which is still the case for a lot of older folks
Yes no clearly clearly. I never would have tried that. Thank you for your insight. I don’t know how I would have missed that. No clue just pure flabbergasted over here
To whoever does that, I hope that there is a special place in hell where they force you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.
Sadly it doesn’t fix the bad documentation problem. I often don’t care that a field is special and either give a string or number. This is fine.
What is not fine, and which should sentence you to eternal punishment, is to not clearly document it.
Don’t you love when you publish a crate, have tested it on thousands of returned objects, only for the first issue be “field is sometimes null/other type?”. You really start questioning everything about the API, and sometimes you’d rather parse it as serde::Value and call it a day.
The worst thing is: you can’t even put an int in a json file. Only doubles. For most people that is fine, since a double can function as a 32 bit int. But not when you are using 64 bit identifiers or timestamps.
That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.
Unless you’re dealing with some insanely flexible schema, you should be able to know what kind of number (int, double, and so on) a field should contain when deserializing a number field in JSON. Using a string does not provide any benefits here unless there’s some big in your deserialzation process.
What’s the point of your schema if the receiving end is JavaScript, for example? You can convert a string to BigNumber, but you’ll get wrong data if you’re sending a number.
I’m not following your point so I think I might be misunderstanding it. If the types of numbers you want to express are literally incapable of being expressed using JSON numbers then yes, you should absolutely use string (or maybe even an object of multiple fields).
I am not sure what could be the example, my point was that the spec and the RFC are very abstract and never mention any limitations on the number content. Of course the implementations in the language will be more limited than that, and if limitations are different, it will create dissimilar experience for the user, like this: Why does JSON.parse corrupt large numbers and how to solve this
This is what I was getting at here programming.dev/comment/10849419 (although I had a typo and said big instead of bug). The problem is with the parser in those circumstances, not the serialization format or language.
I disagree a bit in that the schema often doesn’t specify limits and operates in JSON standard’s terms, it will say that you should get/send a number, but will not usually say at what point will it break.
This is the opposite of what C language does, being so specific that it is not even turing complete (in a theoretical sense, it is practically)
Then the problem is the schema being under specified. Take the classic pet store example. It says that the I’d is int64. petstore3.swagger.io/#/store/placeOrder
If some API is so underspecified that it just says “number” then I’d say the schema is wrong. If your JSON parser has no way of passing numbers as arbitrary length number types (like BigDecimal in Java) then that’s a problem with your parser.
I don’t think the truly truly extreme edge case of things like C not technically being able to simulate a truly infinite tape in a Turing machine is the sort of thing we need to worry about. I’m sure if the JSON object you’re parsing is some astronomically large series of nested objects that specifications might begin to fall apart too (things like the maximum amount of memory any specific processor can have being a finite amount), but that doesn’t mean the format is wrong.
And simply choosing to “use string instead” won’t solve any of these crazy hypotheticals.
As if I had a choice. Most of the time I’m only on the receiving end, not the sending end. I can’t just magically use something else when that something else doesn’t exist.
Heck, even when I’m on the sending end, I’d use JSON. Just not bullshit ones. It’s not complicated to only have static types, or having discriminant fields
You HAVE to. I am a Rust dev too and I’m telling you, if you don’t convert numbers to strings in json, browsers are going to overflow them and you will have incomprehensible bugs. Json can only be trusted when serde is used on both ends
This is understandable in that use case. But it’s not everyday that you deal with values in the range of overflows. So I mostly assumed this is fine in that use case.
Well, apart from float numbers and booleans, all other types can only be represented by a string in JSON. Date with timezone? String. BigNumber/Decimal? String. Enum? String. Everything is a string in JSON, so why bother?
Well, the issue is that JSON is based on JS types, but other languages can interpret the values in different ways. For example, Rust can interpret a number as a 64 bit int, but JS will always interpret a number as a double. So you cannot rely on numbers to represent data correctly between systems you don’t control or systems written in different languages.
No problem with strings in JSON, until some smart developer you get JSONs from decides to interchangeably use String and number, and maybe a boolean (but only false) to show that the value is not set, and of course null for a missing value that was supposed to be optional all along but go figure that it was
And also, it’s actually a complicated question. A one-man boycott doesn’t do anything. If you work at a FAANG, work for a better world when you’re off, and go whistleblower when they do something really evil, I find no fault in that at all.
The other consideration is that pretty much every company you could work for as a software developer is going to try to take advantage of your work. Most companies are morally bad at best and morally terrible at worst. If you discourage any good person from working there, the problem will only snowball from there.
If working at FAANG gives you the resources to support things you’re passionate about, and you’re willing to stand up for your values when they do something bad, there isn’t a problem with that IMO.
My point wasn’t that FAANG isn’t exploitative (my bad if it came off that way, I didn’t mean for that), it’s that everywhere else is also exploitative to some degree (most probably less so than FAANG, there are definitely a few that are worse though), and that it could still be reasonable to work there for some people.
Bioinformatics isn’t used only for medical research or within big companies. Sub-topics like metagenomics, that are helpful in many areas of research, require high level of technical knowledge, that the life science people don’t have.
Agreed. Just working for somebody bad doesn’t necessarily mean you’ve given up, though. I mean, they made a movie about Schindler, and we all know who he worked for.
Why not? Unlike Schindler you don’t have to worry about how many beatings are necessary to keep up appearances, and you might have a specific role that exposes you to very little evil at all. Meanwhile, you can donate some of that big wage to people like EFF, or volunteer using the flexible schedule.
You can do all those things while also not supporting FAANG
Depends. If you can find another employer that’s more ethical (which is not guaranteed just because they’re smaller) and pays as much with as flexible a work schedule, yeah, you should probably do that. Otherwise it might indeed be necessary.
I don’t know, are we doing concequentialist ethics here, or deontological? I feel like we’ve reached the level of splitting hairs where we need to decide. For the purpose of actual advice people reading might follow, I’d say just try and be a good person, and don’t let perfect be the enemy of better.
And go bankrupt when something happens on the way to work because they slipped and fell on the ankle.
Thanks, but I’ll take lower pay over financial bankruptcy.
Yeah, that’s true. It amazes me how some of my team in NYC will make double what I make, but live like I lived when I was a student, and be amazed that I own a car.
I was kind of assuming that, since FAANG are American, but I’d guess they probably have foreign employees as well.
Canadians make pretty much the same as Europeans, I think. The Americans have a bunch of monopolies, and are characteristically weird and nationalist about who they share the spoils with. (I know, it’s not all of you guys, but it’s definitely some)
Speaking at a software conference in 2009, Tony Hoare hyperbolically apologized for “inventing” the null reference:[26] [27]
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Huh, so Tony Hoare invented null and then Graydon Hoare invented Rust, immediately terminating the existence of null which does not have a traditional null value.
Man Nvidia users are going to be stoked when the get explicit sync in they’re desktop environments in two years. 😂 They’re have been so many small improvements in the Nvidia drivers up until that point I hope they actually update Nvidia drivers on Debian. I understand some of those improvements are not going to work because of the kernel version and the desktop versions.
I’m using mxlinux “ahs” version, it comes with kde at their “ahs” repos for supporting latest hardware and graphics cards. You may also check for the non-ahs, there might be a meta-package for kde plasma and that’s it…
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.