►
From YouTube: Community Stream #6 - Murdering a Bug
Description
Broadcasted live on Twitch -- Watch live at https://www.twitch.tv/nrelabs
A
Okay,
thanks
for
your
patience,
this
is
going
to
be
a
really
cool
stream,
so
I
I'm,
going
without
Toad
this
morning,
toad
is
dealing
with
some
corporates
left
top
issues
that
I
know
everybody
has
dealt
with.
So
this
may
not
be
like
the
full
hour
or
whatever,
of
course,
we're
starting
40
minutes
late.
So
maybe
it
will
go
to
the
top
together.
There's
a
few
things.
I
want
to
talk
about,
there's
really
two
main
things
one.
A
The
first
thing
is
something
that
has
frustrated
me
for
a
few
months
in
some
of
the
the
way
that
the
backend
has
worked,
there's
been
a
bug
that
I
thought
was
innocuous,
but
ended
up
not
being
crazy.
Innocuous
and
so
I
want
to
accomplish
two
things.
I
want
to
explain
the
bug
and
I
also
want
to
apologize
that
it
impacted
the
people
that
it
did
I'll
get
into
this,
but
the
nature
of
the
bug
actually
allows
me
to
be
precise,
with
the
number
of
people
that
were
affected
by
it.
A
I
know
that
what
was
it
eight
percent
I
think
was
eight
percent
yeah
yeah
point:
oh
seven,
six!
Nine
percent
of
people!
Sorry
point!
Oh
yeah,
well,
seven
point:
six:
nine
percent,
sorry
of
people
were
affected
by
this
bug
and
because
of
the
nature
of
the
bug,
I'll
explain
and
that's
how
I
there's
a
specific
reason.
Why
I'm
able
to
be
that
sure?
And
for
those
in
that
unfortunate
minority
you
you've
probably
had
a
pretty
bad
NRI
life
experience
for
the
past
few
months.
I
don't
want
to
spoil
it
I'll
I'll
get
into
it.
A
So
so
really
the
thing
that
I
want
to
do
is
go
through
that
I.
Actually
I'm
gonna
whiteboard.
That
because
I
think
it's
interesting.
It's
just
cool
to
have
not
only
found
the
source
of
the
bug,
but
also
be
able
to
articulate
why
and
then,
of
course,
to
offer
my
apologies,
because
I
didn't
think
it
was
as
much
of
a
problem
as
it
was
so,
even
though
it
was
a
very
small
number
of
people
impacted
relative
to
everybody
else,
and
there
were
ways
around
it.
A
The
main
main
thing
there
is
to
dive
deep
on
it,
just
to
explain
some
of
the
architecture
that
led
to
this
also
to
set
of
the
stage
for
something
that
we're
gonna
be
doing
in
in
the
whole
antidote
version,
1
Oakland,
which
you're
gonna
start
hearing
more
about
that
we're
starting
to
get
closer
and
closer
to
an
idea
of
what
we
want.
One
dato
to
look
like
you
know:
we
put
energy
labs
out
there,
we
launched
in
October
last
year
and
I
got
to
tell
you
it
really.
A
It
didn't
go
through
that
much
development
prior
to
that.
This
was
not
something
that
I.
You
know
that
we
sat
down
and
like
did
over
like
two
years.
It's
like
it
was
like
four
months
and
I
had
a
baby
in
the
middle
of
that.
So
it's
like
you
know
there.
There
were
certainly
shortcuts
taken
to
make
sure
that
the
that
the
platform
got
out
there.
We've
said
from
the
beginning
that
entering
labs
was
never
meant
to
be
something
that
juniper
just
put
out
there.
A
How
does
somebody
that
doesn't
know
what
to
make
sure
it
all
gets
started
by
consuming
things
very
easily
in
the
browser
which
we've
all
talked
about.
So
to
that
end,
you
know
we
put,
we
put
this
out
as
quickly
as
possible,
because
again
we
didn't.
This
was
a
this,
isn't
a
Juniper
product,
it's
effectively
a
side
hustle
to
be
honest,
is
is
the
way
that
this
came
out
and
the
whole
reason
we
wanted
to
put
it
out
early.
A
It
was
because
we
wanted
to
prove
out
the
concept
of
curriculum
as
code
and
by
pushing
pushing
the
platform
out
as
early
as
possible.
We
get
people
thinking
about
that
as
early
as
possible,
which
means
that
the
curriculum
becomes
much
more
of
a
community
effort
instead
of
something
that
again
we
baked
behind.
You
know
closed
doors
for
a
year
or
two,
that's
not
what
we
wanted
to
do
so
anyway.
The
reason
I
say
all
that
is
that
comes
with
trade-offs
like
if
you
want
to
put
something
out
very
quickly.
A
You
have
to
make
certain
decisions,
and
this
is
in
the
truest
nature
of
technical
debt,
not
the
not
the
way
most
people
use
the
term,
but
in
the
truth,
nature
definition
of
technical
debt
I
made
decisions
in
the
creation
of
a
lot
of
the
backend
platform.
That
was
explicitly
designed
to
keep
things
simple
and
quick
and
cheap
and
cheerful,
and
there
are
definitely
trade-offs
there
in
terms
of
how
well
the
backend
scales,
which
is
why
we
have
a
static
number
of
virtual
machines
right
now
serving
this
up.
A
So
a
lot
of
what
I'm
about
to
talk
about
is
going
to
change.
In
fact,
everything
that
I
whiteboard,
you
can
probably
safely
assume
that
it
won't
last
for
1.0,
because
the
whole
architecture
of
how
state
is
managed
in
the
back
end
of
every
Labs
will
change,
but
I
think
it's
a
useful
exercise
regardless.
So
just
keep
that
in
mind.
A
I'll
probably
just
claim
that
once
more
one
when
I
get
whiteboarding
the
thing
that
I'm
white
boring
isn't
meant
to
educate
you
on
like
how
the
backend
works,
because
that's
how
it
works
now,
but
it
probably
won't
work
that
way
for
a
long
for
awhile
or
in
a
little
bit
it
will.
It
will
change
you
know,
probably
the
next
few
months,
so
that's
one
thing
I
want
to
cover
and
then
towards
the
end.
You
know
what
I'll
do
this
now
I'll.
Do
the
white
boarding
last
so
there's
a
few
things.
A
We
have
certainly,
obviously,
this
stream
being
one
of
them.
Many
community
efforts
that
we're
trying
to
do
to
build
a
community
around
the
curriculum
that
we're
building
in
the
platform
that
we're
building
so
naturally,
like
I,
said
one
of
those
things
is
this
stream
that
you're
watching
right
now?
Another
one
is
our
discord
channel.
We
have
a
discord,
channel
fir'd
for
sort
of
real-time
communication
if
you're
not
familiar
with
this
cord
by
the
way,
it's
a
it's
kind
of
like
slack
but
better.
A
It's
like
it
has
a
lot
of
the
things
people
like
about
slack
but
a
lot
of
other
stuff
as
well,
and
in
addition,
it
just
has
a
better
education
model,
so
you
don't
have
to
authenticate
per
server
that
you're.
You
know
going
into
you
just
kind
of
authenticate
once
there's
a
bunch
of
other
stuff.
That's
that's
cool
one
thing
that
even
was
missing
from
that,
though,
was
the
idea
of
real
time.
Can
we're
sorry
that
that
obviously
is
really
good
for
real-time
communication?
But
one
thing:
that's
missing
from
that.
A
But
even
if
you
did
that,
it's
still
a
very
walled
garden,
meaning
that
the
way
that
people
find
information
about
your
project
normally
through
googling,
all
of
the
information
that's
being
disseminated
within
that
community
is
not
available
to
Google,
like
you
have
to
sort
of
be
in
the
community
and
be
listening
all
the
time
or
at
least
know
what
you're
searching
for
having
content
out
there.
That
is
public.
Make
means
that
it
can
be
Google,
indexed
and
I
know
it.
A
I
know
it's
free
to
join
discord
and
slag
and
all
those
things
but
I'm
talking
about
how
easy
it
is
to
find
information
and
I
think
a
lot
of
people
learn
that
way
through
you
know,
through
googling,
and
so
one
thing
that
we
want
to
do
is
find
the
right
first
off.
We
don't
want
to
have
a
bunch
of
different
communication
methods.
A
But
then
we
started
thinking
of
other
things
that
we
wanted
to
do
like
in
terms
of
future
like
gamification
and
not
the
weird,
like
you
know,
cheesy
way
like
more
like
just
keeping
track
of
what
you've
done
and
and
effectively
creating
what
we
were.
One
of
the
ideas
we've
been
playing
with
is
create
creating
this
sort
of
profile
of
a
lesson
either
you
know
and
learner
or
or
or
a
teacher
or
a
contributor,
either
way
building
kind
of
a
profile
of
what
that
person
is
good
at
not
good.
A
That's
not
the
right
term,
but
kind
of
things
that
they
like
to
focus
on
like
mine,
would
be
testing.
No
doubt
that's
one
of
the
things
that
I
love
have
loved
focused
on
focusing
on
for
a
long
time,
Network
automation,
testing
and
testing
in
general,
even
in
the
software
space.
So
you
basically,
we
wanted
a
platform
that
allowed
us
to
do
certain
things
like
that,
and
you
know,
email
lists
are
not
meant
for
that.
There's
their
email
lists.
A
You
send
an
email
into
this
distribution,
everybody
gets
it
and
then
a
cop
is
made
on
available
on
the
web,
and
so
people
can
google
for
things
that
you
share
and
then
they
find
it.
But
then,
of
course,
all
these
other
goals
that
we
had
wouldn't
be
met
and,
of
course,
like
I
said
I
didn't
want
to
have
you
know
we
didn't
want
to
have
multiple
tools.
A
A
It
seems
relatively
new,
it's
a
it's
like
a
it's
like
if
forums
it's
like
forums
but
for
2019,
it's
called
discourse
and
I
believe
the
guy
behind
Jeff
Atwood,
the
guy
behind
Stack
Overflow,
is
either
jointly
or
solely
probably
I
think
jointly
responsible
for
this
new
project
discourse.
But
it's
really
cool.
Like
I
said
it's
like
forums,
but
not
in
the
90s
and
early.
You
know
to
thousands
and
it
accomplishes
a
lot
of
what
we
want.
Not
only
is
it
everything
Google
indexable,
which
again
people
learn
through
doing
that.
A
We
kind
of
just
want
to.
You
know,
allow
everybody
to
write
to
post
things,
but
we
still
do
want
to
give
credit
for
some
of
the
lessons
that
they've
done
it.
So
we're
really
thinking
about
integrations
between
anti
relapse
and
discourse,
nothing
to
share
there
that'll
be
part
of
the
version
1.2
zine
that
we'll
share
in
the
near
future,
but
just
FYI
as
a
heads
up.
If
you
would
like
to
join
the
discourse
community,
it's
live
right
now
we
haven't
really
published
this.
This
is
kind
of
the
first
time
anybody's
mentioned
it.
A
If
you
go
to
community
dot
network
reliability,
engineering
so
instead
of
labs
just
say:
community
you'll
go
to
it'll,
go
to
the
discourse
page
now,
I
will
say
it's
it's
very
new,
and
so
it's
very
skeleton
really
looking.
So,
if
you're,
if
you're
looking
at
that
and
you're
thinking
of
like
I,
would
I
would
like
to
ask
this
question
about
how
the
platform
works
or
how
to
contribute
a
lesson
or
any
number
of
things.
A
Please
ask
it
there
we're
going
to
be
getting
some
of
the
people
that
have
you
know,
contributed
sort
of
behind
the
scenes,
in
slack
and
in
dis
court
to
push
their
questions
in
there
so
that
everybody
can
benefit
from
it.
So
please
join
its.
It's
not.
You
know
required
we're,
never
going
to
require
that
you
are
part
of
that
to
use
energy
labs,
but
if
you
do
authenticate
to
the
discourse
site,
you'll
you'll
probably
get
some
like
extras
like
the
ability
to
track
what
you've
done.
A
Things
that
you
would
expect
nothing,
nothing
like
hidden
or
anything
like
that,
but
just
a
you
know,
sort
of
additional
context
for
what
you've
done
so
very
excited
to
share
that
in
the
future.
But
that's
all
I
have
for
now
in
terms
of
tangible
things
to
share
the
the
next
thing
I'd
like
to
do
is
whiteboard
this
issue.
So
let
me
first
set
the
stage.
A
Let
me
go
to
my
stream
settings
and
do
screen
share
and
I
will
leave
her
a
podcaster
enabled
for
now
and
actually
I
want
to
I
want
my
oops
I
want
my
webcam
to
be
on
top
so
that
I
can
still
so
you
can
still
see
my
beautiful
face
there.
We
go
okay,
so
let
me
now
go
to
a
katana
all
right,
so
just
to
make
sure
you
can
see
that
good.
So
this
is
these
are
the
stats
for
lessons
in
progress
for
NRE
labs.
Basically,
what
what
the
backend
Orchestrator
does
called
syringe
is.
A
It
keeps
it
keeps
track
of
the
lessons
that
are
in
progress
and
every
once
in
a
while.
It
sends
effectively
a
blob
to
a
time
series
database
in
flux,
DB
and
then
this
graph
on
a
page
is
designed
to
look
at
that
that
data
source
and
display
it-
and
you
know,
visualize
it
now.
This
is
mostly
not
useful,
for
you
know
the
you
know
the
average
Joe
that's
using
the
site
might
be
kind
of
useful.
A
It's
mostly
useful
for
folks
like
me
who
I
want
to
keep
you
know,
I
want
to
keep
track
of
like
for
it,
for
instance,
especially
early
on
this
was
a
very
good
indicator
of
any
problems.if
like
there
was
a
sudden
die,
probably
meant
syringe,
crashed,
because
the
first
thing
syringe
does
whenever
he
starts,
is
it?
Is
it
cleans
up
all
the
existing
lesson?
Namespaces
and
again,
there's
reasons
for
that.
We
don't
have
an
external
database,
and
so
all
the
state
is
kept
inside
of
syringe.
So,
instead
of
you
know,
we
don't
want
any
straggling
namespaces.
A
In
fact,
the
this
this
is
just
one
day
here
over
the
course
of
several
days
in
many
in
many
cases
weeks,
it
just
sort
of
naturally
keeps
building
and
building
and
building.
Now.
What
you're,
looking
at
here
is
the
different
cup
they're
actually
overlaid
on
top
of
each
other.
The
different
lessons
are
the
different.
The
different
colors
represent
the
different
lessons,
and
so,
if
you
see
this,
for
instance,
you
see
not
only
is
this
lesson
at
you
know
twenty
three
concurrent
lessons.
A
It
looks
like
that's
introduction
to
yeah
mole,
so
the
graph
seems
to
be
saying
that
at
this
time
there
were
twenty
three
concurrent
introduction
to
my
lessons:
fifteen
Jinja
lessons
and
then
spattering
of
others.
So
it's
not
just
a
twenty
three.
It
looks
like
potentially
you
know
upwards
of
50
or
more
lessons
in
in
progress.
A
Now,
normally
my
ego
would
would
say,
like
yeah
people
are
using
energy
labs,
it's
awesome,
but
it
I
knew
I
knew
better
and
certainly
people
are
using
it,
but
just
not
that
many
at
once
at
least
right
now.
Usually
the
usage
is
much
more,
is
much
more
predictable
and
sort
of
flat.
Because
again
you
only
you
only
see
these
spikes
if
people
are
if
a
bunch
of
people
are
using
the
same
lesson.
A
So
if
a
bunch
of
people
using
different
lessons,
that's
how
you
get
this
like
overlap
effect
here
on
the
bottom,
so
normally
the
the
graph
gets
to
about
one
two.
Four
four
is
generally
the
peak,
for
you
know
peeking
out
on
a
single
lesson.
That's
that's
about
how
much
it's
been
when
we
launched
it
was
a
little
higher
than
that,
and
then
there
were
a
few
other
events
that
we
did
like
an
SD
summit,
internal
and
juniper
that
we
presented
this
at
and
you'll
see
a
little
more
activity.
A
But
generally
that's
the
pattern
this
this
this,
the
graph
you're
seeing
here,
is
very
much
not
in
the
pattern,
and
so
what
I
want
to
do
is
explain
how
this
came
to
be
and
I
want
to
go
over
how
we,
how
I,
how
I,
first
off,
how
I
stumbled
upon
this
bug
and
and
also
before
that
I
want
to
talk
about
why
it's
taken
so
long
to
fix
it.
So
a
few
things
to
go
over
here.
A
A
A
The
general
architecture
of
syringe
and
and
what
less
to
this
problem
so
in
so
syringe
is
a
is
a
is
the
backend
Orchestrator
for
energy
labs
and
the
antidote
project.
What
syringe
allows
us
to
do
is
it
allows
us
to
specify
a
curriculum
in
in
simple
text
file,
storing
those
files
that
get
and
then
incorporating
those
into
a
larger.
A
So
you
know
other
lessons
and
things
like
that,
and
then
that
syringe
is
responsible
for
publishing
that
content
via
an
API
northbound
to
whatever
is
consuming
it
and
in
the
vast
majority
of
cases,
that's
the
antidote
web
project,
which
is
what
you
see
when
you
go
to
enter
relapse.
So
syringe
is
the
system
on
the
backend
that
has
an
API
possess,
that
API
northbound
to
and
still
web
and
I'm
gonna
draw
that
because
that's
not
the
point,
the
point
is
syringe
itself
is
provided
north
in
a
well
and
the
southbound
talks
to
Cooper
Nettie's.
A
So
when
your
web
browser
connects
to
dadlabs
the
JavaScript
on
the
front
end
is
designed
to
generate
things
like
session
ID
theäôve
compete
so
extort.
That's
the
one
cookie
that
we
store
and
I
feel
anything.
We
do
that
is
to
make
sure
you
get
back
into
the
lesson
that
you
need
to
get
into
if
you
refresh
the
page,
for
instance,
it's
a
way
of
just
keeping
track
of
who
you
are
it
not
enough
personally
identifiable
wedged
in
a
session?
Just
remember
that
we
do
that
because
that's
that's
gonna
come
in
handy
with
the
car.
A
They
consume
the
safety
on
and
then
northbound
or
southbound.
Rather,
you
can
see
that
it
communicates
to
kubernetes
make
sure
you
can
see
that
oh
yeah,
we
got
plenty
of
real
estate,
so
so,
basically
this
is
what
syringes
and
like
I
said.
Please
don't
get
married,
because
this
will
change,
but
right
now
all
syringe
at
least
the
server-side
there's
a
client
as
well,
but
that
you
can
run
on
your
laptop
for
things
like
validation,
that
the
backend
is
just
one
single
binary.
A
So
everything
is
just
in
this
one
single
running
process,
and
so
everything
I'm
about
to
talk
about
are
the
internals
of
syringe
of
the
backend
binary
here.
So
that's.
What
syringe
does
I'm
gonna
draw
a
bigger
box
and
then
talk
a
little
bit
about
the
internals
of
syringe.
So
this
big
box
is
syringe.
A
So
this
big
box
of
syringe,
as
I
mentioned,
syringe,
is,
is
made
one
single
payer,
but
to
do
this
things
that
we
need
storage
to
do
currently,
it's
separated
into
two
logical
components
so
that
you're
not
processes,
it's
still
one
process,
but
the
political
things
about
go
is
that
it
will
never
to
manage
concurrency
very,
very
efficiently
and
very
and
very
easily
really.
It
has
a
lot
of
really
awesome
primitives
for
handling
myself.
So
this
is
enough.
This
is
not
that
process.
A
Depreciation
is
all
once
one
process,
but
inside
of
syringe
we
have
two
local
components.
We
have
the
API
server
and
then
we
have
these
scheduler
and
actually
before
I
go
any
further.
What
I'm
going
to
do
is
I'm
going
to
separate
the
two
again.
Please
keep
in
mind
that
this
is
one
just
one
process,
but
I
want
to
give
myself
some
space
here,
because
I
want
to
talk
about
how
they
communicate
with
each
other,
how
these
two
components
communicate
with
each
other.
So
that's
the
API
server,
and
this
is
the
scheduler.
A
So
if
you
think
about
the
different
like,
if
you
think
about
the
different
components,
there's
there's
too
many
components
again
all
inside
of
the
same
running
process,
the
API
server
is
responsible
for
providing
the
API.
The
front-end
consumes
can
make
lessons
work,
and
so
we
have
and
those
pretty
mostest
declared
services.
Things
like
you
know,
request
new
lesson
or
get
new
lessons.
So
all
the
API
endpoints
that
you
might
expect
that
you
can
see
in
our
Doc's
actually
are
lighted
by
this
component.
A
Again,
all
one
running
process
that
this
component
is
designed
to
ought
to
provide
that
connectivity
northbound,
and
it
also
does
some
other
things
like
keep
track
of
states.
So
if
you
I
wish
I
left
myself
some
room
up
here,
let
me
make
this
kind
of
there.
We
go.
It's
not
the
perfect.
It's
not
a
perfect
square.
That's
fine!
A
So
the
API
server
part
of
syringe
a
traversed
by
a
response
to
outside
requests,
and
so,
if
you
initially
send
a
request
into
syringe,
but
just
by
going
to
the
website
again
the
JavaScript
on
the
in
the
web
portal
with
be
doing.
This
sends
a
request.
Ends
like
I
need
less
than
12,
so
basically,
you've
gone
to
less
than
12,
which
is
I
have
in
the
Jason
Eppie
lesson
it's
another
byproduct
of
having
worked
on
this
very
intensely
for
four
months
is
I.
Have
most
of
the
lesson.
A
So
lesson
ID
12
and
the
other
thing
that
it
needs.
This
is
also
something
it's
done
on
the
on
the
front
end
is
a
session
ID,
so
you
have
a
lesson
ID.
I
lesson
12,
but
who's
requesting
it
and
I
keep
track
of
who
requested
it
so
that,
if
you
requested
again
I
know
who's.
You
know
what
kind
of
data
is
sent
to
you.
So
so,
usually
this
is
some
sort
of
it's
all.
Just
I
can't
remember
how
long
this
is,
but
it's
just
alpha.
A
It's
not
even
alphanumeric,
it's
just
alphabet,
so
26
letters
possible
and
then
some
length
of
characters,
let's
say
ten
or
five
for
the
sake
of
argument,
so
ABCDE
F
or
ABCD,
a
b
c
d
e
and
then
actually
the
stage
is
set
and
that's
optional.
So
these
are
the
two
required
fields
for
requesting
a
new
lesson.
You
need
to
specify
who
you
are
meaning
the
the
string
of
characters
that
the
front
end,
meaning
the
JavaScript
client
that's
in
into
the
web
when
it
generated
for
you
and
store
it
as
a
cookie
in
your
browser.
A
So
that
is,
that
is
what
uniquely
identifies
you
when
you
go
to
the
site
and
in
this
session
of
these
importance
it
keeps
track
of
the
lesson
resources
based
on
the
session
ID
and
then,
of
course,
you
want
the
last
90,
which
lesson
do
you
want,
which
which
lesson
are
you
trying
to
load
and
then
so,
together
these
these
to
actually
create
sort
of
a
session
any
of
their
own
or
a
UUID?
That's
carried
throughout
the
system
generally,
just
FYI
the
the
request.
A
Endpoint
requires
those
two
things
now.
What
happens
is
that
request?
Endpoint
has
some
logic
in
it.
It
does
some
basic
sanity
checking
like
hey,
there's
less,
how
you
twelve
actually
exist
if
it
doesn't
I'm
just
going
to
throw
an
error
right
away.
So
there's
some
simple
stuff
that
we
do
within
the
yeah
there's
some
logic.
There's
a
lot
here.
Actually
that
does
stuff
like
that.
Just
basic
sanity
checking
kind
of
like
kind
of
like
a
security
guard.
A
You
know
they're,
not
gonna,
stop,
you
know,
they're,
not
gonna,
stop
like
an
invasion
by
a
military,
but
they
do
some
of
the
basic
stuff
to
make
sure.
Like
you
know,
people
don't
try
to
rob
the
place,
so
we
have
basic
where
a
security
guard
kind
of
functionality
within
the
API
server
feel
sneeze
coming
on.
A
Refresh
the
page,
we
don't
want
to
have
to
reprovision
the
lesson
from
scratch:
we'd
like
them
to
get
access
to
the
same
lesson,
those
provision
before
again
a
student
still
exists
and
hasn't
been
going
collected,
and
so
the
way
that
we
do,
that
is,
we
actually
keep
track.
There's
a
table
within
the
API
server
itself.
It
keeps
track
of
session
IDs,
meaning
like
12.
A
In
my
head
meeting
the
API
server
they
it
knows
that
there's
a
lesson
in
progress
with
that
less,
maybe
with
that
session
ID.
So
that's
pretty
cool
the
next
day
does.
Is
it
record
that
state
and
the
next
thing
it
does
is
via
a
little
channel,
which
is
a
way
that
different
go
routines
can
communicate
with
each
other
and
by
the
way
the
API
server
and
scheduler
run
on
separate
go
routines.
So
these
are
running
parallel.
A
These
don't
have
to
run
together,
but
they
do
have
to
coordinate
and
one
of
the
ways
they
coordinate
is
through
channels.
So
there's
a
channel
that
goes
in
this
direction
and
then
there's
another
channel
that
goes
in
this
direction,
which
we'll
get
to
in
a
little
bit.
But
this
channel
is
is
designed
to
have
messages
on
it.
They
say:
API
server,
a
message
to
the
scheduler
and
again
the
very
common
use
use
case,
for
that
is
requesting
a
new
lesson
and
so
on
I,
say:
hey
I
want
a
new
lesson.
Any
case
service
is
cool.
A
I,
don't
see
that
yet
so
I
add
an
entry
into
my
state
into
my
internal
state
so
that
so
that
I
do
keep
track
of
it
now
and
then
I'm
going
to
send
a
request
down
to
the
scheduler
and
say:
hey
scheduler.
Please
go
make
this
lesson
happen,
so
it
doesn't
talk
to
kubernetes
at
all.
It's
designed
to
talk
northbound
to
front
end
and
then
keep
basic
state
about
requests
that
have
come
in
the
request.
That
said,
only
a
guest
server
via
the
skill
channel.
A
It's
called
a
memory
again
solving
process,
and
so
there's
no,
this
isn't
an
API.
So
it's
just
a
go.
Channel.
The
scheduler
seems
that
message,
it
says,
looks
like
we
have
a
robust
Purdue
lesson
and
based
on
the
lesson
definition,
which
is
a
mammal
but
imported
into
syringe
when
it
boots.
So
it's
going
to
have
all
of
that
lesson.
A
Definition
in
memory,
it's
going
to
say:
oh,
it
looks
like
less
than
12
hours,
3,
BQ
effects,
images
and
the
you
know
the
lesson
value
is:
is
this:
you
know
this
file
and
a
bunch
of
other
stuff,
so
I'll
stop
it's
in
the
lesson.
Definition!
Scheduler
now
knows
it
means
to
actually
create,
because
it's
being
requested
to
create
lesson
12.
So
what
that
does
is
it
goes
through
and
it
talks
to
kubernetes
I
assume.
A
You
can
still
see
that
yeah
barely
so
talks
to
kubernetes,
and
then
it
actually
has
its
own
state,
which
were
we're
using,
but
not
really
in
the
in
this
case,
it's
a,
but
it's
not
relevant
to
this
conversation.
This
is
the
state
that
where
we
have
the
laptop,
so
it
keeps
track
of
like
the
specific
kubernetes
resources
like
things
like
pausing
and
services,
and
things
like
that
upon
sitting
here,
so
we
have
a
record
of
it.
Now
all
this
is
in
memory.
This
is
not
this
external
database.
Neither
this
or
this
it's
just
in
memory.
A
I
should
say
that.
So
if
this
restarts
all
of
it
gets
wiped
away.
We're
just
fine,
it's
just
running
lessons
and
does
a
media
keep
track
of
any
of
this.
Everything
that
needs
to
be
persistent
is
in
get,
let's
see,
sorry
I
keep
going
down
the
rabbit
holes
I
shouldn't,
that's
probably
confusing,
so
the
scheduler
received
a
request
right,
so
the
scheduler
received
requests,
I'm
gonna,
go
fire
up
kubernetes
and
talk
about
all
these.
A
You
know
kick
all
these
things
and
actually
I'm
gonna
end
that
there
is
nothing
in
the
scheduler,
it's
cool,
but
nothing
in
the
schedule
is
relevant
for
this
bug
at
the
end
of
this
provisioning
process.
Let's
say
it
takes.
You
know
five
six
minutes
to
boot,
a
lesson
which
actually
isn't
isn't
uncommon.
That
does
happen
because
sometimes,
like
eg
effects,
devices
take
a
lot
of
boot
off
and,
of
course
they
have
health
checks
that
need
to
run
and
then,
of
course
they
need
to
be
configured,
and
so
we
got
to
go.
A
Call
me
Paul
the
configure
them
the
scheduler
takes
care
of
all
of
that.
So
based
on
the
lesson
definition
based
on.
What's
in
the
lesson
and
once
it's
finished,
the
scheduler
sends
a
result
back
to
the
API
server.
Now
that
result
is
designed
to
update
this
state,
and
the
reason
for
that
is
because,
in
this
state
this
this
like
I,
said
the
key
is
this
combination
of
have
lesson
ID
and
session
ID.
A
The
value
that's
stored
in
here
is
basically
a
JSON
blob
of
all
kinds
of
attributes
of
that
lesson,
specifically,
if
the
lesson
is
ready
or
not.
So
when
we
first
received
this
request
and
record
in
a
and
entry
here,
naturally,
we
know
it's
not
ready.
We've
got
an
old
scheduler
about
it.
Yet
so
we
just
say
in
his
lessons
not
ready,
and
so
we
feel
requests
often
scheduler,
and
then
we
keep
chugging
along
here
and
doing
whatever
what
this
means
is,
if
you
can,
if,
if
you
fire
another
request,
there's
actually
a
get
function.
A
So
this
is
anyone
to
request
a
new
lesson,
there's
also
an
get
function
which
simply,
which
simply
says
hey,
give
me
the
latest
information
on
this
lesson,
and
it
has
similar
information.
So
twelve
ACCE
giving
me
the
latest
on
this
particular
lesson,
so
it
just
simply
looks
into
that
table
it's
and
provides
the
result,
that's
stored
in
the
state
and
again,
if
we've
just
requested
this,
the
lessons
not
ready
yet
so
the
response
to
the
safety
I
call
will
be
no
you're,
not
ready
yet
so
it
actually
does.
A
A
A
A
The
scheduler
maintains
that
knowledge,
it
knows,
obviously
is
talking
to
kubernetes
and
it
can
ask
you
or
noise
hey
how
long
your
name,
these
lesson
name
space-
has
been
active
and
it
compares
that
with
the
the
timestamp
of
the
last
time
that
somebody
did
something
of
the
lesson
and
then
based
on
that
it
decides
which
lessons
tune
to
destroy.
Now,
of
course,
after
it's
destroyed
a
lesson,
so
it
says
this
is
the
garbage
collecting
go
routine
within
the
scheduler,
it
says:
hey,
kubernetes,
main
spaces.
A
A
This
isn't
the
word
country
means
so
remember
that
graph
showed,
like
all
of
these
lessons,
continually
growing.
If
you
look
at
the
kubernetes
namespaces,
that's
like
that's
like
the
source
of
truths
really
now.
Obviously
the
namespaces
and
the
state
should
be
in
sync
but
they're.
Clearly,
not
if
you
look
at
the
CUDA
is
namespaces.
If
that
graph
said,
hey,
you've
got
50
lessons
in
progress
and
you
learn
the
kubernetes
namespaces,
with
coop
kowtowing
to
cuoco,
get
NS,
then
you'll
see
the
third
one
negative
one
or
zero
namespaces
so
clearly,
there's
a
mismatch
between
the
two.
A
So
what
happens
when
the
garbage
collection
takes
places
and
delete
the
namespace
successfully
and
in
a
sense,
a
message
back
the
API
servers,
the
API
server
knows
to
clean
up
its
local
state,
probably
you're,
probably
anticipating
what
comes
next
clearly
there's
a
problem
with
how
the
state
gets
cleaned
up
and
you're
not
wrong,
because,
obviously,
if
there's
more,
what
hit?
There's
more
interest
in
here
that
our
namespaces
for
lessons?
Yes,
clearly
there's
some
sort
of
a
problem
with
communicating
that
resolved
back
to
the
API
server.
A
But
it's
not
as
simple
as
that,
because
it
was
just
that
simple
right
there
with
a
problem,
communicating
between
the
two
that
we
would
see
that
you
would
never
see
deletions
in
this.
In
this.
You
never
see
sessions
get
deleted
from
this
list
and
we
were
still
seeing
a
lot
of
lessons
getting
delete.
It
wasn't
like
every
single
lesson
stayed
around
in
the
state.
It
was
roughly
8%
and
I
mean
8%
very
specifically,
because
I
now
know
because
the
nature
buddies,
it
is
a
percent
and
I
should
mention
this
in
flux.
A
Tb
is
sitting
over
here.
This
is
a
separate
process.
It's
not
part
of
you
know
it's
a
separate
open-source
project
and
it's
awesome
by
the
way
check
out
it's
a
time
series
database
and
then,
on
top
of
that
we
have
group
fauna,
which
is
a
graphic
that
the
graphing
application
that
you
saw
earlier
and
again.
This
is.
A
Guru
team
inside
an
API
server,
that's
designed
to
look
at
that
state
and
then
export
it's
in
flux,
I
already
admitted
or
so
so
it's
pretty
simple.
It
just
takes
a
snapshot
of
whatever
than
the
state
sends
it
off
to
in
flux
and
then
shows
the
in
in
grow
funnel,
which
means
that-
and
we
see
this
grant
guerrilla-
that's
that's
a
reflection
on
this
on
the
state
being
reset
now
this
is
this
is
the
difficult.
This
is
the
problem
with
this.
With
this
bug,
is
it
wasn't?
Every
single
lesson
was.
A
Actually
we're
getting
cleaned
up.
It's
just
that
every
once
in
a
while
one
of
the
launched
lessons
would
stick
around
in
this
state
and
of
course,
over
days
and
weeks,
that
would
slowly
grow
and
cause
problems.
Now,
normally
you
would
look
at
that
and
be
like
wow.
So
what
people
you
know,
people
still
have
their
their
lessons
around
and,
and
you
just
pay
for
the
cloud
costs
right.
Remember
what
I
said
the
kubernetes
namespaces
are
going
to
successfully
deleted,
so
the
computer
stuff
is
going
to
get
cleaned
up
for
every
lesson
without
fail.
A
That's
worked
really,
really.
Look
it's
just
the
copy
of
the
state.
This
is
syringe.
Keys
in
the
API
server
have
become
out
of
sync
because
again,
as
I
mentioned,
if
you
send
a
request
in
and
the
state
is
here,
it's
just
gonna
send
you
to
a
lesson,
because
it's
gonna
have
that
state
stored
here
and
the
value
little
an
IP
address
is
important.
You
need
to
connect
to,
because
if
the
state
is
here,
the
assumption
is
it's
lying
ready
to
be
connected
to,
because,
again
that's
the
sky
makes
these
assertions
like.
A
Is
the
lesson
live
in?
If
it
is
I'm
going
to
send
the
result
back
to
the
eki
server
to
say
yes,
it's
ready
to
go
in
this
never
gets
cleaned
up,
but
this
gets
deleted.
Then
the
user
is
going
to
be
presented
with
a
results
from
their
get
request.
This
is
your
lessons
ready
to
go,
but
it's
not,
it
doesn't
exist
and
so
for
this.
A
A
A
Just
put
it
aside
for
now,
and
yeah
I
have
something
that
I
did
that,
because
for
the
8%
of
people
who
are
affected
by
this,
they
had
a
horrible
experience
and
I
I
wanted
to
explain
this
because
I
wanted
to
want
to
make
it
clear
why
it's
8%
and
why
we're
gonna
fix
it.
So,
hopefully,
I've
described
the
problem.
I
haven't
talked
about
the
solution
yet
and
how
we
fixed
it
or
these
the
symptoms
of
the
problem.
A
A
All
right,
so
let
me
share
my
screen
again.
Switch
over
to
the
road
turn
off.
The
webcam
audio
sounds
a
little
better,
okay,
so
yeah.
So
this
is
this
is
a
problem
and,
as
you
can
see,
it's
not
like
it's
not
like
it's
a
steady
increase.
If,
like
I
said,
if
every
single
person
was
affected
by
this,
we
would
never
see
any
of
these
any
of
these
graph
lines
go
down,
meaning
it
would
only
ever
increase.
But
it's
not
that
simple.
A
We
were
seeing
decreases
when
when,
when
a
lesson
is
garbage-collected,
it
goes
back
down,
the
usage
goes
back
down
and
so
clearly
garbage
collecting
was
working
and
the
way
the
state
was
being
recorded
was
working.
Mostly
it's
just
every
once
in
a
while,
it
seemed
like
the
floor
for
these
graphs
was
raised
up
by
one
every
once
in
a
while
again
over
the
course
of
days.
A
That's
why
we
had
this
steady
growth.
It
wasn't
linear
growth,
it
wasn't
like
every
every.
You
know,
every
single
time
a
lesson
was
launched.
It
would
go
up
one
and
stay
there.
It
would,
it
would
be
every
you
know,
one
out
of
ten.
Would
would
cause
this
to
happen,
cause
this
floor
to
get
raised
and
eventually
go
up
and
then
of
course,
I
would
reset
syringe
and
and
I
would
be
like
okay,
well,
all
the
states
cleaned
up
and
then,
of
course,
and
just
kept
creeping
back
up.
A
So
that's
that's
a
problem
because
again
for
for
all
of
those
people
who
connected
would
that
have
that
state
stuck
that
stuck
in
syringe
unless
I
restart
syringe
those
people
are
gonna,
be
trying
to
connect
to
lessons
that
don't
exist
and
they're
not
gonna,
be
able
to
use
them,
they'll
be
able
to
use
them
once
and
then
they'll
be
locked
out,
basically
until
syringe
gets
restarted
so
on
a
whim.
I
was
working
on
another
fee
of
similar
feature.
A
A
A
Imagine
I
would
have
fixed
this
eventually
given
enough
time,
but
I
definitely
would
not
have
felt
the
motivation
to
fix
it
had
I
not
done
that.
I
did
this
yesterday
and
I
dropped
everything
the
moment
I
did
that,
because
every
single,
let
after
I
made
that
change
to
my
session
ID
every
single
lesson:
I
launched
every
single
one
had
this
problem,
meaning
I
would
launch
it
once
and
it
would
work
it
would
connect.
A
Excuse
me,
so
that
got
me
motivated
I
was
convinced
that
this
was
a
problem
and
so
I
started
looking
in
earnest
for
the
cause
and,
as
it
turns
out
I'll
just
sort
of
cut
to
the
chase
here.
I'm
gonna,
I'm
gonna
explain
the
the
details
behind
that.
Why?
But
as
it
turns
out,
if
you
go
to
the
sky,
the
API
server,
so
as
I
mentioned,
this
is
there's
two
components:
there's
an
API
server
in
the
scheduler.
A
If
you
go
to
the
server
go
and
you
go
to
the
lesson
or
the
result,
handlers
section
you'll
see
if
there's
a
for-loop,
that's
running
and
constantly
gathering
result
messages,
and
so
it's
this
is.
This
is
where
it
receives
messages
off
the
channel
and
for
every
message
that
the
scheduler
sends
it
decides.
Okay,
what
function
do
I
need
to
send
you
to
based
on
the
message
type.
So
if
the
message
type
is
operation
type
delete,
for
instance,
if
the
scheduler
garbage
collects
a
lesson,
the
scheduler
will
send
this
message
to
the
API
server.
A
A
Handle
result
delete.
Now.
This
is
a
really
simple
function.
It's
not
very
complicated.
It
just
runs
a
single
call
where
it
says
s
delight,
delete,
live
lesson
which
is
just
a
helper
function.
That
removes
a
live
lesson
from
that
state
entry.
So
remember,
I
mentioned:
there's
a
state
table
in
the
API
server.
This
function
is
designed
to
take
in
the
session
ID
or
the
UUID
really,
which
is
the
lesson
ID
combined
with
the
session
ID
and
and
delete
that
entry.
A
What
it
does
is
if,
if
the
session
ID
that
you
pass
in
to
it
or
the
UUID
rather,
which
is
both
the
session
ID
in
the
lab,
ID
or
less
ID,
if
it
doesn't
exist,
just
doesn't
do
anything.
If
it
does
exist,
it's
safe,
it
locks
the
it
locks.
The
state
deletes
it
and
unlocks
it
safely.
So
it's
a
it's
basically
a
easy
function.
You
just
pass
a
value
in
and
if
it
exists,
it
gets
deleted.
If
not,
it
doesn't
do
anything
just
sort
of
silently
does
whatever.
Now.
This
is
a
problem.
A
A
Oh
I
think
yeah.
Okay.
Here
we
go
yeah
okay.
So
if
we
look
at
this
function,
basically
let
me
go
back
to
the
code.
Real
quick.
What
I
wanted
to
do
was
take
off
the
dash
NS
after
the
after
the
UUID,
because
we
append
to
the
dash
and
s
in
the
cout
before
when
we
declare
kubernetes
namespaces
so
long
term,
I'm,
probably
just
gonna,
get
rid
of
that
altogether
because
it
caused
it.
A
It
just
caused
us
too
much
trouble
having
to
remove
this
before
we
pass
it
into
another
function,
but
but
normally
it
wouldn't
cause
a
problem.
It's
just
a
little
extra
work.
The
problem
came
came
because
I'm
using
the
wrong
function
in
this,
in
this
section
of
my
intention,
is
to
remove
the
the
trailing
NS
from
the
right
of
the
string
and
I
briefly
I.
Remember.
Writing
this
code.
I
briefly
perused
the
go
doc
and
I
was
like
yeah.
It
looks
like
what
I
want?
A
A
If
S
doesn't
end
with
the
suffix
and
S
is
returned
unchanged,
so
kind
of
like
my
delete
function,
it
takes
in
a
it,
takes
in
a
string
and
then
the
desired
suffix,
which
is
exactly
what
I'm
sending
to
the
other
function
right
now
and
it
simply
says:
hey:
does
this
suffix
exist
on
the
end
of
this
source
string,
if
so,
delete
it
and
return
the
result
and
if
not
return,
the
original
string?
That's
what
I
wanted,
but
instead
I
selected
trim
right.
A
Let's
take
a
look
at
what
trim
right
does
trim
right
returns,
a
slice
of
the
string
s
with
all
trailing
Unicode
code
points
contain
and
cut
set
removed.
This
is
a
very
important
distinction
to
make
if
we
go
back
into
the
code,
what
it's
saying
is
it's
going
to
look
at
the
end,
it's
going
to
look
at
the
right
of
the
string.
A
That's
not
in
that
list
of
characters,
even
if
they're
not
together,
even
if
it's,
even
if
it's
like
just
an
N
or
an
S,
it
doesn't
have
to
be
an
S,
doesn't
have
to
be
the
full
string.
It's
an
or
it's.
If
it's
any
one
of
those
individual
characters,
it
will
delete
it
and
it
will
keep
deleting
it
until
it
finds
one.
That's
not
one
of
those
original
characters.
Now,
obviously,
at
the
end
of
the
UUID
for
every
for
every
namespace,
there
is
a
ns,
so
it
will
still
delete
those
last
three
characters.
A
Just
like
that,
the
trim
suffix
would
have
deleted
it,
but
it
won't
stop
there
for
the
8%
of
cases
where
the
session
ID
ends
in
an
N
or
an
S.
Now
it
won't
have
any
hyphens
in
it
because
that's
it's
like
I
said
it's
just
alphabet.
The
alphabet
is
there
so
for
two
letters
out
of
the
alphabet
out
of
26,
which
is
1
over
13,
which
is
8%,
it
will
delete.
A
A
It
you've
basically
eaten
up
too
many
characters
in
that
session
ID
and
when
it
says,
hey
I'd
like
you
to
leave
the
session
ID
the
delete
livelesson
function
says:
there's
nothing
in
my
records
with
that
session
ID,
even
though
there's
a
session
ID
in
the
state
table
that
has
that
session,
that
those
characters,
but
a
few
other
ones
that
got
cut
off.
So,
if
you're,
if
you're
set,
if
you're
less
than
if
the
session
ID
that
was
generated
by
your
clients,
meaning
the
JavaScript
on
the
front
end
ended
in
an
N
or
an
S.
A
You
suffered
from
this
bug,
which
statistically
is
8%
of
you,
because
it's
all
randomly
generated
now
back
to
the
session
ID
that
I
used.
The
reason
that
was
so
lucky
is
because
I
said
my
session
ID
that
I
manually
typed
in
so
that
I
could
keep
track
of
my
session
visually
when
I
look
at
output
and
logs
things
like
that
was
mirrored
in
PTR
or
mirrored
in
prod
session
ending
in
an
end.
A
That
was
that
was
a
very
lucky
thing
to
have
happened,
and
it
allowed
me
very
quickly
to
figure
out
the
cause
of
the
issue
so
very
long-winded
way
of
describing
the
problem.
Hopefully,
that
was
interesting.
I
want
a
caveat.
Well,
two
things
I
want
to
say
the
fix
is
really
easy.
Simply
change
trim
right
to
trim
suffix,
that's
step.
One
step
two
is
in
the
future:
read
the
docs
Matt.
A
It's
probably
a
good
idea
shameful
that
all
of
this
was
caused
by
a
very
simple
wrong
function
and
oh
by
the
way
before
you,
this
is
another
thing.
I
would
say
you
might
say:
well,
don't
you
have
tests
to
catch
this?
Yes,
we
have
tests
that
run
this,
but
it's
only
8%
of
possible
session
IDs
and
we're
not
randomly
generating
them
in
the
tests,
we're
statically,
generating
them
with,
like
ABCDE
F,
that
kind
of
thing.
A
So,
yes,
we
have
tests
and,
yes,
we
will
start
randomly
generating
them
in
the
tests
as
well,
instead
of
just
using
static
to
find
ones.
So
we
that
we
statically
defined
a
session
ID
in
the
tests
with
a
b
c
EF,
and
so
every
time
we
did
garbage
collection,
all
the
state
got
cleaned
up
perfectly
because
it
didn't
happen
NS
at
the
end
of
the
string,
and
so
we
didn't
catch
this
in
tests.
A
So
we
will
randomly
generate
the
session
IDs
inside
of
the
inside
of
the
test
suite
in
syringe
from
now
on,
and
then
at
that
point
again
we
would
only
catch
a
problem
8%
at
a
time,
but
you
know
it
would
it
would
catch
it
now,
of
course,
we're
fixing
this
issue.
So
this
whole
eight
percent
thing
is
not
gonna.
Hopefully
there
won't
be
another
issue
lurking
somewhere
about.
You
know
that
has
the
same
nature,
but
if
it
does
I'll
own
the
word
look
for
it.
So
the
fix
is
easy
change.
A
The
trim
right
to
trim
suffix
I
do
want
to
mention
that
I
actually
already
went
back
into
the
version
0
to
3.1
branch
for
syringe,
which
is
the
latest
release
I
manually,
patched
that
and
published
a
new
version
of
the
of
the
ODA
3.1
and
pushed
it
and
started
running
production
on
it.
So
if
we
reef,
if
we
actually,
if
we
refresh
this
page-
and
let
me
actually
zoom
out
I-
wonder
how
well
let
me
go
back
out
to
partially.
A
Oh
they're
real
yeah,
so
this
is
way
more
reasonable.
This
is
what
this
looked
like
for
a
long
time
before
before
the
bug
was
created
a
few
months
ago
at
launch.
This
is
what
the
graph
looked
like
very
useful.
I
can
see
beyond
a
shadow
of
a
doubt
what
lessons
are
in
progress,
because
this
state
is
in
lockstep
with
the
kubernetes
namespaces
that
exist,
so
the
the
func
the
the
patch
has
been
applied.
This
bug
has
been
squashed
and
the
last
caveat
that
I
want
to
offer
is.
A
Hopefully
this
was
useful
in
terms
of
my
first
off
as
an
apology,
as
I
mentioned,
I
really
I'm,
sorry
that
I
just
neglected
this
issue
and
assumed
that
it
wasn't
a
problem
for
8%
of
you.
It
was
a
bad
problem
and
you
couldn't
use
that
every
Labs
and
effectively
so
for
that
I
apologize.
We
will.
We
will
try
to
be
better
at
that.
If
you
have
any
issues
in
the
future
like
this,
please
do
not
hesitate.
There's
there's
only
so
many
things
that
we
can
try
to
monitor
on
our
own.
A
We
still
require
a
lot
of
user
feedback.
Please
tweet
at
us
at
emory
labs,
go
to
our
documentation,
there's
a
community
page
that
contains
things
like
our
discord,
channel
and
our
discourse
site
all
kinds
of
all
kinds
of
ways
to.
Let
us
know
please
please,
please.
If
you
have
issues
just
just
send
us
a
heads
up.
If
we're
not
aware
of
it,
we
can't
fix
it
and
then
the
final
caveat
that
I
like
to
offer
is
just
keep
in
mind.
All
of
this
is
gonna
change
in
version.
A
1.2
Ranger
is
actually
gonna
break
up
into
little
micro
services
and
all
of
the
state
is
actually
gonna
be
managed
by
an
external
database.
We're
doing
that,
we
were
sort
of
proud
that
we
didn't
have
an
external
database
at
the
beginning.
We
still
are
because
it's
very
simple,
but
there
are
scale
there
are
known
scale
scaling
limitations
for
that
we
won't
be
able
to
scale
past
a
certain
point.
If
we
just
try
to
keep
everything
in
memory
and
then
certainly
obviously,
failures
is
failure.
Scenarios
are
there
like
we.
A
If
syringe
crashes,
we
got
to
restart
syringe,
then
of
course
clean
up
all
the
namespaces
as
well,
and
it's
just
kind
of
it's
not
fun
for
everybody.
So
we
got
a.
We
got
to
break
some
stuff
apart
as
a
result,
just
keep
in
mind
the
architecture
that
I
talked
to
you
about
here
is
going
to
be
very,
very
different
in
version
1.2,
so
don't
watch
this
video
be
like
I.
Now
know
how
syringe
works
you
do
in
its
current
state,
but
it
will
change
very
rapidly
over
the
next
few
months.
This
was
mostly
an
act.
A
A
Or
refresh
the
page
rather
but
I'm,
not
sure
it
says,
said,
what's
happening,
Matt
I'm,
not
sure
I'm
streaming
that
I'm
not
sure
whoever
asked
that
question.
Hopefully
there
was
not
a
problem
with
the
stream
while
I
was
away.
I
did
say
there
was
a
network
error,
but
that
was
on
this.
That
was
on
the
twitch
site
itself,
so
I'm
assuming
it
was
a
network
error
for
me.
Seeing
it
and
not
a
network
error
for
me,
streaming
looks
like
0.4%
dropped
frames,
it's
not
too
bad,
so
yeah
I'm,
not
sure.
Hopefully
the
stream
was
okay.
A
Hopefully
there
weren't
any
other
issues.
I
mean
a
simple
screen
share:
I'm
gonna,
look
at
Twitter!
Now
no
questions
on
Twitter,
okay!
Well,
you
know
where
to
reach
us.
If
you
have
any
future,
questions
feel
free
to
ask
like
I
said
that
in
the
Twitter
in
the
in
the
on
the
page
for
this
we
could
enter
it
out.
Live
you'll,
see
links
to
everything
you
got
our
Doc's
with
us
with
all
our
community
links.
A
You
can
go
to
our
our
our
discord
channel
for
asking
questions
were
in
there,
we're
in
the
discourse
to
the
new
discourse
site,
which
is
community
dot
network
reliability
at
edge,
not
engineering,
so
stop
by
there
and
help
us
build
that
context.
It's
a
totally
new
site,
there's
really
nothing
in
there
right
now.
So
please
put
a
bunch
of
questions
in
there
help
us
fill
it
out.
Then,
of
course
you
know
where
to
reach
us
on
twitter
at
nra,
labs,
which
is,
which
is
a
direct
line
to
to
me
and
to
Derek.
A
So
thanks
for
watching.
Hopefully,
this
was
useful
and
I
hope
there
weren't
any
stream
issues
I'll
be
really
pissed.
If
something
happened
in
the
middle
there,
because
they
went
over
a
lot
of
stuff
and-
and
if
this,
if
this
kind
of
deep
dive
is
your
thing,
I
would
love
to
hear
feedback
on
that
I
know
I
rambled
a
little
bit,
it's
sort
of
my
nature.
A
If
you
found
this
useful
or
not
useful-
and
you
just
don't
want
to
do
this
kind
of
thing
anymore,
you'd
like
to
be
a
little
more
like
screenshare
kind
of
stuff.
You
know
like
way
boarding
or
whatever
all
of
that
feedback
is,
is
good
and
valuable.
So
please,
please
just
speak
up
and
it
helped
us
improve
this.
This
is
something
we're
doing
for
the
community.
We
want
the
commute.
A
You
have
a
huge
amount
of
input,
in
fact,
the
most
input
for
what
we're
doing
in
the
future,
including
the
live
streaming,
as
well
as
the
project
itself.
So
with
that
I
will
say
goodbye
and
I'll
see
you
next
week
so
join
us
next
week
at
10
a.m.
nra,
dot
live
and
you
will
see
the
the
stream
next
next
week
and
then
feel
free
to
subscribe.
Twitch
YouTube
we're
going
to
publish
all
YouTube
all
videos
to
YouTube,
like
we
usually
do,
and
that
will
happen
later
today.
Alright,
sayonara
thanks
everybody.