►
From YouTube: 2021-10-06 Source Code Weekly
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
All
right,
weekly
for
source
code,
it's
a
very
small
agenda.
Today.
I
wanted
to
give
a
bit
of
an
introduction
or
an
explanation
to
the
context
of
one
of
the
okrs
we
have
for
this
quarter
and
how
we're
potentially
updating
how
it's
scored
and
how
it's
tracked.
A
So
the
for
context,
the
the
the
okr
that
we're
looking
into
is
the
complete
migration
of
all
x,
like
a
number
file
type
viewers
to
the
repository
browser,
and
this
was
a
loose
goal
that
we
had
and
we
have
been
pursuing
that
the
problem
or
the
the
news,
the
the
novelty
here.
What
what
changed
is
that
in
the
meantime,
after
we
set
that
okr,
we
scheduled
an
issue
that
kind
of
nailed
all
of
them
at
once.
A
So
when
we
were
working
on
the
on
this
extent
on
this
okr
to
refactor
the
the
repository
browser
to
one
view
application,
the
idea
was
to
have
rewrite
the
client-side
viewer
for
all
of
these
types,
the
balsamic,
the
sketch
the
notebook,
the
open
api.
All
of
that.
But
what
we
realized
was
that
we
could
take
a
shortcut
after
we
set
up
the
opr
that
we
could
just
prepare
a
solution
that
would
reuse
the
server-side
haml
based
viewers
into
the
new
view,
repository
app.
A
A
I've
already
rewrote
a
couple
like
the
video,
the
image,
the
download,
the
empty
and
the
text.
All
of
these
are
already
refactored
into
the
new
way,
so
these
are
already
leveraging
the
new
approach,
which
is
faster
and
improves
performance,
there's
still
a
lot
of
them
that
we
haven't
gotten
to
them
yet,
but
they're
working
so
in
essence,
they're
already
in
the
new
application
they're
just
not
as
fast
as
they
could
be.
A
So
our
our
idea.
That's
one
of
the
things
I
wrote
in
the
agenda.
Our
idea
is
that
I'll
have
the
okr
and
I
can
just
stop
sharing
the
screen.
The
idea
that
I
have
is
that
I'll
update
the
okr
text
to
not
mention
this
as
explicit
by
the
number
of
file
viewers,
but
more
like
support
all
the
viewers
and
enable
the
repository
browser
app
refactor
so
because
that
was
the
goal
initially.
A
What
we
wanted
to
say
with
this
goal
was
we'll
be
able
to
turn
on
the
repository
browser
refactored
right,
because
that's
what
brings
the
usability,
improvements
and
performance
improvements
to
the
users,
but
we
probably
could
have
awarded
it
better
and
so
yeah.
That's
what
I'm
looking
for
any
feedback.
Any
thoughts
does
it
sound.
That
is
I'm
good.
A
B
I
mean
there's
an
easier
way
to
do
it.
Let's
do
it
the
easier
way.
A
Yeah
the
big
the
biggest
difference,
so
that
it's
clear
is,
for
example,
when
we're
rendering
in
hamel
the
html
is
being
rendered
on
the
back
end
right.
So,
instead
of
us
having
like
imagine
a
file
of
200k,
we
transfer
those
to
100k.
A
It
doesn't
go
to
the
back
end
to
render
that
file,
but
some
of
them
most
of
them,
are
still
using
the
old
one,
and
I
think
we,
after
we
enabled
the
the
the
new
code
we'll
do
that
iteratively
and
probably
even
have
community
contributors
to
to
do
that,
because
it's
pretty
straightforward
for
some
of
the
files,
the
the
other
part
that
we're
probably
going
to
have
to
take
another
effort,
probably
in
the
next
quarter,
is
the.
Let
me
see
if
I
can
put
this
in
clear
words.
A
So
the
source
editor
that
we
were
using
as
read
only
isn't
there
isn't
a
good
enough
solution
because
of
the
syntax
highlighting
problems
we've
seen,
because
it's
leveraging
monaco
and
we're
we're
attempting
to
go
with
highlight
js
route
for
the
solution.
What
that
means
is
that
won't
be
a
solution
for
the
source
editor.
It
will
be
a
solution
for
the
source
code
repository
presenting
files.
A
A
Blames
that
show
code
we're
trying
to
move
that
highlighting
to
the
front
end
to
make
it
easier
for
the
back
end.
So
all
of
this
plays
into
that.
So
it's
going
to
be
a
longer
term
project,
but
I
just
want
to
highlight
that
it's
no
longer
what
we
expect
to
be
an
editor
project.
It
turned
out
that
this
would
probably
be
a
source,
a
source
code
project.
A
B
A
Not
so,
okay,
I
think
I
know
what
you're
saying
so.
The
file
blob
viewer
is
when
you're
on
the,
when
you're
transferring
when
you're
navigating
to
the
repository-
and
you
click
a
file,
you
go
to
the
blog
viewer.
Now
the
blob
viewer
can
have
two
modes,
one
is
the
raw
file
content
and
the
other
is
the
rendered
file
content
right
like
preview,
that's
what
you're
talking
about
yeah.
All
of
that
is
the
blob
viewer
and
both
of
those
modes
will
be
supported
by
the
new
refactor
that
we're
shipping
very
soon
right.
A
What
I'm
talking
about
it
here
is
whether
we
can
do
the
highlighting
on
the
front
end
or
we
have
to
do
the
highlighting
on
the
back
end
right
now
and
in
the
past
we
do
the
highlighting
it
on
the
back
end
and
we
receive
the
html
rendered
from
the
backend,
and
we
just
put
it
on
the
page.
What
we're
trying
to
do
is
we
only
get
the
file
content
from
the
back
end
and
we
present
it
in
the
front
end
completely
no
dependency
on
the
back
end.
That's
the
goal
in
the
future.
A
What
we
thought
we
could
do
was
right.
We
have
the
source
editor
that
they
created
on
the
editor
group,
which
is
like
a
monaco
editor
that
you
can
just
select
using
the
snippets.
We
can
put
it
in
read-only
mode
and
presented
it
as
a
fall
content
kind
of
thing,
but
he
had
a
bunch
of
problems.
He
had
mobile
problems.
A
The
source
editor
application
thing
separate
from
that.
What
it
does,
though,
is
the
the
transition
from
seeing
a
file
to
editing
that
file
you're,
probably
going
to
have
a
rift
between
the
highlighting,
for
example,
the
highlighting
on
the
content
of
the
file
will
be
different
than
when
you're
editing
it
because
it
uses
another
technology
we
deem
it
as
acceptable.
B
Do
you
think
yeah
I
mean
obviously
there's
right,
minimal
differences
acceptable
major
right
yeah.
I
don't
know
what
that
threshold
is,
but
you
know
I
I
would
anticipate
it
to
be.
I
mean
highlighting
is
doesn't
vary.
A
Some
files,
it
will
be
drastic,
though,
like
I
can
tell
you
that,
for
example,
what
will
happen
more
often
is,
for
you
know
some
obscure
files
we'll
have
the
highland
js.
Do
the
highlighting,
when
you're,
seeing
the
content
of
the
file
when
you
click
edit
monaco
might
not
have
it,
so
it
might
be
just
plain
guys,
but
that's
just
until
monaco
steps
up
the
the
support
of
the
languages,
there's
not
much.
We
can
do
in
that
regard.
We
can.
A
B
A
A
If
you
have
the
extension
installed
and
there
you
can
have
pretty
much
any
syntax
highlighting
you
want
right,
you
can
extend
it
to
your
own
taste,
so
we're
always
going
to
be
like
providing
a
a
good
enough
effort,
a
good
enough
solution
to
edit
things
on
the
browser,
which
is
convenience,
with
some
trade-offs.
Last
customization
that
sort
of
thing,
but
as
we
go
forward,
I
think
that
that
that
bridge
will
will
be.
A
B
Right
so.
B
So
that
kind
of
a
sidebar-
but
there
was
dennis,
had
put
together
that
kind
of
proof
of
concept
converge
request.
Is
that
still
valid.
A
A
He
has
support
for
one
of
the
themes,
because
what
what
highlight
js
does,
is
it
tokenizes
the
the
code
and
then
apply
certain
classes
to
certain
reserved
words
and
different
kinds
of
words
right
if
it's
a
variable,
if
it's
a
for
loop,
it's
those
kinds
of
things,
it
applies
classes,
but
then
we
have
to
provide.
A
The
styling
for
each
of
the
themes
we
have
to
write
at
least
one
file
per
theme
to
apply
that
look
to
those
classes
right
and
that's
one
of
the
efforts,
one
file
per
theme.
Moreover,
if
you
want
to
have
more
confined
grain
control
over
the
highlighting
for
certain
languages,
we
can
even
have
a
file
for
that
language.
For
that
theme
right
now,
our
initial
strategy
is
going
to
be
one
file
per
theme,
that'll
be
a
good
enough
starting
point
and
then
we'll
improve
support
as
we
go.
A
A
Awesome
sounds
great.
The
good
the
good
part
is
that
it's
also
front
end
only
so
we're
completely
free
to
play,
while
the
back
end
works
on
their
stuff.
A
A
Is
absolutely
key
player
into
the
whole
ecosystem,
but
let
back
into
the
back
end
part
and
let
the
front
end
of
the
front
end
part
and
we'll
be
much
more
happy.
There's
two
bridges
collaboration!
All
of
that,
but
yes,
there's
a
lot
of
stuff
that
we
can
do
at
the
front
and
much
easier
and
more
like
the
syntax.
Highlighting
is
one
of
them.
Instead
of
spending
a
shared
computation
in
a
shared
in
a
server
environment,
the
browser
itself
can
do
it
as
long
as
we
can
do
it
performantly.
A
B
A
So
funny
yeah
mike,
if
you,
if
you
go,
read
the
computer
science
history
book
you'll,
see
that
there's
always
been
a
ping-pong
movement.
You
see.
First,
we
had
the
big
mainframes
and
dumb
computers,
so
the
computing
was
done
on
the
server
and
then,
as
the
computers
became
bulkier,
the
personal
computers
became
bulkier.
You
could
do
more
things
right
now.
Let's
shift
the
computing
back
to
the
personal
computer
to
the
terminals
right
and
then
we
start
realizing
wait.
A
B
And
there
was,
I
forget
what
the
name
of
it
was,
but
there
was
there
was
that
gaming
company
that
yep
they
started
pushing
all
of
that
and
you
could
play
it
on
a
chromebook
just
like
you
were
playing
on
there.
So
it's
like
it,
it
does
it
well.
I
think
a
lot
was
ping
pong.
A
When
I,
when
I
was
doing
ux,
we
did
a
user
research
with
a
group
of
users
that,
with
that
kind
of
service,
where
the
game
servers
were
in
israel,
and
we
basically
made
the
same
game,
run
on
their
servers
and
on
a
on
a
local
pc.
A
B
B
B
A
B
A
A
Okay,
I'll
I'll
see
when
this
I'll
I'll
see
that
this
gets
posted
and
share
with
with
sarah,
and
so
we
can
get
this
topic
going
forward.
But
this
is
good
thanks
for
the
feedback.