67% is good enough for me. I am not using it as a medical device, and I am not an elite athlete. I just enjoy doing exercise, and every now and again I like to review the stats from my watch.
CRA has been a maintenance burden for my team for the last couple of years due to security vulnerabilities and incompatibilities in old packages.
We have several React apps (created with CRA) to support, embedded deep inside ASP.NET Web Forms apps (its legacy all the way down).
We decided to switch from CRA to Vite. It has worked great so far.
I am happy to see these docs recommend Vite as an option for adding React to existing apps, because at the time this decision was made on my team, it wasn’t very clear what the correct path was for replacing CRA. I don’t think we could have as easily switched to a framework like Nextjs.
If you are in a similar situation, I would recommend Vite.
Similar to wanting to start a blog, but instead of writing a post, spending significant effort building the platform. First post becomes ‘how I built my blog’.
Are these types of repos trust worthy, or is it best to download straight from Signal’s site?
Similarly, I noticed Signal is on Flathub [1] for installing via Flatpak, but the developer account is ‘unverified’. It’s always put me off installing via this method.
I struggle with reading speed, and concentration in general when reading. No idea why. However, I love listening to podcasts, audiobooks, videos etc. at 3x speed.
Using text to speech has also helped. No longer do I delay reading long messages from coworkers, or dread reading boring documentation. I just use text to speech. It works really well on Windows (my current work laptop), but unfortunately not so much on Linux (personal laptop) or mobile (too fiddly).
It’s great that Google is extending the support, and that GrapheneOS can benefit from it.
I bought a Pixel 4a specifically for installing GrapheneOS. I used it happily for almost 3 years, until EOL firmware support. The phone worked fine, but I wanted the reassurance of firmware security updates.
I was going to get a Pixel 6/7 (I forget which was available at the time) to use GrapheneOS again, but I was so annoyed at Google for only supporting firmware for 3 years, that I decided to switch to an iPhone SE.
Shortly after this, I believe the next Pixel came out with 5+ years support. I had some regret, but the iPhone SE is OK, and I didn’t want to buy a new phone just for the sake of it.
I will probably switch back to GrapheneOS for my next phone, as it really is a great mobile OS. Hopefully the project is still going strong by then.
Smaller companies have less traffic, need less expensive servers, and have no need to spend money optimising the language. They can focus on that when they make billions of dollars, like Shopify does.
He admits the company will die if advertisers pull out, and his solution is to document it and let the world know that the advertisers were the reason the company died.
I think you could run this service on CloudFront Functions, if you didn't mind using a Refresh header instead of the meta tag.
(CloudFront Functions can't generate body content, but it looks like this service works by responding with a refresh meta tag. So if you change that to a Refresh header you wouldn't need to write the body.)
CloudFront functions run on the 200+ edge locations of CloudFront and, according to the docs, have sub-millisecond startup times. So might be a viable option?
I think the difference may be in the "They’re easily revoked and expired" part.
Passwords are usually one-per-resource, e.g. a user has a single password. If that password is compromised you can reset it, but all the consumers that used it will need the new credential.
Whereas tokens are typically one-per-consumer, so if one is compromised you can revoke/expire just that token, without affecting other consumers.
Same with expiry times -- you can set that on a token without it expiring all access to that resource.
Not sure if that's what the author had in mind, but it's a difference in how these things are often used (even if fundamentally they are otherwise very similar).
While this probably doesn’t completely solve your problem, have you tried using conditional includes in your .gitconfig? I’ve been using that to ensure that anything under ~/work uses my work email for user.email, but anything under ~/projects uses my personal email. It’s quite handy.
pubsub would also be misleading, given SQS does not support the pub/sub pattern. It's a queue where each message is processed once by a single consumer; it's not a pub/sub system where multiple consumers can subscribe to messages of interest.