A simple on/off toggle isn't going to prevent them from using your data. If your data is in their server then it's going to be used one way or another. Whether in an anonymous way or shipped to where there are no privacy laws.
Yep, did the same thing too. It's nice that you just need one tool to unscrew, screw things and everything is labelled well that you don't need to go dig to multiple websites on how to do repair/replace parts.
But of all things, replacing keyboard was the most tedious one in framework with so many screws, haha.
It never occurred to me to lookup the creator of the tool[1] that I used to use so often. It's so easy to overlook that there are actually humans with their own story (tragic or not) behind the tools that we use.
I should learn to appreciate people behind the code more. And, I'm so sorry what you had to and are going through, Mr. Meyer.
And the reason they suck is the feedback loop is just too high as compared to running it locally. You have to jump through hoops to debug/troubleshoot your code or any issues that you come across between your code and output of your code. And it's almost impossible to work on things when you have spotty internet.
I haven't worked on extremely sensitive data but for PII data from prod to dev, scrubbing is a good practice to follow. This will vary based on the project/team you're on of course.
Oh for sure. I use it as smart(ish) autocomplete to avoid typing everything out/looking up in docs everytime but the thought of prompt engineering to make an app is just bizarre to me. It almost feels like it has more friction than actually writing the damn thing yourself.
Most of the time the entire apps are just a timer app or something simple. Never a complex app with tons of logic in them. And if you're having to write paragraphs of texts to write something complex then might as well just write that in a programming language, I mean isn't that what high-level programming language was built for? (heh).
Also, you're not the only one who's had the thought that someone is vested in someway to overhype this.
Yeah, I'm curious how others are using too. For boilerplate code and configs, they're great in a sense that I don't have to open docs for reference but other than that I feel like maybe I'm not fully using it to its full potential like others are mentioning.
Yeah, that's what I've noticed too. Conceptually, they're more or less same giving an option of RBAC, ABAC or ReBAC and each offer their own DSLs (e.g. Oso, Ory Keto etc) and deployment strategies. It's been a bit harder to pick one honestly but I guess I'll just have to just use them to find which one fits for me.
This feels very much like OpenFGA[0]. I've been evaluating authorization tool for one of my side projects and honestly most tools feels like creating relationships in a graph-like database and querying to see if there is/isn't relationship between two entities. Is there more to this (besides the implementation details) or am I missing something from these tools?
Heh I had the same experience but with bun. Lots of subtle bugs on stream and crypto packages where I spent a lot of time trying to figure out what was wrong only to find that it's a known bug in bun. I would have understood that there'd be bugs in relatively new runtime that's undertaking this huge task but it's not drop-in replacement for node as it claims to be and I wouldn't say v1 is stable at all.
Because the chance of you dying when something goes wrong in an aircraft at high altitude is significantly higher (almost 100%) than you dying in a car crash. There's still a chance of you getting ambulance on road accidents but you're plummeting to your death on major aircraft malfunction.
Likewise, same result for me too but I get it. It's a language model. It makes a best guess based on the information it was provided so I trust it on the things I'm familiar with but verify on those that I'm not.