It should be possible for some recipients to donate plasma after they recover. So if pfas levels are a real concern, there’s an easy solution for at least some of the recipients.
I can only imagine how upsetting this must be for you and your family. I just hope that after you’ve had some time to process, that your son finds a way forward that brings him closer to the future he wants for himself. Just a bit of unsolicited advice from an internet stranger, but describing the situation as a “complete disaster for his future”, even if not expressed directly to your son, runs the risk of becoming a self fulfilling prophecy. Transfers, grad school, good job placements/pivots, a gap year, are all options.
I don’t know, we’ve had staged content presented as reality for a long time(ie almost all “reality” tv) and we seem to be doing ok. The TikTok content you’re describing doesn’t feel terribly different from that.
I've always felt a connection to this story in my professional life. I've been in enough rooms full of "ideas people" who will spend an entire meeting talking about tools that should exist or processes that need to be changed, if only "someone" would implement it. It's about work that everyone agrees someone else should do. Everyone wants the cat belled, no one wants to do the belling.
Outside of gaslighting's original context in a relationship, I often see it used to refer to a form of strawman argument. I read the gaslighting comment as saying that the person knows that virtualization in the form before Kubernetes was not sufficient, but tries to make people who express that thought feel like they're wrong at a fundamental level. So the implication is that the author knowingly constructs a strawman argument and then tries to make it sound like anyone who recognizes it for what it is, is "crazy".
I think the RPA is way overhyped, especially the "ML" features of the big players. But from what I've seen, it does have it's place in the enterprise.
There are two primary types of RPA, attended and unattended. Unattended automations make for good candidates for replacement with systems that have proper API's. The issue I've seen is that most of the underlying back office systems have a weird division of business logic between the view layer, the server and the database such that no one wants to risk trying to detangle the systems. In theory RPA can act as a bridging technology that lets you first create something closer to a proper API. Then if new apps built on top of those API's provide value, it becomes easier to justify a re-write of the underlying systems. So it kind of helps build the political will in larger organizations by making the value of the future state of sunsetting the legacy systems more real to those outside of the tech org.
Attended automations, when done right, function as a window orchestration tool for multivendor workflows where the end user needs to be in the loop, maybe for compliance reasons, or because they need to use some professional judgement like underwriters. Even when platforms have solid API's, they rarely have deep linking with enough sophistication to take the user to the proper screen for a multi-application flow. In a perfect world you'd map out relevant workflows, and write some simple glue apps that are built on top of multiple APIs, which is what Power apps is kind of trying to do. The reality is that SME's can be really attached to certain systems and ways of doing things, that the cost of retraining on a new flow is often not politically viable. So it becomes easier to augment the workflows, pulling up SharePoint docs when certain conditions are met, partially filling out forms in some webapps, etc... than search for a global maximum.
I guess in short, I think there are pragmatic ways to use RPA without resigning yourself to never doing the necessary work of rearchitecting the systems that made RPA necessary in the first place.
We used Casbin at my previous company where we needed to implement RBAC on top of our API that was written in Go. What we liked about it was that it could be embedded directly in our main application without needing to administer an external system. It also helped that we were using Postgres and redis as part of our stack as the casbin plugins for those tools made policy storage and enforcer updates dead simple across our API nodes.
Yeah and those numbers seem in line with what others have reported in HN meta threads on the topic, and at least an n of 1 personal experience. I totally get it when it’s a game or some other server intensive thing. Guess caching is an afterthought for a lot of smaller sites.
I subscribe to EatThisMuch for a lot of this stuff. I think calorie counting through meal prep makes a lot of sense and EatThisMuch does a solid job of allowing me to do things like set macros, black list certain ingredients, account for my schedule and leftover preferences and also has a good (but sometimes flawed) integration with whole foods delivery.
You definitely need to do some care and feeding on your favorite meals (unless you love eating cottage cheese with every meal) and remove meals for days you know you’re likely to eat out, but other than that it just works out of the box.
I’ve moved around a lot since college, and have had to build a social network from scratch a few times with varying degrees of success.
While the advice to join a social activity centered around a shared interest is solid, it’s not sufficient by itself for making friends. Bridging the gap between hanging out for a given activity to hanging out more generally to being actual friends with someone is hard.
Make one friend that is just down to show up. With at least one friend that you can consistently count on to show up, you can start inviting other potential friends to things and build out your social circle. You have to be open to rejection and to a bit of awkwardness that comes with two semi strangers hanging out. But with one anchor friend it becomes so much easier to make more and it’s the one piece of advice I wish I’d come across sooner.
I'm in the process of porting a reasonably complex hobby app that I built in RN to Flutter.
Things I like better about Flutter:
- Cleaner upgrades. For mere mortals like myself, RN can be really painful to upgrade sometimes. This is imho the most frustrating part of working in RN.
- Navigation makes sense out of the box in Flutter. react-navigation is getting better, but there has been a lot of churn there and there's still no community consensus on the "right" navigation library for RN.
- More opinionated stylized components. It takes a lot less work to get something that looks good using the standard components in Flutter.
- Dart is typed (yes I could use TypeScript with RN, but at least when I started building my app in RN, Flow was in some circles the preferred typing system and it took non-trivial effort to get TS working in RN in earlier versions).
Things I like better about RN:
- I think the debug tools, especially if you're using redux is superior in RN
- Greater portability to the web. Yes, the Flutter team is beginning to address this with Hummingbird, but there are many more options with RN
- React is still my go-to for building webapps, and even though Dart is quite similar to JS, improvements/maintenance of React skills while working on a mobile app is quite nice.
Resistance bands, a pull-up bar and a TRX go a long way for a fraction of the cost and space of a gym. Not as effective as free weights (in my personal experience) for putting on a lot of new muscle, but still quite effective.
This article is about a study done on mice. Having not read the underlying study, and it not being my field, I can't speak to how well the article articulates the study's findings, but I don't think it's fair to dismiss it with the "correlation does not imply causation" argument.
Nothing high tech. Started out monitoring failed deliveries and sent out verification requests manually to get over the first week or two. I noticed it was failing consistently on Microsoft domains, so contacted the provider and they reassigned an IP which improved things. Other than that, I have a really high open rate, but I'm not going to pretend I know much about the intricacies of building a domain's reputation. I'm using Mailgun btw. Can't really compare it to other services personally, but their support has been great especially given that my service isn't large enough yet to need more than the free tier.
Good point, I mean user name and password, with an initial verification email. If you use the email option, you can't get into the app without first clicking a verification link in an email. That caused a few headaches after launch when my transactional mail service didn't have a great delivery rate. Still the right thing to do from a security perspective. I do have a big "preview" option on the login page for anyone looking to kick the tires before committing to creating an account, which hopefully compensates for some of the added friction in the verification process.