sfilipov

Worth mentioning that virtual nodes also ensure that the order of servers is random. Which helps when a server is removed - the keys that need to be moved will be spread across all other servers. If we were to evenly chop up the hash ring, server B will always be after server A. And when we remove server A, all keys residing on it will need to be moved exclusively to server B.

I am not sure I understand your confusion but here's a few pointers in no particular order:

- the argument passed to useState is initial state, not "forever state". It will seed prevItems for the first render. But later when items prop changes, it's on you to detect the change to what you have as prevItems so far and call setPrevItems yourself.

- items is coming as a prop from outside, prevItems is whatever you set it to last time using setPrevItems

- calling a state setter (setPrevItems / setSelection etc) will always cause a rerender. That's why if you don't have the if condition you have just created an infinite loop - you are inside a render, and if you unconditionally call setX that causes another rerender later etc etc

- that's why I am not a big fan of this particular "Better" example and prefer the later "Best". Avoiding calling state setter function from inside render will make your life easier.

You could argue investing in Coinbase had lower risk than investing in Bitcoin directly (was it?). Then the risk adjusted return would be even better.

Exactly! I get blamed for cheating and reported (trust me I don't) so I whenever I play matchmaking I'm also in the "likely cheater" group. That's why I play on third party server with their own anti cheat system.

> A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is using the native in-database row level security model.

I agree with your overall comment. Note that Hasura doesn't use the native row level security in Postgres. They implement the layer themselves. There are two reasons: 1) Hasura is older than the first release of Postgres that included the row level security feature. 2) Their implementation scales better when there are a lot of users subscribed to the same GQL Subscription. When using row level security, every user's query result looks different, so they need to create a database subscription / polling for each user GQL Subscription. Their implementation allows them to have a single PG subscription (well they mostly do polling), get all the data back, then strip down on the way out to the GQL subscribers.

One way I try to combat that is by forcing myself to do things the simplest way (unless I am aware I'm making a technical decision I can't change later). Then I try to add more complex bits when necessary. As a bonus you learn the skill of "refactoring" etc.

For example, nobody is forcing me to use Docker from the start. I don't have to use it until I decide the development or deployment pain is big enough that I will learn how to use Docker. Similarly, why do server side rendering when you can have a perfectly working project without it. Add server side rendering later, when you project actually has real features. Not from day one. The temptation to use cool tech from the start is difficult to ignore at first, but after a few attempts to do a side project, only to give up before you've even started, it gets easier to appreciate stack simplicity :)

Trying to keep code as simple as possible from the start is more difficult, i.e. you might be structuring your code too naively and regret it later when you try to refactor. But as we know, abstracting too early creates similar if not worse problems.

To prevent existing code that relies on it from breaking.

What are good examples of Reinvest Software? My guess would be Amazon, but what others?

Maybe try Dragon, Fly! It is quite similar.

I don't disagree overall but I'm using SQLAlchemy (Python) on a daily basis and it works quite well.

I agree that if you are building ORM with the intention of hiding so many SQL details that the developers don't need to learn SQL, you'll run into problems.

SQLAlchemy on the other hand starts simple, but is flexible enough that you can do inner/outer joins, you have different loading strategies etc. It is quite nice if you are proficient enough in SQL.

When writing complicated select queries, I'd start by writing the raw SQL then spend my time representing it in SQLAlchemy. It's a bit less than double the work sometimes, but working with the SQLAlchemy objects in Python is quite nice as long as you pull them in an efficient manner. SQLAlchemy just feels like a well thought out ORM.

Tested and it works, as long as you haven't finished downloading and applying the updates.

Is that going to help against checking with the Internet Archive? I've used the Internet Archive to read versions of reddit comments when they were deleted (but not to dox people).

Agreed, it's not a problem of theoretical possibility. It's just that the maintainers' time can be better spent improving Python 3 than maintaining a Python 2 compatible runtime.