►
From YouTube: Special guest @eileencodes #30minutestomerge
Description
Eileen M. Uchitelle has been contributing to the popular web framework Ruby on Rails since 2014 and has been a maintainer on the Core team since 2017. She is passionate about making Rails scalable, resilient, and secure while striving to always make user-friendly public APIs.
A
A
B
Hey
and
welcome
to
another
episode
of
30
minutes
to
merge.
I'm
your
host
matt
aka
beard
of
edu,
and
today
I
am
going
to
be
introducing
a
super
awesome,
principal
engineer
or
yep
principal
engineer
at
github
named
eileen.
You
should
oh
man.
I
just
had
our
last
name,
and
then
I
forgot
it.
You
could
tell
there.
It
is
so
a
couple
of
things
about
my
awesome
guest
today.
So,
first
and
foremost,
she
will
be
discussing
class
variables
in
ruby.
B
C
B
All
right,
well,
we'll
see
them
in
just
a
sec,
so
just
really
quickly
just
to
introduce
you
to
everyone
on
the
internet
and
some
of
the
stuff
that
you're
into
so
you're
a
big
fan
of
hiking,
traveling
and
photography.
So
maybe
you
travel
and
then
hike
and
take
photos.
At
the
same
time.
You've
also
got
a
husky
lab
mix
named
arya
and
you're,
currently
involved
as
a
core
maintainer
of
ruby
on
rails,
open
source
project,
a
maintainer
of
rack
and
every
once
in
a
while.
A
B
A
C
C
the
core
team
for
rails
is
similar
to
ruby
core.
We
both
work
to
drive
the
future
of
our
language
or
framework
on
the
core
team.
We
plan
releases,
merge
contributions
and
build
functionality
to
improve
the
framework
in
order
to
support
applications
as
they
grow.
I
work
at
github
where
I'm
my
principal
software
engineer.
I
work
on
improving
the
rails
framework
and
ruby
language
so
that
we
can
continue
to
use
them
for
the
long
haul.
C
C
Earlier
this
year,
I
worked
with
aaron
patterson
from
shopify
on
adding
a
cache
to
class
variables
to
make
them
faster.
On
the
surface,
adding
a
cache
probably
sounds
like
a
relatively
simple
project.
However,
it
took
us
probably
about
six
months
and
a
few
different
attempts
to
accomplish
this,
because
it
turns
out
the
class
variables
are
incredibly
complex
in
ruby.
C
Today,
we're
going
to
talk
about
how
class
variables
work,
what
makes
them
complex,
why
they
were
slow
and
how
we
made
a
cache
to
improve
their
performance
after
diving
into
the
technical
details.
We'll
take
a
look
at
what
we
learned,
how
to
handle
tradeoffs
in
open
source
and,
lastly,
why
it's
so
important
that
we
all
work
to
make
improvements
to
ruby
before
we
dive
into
ruby's
internals
and
how
we
improve
performance.
Let's
first
take
a
look
at
what
a
c
bar
is
and
how
it
works.
C
C
B
C
Initializer
for
the
name
with
the
value
arya
and
owner
with
the
value
eileen
puppy,
inherits
from
dog
and
sets
the
value
of
name
to
sansa,
but
does
not
set
owner.
When
we
read
the
class
variables
in
ruby,
we
can
see
that
the
ivars
are
isolated
to
their
instance,
while
puppy
inherits
from
dog
puppy
doesn't
automatically
inherit
its
initialized
instance
variables.
We
can
see
here
that
the
name
on
dog
is
set
to
arya
owner
acetylene,
name
on
puppy
instantly
set
to
sansa
and
owner
returns.
Nil
instance.
C
Variables
are
bound
to
the
current
self,
which
in
this
case,
is
the
instance
of
the
class
dog
or
puppy.
The
instance
variables
on
dog
are
isolated
from
the
instance
variable,
so
puppy
initializing
a
dog
instance,
doesn't
change
puppy
and
initializing.
A
puppy
instance
doesn't
change
dog's
variables
if
you've
been
writing
ruby
for
a
bit
you're
likely
already
familiar
with
how
instance
variables
work
as
it's
one
of
the
first
things
that
we
learn
in
ruby.
The
inheritance
model
is
straightforward
when
it
comes
to
instance,
variables.
C
Now,
let's
see
what
happens
when
we
actually
read
these
class
variables
here
we
can
see
that
dog
owner
is
eileen
and
puppy
owner
is
also
eileen.
Remember
with
instance,
variables.
Puppy
owner
was
nil,
so
this
is
already
a
little
different,
but
not
entirely
odd.
But
let's
see
what
name
on
dog
is
wait.
Dog
name
is
set
to
sansa
shouldn't
it
be
arya
and
puppy
name
is
also
set
to
sansa.
C
How
can
that
be?
Isn't
that
a
bug?
Why
would
both
classes
return
puppies
value
for
the
name
class
variable?
Well,
this
might
look
like
a
bug,
but
it's
actually
how
class
variables
are
supposed
to
work
c.
Virus
c
bars
are
shared
among
their
descendants,
think
of
class
variables
as
global.
They
can
only
have
one
value
in
the
inheritance
chain
and
the
last
one
to
set
the
class
variable
wins.
C
So,
if
name
is
done
on
both
puppy
and
dog,
the
actual
value
of
name
will
be
stored
on
dog,
which
is
the
parent
of
puppy.
Dog
will
also
store
the
value
of
owner
when
puppy
sets
name.
Arya
will
be
overwritten
on
dog,
with
the
value
sansa,
because
the
last
class
in
the
chain
to
set
the
class
variable
wins.
Even
though
that
value
is
stored
in
the
dog
class,
the
information
for
the
class
variable
name
is
stored
in
a
hash
table,
which
is
look
which
is
accessed
on
dog,
since
dog
is
the
topmost
class.
C
C
C
Well,
the
reason
is
that
ruby
needs
to
do
this
to
handle,
what's
called
the
overtaken
c
bar
overtaking
case,
since
you
can
reopen
classes
in
ruby
or
mix
in
modules,
ruby
can't
be
sure
there
isn't
already
a
class
variable
with
the
same
key
set.
So
every
time
a
class
is
called,
ruby
has
to
check
the
entire
chain
for
an
existing
hash
table
and
if
it
finds
one
we'll
raise
an
error.
Let's
look
at
an
example:
here
we
have
a.
C
C
We
then
reopen
the
dog
class
and
define
a
name
class
variable
in
that
new
class.
When
our
code
tries
to
read
the
name
name
class
variable
on
puppy,
it
will
raise
an
error
that
says.
Class.
Variable
name
of
puppy
was
overtaken
by
dog.
What's
happening
here
is
that
when
the
name
class
variable
is
set
on
dog,
the
hash
table
that
was
stored
on
puppy
gets
overtaken
because
the
class
was
reopened.
The
class
variable
needs
to
be
stored
on
the
highest
and
set
of
the
ancestor
that
sets
the
class
variable.
C
C
C
Then
our
benchmark
reads
the
c
bar
getter
from
each
of
our
classes
to
demonstrate
that
when
the
inheritance
chain
is
deeper
class
variables
get
slower
want
to
see
the
numbers
well
in
ruby
3
at
the
time,
including
30
modules
with
a
class
variable
was
2.8
times
slower
than
including
one
module
and
including
100
modules
was
8.5
times
slower
than
including
one
module
eight
and
a
half
times
slower.
That's
a
pretty
significant
difference.
C
But
how
often
do
we
have
deep
enough
inheritance
chains
that
are
using
class
variables
when
working
on
improving
performance?
It's
important
to
realize
that
micro
benchmarks
that
show
an
improvement
might
not
translate
into
meaningful
performance
improvements
in
your
application
or
library.
So
once
we
knew
how
slow
class
variables
were,
the
question
became.
How
often
are
class
variables
used,
and
how
often
is
the
inheritance
chain
deep
enough
on
a
class
very
deep
enough
to
make
a
difference
on
class
variable
performance?
C
In
order
to
address
this
aaron
patterson
and
I
set
out
to
build
a
cache
for
class
variables
when
aaron
and
I
first
started
working
on
this,
we
didn't
realize
how
complex
and
nuanced
class
variables
were.
So
it
took
us
a
very
long
time
to
figure
out
a
cash
strategy
that
worked
while
it
was
while
it
was
a
difficult
project
that
took
us
about
six
months.
We
wanted
to
pursue
it
because
we
knew
that
class
variables
were
slow
and
that
their
slowness
affected
every
single
application.
C
C
This
is
an
opportunity
to
improve
the
performance
of
every
single
codebase
that
uses
class
variables,
as
we
saw
earlier,
class
variables
are
stored
in
a
hash
table
on
the
highest
class
that
set
the
c
bar.
So
it
made
sense
for
us
to
store
a
hash
table
for
the
cache
next
to
the
class
variable
hash
table
as
well.
Then
we
could
lean
on
all
of
the
existing
class
variable
code
and
handle
creating
and
busting
the
cache.
Alongside
it.
C
The
cache
hash
table
holds
the
class
variable
name
which
points
to
an
inline
cache.
The
inline
cache
has
a
pointer
to
dog
that
tracks
the
value
attracts
a
value
called
globalc
bar
state.
The
cache
is
stored
in
the
topmost
class,
so
when
puppy
needs
to
find
its
class
variable,
the
cache
the
cache
will
be
created
by
dog.
The
first
time
we
read
or
write
a
class
variable,
ruby
will
still
walk
the
all
the
way
up
the
inheritance
chain.
Looking
for
the
topmost
class,
that
has
a
setter
for
the
name
class
variable.
C
C
For
example,
we
call
puppy
name
in
our
application.
Ruby
will
find
the
global
c
var
state
from
the
cache
and
compare
it
to
the
get
global
c
var
state
value
if
they
match.
That
means
that
we've
seen
this
class
variable
before
the
cache
then
returns
the
dob
class,
which
informs
ruby
where
to
look
up
the
class
variable
hash
table,
and
then
the
value
sansa
will
be
returned
from
the
dog's
clap
dog
classes
hash
table.
C
This
allows
ruby
to
entirely
skip
walking
up
the
inheritance
tree
once
the
cache
is
created
in
the
case
of
overtaken
global
cevar
state
would
have
a
different
value
than
get
global,
cbar
state
and
the
cash
would
be
ignored
if
the
values
are
different.
Ruby
will
walk
the
in
the
ancestor
chain
to
build
a
new
cache
and
that's
basically
it
as
you
can
see.
The
overall
cash
ended
up
with
a
relatively
simple
design.
C
C
C
C
We
that
showed
that
including
a
hundred
modules
that
read
a
c
bar
was
eight
and
a
half
times
slower
than
including
one
module
when
running
the
same
benchmark
on
our
branch
that
added
the
cash
we
saw
that
we
completely
eliminated
the
progressive
growth
that
occurred
as
more
classes
were
added
to
the
inheritance
chain
now,
including
one
module
with
a
class
variable
that
has
the
same
performance.
Clearly,
one
module
with
a
class
variable
has
the
same
performance
as
including
100
modules,
with
a
class
variable.
C
It's
not
the
same
same
as
running
it
in
our
application
on
production
hosts,
but
it
can
tell
us
a
lot
more
than
a
micro
benchmark
with
rails
bench.
We
saw
that
rail
61
without
a
class
variable
cache
could
perform
615
requests
per
second,
then
we
did
the
same
measurement
using
our
class
variable
cache
branch,
and
we
found
that
we
could
perform
6567
requests
per
second,
with
the
cache
we
get
42
more
requests
per
second,
which
works
out
to
a
little
more
than
six
percent
improvement
in
request
times.
C
The
complexity
of
class
variable
inheritance
was
why
this
change
was
so
difficult
when
we
finally
got
the
bug
fixed
test
passing
diagrams
made,
and
we
were
confident
in
our
changes,
it
was
time
to
open
the
poll
request
and
a
feature
request
issue.
After
some
discussion
on
the
issue,
I
started
to
get
nervous
because
it
became
clear.
The
ruby
team
wasn't
sure
they
wanted
to
merge
the
feature.
C
Eventually,
we
did
get
it
merged,
but
I
want
to
take
some
time
to
dive
into
what
concerns
the
core
team
had
and
how
we
navigated
negotiating
getting
this
change
merged.
Fundamentally,
every
change
in
open
source
has
trade-offs.
Actually,
let's
be
real.
Every
change
in
code
everywhere
has
trade-offs.
I'm
sure
you've
experienced
this
at
work.
In
your
own
job,
trying
to
decide
whether
it's
worth
the
risk
of
fixing
that
technical
debt
or
just
ignore
it
and
build
your
feature,
maybe
you
opt
to
add
complexity,
because
you
think
you'll
get
back
to
it
later
and
fix
it.
C
But
we
all
know
you
never
do.
Maybe
you
decide
to
not
remove
that
out
of
date?
Gem,
because
you
don't
have
time.
Maybe
you
write
a
monkey
patch
in
your
application
instead
of
sending
an
upstream
hatch,
because
you
don't
want
to
wait
for
a
release
every
day
we
weigh
trade-offs
regarding
complexity
against
one
another,
when
making
a
change
to
our
code
base
open
source
maintainers
need
to
weigh
trade-offs,
too,
of
whether
a
change
is
worth
it
or
not.
To
aaron
and
I
adding
a
cash
seems
like
a
clear
win.
C
bars
are
slow.
C
What
trade-offs
could
there
possibly
be
when
we
fix
the
performance
issue
in
ruby
when
you
have
a
feature
as
complex
that
feature
that
is
as
complex
as
class
variables?
Any
change,
even
a
small
change,
has
trade-offs
that
maintainers
need
to
consider
the
first
trade-off.
The
core
team
was
concerned
about
was
that
our
change,
increased
complexity
of
class
variables,
as
you
saw
today
c
bars,
are
already
so
complex.
So
by
adding
something
even
as
simple
as
a
cache,
we
made
them
even
more
complex.
In
addition
to
the
inheritance
and
overtaking
complexity.
C
We've
now
introduced
the
complexity
of
creating
updating
and
busting
an
inline
cache
when
the
cache
was
done.
It
seemed
simple
to
us,
but
the
process
to
get
there
demonstrated
that
it's
not
as
straightforward
as
it
looked
to
accomplish,
adding
a
cache.
We
had
to
add
a
second
hash
table
track.
Every
time
we
write
a
new
cvar
and
ensure
that
the
cache
behave
properly
when
class
variables
are
overtaken
class.
Variable
behavior
around
inheritance
means
that
there's
a
lot
of
places.
We
could
get
it
wrong.
C
C
The
concern
was
that
we
made
class
variables
faster
than
we
accidentally
encourage
applications
and
libraries
to
use
them
more.
Since
most
ruby
programmers
aren't
aware
of
the
intricacies
and
complexity
of
class.
Variable
behavior,
encouraging
more
usage,
might
lead
to
bug
reports
on
the
issues
tracker
or
other
efforts
to
make
them
better
if
we
keep
making
them
more
useful,
they're
a
lot
harder
to
deprecate
in
the
future.
C
Lastly,
by
adding
a
cache
to
class
variables,
we
also
increase
the
maintenance
burden
for
the
core
team.
What
if
a
new
case
for
inheritance
is
added,
and
we
miss
clearing
the
cache?
What
if
there's
a
bug
in
the
existing
code
and
now
we're
hiding
it
whatever
caching
the
wrong
information
in
a
specialized
edge
case?
C
What
are
the
risks
of
this
change
to
existing
applications
for
perspective?
Consider
your
own
application
network
or
a
library
you
maintain.
Is
there
a
feature
or
part
of
the
code
base?
You
know
better
than
anyone
else
what?
If
someone
came
along
and
changed
that
code?
How
would
you
feel
if
you
knew
it
was
probably
a
net
gain,
but
now
you're
worried
that
you
no
longer
understand
all
of
the
moving
parts.
C
I've
experienced
this
a
lot
as
a
rails
maintainer.
I
want
contributions,
but
I
don't
want
to
introduce
changes.
I
don't
understand
because
once
it's
merged,
I'm
now
responsible
for
that
new
code,
I
completely
understood
where
their
core
team
was
coming
from.
Even
though
I
felt
like
adding
a
cash
was
a
net
win
once
we
understood
the
concerns
of
the
core
team,
we
needed
to
convince
them
that
this
change
was
worth
it
negotiating.
Whether
a
change
should
be
emerged
is
a
tough
thing
to
do,
but
it's
an
important
skill
for
contributing
to
open
source.
C
In
the
case
of
configurations,
it
is
a
global
and
there
can
only
be
one
value
using
an
instance.
Variable
would
break
that
contract
that
activerecord
relies
on.
In
addition,
the
benchmarks
we
provided
showed
real-world
impact
applications.
It
wouldn't
have
been
convincing
if
all
we
had
were
micro
benchmarks
that
showed
an
improvement
to
class
variables
in
isolation.
C
By
doing
the
work
to
get
a
benchmark
that
showed
improvements
to
request
times
and
rails,
we
were
able
to
show
that
the
cash
was
effective
in
making
requests
times
six
to
seven
percent
faster.
The
benchmarks
are
compelling
because
they
demonstrate
real-world
improvements,
making
the
complexity
worth
taking
on.
C
Lastly,
what
are
the
net
benefits
of
making
this
type
of
change
to
ruby
is
that
applications
can
get
a
performance
boost
without
changing
their
code?
All
they
need
to
do
is
upgrade.
This
is
compelling
because,
if
ruby
is
slower,
thus
applications
upgrade,
but
if
ruby
is
faster,
more
applications
upgrade
also
it's
more
enticing
to
upgrade.
If
you
don't
need
to
change
your
application
to
get
free
performance
improvements.
C
With
these
three
points,
we
can
convinced
mats
and
the
ruby
core
team
that
it
was
worth
trying.
The
class
variable
cache
in
ruby
and
it
was
merged
in
june,
it'll
be
released
in
3-1,
which
the
preview
is
already
out.
If
you
want
to
try
it
negotiation,
isn't
about
being
agreeable
or
acquiescing
to
what
a
maintainer
wants.
It's
about
understanding
the
concerns
and
working
to
demonstrate
the
value
of
your
change
in
a
negotiation,
take
time
to
understand
the
concerns
of
the
maintainers,
because
they
end
up
maintaining
the
code.
C
Take
time
to
consider
how
you
can
make
the
change
less
risky
or
complex.
Think
about
how
you
can
prove
the
changes
in
net
gain
that
offsets
risk
be
willing
to
do
the
work
to
advocate
for
your
change
and
provide
evidence
that
any
added
maintenance
or
complexity
is
worth
the
cost
if
you're
rubyist.
I
hope
that
learning
about
our
journey
to
add
a
cache
to
class
variables
has
inspired
you
to
contribute
to
ruby
in
the
future.
C
I
want
us
to
contribute
more
to
ruby,
because
this
is
how
we
maintain
a
healthy
ecosystem
for
years
to
come.
If
you're
at
all
worried
about
ruby
becoming
less
popular
or
dying,
then
the
best
way
to
prevent
that
is
for
us,
everyone
here
to
start
contributing
to
ruby,
let's
work
on
making
ruby
better
so
that
applications
can
not
only
run
on
ruby
but
thrive
on
ruby
as
well.
C
The
first
thing
that
you
can
do
is
learn
c,
I'm
not
a
c
expert.
So,
while
I
was
writing
this
talk,
I
had
to
go
back
and
reread
the
cache
like
800
times,
to
figure
out
how
it
worked.
In
this
case.
I
wouldn't
even
really
call
myself
a
beginner
c
programmer,
I'm
more
like
a
c
tourist
visiting
it.
When
I
want
to
work
on
making
ruby
better.
C
However,
learning
c
is
going
to
make
contributing
to
ruby
a
lot
easier,
because
well,
ruby
is
written
in
c,
so,
the
more
c
you
know
the
easier
it
will
be
to
understand
those
internals,
in
addition
to
learning
c
you're
going
to
want
to
get
an
understanding
of
of
how
ruby
is
designed
for
that.
I
recommend
reading
ruby
under
a
microscope
by
patch
honestly
this
book
dives
into
the
design
of
ruby's,
parser
and
bm
and
other
areas
that
make
the
language
unique.
C
While
the
book
was
written
in
2013
and
some
of
ruby's
internals
have
changed
since
then.
It's
still
an
invaluable
resource
for
understanding
how
ruby
was
designed
and
the
fastest
way
to
start
contributing
to
ruby
is
to
start
contributing.
That
sounds
kind
of
simplistic,
but
it's
also
true.
You
can't
contribute
to
ruby
by
thinking
about
it.
I
get
that
making
changes
to
a
programming
language
used
by
hundreds
of
thousands
of
applications
can
be
overwhelming,
but
you
don't
need
to
go,
implement
a
new
jit
to
contribute
to
ruby.
C
You
can
make
small
changes
like
documentation,
updates,
fixing
bugs
on
the
issues
tracker
and
benchmarking,
improving
performance.
I've
heard
people
say
like
ruby's
slow
because
it's
ruby,
but
if
there's
something
that's
slow
about
ruby,
it's
because
no
one
tried
making
it
faster.
Yet
the
person
that
can
make
it
faster
might
just
be
you.
C
So
I
hope
this
talk
has
inspired
you
to
contribute
to
ruby
and
look
for
ways
that
you
can
make
the
language
better
when
we
contribute
to
ruby
and
make
the
language
faster,
cleaner
or
add,
features
we're
making
ruby
better
for
everyone,
but
we're
also
making
ruby
better
for
ourselves
every
change.
The
ruby
is
for
everyone
in
this
room
for
everyone
at
home.
For
you
and
for
me
contributing
to
ruby,
isn't
charity
and
it's
not
a
donation
to
the
community.
I
don't
do
it
for
fun.
C
Well,
it
is
fun,
but
I
contribute
to
ruby
so
that
I
can
continue
to
thrive
as
a
language.
I
do
it
so
github
can
run
on
ruby
for
five
ten
fifteen
hundred
years.
I
do
it
so
shopify
can
run
on
a
ruby
for
a
hundred
years.
I
do
it
so
your
application
and
your
application
and
your
application
can
run
on
ruby
for
100
years,
and
I
want
you
to
contribute
to
ruby
for
the
same
reason,
to
ensure
that
it
can
support
and
scale
and
grow
our
applications
for
years
to
come.
C
B
Wow
that
was
like
a
huge,
deep
dive
too.
As
someone
who
doesn't
really
mess
with
ruby,
I
learned
a
whole
bunch,
so
I've
got
a
couple
comments
that
I
want
to
throw
at
throw
your
way.
It
seems
towards
the
end
of
your
presentation.
Cedric,
on
youtube,
threw
in
a
bunch
of
comments,
so
one
of
them
being
that
they've
they
learned
that
the
difference
between
class
variables
in
python
and
ruby
is
that
in
python
they
can
class
variables
can
be
changed
by
subclasses
while
in
ruby
they
can't.
C
Well,
they
can
be
changed
by
cl
by
subclasses,
but
it's
still
a
global
so
like.
If
the
subclass
changes
it
then
all
of
them
change,
so
they
can't
have
different
values,
which
is
like
what
I
showed
with
puppy
and
dog.
So
puppy
inherits
from
dog
puppies,
a
subclass
of
dog
change,
the
value
of
name
to
sansa,
but
dog
can't
have
a
different
value.
They
have
they
end
up
with
the
same
value,
because
there's
only
one
place
to
store
the
class
variable,
but
I'm
not
familiar
enough
with
python
to
tell
you
what
the
difference
is.
B
C
B
Because,
okay,
yeah
yeah
that
definitely
makes
sense
and
no
worries
cedric,
I
see
you
just
said
sorry,
not
a
problem.
It's
always
good
to
get
comments
and
then
have
people
have
the
opportunity
to
you
know
kind
of
talk
to
it
and
then
I
guess
they
started
looking
into
spelt
to
for
speeding.
Something
up.
Is
that?
Are
you
familiar
with
svelte
at
all?
If
not.
C
B
C
I'm
not
on
the
ruby
core
team,
so
I
personally
don't
get
to
make
decisions
about
that.
I
am
not
a
fan
of
static
typing,
so
there
is
some
work
on
static
typing.
I
don't
know
how
far
along
it
is,
and
I'm
pretty
sure
it's
optional
in
ruby,
but
I
don't
I
haven't
actually
played
with
it,
because
I
don't
like
static
timing.
B
A
B
Again,
for
showing
up
that
was
awesome.
I
really
appreciate
your
time
and
I
hope
hopefully,
everyone
else
does
as
well.
If
people
are
celebrating
the
thanksgiving
holiday,
I
hope
you
have
a
great
thanksgiving
holiday
and
yeah
thanks
again
for
joining
us
on
a
30
minutes
to
merge,
we'll
see
you
next
month
and
yeah
have
a
wonderful
one
and
have
a
great.