If you load an issue page, you'll see 1 failed request to:
/project/product/issues/<number>
And sure, that's what you care about, but consider the working requests to:
/in-product-messaging/copilot-budget-request-banner
/in-product-messaging/code-scanning-ai-findings-preview-banner
/github-copilot/chat
/_private/browser/stats
If page has 15 requests and needs data from all of them to work correctly, then with 20% failure rate you are suddenly close to 100% non-functional page from the user perspective.
A technique we've used to deal with this situation: in the overloaded backend (that has to reject some percentage of incoming requests), group the incoming requests by the parent request (the one with the 1:15 fan out) and reject according to the parent request. One way to put it, simply (though somewhat inaccurately), would be: reject 100% of traffic from 20% of users, rather than 20% of traffic across all users (causing essentially full failure for all users).
We typically implemented this by propagating an ID of the parent request down to the backend. I'm simplifying a lot in this description (e.g. have to deal with the parent requests landing on different backend tasks; also rotate the IDs gradually to introduce some fairness).
A nice technique to learn of this situation is to fail ("black hole") random resources in synthetic loads of the frontend. This lets you find out 'bout these single points of failure, and then you can start adding fallbacks.
It's easier to create a nice worst-case failure UX this way too. Rather than a page that sorta kinda loads but doesn't actually work at all you can unambiguously put up a "oops we're broken right now try again later" page whenever that top-level endpoint returns a non-retryable error.
But that of course begs the question--why is the frontend retrieving all these data from 16 different endpoints instead of just one? It would be less overhead (http, auth, serialization, compression) to just serve it all in one request even if the http layer needs to fan out 15 rpc calls... this is why we can't have nice things.
Shyeah, all those successful requests were really helpful for showing me a page, which then failed when I tried to do anything by clicking the buttons on the page. I was completely unable to merge things for hours, for no lack of trying. GH was down.
I personally find a prop to be a perfectly acceptable solution - you can define styles in your JS and share between components if need be. But I reckon there are folks who'd prefer passing class names to define their styles in CSS.
The "build quality" means it looks nice, but it sure isn't durable. If you spill liquid on an Apple, it's a dead machine. If you drop an Apple, it's also dead. Thinkpads can survive a hell of a lot more abuse.
Every time a friend or colleague asks why I use "that" I simply thrown my laptop to the floor, pick it up and continue working on it.
Then I ask them to try the same with their Apple laptop.
That normally makes them never ask such questions again.
I learned that from an IBM (and later a Lenovo) sales person when presenting the X series. It's designed and built to tolerate real use. And some abuse :-)
I've used laptops for the last 10-15 years, often 8+ hours a day. I have not once dropped a laptop during those years. I'm completely okay with having a laptop that disintegrates when dropped and is better in other ways (thinner, lighter, longer battery life) as a result of not focusing on resistance to drops.
I guess it depends on your laptop. I dropped Macbook once (it was closed and there was a big scratch on case), but otherwise I'm very careful with it. I didn't drop my iPhone either. But when I owned old indestructible Nokia phone, I dropped it few times a week, just because I didn't really care. If I would own indestructible laptop, I might drop it as well sometimes. If I'm laying on bed with laptop and I want to sleep, I have to carefully position laptop on the floor. But I would happily threw it away, if I could, it would be so much easier.
Definitely agree on "If you drop an Apple, it's also dead.", but "If you spill liquid on an Apple, it's a dead machine." hasn't been true for me: Spilled a whole glass of water on my MBA which was running and it immediately turned off. After drying it on the heater for half a day it turned back on without any problems or damage.
Check out Louis Rossmann's Apple repair channel on YouTube. The vast majority of boards he repairs are broken because of liquid damage (he does actual board-level repair using microsoldering, unlike Apple which merely replaces everything). It's definitely a huge problem.
I don't believe that I actually want improved performance. I just want a smooth laptop that is thin, has long during battery life, and is price competitive. Essentially a MacBook at a reasonable price.
That's maybe not a great comparison, it's a different class of product with worse battery life and much heavier. The MacBook Air has been optimised for a different use case.
The closest real comparison is the MacBook Pro to the Surface Pro, in which case the MacBook is better at every price tier(expect for the touchscreen which is totally useful).
Chrome-only and that's if there's no bug. I have the latest version of Chrome on Ubuntu but my GPU (GTX 960m, latest drivers) is blocked and the --ignore-gpu-blacklist flag doesn't work.
