►
Description
Presented by Jason Etcovitch, Learning Engineer (GitHub).
We share how we built Learning Lab using public GitHub APIs and Probot, a framework for building GitHub Apps. We’ll also share implementation details for reusable API abstractions - using these actions, you can build your own courses on Learning Lab to teach developers how you work, what your product or integration does, or something completely new.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Hello,
everybody
how's
it
going
fantastic
super
energy,
I
love
it
yeah.
This
is
so
much
better
than
it
was
two
seconds
ago.
Awesome
cool,
hi,
everybody
all
right,
all
right:
okay,
hello,
my
name
is
Jason.
I
am
an
engineer
here
at
github
I'm,
also
a
maintainer
of
Probot,
which
I'm
going
to
talk
about
a
little
bit
later.
It's
an
open
source
library,
I
am
super
super
excited
to
be
here.
A
I've
been
at
github
for
just
over
a
year
now,
first
as
an
intern,
then
as
a
full-time,
employee
and
I've
had
one
major
project
throughout
my
year
here,
collecting
stickers,
I'm
just
kidding.
So
it's
a
really
big
day.
Today
we
got
a
lot
of
shiny
new
stuff
to
talk
about
and
I'm
happy
to
share
with
you
something
that
we
haven't
talked
about
a
lot
before,
which
is
github
Learning
Lab.
A
So
you
heard
about
it
in
the
keynote
this
morning,
it's
in
the
title
of
the
session,
but
to
make
sure
that
you're
all
in
the
right
place
we're
talking
about
github
learning
lab
it's
a
project
that
I've
worked
on
for
about
eight
months
and
last
year
at
github.
Universe
is
when
actually
somebody
shared
the
idea
with
me
the
first
time
they
said:
what
can
we
do
to
change
the
way
that
people
learn
on
github
so
for
context?
A
We
have
a
stellar
professional
services,
training
team
that
go
to
companies,
they
go
to
organizations
and
they
help
them
change
their
workflows,
improve
their
workflows
and
they're
super
successful
in
that
the
problem
is
our
trainers,
can't
teach
30,000
developers
at
a
time
and
they
can't
be
everywhere
in
the
world.
It
just
isn't
scalable.
So
we
came
up
with
the
idea
to
provide
something
interactive
scalable
on
github.
A
The
first
programming
book
that
I
ever
picked
up
is
called
HTML
and
CSS
by
John
Duquette
great
book,
I
see
a
class,
that's
awesome
and
the
reason
it
was
so
successful
for
me
was
that
I
had
it
propped
up
in
front
of
me
and
I
was
reading
through
it
and
I
had
a
you
know,
a
computer
screen
just
above
it.
So
you
know
having
those
two
right
side-by-side
was
super
super
helpful.
A
So
for
those
who
haven't
seen
it,
Learning
Lab
is
an
interactive
learning
experience
that
takes
place
entirely
in
a
github
repository.
It
uses
github,
public,
api's
and
web
hooks
to
listen
for
activity
in
those
repositories
and
attracts
user
progress
to
help
them
learn.
So
students
register
for
a
course
and
learning
lab
creates
a
repository
for
them.
Getting
them
started
on
a
new
project.
A
A
It
uses
an
event-driven
API
to
simplify
the
web,
the
web
hook
handler
mentality
and
abstract
all
of
the
authentication
boilerplate
that
you
shouldn't
ever
have
to
deal
with,
and
it
was
designed
to
basically
help
you
write
software
and
help
you
customize
your
github
workflows.
So
here's
an
example
of
a
really
basic
Probot
app
we're
gonna
look
through
this
in
a
second.
A
So
this
entire
code
block
means
when
a
new
issue
is
opened,
go
ahead
and
respond
to
that
issue
create
a
comment
on
it
that
says
hello,
universe,
so
issues,
dot
open
means,
listen
for
a
new
issue.
Context
includes
all
of
the
information
about
the
issue
that
was
just
open.
So
you
know
the
issue
itself
who
opened
it
the
repository
we
came
from
all
that
kind
of
good
stuff
and
then
context.
Github
is
an
octocat
client,
a
Hubb
API
SDK
lots
of
acronyms.
A
That's
authenticated
for
the
specific
repository
that
this
event
came
from.
So
in
the
case
of
Learning
Lab,
this
gave
us
the
Y
or
sorry.
This
gave
us
the
how
and
we
already
had
the
Y
we
wanted
to
help
people
learn
so
aside
from
being
a
maintainer
of
Probot
itself.
At
this
point,
I
had
built
enough
bad
Probot
apps
to
say:
okay,
it's
time
for
something
non-standard
and
kind
of
funky.
A
So
before
we
began
to
build
Learning
Lab
in
earnest,
we
built
a
sort
of
alpha
version
and
it
was
one
course
had
few
bells
and
whistles
and
was
designed
to
be
tightly
scoped
and
at
the
time
we
didn't
really
consider
what
it
meant
to
parse
a
webhook
event.
We
ended
up
with
a
number
of
event,
handlers
that
tried
to
do
the
same
thing.
A
What
we
ended
up
doing
was
using
github
as
sort
of
a
store
for
information,
so
here
you'll
see
that
when
we
run
a
handler
for
a
new
issue,
we
check
to
see
the
state
of
the
repository
we
check
to
see
if
the
first
issue
in
that
repository
is
closed,
and
if
it
is
that
sort
of
gives
us
a
sense
of
where
we
are
in
the
course
now.
This
turned
out
to
be
really
brittle.
A
If
you
were
off
by
one,
if
you
opened
an
issue
by
mistake
right
that
creates
an
off
by
one
issue
number
and
everything
was
borked,
it
was
horrible,
so
I
had
discovered
a
turning
point
in
the
project
to
be,
and
I
was
excited.
So
looking
back,
this
seems
really
obvious.
But
when
we
were
steeped
in
the
logic
and
the
content
of
the
courses,
it
was
difficult
to
think
about
what
was
going
on
from
a
higher
level.
A
So
we
devised
a
system
to
abstract
the
concept
of
progress,
because
it
was
so
important
that
no
one
should
ever
have
to
think
about
it
again.
So
slight
tangent,
because
this
is
super
important
I'm-
going
to
interject
this
train
of
thought
with
a
note,
if
it's
important,
do
it
right
once
and
then
forget
about
it.
If
you
can
modularize
some
core
component
of
your
applications
design,
you
can
do
it
right.
One
time
you
can
just
keep
reusing
it
and
making
it.
You
know
build
everything
on
top
of
that
you'll.
Thank
your
past
self.
A
Like
I
do
so.
This
system
works
in
two
parts.
Courses
have
metadata
and
courses
have
logic,
so
the
metadata
is
defined
in
a
llamó
file
like
you
can
see
on
the
left,
I
think
and
the
logic
is
expressed
through
some
JavaScript
here
on
the
right
and
you
may
be
noticing
some
related
bits,
so
we're
gonna
dig
in
to
see.
What's
what?
So,
by
far
the
most
successful
part
of
this
API
was
the
abstraction
of
a
step.
So
you
can
see
here
that
we're
defining
a
step
in
the
animal
you
see.
A
The
title
of
the
step
is
my
step
very
creative.
We
then
call
course
dot
on
to
register
an
event
handler
basically
saying
when
the
user
is
on
this
step
in
the
course
and
triggers
the
appropriate
event
right
might
be.
Opening
an
issue
might
be
merging
a
pull
request,
whatever
it
is,
go
ahead
and
run
this
code
and
the
course
object
is
basically
an
event
emitter.
So
if
you're
familiar
with
nodejs
is
event
emitter
API,
it's
virtually
the
same
thing.
A
We
load
up
each
courses
javascript
file
when
the
app
starts
up
and
we
registered
those
event
handlers.
So
this
was
the
result
of
doing
something
important
once
and
then
abstract
it.
Now,
let's
look
at
what
this
course
dot
on
function
looks
like
under
the
hood,
so
it
looks
like
a
lot.
We're
gonna
dig
in
and
actually
look
through
it
all.
So
first
we
identify
the
step
that
the
little
name
thing
comes
from.
This
is
important
because
it'll
contain
all
of
the
information
about
the
step.
What
webhook
event
we
want
to
listen
to!
A
A
So
then
we
use
the
steps
handler
or
the
steps
event
to
register
a
normal
event
listener
courtesy
of
pro
bots
event,
tomater
event,
emitter
api,
so
anybody
that
sees
robot
should
be
pretty
familiar
with
this
code
right
here
so
so
far,
all
we've
really
done
is
move
the
step
outside
of
the
JavaScript
code.
Nothing
super
fancy
now
for
the
fun
stuff.
A
When
we
get
a
web
hook
payload
for
the
event,
we
need
to
run
a
couple
of
checks
on
it
to
see
which
user
we're
dealing
with
where
they
are
in
the
course.
So
first
we
check,
we
identify
the
user
and
we
can
do
this
in
a
whole
bunch
of
different
ways.
They
all
have
subtle
drawbacks.
You
can
look
at
who
actually
sent
the
event.
So,
if
I
create
an
it
an
issue,
we
can
look
at
who
created
the
issue
or
we
can
look
at
who
owns
the
repository.
A
A
So
once
we've
identified,
which
user
we're
dealing
with,
we
asked
what
step
they're
on
in
this
course.
So
this
is
the
first
time
we
introduce
a
data
point
that
is
solely
owned
by
learning,
lab
and
not
shared
with
github
and
that's
important,
because
you
can
do
so
much
with
github,
but
it's
also
important
to
realize
you
know
it's
not
the
Silver
Bullet.
You
can
build
a
lot
on
top
of
it
and
it's
great
to
sort
of
share
that
information
back,
so
we
keep
track
of
which
steps
a
user
has
started
and
in
which
course.
A
So
then
we
compare
the
step
from
earlier
to
where
the
step
to
where
the
user
is
in
their
actual
course
and
if
they're
the
same,
we
go
ahead
and
run
the
courses
handler
the
steps
Handler
and
that
can
be
virtually
anything.
It
can
be
merging
a
pull
request.
It
can
be
opening
an
issue,
it's
totally
up
to
the
step
and
from
Learning
Labs
perspective.
What's
important
here
is
the
return
value
right.
You
see
that
words
success.
A
So
if
the
steps
handler
returns,
true
the--,
we
know
that
they've
passed
the
step,
which
means
that
they've
done
whatever
the
course
was
asking
them
to
do,
and
we
go
ahead
and
mark
that
step
as
past
for
them
now,
the
next
time
we
get
an
event,
a
webhook
event
that
has
that
same
event.
As
the
step
super
confusing
I
know,
then
those
checks
aren't
gonna
pass
again,
but
they
will
for
the
next
step
in
the
course
right
step,
number
three.
A
So
to
give
you
a
practical
example
in
this
step
example,
we
say
we
ask
the
user
to
say
hello
in
the
body
of
a
new
issue,
we're
listening
for
an
issue
created
event.
We
check
the
body
on
that
payload
we
say.
Does
it
include
hello?
If
it
does
return?
True
they've
passed
the
step
awesome
and
if
it
doesn't,
we
don't
return
anything
which
is
false,
II
and
will
not
pass
the
step
for
the
user.
So
this
actually
got
us
a
long
way.
This
got
us
to
a
working
version
of
the
Learning
Lab.
A
A
We
tried
to
put
those
all
behind
helper
methods
to
help
abstract
those,
and
you
know,
build
courses
more
efficiently,
but
here's
what
I
love
all
of
the
logic
that
isn't
very
specific
to
how
that
step
in
the
course
operates
is
totally
abstracted
right.
The
concept
of
progress
and
progress
tracking
is
abstracted,
so
we
never
have
to
look
at
it
again,
right
nope,
so
our
dreams
for
this
project
were
too
big,
and
this
system
didn't
scale
at
the
time.
Courses
were
written
entirely
by
a
at
github.
A
So
we
wanted
to
expand
learning
lab
and
allow
others
to
write
courses,
but
writing
JavaScript
for
each
and
every
course
was
a
lot
to
ask
and
I
mean
for
one
thing:
it
honestly
took
us
a
lot
of
time,
so
the
other
thing
is
at
the
time
we
didn't
want
to
take
on
the
burden
of
running
user-provided
code.
You
look
at
actions
right
now.
Github
actions,
super
cool,
new
technology,
they're
amazing,
but
at
the
time
those
didn't
exist.
A
So
we
also
didn't
want
to
make
sure,
or
we
want
to
make
sure
that
course
authors
weren't
just
supplying
whatever
they
could
do,
because
it
was
really
easy
to
introduce
bugs
in
a
course
and
when
you
do
that,
users
are
left
with
a
sort
of
you
know
where
do
I
go
now
in
this
learning
experience,
and
that's
really
really
bad
for
a
learning
experience,
because
they
have
to
trust
it
a
lot.
So
we
started
with
the
obvious:
what
were
our
goals?
What
did
this
new
system
need
to
do?
A
Well,
in
our
case,
the
the
question
was
mostly
answered
already
because
we
had
courses
and
we
had
a
list
of
github
API
s
and
web
hooks
were
that
we
were
listening
for,
and
we
also
had
a
list
of
everything
on
a
web
hook,
payload
that
we
were
already
looking
at
so
that
was
fairly
simple.
I
did
an
audit
of
our
five
existing
courses,
I
think
at
that
point
we
were
actually
up
to
eight
or
so,
and
I
wrote
down
all
of
the
API
endpoints
that
we
were
using
and
all
that
stuff.
A
So
here's
what
I
found
some
of
this
might
not
surprise
you,
but
there
were
lots
of
if-else
comment
or
conditionals
right.
We
wanted
to
say
you
know:
does
this
something
meet
this
conditional?
Does
this
file
include
the
right
content
does?
Does
this
issue
include
the
right
label
that
kind
of
stuff?
So
from
that
we
sort
of
understood
that
whatever
conditional
logic
we
came
up
with
to
provide
course,
authors
had
to
be
fairly
vague
and
pretty
powerful
and
I
also
saw
a
lot
of
issue
comments
which
made
sense.
A
The
bots
wanted
to
respond
to
people
in
issues
and
pull
requests.
It
had
a
lot
to
say,
so.
We
wanted
to
sort
of
make
sure
that
that
was
a
good
experience
and
then
each
course
had
slight
derivations
on
what
other
API
is.
They
were
using.
Github
has
a
really
rich
API
and
we
wanted
to
make
sure
that
courses
could
maintain
that
sort
of
we
can
do
whatever
exists
on
github
within
reason.
A
So
you
know
what
I
did
I
wrote:
some
yeah
Mille
well
really
I
built
a
system
that
consumes
yeah
Mille,
but
there
was
lots
of
yeah
m'ling
involved
so
to
the
existing
files.
We
added
the
concept
of
actions,
not
the
github
actions
that
we
talked
about
today,
which
are
amazing
something
totally
different.
A
So
this
is
what
we
shipped
you'll
see
the
very
large
commit
count.
These
were
not
trivial
commits
now
it
was
broken
down
into
multiple
pull
requests,
but
at
the
end
of
the
day,
this
is
what
we
merged
and
it
was
a
big
day
and
by
some
miracle
we
deployed
this
change
without
anybody
knowing
but
I
was
really
tired,
but
it's
okay,
because
my
team
sent
me
cookies,
so
nice,
so
I'm
gonna
show
you
how
this
new
yamo
system
works
because
it'll
lead
into
the
shiny
new
things.
A
I'm
gonna
talk
about,
but
I'll
start
with
this
spot.
Everything
is
a
template,
including
your
templates
templates.
Yeah
I
had
written
a
lot
of
yeah
Mille
at
this
point.
So
if
you
kind
of
think
about
it,
everything
that
we
do
in
code
is
piecing
things
together
and
to
build
a
system
that
pieces
things
together.
It's
sort
of
it's
an
interesting
mindset
to
steep
yourself
and
everything
as
a
template,
so
so
as
a
first
step,
I
extracted
the
repeated
logic
from
the
old
courses
JavaScript
into
actions.
A
So
this
is
the
Amal
API
I,
designed
to
call
them
you'll,
see
that
I
use
an
action
with
a
type
create
issue
and
provide
some
additional
fields.
So
here's
what
this
actually
looks
like
under
the
hood
we're
basically
calling
this
JavaScript
module
straight
from
the
EM.
So
this
is
one
of
more
straightforward
actions,
but
hopefully
you're
starting
to
see
how
this
templating
setup
can
get
bigger
and
much
more
powerful.
A
So
it
let
us
go
from
something
like
this
to
this
wonderful
yam,
alized
version,
and
this
actually
does
the
exact
same
thing
within
our
new
system.
So
I
want
to
talk
about
one
of
the
really
interesting
actions.
We
use
a
lot
in
our
courses,
the
gate,
it's
a
sort
of
if-else,
but
it
can
say
because
this
condition
is
not
met.
The
user
does
not
pass
the
step,
which
is
a
really
great
way
of
saying
hey.
You
know
you,
you
didn't
do
what
we
wanted
you
to
do
properly.
A
Here
are
some
great
tips
on
how
to
do
it
well
and
they
can
go
from
there.
So
with
this,
we
get
a
pretty
powerful
conditional
with
just
a
few
lines
of
yam
and
there's
a
whole
bunch
of
other
options
and
I'm,
not
even
passing
that
I
could,
because
it
gets
pretty
big,
so
we're
able
to
compare
fields
on
the
web
hook,
payload
with
arbitrary
content.
A
Now
taking
this
a
step
further
into
a
more
realistic
setting,
this
gets
the
user
ready
for
the
next
step
by
creating
a
new
issue,
but
it
could
be
merging
a
pull
request
or
enabling
github
pages
or
creating
a
pull
request.
Review
like
I,
said
the
entire
github
API
is
pretty
much
open
for
us.
So
by
now
we
have
a
wealth
of
actions
that
are
used
within
the
various
courses,
and
these
range
from
straightforward
actions,
like
merger
branch
to
you,
know,
get
something
from
git
which
is
like
super
complicated.
A
So
I
want
to
call
out
this
particular
line
at
the
bottom.
What
we're
doing
is
referencing
a
markdown
file
and
in
this
file
we
store
the
actual
text
content
of
what
the
bot
is
going
to
respond
with
it's
sort
of
like
it's
sort
of
like
it
speaker,
notes.
Aha,
so
we
already
use
markdown
for
writing
content
at
github
and
that's
sort
of
how
people
communicate
on
github
the
platform
they
write,
documentation
and
markdown.
A
We
communicate
in
issues
and
pull
requests
and
markdown,
so
it
felt
really
natural
or
already
now
we
took
it
a
step
further
to
add
some
templating
to
those
markdown
files
to
provide
those
courses
with
some.
You
know
additional
context
and
information
make
the
learning
experience
feel
a
lot
more
personal.
We've
actually
taken
this
even
a
step
further
and
provided
users
with
some
preference
availability.
A
A
A
So
the
most
exciting
thing
for
me
was
when
the
next
few
courses
rolled
out
the
door
with
minimal
engineering
effort,
so
our
training
team
was
able
to
design
new
curriculum
and
implemented
on
learning
lab
with
you
know,
basically,
no
help
from
the
engineers
were
not
needed
anymore,
so
we
were
lacking
documentation.
The
api's
were
largely
untested
and
the
schema
for
gambling
was
a
little
confusing,
but
it
worked
and
since
then
we've
been
improving
the
API,
adding
new
actions
and
getting
a
much
better
understanding
of
what
it
means
to
build
courses
on
learning
lab.
A
So
it
was
always
our
goal
to
help
organisations
scale
their
training
right.
We
wanted
to
improve
the
way
they
work.
That
was
our
motivation
from
the
beginning,
and
we
knew
that
a
common
point
of
friction.
When
you
are,
you
know,
switching
from
an
old
version,
control
system
or
another
version
control
platform.
Is
that
it's
hard
to
just
switch
right.
It's
a
it's,
a
workflow
switch,
it's
a
culture
change
and
it
has
to
be
really
deliberate.
So
today
we
announced
Learning
Lab
for
organizations.
What
does
that
mean
great
question?
A
So
your
organization's
can
now
design
and
build
private
courses
containing
proprietary
information
about
how
your
organization
works.
So
this
is
great
for
any
kind
of
org
that
needs
to
scale
up
their
developer
teams,
while
maintaining
the
workflows
that
they've
already
had
success
with
or
it's
an
opportunity
to
improve
those
workflows
in
a
more
realistic
setting.
So
specific
branch
naming
strategies
custom
integrations
that
you
want
your
developers
to
know
about
being
able
to
train
them
in
the
actual
workflows
that
they'll
be
using
is
super
super
helpful
right.
A
Remember
that
context,
switching
you're
gonna
be
a
lot
more
successful
if
you
don't
have
to
bounce
back
and
forth
between
five
different
places.
So,
with
this,
we've
also
added
an
organization
dashboard
to
show
aggregate
information
about
how
your
private
courses
are
doing
and
how
members
of
your
organization
are
growing
and
learning
with
those
courses.
A
I'm
super
excited
for
you
folks
to
have
your
hands
on
this.
This
is
something
that
we've
been
working
on
for
a
while
and
I'm
just
I'm
so
excited
so
we're
also
looking
for
organizations
to
partner
with
that
want
to
participate
in
a
private
beta
of
public
courses.
So,
right
now,
all
of
our
courses
that
we've
shared
our
public
anybody
can
take
them.
It's
not
paid.
It's
totally
free
for
developers
that
want
to
you
know,
learn
markdown,
learn,
introduction
to
github
introduction
to
HTML
all
kinds
of
really
cool
things.
A
We
actually
launched
three
new
courses
today,
they're
amazing,
some
of
them
use
new
technology
that
we
showed
in
the
univers
keynote
so
definitely
check
those
out.
But
if
you're,
an
integrator
with
a
product
to
share
or
some
kind
of
platform
that
you
have
developers
using
and
want
to,
you
know
help
them
use
your
API
is
better
or
more
efficiently
or
just
at
all.
Definitely
let
us
know-
and
you
can
do
that
by
heading
over
to
lab
github
comm,
slash
organizations,
you
can
also
email
services
at
github
com
and
there's
also
an
ask
services
booth.
A
Just
upstairs
our
professional
services
team.
They
are
amazing.
They
will
be
happy
to
answer
questions
I'll,
be
there
most
of
the
day
tomorrow.
If
anybody
has
questions
and
then
of
course,
if
you
have
questions
at
all,
feel
free
to
come,
see
me
afterwards
or
you
can
get
ahold
of
me
on
Twitter,
that's
my
Twitter
handle
I
want
a
whole
bunch
of
new
followers,
so
there
you
go
and
that's
it.
Thank
you
all.
So
much
for
listening.