[MUSIC PLAYING]
YISHAI LEVENGLICK: Hi everybody, I am Yishai.
I am an Android developer at Glide.
ROI GINAT: And I'm Roi, his CTO.
And I'm thrilled to be here, at Firebase,
talk about our experience with Firebase, how it helps us,
some of the things that Steve just talked about,
how we use them, and how it affects our life as a company.
So we're going to talk briefly about quality.
And all of you who have experience
with QA engineers, labs.
You probably have a few devices.
Maybe you're using cloud, the cloud service.
We have hundreds of devices in labs.
But we'll learn something that most of you know.
It doesn't matter how much testing you
do internally, how much testing you
do with some crowd testing or beta groups.
You will never be able to get to this specific device,
specific network condition, and that specific use case
that one device and one user had,
which is just one out of million.s
Before we dig any farther, I'll just briefly introduce Glide.
Glide is a messaging platform.
And our goal is to create a platform
for authentic communication between human beings.
We believe that a smile is much better than a smiley.
And for that, the best way, we believe,
is asynchronous, live video communication.
We're available on multiple platforms,
and we're very excited about the wrist worn new platforms,
or relatively new.
It's the right place to actually communicate, more accessible.
We were working with Google Wear team for quite a while.
And already now you can download Glide and use it
on your Wear device, and you'll be
able to see live video of your colleagues, friends,
and families, and be able to respond
with live audio, or text.
Obviously we're missing just one thing, which is a camera.
And I'm happy to say that last Wednesday, Glide
has announced to the world CMRA, camera, which is basically
adding the camera functionality to the wearable device,
initially for the Apple Watch-- two HD
cameras, one front facing, one outward facing,
that allows you to quickly communicate with your friends.
By the way, it's going to be open.
So any developer will be able to use the camera for its own app.
So we talked about quality.
And obviously we want to find out things sooner than later.
We're going to share that, in our case, it's not always true.
YISHAI LEVENGLICK: Well, one of the first things
the application does upon connection to the server
is sync all the relevant and new information
in order to display it to the user as fast as possible.
So part of that is receiving chat IDs of chats
that I am part of, and then requesting relevant information
about them.
Among them is the last messages.
Now what happens if an application requests
information about a chat that it's not part of?
Well thankfully for that, we have security measures.
And those security measures will return a negative answer
to the user, to the application, saying you cannot have this
information.
You're not part of this chat.
So a few years back, we had not many, just a few devices,
that, as a mistake, got chat IDs of chats
that they were not part of.
So they requested information, and requested
the last few messages from those chats,
and received an answer that was no.
Unfortunately those clients did not have no as an answer,
and kept on requesting again and again and again,
as fast as they could.
Every time a negative answer came back,
a new request came in.
As a result from that, our servers crashed,
and a few alarms were raised.
ROI GINAT: Yeah, that was probably one of those days
that we were trying to fix the server to make them not crash
and those repeated events, hack around it.
At the same time, try to locate the problem on the client side
and fix it.
That image is very reflective of that day.
YISHAI LEVENGLICK: Anyway, that is not the only problem when
maintaining a big application.
ROI GINAT: I think it's obvious that the sooner you find
a problem, the better it is.
And our purpose in life is to make user experience best.
And we face challenges in finding those problems soon.
YISHAI LEVENGLICK: As we all know,
Android has some OSes that our live at the same time.
If you support multiple platforms,
you will have a few application files live at the same time.
If you support multiple platforms,
you will have that on different stores simultaneously.
And if you have different hardwares,
if you deal with video streaming, which is what we do,
then you have also vendor issues.
Now the problem is that once you have so much information,
it becomes a bit hard to understand and analyze that.
You have a large array of analytics platforms and crash
logging platforms.
And it takes time and resources and people
to gather all this information into one place,
and then analyze it.
And if a bug happens, you need to understand
what the impact is on the end user,
if it's destroying your current app, or is it
the bug that you're currently fixing?
And that is something that you have
to know as fast as possible.
We encountered a lot of issues because there
was a lot of data, and a lot of places,
and we didn't have enough time to analyze it.
And this is basically where Firebase comes in.
As you can see here, we have filtered
by an application version.
As we're releasing it, we have all the relevant information
about the health status of the current release.
And we know how many users are using it.
So if we actually find a crash, which occasionally happens,
we can actually know if it's a bad one or if it's OK,
and generally try and fix it as fast as possible.
But we prioritize according to the impact on the end user.
ROI GINAT: So what you can see here
is how Firebase actually affected our rollout release.
Typically we start with low percentages
and try to understand what's the impact on users, what kind
of issues they face, and as Yishai said,
are those critical, et cetera, et cetera.
On an average release, Firebase Analytics,
that you've seen Steve used, have reduced our rollout
from beta testing to 100% from approximately 10 days
to seven days.
But it's even way stronger when we're
using that for patch release.
When we have something that is a fire
or close to a fire, something that we
want to release quickly, we're able to typically release
in a very safe way within 48 hours.
That slow release is typically affected also by the fact
that we live in a different time zone than most of our users.
And that's probably common for many of you here.
Most of our users are in the States.
That means that when you want to test things and see the events,
if we don't wait for the late night hours,
it's going to take a day for a cycle.
YISHAI LEVENGLICK: Integrating Firebase has been very easy,
literally three lines of code.
We add it into our configuration files.
And this I think is not even needed anymore
because it happens automatically.
We tell Firebase Crash Reporting we had a crash.
Again, I think this already happens automatically now.
So basically it's two lines of code.
We got everything back.
We sped up all of our release cycles.
And life is much, much better now.
Thank you very much.
[APPLAUSE]
[MUSIC PLAYING]