HN user

wiennat

66 karma
Posts1
Comments28
View on HN

Cool story and congratulations on your work.

-------

I gave my 2010 macbook pro to my parents when I got a new one in 2015. They still use it to surf the internet and sometimes for netflix before bedtime. Its battery is so swollen that the lid cannot close anymore.

I also bought apple care but never had any chance to use it. Very impressive for a computer without any hardware failure for 12 years.

I heard its name frequently around the time before nginx came to its fame. Maybe 15 years ago. However, I never heard any major players use it after that.

I am also in the middle of moving off graphql to REST api. It is a 5 years old project and the graphql part was implemented with a very old spec. Since it has not been well maintained, it could not catch up with any features offered by graphql and users need to write their own queries by hand due to spec compatibility.

Rewriting it to REST allows us to "rebrand" these apis. At least, it does not scare our api users as the word "graphql" did.

It can be introduced at many points.

in dev: You can setup dependencies without worrying about underlying os. So it is easier for building a new dev machine, adding a new team member, etc.

in integration test: you can setup multiple integration test environment as long as you have enough resource. Running multiple integration tests without interfering other team members is the major benefit here.

in prod: as you may know, for isolation and horizontal scaling. Easier roll back and update?

Not only sewage infrastructure in Thailand cannot handle toilet paper well, toilet papers sold in Thailand also does not dissolve well in water.

I don't have any problem with their Go implementation. Instead, it is very impressive to me who has little knowledge in Go.

I just want to point out that Node runs with a single thread so it does not max out CPU utilization. It would be nice if the author does the benchmark again with multiple processes of node js.

This immediately comes into my mind when I see the charts.

It is also interesting to see that only one Node process can barely serve 10k connections.

---- After I check the source at [0]. They use a simple http module to serve the requests while they use `http.ListenAndServe` which spawns go routines, hence more CPU utilization.

[0] https://gitlab.com/stressgrid/dummies

Vue, Vuex, and Vue-router official document are good enough. Many concepts in Vue are similar or quite simple compared to what you have to know in React. However, I find that Vuex is a little bit more verbose than Redux. You might it troublesome at first but will be better after you are familiar with it.

Agree with other comments that Vue and its companion libraries have much larger API surfaces and have a lot of magic while React's advance techniques can be built upon few basic fundamentals so you need more time to remember those. But I feel that most of APIs are practical solutions to problems you need to fix by yourself in React.

They had some snacks with them when they went into the cave.

Basically, there is a warning sign for cave flooding during July and October. Monsoon season is not likely to start at the end of June so they might thought it is still be fine to go into the cave.