As a remote worker (and as someone who prefers remote work) I feel like this is attempting to recreate the feeling of stopping by someone's desk in an office. If that's what you want to recreate, I think this is an interesting approach, but I've always felt that remote workers do so specifically because they prefer not having in-office distractions. (Assuming those working remotely prefer to do so of course. I realize that's not always the case.)
Not trying to be snarky, but did you read the article or did you skim it? The author explains the reasoning behind the walkie-talkie approach versus a phone call.
FWIW, Tesla has been incredibly clear that yes, the Model 3 and Model Y are designed for a self-driving future. They even made sure that they could easily remove the steering wheel and replace it with a cover.
IIRC Flipboard once tried this approach, rendering everything to a <canvas>. As it stands right now, that will never be a viable solution for the reasons you mentioned, along with the fact you throw literally all accessibility features out the window.
The Pax app let's you set dosage controls so that you can always get a consistent hit each time. The new Era Pro even remembers the dosage based on which pod you're using, which is super useful for me since I have a sativa pod set to one dose and an indica pod set to two. The app also supports fine-grained temperature control in addition to surfacing information related to the pod like lab testing results.
In the case of the acceleration boost update, it's more like "we wrote a new firmware for several subsystems that increases your acceleration". It's not enabling hardware that already exists, but is disabled. It's the same case with the Full Self-Driving package: you're not paying for hardware you have to be enabled, you're paying for new software features. The purchase price covers the "labor" of creating those software packages.
Edge (and Chromium) both use a custom C++ UI framework. Chrome wrote the framework to be cross-platform, so Edge was able to take advantage of that to deliver the macOS version. AFAIK there's no WinUI XAML components being used.
I'm really curious why they released to stable with so many basic features missing. For example, your bookmarks won't sync between devices (although that was recently re-enabled in the preview channels). It sounds like they're not pushing out automatic updates right now anyway, so I'm not sure what this announcement amounts to. Why not wait until the 20H1 Windows 10 feature update (which sounds like the update that will include the stable version of Edge) is released to mark the first stable version? Just seems like a weird release schedule.
To be completely fair, virtually every app I've ever used has a "Send Feedback" function in the settings, and quite a few of them use both a bottom app bar along with some sort of overflow menu. Biggest example would be Google Play, something familiar to almost all Android users.
Starbucks has a PWA! You can get to it via app.starbucks.com. I'm not sure why it's not the default experience, but they're definitely already sharing code between starbucks.com and the PWA since the ordering experience is exactly the same.
Sorry, I was apparently producing a development build. I'm used to create-react-app, which eliminates this exact scenario by always building in production mode, so that people can't accidentally ship a development build to production.
Ah yes, I didn't realize "ember build" produced a development build. For comparison, create-react-app always builds in production mode to eliminate this exact scenario!
One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React app down too, especially on initial load. For comparison, my _entire_ React application (which includes emotion, react-router, and a full data synchronization library) is only 356 KB (104 KB gzipped). Don't get me wrong: there's certainly applications where the size of the JavaScript doesn't matter, and I think Ember is _great_ for those use-cases. I just wish it could be used for smaller, mobile-focused applications without being several times larger than an equivalent React app.
[1] Apparently this is the development size. The production size is 712.29 KB (180.80 KB gzipped). My point still stands though.
Oh, awesome! I just installed Riot 0.9.9, so I'm going to test that out and see if the issue occurs. After that I'll switch to RiotX and check there as well and report any issues I find.
I don't think this issue is related to soft logout, which is what happens when the user logs out of a device remotely. The issue I was running into was that the app, after 24 hours of being logged in, would get stuck in an initialization loop.
I really hope this means more development and focus on building great mobile apps for Matrix. For the past four months the Riot Android app has had this bug where login state expires after a day and the app gets stuck in an infinite loop trying to refresh the token. Supposedly a fix was merged [1], but after four months of not being able to use Riot (and thus Matrix) my friend group has fallen back to Discord.
Unfortunately FaunaDB isn't a SQL database, so it's in the same class as things like Cloud Firestore, AWS DynamoDB, and Mongo Atlas. Good datastores for serverless applications, but not so great for traditional applications migrated to serverless.
Cloud Run user here. It does not support running a database as a Cloud Run service; you'd need to connect to a Cloud SQL instance. This is one area I really hope PaaS providers improve on in the future. The closest thing at the moment is Aurora Serverless on AWS, especially with their neat HTTP connection system. That being said, cold starts are even worse since they're now the start up time for your application in addition to the start up time for Aurora Serverless.
I had a friend who had an interlock device; it was so unreliable, and triggered so many false positives that his sentence was extended because the DMV thought he was regularly driving drunk. What's worse is that when the device had a positive reading, he'd blow again, and it was negative. This was accurately recorded, and yet the DMV wouldn't recognize the impossibility of going from incredibly drunk to stone cold sober in the span of three minutes.
While I support the idea itself, the technology is incredibly unreliable, and since it only affects "criminals", there's no public demand for them to improve.
I don't think this is accurate. I'm fairly sure Apple Pay uses tokenization, so the merchant/merchant bank never sees the actual card details. The only party in the transaction who knows the actual card details is the issuing bank.
It's a little bit more complicated. Sure, if you're doing low-level programming I imagine you might run into the Win32 API, but if you're just building typical desktop applications (particularly for newer devices like the Surface Pro X or Surface Neo), you'll most likely want to use UWP. Usage of Win32 for app development is only going to decrease overtime for typical consumer applications. I'm sure businesses will continue building LOB apps in WPF and WinForms until the heat-death of the universe, but there's also businesses building apps in VB6 and you don't see many people recommending to learn that.
The Win32 API is on life-support. Microsoft will maintain backwards compatibility for legacy apps of course, but learning Win32 for new development doesn't seem like a good investment (unless, of course, you want to get a job maintaining a legacy Win32 app).
The Office app actually opens each document in a new activity, meaning you can open a Word document and an Excel sheet and switch between them in the app switcher just fine.
Yeah, that's my assumption as well. It would explain why there's no mention of it in breaking changes, and why being specific about the generics in `SinonStub` fixes the error.
Makes me wonder what other unsoundness the compiler isn't catching.