braintree day1

gistfile1.txt

are vendor services and your 
team might just not have the capital to pay for it. 
Complex software licensing agreements may not meet your 
needs for various reasons. Or maybe the amount of load
that your team will generate is just prohibited. 
So what do we do in these cases? That's 
really where my concept -- my ideas for experts will 
frame buffer come into play. The frame buffer, more
known as XPF, and trying to use the two interchangeably 
in this presentation, and it's not new technology, and 
it's not JavaScript technology, but it is some towing 
that allows you to run gooey applications, like, web 
browsers with no gooey, with no screen. 
So let's talk a little bit about XBFB, and 
I'll hopefully provide some explanation on what this is 
bring lead into my demo. 
And with that quick sidebar, let's talk about 
the X Windows system. So the X Windows system is how 
gooey displays are rendered on Linux-like systems, being 
Linux and Mac OS. And the display server is the current 
release, so, again, this is a Windowing system to render 
gooeys, and this is effectively how visual elements are 
rendered on the screen and available for user
interaction via mouse click or visual gooeys with
quality, like, color and shape on Mac OS and Linux. 
So with that, what is expert came from buff we 
are, behaves like any other X server, the different 
being no graphical output, which is rendered. It allows 
us to perform all graphical operations in memory without 
showing screen output. So, again, it doesn't require
the computer running it to have a screen. As is the 
case in my own team's continuous integration, workflow, 
and I'm sure that's true with many others. Either in 
cloud or manage BMs that have no display. 
So that brings me -- so with all of these 
problems in mind, and bearing into consideration XBS and 
candidate solution technology, I doctor it up aa polymer 
testing box. So this available on my gate hub, and it's 
testing box polymer-testing-box. And I'm not advocating 
necessarily that this is the best or most appropriate 
way to solve this problem, this is just a reference 
implementation, proof of concept for how you can run 
your automated tests in a headless BM. 
So the core technologies I'm going to be using 
throughout, throughout the presentation in demoing 
polymer testing box are of course XBFB, we're going to 
use answerable, it is a configuration comparable to 
chef or puppet or CF engine, typically used by system 
administrators and operate in professional servers. 
We're going to install Google chrome, Firefox, 
and web component test servers. They're all the 
prerequisite for running Google polymer tests. 
So demo time. So, again, here's what we're 
going to do. Our provision of box, ANSIable is then 
going to do its work in installing all necessary 
dependences, and then we're going to run some component 
tests against polymer web component. So quick sidebar. 
A disclaimer for those of you who aren't familiar with 
vagrant, this is not JavaScript, but it's -- I feel
baited to say that at a JavaScript conference; right?
But this is some great technology that helps us -- helps 
serve our needs within the JavaScript community. So 
vagrant is built on virtual box, and it's effectively a 
tool to spin up lightweight headless BMs, but a quick 
point I want to make about this. 
But on my laptop, vagrant is the provider of 
this Linux BM, but that provider could just as easily be 
a remote or cloud provider such as amazon web services 
or digital option or open stack. In this case for this
demo, its purposes, just using vagrant. But in theory, 
this ANSIable playbook, being the metaphor for how 
provisioning happens, it could take effect on a box from 
a different provider, like, a cloud provider. 
So the primary way that we communicate that we 
want a VM from the vagrant is via this vagrant file.
So, again, this is also not JavaScript, this is Ruby, 
but I do want to point out a few things here. There's 
more going on, but in the larger vagrant file, chucks in 
my repo, but quick points here. So number one, note 
that we are 5900 to 5901 on the host machine, so the 
host machine in this being my MacBook, so the VM becomes 
available via my MacBook. And then secondly we're 
declaring vacancy vagrant provision and this box we're
asking depo, via answereddable, and the instructions on 
how to do so is in this playbook file. 
So the ANSIable playbook file, again, not 
JavaScript, it is Python. But, again, I hope you see 
the relevancy. We're going to -- as per directive for 
this playbook file, install and run XBFE on display port 
O, we're going to install node, and Firefox. So we kick 
all this off by executing, by running vagrant up, so 
that gives us the box and then kicks off the ANSIable 
revisioning process. The point here is that this is, 
you know, I'm storing my infrastructure in code here. 
So this is easily repeatable scientific process. This 
is not a gradual managed server. This code allows us to 
repeat this process again and again and again and get 
the theory exact same again and again. 
So when did that all done, we're going to 
shell into the polymer testing box, which I'll do via 
vagrant SSH. And then I'm going to clone a Google 
polymer web component. So in this case we'll clone four 
AJAX, which is a Google polymer component maintained by 
the polymer team, which provides some AJAX functionality 
within polymer. So we'll clone that. 
I'm going to check out version 057 of core 
AJAX, I want to do that because I want to demo tests, 
and I know 056 is a official release. And then we're 
going to run to install the AJAX dependency. So, again, 
this is all happening on the polymer testing box. 
So now I'll demo running web component tester. 
So what you'll see is I'll run WCT, which is a web 
component tester, executable, setting the environment 
variable to display port 0, so I'm telling web component 
to run on display port O, and remember per our ANSIable 
playbook, experiencable is running on display port O, 
and we'll see evidence -- I'll go ahead and kick this 
off, that sellinium is going to spin up both chrome and 
Firefox. So chrome 43 and Firefox 38, which were 
installed via ANSIable, and we're going to run the Web 
component test. So you can see the tests, all of our 
tests in each browser, and that happens with no screen 
output. That happened entirely on a vagrant box. 
So that is, like, the core of what I see the 
demo here. 
So I can understand any skepticism you have, 
you know, how do I really know that chrome and Firefox
really ran and what about the debugging? What you need 
to poke around in development or even remotely to see 
why are things failing. You might need a gooey, so I
have a solution. ENC. The polymer testing box has no
screen, it has no gooey, your Mac does. So what this
means is that we can open a VNC connection from -- in 
this case my MacBook to the vagrant box and because my 
MacBook has agooey, the screen, the draw commands and 
the all of the gooey commands executed will have a 
screen to take effect on. 
So step one on the polymer testing box, we'll 
have to install a VNC server, so I'll do it X11VNC and 
also on display port O. And then on your Mac -- or my 
Mac rather, I've brew installed tiger VNC viewer, any 
VNC client will do, and I'm running this on local host 
59.01, and you'll recall that I forwarded port 5900 of 
the vagrant VM to port 59.01 on my Mac. Sorry for 
the -- it's a little small. I wasn't what kind of 
screen real estate I would have to deal with. 
But on the left, this is my VNC connection 
from my Mac to the vagrant box on the right. So I'll go 
ahead and run the same command I ran previously on 
the vagrant box, and on the left it's going to be 
squished up, but hopefully you'll take my word for it 
that you'll see chrome and Firefox actually open and 
execute these tests. So there was chrome first there 
was Firefox and all tests passed. 
So, again, that is available at my profile and 
quick extra credit, I doctored up both unit and testing 
NW desktop application on similar box. 
So as for next steps, you know, I'm hoping 
that you could say how you could adopt maybe what I've 
proof of concepted here with something during your own 
builds, maybe MW, or MWS for some comparable cloud 
provider. Also an idea for how similar DM could be spun 
off in provisions for building and unit testing. 
ActionScript. I think this also opens a lot of advanced 
scripting for those websites that don't seem to behave 
at all for whatever reason. And it also provides 
passwords, headless functional testing, if that's
something that you're interested in. 
So that's it. Thank you very much.. 
[Clapping] 
>> Okay. It sounds like everybody would like 
it to start. We still got a couple of minutes. You 
guys can chat. Up next we've got Kyle Tyacke, from 
San Diego where they have delicious beer and stone 
brewing. Have you ever heard of this thing called 
WebRTC before isn't the skile going to share with us his 
work with WebRTC, and give it up for Kyle. 
[Clapping] 
>> Thanks, everybody, I'm just going to give
it a couple more seconds, so if I could get a quick 
photo with everybody, awesome. Beautiful crowd today. 
Great turnout. So the title of this talk is communicate 
all the things. What that means is I'm going to be 
talking about web communications, more specifically 
about the compatibilities that you now have access to as 
develops to do communications on the web. 
So while we're kind of waiting for those last 
couple of people, if you want to follow along, this is a 
live that's going to update automatically, it's U.UL, 
and I would love to get some audience interaction, maybe
a video call and a little bit of screen share if you 
want to go ahead and hit this URL, we'll run that 
throughout the session here. 
All right. So everybody ready? Let's do this 
thing. So what are we going to talk about today? We're
going to look at WebRTC, what it is and what it allows
you to do wab what the spec looks like. Going to talk 
about a little bit about spoke, the company I work with, 
and how it simplifies your life a little bit, and then 
we're a lot going to look at building a video call, 
screen sharing, and messaging a bit. And then this is a 
short session, 30 minutes is it a ton of time. So if
you could hold questions until the end, that would be 
great too. 
So who am I and why should you actually listen 
to anything I have to say? I mentioned my name is Kyle 
Tyacke, about 10 years as a flash freelancer doing a ton 
of script work, and which is where I led myself today. 
Video streaming, auto, and sort of laid for foundation 
for why JavaScript is coming out to speed for this 
communication stuff. And then I got back in the 
front-end, and then I'm developer the and coming to 
great conferences like those. And I'm also a huge beer 
geek, so if there are any microbrewers in here, I would 
love to talk about that all day. 
So what the heck is WebRTC? It's defined by 
the Mozilla foundation as a free open project with web 
browsers. Compatibilities via simple JavaScript API. 
So what does that mean exactly? 
It's free. You can use it. It's built into 
the browser. It's part of the HTML specter or supposed 
to be part of the HTML 5 spec, so you have access to it 
for free. You just go to play around with it. Open. 
It's open sourced People's No. so if you're one of those 
crafty developers that like to contribute to projects, 
and I recommended you do, you can actually make 
contributions to the spec and might actually see them go 
live. Realtime communications. This is sort of the 
meat of it all. It's auto and video date in realtime. 
So basically what it does is connect two browsers Napier 
to peer connection. So if you think about how web 
sockets work, that's what pure communication does. And 
the realtime portion of it is real time. So think about 
video and auto realtime when you talk to somebody on the 
phone be that's a realtime conversation. The same 
compatibility is going milligram through the web 
browser. Or Skype or Google hangout.
And it's stuff that you can access with the 
JavaScript that you all know today. I'm assuming that I 
have a large audience of JavaScript developers in the 
room, given the conference. So this is going to be 
stuff that you can easily work with. You don't need to 
know anything learn new or learn anything new, other 
than just start working JavaScript. The contributors, 
Google, Mozilla, and opera are the big ones. IE is kind 
of Microsoft working on their own implementation of 
ORTC, which sort of McI can say WebRTC with a few 
implements. And they're also contributing back to the 
main spec. So there is back and forth going on between 
Google and Mozilla, and IE, which is good, because the 
hope one day when they finalize the spec that everyone
will implement one version of the spec. 
Again, that's a hope. Maybe a dream. But are 
things actually looking like they might go in that 
direction. So WebRTC in the wild. What are people 
doing with this stuff already? You may have seen amazon 
may day some time ago, the can I make fire X was 
launched. 
Bear with me. I'm going to go a little bit 
rowing on this. 
So amazon may day, when Kindle launched, they 
added this new feature called the may day button, it
allowed you to be connected to a support rep at amazon, 
who would be able to access your screen and circle the 
mail button, for this example, and then. I have tested 
this service. This is want the person you talk to. 
They were very helpful, but not nearly as shiny as in 
their marketing campaign. 
That being said, it's a really could cool use 
case, you've got live video happening with this support 
tech, it beats chat supporter or even the worse more 
standard phone supporter that you get from most 
companies. And they built this using WebRTC on top of 
their own server. So they use WebRTC for the video 
portion, at least from what we can tell, and then it 
goes through the supporter lines that they already had 
in place. 
What umight have seen more is Google hangouts, 
what I'm assuming some of you in the room are using, you 
may have auto noticed in the past you had to download a 
plugin, and no longer. You can use it for WebRTC. For 
functionality, like, the data transfers and the live 
videoconferencing, as well as messaging. So a good 
example of the functionality built into WebRTC. Follow 
is a chat client, we didn't like slack, is we didn't 
like hangouts for specific reasons. We built our own. 
We used our own tools to roll our own version of 
communications app. This actually has things, like, 
group sharing, file sharing, phone conversations, you
can dial somebody's phone or directly over the web using 
a video acall. And, again, it was just something we 
built a custom solution for what we needed. 
CDN, this is actually a really cool 
implementation. It's essentially a CDN on your website. 
What you do is drop into a JavaScript library, and it 
scrubs your website for static assets,PDFs, anything 
that's large and you have every user download from the 
web server. And what it does is look to see if anybody 
else currently on the site has those files already. If 
it does, it creates a peer to peer connection between 
the new user and the user with the files, and it 
actually sends the files across that peer to peer. And 
what that's doing is saving you a ton of costs. So 
instead of every one of going and downloading the file, 
charging us bandwidth, they're streaming those files 
when possibly directly from person to person. So kind 
of a bit torrent client in a way. 
And, again, bandwidth savings can be huge on 
that, especially when you think of things like large 
video files, 10 megs at a time, lots of users. 
And this was an example Google built. To kind 
of showcase the gaming potential for WebRTC. So they 
actually take advantage of that peer to peer connection 
with live game updates. So if you think normally how
you set up a game online, the access of gaming server in 
between. It would go up to the gaming server and out 
the rest. This implementation, they built an on style 
game where they're using video to actually show you the 
user you're playing against and auto so you can talk 
back and forth. And then using that same channel on to 
have simple object. 
So as under which dates are happening in the 
game, sending all that stuff across just using this JSON 
review data channel. 
So more altruistic examples that you think are 
actually really cool, speaking of one that I was just 
recently shown. So this is basically connecting 
retirees with non-English speaking students in Brazil. 
And it allows them to practice their English. So 
speaking folks that are rather lonely that are trying to 
it teach kids English and using the simple web chat. 
And, again, all they need to do this is go into the web 
during the course that support WebRTC, and they're able 
to to have that video communication. There's no plugins
or software to download and that's the big thing. 
Again, they're not paying these huge bandwidth 
bills to host that server and stream all that data 
through that server. 
And another one that's a personal favorite of 
my is BMI. They built a concept to build an app that 
would allow site challenged people to dial into this app 
and request help. So imagine you're blind and you're in 
your apartment and you need to know if the milk is 
spoiled or if you're on a subway and they don't have a 
Braille system and you need to know which track to 
travel on. This actually allows to you open the app, 
and then they connect you via WebRTC, and you can Shem 
as though them what they're looking at or describe to 
them what you're seeing. 
So, again, kind of a cool way to look at use, 
or potential use for this type of technology. 
So it's just giving developers like ourselves 
a new way to work with new patients, new JavaScript, our 
language. We don't have to go out and learn 
ActionScript or god I even suggest it, flash to 
accomplish something like this. We can just use it 
using JavaScript. 
So how does it work? Kind of like this. 
Everybody remembers the old tin cans and strings is 
good. Ayou've got a tin can on one end, and the other
and connected with a string. So you place it in a 
browser and that peer on peer, this is kind of how 
WebRTC works. You've got two people that want to 
connect, and WebRTC figures out how to make that happen, 
and whether it's video, auto, data, all streams directly 
across. 
So to kind of bring this example home a little 
bit more, we're going to talk about bop and Alice. They 
met on a online dating site like many of us today, and I 
wanted to use paleodate.com for paleofolks that want to 
date. But caveman date.com is our example for today.
So Bob and Alice met on cave date, and they want to have 
a video chat and test the waters before they want on 
their first date. So in a ideal world, the browser
would update quickly enough that I could actually talk 
to it. It would look something like this. Bob and
Alice would change some information through a process 
known as signaling. And what it does is basically say, 
hey, I've got the compatibilities to share a webcam, my
microphone, and here's some information about how to 
access it, so my local IP address. And it could share
that stuff back and forth, and from that they could 
establish this peer to peer connection that we're 
talking about. 
About as we all know the reeled world isn't so 
ideal. We have got the network access translation, so 
things like your record at home or a firewall at your
work place. These are things that both allow us to have 
the networks that are existing today, but also block us 
from connecting. Fortunately there's a thing called 
ice. This is a technique used by WebRTC be to sort of 
Traverse that. So how to make those browsers talk to 
one another. So if Alice is at work before you went 
online dating and Bob is at home or a coffee shop, 
somewhere public. Let's say Alice has a big firewall in 
place, and Bob is wide open, Bob is going to try to 
figure out how to talk, he isn't actually doing this, 
this is happening on the back end. He's going to use 
something called a stunt server. And what it does, it's
got one roll, and when boll wants to talk to Alice, the
stun server is going to say, hey, Bob you're wide open, 
here's your IP address are, here's your port, Bob is 
going to get that information back and he's going to 
send that over to Alice. Alice is going to receive it 
and then say okay how am I going to connect to Bob. 
She's at work and can't access publically, so they're 
going to send a pact out to the stun everybodier, and 
it's going to say I don't know what you look like. So 
that's where this third piece is the turn serve certify. 
Basically that's a way to relay around that, so ideal in 
a why would world, this is about 86 percent of the time 
given statistics, so they both get the IP addresses and 
it will be done. So given the case of the firewall, 
which is that O'14 percent time where there's something 
preventing that from happening. It's going to come in 
and act as a relay. So Alice is going to send 
information back to Bob saying here's the turn server. 
When Bob sends the information over to Alice, 
it's actually going from Bob to that turn server and 
then down to Alice. When Alice sends information to 
Bob, allegation straight across. So when an ideal world 
what we're hoping to accomplish is a peer to peer 
connection where data goes directly across in both 
directions. But in the case of, you know, network 
issues or something like a firewall, you're going to use 
that relay server as a back up. So what's that giving
you is cover. Probably 99.99. But the piece to take 
away from this is through this technique, we have the 
ability to connect everyone peer to peer. So that small 
percentage of a time you're going to go through that
server, the rest of the time you're basically going 
directly across that channel and hopefully saving a ton 
of money. 
So the complete connection would look 
something like this. Bob and Alice would share 
information, and Napier to peer channel, in a nonperfect 
world be they would share through a server and the rest 
would go across. Simple; right? Ready to go out there 
today and spin a couple and play with this stuff? 
That's where spoke comes in. So it's a set of AP I's, 
it allows the developers to add them to their app.
It's sort of like WebRTC, but we wrap 
everything up for you guys. The turn server, the stun 
server, you can just focus on what you do with 
developing the app. So if you remember Bob and Alice 
the signaling process that's done, it looks something 
more like this. You connect out to respoke, we take 
care of that handshaking process for you, figure out how 
to connect that up, and then all it does is is really 
creating the application and how they're going to 
connect, whether they're going to have a video call or 
an auto call or hear some data back and forth. That's 
really all you've got to worry about. So we take care 
of the harder by the for you. 
And old Billy banks, my homey. But wait 
there's more. There's a few features we added up. You 
might wonder okay. I can still go turn on the server
myself. What's the value here? One it's open source. 
Our JavaScript libraries are at least so you can edit 
and add features to yourself. And all those nice 
prefixes that we love and hate so much. We're taking
care of those for you. Concepts likened point 
discovery. This is kind of a big one that's not taken 
care of by WebRTC People's No. so how do you find peep 
within the network or the application that you want to 
talk to? That stuff doesn't really exist in WebRTC, so 
you have to make it yourself. We handle methods for you 
to handle that for you. Concept, like, groups, 
messaging features, so you want if you want to accepted 
messages out to a group, things, like, presents, whether 
or not you're only, offline, we have compatibilities for 
that, and a really cool home system supporter. So if 
you want to have your mobile or web app talk out through 
the transitional network, you meant to have a button on 
your site to call out to somebody's phone, you want to
have a phone call into your web app, we have that 
supporter also. And WebRTC is currently not so were 
they in most if not almost all noticeable devices. So 
we added the compatibilities to view those adds native 
applications and put them into your web app. Let's get
down to the good stuff. 
So first thing you're going to want to do is 
go to spoke and get a free account and get started 
there. 
And I'm going to switch this up to get some 
code. 
Is that big enough for everybody? I'm not 
sure we're going to get everybody all the way in the
back. But thumbs up? Thumbs down? Up? I see pretty 
far back there. Sorry, bud, you're going to have to 
come a little bit closer. 
So getting started with this, how to all 
works, it's just a JavaScript library, so you Futch did 
you ever have isn't an include, and you're on of and 
running. Getting connected like I said is kind of the 
first part of that whole signaling portion that I talked 
about, that's going to happen during this connection 
phase. And to do that, you need a app ID, that's how
you identical yourself in the spoke frame wok and you 
identify your application. It acts as a container of 
sorts, so anything that connects user users in that app 
ID. So if you guys all Kecked thunder app ID here, 
we'll be able to find eastern other, everybody in the 
room. If we split half the room, it would split that 
group down. Half on the left wouldn't know about half 
on the right. It's basically the container for the 
application. 
There's concepts, you'll hear me mention end 
points and peers, those are just and ourselves browsers. 
An end point is somebody you're trying to connect to. 
So the first step is creating an instance of the client 
object. To do that with respoke, just call 
respoke.create client. And then there's a key piece 
here called development mode, we're going to set that to 
true. Basically what this does is handle all the tone. 
And most frameworks, you're going to have to take care 
of token and management of the user privileges. With 
development mode, we're just, like, leave that wide 
open. You can just connect in, play with all the 
different AP I's with all the sources users have access 
to everything. Once you're ready toking into 
production, you're going to have some simple stuff to go
through. 
So once that we get client object, we can 
start calling some listeners on it and calling some 
methods. The listener we're going to add here is 
connect. And that's basically saying, hey, you're 
connected, start playing around. Your video call is
ready to rock. You're ready to start going. And then 
to get connected, we're going to call client.connect and
pass through a pinpoint ID, and in this case it would be 
the ID that I want too to connect as. So if I pass as 
Kyle, on an e-mail address or however you is to your 
users in a database, it's up to you. But the end point 
ID, the take away from that as little how you're going 
to find people. If I log in by Kyle, you can look me up
by Kyle. 
And you're going to be ready to roll. 
So messaging. We're just going to look at the 
code for this. Have he simple. You connect up, and 
once you start connecting, messaging would be I am the 
of my I want to send a message to another user. This is 
an example of point to point. So me to one other 
pepper. 
So to do that, you would call client.listen, 
or messages even, and then you just get back in a and 
event all that is is a simple JSON object. So you 
access it message.message.message. For send a message. 
You're going to first get the ID of the person you want 
to talk to, in this case we're talking about remote ID. 
And this is just some J Cory I've used hero. End point, 
the that's the person you want to talk to. So we would 
want to pause putt the ID of the person I want to talk 
on pop so in this case it would be John. And once I 
have access with that end point, I'm going to start
communicate with that person. So I'm going to call end 
point.send message. With the property of the message 
and the message I want to send with the message. 
So you can get an application going with that 
pretty quickly. The group messaging. We'll actually 
look at a quick demo on this one. So if anybody is 
following along out there, if I could get a couple of 
people to click on that link, the DNXBUC link on there 
and that should open up the group messaging window. And 
you'll see here I've got not connected respoke, not 
connected to the group. And what's going to going to 
happen here is I'm going to use the user name, hit Kyle, 
go through that connection process that I talked about, 
and then it's going to automatically join a group, and 
we'll see how it is happening. 
As you can see here it's just really simple 
but it's sending mentions out to a entire group of 
people. And the UI is purposely dumb. It's meant to be 
for show casing here. So to look at the code for that, 
it's very similar to the code we had in the original, 
except we added some functionality to create a group.
So we're going to listen for that connect event again, 
and when that happens, we're going to join this group 
and pass on a group ID and then there's on success and 
hedge handler inside the group. So on success, I'm
going to start as to that group as a variable, is and on 
message I'm going to pass the message out to that list 
that I'm showing in the window there. And then to send 
a message to a group, it's the same as sending a message 
to a single person or an end point. It's called 
group.send message and it passes out the valley that we
want to send out. So pretty simple stuff out there. 
10, 15 lines of code you can get messaging through a 
group. 
To get into something more interesting. Take 
a look at video. Hopefully all works perfectly. If 
somebody could go ahead and click on this link that's 
following along there and then just give me a little 
hands up that you're going to participant via the demo. 
Please, all right if you just let me know the name that
you logged in with. All lower case? Okay. 
So I'm connecting in as Kyle, you can see the 
whole connecting process happen. And then I'm going to 
call out to connect to rob. So I'm just typing in Rob's 
name here. And I'm going to hit call.
The first thing you're going to see here is 
the access to my of mine. Once I click allow, you'll 
see the first thing on Rob's end, and then hopefully 
we're going to see rob. Nice. 
So you're live on camera. So this is actually 
a hell of a lot simpler than you might expect, and this 
is the cool stuff with WebRTC, I'm able to set up a 
video call with a couple of simple things. 
And looked at this example here. We've got a 
couple of new things here. We knew the whole connection 
process, and I'm not showing that here just to keep the 
code simple. But you've got this DIV for the local and 
remote source. 
Once we get past that, we've got some options 
here, and that's is just option to allow constraints,
and constraints are what I as the user or developer. So 
if I want to add some UI feature that allows them to 
turn off their of mine or web camera, this is where you 
would update those properties. So in this case I'm 
sharing out auto and video. And I'm going to share 
everything and have a full video call with Rob. And
then we've got methods here for on local media, which is 
when my video becomes available and on connect, which is 
when Rob's video becomes available. So these messages 
say what I want to do when that becomes available for 
me. 
When you're going to get back in that event is 
a video element. So you wrap up the stream in a video 
element, pass it back to you, and then all you need to 
do is pass it back to the GIV. And all that really does 
is take the DIV, and then passes out the element, so you 
can see here I'm pag of out event.element, that's going 
to be the element that's being returned, and then local 
video source was the DIV that want that I want to 
access. And then I'm listening for a call event. 
This is going to listen for a incoming call. 
So here you can see active call is event.call, it's the 
that gets passed with that and that's how you access 
with video calls or auto Sauls calls for a legal 
conclusion. And then I'm going to do a simple check 
here. And it's going to say whether or not I'm the one 
who initiated this call, argument answer missable so
this check take care of that. So when I place a call 
for Rob, his checks for this, and it's I'm not the guy 
that I want to call, and then it's going to pass through 
the call options that was applied. 
And then it's going to add a in line hangup 
peasant it's when you dissect. And to actually pake the 
call happen, we're going to get access to that end point 
the same way if we did messaging calling client.end
point, subsequently the recipient you want to talk to, 
so Rob in this case. Once I have access to that end
point, I'm going to pass through this call options. So 
see athe person initiating through the call, all I have 
to do is call end point and pass through those options 
with the simple JavaScript and then wait for the call to 
come back. 
And from there here's my video, all I'm using 
is JavaScript, clearing out anything that's already 
existing and pending the video element that I passed 
through. That's really all there is to start a video 
call. You know, we're looking at 5 lines of code here
with some flush for the JQUERY stuff. Pretty simple , 
yeah? 
And we'll look at something very similar, 
which is screen sharing. This actually functions almost 
exactly the same. I'm going to pick on Rob and ask for
his help again if you don't mind following along there. 
I'm going to hit connect. Connect up the same way we
did in the other examples. And then once I get the 
thumb's up from Rob that he's connected, I'm going to go 
ahead and call out to rob only this time instead of 
sharing my web cameras, I'm going to actually capture my 
desktop. So you're going to see this popup. This is 
very familiar with anybody. It's the exact same UI. I 
can choose which screen I want to share out. So if I
want to share my whole screen or maybe Michael Jordan 
line text. 
I'm going to hit share and it's going to bump 
me over to the it app. And as you can see here, this is 
my screen being shared out and Rob should be seeing the 
same thing on his end. Probably not as interesting for
the rest of you. This is a one-to-one demo. But the 
screen should share out and he should be able to say any 
updates I'm seeing on my side. Hoping for a thumbs up. 
Demo problems. Is there any sort of allow or anything 
that came up? 
So what should happen when the demo works 
properly is that Rob should share the screen. Probably 
a simple fix of security going on there, but I want is 
to show you guys the code. That's the more interesting 
part of this. 
So, again, we've got a video element for 
local, video element for remote. Similar stuff that we 
did in the video screen example. The only main 
difference is we've got to install a small plug in. 
This is a polyfill for chrome right now. Once that 
happens, you did have to do this plug in. So this code 
here is basically handling a check saying do they have 
the chrome extension yet? Finance the, we're Googled 
and let them install it. Luckily it's an inline 
installation, meaning you don't have to go to another 
website, you can download it all within that one package 
I. So it's going to go out and find the plugin, install 
it to the user, give me a notification that's all 
reasonable doubt to rock and then we're going to move 
on. So once this success happens, or a O if I already 
have the extension, which in my case is younger see any 
installation process happening.
So we're going to go to sharing. I'm going to 
get access to the local and the video element, and then 
I'm going to call end point.start screen share, passing 
in the video element here. This is a little bit 
different in that I'm going to pass the video and local 
objects into the method here. And they're actually 
going to attach the video for me automatically. This is 
just the helper feature that was built in part of the 
rephrase the question work, so you have options in how 
you're going to connect up, depending on how you want to 
interact with that code. 
Needing more access, you want to do some more 
UI updates in between, being you get that actual element 
back and edit it yourself. If you want to automatically 
connect to the DIV and start streaming, you can do that 
as well. 
But basically it's a screen share. You get 
the same thing back. A video element returned. And 
it's just going to use your screen as the source of 
sharing or the screen, video streaming as opposed to 
your webcam. 
And then there's a handler process here if it 
fails to install properly. 
Snooze screen sharing. Docs and additional 
examples, there's more up on that you can see how all 
that stuff happens. So to kind of wrap up a little bit. 
What does all this stuff mean what's the point of 
WebRTC, why is it available, why should you care? A
fame workadds faster development. I like to harp on 
this one specific point. How many people in this room 
have gone to a website in the last couple of months 
where they've been logged in, people on the website, 
they know who you are, your session identifies you, your 
account information, maybe you're on your cell phone, 
they know everything by you, they know the page you're 
looking at, it's all there in the session. But then 
when you need help, you have to dig up an 800 number, 
and you have to be enter your account information. 
Probably some other personal identification stuff for 
security. And then you get somebody on the phone if 
you're lucky who then asks you for your account 
information and your mother maiden's name. 
We've all been through this process, it takes 
an hour to get any kind of information you might want. 
I would like to propose that as developers, we have the 
power to change that. Given these two tools in that 
same scenario, this can be I button on the website that 
says click to call; right? Or just call. So you click 
the button, it on pops up a video chat. You take all
that session information that we already have through 
JS, pass it through to the supporter representative. 
The. On the other end one you can decrip that 
information so they know who they're talking to, what 
account information you have, they know what page you're 
looking at, and they can more readily help you with your 
problem. So I would just like to challenge you guys to 
start thinking about in things new ways. We haven't had 
access to of mine and video in reason JavaScript, but we 
have the chance to change things for that. 
So you build some cool app that makes you a 
million dollars, you're going to be pretty stoked, he 
but we have a chance to connect with people. There'sal 
relevant really a chance to change lives with what 
you're creating, and these tools are going to give you a 
chance to do that.
So the thing I would like to leave you with. 
Communication should be a feature with not a product, I 
would like to challenge you how communication instead of 
asking you if you can go and up op up the site, go jump 
on Google hangouts. If you're on a remote team, this is 
hugely important, that was part of it driver for it. 
Because we wanted communications to happen in a seamless 
fashion. We wanted multiples ways to do it. So we 
built that to allow it. The other thing I played around 
with is a demo with the technical interview. White 
boarding and code challenges, all live over a video,
with video chat. 
You know, it's all stuff you can build. So if 
you see use cases out there, there's a ton of nails, 
this is the Newhamer; right? So look at ways you can 
start being building commutations into your application 
as features rather than creating separate products for 
it. 
That's it for my, my name is Kyle Tyacke, and 
you can catch me on Twitter and if you want to play 
around with this stuff. The whole example and sources 
all available to you at the URL at the bottom, if you
can't read it, hopefully you can come up, and I'll open 
it up for questions, if we have time, if not -- 
>> No questions. 
>> All right. Well, then just find me 
afterwards. I also brought some stuff for you guys if 
you want to come to the shop up front. 
>> So we're going to taking a break for lunch. 
Don't rush out yet. They might not be totally set yet. 
If you didn't order a special meal, please don't take 
one. And if there's an Elliott cable in the office, the 
front desk is looking for you. Yeah, enjoy lunch.
We'll be back at I think 12:45? To talk about closures. 
Thanks.