►
From YouTube: DAG meeting 04-15-20
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
Right
so
I'll
start
over
hi
everyone.
This
meeting
is
about
the
data
pipeline
graph
and
we
are
here
to
talk
about
the
context
of
how
we're
going
through
the
engineering
process,
and
so
the
idea
was
that
we
want
to
create
a
graph
that
will
represent
diagonally
pipelines.
Originally,
this
issue
was
to
represent
a
graph
with
staged
pipelines
and
died
by
playing
together,
but
in
our
previous
discussion
we
kind
of
felt
that
that
was
a
bit
more
complex
and
generating
something
that
work
for
both
at
the
same
time
wouldn't
require
way
more
effort
and
time.
A
So
we
decided
to
go
with
like
an
apprentice
easier,
which
is
time
only
when
we
would
take
that
digraph
and
put
it
in
a
separate
case.
So
we
would
have
the
normal
stage
view
and
then
the
diagonally
view-
and
that
made
it
much
easier
for
us
to
engineer,
because
there
is
less
clutter
in
the
graph,
because
when
you
have
staged
and
that,
then
you
have
lines
that
crossover
between
the
normal
cascading
view
of
the
stage
view
and
to
the
tag,
and
that
was
a
bit
more
complex.
So
we
have
so
far
in
terms
of
that.
A
Only
is
we've
been
playing
around
with
the
tree
and
we've
we've
injected
the
data,
and
we
can
build
a
graph
with
lines
that
connects
on
the
bed,
the
doc
job.
Basically,
so
far,
it's
scaling
pretty
well.
There
are
still
some
issues
about
laying
some
spacing
or
like
even
understanding
or
training
a
bit
of
the
code,
but
that's
kind
of
where
we
are
so
far.
I
can
ensure
my
screen
for
a
second
just
for
the
record
and
show
kind
of
what
it
looks
like
currently
that
thing
that
will
help
everyone
kind
of
understand.
A
This
is
kind
of
what
it
looks
like,
so
you
can
see
so
far
like
you
can
have
a
call
to
that
job
connecting
it
can
go
cross
stage.
So
the
idea
was
that
we
for
now
we
still
use
the
stage
view
as
in
like
because
all
of
our
tank
job
needs
to
have
a
stage
anyway,
we're
visually
representing
them
in
their
original
stage,
but
we're
connecting
all
the
lines,
no
matter
what
the
stage
is
and
it
scales,
no
matter
how
many
jobs
you
have
here
or
on
the
left
to
the
right
side.
A
C
A
I
think
that's
relevant
and
even
that
just
to
understand,
I
would
say
that
right
now
like
we
were
both
at
bitten
and
I,
we're
both
new
2d
tree.
So
I
think
it's
like
having
your
eyes,
and
all
of
this
would
be
super
useful
and
we're
kind
of
looking
forward
to
having
you
around
and
like
helping
us
that
right.
This
I
think
like
like
purely
take
like
in
a
purely
technical
discussion.
A
I
think
what's
interesting
is
I've
realized
that
d3
is
really
just
about
bonding
data
to
your
graph,
and
there
are
some
data
preparation
that
we
have
to
do
to
kind
of
draw
the
graph
correctly
and
it's
the
line
between.
Should
we
use
the
tree
for
that
preparation,
or
should
we
do
that
in
Jess
and
then
pass
that
to
the
tree?
I
think
there's
kind
of
a
interesting
separation
of
concern
there
that
we're
not
sure
yet
how
that's
gonna
look
like.
So
that
would
say.
That's
one
that
big
one
pretty
big
concern.
A
We
have
the
other
one
is
we're
trying
to
leverage
the
tree
as
much
as
possible
for
electoral
lines,
for
example.
So,
instead
of
having
you
know,
custom
SVG
and
then
passing
around
court
and
it's
trying
to
make
sure
that
each
we
can
handle
the
spacing
between
elements
that
it
can
handle
it
like
the
size
so
far,
where
we're
passing
the
tree,
a
coordinates
for
each
line
and
we're
using
the
vector
line
function,
so
it
Rondo
and
for
us
that's
good.
A
But
at
some
point
we
also
want
to
have
a
curve,
for
example,
so
that
the
lines
are
better-looking.
And
so
we
will
need
to
use
d3
curve
and
like
a
factory.
So
there
are
all
of
this
like
getting
used
to
what
did
weaken
power
for
us
and,
what's
more
complicated,
to
used
each
before
they
like
just
a
plain
JavaScript
function.
A
D
Also
like
to
make
a
note
of
I'd
say
like
one
of
the
things
that
would
be
great,
that
I
don't
know
if
it's
even
possible
right
now
is
every
time
I
find
myself
writing
vanilla,
JavaScript
I,
try
to
take
a
step
back
and
look
through
the
docs
and
like
is
there
a
d3
ish
way
we
can
do
this,
but
like
fred
was
talking
about
like
the
preparation
of
data?
Is
one
of
the
things
that
I
don't
know
if
we
could
get
around?
C
Right
that
makes
sense,
so
you
were
showing
the
version
with
like
three
stages.
Right
now,
have
you
guys
been
working
on
dumping
like
one
thing
in
and
a
thousand
things
in
to
see
where
it's
expand
like
where
it's
scaling
now
or
is
that
one
of
the
next
steps?
That's.
A
One
of
the
next
step
for
sure
right
now,
it's
like
we're
trained
with
different
kind
of
data,
but
nothing
very
large
set
I.
Think
exactly.
You
know
better
realizing
that
each
tree
has
a
couple
of
very
useful
function
like
scale
in
here
where
you
can
make
sure
that
everything's
scaled
properly
and
then
we'd
have
to
explore
kind
of.
Do
we
want
an
overflow
or
do
we
want
the
SBT
to
scale?
Is
it
light?
My
guess
is
that
it's
gonna
be
something
like
an
overflow.
B
It
helpful
we
can
set
like
a
max
for
now
for
this
first
iteration
and
say
like
well.
If
you
got
more
than
a
thousand
nodes
in
the
deck,
then
we're
not
even
gonna
try
and
render
it,
and
then
we
can
see
who
even
asks
for
more
than
whatever
is
a
basic,
reasonable
amount
to
support.
So
if
you
find
yourself
like
really
optimizing
for
that
last
10%
or
20%,
or
whatever
like
feel
free
to
bail
on
that,
thanks
that
make
sense.
A
A
We
were
only
receiving
like
you
know
all
the
jobs,
but
we
don't
have
a
good
needs
keyword
for
example.
So
we
don't.
We
don't
have
that
information
which
that
will
be
something
that
we
are
expecting
from
the
backend.
That's
we
can
have
an
endpoint
that
gives
us
all
of
the
jobs
that
are
physically
diets
and
what
job
do
they
require,
and
once
we
have
that,
then
the
only
a
question
is
like
we
need
the
opposite
as
well,
so
each
job
and
it's
dependent.
A
B
D
D
That's
been
working
for
us
just
to
have
a
conversation
around
just
see
if
we
can
create
a
new
endpoint
for
this
or
if
I'm,
trying
to
take
a
lot
of
the
low
or
I
think
we
should
take
a
lot
of
the
load
of
the
data
manipulation
as
much
as
possible
off
the
front
end
and
let
back
in
handle
that.
So
we're
not.
You
know
killing
performance
too
much
other
firm
in
because
we're
finding
ourselves
a
lot
of
the
times
and
like
double
loops
and
sometimes
maybe
even
a
triple
loop.
B
D
Did
not
even
know
we
had
an
agenda.
Dmitry
made
this
sorry
about
that
I
linked
it
in
the
dag
channel.
Yesterday,
oh
okay,
cool
I'll
I'll
put
in
the
ginger
really
quick.
Sorry.
C
A
Can
we
will
show
your
linkage
engine?
That's
a
good
idea
right
now
we
have
like
two
branch,
there's
a
master
which
is
kind
of
a
very
basic
version,
and
there
was
a
develop
version,
which
is
the
one
that
I
worked
last
last
week.
Paul
Payton
was
away,
which
is
I
would
say
kinda
the
first
I
showed
with
all
of
the
lines
and
everything
it's
still
in
a
very
early
stage,
but
any
feedback
at
this
point
is
appreciated,
like
the
structure
in
I
was
kind
of
going.
A
My
next
step
was
going
through
kind
of
making
sure
that
we
can
simplify
this
code
as
much
as
possible
and
had
like
a
very
testable
function,
because
I
feel
I'm
kind
of
I'm
concerned
that
it
I
want
to
make
sure
that
whenever
we
were
ready
for
work
like
officially
work
on
that,
we
have
like
very
small
function
that
came
to
test
it
for
outputs
and
maybe
with
that,
have
any
pollution
being
on
the
back
ends.
We
have
easier,
but
even
then
we
can
have
it
a
couple
of
very
simple,
like
a
rendering
test.
A
A
C
D
C
C
A
D
Jason
I
wanted
to
check
I,
don't
know
if
you're
still
in
the
loop
on
I
mean
I,
know
you're,
always
in
the
loop,
because
I
see
you
everywhere,
but
as
far
as
like
plans
for
implementation,
I
just
kind
of
wanted
you
to
like
a
little
bit
product
overview
on
like
what.
When
and
what
are
we
expecting
to
implement
this?
D
B
I,
don't
know
yeah
I,
I,
just
don't
know
towns
out
for
the
next
couple
of
weeks.
She
wouldn't
have
the
answer
to
that
I
know.
I
had
thought
that
it
was
planned
for
$13
was
the
last
night
heard,
I'm
sure
it's
not
too
far
away
whenever
it
is,
but
no
I
don't
know
the
exact
the
exact
date
that
this
issue
is
coming
playing
for.
It
is
the
issue
in
the
agenda.
I
could
take
a
look
at
least
at
that
part.
D
B
D
We
may
I
guess
we
don't
have
any
granular
data
based
on
like
the
actual
jobs
currently
in
our
current
data
visualization
for
the
current
stage
based
pipeline,
like
we
have
ways
to
restore
jobs,
they
wing
two
things:
they
show
different
details,
they
show
statuses
and
the
current
mock-ups.
They
aren't
as
detailed
like
that.
A
I
wouldn't
say
also
like:
there
are
two
points.
I
would
like
to
add
a
bad
like
the
first
one
is
I
know
like
we're.
Gonna
look
into
like
having
a
good
the
curve
line,
for
example,
visually.
One
of
the
things
I
wanted
to
know
is
how
kind
of
how
important
is
that
for
the
first
version,
because
I'm
gonna
spend
some
time
exploring,
but
I'm
still
not
sure
how
easy
it
is
to
do.
It
seems
a
bit
complex
to
do
a
curve
generator.
A
Maybe
Sarah
can
you
know,
do
it
in
one
hour
and
I
thought
my
question
is
not
relevant,
but
if
it's
not
like,
if
it's
not
easy
to
do,
then
how
important
is
that
versus
having
straight
liners?
That
would
be
one
and
the
other
one
would
be.
Is
there
any
specific
usability
that
we're
expecting
and
of
this
is
between
I
know,
Dimitri
talked
about
having
over,
in
fact,
I.
A
Don't
think
it's
the
first
version
kind
of
thing
anyway,
but,
like
you
know
when
I
mouse
over
aligned
and
then
that's
the
one,
that's
focused
and
you
don't
don't
see
the
other
as
well
as
it
goes
down.
I,
don't
know
like
anything
like
that,
it's
plan
are
we
trying?
Are
we
gonna
try
and
you
kind
of
just
list
how
the
thing
that
we
want
and
make
them
as
optional,
or
do
we
just
go
with
the
further
minimal?
And
you
don't
just
assume
that
it's
going
to
be
the
very
simple
thing,
I.
C
A
D
C
D3
does
have
a
decent
color
scale,
possibility
I
think
they
do
tend
to
top
out
more
like
20,
you
know,
but
there's
a
couple
different
types
of
scales
that
they
have
and
again
you
know
it's
like:
should
lines
be
darker
when
they
have
more
jobs
depending
on
men,
should
lines
at
all
have
the
same
dependency
start
off
with
the
same
shade
and
carry
that
through.
Like
that's
something,
I
noticed
when
I
look
at
the
examples,
and
the
designs
is
just
like
how
much
lifting
we
want
the
color
to
do.
E
E
A
Add
on
the
color
issue,
I
think
one
thing
that's
interesting
is
right
now,
just
for
free
over
for
work
engineering
purposes,
it's
just
a
random
color
generator.
So
just
pick
any
color,
it
doesn't
matter,
but
I
think
one
thing
I
will
be
important
is
that
you
know
every
time
that
I
refresh
the
color
changes
and
like
obviously
for
now
it
doesn't
matter
but
I'm
thinking
in
term
of
like
little
clicking
an
official
version.
I,
don't
think
a
user
would
like
that,
the
color
of
our
window,
for
example.
A
Today
you
can't
confuse
very
quickly
so
if
we
have
the
same
order
of
color
every
time
so
like,
for
example,
every
time
it's
your
first
line,
it's
the
same
color
or
if
it
has
the
same
number
of
jobs
or
like
like
Sarah,
was
saying
so
I
think
that
would
be
more
consistent.
Also,
so,
even
in
terms
of
like
understanding
your
graph
every
time
it
could
change
a
little
bit
depending
and
it's
your
grass
change,
but
not
like.
If
you
have
the
same
graph,
it
should
be
the
same
color
kind
of
deal.
D
It
sounds
like
maybe
we
can
keep
that
data
persistence
with
the
color
skill.
That
Sarah
was
mentioning
with
d3.
It
sounds
like
we
might
could
explore
that
and
keep
that
consistence
of
making
attaching
the
color
to
a
line
and
making
it
darker,
depending
on
how
many
jobs
were
connected
to
it,
type
kill.