shrug To each their own, I guess.
I can definitely appreciate that opinion, I just… disagree. I don’t really give 2 shits about a file having some stuff in it that I don’t personally use, so long as it still has a purpose. I.E. I’ll take a little clutter in a file like that, that basically never gets looked at or edited, over the chance of cluttering up the repo itself, or PRs, or history with stuff that has no purpose at all.
Anyone else dislike the idea? Like, having ignore patterns be ported automatically to everyone that wants to clone the repo just seems… always better than making people do it themselves. At basically no cost.
Me personally? Hate 'em. In every scenario. They force you to break standard naming semantics.
I mean, both sound valid. I’d say the first option is likely the most common: some kinda firewall or private network that keeps your microservices isolated from the public internet. In a practical sense, odds are all of this stuff is physically co-located anyway, so it could even be that the networks are physically isolated as well.
What you describe seems sound, but I’d say you need a final “decrypt and confirm” pass on each matched result, to work around the hash collisions, especially if you only store partial hashes, like you describe (which also seems sound).
Also, depending on your database implementation (whether it has good text-search-indexing support), it might make more sense to not recombine the hashed tokens, and instead store them in a 1-to-many mapping table.
Dear lord, why are they running a database in a browser?
Tell you what, I’ll just link a couple of recent posts/comments from elsewhere:
Vast improvements. No regrets. Still working through a few growing pains, though.
Well, THAT wasn’t on my bingo card. More power to 'em, I guess.
I never really understood the appeal of jQuery, it doesn’t do anything that you can’t do natively, and it’s not like it does any of the things it DOES do significantly better than native. Just not worth the cost of adding a dependency, for me.
5 Repeat until completion
What the fuck IS completion here? Just running indefinitely until the user manually kills the loop?
I’ll hazard a guess… OPAM was using a text-based utility to get the list of groups, and 33 is the point where the list would wrap to a new line.
No. Turning things into SPAs that should have been simple websites has been. Also developing SPAs in JS.
Alternatively, buy the physical copy and just torrent a digital one.
How should I know or figure out things like this?? When there’s no error and I don’t know why it doesn’t working other than trying different syntax until it works!
A) MDN. Never use any JS API you’ve never used before without reading the docs on MDN first. JS is kind of a massive pain in the ass to work in, but dear lord, the MDN docs are just the absolute gold standard.
B) Set yourself up with a rudimentary TypeScript build process. Not like a full managed project under npm or bun or whatever the latest fad is (unless you’ve already got a project setup like this, I guess). Just write your source files in TypeScript instead of JavaScript, setup a .tsconfig file, and run a copy of the TypeScript compiler tsc to convert 'em all to JavaScript. That’ll eliminate entire classes of errors from your code, like your attempts to write to a non-existent .width property, for example.
If you’re not familiar with TypeScript, it’s built to be exclusively a superset of JavaScript. I.E. it’s just JavaScript with some type annotations. Really, the compiler is less of a compiler, and more of just a static analyzer that trims out the type annotations.
C) You should probably also look for a JS/TS autocompletion tool, of some kind. I’m not sure what’s out there in that regard, except for Intellisense within Visual Studio, since VS is what we’re given at work. But for someone new to an API, having it be discoverable right in your editor is a DX that can’t be beat.
It’s a hobby that allows for a LOT of different types of creative expression, does not require any monetary investment to get started in, or to pursue long term, and even has a small chance to MAKE you money, if it turns out you enjoy it enough to purse that end. It has the potential to make a GREAT hobby.
I enjoyed my brief time with gRPC and protobuf, when I was trying them out, and I’d happily use them again, but I think it’s obvious why JSON and REST are more dominant.
For one, gRPC works great for simple server/client apps, but it makes them VERY tightly coupled. If your product is an API itself, open for public use, tight coupling is a hindrance more than a benefit.
And more to the point… have you ever tried to DEBUG gRPC traffic? The efficiency of gRPC is top notch, t optimizes for serialization, deserialization, and bandwidth, all at once. But JSON is human readable, and when you throw in HTTP compression, the efficiency is close enough to protobuf to serve the vast majority of scenarios. JSON is just far more practical.
Relevant article: https://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/
Long story short, whoever wrote that tutorial is wrong: you cannot guarantee invocation of finalizers. My guess would be it’s old and maybe used to work, but the inner workings of the GC have changed since then.
Unfortunately, the alternatives are really lacking. JetBrains Rider REALLY feels underbaked. No deal-breaking issues, but lots of little low-impact ones, and lots of design decisions that go against common conventions, for no apparent reason. The “Visual Studio Mode” doesn’t really help.
On top of that, I’ve had several issues with RUNNING Rider, on account of being on Bazzite, an immutable distro. It was fine on Mint, but Mint had its own troubles with my NVidia card.
Drug money.
I mean, the trouble is you gotta move the fridge to get to it, yeah? So surely nothing you’d want to get at frequently.
Christmas/Birthday presents?
Really rare house supplies? Like, say, light bulbs?
One of them portable fireproof safes with important documents?
There’s a difference between a website and a web app. Websites indeed should not require JavaScript to function. Web apps are a different beast where, yes, disabling JavaScript means you are opting yourself out of being able to use the app.