►
From YouTube: 2019-10-09 Ruby SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
No,
not
a
ton,
I
mean
I
think
we
still
have
a
hair
handling
from
last
week.
I
know
you
have
a
PR
open
for
starting
the
name.
Tracers
work,
I
kind
of
glanced
over
it
briefly
last
night,
I
didn't
have
to
say
about
it,
but
I
can
give
it
a
look
over
again
I'm
kind
of
with
you,
where
I
don't
fully
like
understand.
Why
we
need
this
thing
or,
like
I,
don't
know,
I
can
kind
of
see
it
in
like
a
fantasy
feature
world.
Maybe
wanting
something
like
this,
but
not
really
in
a
practical
sense.
B
B
B
A
B
A
Don't
know
I
guess
the
only
insight
that
I
have
is
that
you
know
I
feel
like
that.
Doc
is
really
written
from
a
compiled
language
perspective
and
if
I
could
sum
that
whole
thing
about
like
in
one
sentence,
it
says
like.
If
your
application
compiles,
then
your,
but
the
SDK
should
not
throw
any
unhandled
exceptions
and
I
feel
like
if
we
were
to
adopt
that
for,
like
you
know,
Ruby
I
mean
basically
saying
like.
If,
if
you
are
past
the
right
type
of
arguments,
the
SDK
should
not
throw
an
unhandled
exception.
A
A
B
B
Which
I
don't
mean
I,
don't
know
how
I
feel
about
that
in
terms
of
the
user.
Believe
the
API,
but
the
other
thing
we
talked
about
was
some
kind
of
strict
mode
which
I
don't
think
we
would
want
to
implement
as
kind
of
a
boolean
flag
or
anything
I.
Think
it's
more
like
you.
Either
they
install
the
the
strict
mode
tracer
or
you
install
the
no
op
tracer
from
the
API
or
you
install
the
the
SDK
tracer.
A
B
I
guess
one
question
is
like:
do
you
end
up
with
like
four
variants
of
this?
So
do
you
end
up
with
three
right?
It's
like
there's,
no
op
implementation
and
there's
the
SDK
implementation,
and
then
there
do
you
want
like
a
no
ops
tricks
and
a
SDKs
stretch.
Well,
you
just
want
to
know
up
stretch
like
what's
the
purpose
of
this.
Is
it
just
testing.
A
B
So
I
wanted
in
the
relaxed
mode
like
for
the
NOAA
implementation
like
I'm
looking
at
at
event
here.
Out
of
them
has
three
raise
argument
era.
Unless
what
Evers,
before
just
returning
self
right,
a
like
a
true,
no
op
implementation
would
just
return
self
and
not
to
bother
doing
any
argument
checking
because
it
doesn't
actually
use
the
arguments.
Yeah.
A
A
A
In
general,
I
kind
of
think
this
is
what
people
want
out
of
no
op
imitations
that
really
want
to
preserve
overhead
more
than
they
want
to
use
it
to
kind
of
like
test
that
their
code
might
be
on
the
right
track
and
that's
kind
of
what
happens.
I
guess
if
we
have
our
type
checking
in
the
NOAA
implementation.
B
But
yeah,
is
it
worth
trying
to
sketch
out
different
ways
of
accomplishing
this
and
I
mean?
Maybe
we
want
to
use
mix-ins
or
something
to
actually
do
the
through
the
checking
so
that
your
your
you
know
end
by
invariance?
This
can
be
just
you
know.
Strict
SDK
tracer
includes
the
strict
tracer
and
the
SDK
tracer
I,
don't
know.
A
A
B
A
A
So
I
mean
they're
kind
of
going
with
the
interpretation
that
I
kind
of
mentioned
earlier
that
that
that
error,
spec
written
from
a
compiled
language
perspective,
is
if
my
application
compiles,
the
tracer
will
not
raise
any
exceptions.
Okay,
wait
I,
see
a
raised
type
error
right
here
in
create
span
I.
A
B
A
B
Every
few
checks
so
yeah
distributed
context
has
a
couple
of
tricks
that
are
not
tied.
Checks
are
actually
checking
for
printable
characters
and
their
exporter
just
has
some
configuration
checks
so
making
sure
that
the
max
queue
size
and
the
scheduled
delay.
Milly's
are
both
positive
yeah,
but
it
does
feel
like
they're
checking
is
pretty
likely.
B
B
B
B
A
B
Yeah
I
mean
it
suffers
from
the
same
problem
so
that
C
had
a
file
suffered
from
so
possibly
even
more
so,
just
because
of
the
dynamic
nature
of
Ruby,
but
you
end
up
having
to
look
in
a
separate
place
for
the
type
information
and
then
having
to
maintain
that
separately.
So
it's
not
kind
of
living.
B
B
B
B
A
B
B
B
Right
so
you
kind
of
want
a
true.
No
op
span
right
a
stand.
That's
just
not
going
to
it's
kind
of
pretending.
It
doesn't
exist,
but
the
finish
on
it
is
going
to
reset
the
parent
context.
If
that
makes
sense,
I
see
that
makes
sense.
The
only
concern
there
is
that,
if
you're
calling
with
span
or
in
span
for
this
you're.
A
B
A
A
So
that's
probably
fine
I
think
we
should
actually
double-check
that
this
is
the
behavior
that
that
other
people
have,
but
it
seems
reasonable.
This
does
bring
up
something
suddenly
off
topic
that
I
that's
currently
being
talked
about
and
probably
has
some
implications
for
our
API,
but
in
open
tracing
there
is
start
span
and
there
is
start
active
span
and
PE.
A
The
difference
between
those
is
that
start
active
span
will
start
a
span
and
make
it
kind
of
the
current
span
in
the
context,
whereas,
like
starts
fan,
it's
just
kind
of
like
a
off-the-books
span.
It's
kind
of
you're
totally
doing
your
context
pop
manually.
In
that
case,
and
there's
been
talk
about
this
for
open,
telemetry
and
I.
Think
people
were
saying
that
the
Java
version
starts
fan
doesn't
actually
make
it.
A
B
Yeah
in
our
current
API,
we
have
stops
fan
into
this
span,
which
is
actually
the
thing
that
sets
it
to
be
the
active
span
and
then
in
each
keeping
in
span,
which
just
combines
those
two.
So
it's
really
the
equivalent
of
stop
active
span.
The
one
odd
one
out
here
is
stop
root
span,
which
doesn't
have
a
corresponding
like
hidden
roof
span.
A
A
B
Yeah
I
was
trying
to
think.
Is
there
any
reason?
You'd
want
to
stop
an
active
span
outside
of
a
block
structure
right
so,
like
start
an
active
span
and
then
finish
it
in
a
way
that
is
not
not
block
structured
right,
I'll
current
api's,
assuming
that
it's
block
structured,
so
you
end
up
doing
like
with
span,
makes
it
active
for
a
block
and
then
restores
the
previous
active
standoff
to
its.
A
A
B
B
B
A
B
B
B
A
Named
traces
I
think,
ultimately,
the
impression
that
I
am
getting
is
that
you
know
right
now
we're
working
on
like
an
alpha
and
I
think
there
is
like
there's
still
time
to
like
raise
flags
for
things
that
we
feel
are
bad
ideas
and
I.
Don't
know
how
many
people
have
really
looked
into
this
stuff.
A
A
I
think
I
think
in
general.
That's
always
like
a
really
good
way
to
to
approach
a
thing
is
to
show
some
code,
because
I
think
people
can
understand
that
I
think
you
can
hand
wave
about
a
bunch
of
concerns
that
you
have
and
who
knows,
if
they're
actually
valid.
Until
you
see
some
code
like
even
even
when
I
have
concerns
I,
don't
know
how
valid
they
are
until
I
actually
see
them
in
action.
Yeah.
B
A
Think
there's
just
like
a
lot
of
code
being
written
right
now
in
a
short
amount
of
time
and
nobody's
using
it
yet
and
I
like
I,
think
people
are
gonna
use
it
I
think
there's
gonna
be
varying
levels
of
happiness
after
it's
used
and
probably
I
would
imagine
that
there
needs
to
be
some
kind
of
iterative
process
to
improve
things
and
make
them
a
little
bit
more
usable
and
I.
Don't
like
I
think
there
is
an
expectation
that
we
will
be
able
to
break
stuff
early
on
so.
A
B
B
B
B
B
A
Yeah,
either
way,
if
lists
of
grievances
show
up
I
think
we
should
document
them
some
way,
just
to
make
sure
that
there's
a
chance
of
addressing
them
through
the
alpha
period.
I,
don't
know,
I
really
hope
that
this
stuff
comes
out
like
being
tools
that
people
enjoy
using
and
not
tools
that
you
know
are
just
frustrating
because,
like
nobody's
gonna
use
them
yeah.
So.
A
People
have
been
using
it,
like
our
our
agents,
kind
of
make
this
all
pretty
simple
but
yeah
they
they
handle
everything.
B
A
A
A
Less
than
a
year
after
that,
we
G
aid
the
feature,
but
it's
still
not
like
a
default
turned
on
feature
for
people.
It's
kind
of
like
people
need
to
know
about
it
and
kind
of
turn
it
on
otherwise
they're,
just
kind
of
getting
the
old
classic
New
Relic
experience
where
you're
just
kind
of
seeing
stuff
on
a
per
request
basis
and
I
don't
know.
I
was
getting
like
slightly
frustrated,
was
the
pace
of
pace
of
adoption
and
just
being
able
to
actually
get
a
feature
from
conception
to
users?
A
A
It's
a
little
bit
more
complex,
I
guess
because
the
stuff
that
even
that
feature
that
I
like
implemented
it
just
works
that
new
relic
it's
just
using
new,
relic
context.
It's
not
it's
not
the
w3c
trace
context,
which
kind
of
is
of
the
stakes
and
complexity.
Just
a
little
bit
more
to
get
things
working
between
vendors.
B
Yeah
I've
seen
two
issues
here:
I
guess
one
is
that
people
are
not
comfortable
or
they're
used
to
the
new
relic
experience.
If
you
just
get
a
bunch
of
instrumentation
out
of
the
box-
and
it's
already
turned
on
for
you
and
you
don't
really
have
to
think
about
it
and
because
they
used
to
that
out
experience,
they
don't
think
about
tracing
the
way
they
do.
Logging
or
metrics,
where
it's
like.
Oh
I,
need
to
get
some
information
out
of
this
point
in
the
code.
B
So
I'm
going
to
you
know,
drop
a
counter
in
here
or
drop
a
you
know,
histogram
in
here
or
just
drop
a
log
message
here
in
the
code.
There,
though
they
think
tracing
is
owned
by
somebody
else,
and
they
don't
think
they
have
almost
permission
to
add
tracing
to
their
codebase.
They
internal
spans
effectively.
So
that
was
one
thing.
B
The
other
side
is
that
they're
like
being
able
to
actually
analyze
traces
and
do
useful
things
with
them
seems
to
be.
It
seems
to
be
a
really
high
barrier
to
entry
compared
with,
like
log
analysis
of
log
analysis.
You
know
people
will
actually
write
incredibly
complex.
Splunk
queries
to
analyze
and
extract
data
from
their
log
files
with
tracing
it's
more
like
try
to
construct
a
query
that
will
return
a
trace
and
then
look
at
the
trace
and
hope
that
it
kind
of
represents
something
interesting
and
that
you
can
get
something
useful
out
of
it.
B
B
But
those
people
are
often
the
gatekeepers
for
tracing
like
everybody's
looking
to
them
to
understand.
You
know
how
do
I
actually
use
tracing
and
I
think
the
more
there's
more
value.
Looking
at
aggregate
analysis
of
trace
theta
and
the
problem
there
is
that
the
experts
just
want.
They
are
query
interface
and
so
they're,
not
as
interested
in
the
aggregate
views
for
some
reason,
because
it
doesn't
look
like
Splunk,
I
guess
and
there,
like.
The
aggregate
view,
is
probably
more
useful
for
the
vast
majority
of
engineers
of
the
company.
B
We
have
had
stackdriver
for
a
few
years,
we've
been
sending
trace
data
to
stackdriver,
we've
experimented
with
Ken,
with
yaga,
with
like
step
earlier
this
year
and
we're
currently
using
omniscient,
which
is
like
which
was
just
acquired
by
slunk.
We
tried
signaling
effects
last
year
as
well,
so
we've
tried
a
bunch
of
different
things.
B
Hasn't
seen
the
extensive
Houston
the
company,
yet
none
of
the
tools
are
really
extensively
used.
I.
Think
a
lot
of
people
are
waiting
for
like
a
blessed
solution
and
went
willing
to
invest
the
time
to
actually
try
out
a
tool,
get
constructive
feedback.
So
we
could
evaluate,
like
all
the
tools
in
a
reasonable
fashion,
so
like
well,
I,
don't
want
to
learn
like
yet
another
tool
that
might
be
replaced
by
something
else.
In
three
months.
A
Yeah
yeah
I
mean
there.
There
are
endless
challenges,
I
guess
when
it
comes
down
to
this
and
I
think
you
probably
have
a
better
having
actually
use
all
those
tools
probably
have
a
better
idea
of
how
everybody
is
handling
those
things,
but
I
think
like
from
New
Relic
like
one
of
the
biggest
challenges
which
is
like
actually
getting
a
complete
trace.
The
sampling
is
just
such
a
that
you
know.
You're,
probably
gonna
lose
some
stats.
A
It's
just
sampling
is
really
quite
heavy
and
the
coordination
between
the
systems
it's
all
kind
of
based
off
of
a
probability
sampling.
So
it's
a
slightly
intelligent
probability
sampling
but
I'm
not
sure
how
often
it
actually
resolves.
They
know
in
a
full
trace
and
then.
A
Even
even
with
all
that
all
you're
really
getting
is
like
here's,
your
trace,
you
look
at
it
and
you
tell
us
what
happened
nah,
not
so
much
the
other
way
around
so
I
think
a
tools
I
can
get
you
a
full
trace
and
be
actually
kind
of
do
some
of
the
comparison
for
you.
Are
you
going
to
probably
be
the
most
useful
things,
but.
A
B
A
I'll
go
ahead
and
go
through
that
name,
tracers,
PR
and
and
any
comments
that
I
have
and
most
likely
just
prove
it,
and
we
can
figure
out
what
to
do
with
it.
Sooner
should
actually
be
integrated.
I
know,
is
it
Reese,
Reese
Reese,
yeah
Reese
had
been
working
on
the
open
tracing
bridge,
I
lost
some
comments,
and
it
seems
like
that.
Work
is
kind
of
stalled,
a
little
bit
so
I'm,
just
not
sure.
If
I'm
the
bottleneck
there
or
not.
B
Thursday
last
week,
where
it's
not
like,
he
was
gonna,
be
focusing
a
little
bit
more
on
spunk
and
data
dog
for
a
little
bit,
and
this
was
going
to
be
more
with
that
grab
activity.
So
I'll
poke
him
and
see
if
he
needs
anything
more
from
you
in
the
short
term
or
if
he
just
needs
a
little
bit
more
time.
A
A
Exactly
sure,
I
really
don't
know
exactly
what
my
job
is.
I
assume
it's
a
very
similar
job
to
what
I
was
doing
before,
but
like
I'll
actually
be
be
on
boarding
next
week
in
in
San
Francisco,
so
I
imagine
I
will
be
somewhat
busy
with
that
stuff.
After
that
I
imagine,
I
will
be
working
on
this
stuff.
A
lot
oh
cool.
A
A
How
involved
they
have
people
in
different
areas,
but
I
think
where
there's
need
they
will
probably
have
you
doing,
work
and
I
know
I
know
it's
obviously
quite
a
bit
of
need
in
Ruby
right
now,
evidenced
by
the
fact
that,
like
that
even
hired
contractors
in
this
area
so
I
imagine
that
that'll
be
kind
of
like
my
number
one
priority.
I
might
get
some
like
secondary
priorities
somewhere
else.