There has been a similar project developed in Poland already. (https://en.media.pkobp.pl/78483-strategic-partnership-betwee...) In practice it's not much more than government-branded version of Google Cloud Platform and Microsoft Azure. So far it serves well as a marketing vehicle for a handful of the biggest corporations, but it's barely used by anyone.
I can see it could make sense as a solution to some particular problems though – European regulations often forbid banks from processing/storing customer data in other countries, so even though the tech is provided by the American tech giants, having everything hosted locally makes it possible for local financial services to finally move away from hosting everything on premises.
I totally agree with you on the mandatory part, I’d hope it would be widely accepted that opt-in is the way to go in such cases.
Although I need to point out there’s a huge difference between what people say vs what they actually do (see https://www.nngroup.com/articles/first-rule-of-usability-don...) and I can’t imagine an effective product development process that ignores the actual usage data.
Transcriptions are not really the issue here, the cost of freelance transcribers is relatively low. It is privacy that makes it so hard, most of the call center calls need to have some kind of user authentication, which means they would need to be anonymized prior to being transcribed and used as a training material.
Having it learn on human games was just a way of speeding up the initialization process before running reinforcement learning, it didn't limit the state tree that was being searched later on.
Being a Pole, I wish more people understood that. :(
We're in the process of dismantling our democracy by removing all of the checks you mentioned, while supporters of the ruling party argue that democratically elected majority is within full rights to do it.
That's true, although I see no reason Elm couldn't be compiled to server-side JS running in Node.
I'd love to see some full stack solution that would abstract away separation between backend and frontend (like Meteor perhaps) using some sane programming language and architecture.
Having built lots of SPAs and APIs serving as a backend for them I always feel that what's really relevant is modelling your data and domain logic (which tends to happen on a server side) and the UI consuming this data on the other end. Everything in between – endpoints exposing the data on the backend, frontend machinery to pull that data into client – seems to be totally arbitrary and implementing it is nothing short of a grind.
Although it's meant to be sarcastic, I believe it nicely exposes typical things developers used to argue about back then, not that different from modern arguments about JS vs compiled-to-js, elixir vs erlang, GC vs manual memory management, etc.
Anybody knows some more serious piece from those times that would show the actual arguments of, say, PASCAL opponents?
According to this quiz, you can either have small guaranteed impact or bet on something bigger while accepting you might fail.
I wonder what's their take on bootstrapped startups, that have potential to grow exponentially but don't rush it valley-style. Biggest long-running tech companies had positive revenue since very early in their life (if not day 1).
Think of it as of seeing URL printed on the wall (or hidden in QR-code), just easier to use if you actually want to.
It's not spamming notification center. Whenever the beacon signal is heard the information about it is shown in Chrome widget, but you still have to manually go there to see it. If you ignore it and move away from the beacon it will simply disappear.
We're doing sensor-fusion trying to use as much data as possible coming from different sources, so besides RSSI from beacons there's also accelerometer, magnetometer, etc. Lots of non-trivial maths to combine that into a robust model, but results are getting more and more incredible. :)
A bit surprising that so many people in the comments would rather see links to cheap temu polaroid knockoffs.