►
From YouTube: 2021-12-21 meeting
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
C
C
C
D
C
I
did
that
for
a
long
time
I
I
should
have
given
up
way
way
before
I
actually
learned
how
to
snowboard
properly
right
but
yeah.
It's
like
I
started
snowboarding
back
in
college,
but
I
lived
in
chicago
so
like
it's
pretty
flat
and
not
a
lot
of
places
to
go,
so
I
would
end
up
going
snowboarding
like
once
or
twice.
You
know
every
two
or
three
years,
and
it
was
just
like
not
enough
to
get
enough
repetition
to
figure
things
out.
So
you
just
like
go
tumble
down
the
mountain
and
ask
yourself
why?
D
But
yeah
I
live
in
the
prairies
right,
so
there's
like
throughout
my
life,
there's
been
a
few
opportunities
where
I
can
go
to
a
proper,
proper
hill
or
mountain
or
whatever.
You
want
to
call
it
and
go,
and
it's
like
seems
like
it'd,
be
fun,
but
you
just
never
get
enough
practice
in
to
get
beyond
like
oh
I'm
carving.
This
is
awesome.
This
is
awesome.
I
caught
an
edge
and
wham.
You
know,
thank
god,
for
helmets.
C
Yeah,
but
for
some
reason
I
kept
going
because
I
like
the
environment-
and
I
just
you
know
it's
a
good
reason
to
get
outdoors
and
when
I
was
living
in
portland,
I
got
invited
to
go
snowboarding.
I
think
like
three
times
in,
like
you
know
a
month
and
a
half
or
something,
and
that
was
enough
for
me
to
actually
on
that
third
time
it
was
something
clicked
and
I
started
buying
a
season
pass
to
the
mountain
there.
D
I
know
what
you
mean
about
the
environment,
though
it's
like
it's
fun,
it's
like
a
fun
little,
it's
a
fun
thing
to
do.
That's
why
I'm
trying
to
hopefully
get
the
opportunity
I
want
to.
I
would
like
to
learn
how
to
downhill.
Skis.
Try
my
luck
at
going
forward
instead
of
sideways
and
see.
If
I
have
a
better
experience,
going
down
a
hill
and
try
to
stay
on
my
feet
instead
of
my
head
or
my
butt.
C
Yeah,
I
considered
skiing
a
couple
times
because
I
don't
know
I
grew
up
playing
ice
hockey.
So,
like
skating
is
pretty
natural,
I
feel
like
just
skis
seem
like
it
seems
like
it
all
makes
sense.
Yes,
however,
the
thing
that
prevented
me
was
like
it
seems
like
you,
can
crash
a
little
bit
more
epically
on
skis,
like
snowboarding
you're
kind
of
like
all
one
unit
like
nothing
can
like
split
apart
or
like.
D
A
C
Let's
I
can
hop
in,
and
I
think
this
would
be
quick.
There
was
only
one
item
on
the
agenda
and
that
was.
C
C
What
is
this
name
field
in
in
the
log
data
model
all
about,
and
it
isn't
really
necessary
and
first
it
kind
of
started
off
by
saying
it
is
kind
of
necessary.
This
is
this
ends
up
correlating
to
the
event
name
for,
like
a
span
event,
a
fan
event
can
translate
to
a
log,
but
then
the
discussion
started
talking
about.
It
would
be
quite
useful
for
modeling
rum
events
and
this
kind
of
cascaded
into
this
whole
question
about
about
what
currently
exists
in
the
data
model.
C
We
have,
you
know
spans
logs,
that
are
emerging
and
then
metrics
and
whether
or
not
in
the
real
user
monitoring
space,
whether
or
not
that
is
sufficient
for
modeling
realm
events-
and
I
don't
know
the
discussion
went
all
over
the
place.
Saying
that
you
know
logs
logs
are
so
generic.
You
should
probably
be
able
to
actually
like
model
anything
with
them,
and
people
brought
up
the
point
of
like
well,
then
why
do
we
even
have
spans
if
logs
are
so
flexible?
C
Why
wouldn't
we
just
record
them
all
as
as
long
events-
and
I
think
one
of
the
points
that
was
made
is
that
you
know
logs
are
a
little
bit
too
flexible?
They
don't
really
have
any
kind
of
causality
built
into
the
model.
C
So,
having
like
a
parent-child
relationship
like
this
caused
this,
whereas
fans
definitely
have
that,
and
I
think
ultimately,
what
where
this
discussion
kind
of
ended
is
that
for
at
least
real
user
monitoring
and
any
kind
of
like
event
or
mini
events,
you
would
be
able
to
like
do
a
pretty
good
job
with
zero
duration
spans.
That's
really
like
the
one
thing
that
makes
them
not
a
great
fit
for
traces,
but
it
turns
out
that
in
the
trace
data
model
you
you
can't
have
a
degradation
span
as
far
as
otlp
is
concerned.
C
So
that's
good
news.
The
apis
are
not
super
ergonomic.
I
guess
for
recording
a
zero
duration
span,
so
in
general
I
feel
like
the
rom
folks
felt
okay
with
deodoration
spans,
but
maybe
the
idea
would
be
one
of
two
things:
either
make
the
apis.
The
tracing
api
is
a
little
bit
nicer
for
recording
geoduration
spans.
C
I
think
the
discussion
there
was
generally
like.
Would
this
be
useful
in
all
situations?
Is
this
something
that
we
really
want
to
want
to
add
to
all
sdks?
C
So
it
kind
of
brought
up
this
point
that.
C
C
Maybe
for
rum
they
might
want
to
consider
something
a
little
bit
more
streamlined
that
just
kind
of
like
you
know,
introduces
its
its
own
api.
That
makes
sense
for
rum
that
outputs-
you
know
otlp,
underneath
but
kind
of,
is
tailored
towards
towards
that
use
case,
because
it
does
seem
to
be
one
where
kind
of
go
to
great
lengths
to
kind
of
minimize
the
the
size
of
things
for
performance
reasons.
C
D
I
see
it
like
I've
seen
it
in
a
few
places.
It
happens.
It's
like
they're,
basically
just
they
don't
like
with
our
old
instrumentation
gem
that
we
were
using,
didn't,
have
the
concept
of
an
event,
so
you'd
see
people
just
make
like
a
span
and
immediately
finish
it
just
to
like
record
that
this
thing
occurred
right,
they're,
not
actually
trying
to
capture
the
duration
there,
so
that
kind
of
makes
sense.
When
I
see
that
now,
I'm
more
like
as
I'm
migrating,
these
apps
there's
like
a
couple
left
really
it's
like.
D
Well,
maybe
this
is
just
an
event
within
the
context
of
its
parents
fan
and
it
fits
better
like
actually
just
recording
an
event,
but
I
go
back
and
forth
because
I
I
get
the
desire
for
it
like
that
zero
duration
span.
You
just
like
want
to
basically
log
something
right,
but
I
don't
see
why
we
like
what
maybe
I
missed
it
like.
What's
the
reason
for
not
using
an
actual
event
in
that
instance
like
what's
their
argument
against
it,.
C
C
D
That
makes
sense
in
that
context
like
that
makes
sense
because
it's
like
well,
I
don't
know
if
I
have
a
parent's
fan
here
like
you
just
clicked
on
a
button,
and
I
just
want
to
know
that
you
clicked
on
this
button.
So
let
me
record
that
a
click
occurred
yeah.
I
don't
know
it
doesn't
seem
unreasonable
to
have
like
this
zero
duration
span,
where
it's
like
user
clicked.
D
D
G
It's
a
it's
and
I
guess
if
it
doesn't
have
a
trace
parent,
it's
a
single
span,
trace
right
and
it
records
the
something
happened
and
unless
you
give
it
some
more
context,
it's
hard
to
correlate
it
with
anything
else.
But
if
you
want
to
record
the
event
happened:
okay,.
D
E
The
the
way
I've
seen
this
work
at
datadog,
which
has
a
ga
product
in
rom
now
is
they
originally
took
the
approach
of
shoving
a
tracing
sdk
into
the
browser,
and
I
don't
think
there
was
a
single
customer
who
was
able
to
deploy
it
in
production.
E
Without
it,
you
know
just
destroying
their
bundle
size
and
it's
just
like
way
too
heavyweight
and
the
tracing
model
in
general,
like
it's
just
not
particularly,
it's
really
like
a
log
model
as
closer
shooter,
but
what
they
found
is
they
it's
a
custom
sdk,
but
it's
it's
essentially
one
event:
one
span:
zero
duration,
traces,
zero
duration,
spans
or
whatever
span
events,
but
they're
aggregated
by
session,
is
sort
of
like
the
grouping
thing
and
not
necessarily
like
tracing.
E
That
session
has
an
identifier
and
then
there's
some
back
end
magic
to
associate
sessions
with
you
know,
maybe
a
server
side
request
that
session
made
or
whatever,
but
the
the
real
analysis
comes
from
being
able
to
do
like
flow
analysis
of
your
rem
events
or
like
funnel
analysis,
and
so
having
some
sort
of
like
grouping
session
is
the
useful
thing,
but
I'm
not
going
to
get
involved.
E
F
F
G
E
Yeah
it's
anyway,
it's
almost
not
like
client-side
tracing
is
really
not
you
really
don't
want.
Tracing
like
tracing
is
just
not
the
thing
you're
really
looking
for
it's
this
more
like
event-based,
you
know
thing
but
anyway
like
and
also,
I
think,
there's
significant
issues
with
client-side
instrumentation
right
now,
because
the
javascript
instrumentation
doesn't
work
well
with
esm
modules
because
of
the
way
patching
occurs.
If
anyone
is
curious,
there's
an
open
source
package
for
patching
esm
modules
written
by
some
tc39
members
anyway,
but
yeah
our.
E
G
Making
it
useful
slightly
dovetails
with
something
that
I
had
brought
up
in
the
chat
room
about
at
honeycomb.
We're
experimenting
in
our
distribution,
with
a
thing
that
our
custom
instrumentation
did
called
trace
level
fields
which
we
could
gather
up
traces
and
then,
if
you
declared,
I
want
this
field
on
every
span
in
this
trace,
we
would
tuck
it
onto
every
field
and
send
it
can't
do
that
in
hotel,
but
we've
faked
it
but
enable
it.
G
We
wrote
a
custom
baggage
span
processor,
which
was,
if
there's
a
field
on
baggage,
we're
going
to
jam
it
onto
the
span
on
every
span
in
a
trace
so
like
from
here
down
all
children
get
that
field
you
put
on
baggage
and
if
then
you're
downstream
services,
you
pass
baggage
to
your
downstream
services.
Your
downstream
services
also
have
the
baggage
fan
processor
that
puts
baggage
fields
on
spans,
sorry
attributes
attributes
on
spam.
You
can
get
like
session
id
at
a
point
in
the
trace.
G
G
That
sort
of
thing,
if
you
could
just
decorate
all
the
stuff
with
say
session
id
your
back
ends
putting
a
field
called
session
id
on
the
events
in
the
back
end
that
are
happening
there.
They're
front
ends
putting
session
id
on
the
things
they're
all
happening
now
and
now
session.
Id
is
a
way
that
you
can
aggregate
all
the
stuff
that
a
particular
session
generated.
G
And
we're
going
back
and
forth,
I'm
like
is
baggage
the
right
way
to
implement
this,
because
it's
baggage
I've
got
a
research
spike
to
do
to
see
how
many
of
the
http
instrumentations
let
you
do
and
include
exclude
about
who
gets
your
baggage
when
it
goes
out
so
that
you
know
you
don't
have
session
ids
leaving
your
network.
E
D
Had
something
like
that
in
shopify
for
just
injecting
trace
context
like
if
it
was
leaving
our
world,
we
would
just
not
inject
trace
context
like
so
it's
like
say:
we
have
some
apps
making
a
call
to
like
gcs
or
something
like
that.
We
would
say
like
nope,
like
don't,
don't
propagate,
trace
context
here
like
no.
No,
no,
it's
not
like
it
really
isn't
necessarily
harmful
to
us,
but
we
don't
want
to
do
it
right.
D
G
Not
everybody
wants
to
have
to
write
those
rules
at
their
egress
points
because
that's
complicated
infrastructure
and
yes,
so
yeah
we're
we're
we're
thinking
about
spike,
and
that
was
the
conversation
I
think
we
had
with
francis,
where
we're
thinking
about
spiking
on
something
in
our
distro,
so
that
proof
of
concept,
for
maybe
that
would
go
to
a
spec
where,
like
these
trace
level
fields
within
a
process
that
you
could
then
choose
to
duplicate
on
the
baggage.
E
G
C
I
was
gonna
say
I
think,
like
the
the
main
goal,
there
is
to
be
able
to
kind
of
like
correlate
stuff
on
on
the
back
end.
So
hopefully
you
don't
have
a
bunch
of
just
like
one
span,
traces
that
you
can
actually
see
that
this
click
triggered
this
stuff.
That
happened
on
the
back
end,
but
but
then
I
think,
as
as
eric
was
mentioning,
there
is
kind
of
this
notion
of
a
session
and
wanting
to
kind
of
like
track
everything
that's
going
on
there
and
that
that
is
a
little
bit
more
foreign.
To
me.
C
I
will
at
least
mention
with
like
the
with
the
the
javascript
sdk
and
the
way
things
kind
of
currently
work
like
there
is.
C
There
is
kind
of
like
this,
this
magic
thing
that
you
can
do
basically
like
usually
your
or
every
browser
request,
will
actually
start
with,
like
a
request
to
your
backend,
that
has
to
like
at
least
serve
up
your
single
page
app
or
your
your
page
in
one
way
or
another,
and
if
you
stick
a
trace
parent
as
a
meta
tag
in
that
html,
then
there
is
like
a
document
load
plugin.
C
I
think
that
will
look
at
that
meta
tag,
and
this
fan
that
it
creates
it
will
use
the
the
server
side
span
as
a
parent
and
at
least
link
that
stuff
up
properly.
E
So
that's
that
works,
except
on
initial.
The
initial
response,
like
in
the
first
request
to
the
site,
the
meta
tag
that
you're
supposed
to
use
according
to
the
spec,
isn't
supported
by
safari
or
or
I'm
sorry.
The
api
safaris
like
api
won't
allow.
I
basically
they
won't.
Maybe
it's
a
header,
not
a
meta
tag.
There's
one
there's
like
some
issues
with
it,
but
yeah.
That's
another
important
point.
I
am
not
looking
good
on
the
details
here,
but
yeah.
This
was
an
issue
I
bumped
into
a
while
ago.
C
Yeah,
no,
I
just
wanted
to
throw
out
there
that
there
is
some
magic
there.
I
guess
we
don't
need
to
like
go
into
the
nitty-gritty
details
of
it
all,
but
if
you
are
trying
to
link
up
stuff
between
browser
and
and
the
back
end,
yeah
look
at
the
document
load
example.
I
think
it
kind
of
explains
a
lot
of
the
stuff
in
in
js
yeah.
I
think
the
meta
tag
is
a
workaround.
It's
like
you
really
want
to
use
headers,
but
they.
C
There
are
definitely
some
restrictions
that
the
browser
has
in
in
that
area
anyway,
yeah
yeah.
So
honestly
that
was
like
the
only
that's
the
only
topic,
so
we
are
the
floor
is
open
for,
for
any
other
rabbit
holes
that
we
want
to
start
climbing
down.
E
Maybe
maybe
I
can
speak
not
on
behalf
of
amir.
I
know
he
probably
isn't
things.
I
think
we
need
another
review
on
the
sqs
sns
propagation
and
additional.
I
I
approved
it.
I
think
it
looks
good
to
me,
but
I
could
use
a
second
set
of
advice
and
also
we
literally
need
more
approvals,
and
then
I
think
there
was
yaniv
had
some
additional
questions
on.
He
wants
to
add
additional
work.
I
wasn't
sure
how
to
make
a
server
vr.
F
E
I
want
to
make
sure
that
gets
covered.
Let
me
or
do
you
have
anything
you
want
to
mention
here.
A
E
Sure
yeah
I'd
like
to
be
honest,
I
think
the
work.
Oh,
we
maybe
already
updated
it.
We
had
sort
of
like
a
chunk
of
work
that
I
think
was
good
to
merge,
which
is
like
additional
metadata
for
sqs
sms
and
then
injection
and
then
an
extraction
api.
But
not
the
api
wasn't
actually
used
within
the
instrumentation,
and
I
think
that
was
what
I
proved.
It
was
like
all
right.
Let's
like
get
this
merged
and
then
you
can
add
the
extraction
as
like
a
separate
pr
like
yeah,
actually
like
applying
the
extraction.
E
So
I
think
he
mentioned
that
he
has
maybe
some
of
that
work
in
flight
or
ready
for
review.
My
vote
is
kind
of
like
merge.
What
we
know
is
good
and
then
like.
Let's
take
that
as
a
separate
pr
just
so
we
can
get
stuff
because
our
we've
been
erring
to
the
side
of
it
takes
a
while
to
get
stuff
merged
for
y'all
but
yeah.
So
I
think
that's
where
it
stands,
but
again,
like
I'm
open
to.
E
I
think
what
we're
merging
is
like
definitely
like
semi-incomplete,
in
that
we
don't
have
extraction,
actually
isn't
possible.
It's
only
just
like
you
know,
the
api
part
has
been
written
so
a
little
bit
of
people's.
A
A
So
the
race
doesn't
look
so
good,
but
there's
a
lot
on
changing
their
messaging
specification
and
it's
it's
going
to
be
ready
in
few
weeks
and
we
just
don't
want
to
waste
time
on
implementing
problematic
stuff
on
the
old
specification
and
then
specifications.
So
we
thought
it
would
be
wait
for
things
to
stable
and
then
do
this
work.
E
Yeah
yeah,
I
think
that
sounds
correct
to
me,
which
is
why
I
was
like
the
work
he
already
pushed
up
was
like,
I
think,
good
to
merge.
It
just
needs
another
review,
but
then
that
extra
work,
which
is
kind
of
like
both
controversial
and
maybe
depending
on
a
moving
target.
He
says
in
this
last
comment
like
he's
working
on
it,
should
I
add
it
as
this
pr
or
separate
pr.
E
So
I
was
going
to
say
like
just
leave
it
as
a
separate
pr,
because
it
sounds
like
things
are:
moving,
there's
more
moving
pieces
to
that
and
that
shouldn't
block,
like
all
the
good
stuff
here
that
helps
people,
so
I'm
gonna
I
just
for
haven't
commented
because
I
didn't
look
at
it
until
this
morning
so
but
on
the
original
work
we
would
be
good
to
have
another
set
of
eyes,
for
you
is
that
have
I
communicated
things
here
clearly
link
twice
if
your
people
know
what
I'm
talking
about?
Okay,.
E
Cool
yeah,
so
I'll
reply
to
you
and
even
just
say
like
let's
make
that
a
separate
pr,
but
then
my
my
humble
request.
Everyone
here
is
a
quick
review
of
this.
If
it's
not
too
much
ask.
C
Cool
yeah
that
sounds
like
a
good
plan.
I'll
try
to
get
some
eyes
on
this
and
handle
extraction
separately.
D
C
Yeah,
it
sounds
like
they've,
been
doing
a
lot
of
refactoring,
which
has
made
our
lives
hard,
but
perhaps
that
solves.
D
No
yeah,
like
the
last
refactor,
were
good
one
of
the
other
ones
that
we
were
depending
on
a
private
method.
Multi
and
the
author
made
it
public
and
aliased
it.
It's
now
quiet,
but
multi
is
still
supported
so
that
it's
not
breaking
any
of
our
instrumentation.
D
They
extracted
a
lot
of
stuff
from
patching
into
a
base
class,
but
because
of
the
way
it's
being
loaded
in
our
instrumentation
still
works.
But
it
looks
like
it's
actually
just
gravitating
towards
a
point
when
they
do
the
4.0
release
that
or
it'll
just
be
easier
to
instrument,
because
we'll
just
instrument
this
base
class.
D
But
I
just
provided
like
a
quick
example
of
what
we'd
look
for
like
if
we
did
get
it
added
in
and
just
kind
of,
I
don't
know
how
much
like
they
know
about
open,
telemetry
or
tracing
or
at
all,
like.
I
don't
want
to
assume
that
there's
just
this
in-depth
knowledge.
I
just
provide
an
example
like
the
type
of
information
we
can
capture
with
our
instrumentation,
but
it
would
be
nice
if
there
was
like
a
officially
supported
path.
D
So
we're
not
just
patching
things
and
hope
they
don't
change
right,
which
is
like
the
way
we've
been
doing
everything.
So
again.
I
think
we
have
to
hit
that
point
where
it's
like
that.
First
step
of
getting
the
first
few
people
to
say,
hey
telemetry
is
good
enough
for
us
to
make
it
the
supported,
instrumentation
path
in
our
library
and
then
hopefully
it
gains
momentum
and
we
see
more
projects
pick
it
up
so
got
to
get
our
foot
in
the
door
somewhere
fancy.
Maybe
here.
C
No
like
I,
I
think
this
is
an
awesome
idea
to
try
to
start
start
reaching
out
to
people
and
seeing
seeing
seeing
what
happens
and
if
it
starts
to
take
and
catch
on,
then
we
can
deprecate
all
of
the
auto
instrumentation.
All
the
instrumentation
all
package.
D
If
it's
third
party,
you
can
figure
it
through
our
sdk
I've
kind
of
accepted
that
to
be
my,
my
true
true
and
how
I
feel
about
it,
but
I'm
sure
there's
reasons
why
that
might
not
work
out
in
practice,
because
then
you
get
inconsistent
configuration
options
and
it
turns
into
a
nightmare,
but
we'll
see
we'll
embark
on
this
voyage
together.
D
Yeah,
I'm
just
like
not
particularly
related
to
open
telemetry,
but
I'm
gonna
after
today,
I'll
pretty
much
be
gone
until
the
10th,
I
think,
is
when
I'm
gonna
be
back
on
the
radar.
So
there's
anything
that's
merged,
but
hasn't
been
released
like
an
individual
gem
that
needs
to
get
bumped
or
something
like
that,
just
like
at
me,
and
the
telemetry
ruby
channel
on
the
cncf
slack,
and
I
can
like
fire
out
a
couple
of
releases
today.
D
C
I
did
see
a
message
from
francis
that
maybe
we
should
consider
releasing
some
stuff.
D
E
The
only
one
I
would
say
I'm
worried
about
is
not
worried
about
is,
I
know,
arielle
had
pushed
up
trilogy
instrumentation,
so
I
don't
know
how
urgent
that
is
for
them.
I
assume
they
have
something
internal
they're
using.
So
it's
not
like
they're
losing
coverage,
but
if
you
hadn't
seen
github
open
source
they're,
my
sequel,
client
and
coincidentally,
the
following
day,
there
was
a
pr
for
instrumentation
for
it.
E
What
a
coincidence
for
marielle
so
that's
merged,
but
I
I
he
would
I'm
sure
he
wouldn't
message
if
he
needed
it
right
away.
So
I'm
not
too
worried
about
it.
E
Yeah
right,
I
a
small
note,
is
I
did
a
quick
review
really
dirty
quick
and
dairy
review
of
like
whether
rail
7
breaks
anything
besides
active
record,
our
instrumentation
looks
fine.
None
of
them
met.
We
we
do
use
a
couple
like
private
methods
here
and
there,
but
no
they're
all
still
hanging
out
and
our
appraisals
are
running
now
on
rail
7.
So
we
have
some
confidence
that
it
works,
but
I
guess
we'll
see.
E
I
think
it's
ought
to
be
one
of
those
like.
Let's
wait
for
the
bug
reports
to
kind
of
float
but
yeah,
I
think
we
should
be
good
to
go
we'd
need
to.
We
can
probably
I
know
tim
wants
to
like
get
his.
Yes,
we
can
probably
unblock
the
active
record
stuff
he
had
mentioned.
I
think
there's
some
visibility.
We
lose
like
there's
some,
maybe
attributes
that
aren't
as
useful
aren't
available
now
or
something
he
had
a
note
on
his
pr.
E
C
D
D
D
C
Yeah
I
was,
I
was
half
joking
because
I
don't
know
a
lot
of
rail
shops
that
I'm
familiar
with
get
stuck
on
really
antiquated
rails
versions.
But
it
sounds
like
you
all,
have
a
good
process
down.
D
Yeah,
even
even
some
of
the
non
like
because,
like
we
have
our
our
monolith,
like
the
big
big,
big,
big,
big
rails,
app
right,
and
so
it
points
at
head,
but
because
they're
doing
it
a
lot
of
smaller
applications
of
the
company
are
like
they're
doing
it.
Let's
do
it
so
a
lot
of
applications
as
well
like
not
even
the
big
big
big
one
galaxy
just
point
of
head
and
it
seems
to
work
fine
right
like
we
have
a
pretty
responsive,
like
group
of
rails
enthusiasts
that
are
just
at
the
ready.
D
But
what
I
want
to
say,
though,
is
like
there
was
a
really
good
fix
that
got
merged
in
for
active
support
notifications,
and
I
think
my
tune
on
the
use
of
them
will
probably
drastically
change
as
a
rail
7.
I'll
have
to
like
actually
do
some
testing
with
it
to
really
solidify
that
confidence.
But
I
know
in
the
past
I've
been
very
against
using
the
active
support
notifications,
but
basically
it's
like
that
exploding
behavior.
That
would
blow
up
the
span.
D
D
D
I
think
a
lot
of
time
is
spent
in
there
that
becomes
invisible
to
users
like
had
someone
asking
they're,
basically
trying
to
understand
a
trace
the
other
day
and
they're
like
well.
I
have
a
bunch
of
like
sequential
active.
This
is
still
using
the
old
active
support
notification
instrumentation,
it's
like
a
bunch
of
sql
active
records,
but
there
there's
two
of
them,
but
there's
a
big
gap
in
between
them.
They're
like
well
where's
this
gap
coming
from
and
it's
like
you
don't
know
it
could
be
the
orm.
D
It
could
be
some
uninstrumented
code,
but
if
you
had
the
orm
you
could
see
like.
D
Oh,
they
have
a
callback
that,
for
whatever
reason
is
doing
like
an
inline
network
request
like
that
could
be
happening.
It's
not
impossible
that
someone
wrote
that
code.
You
know
a
decade
ago
at
shopify,
so
I
still
think
there's
a
lot
of
value
outside
of
just
using
the
active
support
notification
stuff
on
activerecord.
E
Yeah,
the
same
thing
exists
for
action
pack.
Also,
like
you,
don't
necessarily
get
the
hook
the
before
and
after
hooks
on
your
controllers,
unless
you're
patching
the
metal
which
is
for
brittle,
but
you
get
anything
you
want,
which
is
nice,
whereas
active
support
is
like
you
just
get
a
little
blob
of
json
yeah.
C
Yeah-
and
I
guess
my
recollection
with
active
record
especially,
is
that
you
get
limited
visibility
from
active
support.
I
think
like
sometimes
you
have
to
like
resort
to
monkey
patching
some
some
of
the
methods
in
order
to
be
able
to
identify
if
it
was
like
an
update
or
a
delete
or.
E
Yeah
it'll
be
good,
though
regardless
it'll
be
super
useful
for,
like
I
don't
know
some
of
the
like
random
third-party
libraries
that
you
have
asn
notifications,
it's
just
like
where
we
don't
have
to
worry
about,
like
I
feel
like
real
stuff.
It's
like,
let's
take
the
time,
have
like
really
deep,
thoughtful
instrumentation
and
then,
like
whatever
some
gem
comes
out
of
left
field.
It's
like
some
sidekick
knockoff
thing
that
has
asn
notifications
like
cool.
E
D
D
D
After
you
please,
no,
I
was
just
gonna
say
I
think,
for
some
of
the
stuff
that
we
might
be
interested
in
now.
I
think
the
conversation
with
the
rails
community
becomes
a
lot
easier
if
we
can
depend
on
active
support
notifications,
and
we
want
some
portion
of
the
code
instrumentable,
we
don't
have
to
necessarily
convince
them
to
jam
and
open
telemetry
ruby.
We
can
just
say:
can
you
add
a
notification
here
for
us
and
then
they
can
go
back
and
forth.
D
Ultimately,
like
it's
so
much
it,
the
adoption
becomes
trivial.
It's
like
we
want
to
know
more
about
this,
this
code
path.
Can
we
instrument
it
and
it's
like
if
you
can
make
a
case
for
it,
I
would
be
surprised
if
they
would
push
really
hard
against
it.
So
now
we
can
own
a
little
bit
more
of
the
instrumentation
story
inside
of
rails
itself,
just
because
we're
using
their
their
blessed
tech
right.
So
I
think
that's
what
I'm
also
very
excited
about.
C
Yeah,
I
think
that
makes
a
lot
of
sense.
It's
like
active
support.
Notifications
is
already
built
into
rails.
They
don't
need
to
build
in
anything
else.
They
just
need
to
add,
add
the
events
and
then
like
in
a
real
perfect
world
like
we
would
have
kind
of
like
a
an
action
support
notifications,
kind
of
base
class
that
you
could
inherit
from
and
just
be
like
subscribe
to.
C
This
event
create
a
span
and
like
pull
these
attributes
and
transform
them
in
this
way
to
like
make
them
spec
compliant,
but
I'm
sure
in
the
real
world,
like
all
the
attributes,
you
need
are
not
going
to
be
right
there
and
you're
going
to
have
to
like
pick
and
pull
and
grab
them
from
random
places,
but
maybe
we
can
build
that
abstraction
into
still
into
something
that
is
like
a
pretty
solid,
reusable
component
that
makes
makes
instrumenting
the
stuff.
You
know
pretty
straightforward.
D
Yeah,
that's
kind
of
how
I
see
like
the
active
support
notification.
Instrumentation
gym
being
is
just
like
this
really
convenient
helper
gem
that
our
rails
instrumentation
uses,
but
also
anyone
can
just
pull
in
and
use.
The
api
becomes
really
simple,
because
you're
just
provided
a
span
subscriber
and
then
maybe
you
give
it
like,
like
you
said,
like
the
ability
to
transform
and
extract
attributes
out
of
whatever
topic.
D
So
you
just
say
like
subscribe
to
this
and
use
this
transform
you
just
if
you
have
any
custom
stuff
you
want
to
do
so
that
that
could
be
the
instrumentation
story
for,
like
eric
was
saying
other
gems
that
use
asn.
It
becomes
like
that
for
rails.
If
someone
wants
anything
that
we
haven't
instrumented
out
of
the
box
with
like
the
rails,
gem
and
stuff,
like
that,
just
it
seems
like
the
path
forward
becomes
really
really
really
easy,
and
not
painful
and
everybody's
happy
and
the
world
is
just
a
better
place
because
of
it.