►
Description
Discussion for Chapter 3: How Ruby Executes Your Code and Chapter 4: Control Structures and Method Dispatch
B
A
B
I
think
the
most
interesting
thing
is
seeing
how
these
different
you
know
like
the
conditionals
and
the
blocks
are
sort
of
built.
Out
of
these
very
simple,
I
forget
what
they're
called
very
simple
pieces,
like
the.
I
think
it
was
just
like
something
unless
and
a
jump
makes
like
all
of
that
stuff
work.
B
A
I
think
right
where
I'm
at
is
where
they're
talking
about
how,
like
the
the
for
loops,
are
really
just
syntactic
trigger
on
each
loops
and
like
there's
no
real
for
loop
structure,
and
then
it
just
got
past
like
how
break
and
return
are
basically
the
same
thing
they're,
just
both
a
throw,
but
one
has
a
one
and
one
as
a
two
as
an
argument.
It's
like
whoa.
A
B
B
Yeah,
I
also
like
I
mean
I
feel
like
this
chapter.
Things
started
to
get
more
interesting
like
before.
I
was
just
kind
of
saying.
Like
you
know,
this
is
what
things
look
like
under
the
hood.
This
whole
yard
thing
what's
going
on
with
that,
and
what
does
it
look
like?
How
do
you
read
it
and
now
we're
kind
of
seeing
like
how
do
you
build
ruby
out
of
those
pieces.
A
Yeah,
I'm
starting
to
lose
track
of
how
many
side
tables
there
are
now.
Yes,
I
feel
like
there's
one
for
for
something
else,
maybe
for
locals,
like
all
the
different
variables
that
could
be
assigned
yeah
and
then
and
one
for
globals
and
one
for
and
now
one
for
like
these.
What
are
they
called
catch.
B
A
Yeah
for
sure,
oh
man,
that's
a
good
point
like
yeah
using
ruby
is
so
nice.
I
can't
imagine
going
and
like
all
the
under
hood,
all
the
under
the
hood
stuff
needed
to
make
it
work
like
for
me,
I'm
not
really
like
a
car
guy
or
anything.
So
it's
a
very
good
analogy
for
me
in
that
way.
It's
like.
I
appreciate
my
car
and
like
driving
it
and
all
the
things.
B
A
B
A
Totally
yeah
I'm
coming
from
like
a
graphic
design
background,
so
like
no
computer
science,
like
basics
at
all,
so
yeah,
but
I
mean
I've
been
doing
ruby
and
ruby
on
rails
for
like
10
years
or
so,
but
still
it's
just
like.
I
live
in
ruby
or
rails
or
javascript
like
this
is
where
I
live.
I
don't
go
poking
around
in
these
other
domains
where
it's
like.
Suddenly,
you've
got
garbage
collection
and
memory
pointers
and
who
knows,
what's
going
on
it,
just
kind
of
explodes
really
fast
yeah.
B
For
me,
I've
even
been
amazed
just
that
git
lab
I've
never
really
had
to
think
about
things
like
like
execution
times,
and
you
know
sort
of
optimizing
database
queries
and
things
like
that,
it's
usually
just
like
whatever
rails
does,
is
fine,
whereas
here
we
actually
pay
a
lot
closer
attention
to
that.
So
that's
been
kind
of
eye-opening
to
to
see
a
little
bit
closer.
How
like
active
record
works
even
within
rails,
right.
A
A
Yeah
for
sure
same
here,
yeah
I've
never
worked
in
any
place
that
had
like
all
of
its
own
extra
things.
On
top
of
like
the
way
rails
does
stuff
by
default.
Just
to
like
manage
some
of
those
complexities
of
making
sure
your
stuff
yeah
can
operate
quickly
at
scale,
which
you
know
like
that's
kind
of
the
get
labs
thing
is
like
yeah
got
all
these
people
relying
on
your
software.
A
B
Yeah
as
well
as
they
were
yeah,
I
definitely
appreciate
the
infrastructure
we
have
built
up,
because
that's
the
the
side
of
things
that
smaller
companies
that
I've
never
enjoyed
working
in
like
trying
to
figure
out.
All
of
that,
you
know
setting
up
servers
and
maintaining
them
and
setting
up
all
that
sort
of
all
those
processes
that
just
make
things
kind
of
automatic
that
we
have
take
it
for
granted.
A
A
A
So
chapter
three
ended
up
being
january,
12
or
december
15.
Either
way
there
was
nobody
present,
but
me
so
so
so
yeah
I
put
in
one
here
that
was
about
four
long-lived
processes
such
as
loops
with
a
large
number
of
iterations,
ruby,
1.9
and
2.0,
or
about
4.25
times
faster
than
I
think
it
would
be.
1.86
is
what
the
book
would
say:
yeah.
A
A
B
So
I
mean
I
can
I
can
in
gitlab,
so
we
have
a
package
registry,
for
you
know,
npm
packages
rubygems
is
coming
up
soon
and
things
like
that.
So
we
have
a
php
registry
using
composer
which
I'm
not
too
familiar
with,
but
similar
to
if
you're
familiar
with
with
ruby
gems
there's
an
index
file
that
gets
thrown
around
that
just
contains
like
an
index
of
every
single
package
within
that
registry.
B
So
when
you
make
a
call
to
like
rubygems.org
to
to
do
a
gem
install,
it
will
download
this
index
file
that
has
it's
like
a
12
megabyte
file.
It's
kind
of
large
and
so
composer
for
php
does
the
same
thing
and
we
set
things
up
where
you
can
only
upload
a
package
to
a
given
project
or
you
can
access
them
via
the
group.
I
guess,
and
so
we
thought
all
right
well
worst
case
there
will
be
a
couple
thousand
packages.
B
It
has
to
loop
over
a
couple
thousand
packages
to
create
this
index,
but
that's
not
too
bad.
You
know
a
couple
thousand
database
records
that's
fast,
but
we've
had
users
that
have
had
you
know
like
a
hundred
thousand
and
so
that
suddenly
slows
things
down
to
a
halt
when
they
attempt
to
like
install
a
package
so
we're
trying
to
figure
out.
How
can
we
like
break
that
down
and
make
that
go
faster
or
not
have
to
iterate
through
everything
everything
every
time.
B
B
B
A
B
A
Yeah,
even
if
we're
just
looping
over
you
know
a
file
that
has
like
10
000
lines
in
it
or
something
or
even
a
number
of
files
with
you
know
thousands
of
lines,
each
like
you're
doing
some
operation
with
all
those
lines
that
can
add
up
pretty
fast
yeah
yeah.
That
makes
sense
packages.
So
people
have
a
hundred
thousand
packages.
B
Common
for
people
to
set
up
with
every
push
or
every
commit
it
auto
their
ci
will
build
a
new
package
and
publish
it
similar
to
how
like
we
have
on
our
on
the
gitlab
ci.
It
builds
a
new
docker
image.
Every
single,
like
I
don't
remember,
commit
or
push
or
something
sure,
so
we
just
fill
it
up
with
all
that
people
do
the
same
pattern
with
packages
for
various
reasons.
Gotcha.
B
A
Oh
man,
I
can
imagine
oh
wow
yeah,
that's
a
good
point.
I
mean
even
even
going
from
you
know,
small
startups,
where
I
worked
to
get
lavish
like
the
whole.
The
whole
idea
of
what
rails
is
and
what
it
can
do
is
sort
of
shifted
and
changed
a
bunch
for
me.
So
like
yeah,
I
can
imagine
other
places
with
whatever
php
or
python
or
whatever
packages
they
got
going
on
like
yeah.
B
A
A
Nanoseconds
or
something
but
yeah
yeah,
that's
interesting.
That
makes
good
sense.
Actually,
because
I
was
yeah,
I
was
noticing
the
whole
like
the
example
at
the
very
beginning
was
using
like
you
know,
if
n
is
less
than
10,
or
something
like
that,
so
in
the
yar
of
instructions
had
like
this
opt
underscore
lt,
which
was
optimized
less
than
so.
A
B
A
B
B
A
A
B
A
B
Yeah,
it
is
interesting
dealing
with
the
polymorphism,
because
it's
one
of
those
things
where
I
think
ruby
developers
do
deal
with
like
single
table
inheritance
and
polymorphism
a
lot
and
so
coming
together
and
being
told
like
no,
you
shouldn't
do
that
yeah.
It's
like
well,
wait
a
minute,
then
what
should
I
do.
A
B
B
Oh
just
practical
object,
oriented
design
in
ruby
yeah.
I
think
that
one
was
like.
I
read
through
that
at
one
point
like
already
writing
ruby
for
a
long
time,
and
it
was
just
kind
of
this
view
of
like
you're
doing
object-oriented
code.
Here's
how
you
should
actually
think
about
it
when
you're
writing
it
and
they
go
through
the
examples
of
like
you
know:
here's
how
to
do
inheritance.
Here's
why
you
shouldn't
do
inheritance
and
and
how
to
write
it
in
a
better
way,
using
modules
and
object,
composition.
A
Yeah
I
need
to
brush
up
on
all
of
my
object-oriented
design
patterns
and
stuff.
That's
something
that,
like
being
somewhat
self-taught
and
just
sort
of
like
learning
new
things
as
I
needed
them
for
work
it
it.
Never
really.
You
know
it
wasn't
like
this.
Oh
I'm
gonna
learn
these
design
patterns
and
structures
and
then
like
understand
how
to
use
them
in
different
ways.
It's
more
like
I'm
gonna
copy
what
this
person
did
or
copy
what
that
person
did,
because
it
makes
good
sense.