►
From YouTube: N-API: The Next Generation Node.js API is Ready! - Michael Dawson, IBM & Arunesh Chandra, Microsoft
Description
The Native module ecosystem for Node.js is an important factor in the rapid growth of Node.js. The N-API is now a supported feature and is designed to provide ABI stability across Node.js releases. This will reduce friction in upgrading to newer Node.js versions in production deployments. In addition, it will reduce the maintenance cost that module maintainers previously had to take on due to the fast pace of changes in the v8 APIs. This talk will provide a progress update on this community project, the roadmap, and why now is the right time to get involved.
A
A
Alright,
so
we're
going
to
talk
about
today
is
how
an
API
is
going
to
help
improve
the
experienced
developer
experience
with
node.js
and,
more
specifically
around
how
it
is
help
going
to
improve
the
deployment
story
of
your
node.js
apps.
So
my
name
is
erina
Chandra
I'm,
a
seer
program
manager
on
Microsoft
edge
team
I've
been
working
on
the
node
community
for
summer
projects
like
napi,
the
no
trucker
core
project
and
some
developer
diagnostic
innovations
like
the
time-travel
debugging.
A
B
I'm
Michael
Dawson
IBM,
I'm
ibm's
community
lead
for
nodejs.
So
if
you've
been
involved
in
the
project,
you'll
see
that
I'm
active
in
a
lot
of
the
working
groups.
Obviously
in
the
n
API
team,
as
well
as
being
on
the
technical
steering
committee
and
on
the
community
committee,
I
also
get
to
work
with
a
lot
of
great
teams
within
IBM,
where
we've
done
really
interesting.
B
B
A
B
A
All
right,
so,
let's
start
with
some
basic
understanding
that
we
all
can
agree
about
the
the
relationship
of
nodejs
with
its
npm
module
ecosystem.
So,
first,
the
vast
module
ecosystem
makes
no
js'
more
powerful.
So
we
all
can
agree
that
you
know
the
the
module
ecosystem
you
know
is
we
find
value
in
that
and
that
is
generating
and
is
a
source
of
power
in
a
generating
powerful
impact
on
on
the
node.js
platform?
A
Nodejs
growth
depends
on
the
stability
of
this
ecosystem,
so
more
reliable
and
stable.
This
ecosystem
is
the
no
more
low
just
developers
are
going
to
be
relying
on
this
platform
and
it
is
going
to
help
fuel
the
growth
of
this
amazing
platform
that
we
all
know
and
love
and
the
third,
because
you
know
the
previous
two.
If
we
agree
on
that,
we
need
to
ensure
that
this
module
ecosystem
that
we
all
love
and
depend
on
has
to
be
preserved
and
strengthened
going
forward.
A
So
if
we
all
agree
with
this
today,
this
marginal
ecosystem
is
very
fragile
and
it
needs
help.
So
what
do
I
mean
by
that?
We
all
are
aware
of
you
know
this
particular
user
I
mean
this
error
that
you
know
you
see.
Module
was
not
compiled
against.
This
module
was
compiled
against
a
different
node.js
fortune,
I'm
sure
the
it
would
be
a
familiar
message
for
a
lot
of
people
and
what
the
problem
is
that
we
have
accepted
that
this
is
normal
and
we
have.
We
know
how
to
work
around
it.
A
We,
you
know,
I,
have
changed.
The
note,
dress
version
that
we
are
running
on
or
find
the
latest
version
of
the
module
and
match
it
together
and
it
works.
This
is
now
you
know.
This
is
basically
how
this
happens
quite
a
lot.
You
know
if
you
weeks
ago,
we
saw
an
instant
where
you
know,
deprecated
v-8
methods
actually
caused
modules
to
break
in
in
the
latest
node
version
and
the
surgeon
test.
A
So
this
is
not
how
a
mature
enterprise
ready
platform
is
supposed
to
work.
We
shouldn't
take
these
kind
of
failures.
As
an
accepted,
you
know
fact
of
your
programming
life,
so
there
got
to
be
a
better
way.
I
mean
there
has
to
be
a
better
way
to
kind
of
not
create
such
an
impact
on
the
entire
ecosystem,
with
every
node
release.
A
So
imagine
you
know
all
the
modules
are
living
peacefully
without
braking
and
it's
it's
easier.
If
you
imagine,
if
you
are
an
app
developer
with
note,
imagine
that
upgrading
node
was
was
easy.
You
know
it
was
easy
to
swap
back
and
forth
between
different
versions
of
node.
There
are
more
high
performance
native
modules
available
for
you
to
work
on
or
work
with,
and
all
these
modules
were
portable
across.
You
know
different
versions:
binaries
were
compatible
and
you
know
there
are
several
different
node
flavors
coming
up
in
the
market
as
well.
A
Let
know
chakra
for
is
one
spider,
node,
there's
another
one
which
is
work
on
iOS
with
GS
c
GS
core
engine.
So
these
all
these
different
flavors
of
node
will
not
work
with
the
existing
way.
The
native
modules
are
working
today.
So
with
with
imagine
that
you're
able
to
you
know,
take
your
app
take
any
note,
worsen
or
flavor
and
just
drop
it
in
and
it
works.
A
Imagine
if
you
are
a
module
maintainer
yourself.
Imagine
that
no
there's
no
code
update
required
or
no
new
boundaries.
You
have
to
create
to
support
a
new
node
version,
it's
easier
to
write
a
native
modules.
The
API
is
that
they
are
available
for
writing.
Named
modules
are
safe
and
well
defined
and
well
documented,
and
your
modules
will
run
on
different
flavors.
So
these
are
the
things
you
should
expect
from
a
mature
enterprise
ready
platform
and
it
we
are
not
there
yet
so
we're
gonna
be
covering
how
an
API
is
gonna.
A
A
An
API
enables
native
modules
to
just
work
across
these
different
versions
without
the
need
of
recompilation.
That's
the
key
word
here:
you
don't
need
to
have
this
recompilation
step
that
goes
on
today.
This
has
been
worked
on
by
in
a
variety
of
contributors
from
individual
contributors
from
the
community
and
also
had
people
working
from
these
node.js
foundation.
Member
companies
as
well.
So
this
has
a
very
broad-based
effort-
has
been
put
in
from
couple
years
now
to
bring
this
to
life.
A
So
some
quick
context
here
how
what
where
the
N
API
value
lies
so
a
long
time
ago
you
know
JavaScript
was
tied
to
the
browsers,
but
somewhere
along
the
way.
It
escaped
the
browser,
sandbox
and
landed
on
the
server
and
nodejs
revolutionized
the
the
use
of
JavaScript
on
the
server
and
to
meet
these
new
demands
of
server
application.
It
was
important
for
no.
A
Jurisdictional
at
forum,
so
hence
the
use
of
native
add-on
modules.
It
allowed
developers
to
extend
the
capabilities
of
node.js
but
building
native
libraries
and
exposing
them
to
to
choose
javascript
so
native
Iowan.
You
can
see
here.
Here's
some
sort
of
the
use
cases
accessing
native
API
is
on
the
platform
unavailable
with
JavaScript
derived
better
performance
for
compute
bound
code
using
C
C++,
and
occasionally
you
see
that
there
are
some
legacy.
C
C++
code
available
already
that
how
to
bring
it
into
your
JavaScript
app.
A
Here's
some
of
them-
but
you
know
sometimes
developer,
take
direct
dependency
on
these
native
modules
and
and
sometimes
they
don't
even
know-
and
it
comes
in
as
an
indirect
dependency,
but
it
all
kind
of
impacts.
Your
application,
whether
or
not
you
have
taken
drug
dependency
on
it
or
not,
and
by
some
estimate.
There's
30%
of
the
entire
module
module
ecosystem
depends
on
native
modules.
So
native
modules,
you
know,
has
a
very
important
role
to
play
in
our
ecosystem
and
we
need
to
take
care
of
it.
A
Where
you
know,
the
modules
used
to
break
every
noodle
release
would
require
module,
maintainer
x'
to
have
to
update
their
modules
to
support
new
version
old
versions.
Every
time
new
note
release
comes
out,
module
native
module
maintenance
will
have
to
change
some
code
to
support
the
new
release
and
module
consumers.
The
app
developer
have
to
wait
for
that
event
to
happen
that
you
know
you
either
look
for.
You
know,
wait
for
the
the
margin.
A
A
base
to
happen
or
if
your
modules
have
depend
on
NAND,
then
you
know
you
have
to
recompile
your
nan
modules
to
be
able
to
take
advantage
of
the
new
new
door
release
talking
about
nan
nan
was
the
first
attempt
to
solve
this
problem,
but
it
didn't
go
that
far
it
was
it
was.
You
know
it's
available
since
0.8
node
point
8.
It
has
done
a
pretty
good
job
so
far,
but
nan
can
only
provide
so
much
isolation.
A
A
It
introduces
a
bi-stable
layer,
as
you
can
see
in
this
graph
here.
Our
chart
you
can
this
introduced
an
a
bi-stable
there.
Nappy
modules
are
other
native
modules
that
depend
on
these
a
bi-stable.
There
are
guaranteed
to
work
across
different
verses
and
the
use
of
these
module.
The
napi
modules
will
improve
the
experience
of
the
developers,
who
are
maintaining
these
modules
and
for
the
users
who
are
using
it.
A
So
if,
if
we
imagine
this
world
that
the
all
the
native
modules
are
napi
based,
then
the
module
maintenance
don't
have
to
update
their
modules
to
support
new
neural
JS
versions
and
the
consumers
of
those
module.
They
don't
have
to
recompile
their
napi
modules
or
they
don't
have
to
wait
around
to
for
the
module
or
owners
to
bring
out
the
latest
support
for
their
new
node
versions.
So
this
is
certainly
you
know
one
way
of
making
sure
that
our
module
ecosystem
continues
to
be
robust
and
brings
out.
A
B
I'm
gonna
take
over
from
a
Rhenish,
hopefully
he's
painted
a
picture
of
where
we're
at
and
helped
you
imagine
a
world
where
it
could
be
better
and
to
start
out
to
sort
of
reinforce
that
I'm
gonna
start
by
taking
you
through
a
quick
demo
which
shows
the
experience
upgrading
from
version
8
to
version
10.
We
all
know
that
version
10
is
going
LTS
in
the
next
few
weeks,
and,
what's
my
experience
going
to
be
like
when
I
go
to
upgrade
my
application,
we
have
a
demo
application.
B
You
can
actually
go
to
the
repo
that
I
have
there
and
that's
one
where
you
can
check
it
out,
and
you
actually
can
you
know,
run
it
yourself,
showing
that
you
can
upgrade
and
change
between
different
versions
of
nodejs
and
have
the
application
continue
to
run
when
you're,
using
an
API
and
even
switch
between
different
flavors
of
nodejs
azure
ruch
mentioned.
There's
things
like
the
chakra
core
based
version,
and
you
can
compile
your
module
once
and
then
run
with
any
of
those
different
versions.
B
This
demo
was
a
simple
database
application
that
depends
on
a
single
native
module,
call
down
I've
precompiled
it.
So
I've
pre-installed
it
using
version
8
sort
of
as
my
base,
because
I'm
doing
an
8
to
10
upgrade
and
I'll
show
you
using
nvm
to
basically
switch
between
the
different
versions,
and
you
know
we'll
see
what
kind
of
experience
we
get.
B
My
application
make
sure
I
have
compilers
and
all
that
installed,
and
so
it's
really
not
a
great
experience.
Instead
with
any
PR
I'm
gonna
switch
back
to
version
8
and
start
up.
The
application
again
because
I'm
that's
my
baseline,
where
I'm
starting
from
we
see
the
application,
starts
up
just
fine
once
that's
up
and
running
I'm
gonna
kill
that
and
I'll
switch
over
to
version
10
and,
in
this
case
we're
using
a
version
of
level
down
that
we
compiled
using
an
API,
and
you
can
see
the
application
just
starts
up
and
runs
just
perfectly.
B
So
this
really
shows
the
experience
you
can.
You
can
expect,
when
you're
using
modules
that
we
have
today
versus
modules
that
we
hope
to
see
mostly
in
the
future,
when
you're
using
an
API,
we
upgrade
between
version,
8
and
10.
Everything
just
continues
to
run,
just
like
our
native
JavaScript
modules.
The
other
nice
thing
is:
if
I
have
this
in
production
and
I
discover
that,
for
some
reason,
I
want
to
go
back
to
version.
8
I
can
just
switch
back
to
the
version
8
event
of
node,
and
it
continues
to
run.
B
So
it
gives
me
the
flexibility
of
being
able
to
switch
back
and
forth
quite
easily,
which
is
really
a
good
thing.
So,
hopefully
you're
excited
about
any
pie.
You
want
to
be
using
in
the
questions.
Well,
first
of
all,
where
can
I
use
any
pie?
Well,
as
of
today,
you
can
use
it
in
all
the
different
LTS
versions:
it's
stable
in
version
10
and
version
8.
B
It's
still
technically
experimental
in
six
thought
X,
but
it's
a
documentation
only
experimental
there
won't
be
any
or
anything
else
when
you
actually
start
up
your
application
so
for
all
effective
purposes.
You
know
you
can
use
it
today
across
the
different
release
lines
and
for
version
six,
when
we
did
the
back
part,
we
had
to
make
a
few
extra
changes
and
that's
why
we
marked
as
experimental,
given
that
its
lifespan
is
only
till
next
April.
B
B
It's
built
into
node
core,
it's
part
of
the
standard,
API
Docs,
and
so
basically
you
know
you
would
just
include
node
underscore
API
dot
H
and
you
can
compile
against
the
methods
that
are
provided
there
and
all
I
have
some
slides
later
on
to
show
what
they
look
like
and
give
you
a
flavor
of
what
the
API
is
like.
The
thing
is,
though,
that
we
we
know
that
a
lot
of
people
develop
in
C++
and
for
a
lot
of
people
that
actually
can
be
much
more
effective.
B
Now,
when
you
use
it,
what
you
see
is
you
you
write
what's
on
the
top,
so
basically
I'm
creating
an
object
and
I'm
assigning
a
property
of
the
object.
Object,
I've
got
two
lines,
but
in
your
actual
code
that
you
compile
the
inline
C++
expands
to
the
code
we
see
below,
which
makes
the
NEP
I
sea
level
call.
So
you
know
calling
Nappi
create
object.
Navi
creates
string
UTF.
So
in
fact,
when
you're,
using
no
down
on
API,
you
really
just
are
using
the
C
API
is
there's
no
extra
dependencies.
B
Nothing
else
to
link
in
you
get
all
the
benefits
of
using
an
API,
the
ABI
stability,
because
you
really
are
just
writing
the
same
code
in
a
more
concise
and
more
compact
Manor.
So
that's
you
know.
One
of
the
key
things
about
no
data
API
is
that
it's
really
just
a
wrapper
for
writing
your
code
more
effectively
in
terms
of
the
API
shape
itself.
B
It's
basically
a
collection
of
C
api's.
As
I
said,
will
you
see
because
that
that's
easier
to
maintain
stability,
you'll
notice
that
every
function
returns
an
Appy
status?
So
basically,
you
know
this
is
a
standard
pattern
that
we
use.
If
you
get
an
Appy
okay,
that
means
you
know
what
you
requested
happened.
Everything
was
fine.
You
can
just
move
on
if
you
get
something
other
than
not
be
okay,
that
could
mean
one
of
two
things
there's
a
particular
status
code,
which
is
an
app
the
exception,
and
that
tells
you
that
an
exception
happens.
B
So,
for
example,
maybe
you
made
a
callback
to
JavaScript.
It
threw
an
exception
that
wasn't
caught.
It's
telling
you
that,
while
there's
an
exception
pending
and
once
you
return
from
your
native
code,
that
exception
will
percolate
up
through
the
stock
to
be
caught
or
to
be.
You
know
an
unhandled
exception
and
terminate
the
process
generally.
When
that
happens,
it
means
something's
gone
on
that
you
probably
don't
want
to
recover
from.
B
There
are
methods
in
the
API
like
Nappi,
get
and
clear
last
exception,
so
you
can
actually
handle
that
exception
if
you
want
to,
but
for
the
most
part
in
the
the
code
patterns,
you'll
see
you'll,
see
that
that
happened,
you'll
simply
do
whatever
cleanup
you
can
and
return,
so
the
exception
gets
thrown
normally.
The
other
thing
you'll
see
in
the
API
is
that,
oh
sorry
and
the
other,
otherwise
you
can
also
in
terms
of
Nappy
status.
B
You
can
also
get
something
that
tells
you,
for
example,
you
pass
the
wrong
parameters
to
the
sea
call
or
something
else
went
wrong
at
the
sea
level.
In
that
case,
there
might
also
be
an
exception
panning.
So
you
need
to
check
that
as
an
extra
check
in
that
those
cases,
the
other
common
pattern
is
that
the
first
parameter
is
always
in
a
p.m.
that's
an
opaque
token
that
you
need
to
pass
into
all
the
calls.
B
It
allows
us
to
contain
to
sort
of
maintain
state
behind
the
scenes
for
her
for
Nappi
itself,
and
the
other
thing
you
notice
is
because
we've
used
the
the
return
code.
All
you
know,
return
values
are
passed
back
to
you
through
to
an
in/out
type
pointer
like
we
show
for
the
the
result
here
to
go
through
and
get
all
the
documentation.
It's
all
you
know
like
I
said
it's
part
of
the
standard.
Nep
are
part
of
the
standard,
no
documentation,
and
you
can
also
just
look
at
the
note
underscore
API
for
the
functions
themselves.
B
B
So,
basically,
you
know
there'll
be
examples
for
ten
twelve,
possibly
for
nan
and
then
for
n
API
and
no
doubt
on
an
API,
of
course,
when
we
add
new
examples,
we're
focusing
more
on
any
P
I
and
and
no
doubt
on
API,
but
for
a
number
of
them
you
can
sort
of
compare
and
if
you're,
moving
from
nan,
for
example,
you
can
actually
look
at
the
example
and
see
what
was
done.
This
is
a
simple
example
here,
where
we
can
just
see
some
of
the
code.
B
B
You
have
your
M
and
your
callback
info
and
then
you
have
an
initialize
function
where
you
basically
can
create
a
sort
of
JavaScript
object,
which
is
your
function
and
you
pass
a
pointer
to
your
c
c
function,
and
then
you
return
that-
and
you
know
you
return
that
as
your
export,
so
that
when
you
require
that
method,
you
get
that
function,
you
can
call
the
method
and
if
you've
been
writing
no
modules.
You'll
see
that
we
have
nappy
modules
as
opposed
to
node
modules.
B
As
the
way
you
set
the
entry
point
into
the
native
module
itself.
This
shows
the
example
itself
again
use
you
know
the
C
API
is
fairly
straightforward,
we're
doing
very
basic
things
like
you
know:
we've
got
this
callback
info,
so
I
want
to
get
the
arguments
from
the
callback
info.
So
I
start
by
getting.
You
know
nap
to
get
callback
info.
I
get
the
arguments.
The
first
argument,
I
know,
is
the
callback
that
I
want
to
invoke
and
then
I
can
call.
B
You
know
nappy
create
UTF
utf-8
string
to
get
a
string
which
I'm
gonna
pass
to
that
callback,
which
I
call
in
in
the
last
part,
but
all
you
know,
should
be
fairly
straightforward.
When
you
take
a
look
at
it,
we
mentioned
note
note
at
any
P
I.
So
this
is
the
same
example,
but
written
using
the
C++
wrapper
and
we've
got
the
nan
version
and
the
note
add
on
API
version.
The
key
message
here
is
that
you
know
if
you're
using
then
it
should
not
be
that
big,
a
change
they
look
fairly
similar.
B
We
still
have,
like
our
know,
API
module
versus
node
module.
We
still
have
an
initialization
method
and,
if
anything,
the
calls
to
actually
create
the
objects,
get
access
to
the
parameters
and
all
that
are
a
bit
more
concise
than
banan.
We
didn't
make
it
an
exact
copy
because
we
wanted
to
make
it
like
sort
of
the
best
development
experience
we
could
as
as
opposed
to
just
taking
exactly
what
was
there.
It
needs
to
be
a
bit
different.
B
You
have
to
do
some
work
to
port
from
nan
anyway,
to
help
make
a
conversion,
because
we
know
a
lot
of
modules
will
start
out
in
nan.
Is
we
have
a
conversion
script
once
you've
checked
out
note
on
no
doubt
on
API,
you
can
use
that
conversion
script.
You
just
run
it
and
it
will
try
and
convert
as
much
as
it
can
from
nan
to
know
Dianna
on
API
I'd
say
it
probably
does
about
80%,
so
you
still
have
some
work
to
do,
but
it's
a
you
know,
it's
a
good
start.
B
So
what
are
people
saying
about
it?
Well,
there's
really
two
kind
of
things
that
we
hear
as
the
main
messages
when
people
are
talking
that
we
hear
people
talking
about
NEP
I,
both
which
I
think
are
really
great.
The
first
one
are
like
people
are
saying
hey.
This
is
this
is
really
important.
This
is
the
kind
of
thing
you
expect
to
see
in
a
mature
language,
and
you
know
we
wish
that
we
had
this
kind
of
API
before
people
seem
quite
positive
on
the
shape.
The
fact
that
you
know
it's
going
to
be
an
API.
B
They
can
write
to
across
versions,
and
just
that
you
know
hey.
This
is
a
sign
of
growth
for
the
project
and
for
note
itself
that
we're
starting
to
get
to
see
some
of
these,
these
more
key
components.
The
other
thing
which
is
is
not
something
we
necessarily
set
as
initial
goal,
but
is
really
good,
is
that
people
are
also
saying
that
they,
like
the
shape
enough,
that
it's
actually
making
their
life
easier
in
terms
of
developing
their
add-on
modules.
B
It's
like
I
went
to,
you
know,
write
a
new
module
and
boy
I
really
found
it
was
easy
to
use.
No
doubt
on
API
was
intuitive.
It
was
clear
and,
like
you
know,
it
was
even
easier
than
we'd
written
in
then
and
with
v8,
and
all
that
before
so
I
think
it's
a
really
good
message
that
people
are
saying
it's
easy
to
use
the
api's
and
the
tools
that
are
being
provided
and
easier
than
it
was
able
to
do
that
before.
B
This
is
just
a
concrete
example
of
this
ll
note
it's
another
project
within
the
the
node
project
and
there's
other
talks
today.
I'd
suggest
you
go
see
them
because
Diagnostics
are
also
very
important.
Well,
you
know.
This
is
an
example
where
you
know
Joey,
who
has
been
working
on.
It
was
pointing
out
that
the
code
became
much
simpler
after
moving
on
to
use
an
API,
so
I
think
that's
that's.
The
second
benefit
we're
seeing
and
people
talking
about
which
is
really
good.
B
Hopefully,
you're
really
excited
understand
the
problem
and
want
to
get
involved.
So
how
can
you
help
so,
if
you're
an
application
developer?
The
first
thing
you
can
do
did
move
your
life
closer
to
that
experience
where
we
just
saw
it
work
when
we
upgrade
it
from
eight
to
ten,
is
to
look
at
the
modules
that
you're
using
if
you're,
selecting
a
new
module
look
for
ones
which
have
an
API
we've
been
working
on
badges
so
that
module
owners
can
tag
their
modules
with
a
with
a
tag
that
says:
yeah
I'm
using
supporting
an
API.
B
We've
also
created
a
script
so
again
in
the
node
add-on
API
project.
If
you
check
that
out,
there's
a
script
and
some
documentation
that
goes
along
with
that.
That
will
help
you
identify
all
the
modules
in
your
project
which
aren't
using
an
API
and
which
potentially
you're
gonna
need
to
you
know,
upgrade
or
recompile
when
you
when
you
move
to
a
different
version,
and
so
if
you,
if
you
have
a
number
of
those,
you
know
comment
that
you
know
make
comments
and
talk
to
the
module
maintainer
x'
to
see
what
their
plans
are.
B
And
even
you
know,
if
you
have
one
at
which
you've
used,
there's
been
quite
a
few
people
who
have
actually
said
well:
I'm
gonna
port,
my
favorite
module,
so
that
you
know
I'm
can
contribute
back
to
the
the
module
itself
and
make
my
life
easier
as
well,
so
consider
porting
a
monkey
if
you're
a
module
maintainer.
Obviously
the
first
thing
is
to
port
your
module
to
napi.
B
B
You
know
you'll
you'll
increase
the
scope
of
people
who
can
help
out
on
that
front
and
then,
finally,
if
people
come
and
try
and
help
port,
your
modules
be
receptive,
help
to
review
those
and
see
if
you
can
figure
out,
if
you
can
land
those
again,
you
know
so
that
we
can
all
work
together
towards
that
sort
of
goal
of
not
having
to
recompile
on
the
upgrades
and
then.
Finally,
if
you,
if
you're,
really
excited,
we
have
an
N,
API
team
meeting
every
week,
where
we
prioritize
the
different
work
that
we're
doing
we
talk
about.
B
You
know
the
progress
we're
making
like,
for
example,
we
have
a
fairly
good
focus
now
on
or
we
had
a
fairly
good
focus
on
documentation.
We've
now
covered
all
the
API
is
in
no
doubt
own
API
and
we
have
and
we're
working
on
the
the
code
coverage
so
come
come
to
the
meeting,
it's
open
to
anybody
who
wants
to
get
involved
in
help
out,
so
we'd
really
like
to
see
you
there
and
finally,
we'll
just
leave
you
with
a
few
useful
links.
These
are
links
to
the
documentation,
how
to
get
involved.
B
There's
some
generators
for
generating
sample
projects,
so
you
know
those
are
some
good
places
to
get
started
if
you're
interested
and
then
finally
I'll
just
say
we
also
have
in
the
community
quarter
outside
afterwards.
We're
gonna
have
a
number
of
people
from
the
community
from
the
the
bein
API
team,
including
Nick
and
Gabriel,
who
are
here
and
I,
think
Jim
as
well.
So
a
number
of
the
people-
and
you
know
what
I'd
say
is
if
you're
interested
come
on
out.
We
had
a
similar
talk
last
year
and
we
got
a
number
of
new
contributors.