605 karma · joined October 8, 2010
All the big players have done a good job of speech to text (at least for USA English—saw an Englishman have to break into his best John Wayne impression for an on-stage demonstration about a month ago). But the Echo hardware does a great job of isolating your voice and the platform allows us to write skills for it quite easily.
I wouldn't be surprised to see the other guys make steps in a similar direction if the Echo continues to succeed.
I have no doubts the tech could facilitate something similar on Google and Apple's platforms but, afaik, building comparable functionality isn't currently possible (at least with Siri)—can you add arbitrary commands to either?
EDIT: the quickest interaction I could get away with was, "Alexa, start a phone call with {name}". No back and forth. One statement and the echo simply confirms (which was optional).
That said, that's enough of a kick for me to actually clean it up and publish some stuff. I'll email you when I throw pieces of it online (in the next day or two). At the very least, I wasn't able to find a lib that performs all the steps Amazon asks of you to validate the request so I wrote a utility library and hapi auth plugin for that. I'll release those.
Made a quick demonstration video: https://youtu.be/TkVnhp4F1xk
The thing is, it's a natural interface with a decent interaction model. Keyboards, mice, etc, have all become second nature to most of us but they're still not truly natural. The Echo feels like one of the first voice-based interfaces that isn't a complete gimmick. And the hardware does an amazing job of perking up when I say the wake word and picking me out of a room full of noise.
What really convinced me of it's value was when I started digging in to writing a skill for it. My grandfather passed recently and my grandmother has horrible eyesight. I wrote a skill that enables my grandmother to ask to start a phone call. She is then asked who she would like to call. Once she says a name, she receives a call on her landline, is greeted, and the call is forwarded to the intended recipient. There was a small learning curve ("you can't just say, 'call John,' you have to ask her to 'start a phone call'") but it has worked and has provided an often confused elderly woman with poor eyesight a straightforward way of connecting with her loved ones.
This is because Pay with Venmo is already available through Braintree (who acquired Venmo):
https://code.facebook.com/posts/1639473982937255/updating-ou...
Anecdotal, I know, however I have a family member that shows up on the site. His number is low—less than a couple of hundred dollars—but I asked him about it when I first heard of the site from Last Week Tonight. His response was that they were medical device manufacturers taking his team out for meals to discuss devices they were either already using regularly or were in the process of trialing. I can't imagine anyone can find fault in such a thing.
The author has conflated a couple of things. That is the exact opposite of how OSS works. The reason why the majority need to adopt is purely from a "one true coin" standpoint—there is nothing stopping forks or new alt coins from spinning out.
EDIT: Gen 1 and 2 are while the upcoming Gen 3 is built by Blackberry.
"Ford cited issues with Microsoft's complex software dragging down its scores with Consumer Reports and other consumer magazines being a reason it switched to BlackBerry."
http://9to5mac.com/2015/09/23/best-iphone-6s-feature-3d-touc...
1) you can install from cache with something like:
npm install --cache-min 9999999
[0]: http://www.cityofboston.gov/doit/apps/citizensconnect.asp
http://consumermediallc.files.wordpress.com/2014/03/bos_cabl...
Relevant snippet:
Any inadvertent doubts [the previous Facebook-specific grant to the BSD license] introduces detract from what we want our program to be about: world-class communities and world-class software.
So today we're pushing a new version of the grant. Its main significant improvement is that it is clearer with regard to what we mean by 'affiliates' and 'assertions' and the circumstances under which the grant terminates, all of which had caused confusion.
Directionality (for new folks) or terminus (for more seasoned riders) are infinitely better than Inbound/Outbound.
To be clear, I take nothing away from what you've done here: More tooling options are rarely—if ever—a bad thing and your presentation of riot is beautiful and clear, very well executed.
However—by your own description—HN is a place where you solicit feedback but can't be bothered to extend the same courtesy to your peers.
Think of it like a conversation. If I approach you asking for feedback on my projects but never return the favor, does that not seem suspicious?
While self-promotion is a skill, the submitter's comment and submission history is painfully focused exclusively on their own work.
I can certainly appreciate being proud of the things you build—that's great—but it comes across as disingenuous when it is quite literally the only thing you contribute to the discussion.
Just reduces the risk surface a bit.
CSRF tokens don't have to be unique per request. That's useful for things like preventing double submissions, ensuring order, or invalidating requests that are still in an active session but have timed out. However, it isn't necessarily more secure than having a secret tied to a user session and generating a token with that secret (which would, by itself, mean that any single token could continue to be used for the life of the session).
See OWASP's recommendation[0] which includes:
In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.
In your case, if you ever do grow a beard again, I recommend keeping your mustache trimmed. An untrimmed mustache is a substantially greater exercise in patience. You have to train the hairs to not creep into your mouth and, even then, there is a months-long period of time when the hairs aren't long enough to stay out of the way and eating anything wider than your mouth ends with you playing the "am I chewing on food or whiskers" game.
As for me, I grow a beard because 1) I can (thanks, genes plus work environment!) and 2) it keeps my face warm during northeast winters.
From the API docs:
> Multiple callbacks may be given; all are treated equally, and behave just like middleware. The only exception is that these callbacks may invoke next('route') to bypass the remaining route callback(s). This mechanism can be used to perform pre-conditions on a route, then pass control to subsequent routes if there's no reason to proceed with the current route.
The fact of the matter—whether we like it or not—is that these are the tools we have for web development. It's hacks on hacks on hacks, as one might expect in a suite of technologies originally intended for X but arguably powerful enough to perform Y, Z, and Z(2014). Take ECMAScript: the first draft was written up retroactively, quirks and all. Many of the oddities and edgecases were written into the official language spec and vendors were encouraged to implement them as written (thus, intentionally writing engines with quirks).
But the fact remains that no single, "fuck it" has been able to take hold. The technologies we have at our disposal have proven themselves "good enough" to keep that from happening to date. At this point, we've invested ~20 years into these technologies.
And, for what it's worth, there are ways to cut through the cruft. These things can be done moderately cleanly. It is possible to write a web-based application that doesn't make one want to blow their brains out (I'd make the argument that, in a lot of cases if you're trying to write a "desktop app" in the browser, you're focusing on the wrong thing but that's neither here nor there[0]). It's simply that legacy and twisting the language to do what we want and not what it was intended for has caused that to not be terribly straightforward.
I understand you're being hyperbolic but it's been my experience that this mindset ("this is so bad I'm never going to touch it") generally comes from folks who take one look and turn in disgust. That's fine—and I'm not going to argue it's not without it's warts because that would be insanity—but it isn't so bad that you'd need to off yourself, and I think the staying power it has had regardless of quirks, poor design choices, etc., proves that.
[0] - with the right team and the right reasons, it can be done. The Slack desktop app is a pretty good example of when it makes sense and is done quite well.
The reason I replaced it was because of the purpose it was designed to serve and how I was using it. A Chromecast is a remote viewport, not generally a consumer (save for Chrome and a handful of mobile apps). Take, for example, when I used Plex. I'd have my machine as the Plex server, my phone as the Plex consumer / controller, and the Chromecast as the viewport. All three would be on a private network served up from my travel router, disconnected from the WAN (hotel internet paranoia). All three of my internet-connected devices were required to make this setup work.
edit
Just remembered the requirement that the LAN be connected to the internet to use a Chromecast. When I'm streaming from Plex, I don't need to be on the internet. Getting connected just so I could then use Plex felt like an unnecessary hurdle.
end edit
Contrast that with the Roku which is not only the viewport but also the consumer / controller. It freed up my phone to remain on the cellular network. I could pass out watching a movie and not have to worry about missing "important" late night notifications / emails.
The alternative was to stream my screen to the Chromecast, but I found that to have tons of lag / frame-skipping.
Admittedly, it's a very particular concern. <g>
I travel with a Roku Streaming Stick (plus a small travel router) as it's a great way to use Plex and others from a hotel room. The one problem, however, is that the Roku feels sluggish and underpowered (minutes to boot, minutes to open netflix, etc). If Amazon's stick avoids that problem, I'll be getting one.