668 karma · joined October 28, 2012
There are plenty of people opting to die every year by refusing blood transfusions and transplants already.
> https://www.youtube.com/watch?v=gT59YOdch8M
> Typically this type of project would take a team months to complete and weeks to render.
>Apps may use in-app purchase currencies to enable customers to “tip” the developer or digital content providers in the app.
Section 3.1.2(d), regarding permissible use of other payment methods:
>3.1.3(d) Person-to-Person Services: If your app enables the purchase of realtime person-to-person services between two individuals (for example tutoring students, medical consultations, real estate tours, or fitness training), you may use purchase methods other than in-app purchase to collect those payments. One-to-few and one-to-many realtime services must use in-app purchase.
https://developer.apple.com/app-store/review/guidelines/
It's fuzzy, perhaps, given the word "may". Apple's unofficial advice for fuzzy guideline questions is to implement, submit, and argue your case once it's live.
AWS WorkSpaces purports to have machines with meaty GPU's, are they not powerful enough?
Depends where you draw the line at surgery VS procedure, does something have to be cut? Who knows! Either way, I recommend not DIY'ing this one.
YouTube has some deliciously informative videos if you'd like to watch a real surgery!
I personally know of 4 people (in 2 different countries) - family, friends, or family of friends, who have died from Covid. None were over 60. I don't know that many people.
This is not the same, stop believing this garbage.
https://cdc-tencent-com-1258344706.image.myqcloud.com/upload...
The cluster autoscaler has been so good that we've optimised for more, smaller nodes, on spot instance pricing. At $79/node, that's about 4x the cost of the actual instance itself...
And yet the actual cost of the services provided, don't _really_ seem to scale with number of nodes? But then, I can't think of another metric to tie it to easily
Either way, it's an interesting application. I'm not sure how wild you could go with this right now, given all the roads that exist already, and the cost that would come along with it. Or maybe the traffic implications of people climbing to get on those free charging roads?
But public transit seems like a smart use for this kind of thing. Takes a predictable path, for a (somewhat) predictable about of time, on a loop all day. If you designed it right, perhaps you could drive that bus along that route until it breaks down?
Still cheaper to rent humans!
Somebody (presumed ex- or current-employee) took handful of iOS devices from our office a few months ago. Changed the password to the Apple ID, added 2FA phone number.
The account isn't even deleted, and we can't get back into it.
We have a dozen other devices logged into that Apple ID, all prompting for the password. You cannot install updates, you cannot roll back, you cannot log out, you cannot factory reset.
Apple have been no help at all.
The devices we have that are logged into this account are bricks. Apparently if we have original proof of purchase, we can take them into an Apple store and have it reset. But a lot of our devices are older or were acquired refurb/used - they're used as testing devices.
The accounts are locked, they just won't help us get back in, we've tried several times and channels. We've offered to do anything, sign anything, they won't do it. I once went through password/2FA recovery with an Amazon AWS account, and it really wasn't that painless (sign some legal paperwork, show a bunch of documents).
We are an unknown startup, but we have generated millions of dollars for Apple over the past decade in App Store cuts. If we can't get back in, I don't know how it'd go for grandma's iPhone.
Our "features" take anything from 1 day to 3 weeks of effort, and generally need to roll out as a whole. They are often really upgrades of existing features, and the work to continuously merge w/ feature flags, supporting both flows/designs, is just not something we've felt was worth the extra time.
We release on a 2 week cycle, the same day each time. We merge our features into the develop branch as they are ready and safe for production.
Our scheduled release day is Wednesday. The Thursday beforehand, we branch from develop into a release/x.y.0. This builds release candidates. We have a sanity check on Friday, then our remote QA team runs through them over the weekend. Any issues they find, we try to have squared away by Monday, Tuesday at the latest.
Meanwhile other team members are still merging new things into develop. It's useful to have that release branch because it lets the rest of the team keep moving - we maybe only put out 1 or 2 developer's features each cycle, the rest are still trickling in.
Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it.
For our team scale, we have a lot of users (100k's DAU), and we find this method is a nice balance between the pace of output you might get from true CI but with the reliability of a more traditional cycle.
Backend and web projects, however... Straight CI, into master, and we roll out test > staging > production when we're happy.