The easiest way to see this for yourself is with an image generator. Try asking for a very specific combination of things that would not normally appear together in an artpiece.
Alongside a link to Google's explanation of why they do it, that's a very reasonable and helpful reply. "Changing the queuing method from the standard first-in, first-out (FIFO) to last-in, first-out (LIFO) [...] can reduce load by removing requests that are unlikely to be worth processing"
> Most services process queues in FIFO (first-in first-out) order. During periods of high queuing, however, the first-in request has often been sitting around for so long that the user may have aborted the action that generated the request. Processing the
first-in request first expends resources on a request that is less likely to benefit a user than a request that has just arrived. Our services process requests using adaptive LIFO. During normal operating conditions, requests are processed in FIFO order, but when a queue is starting to form, the server switches to LIFO mode. Adaptive LIFO and CoDel play nicely together, as shown in figure 2. CoDel sets short timeouts, preventing long queues from building up, and adaptive LIFO places new requests at the front of the queue, maximizing the chance that they will meet the deadline set by CoDel. HHVM3, Facebook’s PHP runtime, includes an implementation of the Adaptive LIFO algorithm.
For instance, a bunch of clients all make a request to a server at the same time, briefly saturating the server. If all the clients have the same timeout without jitter, they will all try again together at the same time once the timeout expires, saturating the server again and again. Jitter helps by « spreading » those clients in time, thus « diluting » the server load. The server can then process these requests without saturating.
The basic idea behind that is also used in all sorts of networks where you have multiple stations sharing the same medium with everyone being able to freely send stuff. To solve this, if a "collision" is detected, stations then use a random timeout before they send again in the hope that the next time there won't be another collision.
If you use a linked list it’s like always adding at the head of the list and always removing from the head.
Let’s say you have two clients for your server one sends a reliable 1 request per second, and the other sends 10,000 requests every hour in a burst.
The lifo will basically result in the 1/sec client always getting their requests answered and when you get a burst from the other client most of their requests will get dropped. Assume your server can handle 100 reqs/second with a 1 second time out.
There are way more terrible ideas than good ones, and that means treating all of them equally is a one-way road to HN losing the one thing it has going: new ideas.
Feedback like root comment is important to keep pushing ideas forward, instead of a loop.
I would honestly love to educate people here. But when the rabble come together to downvote you and dismiss what you're saying, the general perception from any reader is going to be that I'm wrong because so many people are disagreeing with me. Despite the fact that I'm literally an expert and they're not. So it's useless. (And just hurts my soul.)
If you want to bring your own UI, TanStack Table (formerly React Table) [0], if you want something that's batteries included, MUI [1][2]. There are of course other options with either close or full feature parity, but these are the two I see most often with least pain across different companies. While we're on the topic of recommendations, avoid any- and everything by Telerik.
I really liked seeing this page on tanstack's website explaining their collaboration with ag-grid. Better wayfinding to the proper project is a huge blindspot for most open source projects. I built a page specifically listing related projects... because my thought is, if someone finds that page, and I haven't helped them, they should find the project that works for them.
MUI appears to be more mature but DataSheetGrid has spreadsheet-like range selection out of the box while MUI only provides a beta version under its premium plan.
From MUI: "This feature is not stable yet, meaning that its APIs may suffer breaking changes. While in development, all props and methods related to cell selection must be prefixed with unstable".
This feature tends to be pro or unavailable across options I've seen so it is great that DataSheetGrid has rolled out a working implementation.
Edit: Changed 'its pro plan' to 'its premium plan'.
Tanstack table is great, can recommend it. It can be used for any kind of table. But it's a headless component, so there is quite some work involved in creating something useful.
But it's a great middleware that can be wired between the data and some kind of tabular UI react component.
It's a bullshit formula that can be used to justify "padding" to people that think software development (or any kind of work) is like digging a ditch or like an assembly line.
In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new <whatever's> being used."
It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.
Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow.
New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
From the other angle, you can see how velocity is impacted by using "boring tech", keeping teams small (two pizza team), clearly identifying stakeholder roles, creating efficient communication channels. It's a pretty useful model.
It was inspired by natural gas prices that went 3x this winter and an article that said we (French citizen) pay our electricity much more than what it cost us to produce because our production is sold on the markets then sold back to us at an inflated price (deepl should offer an OK translation even if it might lose a bit of the humor : https://institutdeslibertes.org/nous-avons-la-meilleure-fonc... ). I don't have data to say how much more will it be expensive, but I know it will be bad enough that we certainly will have protests.
You can't just delete nuclear, coal and natural gas power plants and think the invisible hand will provide. There is no secret plan behind: we're gonna crash then our politicians will blame the Russians and / or COVID but certainly not their incompetence.
Don't get me wrong, I don't want to live in a polluted world more than anybody else, but I also want to take a hot shower daily without it being a luxury expense. We needed to think the transition and do it progressively before. Too late.
