[LOGO MUSIC PLAYING]
GABE WEISS: Welcome to our talk, Building IoT
Applications on Google Cloud.
I almost said the wrong one.
I am Gabe Weiss.
I'm a developer advocate for Google
on Google Cloud Platform, specializing in IoT.
Also on stage with me, we have Calum Barnes.
He's a product manager on IoT Core.
We have Martin Varela--
sorry, I'm, like, losing people's names already,
developer advocate on start ups.
We have Alicia Williams--
sorry, Rob Wormald next to her.
He is a developer programs engineer on Angular.
And lastly, Alicia Williams.
She is a developer advocate on G Suite and Google Cloud
Platform.
So given the range of people, that
might give you an idea of what we're talking about today.
So now you know who we are.
I want to know who you all are.
So how many developers, operators, infrastructure?
People that are doing the work, quick show of hands,
how many do I have on that?
Woo hoo.
Nice.
Welcome.
Thank you.
Who out there are executives, C levels,
business decision makers?
And some of the same hands are going up, so start ups, yeah?
All right, cool.
How many data scientists do we have, any data scientists?
Good, oh, yeah, nice.
Everyone else, do your arms work?
So now that we all know who each others are,
application development.
There are a lot of decisions that
need to be made before you can start laying down
code for an application.
I don't want to fool you into thinking that, yes, we're
going to be building an end to end app today in the 45
minutes we've got.
But I don't want to fool you into thinking that you
can actually do it on stage.
All of these decisions that need to be made,
we made a lot of them beforehand.
What I do want you to walk away from this talk
with are three things.
One, understanding what questions
you want to be asking yourself about the app
that you're going to be building.
What are the different parts that are out there?
What do we have product wise in Google Cloud Platform that
help you build these IoT applications?
Two, it really is, from a raw code standpoint,
easy to build these end to end apps.
There's a lot of moving parts.
There's a lot of products involved.
But the actual implementation of each part
is actually really easy to do.
And we'll be showing you some of that.
And thirdly, that what you can put together
in this short amount of time is immediately useful.
The data that you can get from these simple applications
can immediately be introspected, can be looked at,
can be used to get ROI on whatever business
that you're doing.
What I don't want you to take away from this talk
is that whatever you put together
in that short amount of time is production ready.
It's not.
Product managers, don't let your eng teams tell you
that what they put together in a day for an IoT app
is totally ready for release.
And eng teams, don't let your product managers tell you
that hey, I saw at Google they put together an app in an hour.
That's enough time, right?
It's not.
Don't let them tell you that it is.
So what's the first thing that you need in order
to build an application?
Does anyone have any ideas?
You can shout it out.
If you're shy, it's OK.
I'll still give you my answer.
But does anyone have an idea?
What do you need before you can build an application?
AUDIENCE: [INAUDIBLE].
GABE WEISS: An idea, absolutely, first shot, nice--
so you need an idea.
You need to know what you're building towards in order
to build an application.
I'm going to walk you through what our idea is
and how it dictated some of the technology choices
that we made in order to build our application.
The question that I wanted answered--
who up here, amongst us, is the coolest onstage?
Who's the most nervous?
Who's anxious being on stage in front of everyone?
So there's one really reliable way to detect stress in humans.
It's a chemical called cortisol.
You can test for it in your blood.
And its presence and the amount of it
tells you empirically how stressed out you are.
I asked the organizers, and they did
tell me I'm not allowed to create
a biohazard situation on stage.
So I couldn't do blood testing.
So the next step, what about blood pressure?
So blood pressure, how elevated it is,
will tell you how stressed you are.
Let's think about a blood pressure cuff.
It requires that you can detect your heart rate,
and you have to be able to apply and release pressure
in an even way around your arm.
It's totally doable with IoT, but maybe a little ambitious
for a 50 minute session.
So I kind of got rid of that.
So our last option that I fell back to
is this thing called the vagal tone impulse.
This is your vagus nerve.
The vagus nerve is what regulates your heart rate.
It's what keeps your heart rate within normal amounts.
During times of extreme stress, the vagal tone impulse
is suppressed, so that your heart rate can skyrocket,
so that you can be ready to do whatever you want.
The comment-- you've probably heard about it--
is the fight or flight response.
So once you're in that mode, your heart rate
can go up, even though you don't have any physical need for it.
So for example, if you're nervous,
and you want to tear off stage and run away,
you'll get your body flooded with blood
so that you can do that faster.
So why am I giving you this biology lesson?
I could have just said, hey, we want
to know who's nervous on stage, and away we go.
The reality is, I'm vamping a little bit.
I wanted to give my team a little bit of a head start,
so that we can actually show you, as we're
building, what we're doing.
So I needed to give them a little bit of time.
Also, there's still a monster line outside.
So I wanted to make sure that everyone
could come in before I'm talking about the technical stuff.
So architecture-- here's the architecture
in its entirety for the application
we are building today.
We're going to be creating a simple data driven application,
using the IoT devices that Calum is building for us as we speak.
For each piece of this architecture,
I'm going to talk through the product
that we chose, the other options that are available to you
in Google Cloud Platform for that piece of the architecture,
and then show you a little bit of the implementation
that we're working on as we speak.
So first, let's chat about this device that we're making.
It will be able to measure your heart rate and temperature.
And between those two data points,
we're going to be able to tell who's really nervous up
on stage.
Heart rate, in particular, is going
to be our primary indicator.
So hardware and IoT--
how do you pick what hardware you want to use?
Once you pick your hardware, how do you
pick what programming language, what software you
want to use on that device?
There is a problem for those of us
that are building out these devices right now.
And the reality is, who was alive in the '70s?
That's the first question.
OK, good.
There's at least some of us.
I don't feel too old yet.
So in the '70s, we had VHS and Betamax.
Did anyone own a Betamax player?
Yes, yeah, me, too.
Next if you heard about laser discs?
Anyone hear about laser discs?
Yeah, all right, so laser discs and DVDs.
And now we've got Blu-ray and HD.
Hopefully, most of the room would know about that.
So it's the idea of standards.
Each of those technologies eventually
resolved into a standard that most of the market could adopt.
In IoT, we don't have standards right now.
It is a complete Wild West.
You could pick any hardware and any software,
and it would still work.
This is just a small sampling of the options
that you've got up there today.
Sometimes an environmental factor
will help you narrow down this choice.
So if you're working on the side of a mountain,
your options will slim down.
You've got communication problems.
You've got power consumption issues.
That can help dictate what hardware that you're picking.
The reality is that for most large scale IoT installations,
you're going to have custom hardware that gets built.
You're going to have a microcontroller
with custom sensors that really defines
the minimum device that you need to accomplish,
whatever the goal is.
Our only real requirement is to read analog sensors.
Our heart rate and temperature sensors are analog.
They're off the shelf.
So we needed something that could speak analog.
We also want it super easy to set up.
We've only got 45 minutes to build the entire thing.
So I wanted to be sure that whatever we picked
would be really easy to set up.
The Python libraries have everything we need.
Everything that we need to do this end to end,
Python has libraries for them.
And it was out of the box.
We wanted something that could run Python.
So our device is an Arduino, so that we
could read the analog devices really easily,
connected over serial to a Raspberry
Pi, which is super easy to connect and runs Python.
Production, obviously, for most IoT,
that's not what you're going to end up using.
It's not cost effective.
But for our purposes, just to highlight the technology,
it's going to work great.
So let's take a look, if we could, at the device
that Calum's building.
Could we switch to demo one, please?
What we're seeing here is we can see the Arduino chip right here
on top of our device.
And inside this case is the Raspberry Pi.
The two sensors that we're seeing now
is the heart rate sensor, which is on a little ear clip.
And then we've got the temperature sensor,
this little probe guy.
So I'm going to have that temperature sensor in my mouth.
And we'll see how accurate a reading
we can get as I'm trying to give a talk
with a sensor in my mouth.
So before we check out the software
that Calum's got on the device running,
can we switch back to slides now, please.
I want to talk to us a little bit about ingesting our data.
Yay.
So before we can ingest data, there
is something I want to talk about,
and it's going to be the hill that I die upon for IoT.
And it's a question.
What does the S in IoT stand for?
Security-- it's funny, because there's no S in IoT.
You get that?
Ha ha.
So there's a couple of anecdotes I
want to tell about security that kind of highlights
why you should care.
A couple of years ago, a bunch of you
may remember, that the whole internet, large swaths of it
went down for hours.
It was something called the Mirai botnet attack.
And what Mirai software did is it scanned the whole internet
for unsecured IoT devices.
It found 11.3 million of them.
It launched a massive botnet attack
against DYN, the domain services for the whole internet.
And it took the internet down for a bunch of hours.
So that's the macro view--
all of those devices could take down something
like the internet for a while.
Micro view-- last year, there was a single temperature sensor
in a fishtank in a casino.
And it was connected to an internal machine
so it could regulate the temperature of that fish tank.
And an enterprising young Finnish hacker
found that temperature sensor, hacked it,
got access to the internal machine
and pulled out 10 gigabytes of high roller data
from that casino.
They lost millions of dollars and lost face
to all those high rollers.
So this is why you need to care about security.
The macro view with the Mirai botnet attack and the micro,
with this Finnish hacker taking all of the casino data.
I could talk for a long time about how
you can counter-measure this, how
you can secure your devices.
I'm not going to because, on Thursday at 10:20,
there is Security and IoT Talk.
It's being done by a colleague and a partner of ours.
That is a really good talk.
So if you want to learn and go into depth on security and IoT,
go to their talk, because it's going to be really good.
For ingestion, then-- back to that-- this
is why I picked Cloud IoT Core as our choice for that.
Cloud IoT Core is the Google Cloud Platform gateway
for devices to send their telemetry data up
into the Cloud.
It handles things like device authorization,
that security piece I'm talking about.
Management-- it allows you to configure your devices
from the Cloud.
You can send messages back down to your devices.
It allows you to have your devices report their state.
So you can check the health of your fleet from the Cloud
without having to talk directly to your device.
It's a managed service.
It's just an endpoint that you talk to.
So you configure your devices to talk to a URL.
There's no client library.
So if space is an issue, if you're
on a microcontroller with only 200k of space,
it's at a premium.
You don't want to have client libraries.
IoT Core lets you handle that.
All right.
So before I show you the code that Calum
is writing on the device, I want to talk
to you about what the other options that you could do.
Instead of talking to IoT Core, what
are some other possibilities that you could do?
You can leave IoT Core and talk directly
to the event queue system that backs it, Cloud Pub/Sub.
So you could cut out IoT Core.
I left the management block on here on purpose.
Because if you skip IoT Core, what you're left with
is having to manage your devices.
You have to authorize them.
You have to deal with them if one of them gets compromised
and you have to shut it off.
You have to now manage all of that yourself in software.
Another option-- you could skip all of that
and talk directly to your data store.
Now on top of having to manage all your devices,
you also have this problem where,
what if your right to your data store fails?
Someone kicks a cable or sunspots or just
a plain networking problem?
Now all of that retry code to get your data into your data
warehouse, instead of already having your data in the Cloud,
in something safe like Pub/Sub, now you
have to redo it from your device.
Which, for devices, network is your battery killer.
If you have to keep running network from your device,
that's going to run you out of batteries,
and causes this cascade of failure.
So if you skip all of this and talking directly to data store,
your devices or an edge machine is now
responsible for doing all of that retry logic.
So again, this is why we went with IoT Core.
It's the way to go.
So we're almost ready to talk to that code.
No, I lied.
We actually are ready to talk the code from Calum now.
So if now we could switch to the demo one, awesome.
And Calum is actually going to take us through the code
that he wrote on the device.
CALUM BARNES: Thanks, Gabe.
So what I've done, since we only have 45 minutes here,
is basically copied most of the code
from the IoT Core Python tutorial
written by another great dev advocate, Gus Glass.
And what that does for us is make two things really easy--
connecting and authenticating with IoT Core,
and then sending messages to IoT Core over MQTT.
And those are the messages that are
going to contain the data we're going
to build our application with.
So you can see in this Python sample that
comes straight from the website, we have a Create Jot function.
If you go to that security talk Gabe mentioned on Thursday,
you'll find out even more about how IoT authentication works.
But we create a special Jot authentication token
based on a private key on the device.
And this function makes it really,
really easy to generate that and send it to IoT Core.
And then the rest of what we have is basically
boilerplate Paho MQTT code to connect to the IoT Core MQTT
front ends.
All I've added in here in the last few minutes
is some configuration information
about the specific project that Martin set up
when we got started.
And then a little bit of code to talk to the serial input
from the Arduino and toggle to LED
when we get over some limits that we'll talk about later.
So all of this has been pretty easy to write,
because I was able to leverage the samples that we
have on the IoT Core documentation website.
GABE WEISS: Great.
CALUM BARNES: Thanks, Gabe.
GABE WEISS: Thanks, Calum.
So we've now covered kind of the why and the
how of devices and ingestion in the Cloud getting up there.
Next up, we need to get all of that data
from Cloud Pub/Sub, where IoT Core puts it,
into our data storage.
We've decided to use Google Cloud Functions to do that.
Cloud Functions are serverless methods.
They can be called with either an HTTP GET or POST call
or triggered from something that happens in Google Cloud
Platform.
For us, we're using Pub/Sub as our trigger.
So any message that comes into Cloud Pub/Sub
will fire off this function.
Since I know Martin's probably already getting bored,
since he finished this in the first two minutes,
we're going to cut over to Martin,
and we're going to show some of the code that he did.
So we need to switch to demo two, please.
MARTIN VARELA: Yep, that's it.
GABE WEISS: Awesome.
MARTIN VARELA: Thank you, Gabe.
So I just finished five minutes ago--
I didn't have that much time--
deploying this function that is called telemetry to Firestore.
Again, as Gabe said, what this is doing,
this function is subscribed to Pub/Sub topic,
so that every time one of the devices that we are building
sends telemetry to IoT Core, that sends a pops up message
and triggers a new execution or a new instance
of this function.
Let's take a look at the code here.
As you can see, this is written in JavaScript.
And it's running on a Node.js V6 environment.
At the top, I'm just calling and importing the library
that I'm using to write to Firestore
and initializing the app.
Because we are running on this managed environment,
we don't need to do any authentication.
That's handled for us.
And then the about 20 lines that are next
is the output function.
The function expects an event from Pub/Sub.
I will check if it has data.
Otherwise, I'm going to throw an error.
Then I'm going to [? base ?] 64 decode the payload,
parse it into a JavaScript object,
so it's easier to [? run ?] the attributes.
And then this is where I run right to the [? DV. ?]
How Firebase works, or how Firestore works is
that it stores a collection of documents.
And each document can have a bunch of different attributes.
In this case, we're sending the timestamp, temperature,
and BPM, as you can see here.
And this is the path to where I want to write the documents.
And then it's just--
whether it fails or not, I'm going to console.log it just
for reference.
And that's pretty much it.
GABE WEISS: Sweet.
Thanks, Martin.
So this is the glue that joins our event messaging
system as the telemetry's coming in to our warehouse.
Can we switch back to slides again, please?
So let's chat a bit about the other options,
if you didn't want to use Cloud Functions.
And there's a reason you might not
want to use Cloud Functions.
For IoT, there's really three really good options
in Google Cloud Platform for this--
Cloud Functions, Cloud Dataflow, and Cloud Dataproc.
Cloud Functions I've already covered.
They're serverless.
It's a low barrier to entry, because it's JavaScript,
so it's easy to stand up and get going.
And it fires once per message coming in.
That once per message coming in-- that's the catch.
That's the reason you might not want
to be using Cloud Functions.
If you're managing a fleet of a million devices,
and those million devices are sending
a message once a second, that's now
a million firings per second of this Cloud Function.
Part of their cost is number of invocations.
So if you've got a system that has a very high throughput,
that's why you might want to look at Cloud
Dataflow, and Dataproc.
So Cloud Dataflow and Dataproc are both managed service.
They're very similar in what they can do.
Dataflow is our managed service for transforming incoming batch
for streaming data.
It can do pipeline development with the Apache Beam SDK.
And it handles very high throughput.
That's what it's designed to do.
Dataproc is very similar to that.
It also handles a very high throughput.
It does a lot of the same transforms.
It's hosted Apache Hadoop and Apache Spark.
So really, why would you pick one versus the other
is the platform that you're familiar with.
So how do when you should use one versus the other?
The answer is, it really depends.
If you're not doing anything but shuttling data from point A
to point B, you're just taking it from the event system
and pushing it into your data store,
it really doesn't matter that much.
They're both going to perform really well for you.
The invocations per second is what I'm talking about.
So if you've got very high throughput,
that's where you would want to switch over
to Dataflow or Dataproc.
For me, general rule of thumb, always
prototype with Cloud Functions.
Get your entire end to end working.
Find out what you don't know.
Get everything functional.
And then when the cost starts to become an issue,
cut over to Dataflow or Dataproc.
All right.
So we've got ingest.
We've got devices.
We've got pipeline.
Next up, we're onto storage.
Everyone still doing OK out there?
Ah, so I know I'm throwing a lot of stuff at you very quickly.
I wish I could tell you it's going to get better.
It's not.
I'm going to continue to throw a lot of stuff at you
very quickly.
Because next up is storage.
And there's a lot to cover.
So for our application, we picked Cloud Firestore.
It's a NoSQL database.
It's very low latency and low response time.
It's perfect for doing the real time visualization that I
talked about at the beginning.
Because, built into it in native mode,
it's got a push mechanism, an update mechanism,
where anytime you get a data change, it fires a callback.
It's one of the unique pieces of Firestore
in our kind of storage options, which is why
we've decided to pick it today.
It's also really easy to stand up.
So what are some options if you didn't
want to use Cloud Firestore?
We have a flowchart for that.
No need to memorize this.
It's actually on our website.
It's at cloud.google.com/storage options.
Memorize that one.
So this flowchart is not intended
to give you the be all, end all option for your storage.
There's a lot of edge cases that are little gotchas in here.
But this flowchart will help you with things like,
is your data structured or not?
Are you doing analytics or real time analysis?
Do you need mobile SDKs?
That's what this flowchart will help you with.
Cost is the last piece.
The flowchart won't help you with cost.
But it's so dependent on your individual applications.
We have tools online that you can
put in things like general throughput, amount of storage
you need.
The online tools will help guide you
through what your rough monthly cost will be,
depending on the storage that you pick.
So there's too many on that flowchart for us
to go through all of them in detail.
But I want to highlight just a few.
And to speak to IoT, there's usually two different things
with storage that you're wanting to care about
for an IoT application.
There's a real time analysis.
If you're doing things like fault detection
or automatic inference, you want to get a low latency response
or you're doing really heavy analytics.
So IoT often is just a vehicle to get data into the Cloud
to run analysis on.
Those are the two things.
And so I put them on this graph so
that I can put our different products on it to give you
just a ballpark finger in the wind what
the different products are good at.
So first up, Firestore.
I've already pretty much covered it.
It's very, very good at real time.
And it's not the worst in analytics,
but it is a NoSQL database.
If you're not familiar with SQL versus NoSQL,
NoSQL's not the best at doing really complicated queries.
Because you have to scan a whole bunch of rows and then
parse for what you want within it,
since it's unstructured data.
SQL is much better for writing that kind of query,
where you can really get out exactly what you
want in the query.
So that's why Firestore is where it is.
Next, we have Cloud Bigtable.
Bigtable is the speediest of our speedy NoSQL databases.
It's incredibly fast.
And it scales up to really massive amounts of data.
Petabytes of data are not a problem for Bigtable.
The reason it's so far on the analytics left-hand side--
because it's terrible at it.
The way that it is so fast is that it
is incredibly bare bones.
Anything that you want on top of it, you have to build.
There's no tooling built into it.
So it's kind of a blank canvas NoSQL database.
We would never have done it for today,
because there's way too much tooling you'd have to build up.
Next up is Cloud Datastore.
It's much more of an out of the box NoSQL solution.
It's got a bunch of tooling on top of it.
It's got a very well-developed querying API,
and it's easy to understand and use.
In function, it's very similar to Cloud Firestore.
The tipping point for us with Firestore
is why it's a little bit better in the real time-- is
that update mechanism, that push mechanism.
We didn't want to have to build something to do push
to a real time front end.
So that's why we picked it over Datastore.
Next, we have Cloud SQL, our SQL option.
It's hosted by SQL or Postgres.
If you need a SQL database, this is the option for it.
It's very low latency.
It's better on the analytics scale, because it's SQL.
So it can do more complex queries.
There is a gotcha in SQL-- you should know about it--
which is SQL cannot horizontally scale.
It can only vertically scale.
So if all of your data fits happily on a single machine,
awesome.
Use Cloud SQL if all of your data will.
Now for today, I could have used Cloud SQL.
There's no way our sensors today are going
to overwhelm a single box.
But I didn't want to highlight a solution that,
for most IoT applications, aren't going to be doable.
Most IoT is going to produce enough data that it
would overwhelm SQL right away.
And lastly, way down on the corner, we have BigQuery.
Does anyone know about BigQuery already?
A bunch of you do.
If you don't, get familiar.
If you're doing any kind of data analytics,
BigQuery is what you want to use.
Hands down, no question you should be using it.
And if you're not doing analytics
as part of your IoT application, I would ask you--
why are you not doing analytics as part
of your IoT application?
Because it's data, and a lot of it, and you can get really cool
stuff out of it.
So BigQuery is-- it's unique in the offering in that you
use SQL queries against a NoSQL back end.
And it's amazing, which means for analytics,
it is the best of both worlds.
You can use SQL statements, and it horizontally scales.
It also will scale up to petabytes of data.
And you can run queries performant
for the size against that data.
Now having said that, it is performant,
but it's not real time.
I would never ever build a real time application
on top of BigQuery, because it will be terrible at it.
If I had more time in the session today,
and in a perfect world, you would
want something like this, where that Cloud Function is
pulling your data out of PubSub and putting it
into your real time analysis data store, like Firestore.
You would also duplicate the data over into your data
warehouse, like BigQuery.
That way, you really get the best of both worlds
for the cost of some storage, which is cheap.
You get the real time analysis.
You get all of the low latency of Firestore.
And you get the power and the analytics of BigQuery
behind it.
So I've talked a little bit about
latency, real-time processing.
Something that I haven't talked about yet,
which I can't, is computing on the edge.
That's kind of all the buzzword right now, right?
You want to compute on the edge.
Be on the edge.
I could spend an entire talk discussing Cloud
versus the Edge versus Hybrid versus Fog,
although Fog really is just edge.
It's just another buzzword.
The whole talk is going to take up all the time.
Broadly speaking, kind of a finger in the wind,
storage-- do it in the Cloud.
If you need real time compute, low latency, do it on the Edge.
You want to do data visualization, probably
safe doing it in the Cloud.
Safety checks on a nuclear power plant?
Please do it on the Edge.
Don't do it on the Cloud.
So we've covered all of our headless stuff now.
We've gone from device up into IoT Core.
IoT Core bridged into Cloud Pub/Sub.
Cloud Functions pulling off a Pub/Sub,
dumping it into Firestore, all of the no visual stuff.
So we still have not answered my question of who's nervous?
So let's see if we can answer those questions.
I could spend a really long time talking
about all of the front end possibilities for an IoT
application.
This is like the tiniest of samples up there.
I do not have a mountain of time to talk about front ends of all
of what your options are.
So I'm going to talk about the two options
that we have picked.
So we could have just one front end.
But I wanted to see how many people we
could pack up on stage here.
I asked if we could do four.
They told me I didn't have enough pedestals to do four.
So we settled on two.
It was kind of a negotiation back and forth.
So my goals for showing you front ends to an IoT
application are twofold.
I wanted to show you real time visualization and time slice
visualization of data, and I wanted
to show off the front end's ability to modify metadata
around a device.
And I talked about earlier, IoT Core
has the ability to send messages back down to a device
and configure them.
And we're going to try that.
Hopefully, the demo gods are kind.
So first, to highlight the real time display piece,
I wanted to talk about Angular.
That's what we picked.
How many of you know what Angular is?
Yeah!
All right, so Angular is our batteries
included framework for JavaScript.
It has components to do everything
that you would need to do in a web app-- routing, animation,
rendering, forms, iolate [? end ?] support, integrated
testing.
All of those things you would want to have in a web app,
we've got in Angular.
So at this point, I think we're going
to try and get me loaded up with a device.
I think I'm ready.
Rob, are you ready to show off your piece?
All right, so normally you wouldn't ever
do this in production.
We would have unit tests.
We would have integrated tests.
We wouldn't be using a device that we just built on stage.
Here, we just pray to the demo gods and see how it goes.
All right.
So I'm going to hold this in this hand.
Then we're going to slide--
Can we switch to-- what do you want, [INAUDIBLE]---- demo two?
And input three-- uh huh, uh huh.
OK.
So let's see.
I'm shaking like a leaf, but I think I have decent connection.
All right.
So what we're seeing on screen now
is the iteration of the devices.
So all right-- so we clicked on--
Gabe's device?
Hey, where'd it go?
Where's my device?
There we go.
Hey, Alicia, could we change my name to something snazzier?
Gabe's device is kind of boring.
[LAUGHTER]
I am now the Destroyer of Worlds.
Thank you, Alicia.
OK.
So if we click into that, and we're seeing,
now, these latest readings, we might have some garbage here.
Because when the heartbeat sensor
isn't attached to a finger, it just
sends kind of random noise on analog.
So it looks like we're kind of starting to normalize
a little bit on device here.
I'm trying to make sure that I've got it.
Yeah?
OK.
I want to highlight two things that just happened.
So first, the Angular app that's on stage now
is reading from Firestore in real time.
Any of the sensors that are getting pushed once a second up
into the Cloud are being-- yeah, I'm still going--
are being shown here.
So you see, you know, my BPMs 107.
I'm excited.
And two, Alicia made a change to my device in Firestore
on her front end.
And it was almost instantly recognized in the Angular app
and updated live.
So Rob, I do like what we've done here.
But it's going to be hard to tell, side by side, who's
actually the most nervous.
Can we get all five of us in a graph?
ROB WORMALD: [INAUDIBLE].
GABE WEISS: Sure, I can give you a minute.
While he's doing that, I'm going to talk about our second front
app with what Alicia's been working on.
Can we switch to Alicia's laptop?
So while we're doing this, once we're hooked up--
Martin and Calum, you guys are getting hooked up.
Rob, when you're done with the graph, go ahead,
and you get hooked up, too.
Hopefully now we've got Alicia's screen
that's going to come up soon.
So while we're getting her set up here,
the second front that we're doing
is going to be Google Sheets G Suite backed by Apps Script.
So do we know about Apps Script?
AUDIENCE: [INAUDIBLE].
GABE WEISS: A couple do, good.
That's why I want to do this talk,
so we can highlight the fact that we've
got Apps Script going on.
So what see onscreen now is her screen.
And it's showing the metadata configuration page.
So this is where she changed my name
over to that Destroyer of Worlds value.
So I know a lot of you are thinking, like, yeah, and?
She changed a value.
It's happening in real time, and we just built it.
It's going from one front end, through the Cloud,
and updating in a second front end.
The next thing I want to show off is the next tab--
is the ability to configure our devices in some fashion.
And this is where we really see how this is going to go.
So right now on our devices we have a value
called the heartbeat threshold.
So if my heartbeat goes above that threshold,
the LED that's on this device is going to light up.
Right now, it's set to 999.
Because we knew that when the things aren't connected,
they send really high values.
And we didn't want to accidentally go off early.
So now, let's go ahead and set the threshold down
to 120, which both--
I should be able to hit and I shouldn't hit at the moment.
So what I'm going to try and do here
is see if I can get it to trigger and get
this light to go on.
Hang in there.
[MUSIC - ELTON JOHN, "I'M STILL STANDING"]
I am really out of shape!
All right!
So my heart-- I love the music.
[LAUGHS] I love the music choice, guys.
All right.
So now we get to play the game of how
long does it take Gabe's heart rate to go back below 120--
probably a while.
So how this works from Sheets-- we've
got a single cell that, when she enters the threshold into it,
it iterates over all of our devices
and fires off to another Cloud Function.
It's a second called function that Martin wrote.
And all it does is it calls the-- shh-- the IoT Admin SDK
and sends that configuration message back down to all
of our devices to update them.
Yes, I know.
I'm out of shape.
So the App Script is calling HTTP
to call into that second Cloud Function.
So it's not a trigger.
It's actually using that first method
that I talked about with the Cloud Functions.
The last piece that I wanted to show off--
and we'll switch to this, yeah, there we go--
is this is the time slice data I was talking about.
So she is fetching the data from the last 60 seconds or so.
So that big jaggy spike, that's me running around the room
because ouch.
So with Sheets, you get up to two million cells of data,
so what sheets is really good at-- pulling
in large amounts of data.
So the graphing is going to be similar to the Angular,
but I wanted to highlight.
It's the time slice, not the real time that the Angular is.
So that's what we want to highlight
for Sheets is that you're looking at historical data,
not live.
Down below now is-- we've got some conditional formatting.
So any time my heart rate is above the set threshold,
it's being conditionally formatted in that red.
So it's a quick way to get just a quick and dirty look
at your data by doing some analysis in semi-real time
so that you can see what's happening.
So now I would like to go through the Apps Script code,
if Alicia would be so kind.
ALICIA WILLIAMS: Sure.
So I think some of you raised your hands.
But for those of you that don't know,
App Script is a scripting language based on JavaScript
with a bunch of enhancements for G Suite
to be able to automate between different Google products
and services.
So the first line of code I want to show you
is just where I query Firestore.
So I'm using a library that connects
App Script to Firestore.
And I'm querying for a specific device.
I had Gabe's device up there, the most
recent 60 measurements.
So then I'm taking that returned list of measurements,
and I'm appending a new row to the spreadsheet
for each measurement.
And kind of in between there, I wanted
to know what time slice it really represented,
because they are sent about once a second.
But I am pulling the first and last measurement
and just notating that start and stop time.
And then finally, I'm adding some conditional formatting
down here, creating a conditional formatting rule.
So that any BPM value over the current threshold
is made into a background color of red.
GABE WEISS: Awesome.
Thank you, Alicia.
So now we've seen how Apps Script does it,
pulling and showing the data.
Rob, talk to me.
How are we doing on graphs?
ROB WORMALD: Good to go.
GABE WEISS: All right.
So let's switch back over to Rob.
And we will see, look, it's our heart rates, all on screen.
So each of us has our own color.
And now I want to know--
Alicia, go ahead and get hooked up to your device.
So she's in yellow.
That's that squiggly, way up high.
That's the garbage data that I was talking about.
So once she gets properly hooked,
and it's already dipping down.
So what color was I?
I was blue.
I want to be the coolest.
I'm not the coolest.
Wow, Alicia, are you still alive?
[LAUGHTER]
I'm blue.
I get to be the coolest cucumber on stage.
Check that out.
We're all pretty close though.
So the question has been answered.
I get to be--
and I'm out of shape.
I just ran around the room.
What's wrong with you people?
So Rob, now that we've kind of seen it,
let's go into to your code.
And so we've seen Apps Script do the data pulling.
Now I want to show off the Angular
app doing the data pulling.
So go ahead, Rob.
ROB WORMALD: OK.
Switch over to my editor.
So I'm using Angular.
And obviously, I used the Angular CLI to go ahead
and scaffold a project, so it set up
tooling and building and all that stuff that's
really hard about JavaScript.
I started-- the first thing we looked at
was our devices screen.
And that's just a couple of screens.
So I've got a very simple device list
component, a little bit of HTML with some Angular bindings.
We're just iterating over our devices
and rendering some data.
One of the nice things about Angular
is that we have a really, really good relationship
with Firebase.
So we have a really nice built in Firebase Angular
library, Angular Firestore.
And so it takes one line of code to talk to Firestore,
extract that data, and then I get
a real time display of that.
We go a little more in depth into our detailed view.
You can see we're doing the same thing.
We're just using our built in Angular Fire service.
We are just extracting data, getting
some routing parameters, and just streaming
the last measurements off of the device.
So that's kind of basic Angular templating.
That works pretty simply.
For the pulse graph, because that's a lot more complicated,
we're using D-3, which is an awesome graphing
library that's open source.
Again, we're just talking to Firebase,
getting that device data coming out.
I won't bore you with all the math
that we're going on in here.
But basically, we're taking the BPM and the time stamp
and scaling them so they fit in the screen.
And then, just rendering a line across the screen.
So, there you go.
GABE WEISS: Sweet.
Thank you, Rob.
So let's go back to slides.
Yep.
All right.
So to recap, since the keynote went
a little long, so I'm trying to wrap us up so
we get us all back on schedule.
We built an entire app on stage in front of you in 35 minutes.
We went from custom devices--
[INAUDIBLE],, really-- custom devices
up and through IoT Core.
Bridged into Cloud, Cloud Pub/Sub,
Cloud Functions to pull from Pub/Sub into Cloud Firestore.
Firestore firing real time updates
to power our Angular app.
Google Sheets powered by Apps Script
to show us time slice data, configure our devices
with an LED that will not shut off for me.
What else did we do-- and it configured metadata
in Firestore as well.
That is our end to end simple data application
all the way through.
Thank you, team, for making all that happen.
[APPLAUSE]
Thank you for coming.
[MUSIC PLAYING]