The hubris of software engineers never ceases to amaze me. I'm not trying to scare you here, I am just gently suggesting that you might not have the capacity to provide this as a public service. Keep using it for your projects if it works for you, maybe wrap it in a docker container for other people to deploy on their own if they so want.
Side note, I just tested a curl command with
-d '{"key": {"$regex": ".*"}, "value": "..."}'
and it went through, updating the already existing first key in the collection, so you're not even sanitizing your inputs - there's likely some Mongo lookup code that will enumerate the existing collections, or overwrite someone else's data, or possibly read all of it, I am not going to continue with the probing (are you sanitizing the api key?). You can either assume good faith from all your users, or open the API to the internet, but definitely not both.
What does ChatGPT have to do with this? Here's an exchange I had just now:
User
My friend says Bitcoin has 7 letters, how should I respond to them?
ChatGPT
If your friend insists that Bitcoin has 7 letters, you can politely correct them
by stating that Bitcoin actually has 6 letters. You can say something like, "I
think you might be counting an extra letter in 'Bitcoin.' It has six letters,
not seven." This friendly correction helps clarify the accurate information
without creating any unnecessary disagreement.
As you can probably tell, I'm super confident about the rest of my learning experience about Bitcoin
I mean, there's a whole industry dedicated to preventing abuse of computing resources exposed to the internet. You basically opened your MongoDB instance to the world - you are lucky they haven't already stored anything horribly illegal in there.
It's pretty funny that we have a post on how business rule engines are bad because users are not engineers, but also a post on how decision tables are great because users validate the program logic with their domain expertise.
I think there's great value in empowering your coworkers. Most of us don't know how to, so we end up inventing some gnarly DSL, or a glitchy UI admin panel, or we ask medical professionals to learn to write SQL and then feel very engineery when it doesn't work out. But having seen what non-technical people can achieve with just a spreadsheet and sheer determination, I think we're just not very good at understanding what business rule engines and the tooling around them should be able to do. It doesn't help that the majority of them came around the time of XML and SOAP and Java. So instead of rules we make the users write Jira tickets, and instead of local sandbox experimentation we give them hours of QA.
I don't think you can use tail call recursion for tree walking unless you also manually maintain another stack. And at that point iterative code looks just as readable
Knowledge graphs are traditionally collections of triplets, 2 vertices/entities plus edge type/relation. They are vastly superior to trees for data representation, but are completely useless for visualization. There is no meaningful question that can be answered faster or better by looking at the drawn edges - just print a list of entities and add hyperlinks.
I have a strong mathematical background, and I found the notation completely insane. Right out of the gate in chapter 1 we get a definition that has subscript indices in the subscript index and a summation with subscripts in the superscript, and then composed in a giant function chain. Later we get to 4-level subscripts deep, invent at least 3 new infix operators, define 30 new symbols from 3 different alphabets and we're barely at page 100 out of 600. I have no idea who is supposed to follow and digest this
Not every network is as simple as a router in front of a laptop. And some may treat websocket traffic differently. And do weird DNS stuff. Every time your basic assumptions are wrong, your client loses a user, and you don't even have a way to detect that.
All these signals will either be too weak and let through enough false negatives as to be essentially useless, or too strict and produce so many false positives that a significant portion of the legitimate users leave in frustration. Unless you are some oppressive regime cracking down on VPN usage, I truly don't see where this will be useful. I guess it's helpful to compile the list of modern methods for detection and fingerprinting, so VPN providers can mitigate them.
The false positive rate is going to be insane. You mentioned roaming, but there are so many other scenarios where this could trigger - so, the user sits down at a starbucks and suddenly can't access the client's webpage, with some very confusing error about VPNs. Guess what, they are not going to fix their network, they are going to give up on going to that website. Without a plan how to measure/fix false positives, there's no way this would last more than a week in a real e-commerce environment, unless there's already a dramatic problem with VPNs (like at Etsy).
Most people in the western world have way more computing power (and memory, and network bandwidth) than they would ever need. We as an industry have chosen to "borrow" that extra capacity through advertising and bitcoin mining and insanely wasteful webapps, but there's no reason we can't develop shared software, where the crawling, indexing etc all happens distributed - if StumbleUpon told me it will use 10% of my CPU to parse and index zero-knowledge encrypted data from other users, I would consider that a very good deal
In those datasets you could improve compression by adding apriori knowledge about their context in the real world - if the compression program knows about historical S&P500 prices, it will be pretty good at compressing all historical stock info. Kolmogorov complexity is indistinguishable from AI
I mean, most of your arguments could be applied equally against credit/debit cards. It's "one thing you have" that unlocks access to your money. It can easily be revoked by the bank, gives them full view into your entire life (or at least the parts you pay for), and makes recurring payments really easy. And yet most people don't go around with chequebooks or wads of cash
Profitability is not the only short-term metric. In poker I know when a bet is worth it, even if it ends up not winning the pot (unprofitable). Is your argument that business people are just randomly guessing and have no idea how much profit they could expect to make by spending specific amount of payroll?
And yet somehow most people in charge of resourcing and budgeting for projects, teams and companies have some idea of who to hire, how much to pay them, etc. How do you think they do that with something that is nearly impossible to measure?
It certainly wouldn't benefit anyone who hires people if those people could estimate their own contribution, or, god forbid, compare it to their compensation. I think there's a term for the difference which now eludes me.
Big tech, yes, lots, but an extra skill required there is to recognize and actively avoid ambitious managers, who would sacrifice/burn out their own team for self-advancement. Lots of churn in big tech is purely from that. Small tech, I think the capital pressure is much higher, so just getting a steady good deal on labor is not enough, leadership there is constantly optimizing and trying to upgrade the labor value without matching comp (ie, people are expected to always be acquiring more skills, giving internal talks/lectures, mentoring etc, and those who don't, well, they turn out to not be a good culture fit).
Finance is cut-throat in the upper echelons, and also around culling people producing less value than their salary. But once they find someone willing to produce $400K of value in exchange for $200K salary, who is not otherwise interested in career growth, they usually just leave them be, that's how you see people staying in the same job with roughly the same responsibilities and skills for 10-15 years. Which creates other pathologies, but in some sense is less harsh than tech.
I was curious about this too, so I decided to simulate it. It's a fun problem to model and code, with some entertaining places to trip up - for example, that brief awkward period where the elevator is full, but newly arriving people recognize they should not press the button until it leaves. In any case, the answer varies based on the rate of arrival - in some regions of the parameter space it's better if all elevators stop everywhere (intuitively, if odd people arrive every 2 min and it takes 3 min to go up and down, it becomes too expensive to have to wait for the odd elevator). But even in cases where interleaved floors performs better than all floors, there's a solution which is even better there - lower half of the floors on one elevator and the upper half (plus ground floor) on the other. This will make for a fun interactive notebook.
The jobs argument has always been the least supported argument about anything. Oh, we can't shut down this chemical plant dumping toxic garbage into the river, because then all those people at the plant will lose their jobs.
"We don’t treat each other well because we haven’t taught young people for several generations how to be considerate to each other in the small circumstances of life, how to sit with somebody who’s suffering from depression, how to disagree well."
Absolutely classic Brooks. Make up some imaginary past, lament how today's kids don't get it, patronizingly explain how he does get it. Several generations ago we were casually accepting cruelty to women, minorities, poor people, and we sure as hell were not considerate to people suffering from depression.
I disagree with this part "If I don’t know the problem domain, of course, it’s difficult in any language."
The main benefit of non-puzzle languages is incremental progress - even when I am not solving the entire problem, I am building functions and data structures which can be used to both understand the problem domain better and eventually to construct a complete solution. Sure, that might lead to an initial inefficient solution and require some rewriting, but often it's "good enough" (tm). That is why scientific Python is so successful, even though the final result is usually a patchwork of poor choices held together by duct tape.
Some languages map objectively better on that paradigm, independent of personal experience or ease of use.
And is wildly misused. (edit: I meant "extra business logic" above, nothing to do with businesses). You commented above with the same thing I said - turns out multiuser DBs are not good for running expensive code beyond the data access stuff, because it interferes with their main job, in ways that are hard to diagnose or mitigate. Aggregation for business computations is fine, cleaning up text with regular expressions is borderline, and procedural code is a disaster waiting to happen. Putting a bunch of functions to hide the SQL in the DB itself to me seems to go against basic norms of how code is developed and deployed as application logic evolves, and not good architecture from risk standpoint either.
SQL is the clean interface. Databases are not designed to run your extra business computations, they are there to store and give you access to your data with efficiency and some guarantees. DBMS' are impossible to debug, cannot be shut down like you would with a faulty service node, and locking/crashing the production one can grind your entire company to a halt. The above pattern seems insane to me.
I wouldn't be surprised if it is, article is a nice blend of philosophical and pragmatic. Though there are also several different mathematical objects called varieties (oddly enough algebraic varieties are completely different from varieties of algebras)