Que haces che! Two of us from Argentina; it seems like a traditional thing with inflation that my father taught me a long time ago to keep food for at least 2 weeks.
I'll try to do the same with the pills, sounds reasonable and low-effort
A classic of self-promotion. So, with your own criteria, technically, we can say also you “copied?" the name, concept, style of this previous application developed by the Santa Fe Institute https://en.wikipedia.org/wiki/Swarm_(simulation)
One thing I realized after living in Sweden for eight months is the lack of third places, or at least third places similar to what I found in Italy. In order to go to a place, you need to pay, book an appointment, and be "known." Living in Turin, on the other hand, was a story of magical encounters in the street, bars, clubs, etc. These third places (Murazti, for example) gave me people who have now become very good friends of mine that I can trust.
For me, as an immigrant in both countries, it's essential to have those places, and the lack of them made me depressed, sad, and even suicidal (during the Swedish winter).
Not having someone to talk to is sad and unhealthy. Let's not make this an endangered species; it is a public health issue.
You don't have a mechanism of trust in Javascript. Typescript up to this point is just sugar syntax. npm is a dumpsterfire (see npm everything package)
If you are not intimidated by the complexities of this Babel tower, it's up to you. For me, this was just a personal catharsis in my personal blog that I wrote mostly for me (and I didn't share it here)
I believe there's no point on discussing this with particularly you since you have been commenting all around trying to just confirm your view instead of just comprehend that this is not sustainable for new developers (try to follow the conversations on packaging, lol)
It's simply too much burden just to maintain someone else mess. We will pay a high bill in the future for all of this.
While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things and then try to prove those, but it's just too hard to keep track of everything.
In addition, we are using lock files and good practices but it's just too much to handle for our small team (small startup) so we will plan to migrate onto a more stable platform.
It's really funny the heated arguments this post generated but I have been using Javascript for 12 years to these days, still this looks as a nightmare to me.
Tsdoing has a good video trying to install React from scratch, that's exactly how I felt during this debugging process
Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)
Thanks for reading it! It's the first one to get comments on my blog lol.
Yes we did use lockfiles, all over the place. However each service had a different (and mandatory) security update that modified the libraries with a non-breaking change.
From now on I will try to establish a fixed policy although given the frequency of updates in the ecosystem it will become deprecated rather quickly
It partially helps but in the article I mention the package it had a change, a minor (non-breaking) one, that caused A to affect B without us having a direct explanation as to why.
Locking helps on packaging, it reduces the problem of packages being updated without your control but it doesn't help interdependency or the other things I mentioned (not even talking about security here)
While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things and then try to prove those, but it's just too hard to keep track of everything.
Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)
My answer was not related to price (it's a free and open market!) but mostly to the communication behind it:
Maybe you should focus on the value (rate limiting is not a value!) your product produces, the market you want to reach, etc., rather than just rate limiting because it's an issue addressed at almost every layer of the OSI model. If you sell your product as a developer, to developers, the developers will say why? because they know it's quite easy to set up a simple rate limit. Show us why rate limiting is not simple enough (I'm honestly with you here), and money will rain.
Why is your product better than a two-line configuration? if that question isn't answered on your home page, I'll say, "Wtf, does it have a pricing page?".
Maybe adopting a free-premium subscription model is better, in case you want to distribute rate limiting, but mostly I don't think it's about that, but maybe a company-level distribution, like, "I have a small business, I need to put something on top of it, this something needs to have permissions, accesses, etc, across my domain. If so, take my money."
I didn't want to sound harsh, but it's a finite game, and I'm against those! (recommendation here to read Finite and Infinite game)
This is not for you in particular, but as a community, we need to stop adding pricing pages to interview projects one can do in an afternoon. We are better than this. Yesterday, it was a compressor that was a wrapper on ffpmg. Now, a literal wrapper of a library.
Everyone wants to get rich, and I understand that, but seeing these projects have a pricing page is pretty annoying. Of course, I'll move ahead and not buy it, and I get it, but as developers, we need to see this era as an era to build better stuff, not just play these finite games.
I started as an engineering manager (CTO of a small startup) a few years ago; my life has changed a lot, and for every aspect you love and hate, I share the same feelings.
My additional advice here is to meditate. For real. Sit quietly long enough for your brain to switch off before making essential and impactful decisions that could harm your people.
In the beginning, you become a kind of parent-to-child genius. You have to accept them and also understand their ways. The more controls you put in place, the less control you will have, as they will attempt to jump around and oppose the unnecessary bureaucracy (I'll do the same, honestly).
My second advice is to always behave as if you are going to leave tomorrow. This will prepare your team and your peers and even improve your lifestyle.
If anyone is receiving these types of logs on AWS, please do yourself a favor and place AWS WAF in front of your VPC.
It's not expensive and can significantly help you, saving you from many headaches in situations like this. While it might not block everything that arrives at your service, it can be a great help!
It's one of my favorite programming books that makes you realize how quickly you can become confused by the latest trends and shiny new best practices, losing focus on what's important: being a productive and efficient individual contributor when doing something you love