►
From YouTube: 2019-10-16 Ruby SIG
Description
OpenTelemetry Ruby SIG meeting
A
B
B
D
E
B
F
G
C
G
G
G
A
A
A
That's
also
me,
that's
actually
what
I
popped
into
this
to
talk
about.
That's
been
making
a
lot
of
progress.
I
had
to
put
it
down.
I
had
kind
of
a
hell
week,
but
I
picked
it
back
up
this
week.
It
seems
like
there
are
two
finer
fine
issues
that
are
I,
think
difficult
to
express
in
this
high-level
doc,
but
kind
of
came
out
of
the
woodwork.
One
is
around
the
new
name,
tracer
name
metrics.
A
So
as
soon
as
we
add,
if
you're
just
saying
you
know,
your
tracer
has
an
injector
and
your
metrics
has
an
injector.
It's
easy
to
chain
those
together
into
like
a
single
injector
that
calls
all
three,
but
if
which
injector
you
want
to
use
is
dependent
on
which,
like
tracer
handle
you
have,
because
you
have
a
name
tracer
and
like
a
name
metrics,
then
suddenly
that
becomes
kind
of
confused
exactly
like
how
you
would
chain
those
things
together
with
that
the
inject
call
site
kind
of
knowing
about
all
the
things
that
you
want
to
inject.
A
A
But
now
we're
talking
about
a
more
general
context,
object
that
has
to
move
around
the
the
reverse
of
that
is
when
you,
some
asynchronous
layer
like
I,
forget
what
this
is
these
days
and
in
Ruby,
but
I
know
like
in
Python.
You
had
G
event,
but
something
we're
on
the
same
thread.
What's
being
called,
might
be
related
to
a
different.
You
know
active
span
or
active
context,
so
you
need
to
have
some
way
for,
like
a
context
manager
to
be
switching
that
around
every
time.
Your
asynchronous
layer
is
switching.
A
What
work
is
active
and
that
again,
I
think
has
been
kind
of
like
span
centric
and
would
have
to
be
more
like
contact
centric.
So
that's
that
seems
like
that's
like
a
little
bit
of
a
big
shift
just
because
up
till
this
point
we've
been
managing
that,
through
this
start
span,
activate
span
kind
of
call,
so
I
wanted
to
call.
Those
out
is
like
I
think
those
are
like
the
two
final
issues
that
we
have
to
sort
of
grind
through.
If
we're
gonna
actually
fully
separate
context
propagation
out
into
its
own
layer,
I.
F
F
Mm-Hmm
and
brandon
has
a
lot
of
same
questions
on
the
JavaScript
side,
but
it
did
bring
up
maybe
a
larger
question
on,
if
it's
appropriate,
but
just
as
a
general
question
about
how
much
implementation
details
in
the
spec
right,
because
you'll
find
some
that
are
pretty
high
level
and
you'll
have
others
that
say
it
must
have
this
method
name
it
right.
It
must
have
this
method.
Signature,
so
is
that
a
balance
that's
currently
in
progress
or
is
that
some
baggage
from
left
over,
like
old,
specs
I'm,
not
really
sure
just
curious
tomorrow,
yeah.
A
I
would
say
in
general,
there's
like
not
an
issue
with
the
spec
but
I
think
an
area
where
the
spec
is
this
thing,
that's
under
development,
which
is
things
in
the
spec,
especially
the
first
version
of
it
tend
to
be
very
Java
centric.
So
the
original
version
of
the
spec
read
like
Java
API
Docs
for
the
Java
tracer,
which
obviously
is
not
an
appropriately
rate
across
language
spec,
because
it
leads
to
these
sort
of
like
overprescribed
things
where
you
say
like
I.
Don't
literally
have
that
in
my
language.
So
what
do
I?
A
What
am
I
actually
supposed
to
do?
And
so
I
think
there's
been
a
general
effort
from
people
like
Chris
from
Python
in
particular,
to
try
to
rewrite
portions
of
the
spectres
they
come
to
them
to
be
more
cross
language,
while
still
being
specific
enough
that
you
could
actually
do
an
implementation
on
the
spec.
So
that's
all
just
like
a
hand,
wavy
way
of
saying
like
if
you
see
things
that
seem
overprescribed
you're
like
over
specific,
that's,
probably
something
that
should
be
addressed
in
this
spec
and
it
should
be
rewritten
in
a
way.
F
I
think
I
think
so
the
follow-on
to
that.
Well,
thank
you
for
that.
Cuz
I
think
some
of
it
is
just
knowing
hey
I.
Could
you
know
we
could
we
could
we
could
propagate
some
feedback?
You
know
up
and
say
hey.
This
is
overly
prescribed
because,
if
I
see
a
class
factory
in
a
ruby
library,
I
screw
up
my
nose
ago,
why
you
know
I
just
don't
know
why
I
think
the
second
thing
would
be
that
spec
in
particular
seemed
like
the
dotnet
implementation.
F
H
A
With
these,
like
spec
changes
I
in
open
tracing
like
we,
we
didn't
we
weren't
able
to
get
away
with
that
I
kind
of
feel
like
to
a
certain
degree.
The
spec
changes
we've
been
making
having
like
kind
of
minor
or
like
now,
I'm
contentious,
so
we've
just
kind
of
got
away
without
having
a
reference
implementation
to
hash
out
these
details.
But
I
do
think
there
are
some
cases
like
this
context,
propagation
and
stuff,
where
it's
like
you're.
F
A
F
Yeah
I
think
more
than
anything
and
Francis
I'm
not
trying
to
talk
for
you,
but
I
think
your
comment
was
like
I
read
it.
It
didn't
help
here.
It
is
I.
Think
kind
of
that
was
my.
That
was
my
feeling
about
it.
So
when
I
went
back,
I
had
some
examples,
I'd
written
when
I
went
back.
You
know
the
factory
stuff
changed
that
fairly
dramatically
about.
F
You
know
how
I
was
getting
access
to
the
tracer
and
that
kind
of
thing
so
yeah
as
someone
who
hasn't
spent
a
lot
of
time
with
this
stuff,
you
know
I'm
still
sort
of
looking
at
that
going.
Okay,
that's
what
I
have
to
do
and
and
and
sort
of
get
that
to
work.
So
I
think
thanks
for
those
explanations,
Ted
I,
just
I
kind
of
wanted
to
have
a
follow
on
from
that,
because
it
did
come
up
yesterday.
So
I
appreciate
that
Thanks
yeah.
D
Since
we're
talking
about
named
tracers
I'll,
just
kind
of
throw
on
that,
I
was
fairly
like
equally
confused
and
actually
had
a
pretty
lengthy
conversation
with
with
Josh.
Yesterday
it
lights
up
and
was
less
confused,
but
then
I
went
back
to
my
hotel
and
read
the
spec,
and
that
was
the
equally
confused
again
I.
D
Think
there's
a
lot
of
confusion,
I
think
from
what
I
understand
of
the
whole
situation
like
I,
don't
know
that
I
would
be
all
on
board
with
the
concept
in
general
and
I'm
just
wondering
if,
as
other
I
kind
of
feel
like
you
know,
this
is
definitely
brought
up
at
the
spec
meeting
a
few
times
and
the
hotel
was
merged.
When
I
looked
at
the
otep,
there
was
definitely
not
overwhelming
support
for
it.
D
But
whether
or
not
this
is
like
the
best
way
to
solve
those
problems
might
be
still
up
to
debate
and,
like
I,
don't
know
like
I
guess
to
cut
my
rambling
short.
It's
like
I,
really
don't
want
to
like
be
like
a
monkey
wrench
or
throw
a
monkey
wrench
in
any
of
the
progress
of
open
telemetry,
but
at
the
same
time,
I
definitely
want
to
make
sure
that
the
thing
that
we
end
up
with
is
something
that
is
awesome
to
use
and
that's
like
the
number-one
goal.
D
G
I,
looked
at
I
think
somebody
from
maybe
the
dotnet
community
opens
an
issue
about
this,
just
to
get
some
clarification
around
like
what
was
the
intent
behind
it
and
the
author
of
the
otep
responded
the
error
and
they,
if
I
summarized
the
response,
it
felt
a
little
like.
We
don't
really
expect
the
SDK
to
implement
this,
but
dynaTrace
is
going
to
implement
it.
So
it
almost
felt
like
Danny
trace,
needs
us
in
the
API,
but
it's
really
optional
for
the
SDK.
A
A
Trying
to
wrangle
them
a
bit
there
they're
just
kind
of
involved
in
this
work,
but
yeah,
like
obviously
like
the
spec,
has
to
be
something
that
isn't
just
like
a
thing
for
alternate
SDKs
to
implement
and
like
we
Thor
I,
just
think
generally.
What
what
we've
been
doing
up
till
this
point
is
like
we
kind
of
smushed
together
open
tracing,
an
open
census.
A
You
know
back
in
like
May
and
all
the
changes
since
then
have
been
about
implementing
that
smushed
together
thing
and
trying
to
massage
out
the
details,
but
now
we're
hitting
our
stride
where
we've
identified
some,
like
you
know,
critical
things
that
are
actually
like
new
concepts
that
we
think
we
want.
Since
we're
doing
a
rewrite
of
this
thing,
we
still
need
to
be
backwards,
compatible
with
open
tracing
an
open
census,
but
we're
like
we
really
want
to
split
context,
propagation
out.
A
That
would
be
leaking
information.
So
that's
like
I
think
those
are
the
critical
concepts
in
named
tracers,
but
because
this
is
a
new
thing,
I
think
this
process
of
just
write
a
just
write,
a
spec
and
like
throw
it
over
the
wall,
and
then
everyone
implements
it
probably
isn't,
isn't
gonna
be
sufficient
right,
like
I,
think
it's
totally
natural
that
we're
gonna
try
to
implement
this
stuff
and
be
like
I
see,
issues
that
were
not
addressed
in
this
RFC,
so
I
guess
took
up
my
rambling
short
I
feel
like
with
this.
A
This
is
like
a
new
kind
of
change.
That's
coming
down
the
pipes
for
the
next
month
or
two
and
I
think
it's
going
to
involve
a
lot
more
active
participation
from
the
different
sigelei
ders
in
the
SPECT
process.
For
this
very
reason,
so
I
think
this
is
maybe
something
we
need
to
like
work
out
like
some
process.
For
so
it
doesn't
just
feel
like
a
mess.
Are
we
going
to
cut.
G
A
From
my-
and
this
is
just
like
my
own-
take
I
feel
like
it's:
it's
not
an
infinite
set
of
issues.
It's
really
the
the
remaining
things
that
we
want
to
put
a
stake
in
are
some
of
the
issues
raised,
and
this
name
tracer
thing
are
like
things
that
actually
were
a
problem
in
open
tracing.
You
can
go
back
and
be
like.
This
was
like
a
big
pain
point.
A
The
fact
that
stuff
just
gets
propagated
everywhere
all
the
time-
and
you
don't
have
this
level
of
control
and
not
knowing
being
able
to
know
what
component
produced
a
thing
we
had
this
like
component
tag
that
was
just
kind
of
insufficient
the
context,
propagation
stuff
we've
always
wanted
to
have
separate.
But
just
you
know
it
was
like
this
killer.
App
problem
of
people
first
had
to
get
their
heads
wrapped
around
distributed
tracing
before
they
realized
they
wanted
this.
A
A
A
So
that's
my
own
take
if
we
can
get
it
hammered
out
in
the
next
like
month,
then
I
think
it
would
be
worth
it
to
do
these
changes
because
we're
gonna
have
v1
locked
in
for
a
long
time.
But
if
we
can't
do
that,
like
we
were
in
this
like
valley
of
death,
but
we're
the
old
projects
are
like
kind
of
a
life
support,
but
the
new
ones
not
ready
yet
and
I,
don't
think
it
would
be
appropriate
to
like
hang
out
there
for
another
six
months.
A
A
Last
little
like
just
like
point,
three
spec
is
like
the
thing
that
needs
it
needs
to
move
beyond.
Just
like
a
core
set
of
spec
writers
like
pushing
things
out,
we
need
to
have
like
a
feedback,
loop
and
work
out
some
process
for
getting
feedback
that
that
doesn't
feel
like
a
big
mess
and
we
had
this
an
open
tracing,
but
it
was
also
a
slow
process.
So
I
don't
know,
but
I
would
really
encourage
people
to
not
take.
A
The
speck
is
like
canon
and
if
you
like,
you're
trying
to
implement
something-
and
this
feels
like
it's
not
working
out,
feel
like
you
have
the
authority
and
it
is
totally
within.
You
know
your
realm
to
like
go
in
there
and
try
to
fix
these
issues
and
certainly
raise
them,
and
we
should
also
be
doing
this
quickly
like,
like
I,
think
we
really
need
to
hammer
out
these
issues
in
the
next
month.
G
F
Wrote
and
put
those
in
the
docs
for
those
methods-
yeah.
Absolutely
ok,
I'd
like
to
do
that
as
part
of
this,
so
that
that
that
finds
its
way
back
into
the
codebase
cuz,
it
was
very
enlightening
to
have
you
put
that
in
there.
So
ya
know,
I
think
that
that
helped
quite
a
bit.
So
my
only
apology
is
that
I
was
so
dense
on
the
tests.
G
G
G
G
Trace
flags
from
bytes,
we
had
some
checks
in
there
or
we
have
a
check
in
there
to
see
whether
the
value
given
fits
into
a
bytes.
But
if
we're
not
doing
type
checking
there,
then
that
could
raise
no
method
error.
If
somebody
passes
in
a
string
as
an
example.
So
are
we
like
in
terms
of
error
handling?
G
G
D
D
D
But
if
something
totally
bizarre
is
passed
in
and
you
can't
stop
user
from
doing
that,
we
are
probably
not
responsible
for
handling
all
those
situations.
However,
you
know
in
in
instances
where
it's
easy
to
kind
of
I
guess
check
and
correct
and
recover
from
something
we
probably
should
but
yeah
those
will
kind
of
be
the
things
that,
like
I
questions,
I
asked
myself
as
I
go
through
this,
so
the
from
byte
business
like
if
you
know,
if
we're
worried
about
it,
raising
when
a
weird
type
is
passed
in
getting
I,
know
about
no
method,
error.
D
G
The
the
larger
issue
was
complicated.
One
is
around
the
checks
for
link
creation
and
event
creation
to
a
lesser
extent,
resource
creation
as
well,
but
for
Lincoln
event,
creation,
we're
doing
checks
at
the
moment
to
see
all
the
attributes
properly
formed
and
we
are,
we
were
originally
raising
if
they
want
now
we're
just
basically
turning
in
that
mean
empty
attributes,
we're
still
incurring
the
same
overhead
to
check
the
types
of
those
attributes.
G
So
you
know
somebody
could
pass
an
arbitrary
large
hash
attributes
and
we've
got
to
walk
the
entire
thing
and
check
the
types
of
everything.
So
the
question
I
had
was
like.
Do
we
want
to
incur
that
overhead
at
that
point?
Or
do
we
just
want
to
accept
the
attributes
as
given
and
then
when
we
get
to
the
point
of
serializing
them
for
export
check
to
see
whether
they
valid
at
that
point.
D
F
Yeah
I
was
thinking
the
same
thing
in
regards
to
the
front
byte,
because
I,
what's
more
useful
to
the
person
who's
using
the
library,
maybe
and
so
take
all
things
taken
consideration.
You
know
we're
trying
to
balance
the
performance
with
the
usability
and
sort
of
the
ergonomics
of
the
library.
If
I,
if
I
get
in
no
method
error,
is
that
helpful
to
me?
It's
it.
We
know
we
see
a
lot
yeah
and
really
like
well.
Okay,
guess
can't
do
that
on
the
attribute
stuff,
when
I
was
doing
the
examples.
F
These
errors
helped
me
out
quite
a
bit
because
it
was
unexpected
to
me
that
I
couldn't
use
a
symbol
for
the
keys,
for
instance
right,
so
that
that
was
a
surprise
to
me,
and
this
helped
me
say:
okay,
those
are
invalid
and
then
in
France
you
saw
my
little
PR
to
like
change
the
message,
so
it
gave
a
little
more
information
but
to
Daniel's
point
when
I
was
using
it.
It
was
extremely
helpful
to
have
that
there,
but
is
that
in
my
the
normal
case,
someone
rolling
up
and
saying
I've
never
done
this
before.
D
Yeah
so
I
think
that
was
really
kind
of
the
thing
that
what
that
has
been
up
to
debate.
This
error
handling
spec
has
really
said
that,
like
you
should
not
raise
exceptions,
that's
like
the
I
guess
yeah.
The
biggest
thing
is
that
you
know
runtime
checks
and
raising
is
really
not
the
thing
that's
expected
by
that's
back,
although.
F
D
Mean
they
would
but
Ruby
warnings
themselves
like
the
dash
W
flag
like
this
is
not
something
that
comes
like
a
runtime
yeah
situation
like
that
would
be
like
a
logging
concern,
I
guess
at
that
point,
but
that
I
guess
that's.
One
reason
why
we
were
debating
whether
or
not
having
a
strict
mode
is
a
good
idea,
because,
like
the
strict
mode
would
be
the
thing
that
you
could
kind
of
use
that
would
check
and
raise
for
your
debugging
purposes
and
I
guess
a
lot
of
you.
I.
D
Don't
pick
take
the
level
of
comfort
that
you
have
with
with
the
SDK
doing
certain
things
with
your
desired
level
of
feedback,
I
guess
from
the
SDK
as
to
whether
you're
using
it
properly.
However,
like
I
do
anything
strict
mode
is
something
worth
considering.
I
think
it
might
be
something
worth
deferring
for
a
little
while
it
might
not
be
like
a
v1
concern,
but
it
might
be
like
one
of
these
things
that
we
do
because
Donna
you,
you
found
it
useful
if
you
found
it
useful
other
people
gonna
find
it
useful.
G
D
G
F
You
know
we
between
David
and
Phil
and
myself.
Like
you
know,
we
we
don't
have
a
lot
of
the
deep
knowledge
to
implement
the
specs
and
things
that
you
you
guys
have,
but
we
might
be
able
to
come
in
and
say:
let's
take
that
diff
to
Francis
just
did
and
let's
figure
out
how
we
want
that
strict
mode
to
behave,
and
let's
sink
some
time
into
that
for
you,
you
know
and
Matt,
as
you
come
into
your
new
role,
that
that's
something
that
you
know.
F
That's
why
light
step
brought
us
in
so
that
might
help
Francis
in
the
sense
that
you,
you
could
say,
I've
done
the
hard
work
here
of
saying
this
is
these
are
the
places
where
I
think
I
want
to
remove
these
checks
based
on
what
the
spec
wants
us
to
do,
but
we
could
convert
that
diff
into
that
strict
mode
for
us
and
sort
of
come
up
with
a
way
to
kind
of
work
around
that
that
might
be
the
best
of
both
worlds.
So
we
can
take
advantage
of
the
work
you've
already
done.
D
We
don't
have,
we
don't
have
to
do
a
bunch
people
right
now
if
we
do
want
to
address
it
and
like
if
somebody
wants
to
go
ahead
and
start
spiking
on
it
and
throwing
it
out
here
now
is
as
good
a
time
as
any
and
whenever
you're
saying
like
it's
easier,
it's
easier
since
we've
had
these
checks
and
it
will
be
easier
to
kind
of
maintain
them
and
say
move
forward.
If,
if.
F
Is
gonna
be
very
useful,
you
know
go
everywhere,
there's
red
and
and
sort
of
make
it
happen.
Maybe
we
could
a
sink
come
up
with
the
runtime
behavior
like
how
you
want
to
flag
that?
How
you
want
to
pass
that
in
until
the
library
I
want
to
run
strict
mode,
we
could
kind
of
come
up
with
the
API
for
that
and
then
someone
for
mutations
can
can
pick
that
up
and
run
with
it
cool.
Just
as
on
the
shared.
G
H
H
G
Thanks
very
much
well
yeah
yeah
I
felt
in
particular
would
benefit
from
testing
against
ideally
again
see
a
girl
role
in
one
distribution.
I
wondered
whether
we
should
like
once
you've
had
some
people
take
a
look
at
it.
Should
we
merge
it
and
then
build
integration
tests
once
the
docker
compose
PR
plans.
H
G
D
H
D
H
G
Cool
yeah,
actually,
the
comments
I
had
on
the
docker
compose
PR
were
really
around
like
how
would
this
be
extended
to
support
doing
the
kind
of
integration
test
that
I
want
with
Diego
for
the
ager
exporter,
so
maybe
after
you've
done
kind
of
an
end-to-end
test
and
documented
that,
then
we
can
merge
both
these
PRS
and
then
follow
up
with
the
integration
tests.
Yeah.
F
So
Francis
one
thing:
I've
got
some
example
code
in
flight,
where
I've,
where
I've
got
I,
went
to
the
go
library.
Look
at
there
because
I've
been
writing
examples
to
try
and
understand
some
of
the
usage
and
when
I
saw
the
factory
stuff
roll
in
I
wanted
to
do
that,
and
so
I've
got
a
simple
client-server
example
and
the
way
I've
done
just
there
is
I've
just
added
a
composed
service,
which
kind
of
bundles
everything
up
together
and
kind
of
gives
us
a
nice
concise.
F
You
can
just
basically
you
know,
say:
docker
compose,
run,
e^x,
HTTP
and
it'll.
Just
fire
up
start
the
server
and
drop
you
to
command
line.
So
you
can
just
poke
the
server
and
see
the
traces
happen.
So
it's
a
nice
little
way
for
people
to
see
a
very
simple
implement.
You
know
instrumented
server
with
a
single
endpoint
and
just
kind
of
oh
hey,
that's
how
that
works
and
I
have
larger
examples.
So
Dave's
been
working
on
one
that
uses
great,
then
I've
got
one
that
uses
like
more
of
the
middleware
style
for
Sinatra
and
Faraday.
F
So
we've
just
been
trying
to
write
up
some
ways
to
show
people
kind
of
and
those
lead
to
auto
instrumentation
by
the
way.
That's
our
goal
is
we're
kind
of
getting
our
brains
that
way,
but
the
compose
stuff
really
gives
us
a
nice
way.
Those
could
also
be
put
into
longer
running
integration
tests
right
where
we
would
be
able
to
go
up
on
circle
or
Travis
or
whatever
and
say
yeah.
Do
these
real
fast
and
then
run
run
the
integration
test
when
something
merged
master,
for
instance,
and
and
kick
up
kick
up
that
composer?
G
G
F
G
Seemed
to
be
actually
just
going
into
the
open,
telemetry
org
in
Travis,
for
example,
and
saying
like
build
this
repo
that
has
to
be
done
by
somebody
that
has
admin
permissions
in
admin:
permissions
the
open
telemetry
all
in
Travis.
So
we've
added
the
config,
but
we
just
need
to
turn
on
the
builds
gotcha.
E
G
Really
have
strong
opinions
I'm
happy
going
either
way.
Originally
a
lot
of
the
SIG's
seem
to
be
using
Travis,
so
I
adopted
Travis
as
well.
Then
at
some
point
it
seemed
like
people
were
switching
over
to
using
circle
I'm
comfortable
doing
you
know,
using
whichever
everybody
else
is
doing,
but
I
yeah.
We
I
have
the
same
Commission's
problem
with
circle
that
I
had
with
Travis
yeah.
F
We
I
haven't
used
Travis
in
a
while.
Most
of
the
docker
related
see
I
work.
We've
done
has
been
on
circle
lately,
so
we
would
personally,
you
know
the
mutations.
He
would
be
more
productive
on
that
side,
but
I
think
would
be
fine
either
way.
Phil
do
you
know
offhand
if,
like
Travis
is
gonna
have
all
the
same
container
stuff
and
we'll
be
able
to
do
a
lot
of
things.
We've
been
doing
the
supports.
E
G
It
is
a
requirement,
certainly
it's
a
requirement
for
Shopify,
so
we're
doing
a
bunch
more
chocolate,
ruby
stuff,
including
on
projects
that
are
actively
using
tracing
and
would
probably
be
the
first
projects
to
adopt
open
telemetry
here.
So
we'd
really
like
to
have
that
support
in
there.
If
that
support
is
missing
on
circle,
we
can
definitely
do
a
custom
image
for
that.
F
Yeah
and
like
I,
said
sort
of
one
of
the
things
I
think
we
can
do
to
help
is
again
because
we
don't
have
the
spec
knowledge
and
what
are
the
chances
that
you
want
me
implementing
the
metrics
API,
for
instance,
versus
it's
really
spend
a
lot
of
time
with
it.
This
is
a
place
where
we
can
really
help
move
things
along,
so
we'd
be
happy
to
build
those
containers
and
set
those
things
up
and
kind
of
do
the
groundwork
for
you.
G
E
H
Just
do
whatever
you
know:
most
people
are
doing
to
keep
it
consistent
across
the
board
for
all
of
the
reasons
that
that's
good
and
then
yeah
well
up
on
and
if
we
need
a
custom
container
for
truffle
Ruby
or
you
know
something
along
those
lines,
then
naive
me
at
the
moment
would
say
that
shouldn't
be
too
bad
to
put
together.
Plus
these
things
should
be
pretty
straightforward.
I
would
think
yeah.
G
G
F
E
F
The
great
tail
CI
running
on
this
thing,
yep
branches
that
will
also
I,
think
lead
into
a
nice
discussion.
Maybe
we
could
do
this
in
the
next
couple
weeks
about
integration
testing
like
what
are
orders
and
things.
Maybe
we
could
start
to
do
wiring
up
some
and
in
tests
on
all
the
stuff.
My
examples
will
have
some
distributed
tracing
in
it,
which
might
lead
to
some
nice
test
scenarios
which
we
could
wire
up.
So
you
know,
are
there
any
other
tools
or
any
other
ways
you
want
to
do
that?