Or you can just learn a handful of puzzle patterns in exchange for more job opportunities that would have the potential for higher overall pay. Seems like a fair trade to me.
It just feels obstinate to me. Most people will jump through all sort of bureaucratic/performative hoops when they're in a job to keep it or angle for promotions/minor raises, but this one that has a much higher average RoI turns them off. If you put your foot down on that sort of thing too then fair enough I suppose.
To be fair though, I don’t really want a Big Tech job. Several of the FAANGs, especially Facebook, are morally objectionable to me and I would switch careers before working for them. Most others have shitty working conditions with in-office policies, open office layouts, etc, that are detrimental to me getting work done.
So it’s not just about the financial RoI for me.
And I think I’m at least consistent: I’ve never been one to jump through hoops for raises or promotions either.
Why's that? I'm not really sure how DEFLATE works but I can imagine a crappy compression that's like "5 0" means "00000". So if you try to compress "0" you get "1 0" which is longer than the input. In fact, I bet this is true for any well-compressed format. Like zipping a JpegXL image will probably yield something larger. Much larger.. I don't know how you do that.
I'm sure there's a way for them to give enough weight if they really cared enough. I don't think they should or would, but they could stuff the training data with thousands of slight variations if they wanted to or manually give them more importance. This might adversely affect everything else, but that's another story.
I did this, but I used rsync, and you can tell rsync to use the previous ver as the basis so it wouldn't even need to upload everything all over again. Super duper quick to deploy.
I put that in a little bash script so.. I don't know if you call anything that isn't CI "manual" but I don't think it'd be hard to work into some pipeline either.
If you just slap in Zod, the server will drop the extra inputs. If you hate Zod, it's not hard to design a similar thing.
> or if client and server disagree that a field is optional or not
Doesn't GQL have the concept of required vs optional fields too? IIUC it's the same problem. You just have to be very diligent about this, not really a way around it. Protobufs went as far as to remove 'required' out of the spec because this was such a common problem. Just don't make things required, ever :-)
I wanted to refute you but you're right. It's not a security benefit. With GQL the server is supposed to null out the fields that the user doesn't have access to, but that's not automagic or an inherent benefit to GQL. You have the same problem with normal REST. Or maybe less so because you just wouldn't design the response with those extra fields; you'd probably build a separate 'admin' or 'privileged' endpoint which is easier to lock down as a whole rather than individual fields.
reply