Tip:
Highlight text to annotate it
X
MALE SPEAKER: OK.
So let's start again.
So Alex is in this room to talk with us about ***
Simpleauth, the library he has been doing to [INAUDIBLE]
App Engine.
So first, Alex, can you tell me a little
bit more about you.
Who are you?
Where are you based?
What are you working on?
ALEX VAGIN: All right.
So I'm Alex Vagin.
I worked at the University of Trento for several years,
managing internal infrastructure and developing
in-house applications.
And just recently, I left that job to work on my own startup
with a couple of other guys.
And we call it Cloudware.
So the University of Trento--
so this is where I've been living for the past 10 years.
Though I'm not Italian.
I was born in Ukraine.
And I still have Ukrainian citizenship.
MALE SPEAKER: OK.
So you are a Ukrainian based in Italy who works on
[INAUDIBLE]
a startup.
And so when you start using App Engine?
And what are you using App Engine for now?
ALEX VAGIN: So I did have a look at it when you guys just
announced it--
I think it was in 2008.
But at the time, I didn't have really time to start
playing with it.
So I kept watching it.
And I think it was a year after, I started using it for
real, writing some applications.
Well, a couple of applications that are are still running.
One of the applications that I liked it a lot.
It was my last project while I was working at the
University of Trento.
And it was a website for a local event that's was called
[? ICD Days. ?]
And so it wasn't just the website.
It had a few registration forms.
And it also had N RSVP thing for the PhD.
And it also had an admin part, like a little
CMS or whatever system.
And all of those registration data--
they were being synchronized with Google Spreadsheets in
the background.
And the funny thing is all of this stuff up until today,
this website is running on a free app quota.
And it was kind of funny.
Because the day before the event really even started, I
was watching the free instance average
quota going like crazy.
So I did some calculations beforehand, kind of
approximating.
So I was 75% sure it shouldn't be going over quota.
But I did have my mouse button on the Enable Bidding button.
But I just wanted to experiment and see if I could
really manage to run on a free app quota.
And it did.
It went--
I don't know--
98%.
But it stayed there.
MALE SPEAKER: And did you use some tricks in order to
diminish your instantiate usage?
Or did you rely more on caching?
ALEX VAGIN: Yeah, yeah.
So we basically started from scratch.
And at the beginning, I was using NDB and just [INAUDIBLE]
with Data Store directly.
But then as the traffic was increasing, I realized that I
should add some caching and stuff.
And so I did.
And yeah.
It did decrease the instance service.
And what's probably the most piece of instance hours that
was taken away, it was by these background processes
that were calling spreadsheet API's.
Because it's an external API.
So it takes much more time to interact with.
So what I found out is that I moved that
part to the back end.
And that was awesome.
MALE SPEAKER: [INAUDIBLE]
for back end.
ALEX VAGIN: Yeah, exactly.
Exactly.
There was one day I realized, wow, I ought
to have a back end.
So why wouldn't I move it to the back end?
MALE SPEAKER: And I always have a lot of people who are
doing that.
Because that's a really convenient way to scale back
on [? test. ?]
That's just an external [INAUDIBLE].
But you should definitely target all your [? SQ ?] work
if you have the free app to the back end.
ALEX VAGIN: Yeah, yeah, definitely yeah.
And I think I don't know.
I mean, I can only speculate.
But it really felt like when I moved this external API
calling to the back end or you can
different version or whatever--
so the average of the response time or latency--
it was kind of like the maximum and the minimum--
they were reduced, right?
So I think it really helped the scheduler not to launch
the many instances or stay up to the right job.
MALE SPEAKER: It depends on the configuration
of your back end.
But basically the [INAUDIBLE]
for back end is much more simpler since you get to
control the number of instances that are running at
a moment of time.
And so [INAUDIBLE]
schedular to take for scheduling things on back end
is much more simpler.
And plus since it's not [INAUDIBLE]
with user traffic, the scheduler can already predict
what will happen.
Because basically all this back end what will it receive
is internal [? code ?]
from task queues.
And if it's not a [INAUDIBLE]
back end, it's easier for one to do the scheduling.
ALEX VAGIN: Exactly.
Yeah.
That's what it felt like.
When I moved the not user facing requests to the back
end, this is what actually happened.
So the whole response time for users--
it suddenly decreased.
And it was pretty fast.
MALE SPEAKER: When [INAUDIBLE]
test queue what happened is that your test queue traffic
is competing with your user traffic.
And the scheduler will always [? route ?] to privileged user
traffic first.
So when you are on the back end you are not
competing with anyone.
ALEX VAGIN: Right.
Yeah, exactly.
MALE SPEAKER: Your observation was right.
ALEX VAGIN: So yeah.
I was pretty happy about that.
Yeah.
So basically it ran on 24 hours, 3/4, for front end, and
8 hours of back end.
So that was awesome, yeah.
I do have a couple of other business-wise websites.
One is--
it's a website for a local restaurant.
But it's not just static pages.
They offer online orders.
And the owner of the restaurant, I built for them
this admin interface where they can add dishes and stuff
and prices.
They also accept payments with credit cards.
And it's all running on App Engine.
And this app was running--
I think today it's 12 months, one year.
And it was like the best experience I ever had.
Because even in the worst days when App Engine [INAUDIBLE] on
the infrastructure had some maybe bad days or something, I
never had problem with this website.
It was great.
AMY: And your company just launched
something, didn't you?
ALEX VAGIN: Yeah, exactly.
And so the biggest project is yet to come--
so the thing that we launched is the startup.
It's an app.
It's software as a service.
We call it PhD Hub.
So it basically helps--
there's a PhD school.
And there's administrative stuff.
And from my previous experience working at the
University, I found a real need for some kind of
management software or service that would help the secretary
and administrative staff organize all the students,
professors, grades, or whatever.
And the thing is, I started running this app
maybe a year ago.
And at the time, when I started, I didn't have Python
runtime or Java on the infrastructure where I was
running it.
So initially I wrote it in Ruby on Rails.
And then in these few months, I actually started rewriting
it in Python.
So we're slowly moving to App Engine.
But this app, I think it's going to be a huge win for us.
Because right now I still manage this internal service
where this app is running.
This one, we actually offer it for many, many
universities right now.
So we do expect a lot of traffic on it.
MALE SPEAKER: I was going to ask.
ALEX VAGIN: So we'll be moving it on App
Engine for sure, yeah.
It's just not that simple case.
There's many, many lines of code already written.
But I do have already some admin parts
running on App Engine.
And so we're basically calling this Rails app through API,
extending JSON data.
MALE SPEAKER: How would you authenticate the code between
your App Engine app and your regs app?
ALEX VAGIN: Sorry?
MALE SPEAKER: How would you authorize a code between your
regs app and your--?
ALEX VAGIN: Oh, right.
What I did--
but it's kind of secret.
But what it is--
I created a huge token.
I just didn't have time.
I created this huge secret token.
And I basically put this token into a header.
And this is how the Rails app knows that this is kind of an
App Engine app.
And the interface on App Engine--
I started using End Points API.
I just got an invite.
So it's pretty cool.
MALE SPEAKER: But you will be able to make
that more secure now.
ALEX VAGIN: Exactly.
MALE SPEAKER: OK.
So I have a few more questions, if you don't mind.
So I would like to know what is, in your opinion, the
greatest strength of App Engine?
Like as a startup developer, what motivates your decision
to go on App Engine or to go somewhere else?
And if you have any suggestions about how we
should improve the App Engine developer experience or more
specific to request.
ALEX VAGIN: Well for that I have a list.
MALE SPEAKER: OK.
ALEX VAGIN: No, just kidding.
Well besides that, it really auto-scales.
I think it was at the beginning was the first thing
that I kind of noticed that stood out
of all of the features.
And what I also like is that there are so many services
around this platform, the user services, whatever, a lot of
pipelining, a lot of frameworks or
libraries around that.
So you basically can do whatever you want.
But I remember back in 2009 or 8, what really impressed me is
when I started reading docs about App Engine.
And I eventually got to this task queue and [INAUDIBLE]
jobs.
And what I saw there is when you actually create this task
queue or cron jobs it call your URL.
And before that--
so basically before the App Engine, what I was doing
usually is that I would have a cron jobs on Linux server.
Or I could have ready server.
And I could have background processes.
But still, they would execute.
I would still need to launch some of these background
process instances.
And when I saw this, and I was like, whoa.
So everything could be a URL.
So you can call you application,
even for cron jobs.
That was awesome.
I really liked that.
I was interested.
MALE SPEAKER: Yeah.
So model of App Engine is really
based on URL and requests.
And those can be a very short request for front end or much
more request for test queue on back end.
But I also like that the [INAUDIBLE] is web based and
more HTTP based.
In the sense that everything in App
Engine is an HTTP request.
And sometimes I think it was difficult for people coming
from, for example, an RGS background to easily
translate to that.
Because first, it's much more like they have a process that
is spreading.
And these process has dedicated memory.
And it's processing a lot of requests.
But they don't think about everything as an HTTP request.
They don't think about chunking that processing into
an HTTP request.
I think that's a big difference.
And that's one of the challenges of adoption for App
Engine as well.
People are used to resident process and resident memory.
And they come to App Engine.
And then their quota systems [? start ?] and stop.
ALEX VAGIN: Yeah.
Right.
Right.
But when I realized this, it simplified things so much.
I was so happy that I could--
MALE SPEAKER: It's a really easy model to put
your head around it.
ALEX VAGIN: Yeah.
MALE SPEAKER: Like [INAUDIBLE].
AMY: Yeah.
When I first learned App Engine, task queues were my
favorite thing too.
It's so powerful, yeah.
MALE SPEAKER: [INAUDIBLE]
is there any project that you are not
choosing App Engine for?
Is there [INAUDIBLE]
you [INAUDIBLE] and you say, OK.
I can't do that on App Engine.
I will just use a dedicated server?
ALEX VAGIN: Yeah.
Well from my experience, today, off the top of my head,
there is one thing that I still can't
figure out how to do.
So it actually started when I got my laptop broken.
And I had a couple of last days' work on it.
And I couldn't get to it.
And I was thinking, well, couldn't I just all do it on
the web, just programming?
So you have Chromebooks, right?
So you have Google Docs, right?
Whatever happens to your hardware, it doesn't matter.
So I was thinking, well, wouldn't it be great.
So what it is, I created this just simple app where I could
edit the code with a browser.
I think I used CodeMirror library.
But the thing that I wanted--
because I would be missing that a lot--
is I also need to run tests.
And I also need to run development depth server on my
localhost or whatever it is.
So for that, I think I've made some--
I don't know.
I think Compute Engine would be right for this thing.
MALE SPEAKER: You can just use [INAUDIBLE].
ALEX VAGIN: Oh yeah.
MALE SPEAKER: Like if you had paging app, where you have
your [INAUDIBLE]
that is sending some Python code into some data store
[? entities ?]
and executing on the fly, this is the kind of setup that you
have to have some kind of online [INAUDIBLE]
experience.
You can have a special version for editing and then just more
stuff to a different version once you want to [INAUDIBLE].
ALEX VAGIN: Right, right.
Yeah.
That's my point.
Yeah.
MALE SPEAKER: But that's only possible for Python, though.
Because [INAUDIBLE]
conduit for [INAUDIBLE] or Java.
But there is someone on the development team that has made
an experiment where he has been able to run App [? CAG ?]
on App Engine.
ALEX VAGIN: Cool.
Oh, wow.
MALE SPEAKER: Which is [INAUDIBLE].
So it's Daniel on the [INAUDIBLE] team who has
manged to deploy an App Engine app from App Engine.
ALEX VAGIN: Whoa, whoa.
Yeah.
That's awesome.
Yeah.
MALE SPEAKER: It's very, very nice.
And another way to do it is that you could also
[INAUDIBLE]
Google Drive for that.
So you could have your App Engine app.
Instead of providing an [INAUDIBLE]
that is inside the app, you could have the app fetch a
file on Google Drive and execute it.
AMY: I just pasted into this chat window.
There's an interesting blog post that just came out that
this lets you run tests and then deploy from, say, your
github repo.
MALE SPEAKER: And there is also an online meter called
Code [INAUDIBLE] that allows you to deploy to App Engine on
their platform and from there.
I think you're right.
There is not only one solution for doing this.
And there is a lot of different approach and
different acts that try to achieve the same thing.
But hopefully, I hope that they will converge [INAUDIBLE]
into the more [INAUDIBLE]
solutions, so people could just [INAUDIBLE] in the cloud
instead of--
ALEX VAGIN: Yeah, exactly.
Yeah.
That would be awesome.
Yeah.
MALE SPEAKER: And do you have any other suggestions for
improving App Engine [INAUDIBLE] experience, or a
more specific future request, your [INAUDIBLE]
your [INAUDIBLE] list?
AMY: What are the things that are painful?
We want to hear them.
ALEX VAGIN: No.
I knew you'd ask me this.
So I prepared beforehand.
What I want to say, first off, is recently you guys are doing
an awesome job at supporting folks even on the forum.
I see replies flying all the time, like almost to any post
on the forum.
I think it was one of the missing things,
like to just support.
But really, yeah.
It's great.
Well, about the features, the one thing that I remember is
at some point there was a monitoring API for apps
running on App Engine.
And I think it kind of stuck at some point.
And I know you guys are probably working on some
improvements to that.
And well, there's just this thing.
MALE SPEAKER: Yeah.
I think that Amy knows more about this.
Because she's based in Sydney, where the original team was
working on it.
I think that they have got some feedback from the
[INAUDIBLE].
And they have got a lot of feedback.
And they are trying to move the project in a different
direction based on this feedback.
But maybe Amy has more insight.
AMY: No.
That's a good summary of it.
ALEX VAGIN: And then this is actually, I've been
thinking a lot about.
This is actually kind of related to the simple
authentication.
It's about the users API.
So right now, users API-- they support four things.
You guys support Google accounts, right?
So it's, I think, Google accounts.
Or I could also do OpenID authentication.
But the thing is, I'm not even sure if it's a good idea.
But like the way OpenID works--
so I could authenticate any user with the
external OpenID provider.
I think it would be nice to be able to do the same thing, but
not only using OpenID but OAuth2 or any other kind of
authentication.
MALE SPEAKER: Yeah.
I totally agree with that.
And so there is something really frustrating when you
are using OAuth on App Engine right now is that if you want
to have user SO authentication and authorization with OAuth2
at the same times, basically, you have to [INAUDIBLE].
So when the [INAUDIBLE] login serves the App Engine requires
permission using Google authorization, a mechanism to
share his email address with the
applications, that's one screen.
And then, when you want to get permission for Google Drive or
Spreadsheet API or Google [INAUDIBLE]
API, [INAUDIBLE]
run screen for this permission.
And currently, the only way mix the two is to ditch the
standard authentication from App Engine, and instead rely
on the user scope like you do in Simpleauth in order to
authenticate the user.
And so then you can finally request [INAUDIBLE].
You can say I want the email address using the user
[INAUDIBLE].
And I also want to be able to read his Drive [INAUDIBLE].
And I would really like if there was a building way with
the user API to do basically what you are doing now for
authentication using the user API, but using the auth scope
user info and plus request an additional set of scopes.
So you can reduce the ground screen to only one.
ALEX VAGIN: Yeah, exactly.
Yeah.
Exactly that, yeah.
MALE SPEAKER: But I think you did a very good job with
Simpleauth.
We can talk more about it later on that kind of provide
the same solution with the user [? end ?].
But it's a good inspiration for the team to be able to
[? transfer ?]
that and offer that as an active API.
ALEX VAGIN: Yeah, yeah.
Great, yeah.
MALE SPEAKER: Yeah.
So I would like to continue with more questions.
I think we still have some time.
So I would like to know more about what your day to day App
Engine development looks like, like what
editor you are using.
Are you using an ID?
Which language do you target--
Python, Java, [INAUDIBLE]?
And if you have a favorite App Engine framework library or
[? tool? ?]
ALEX VAGIN: So actually I like experimenting
with different IDs.
So I tried like a couple of dozen of them.
But I used to use TextMate all the time.
But then recently, I switched to Sublime Text.
AMY: Me too.
ALEX VAGIN: But like I said before, the best thing would
be if I had some web ID where I could do all the same things
that I do on my [? common ?] line terminal and Sublime.
But today I'm using Sublime Text.
So I'm mostly using Python.
And I do experiment a lot with Go these days.
And I was just reading recent updates on Gorilla Web.
I think probably you were working on that
with Rodrigo maybe.
MALE SPEAKER: I know of just one thing.
But [INAUDIBLE]
to Go library was Go Auth2.
So you might be interested by it too.
ALEX VAGIN: Yeah, yeah.
MALE SPEAKER: But [INAUDIBLE]
Go Auth2--
I mean it's a nice library, does the job.
But I think that there is some room from improvement to make
it work better with App Engine.
Especially, there is not a good story yet for selling a
token to the [INAUDIBLE] store.
You can go it by hand, but it would be nice if there was an
integrated way to save tokens [INAUDIBLE]
always goes to.
ALEX VAGIN: Right, right, right.
MALE SPEAKER: [INAUDIBLE] what [? Rodriguez ?]
has done with Gorilla.
And it's very nice.
I really like the [INAUDIBLE]
architecture, in the sense that you can [? attack ?] any
part of it within the dragging the [INAUDIBLE] thing.
So I like the component approach that shows instead of
a big full stack framework.
He has this set of components that you can use.
He's been also very active on making the templates Go
support and [INAUDIBLE].
Because that's something that's it's
really attached to.
And the story from Go templates--
you can code [INAUDIBLE]
templates from other templates.
And you can [INAUDIBLE] a composition.
But you still have to wire all the templates together in your
code and that's something that we're [INAUDIBLE]
in [INAUDIBLE].
So he is actively working on this too.
ALEX VAGIN: Right.
Cool.
Yeah, that's awesome.
MALE SPEAKER: I like the Go runtime a lot.
I don't know if you've compared the
performance with Python.
But it's really interesting.
And also what I think about the Go runtime is that it
gives you basically the same interaction process that you
have when you are developing Python, but just safer with
type and compiling Go.
What I like is that usually when my Go app is compiling, I
know that it will work.
Whereas when I develop some Python app, I still have to go
into each [INAUDIBLE]
code path to just know that I did not make a syntax error.
ALEX VAGIN: Right, right, right.
I was impressed when--
Oh, sorry.
Amy?
AMY: Oh no.
I was just going to say we were thinking of having some
more Hangouts featuring Go.
So it sounds like you would be in favor of that.
ALEX VAGIN: Yeah.
Yeah, definitely.
Yeah, yeah.
AMY: Sorry.
Go ahead.
ALEX VAGIN: Yeah.
I was impressed when I did try Real Web and Go itself.
What I was impressed with-- the first thing, I wrote
Simple app.
And I launched in.
And it was super fast.
And it was like whoa.
MALE SPEAKER: Yeah.
I like the fact that Go, with just using the storage QP
package, if you are not using any of the Google App Engine
API, your Go app is still a standard web app.
And you can run it wherever you want and just compile
using the [INAUDIBLE]
package.
Because they are controlling the language and the platform,
I like that they are really able to get the two together.
ALEX VAGIN: Yeah, yeah.
Right.
Yeah, yeah.
MALE SPEAKER: And do you have any favorite?
I mean, you were mentioning Python before.
Do you have any favorite App Engine framework for Python,
any libraries that you always use in every app?
ALEX VAGIN: Oh, yeah.
Well, the first thing that I just love is this NDBD--
the new DB interface.
So I like it.
Especially what I like is the asynchronous API.
And this task list-- this is great.
And also Appstats is a tool that I couldn't live without.
Appstats is something that helps me every day.
And then what I also like is also EReporter.
It's a package that whenever you have some errors, it can
make your app email you these exceptions.
So let's say you are running a production application.
Instead of maybe monitoring the log files, you can also
set it up so that you would get notifications by email
when something goes wrong.
So I like that.
And then Back Loader actually helped me.
I logged in.
Pushing some legacy data into data store.
MALE SPEAKER: I think that the exporting and importing data
story is getting better and better, especially since we
introduced backups to Google storage and restore.
Not a lot of people knows this.
But if you go to the Google App Engine project on
code.google.com, and you just look at the SDK sources, the
sources for the backup and restore administration
[INAUDIBLE]
is actually there.
So you can actually look how this feature works.
And you can easily modify it to support importing stuff
from test or that doesn't come from backup, or writing NTGs
that come from your app and export them to Google store
and [INAUDIBLE].
But I that the framework into there is a solid base where
people can give their own important
exporting mechanism on.
It's not well known that it's open source in the SDK code.
ALEX VAGIN: Yeah.
It's a great addition.
Yeah, definitely.
MALE SPEAKER: You mentioned the Pipeline API before?
ALEX VAGIN: Yeah.
I forgot.
Yeah.
That's another thing.
I think I put it on my favorites list, yeah.
I used it a couple times, yeah.
Even if you had terabytes of data, what I like about it is
that way, using Pipeline API, you can process a huge amount
of data, and just not worry about it later on.
MALE SPEAKER: Yeah.
So you mentioned both NBD and Pipeline.
And there is something special about those two libraries,
that they are not developed inside the SDK lab.
They have their own project on code.google.com.
They have [INAUDIBLE] their online list.
They have their own [INAUDIBLE] trackers.
And they get syncing to the SDK on each release.
But I was wondering what you prefer as a developer.
Like do you prefer that they are structured as an
independent project?
Or do you prefer that everything gets tracked into
the same App Engine product?
ALEX VAGIN: I don't know.
I like the way the NDB--
the fact that it has its own Google group, forum, where I
think it's because there could be a lot of
questions related to that.
So I think that way people can track or ask
kind of specific questions.
And I don't really mind to do import from
GoogleAppEngine.ext import NDB instead of--
so I like the way it is right now.
But I like the fact that [INAUDIBLE]
back actions SDK.
But I also like the fact that they have their own community.
And I think it's important for the community to build and
[INAUDIBLE]
around [INAUDIBLE].
I wish we were doing the same, for example, for [INAUDIBLE]
backup and restore thing, like if it was the right project,
we could get contributions more easily.
It will raise knowledge that this is there and
people can use it.
Even though it's [INAUDIBLE] inside the SDK.
But I think that it will deserve more visibility.
ALEX VAGIN: Yeah, exactly.
And then plus there might be some time when you could even
use those external projects in some non-App
Engine related thing.
You could just take that call, then communicate your needs
and just use it.
So, yeah.
MALE SPEAKER: I think there is only maybe 15 minutes left.
So I will try to ask my question.
There's a last question for you.
AMY: Do you think we should just switch to demoing?
MALE SPEAKER: Yeah.
I think that we just have one last section
before we get his demo.
And I think that we are fine.
Like do you have any tips?
You mentioned test queue.
You mentioned using the background.
You mentioned at the [INAUDIBLE]
you mentioned caching.
Do you have any user tips that you would like to share with
an App Engine developer?
ALEX VAGIN: Sure, yes.
One thing is testing.
There is nice test bed framework.
And I would have had to write so much code to support my
testing environment.
So this has really helped me out.
And the second thing is code reviews.
If you are working on some open source project, I think
it's codereview.appspot.com.
I think it's awesome to get feedback from other
developers.
And actually when I was in there, I was working on the
Simple app, there was this guy, Eric Higgins.
I don't know if you guys know him.
I think he's ex-Google maybe.
So I posted the link to Go code review.
And I just said whoever feels like code reviewing.
And suddenly I got it reviewed this guy.
And it was awesome.
He gave me so much.
Like different people see things from different
perspectives.
So it really helps in development.
MALE SPEAKER: The Go project is using code review
intensively for the development of Go.
They have [INAUDIBLE]
called [? golden ?] dev, where you can see all of the
contributions [INAUDIBLE].
And maybe that's something we missed for App Engine.
Maybe we should have [INAUDIBLE]
mailing list, where all the community projects that are
also third party libraries that are using App Engine and
building stuff staff can submit code review.
So you can just watch it and interact with people who are
developing App Engine apps.
ALEX VAGIN: Yeah.
That would be great.
Yeah, yeah.
AMY: Incidentally, big props to ***, who is involved with
code review and app stats as well as NDBs.
ALEX VAGIN: Right.
AMY: [INAUDIBLE].
ALEX VAGIN: Yeah, yeah, yeah.
And this one last thing that I want to maybe emphasize is
I've seen a lot of blog reports on App
Engine issue tracker.
And what I found out myself too--
because I've been on the other side--
when you file a bug report, before submitting it, try to
put yourself on the other side of the guy who is going to
handle this bug report.
And try to read what you just wrote.
And try to figure out whether the guy that's on the other
side will actually understand what's going on.
Even better, if you could submit a
patch, how to fix your--
because I've been there.
And I know a lot of bug reports, when you get this
saying, it's not working.
And you just don't know what to do with it.
MALE SPEAKER: I've been doing a lot of work on the issue
tracker [INAUDIBLE]
[INAUDIBLE] who try to reuse a [INAUDIBLE] of issues that we
have to triage.
There are some things that if you can submit the test that
is reproducing the failure that you are reporting, that's
a [INAUDIBLE] platform.
Because something that is really difficult to evaluate
is how much time it will take for you to
reproduce the issue.
And a test is basically the reporter transferring to the
one who is going to triage [INAUDIBLE]
the knowledge of what you need to do in order
to reproduce it.
I think it's very [INAUDIBLE].
And we should have a better story for people crashing
tests that are using test bed [INAUDIBLE]
or that are [INAUDIBLE]
SDK in order to reproduce a given bug.
But that's something that is very valuable to an engineer,
when they have a simpler way to reproduce a problem.
And you write about the issue tracker, that people should
really to try to do better submission.
But that's something also that is on your plate as well.
We should try to improve and to give more incentive to
people to do better submissions.
Like for example, the submission templates--
I am in the process of refactoring them.
So it will better spell out what you need to do in order
to submit an issue.
Because is it not always clear to people that they first have
to describe the step to reproduce the issues.
They have to describe what they are expecting and to
describe what they are seeing still.
And just listing that in the template would, in my opinion,
raise the clarity of the issues that we get reported.
ALEX VAGIN: Yeah, right.
Cool.
Cool.
MALE SPEAKER: I heard that you maintain a library which is
called Simpleauth.
So maybe you can talk a bit about it.
And maybe you have a small demo of how to use it.
ALEX VAGIN: Sure, yeah.
So you know what?
I'm going to just do a little quick demo.
And I'm going to do a screen sharing.
Oh, wait.
I'm going to share my desktop.
So do you guys see my screen?
Cool.
Yeah.
So yeah.
You can find the link to this project on the Hangout
description, I think.
Well first off, just one minute, where we all started.
So there was this website where the [INAUDIBLE].
And what I needed to do is we went to invite these PhD
school alumni.
We wanted them to RSVP if they're coming or not.
The thing is, they are spread all over the world.
So we didn't even know whether they were using some social
networks like Google+ or LinkedIn or whatever.
So what I thought is I would just put these three buttons.
And whenever a guy coming in.
And they can just confirm it with their preferred account.
So this is where it all started.
And I just took this piece of code.
And I put it into the Simpleauth.
So how I can get started is you can go to the source
through the check out base.
And you can copy the link.
And then you call it.
Make it a bigger screen.
So you call it.
I'm opening my header.
And so you have this example application.
This is secrets.pi.template.
So what I'm going to do is I'm going to copy the content of
this file in another one that I just called secrets.pi.
So it's the same file only without
top template extension.
And in here I have client keys and the consumer key and
secrets for different providers.
So I'm going to go and start with Google APIs.
You'll find links to where to get a client secrets on the
home page of the project.
Here is one for Google APIs.
So I'm going to go here.
And this is Google API's console.
And I'm just going to create a project.
And it's called hangoutdemo.
AMY: And you might make your browser font
just a little bigger.
ALEX VAGIN: Sorry.
OK.
So there is nothing I need to enable here.
What I'm going to do is I'm going to create an auth client
that's called demo.
Here I need to choose a web application.
And what I'm going to do is--
well.
Let's say localhost.
Because I'm running on a localhost.
Note the redirect URL.
We'll need to change it just here in a second.
So here we go.
I get the client ID.
And I get client secret.
What I need to do, though, is change this
redirect URL or callback.
I can either change this or I could even add another one to
Google callback.
This URL--
If you go through the Getting Started page, you'll see why
it is and how it is formed like this.
So let me change this at Google callback.
So I'm just going to copy client ID and client secret.
And I think it's started.
So I'm going to go in on this example.
And I'm just going to run it.
Try to see if this works.
I'm going to go to my localhost.
So this is actually exactly the same application as you
would see on the simpleauth.appspot.com.
And since I only put real client ID and secrets on
Google API, so I'm just going to go ahead
and try and log in.
And there we go.
Now it's requesting permission.
This is what we probably talked about before.
This comes from the scope parameter that we
talked about before.
I'm going to go ahead and allow access.
And there you go.
We have a number of data here.
So this is data and auth info.
This is what you get inside this method.
And so what I do is I'll just print it out on the page here.
And you can see this is coming from Google+.
Well, actually Google OAuth API.
So you have some user profile data.
This is OAuth 2.0.
Access token is what you'd need to interact with Google
APIs in this case.
And you have this expiration date.
And this actually is the result of interacting with
Google API using just the access token.
And just for the demo, I'm printing out here since the
Simpleauth uses whatever Web App has already implemented.
So it uses Web App's session and auth package.
So you already have the session thing already
implemented for you.
So I don't think we have too much time.
MALE SPEAKER: That was a very nice demo.
For the [INAUDIBLE] coding and getting everything more clean
at the first time.
ALEX VAGIN: Yeah.
And you can basically do the same thing for Facebook,
Twitter, and any other OAuth 2.2 or
OAuth 1 or OpenID providers.
You can do the same thing.
MALE SPEAKER: And are you persisting user creation using
a Web App 2 session mechanism?
ALEX VAGIN: Yeah.
MALE SPEAKER: And then it's up to the user if you want to
persist the user in the database to do it from the
call back, right?
ALEX VAGIN: Yeah, exactly.
Yeah.
So the Simpleauth actually--
it's not the real handler.
It's just kind of mixed in that you can add to your real
[INAUDIBLE]
handler.
And what's happening outside of auth request and response
is up to the developer.
So he can use a different session back end.
So you can use any user model that you want.
Like the example application uses what's
default of Web App 2.
But you can use whatever you want.
MALE SPEAKER: So I think that's it for the demo.
So thanks a lot, Alex, for answering our questions and
going for Simpleauth.
Is there anything you want to add, Amy?
Or any question from [INAUDIBLE].
I don't know if we have the time.
AMY: Just for those who might have tuned in part way
through, look at the event description for a link to the
repository for this code.
It's really very nice.
ALEX VAGIN: Thanks, guys.
MALE SPEAKER: Well, thank you, Alex.
AMY: Thank you very much for joining us.
MALE SPEAKER: Bye.
ALEX VAGIN: Thank you.
I want to say I hope I'll see more Hangouts for the Go
runtime and stuff like that.
AMY: Oh, good.
I'm glad.
And we'll try to do more that are convenient for the
Europeans too than we have been in past.
ALEX VAGIN: Cool.
Cool.
Thanks.
AMY: Thank you.
Thanks so much for joining us.
ALEX VAGIN: All right.
Bye.
AMY: Bye-bye.