►
From YouTube: 2021-07-07 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
B
B
A
Morning,
guys
good
evening
for
people
today,
we
have
short
agenda
as
daniel
is
not
able
to
make
it
due
to
some
some
doctor
issue.
A
Can
you
hear
me
yep,
okay,
yeah,
so,
basically,
with
regards
to
the
previous
to
the
previous
sick
meeting
we
had
the
last
week.
There
are
just
a
few
issue.
I
think
the
example
still
needs
to
be
decided
how
exactly
we
want
to
structure
them.
I
don't
believe
we
have
the
consensus
with
this
one.
Anyone
any
preposition
against
having
this,
either
with
the
with
the
instrumentation
or
having
them
together
with
one
bracket,
json
or
maybe
different.
C
Way
so
I
think
that
that
we
should
keep
the
discussion
going
for
a
few
more
days.
I
have
the
feeling
it's
more
still
a
little
bit
brainstorming,
so
you
could
convince
me
a
little
bit
with
your
last
argument
on
that
instrumentations
could
be
a
little
bit
more
complex
so
that
that's
at
least
my
point
of
view
right
now.
A
I
mean
from
my
side,
I
think,
having
like
a
stand-alone
application
that
show
everything
from
the
front
end
to
the
back
end
and
you'll
be
able
to
see
the
traces.
You
click
and
you
see
the
traces
I
mean.
That
would
be
quite
a
nice
addition
to
all
testing
and
because
I
think
quite
often,
people
are
asking
how
to
connect
things,
including
even
the
web
pack.
Thinking
like
having
the
front
end
up
that
can
work
in
a
dev
or
in
the
production
with
all
bundled
together
and
so
on.
So
on.
C
Yeah,
no,
I
agree
on
that.
So
I
think
there
have
been
also
been
two
people
doing
that
already
I
mean
they
have
them
outside
of
the
contrib
repository.
So
if
you
look
like
there's
the
one
from
nico
achilles
and
I
think
there's
the
other
one
from
from
tempo,
I
don't
see
no,
which
person
this
discontributed,
so
maybe
one
of
them
is,
is
open
to
to
have
it
added
to
to
the
repository.
A
I
mean,
and
then
maybe
we
could
just
have
like
a
very
the
most
basic
example,
also
with
a
front
end
up
and
back
end
like
a
playground.
So
if
you
are
developing
a
new
instrumentation,
you
could
basically
add
your
own
instrumentation
there.
So
you
can
easily
debug
yeah,
so
it
will
be
just
one
line
of
code.
I
think
your
instrumentation
and
that's
it
you
can
debug
and
then
once
it's
done,
you
can
revert
to
the
changes
and
follow
up
yeah.
A
Because
I
mean
if
we
end
up
with
100
examples:
100
like
like
florida,
foreign
having
100
instrumentations,
I
mean
having
100
examples.
I
mean
it
might
be
pain
anyway.
C
But
yeah
okay!
So
when
you
say
some,
some
popular
to-do
app
that
you
mean
like
and
and
when
I
can
use
it
as
a
playground
that
when
I
say
like
hey,
I
develop
something.
For
I
don't
know
my
sequel
or
an
oracle
database
driver
that
I
can
swap
out
the
postgres
one
and
see
like
hey.
How
can
I
make
this
work
with
an
additional
solution
seriously
that
I
have
something
to
to
get
started
with
yeah.
A
B
I
think
we
are
talking
about
two
different
things.
One
is
like
a
big
complex,
like
kitchen
sink
kind
of
thing,
where,
like
lots
of
different
stuff,
is
combined,
which
is
really
useful
to
have,
and
the
other
kind
of
end
of
the
spectrum
is
just
to
have
a
minimal
set
of
one
specific
instrumentation
to
see
how
that
instrumentation
behaves
in
different
situations
and
not
have
anything
else
basically
there,
and
I
think
whether
we
are
talking
about
one
or
the
other.
A
B
A
But
I
mean
you
can
just
disable
this
yeah,
I
mean
in
the
in
this
playground
kind
of
thingy,
because
it
will
be
just
a
minimal
setup
with
with
just
some
front
end
up
and
some
back
end
that
works.
And
then,
if
you
work
in,
let's
say
on
on
on
reddish,
you
still
need
some
some
database
here
for
that
some
other
mechanics
yeah.
B
Maybe
I
haven't
read
the
the
last
comments
on
the
issue
and
I
might
be
missing
something,
so
I
think
I
agree
with
severin
that
maybe
we
can
keep
the
discussion
going
there
for
some
time
to
for
everyone
to.
Actually
you
know
because
the
last
couple
of
comments
have
been
like
a
few
hours
ago,
so
maybe
maybe
it's
better
to
not
make
a
decision.
A
I
can
just
imagine
the
situation
when,
let's
say
from
one
year
from
now,
we
have
100
instrumentation,
100
small
examples,
and
you
want
to
make
a
new
release
and
you
have
to
update
everything
and
if
there
is
anything
that
needs
to
be
changed
because
I
don't
know
the
exporter
has
changed.
You
have
100
places
where
you
need
to
make
those
simple
change,
how
you
initialize
the
exporter
and
so
on,
and
that
would
be
quite
pain.
B
And,
and
it
is
a
trade-off
definitely
and
like
a
complex
situation.
A
I
mean
from
once
you
start
bootstrapping
telera
and
you
will
have
all
the
examples
in
so
many
places
you
will
have
to
install
them
anyway.
A
A
You
can
still
do
this
with
one
package.json,
because
you
will
just
create
an
extra
folder
in
in
in
the
examples
which
particularly
your
instrumentation,
because
it's
quite
specific
and
you
can
still
give
it
a
try
and
but
all
you
have
to
do
just
add
your
instrumentation
to
the
one
to
the
package.json.
That's
it
you
don't
have
to,
like
repeat
all
the
traces
and
so
on
so
on.
A
So
that's
basically
this
is.
This
would
be
quite
similar
to
what
I
did
for
the
web
for
the
web.
Of
course,
there
are
now
less
instrumentation,
but
it
should
give
you
the
idea
so
one
bracket,
json
and
then
you
can
create
as
many
different
small
examples
as
you
want,
but
you
will
have
just
one
node
modules
which,
from
the
bootstrapping
perspective,
it
should
be
much
faster
than
having
like
many
node
modules,
folders.
B
Duplicated
is
there
a
way
to
avoid
dependency
conflicts,
so
if,
for
example
like
the
express
instrumentation
like
showcase
example
uses,
I
don't
know
low
dash
version
4
or
whatever
the
dependencies
and
another
one
uses,
you
know
the
version
three
like
do.
We
have
to
actually
sync
them
or
if
I'm
creating
another
new
example
using
a
dependency.
That's
already
used
in
that
package.
That's
json
in
that
central
example.
Package
json,
then
I
kind
of
I'm
stuck
with
using
whatever
is
already
there
and
I
cannot
add
a
dependency
with
a
different
version.
A
B
But
not
not,
if
I'm
not,
if
I'm
adding
another
dependency,
that's
not
inside
a
dependency,
if
I'm
actually
in
my
quote,
unquote
application
code
in
my
example
code.
Actually
I
use
something
like
imagine
if
a
radius
example
uses
redis
version
something,
and
there
is
another
more
complex
example
that
uses
postgres
and
redis,
but
an
older
version
of
redis.
A
A
B
A
A
A
B
And
it's
growing,
I
see
benefits
and
pros
and
cons
on
both
of
the
both
of
the
like
approaches.
I'm
just
not.