►
Description
In 2017 the V8 engine introduced built-in code coverage; the ability, during runtime, to track the executed lines, branches, functions, etc., of a program. This information is useful for: analyzing bottlenecks, finding unused code, and finding parts of a codebase that need more tests.
Realizing how valuable native coverage could be to the community, Ben made it a mission to expose this functionality in Node.js.
In JavaScript coverage had traditionally been facilitated by a clever hack; tools, like Istanbul, parse the code inserting no-op counters... While this parsing-based approach works, it has shortcomings: as the language evolves, parsers play catch up; counters decrease performance; counters sometimes break applications.
Implementing native coverage in Node.js, was an amazing opportunity for V8, Node.js, and the npm community to work together, and is an exciting success story.
A
So
thanks
for
joining
today,
I
know
it's
day,
two
so
I'm
sure
a
lot
of
folks
wrote
having
dinner
late
last
night,
like
us,
I'm
gonna,
be
talking
today
about
code
coverage,
which
is
a
topic
I'm,
really
passionate
about,
and
specifically
I'm
going
to
be
talking
about
code
coverage
as
it
relates
to
the
node.js
project
itself,
which
is
something
I've
worked
on
quite
a
bit
on
the
project.
My
name
is
Benjamin
Co
I'm
a
dpe
at
Google,
which
is
stands
for
a
developer
programs
engineer.
A
This
is
basically
what
you
get
if
you
smash
together
a
developer
evangelist
with
a
an
engineer
you
get
to
do
some
talking
like
this,
which
is
really
fun,
but
you
also
spend
a
lot
of
time
engineering
which
I
enjoy
so
good
for
folks
who
enjoy
both
things.
A
little
bit
more
detail
about
me.
I
was
the
third
employee
at
NPM,
incorporated
so
I've
been
involved
in
the
node.js
and
NPM
community
for
quite
a
few
years.
I
currently
work
on
node.js
client
libraries
at
Google's.
A
So
this
is
a
really
neat
role
where
basically,
my
team
works
with
teams
within
Google,
mostly
on
Google
cloud,
to
help
them
make
node.js
client
libraries
that
are
idiomatic
to
the
community
feel
like
a
normal
NPM
package,
even
though
not
all
the
teams
at
Google
necessarily
are
part
of
the
node.js
community.
I
in
the
world
of
open-source
I
contribute
yukti
yards,
which
I've
been
working
on
for
quite
a
few
years,
I
wrote
the
tool
NYC,
which
I'll
be
talking
about
in
this
presentation,
which
is
a
tool
for
collecting
code
coverage
and
I
contribute
to
node.js.
A
Actually,
I've
done
a
lot
of
work
on
coverage
and
node.js.
So
that's
why
I'm
talking
about
it
today?
Another
thing
I
really
like
is
I
edit.
This
specification
called
conventional
commits
org,
which
is
a
way
to
add
conventional
kind
of
structure
to
your
commit
messages
so
that
you
can
parse
them
and
automate
them
I'm,
Canadian,
naturally,
but
I
live
in
California,
no
one's
perfect
and
today.
A
So,
to
give
you
a
bit
more
detail
about
what
I'm
gonna
be
talking
about
today,
I'm
going
to
talk
about
what
exactly
code
coverage
is
and
give
you
a
little
bit
of
a
history
of
code
coverage
which
is
I
started
researching
this
talk.
It
was
surprisingly
interesting.
The
history
of
code
coverage,
I'm
gonna,
talk
about
what
it's
useful
for,
so
why
you
should
want
to
use
it
on
your
projects
and
how
we
use
it
on
the
node.js
project
ourselves
and
how
it
benefits
the
project.
A
I'm
gonna
for
folks
who
are
curious,
like
me,
I'm,
going
to
go
into
details
about
how
it
actually
works
behind
the
scenes
like
what's
actually
happening
and
I'm
going
to
talk
about
how
you
can
both
use
it
on
your
own
projects.
If
you
don't
currently
use
code
coverage
is
one
of
the
tools
for
for
your
open
source
projects.
I'm
going
to
talk
about
how
you
can
use
node.js
as
own
coverage
as
a
way
to
start
contributing
to
the
node.js
project,
I'm
going
to
show
you
what
our
coverage
looks
like.
A
So
what
is
code
coverage?
I
mean
the
simplest
explanation,
PRIZE
to
say
it's
a
way
of
tracking
the
execution
of
branches
in
your
programs.
So
if
you
have
an
if
an
an
else
statement,
you
can
run
your
program
of
coverage
and
it
will
keep
track
of
whether
the,
if
was
run,
say
three
times,
and
the
else
was
run
four
times.
So
it
gives
you
nice
analytics
about
how
how
your
program
executed
during
its
run
time.
As
you
probably
guessed
code
coverage,
was
invented
in
a
top-secret
Army
Biological
Laboratory.
This
is
a
joke.
A
You
probably
didn't
guess
that,
but
that's
true.
It
was
proposed
in
a
paper
called
a
method
for
systematic
error.
Analysis
of
digital
computer
programs
by
Jones,
C
Miller
in
1962
Declassified
in
1971,
and
what's
kind
of
interesting
about
this
is
I,
was
reading
the
paper
she's
actually
proposing
an
approach
to
using
coverage.
That's
really
similar
to
what
a
lot
of
people
think
of
when
they
think
of
coverage
today,
which
is
using
it
to
better
expand
the
test
suite
that
they
were
using
inside.
That
lab,
which
I
think
is
really
neat.
A
What
the
paper
suggests.
Basically,
is
that
you
take
a
program,
you
create
a
graph
of
the
different
paths
through
that
program
and
you
enumerate
the
exit
conditions
of
that
program,
and
then
you
use
this
chart
you've
made
to
create
some
more
tests
to
help
make
sure
you've
covered
that
entire
programs
exit
conditions
and
branches
through
that
program.
Kind
of
interesting
that
I
thought
that
this
paper
doesn't
talk
about
automating
it
and
mostly
talks
about
how
one
would
kind
of
draw
this
out
yourself
and
I
was
thinking.
If
you
think
about
1962,
there's
a
good
chance.
A
Maybe
even
the
program
was
punch
cards
so
like
that
you
can't
use
a
lot
of
the
methodologies
I'm
going
to
talk
about
in
this
talk
on
punch
cards
actually
I
think
would
be
harder
to
do
so
and
kind
of
see
why
someone
took
the
approach
of
doing
it
externally
on
piece
of
paper.
So
what's
happened
since
1962
well,
I
was
kind
of
doing
a
little
bit
more
of
a
literature
review.
It
turns
out.
A
A
Interestingly,
then,
by
1996
this
tool
Jakob
came
out
which
is
part
of
the
GCC
C
suite,
and
it
allows
you
to
collect
coverage
in
your
C
code,
and
it
has
a
lot
of
the
features
were
used
to
today.
So
it
has
branch
coverage
line
coverage.
It
gives
you
pretty
reports
out
the
other
end
and
luckily
they
weren't
sued
by
IBM,
because
I
had
no
clue.
A
Ibm
held
this
patent,
which
luckily
ran
out
in
2006,
so
the
tools
I've
worked
on
I,
don't
think
are
infringing
on
this
patent
right
now,
the
same
year,
1996
Java
1.1
also
was
released
with
coverage.
So
this
has
been
a
tool
in
the
Java
and
the
C
communities
for
quite
a
few
years,
jumping
to
the
node.js
community.
We
were
actually
a
little
late
to
the
game.
I
was
talking
to
so
so.
Our
first
kind
of
real
popular
tool
for
collecting
coverage
was
called
Yui
coverage
and
was
part
of
the
Yui
tool
suite.
A
This
apparently
did
not
come
out
until
a
Suprema
came
out,
so
if
this
prima
is
a
parser
for
JavaScript,
that
allows
you
to
kind
of
do
your
own
parsing,
and
this
is
actually
what
enabled
a
lot
of
these
JavaScript
based
coverage.
The
collectors
part
of
this
people
would
actually
transpile
down
to
Java
and
then
use
something
like
Jacob
to
collect
coverage
for
JavaScript.
A
A
So,
unlike
that
manually
drawn
chart,
I
showed
earlier
in
the
talk.
This
is
closer
to
what
you
might
think
of
as
a
coverage
report.
Today,
it's
a
nice
kind
of
human
readable
shows
you
the
code
that
ran
and
just
to
explain
it.
We
basically
see
the
code
that
wasn't
run
by
my
test
suite
or
by
some
run
of
my
processes
in
read.
The
code
that
is
in
yellow
is
a
branch
that
wasn't
executed,
so
this
line
might
have
run,
but
the
but
one
of
the
branches
on
the
line
did
it
execute
what's
interesting
about
this?
A
Is
it
shows
that
problem
in
the
node
codebase,
which
I'll
talk
about
later,
which
is
that
we
historically
collected
coverage
for
Linux,
but
not
for
Windows?
So
a
lot
of
the
time
we'd
have
these
false
negatives,
which
were
related
to
our
Windows
coverage.
The
other
interesting
thing
about
this
report:
it's
not
just
showing
you
what
lines
recovered,
it's
showing
you
how
many
times
they
were
executed,
and
so
this
is
kind
of
interesting.
You
can
actually
start
to
think
about
it
as
a
way
of
tracking
performance
analysis.
A
So
this
is
great.
This
is
kind
of
a
little
bit
of
a
history
of
coverage.
What
exactly
it
is,
but
what
is
it
actually
useful
for
I'm
gonna
start
by
showing
a
little
video
here
that
kind
of
shows
what
a
lot
of
people
think
of
when
they
think
of
test
coverage
and
what's
kind
of
interesting
about
this
too,
is
it's
also
really
close
to
the
approach
that
was
being
proposed
by
that
1962
paper
I
showed
at
the
start
of
the
talk,
and
this
is
using
coverage
as
a
way
to
better
expand
your
test
suite.
A
So
imagine
you
have
a
program,
you
can
add
NYC
to
your
program
to
actually
run
your
test
suite
with
the
coverage
being
collected.
So
then,
when
we
run
our
tests,
we
actually
see
that
we've
only
hit
50%
of
the
lines
of
code.
Here
we
can
then
go
back.
Add
an
additional
test.
Suite
go
back
and
run
our
program
and
see
if
we've
actually
exercised
the
lines
of
code,
we
are
trying
to
exercise
and
sure
enough.
A
A
Another
use
case
I
really
like
is
that
if
you
have
a
long
lived
open
source
project
like
yards
or
nodejs,
if
you
can
get
your
codebase
close
to
100%
coverage,
it's
easier
to
identify
whether
a
contribution
to
the
project
has
been
appropriately
tested.
So
imagine
that
I'm
working
on
an
open
source
project
and
I
get
a
pull
request.
That
looks
something
like
this
one
of
the
first
things
that
jumps
out
at
me
is
that
there's
no
no
new
tests
added
in
this
PR.
A
So
even
though
they'd
look
to
be
maybe
some
problems
with
this
meaning
of
life
method
like
it
looks
like
it
might
throw
an
exception,
because
it's
calling
a
method
on
a
number
that
doesn't
exist.
My
existing
test
suite
is
actually
going
to
pass.
This
is
because
it's
completely
new
functionality,
it
has
no
tests
written
for
it.
A
Another
interesting
thing
that
coverage
is
good
for
in
a
project,
though,
and
I've
seen
this
used
in
the
node.js
project
quite
a
bit
is
it
can
give
you
an
entry,
it
can
give
someone
an
idea
of
where
they
can
contribute
to
the
project.
So,
on
nodejs
for
the
node.js
project,
we
actually
published
nightly
coverage
reports
to
node.js
org,
and
these
reports,
which
look
something
like
this-
can
actually
be
a
really
good
place
for
someone
to
start
contributing
to
the
project.
A
So
this
is
an
actual
snapshot
of
a
night
of
coverage,
and
what
you
can
actually
see
here
is
you
can
see
that
you
know
our
coverage
is
pretty
good
tool
across
a
lot
of
the
codebase.
But
what
will
happen?
A
lot
of
the
time
is
when
a
new
features
added.
So
in
this
case
we
can
see
rim.
Raf
actually
has
quite
a
bit
lower
coverage
than
other
parts
of
the
codebase.
So
if
someone
looking
to
come
in
contribute
to
the
node.js
project,
I
would
read
happily
accept
patches
for
more
coverage
on
rim.
A
Raph
I,
don't
know
if
a
lot
of
people
even
knew,
we
have
Reimer
alpha,
node,
so
kind
of
a
call-out.
To
that
feature,
this
is
a
way
to
rim.
Wrap
is
a
way
to
delete
a
directory
recursively,
instead
of
just
a
single
file
and
directory,
but
great
place
to
start
contributing
to
the
project.
Looking
at
these
coverage
reports,
I
found
a
natural
example
from
earlier
in
the
week
and
I
thought
this
was
a
really
good
kind
of
canonical
one.
A
But
I
would
like
to
point
out
too
that
code
coverage
is
not
just
about
testing.
There's
other
interesting
approaches
you
can
use
it
for
one
such
approach
is
that
you
can
use
it
to
say
what
parts
of
my
program
should
I
think
about
optimizing
more.
So
this
is
again
from
the
full
test
suite
run
of
the
node.js
project.
A
We
can
see
that
a
few
of
the
lines
of
code
are
hit
22,000
times
during
that
test,
run
a
few
of
the
lines
of
code
or
hit
twice
if
I
was
coming
in
and
saying,
I
need
to
optimize
this
method
and
make
it
run
a
little
faster.
I'd
probably
want
to
put
more
work
in
optimising,
read
package
scope
which
gets
executed
22300
times
then
I'd
want
to
put
into
optimizing
err
require
ESM,
which
only
gets
called
two
times
in
kind
of
an
exceptional
case.
So
not
perfect.
A
A
So
we
have
a
little
bit
of
the
history
of
code
coverage.
We've
talked
a
little
bit
about
some
of
the
things.
I
think
it's
useful
for
I
now
for
the
kind
of
folks
who
are
curious
like
me
and
like
to
know
how
things
actually
work.
I
want
to
talk
a
bit
about
how
coverage
actually
does
work.
There's
two
main
approaches
that
I
can
think
of
for
collecting
coverage
in
the
JavaScript
world.
A
There's
the
compiled
based
approach
where
you
take
a
program,
you
transpile
it
with
something
like
babel
or
ASP,
Rima,
and
you
add
a
bunch
of
counters
in
that,
hopefully
don't
change
the
behavior
of
the
program.
The
other
interesting
approach
is:
there's
the
VM
level,
where
you're
not
actually
changing
the
initial
JavaScript
itself,
the
virtual
machine.
That's
running
your
JavaScript
at
the
end
of
the
days,
adding
some
additional
instruction
codes
that
collect
counters
as
your
program
runs
so
I'm
going
to
talk
about
both
of
those
approaches.
A
So
let's
take
this
really
simple
program
here:
it's
an
if
statement
with
an
else
statement
in
it
and
it
doesn't
look
like
that.
Outstation,
it's
probably
going
to
run,
but
all
this
programs
going
to
do
is
it's
going
to
run
hello
world
in
that,
if
block
so
imagine
that
we
wanted
to
instrument
this
for
coverage,
how
might
we
do
that?
Well,
what
we
basically
do-
and
this
is
what's
happening
today-
just
trim
down
a
little
bit-
something
like
Istanbul
or
NYC
takes
your
program.
A
It
rewrites
it
and
it
adds
all
these
counters
in
throughout
your
entire
program,
so
it
if
we
take
a
look
at
the
true
block
here.
If
true,
we
see
that
we're
incrementing
branch
to
0
and
statement
0.
If
we
happen
to
go
through
there,
we're
then
doing
the
same
console
out
info
we
did
before
if
we
were
to
go
into
that
else
block
somehow.
A
Obviously
you
don't
want
to
do
this
manually,
so
there
are
tools
available
that
do
this.
For
you,
one
I,
like
is
called
NYC.
You
can
just
type
NPM,
I,
NYC,
save
def
and
then
run
your
program.
The
same
way,
you'd
run
it
with
the
node
bin.
Usually
you
just
put
NYC
in
front
of
it
and
what
it's
actually
doing
behind
the
scenes
is
it's
capturing
your
programs
runtime.
A
Frankly,
I'm,
not
an
expert
on
it,
but
I
do
link
to
two
blog
posts
that
I
think
are
worth
reading
on.
What's
actually
technically
working
behind
the
scenes.
These
are
understanding.
V8
spike
code
by
my
colleague,
Francisca
Hinkleman
and
JavaScript
code
coverage
by
Jakob.
Gruber
I
did
put
my
slides
up
just
before
this
talk,
so
you
can
think
they
should
actually
be
links
you
can
click
to.
A
These
counters
are
actually
added
in
at
that
virtual
machine
kind
of
bytecode
level,
rather
than
at
that
source
code
level.
When
you're
using
the
v8
based
approach.
There's
some
advantages
to
this.
There
are
there's
no
instrumentation
step
necessary.
So
in
the
case
of
the
node.js
project,
actually
my
my
colleague
Anna
set
this
up.
Originally.
What
we
used
to
have
to
do
was
we
would
take
all
the
JavaScript
inside
the
node.js
project,
transpile
it
with
these
counters,
compile
it
into
the
node
executable.
A
Then
you
could
do
one
to
one
run
of
test
coverage
to
see
what
your
coverage
was
like.
If
you
hadn't
actually
written
the
test
that
hit
the
line
of
code,
you
were
hoping
you
hit.
You
had
to
untransformed
just
your
code,
ree
transpile.
It
rebuild
the
node
executable
and
then
maybe
you've
hit
a
few
more
lines
of
coverage,
and
this
created
a
feedback
loop.
That
was
really
slow
on
the
node
project
for
our
coverage,
so
it's
nice
to
be
able
to
what's
nice
now.
Is
we
don't
do
this
translation
step?
A
We
can
just
run
the
node
project
like
we
would
normally
with
coverage,
enabled
and
use
this
for
our
coverage
collection.
Furthermore,
it
was
significantly
faster
for
the
node.js
project.
It
ran
I'd,
say
three
or
four
times
as
fast
using
it
in
the
v8
based
approach
rather
than
transpiling.
All
the
code
I
put
a
little
asterisks
here,
because
NYC
is
pretty
fast
because
it
aggressively
caches.
It's
a
really
mature
project.
So
you
know
it's
not
always
gonna
be
the
case
that
using
the
v8
based
approach
is
faster
for
you.
A
I
do
feel,
however,
it's
less
error-prone
so,
as
I
said,
the
way
that
coverage
has
worked
with
Istanbul
or
NYC,
or
a
lot
of
these
tools
is
it
takes.
Your
big
computer
program
tries
to
make
a
new
computer
program
that
just
has
thousands
of
counters
thrown
into
it.
There's
been
a
variety
of
bugs
throughout
the
years
of
working
on
Istanbul
that
we
just
put
a
counter
in
the
wrong
place,
and
now
your
program
behaves
differently.
A
It's
hard
to
get
it
perfect.
All
the
time
we're
shockingly.
We
get
few
bug
reports,
but
it's
from
years
of
debugging,
weird
edge
cases
around
adding
these
counters
into
your
programs
and
it's
harder
than
one
might
think
enabling
this
coverage
in
the
VM.
It's
really
easy.
We
have
actually
built
it
into
node.js
itself.
So
if
you
take
the
latest
version
of
node,
node,
14
off
github
or
node
13,
and
you
set
this
environment,
variable
node
underscore
v8
underscore
coverage
and
you
give
it
an
output
folder.
A
And
then
you
run
your
program
as
you
would
usually
run
your
program.
You
will
actually
end
up
getting
a
bunch
of
inspector
coverage
information
out
to
that
output
folder.
So
it's
built
in
you'll
just
end
these
just
raw
JSON
files
get
output
that
tell
you
what's
been
executed.
These
JSON
files
are
hard
to
consume.
They
don't
give
you
a
pretty
visual
report.
I've
written
a
tool
linked
here
called
c8.
A
It
literally
just
turns
on
this
variable
at
the
top
here
and,
having
turned
that
variable
on
gives
you
pretty
reports
at
the
other
side
and
lets
you,
you
know,
see
something
more
human
readable
from
those
reports,
so
we've
kind
of
given
you
a
bit
of
a
history.
We've
talked
about
how
coverage
works
to
a
certain
degree,
so
why
do
I
like
coverage
or
like?
Why
do
I
like
using
it
so
much?
Why
is
it
something
I've
taken
the
time
to
contribute
to
the
node.js
project?
A
Well,
for
one,
it
helps
me
find
parts
of
my
code
bases
that
could
be,
could
use
more
testing
and
I
mean
even
you
can
be
the
best
engineer
in
the
world.
You're
not
perfect
and
I
definitely
find
the
parts
of
my
codebase
that
I,
haven't,
read
and
test
for
are
always
broken
in
every
imaginable
way.
I
think
I'm,
working
with
numbers
they're
actually
strings
just
everything's
wrong
with
it.
I
find
that
using
coverage
to
find
those
untested
parts.
My
program
just
helps
me
write
more
stable
applications.
A
It
also
helps
me
have
more
trusting
contributions
being
made
to
my
projects,
though
so
so
for
a
project
like
yards
I've,
actually
taken
the
time
to
gradually
get
it
up
to
a
hundred
percent
coverage
over
the
years.
Helps
me
know
that
those
new
features
coming
in
are
keeping
that
same
baseline
level
of
we've
at
least
demonstrated
every
new
feature
added
runs
as
as
claimed
it
doesn't
make
your
program
perfect.
A
Well,
there's
a
couple
tools
available
that
I've
already
referenced
a
few
times
in
this
talk,
but
if
you
haven't
taken
a
picture
or
written
them
down
yet
do
so
now,
there's
this
tool
called
NYC.
It
can
be
found
at
Istanbul,
Jay
s,
slash
NYC,
and
it
does
that
approach.
That
I
was
talking
about
where
it
takes
your
code,
rewrites
it
with
counters,
automatically
completely
invisible
to
you
and
can
then
use
that
to
collect
coverage.
A
A
So
it's
neat,
it's
very
portable
once
you've
done
so,
though
you
can
just
run
your
program
like
you
would
usually
run
your
program
with
this
NYC
bin
in
front
of
it,
and
it
just
magically
gives
you
this
coverage
information,
the
other
tool
that
I
don't
think
too
many
folks
know
about.
Yet
we
use
this
on
the
node
project
itself
and
I
use
it
for
a
lot
of
my
open
source
right
now.
Is
this
tool
called
Beco
slash,
c8
I'll,
probably
move
it
into
the
Istanbul
org,
eventually
yeah
and
all
it
does
literally
is
turn
on.
A
V8
s--.
It
turns
on
no
GS
is
coverage.
Collection
environment
variable
gives
you
the
exact
same
pretty
reports
as
NYC.
It
literally
uses
the
same
part
of
NYC
use
code
base
that
does
the
reporting
and
instead
of
typing
NYC
my
program.
You
actually
get
to
save
a
character
and
just
type
c8
my
program,
so
it's
actually
even
more
efficient
in
that
regard.
A
We
just
run
with
this
environment
variable,
and
then
you
see
8
to
make
reports
at
the
other
end
so
see
it
can
just
take
that
raw
output
give
you
reports,
so
we
use
the
bottom
approach
for
node,
so
now
kind
of
getting
back
to
that
topic
of
using
coverage
to
contribute
to
node
J
s.
This
is
a
snapshot
of
coverage,
node.js
org,
an
exciting
thing:
I've
been
working
on
recently
with
rich,
who
I
see
sitting
in
the
corner
there
I'm
gonna
call
him
out.
Is
we
now
have
this
nightly
code
cover
apart?
A
We
put
up
and
what's
neat
about
this-
is
this
actually
takes
the
combined
coverage
of
our
windows
and
our
Linux
test
builds
so
that
if
you
go
to
this
top
report,
you're
less
likely
to
get
these
false
negatives
where
it
looks
like
we
haven't
covered
any
of
the
windows
code,
but
actually
we
did
cover
that
in
Windows
tests,
just
not
in
our
Linux
tests.
So
if
you're
thinking
about
contributing
to
the
project,
I
would
start
by
looking
at
the
coverage
reports
in
this
combined
report.
A
What
we
also
have
is
a
nightly
Linux
branch
coverage
report.
This
is
just
more
detailed
report
that
gives
you
a
lot
more
specifics
about
the
branches
that
have
executed
execution
counts.
You
see
the
left
in
the
rate
of
a
ternary
operator,
so
a
little
bit
more
detailed.
We
also
have
our
c++
coverage
reports,
which
are
linked
to
here
kind
of
a
throwback
to
the
history
of
coverage.
A
These
actually
do
use
G
curve,
so
it
hasn't
changed
much
since
1996,
except
we
use
a
tool
called
G
cover,
which
I
believe
gives
a
nicer
nicer
record
out
the
other
end
and
makes
it
easier
to
instrument
your
code
base
with
it.
So
there's
that
so,
if
you
do
want
to
contribute
to
the
node.js
project-
and
you
do
want
to
like
look
at
these
coverage
reports
and
maybe
increase
rim
rafts
coverage,
the
heads
very
much
appreciate
that
feel
free
to
flag
me
on
github.
A
You
can
find
me
at
github,
comm,
slash,
Beco
and
also
I'm,
always
open
to
talking
to
folks
on
Twitter,
so
you
can
go
to
twitter.com,
slash
Benjamin,
Coe,
always
happy
to
answer
questions.
Just
talk
with
people.
I'll
also
be
here
for
the
rest
of
the
day.
So
if
you
prefer
in
real
life,
I
will
be
on
the
stage
for
the
next
few.
It's
I
don't
know
no
I,
don't
think
I've
was
too
too
fast,
so
I'll
be
here
for
five
minutes
and
so
feel
free
to
come
talk
to
me.
Thank
you
very
much.