warkanlock

Yes. We needed an essay to crack this one

Serious question: Who earns (other than C-level) $150 an hour in a sane (non-US) world?

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

You know what? Last night I watched Threads.

No kidding

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)

Try torvalds!

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.

did you read the article in the first place? this didn't expose any exception and it just keep loading to eternity until timeout

OP here; thanks for reading everyone!

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! Now, how is a mandatory security update an organizational issue?

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

Not really.

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)

OP here; thanks for reading!

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!

Honest question and no pun intended: I don't understand people's desire to prevent JavaScript from being a language that runs in the browser.

Could someone shed some light on this?

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

Knowing Verilog, I must disagree. Although it would be more beneficial if the book focused on hardware, its primary goal is to teach something other than hardware-specific definitions. HDL serves as a bridge to illustrate communication with predefined logic gates.

The book should include a mention or an appendix to clarify its real-world applications. By the end of chapter five, I was dissatisfied, feeling a lack of control over the crucial aspects of the hardware I just built. However, a book can only do justice to some of the missing pieces of information we have.

Making good (!perfect) software is a function of three constraints: knowledge, economic resources, and time.

You can mix those three together and produce a desired output, but don't expect perfection, perfect software only appears when the three variables tend to infinity

Ghost town? It's active and growing!

This is an excellent tool to realize how an LLM actually works from the ground up!

For those reading it and going through each step, if by chance you get stuck on why 48 elements are in the first array, please refer to the model.py on minGPT [1]

It's an architectural decision that it will be great to mention in the article since people without too much context might lose it

[1] https://github.com/karpathy/minGPT/blob/master/mingpt/model....

None. This was the original request.

This is a real conversation I just had with ChatGPT. A strange text appeared near the end of the prompt

This is an insightful article, although I don't necessarily agree with the view that "everyone" needs to know everything from first principles to be good at their job.

Talking about abstractions, during my past month, I was reading nand2tetris, and it's a compelling experience if you understand the exercise you are doing, which is not about building a computer from first principles; it's much more than that.

It makes you really understand what's going on behind the layers of abstracting that have been raised. Sometimes, understanding every layer of complexity is impossible, but depending on the area you are in, we need at least to try to understand the roots of it.

However, this is not for everyone; ask a musician if they are really in the weeds of why the instrument is producing music (the physics behind it!). They are probably aware that it's vibrating air, but, in general, they won't know the theory behind it.

Everything is built on abstractions, and that's OK, with time we will add even more on top of what we have; now, the issue is when those abstractions lock you in with a mindset that prevents you from creating something new without relying on those same abstractions that help you build stuff.

Many discoveries and inventions were made because they knew the layer of abstractions on top of it, and they just started again from scratch. Even Figma, the software, is built on a new core of concepts based on how the web was working back in the time [1]

[1] https://madebyevan.com/figma/introducing-vector-networks/

Actually no, it's was not an story but a blog post from an user

So, when it comes to a technology that works well, I think it should be easy to adopt for the whole team, Node.js won here even against Go. In my experience, Go seems to fit quite well there, although there are plenty of developers out there without Go skills.

But let's face it: In most of the projects we work on, clients don't need to handle millions of requests from distributed systems and geolocated servers all over the world. Generally, our clients just want a CRUD that is a little more elegant than Excel and can help them solve their real-world problems.

IMO if someone from your team tells you that you cannot do something with an average of ~10,000 req/s [1] (around that number is the consensus nowadays for Javascript whereas Bun is highly superior to everyone here), you may be solving the problem in the wrong way.

[1] That's around 36 million requests per hour!

In my experience, Node.js generally performs very well for most use cases although when it comes to data manipulation (or similar use cases), performance often goes down the hill, becoming the primary bottleneck nearly every time. It's simply not the right tool for the job.

The beauty of this is that it allows teams to isolate and optimize just the problematic portion of the code, preventing them from going down a rabbit hole of extensive changes that can be more harmful than beneficial.

NAPI is such a good tool for this; that I've been advocating the use of it to my team since forever.