►
From YouTube: Closing Keynote
Description
Closing Keynote - These keynotes will be State of the Unions and will include:
Alexandre Strzelewicz- Overview of PM2 V2
Cian Ó Maidín- nearForm Lightning Talk
Kat Marchán- npm CLI: Where It's At, Where It's Going
Doug Wilson- State of the Union: Express
A
Hey
everybody,
alright
how's
everybody
doing.
Is
it
get
a
conference?
You
have
a
fun
time,
all
right,
little
deep,
yeah,
yeah
I'd
get
it
you're
tired!
It's
been
a
few
days.
You
still
get
everybody
sticking
around
for
the
club,
we're
into
some
in
the
next
two
days
right:
everybody's
ready
for
another
two
days
of
just
coding.
A
Okay,
awesome
awesome,
all
right!
So,
first
up
we're
gonna
have
we
were
so
lucky
to
get
this
talk
actually
kind
of
last
minute,
but
I'm
really
excited
about
it,
because
PM
2's
become
like
something
that
everybody
seems
to
be
talking
about
it
kind
of,
depending
on
somebody
give
it
up
for
Alexander
to
talk
about
his
project
p.m.
and
how
much
you
all
love
it.
B
Hi
hi,
so
okay,
lightning
talk,
I'm,
not
used
to
that.
So
I
will
try
to
go.
It
fast,
go
fast.
So
basically,
pm-2
is
a
process
manager
I
built
three
years
ago
with
the
community
and
it's
a
process
manager
that
allows
you
to
keep
alive
your
website
and
make
it
more
performant.
In
prediction:
environment,
it's
on
github
and
you
can
star
it.
B
B
B
Ok,
so
I
just
thought
with
like
a
simple
application:
I
don't
know
if
you
can
see
it
clearly,
but
this
is
like
a
simple
HTTP
application
that
you
run
like
it's
an
Express
server.
Basically,
you
do
not
my
application
that
G
has
to
start
it,
but
now
you
can
do
like
to
can
start
it
with
p.m.
so
p.m.
to
start
my
energy
application
and
after
you
can
use
the
cluster
mode
so
directly
with
e
max.
B
You
can
say,
I
want
to
make
this
application
cluster
like,
depending
on
the
number
of
CPUs
automatically,
so
before,
just
launching
this
command
I
lunch
p.m.
2
minutes
and
basically,
when
I
start,
my
application
now
I
can
see
that
this
application
is
been
has
been,
has
been
clustering
for
processes.
B
So
you
don't
need
to
change
anything
on
your
code
that
you
just
do
PM
to
start
the
application
and
we
start
the
application
in
Crystal
mode,
making,
much
more
readable
and
and
and
performant.
There
is
also
the
reload
without
that
he
done
time,
so
you
do
p.m.
to
reload
all
and
it
will
reload.
Your
application.
Will
pop
for
new
processes
will
wait
that
the
old,
like
processes,
all
the
requests
and
the
for
new
one,
will
take
place
after
you
have
lecture.
You
can
declare
each
application
into
a
pro
into
a
configuration
file.
So,
for
example,.
B
You
can
see
there
that
there
is
like
it
so
yeah
Mel
file,
but
it
can
be
a
JSON
file,
so
I
have
a
Web
API.
That
would
start
this
application.
That
is,
and
also
I
have
the
Walker
app
that
stopped
the
Walker.
The
jas
and
I'll
check
that
to
the
bash
script
so
directly,
I
just
stopped
my
application,
like
that.
I
just
start
the
process
30ml
file
and
it
starts
your
application.
B
Sorry
for
the
display
it
stuck
all
the
application
very
easily,
so
it's
very
convenient
after
you
can
restart
all
this
application
just
by
doing
p.m.
to
restart
process
that
Gmail
and
it
will
restart
each
applications
so
after
what
can
I
show.
So
basically
this
is
it
problem
to
like
we
just
published
the
version
2
of
p.m.
to
yesterday.
So
there
are
a
lot
of
enhancement
for
Windows
for
like
less
CPU
and
memory
usage
and
and
docker
integration.
B
So
we
made
like
a
special
light
CLI
that
you
can
put
into
your
docker
file
to
directly
let
p.m.
to
manage
on
ogs
processes.
So
it's
going
to
throw
out
all
the
sign
oles
and
do
graceful
stop.
So
it's
better
for
prediction,
docker
container
and
we
also
built
something
like
like.
Let's
say
you
have
this
application,
but
this
application,
unfortunately,
as
you
v8
profiler,
so
it
needs
like
a
native
compilation.
So
now
you
can
do
like
something
like
p.m.
to
do.
Curl,
dev
and
you
say
which
application
you
want
to
start.
B
When
you
do
this,
it
generated
okra
filer
that
is
automatic,
configure,
ok,
up,
I
start
this
application,
it's
a
do,
a
dokuro
build
and
after
it
was
Duke
I
run.
So
now,
I
can
go
to
my
browser
and
just
like
walks
and
basically,
what
happened
during
this
phase
is
that
we
generate
the
dockerfile,
the
dockerfile
that
integrate
like
different
things,
so
it
installed
p.m.
to
it
then
install
the
beat
cop.
I
the
package.json,
into
into
the
docker,
it
doesn't
end
came
install
inside
it
and
after
it
does
like
run
dev
comment.
B
B
It
will
not
be
as
a
volume,
but
we
do
like
a
row
copy
of
your
source
code
into
the
docker
container
and
after
directly
you
can
you
see
there
is
a
graceful
shutdown
and
after
you
can
just
do
Kirk
remit
and
docker
push
like
this
container
that
is
pre-configured
directly
into
production.
So
now
I
would
go
fast,
but
I
made
the
announcement
when
I
was
GS,
convinced
I
know
it's
about
grid
control,
it's
about
making
p.m.
to
connect
it
together.
It's
like
a
network
layer
that
we
built
on
top
of
p.m.
B
that
allows
you
to
reproduce
like
the
Amazon
AWS
long-dead
systems,
but
on
promise
on
your
own
servers
with
like
discovery
system,
peer-to-peer
fight,
transfer
thanks
to
Macintosh
and
a
power
drive
and
with
like
a
pub
sub
system.
That
is
that
looks
like
your
the
Amazon
AWS
lambda.
So
basically,
I
will
go
very
fast,
but
you
do
greet
some
pearl.
It
will
generate
like
this
kind
of
file.
So
it's
a
Phi
that
integrated
public
key
and
the
private
as
SSH
key
and
after
you
say
the
list
of
servers
you
want
to
provision.
B
Once
you
have
this
file
configured,
you
just
do
grid
provision
grid
provision.
It
will
go
to
it.
We
s
attached
to
each
machines.
It
will
install
everything
you
needed
like
you,
don't
need
to
install
anything
like
in
a
row
server.
It
works
very
well
and
after
an
suji
that
you
will
be
able
to
see
like
this
list
of
servers,
so
basically
I'm
just
going
okay,
hello,
just
this
is
the
thing
if
you
haven't
looked
at
it.
B
Toto,
yes,
I
do
npm
install,
so
this
is
like
a
sample
application
to
use
a
grid,
so
it
will
install
a
api
to
a
found
you
sim
in
see
sample
API
to
to
interact
with
the
grid.
Okay,
and
now
you
can
see
that
there
is
like
a
task
folder
with
some
tasks
on
it
like,
for
example,
echo
dijiye.
So
you
can
see
that's
a
bit
like
Amazon
AWS
lambda.
It's
like
it
takes
a
first
argument
like
parameters
and
a
callback.
B
B
Jiggly's,
so
this
is
like
a
small
dashboard
that
tells
you
to
see
the
progress
of
the
synchronisation
of
each
node.
So
now
you
can
see
that
each
node
has
been
synchronized
with
that
sauce
files
and
if
we
go
back
to
or
code
them,
you
can
see
that
now
the
private
IP,
because,
like
it
in
the
local
network
change,
so
this
request
is
being
executed
on
each
computer
in
a
run
would
be
no
way.
So
you
have
like
a
very
scalable
way
of
developing
micro-services
application.
B
Yes
and
I.
Think
almost
done.
I
just
show
something
else.
Like
a
binocs
I'll
try.
Okay,
there
is
like
something.
For
example,
you
can
trigger
a
task,
a
task
that
does
that
use
the
request,
module
and
that
ask
for
the
public
IP.
But
as
this
computer
has
are
in
the
private
network,
they
will
get
the
same
IP.
B
But
basically
so
it's
a
way
of
doing
micro
services
based
on
the
Amazon
AWS
lambda,
and
if
you
want
to
check
it
out
and
it's
unfortunate
I
cannot
do
deeper
on
this
project,
but
it's
already
on
open
source
and
we
published
it
when
we
could
go
at
the
GS
con
China
and
you
can
check
it
out.
It's
grid
control,
flash
glueten
flow.
Thank
you.
So
much.
A
C
Hi
everyone
I
am
a
tail
that
is
the
name
of
qiyan.
Our
CEO
on
the
on
the
agenda
is
skinny.
Sorry
is
doesn't
feel
very
well
today
and
he
couldn't
make
it
and
yeah.
That
is
my
slide.
If
you,
if
you
see
how
long
ago
I
did
I
did
it
over
there
one
second
ago,
so
yes,
so
I
work
with
a
company
called
me.
A
firm
I,
don't
know
how
many
of
you
know
us,
probably
some
of
you
have
known
as
at
the
booth
or
some
other
conferences
or
through
our
or
out
open
source.
C
Our
open
source
work
near
firm
is
a
company
rotated
in
the
in
open
source.
Even
though
we
are
in
a
tough
business
which
we
do
services,
we
do
professional
services,
we
are
a
consultancy
company.
We
own
companies
about
adopt
no
js'
at
scale,
and
we
do
so
by
using
open
source
modules.
We
do
not
Jas,
we
do
all
the
other.
We
do
all
the
things
that
you
can
imagine
from
a
consultancy
company.
C
I
just
want
to
tell
you
how
I
started
working
with
with
with
with
me
our
firm,
because
I
think
it's
a
nice
experience
of
what
we
are
and
what
what
is
important
in
open
source
I
was
visiting
was
in
Ireland,
visiting
University.
Doing
my
PhD
and
I
did
a
nice
open
source
module
called
level
graph,
a
colleague
of
key
and
Dominic
star,
you
probably
know
Dominick
right
and
I
was
working
in
level
and
said:
oh,
it's
so
nice,
so
cool!
C
You
should
come
down
to
the
office
down
in
Waterford
and
they
make
me
we
had
dinner
together
and
after
some
months,
I
joined
the
family
and
started
working
part
time
at
the
beginning,
but
whatever
and
yes
so
near
from
roots,
is
it's
in
open
source
and
we
use
open
source
and
we
build
open
source
tools
that
are
that
are
useful
for
for
the
community,
and
we
contribute
to
not
core.
We
sponsor
a
lot
of
stuff
that
you
guys
are
probably
using
every
day,
even
though
maybe
we
are
a
little
bit
on
the
side.
C
Respect
of
the
big
products
that
that
you
might
see
and
flashy
flashy
things
so
I
would
really
first
of
all
like
to
thanks
all
of
you
because
I
we
wouldn't
be
here
if
it
wasn't
for
this
amazing
community,
for
this
amazing
ride.
That
is
not
Jes
and
it
has
been
first
of
all
an
honor
for
us
to
be
here
and
to
be
part
of
this
community
and
we
try
to
help
in
any
possible
ways
if
we
can
amp
you
commercially.
C
We
are
happy
to
do
that,
but
if
we
just
need
help
for
with
an
open
source
with
core
with
some
performance
whatever,
if
you
just
want
to
learn
note,
we
are
here
to
help
so
I
still
2
minutes
left
and
I'm
half
run
now.
What
what
I
was
planning
to
talk
about
anyway
and
I
think
that
I
would
like
to
say
it's
did
when
we
go
in
with
with
most
of
our
customers
and
when
we
do
our
job.
We
use
a
frameworks
like
happy.
So
probably
most
a
lot
of
you
ever
I've
used.
C
Express
have
use
happy,
and
all
of
these
are
born
because
of
the
open
source
community
and
how
we
made
sense
together.
So
near
form
is
a
good
company
and
we
are
almost
100
yeah.
We
are
hiding
but
I'm,
not
saying
this
and
I
again.
We
would
really
like
to
thank
you
all
for
for
being
here
and
to
watch
me,
rambling
and
I,
invite
Michael
back
to
the
stage
and
kick
me
out,
because
it
has
been
a
fun,
a
fun
thing,
throwing
throwing
at
this
again.
I
want
again
thanks
thanks
to
all
of
you
and
I'm.
A
All
right,
okay,
everybody
so
I,
don't
think
that
any
of
us
would
actually
be
able
to
do
anything
with
node
without
NPM.
So
it's
great
to
have
somebody
from
NPM
Inc
cat
March
and
please
come
up
to
the
stage
and
tell
us
all
about
this.
What's
going
on
in
the
State
of
the
Union,
with
NPM,
give
it
up
everybody.
D
All
right,
this
works
hear
me:
oh
my
gosh,
okay,
hi,
hi,
I'm,
Kat,
Marchan
I
am
part
of
the
NPM
CLI
team.
That
means
I,
actually
I
actually
code,
on
the
actual
thing
that
you
install
on
your
machines,
we're
a
pretty
small
team
I'm
here
to
give
you
a
little
update
on
the
general
state
of
the
CLI
updates
on
what
we've
been
doing
and
just
go
over
our
plans
for
the
future
with
y'all.
D
D
There's
a
few
breaking
changes
there
that
I
want
to
talk
about
NPM
at
five.
We
kind
of
just
decided
that
we're
going
to
do
that.
One!
It's
coming
out
early
next
year,
most
likely
I
want
to
give
an
update
about
our
LTS
policy
because
we
have
a
different
one
than
one.
D
It's
come
a
long
way
since
300
and
three
three
like
I
know
that
a
lot
of
you
early
adopters-
and
you
saw
you
saw
like
oh,
maybe
it's
too
slow,
maybe
the
the
the
progress
bar
was
slowing,
some
things
down,
or
there
were
still
some
some
issues
with
the
Installer.
That's
not
really
what
NPM
3
is
like
anymore.
Npm
3
is
a
very
different
beast
as
of
3:10,
something
which
is
what
we're
at
right
now
I.
Think
3,
10
8
is
latest.
D
D
Next,
this
just
quick
warning.
It's
an
animated
gif.
This
is
what
the
new
progress
bar
looks
like
I
like
putting
this
gif
up
here,
because
it's
actually
really
cool.
It's
really
fast.
It
is
based
on
an
open
source
project
called
gauge,
which
is
maintained
by
one
of
our
one
of
the
other
developers,
Rebecca
Rebecca
Turner.
You
know
if
you
disable
that
before
just
go
ahead
and
rename
it
it's
fine
now,
so
that's
all
for
that
gift.
There's
a
few
other
things.
We've
been
doing
for
NPM
at
three
in
the
past
year.
D
That
includes
a
project
to
get
Travis
fully
green
all
the
time
and
just
make
sure
that
we're
doing
that
that
was
actually
pretty
hard.
We
have
our
entire
test
suite
running
on
Windows
and
passing
on
Windows
consistently
Windows
users
in
general
see
a
vastly
improved
experience
using
NPM
3
directly.
Now
you
don't
you
shouldn't
need
any
like
compatibility
layers
or
anything
like
that
to
get
a
really
good
experience
with
NPM.
We've
been
also
been
doing
a
big
bugs
push
for
the
past
few
months
to
iron
out
some
of
the
gnarly
bugs
and
corner
cases.
D
We
define
big
bugs,
like
you
might
see
that
term.
If
you're
like
in
the
issue
tracker
or
something
like
that,
so
a
big
bug
is
any
issue
that
either
produces
an
invalid,
install
or
crashes
the
CLI
invalid
or
inconsistent,
or
something
like
that.
It's,
like
you,
install
the
wrong
thing,
there's
a
few
of
those
and
turns
out
that
they
they
kind
of
they
kind
of
sit
in
the
little
corner
cases,
because
the
NPM
does
a
lot
of
things.
D
You
know
you're
talking
about
that
dependencies
and
and
and
bundle
and
shrink
wrap
and
speaking
of
shrink
wrap.
We
have
a
really
major
redesign
of
shrink,
wrap
coming
up,
supposedly
apparently
I
think
so
it's
going
to
be
great.
That's
what
I'm
PM
5
is
going
to
be
about
I'll
talk
about
that,
a
little
more
when
I
get
to
that
part.
D
D
We've
been
collecting
a
few
small
breaking
changes
over
time
and
we're
like
well,
let's
just
let's
just
do
a
couple
of
them
now.
Part
of
the
other
purpose
of
that
is
kind
of
too
close
to
book
on
the
whole
NPM
to
versus
NPM
three
thing
so,
like
people
still
have
a
perception
that
these
are
two
different
things.
Some
of
that
perception
was
like
from
the
original
release,
so
we're
like.
Okay,
let's
just
get
to
note,
get
to
NPM
four,
let's
move
on.
D
Let's
just
make
sure
that
people
are
on
the
latest
version
as
much
as
possible.
You'll
also
see
more
regular
semver
major
changes
after
NPM
four
comes
out,
which
is
well
actually
I'm
going
to
talk
about.
What's
actually,
I
can
see
em
for
there's
on
there's
three
major
changes
that
I
want
to
talk
about.
D
The
first
one
is
this
patch,
so
right
now,
if
you're
using
NPM
your
note
path
of
the
node
that
is
running
the
CLI
that
you
just
ran,
it's
going
to
be
prepended
to
your
to
your
path
variable
when
you
run
NPM
scripts,
this
seems
kind
of
benign
and
like
okay,
that's
convenient.
Sometimes
it
is
like
some
people
really
want
to
make
sure
they
get
this
NPM
to
run
your
scripts.
On
the
other
hand,
it
breaks
a
lot
of
systems,
it
breaks,
NYC
and
Instanbul.
It
can
break
a
pythons
virtual
end.
D
It
can
break
things
like
RVM,
anything
that
manipulates
the
environment
can
have
its
work
kind
of
overridden.
So
instead
we're
going
to
make
it
an
optional
flag.
There's
going
to
be
a
couple
of
other
options
for
people
who
need
those
connectors,
because
the
people
who
need
that
stuff
really
need
it,
and
this
is
an
added
leox
patch.
So
Allah
is
great,
like
really
appreciate,
ur,
actually
taking
the
time
to
sit
with
us
and
and
talk
about
the
design
of
this,
because
there's
been
a
lot
of
you
know,
back-and-forth
between
how
to
design
this
feature.
D
Next
up
is
search.
Mpl
search
works
again,
we're
sacrificing,
so
we
have
a
temporary
thing
going
in
and
we're
sacrificing
the
overall
performance
and
the
overall
and
the
sorting
ability
that
the
current
NPM
search
has
just
so
we
can
have
something
in
there
that
can
get
NPM
search
to
work
so
right
now
it's
going
to
be
a
streaming
search.
D
It's
going
to
be
incremental
in
linear,
and
it's
going
to
be
there
until
time
where
we
wear
the
registry
team
is
able
to
build
a
more
thorough
search,
end
point
and
that's
our
ten
point
is
going
to
be
really
fast,
so
MPN
for
you're
not
going
to
you're
not
going
to
blow
your
heap
every
time
you
try
and
search
for
hyper
term.
This
next
slide
is
a
gif,
so
this
is
kind
of
what
NPM
search
looks
like
now.
D
D
Lastly,
this
is
probably
the
biggest
change
that's
going
into
NPM
for
and
this
one
is
say,
kind
of
like
roundabout
replication
cycle.
We
are
deprecating
the
pre
publish
script
and
replacing
it
with
a
prepare
script,
and
this
is
a
lot
of
you,
probably
use
pre,
publish,
pre
publish,
is
really
common
for
when
you're
building
like
your
your
assets
or
something
like
that.
D
Let's
start
the
deprecation
cycle,
we're
going
to
deprecated
to
publish
you'll
start
seeing
warnings
if
you
use
pre
publish
if
you
want
the
same
behavior,
you
use
the
prepare
script.
D
That
one
is
the
one
to
use
from
now
on
to
do
exactly
what
pre-published
us
now
and
if
you
want
something
that
only
works
with
pre
publish
you
just
republished
only
until
the
cycle
ends
at
which
point
republish
will
geez
just
be
published
only
that
might
be
a
while,
but
there
we
go
npm
five,
that's
gonna,
we're
hoping
to
get
it
out
by
first
quarter,
2017
the
main
thing
that's
going
to
go
into
npm
five
is
a
redesign
of
shrink,
wrap
we're
going
to
refactor
what
we
have
right
there
to
make
it
a
lot
easier
for
us
to
like
manipulate
data
structures
and
all
that
stuff
and
make
the
code
cleaner
in
general,
because
it's
kind
of
gnarly
and
then
we
to
figure
out
what
it
is,
the
community
actually
wants
from
shrink-wrap
what
you
would
find
useful,
we're
gonna
have
a
whole
process,
like
you
know,
hopefully
reach
out
to
people
hopefully
figure
out
what
the
use
cases
are
as
compared
to
other
to
other
dependency.
D
What
do
you
call
this?
The
frozen
files,
whatever
I
forget
they're,
like
oh,
hey,
just
make
sure
we
know
what
others
are
doing
and
see
what
works
best.
It's
still
going
to
be
an
NPM
specific
solution,
because
NPM
is
pretty
unique
as
far
as
package
managers
go,
and
on
top
of
that
we're
going
to
have
a
much
faster,
more
robust
content,
addressable
cache.
D
That
means,
if
you're
look
in
your
cache,
it's
kind
of
a
mess,
it
kind
of
clobbers
things
depending
on
name,
that's
not
going
to
happen
anymore,
we're
going
to
go
by
sha
sum
or
something
similar,
and
it's
going
to
be
really
great,
and
it's
going
to
enable
some
cool
features
that
I
don't
know.
If
I
want
to
tell
right
now,
but
I
am
going
to
talk
about
alt,
yes,
so
LTS
it
stands
for
long-term
support.
D
It
is
the
concept
of
like
we
want
to
make
sure
that
you
know
that
something
will
work
for
a
long
time.
But
NPM
has
a
couple
restrictions
we're
a
very
small
team.
We
are
three
people.
One
of
those
people
is
a
technical
manager,
so
only
two
of
us
are
actually
regularly
contributing
code.
We
have
a
couple
community
community
contributors,
but
now
they're
not
full-time
people,
our
real
goal
with
an
LTSs
we
want
have
one
version
of
NPM
that
works
really
well
for
no
distribution.
D
We
want
note
to
be
able
to
say:
okay,
we
want
a
version
of
NPM
and
we
want
it
to
be
reliable.
What
should
we
have-
and
we
just
give
you
that
one
meanwhile
we're
going
to
continue
our
regular
development
process
and
move
things
to
meetings
more
often
keep
in
mind
when
you
think
about
stability
when
it
comes
to
NPM,
we
don't.
D
We
don't
create
that
many
changes
that
fast
we
actually
prioritize
ability
very
very
much
like
we
have
a
very
large
ecosystem
and
it
turns
out
every
single
little
thing
we
do
can
have
enormous
repercussions,
so
we're
very
careful
about
what
we
actually
do.
So,
even
if
you
don't
use
an
LTS,
you
can
expect
a
pretty
a
fairly
consistent,
reliable
experience.
D
Now
that
said,
if
you're
a
developer
and
not
just
like
an
automated
system
that
in
stalled
node
and
then
just
use
the
NPM,
that's
there,
we
strongly
prefer
that
you
just
update
2
n
pm
at
latest.
It's
great
it's
fantastic,
it's
the
best.
It's
the
only
NPM.
There
is
because
it's
called
NPM
there's
anyway,
whatever.
D
So
these
are
the
versions
once
NPM
at
4
comes
out.
This
is
what
you're
going
to
see
we're
moving
and
pianta
to
to
maintenance.
That
means
that
we're
going
to
patch
it
for
major
security,
vulnerabilities
and
stuff,
like
that,
but
that's
about
it
NPM
at
3,
will
become
our
new
active
LTS.
That's
the
one!
That's
going
to
go
into
node
6!
That's
going
to
be
reliable,
that's
going
to
be
around
for
a
while
we're
going
to
continue
providing
patches
for
it,
but
no
new
features.
D
Note
4
is
probably
going
to
go
into
node
at
7
like
from
here
we're
not
entirely
certain.
We
haven't
talked
to
folks
yet,
but
NPM
before
should
go
into
node
7
and
by
the
time
NPM
and
5
comes
out.
It
should
be
around
time
for
no
date,
so
that's
something
to
look
out
for
so
I
the
state
of
triage
earlier-
and
this
is
the
issue
tracker
for
NPM.
D
D
Even
so,
we
spend
a
ton
of
time
just
going
through
issues
just
managing
feature,
requests,
making
sure
that
we're
in
contact
with
the
community
but
the
reality
is,
we
probably
can't
respond
to
spend
as
fast
as
you
want.
We
do
have
some
help,
but
so
we
triage
everyday
triaging
means
that
you
choose
not.
You
shoot
the
things
that
are
most
important
and
the
things
that
are
important
enough,
but
that
you
can
actually
do
so.
We
so,
for
example,
if
it's
something
that
that
is
a
feature
request
that
tends
to
be
lower
priority.
D
Even
though
we
want
to
keep
iterating
on
issues
on
features.
If
it's
something
that
is
too
hard
to
fix,
we
might
actually
just
like
band-aid
over
it
and
move
on.
We
have
a
lot
a
lot
of
ground
to
cover,
as
far
as
feature
request
go.
If
it's
not
something
that
we're
going
to
do
ourselves
in
the
next
six
to
twelve
months,
we're
closing
feature,
requests
and
we're
not
closing
them
asking
like.
D
No
we'll
never
do
this,
we're
closing
them
some
of
them
we're
not
going
to
do
it
all,
but
we're
closing
them
so
that
we
can.
We
can
stop
keeping
track
of
all
these
things
that
we
probably
don't
have
the
time
to
do
like
if
you
look
at
our
at
our
potential
feature
list
for
that's
right
now,
we're
not
gonna
be
done
for
10
20
years
right,
and
we
can't
do
that.
You
might
see
some
some
feature.
Requests
being
closed
with
patches
welcomed
because
we
do
closed
patches,
welcome
requests.
D
That
means
patches
are
welcome,
go
ahead
and
go
ahead
and
search
closed
issues
for
patches,
welcome
and
maybe
you'll
find
something
you
like
right
now.
Big
bucks
take
priority
over
features.
We
are
doing
that
big
bug
push
right
now,
one
stuff
once
that's
done,
maybe
we'll
do
more
feature
work
over
time.
Finally,
Keenan
yield
room.
We
he
is
he's
fantastic
he's
been
helping
us
on
the
on
the
tracker
he's
been
helping
us
I,
think
a
little
bit
on
Twitter,
but
mainly
on
the
tracker.
Just
keeps
track
of
everything
we
added.
D
Keenan
is
a
contributor
recently
and
so
you'll
be
seeing
Keenan
around
the
tracker.
You
know
just
responding
to
people
usually
taking
care
of
support,
requests,
but
also
kind
of
helping
us
figure
out.
What's
going
on
in
the
repo
and
finally,
I
want
talking
about
product,
so
in
the
MPM
is
a
product,
it
is
a
product
of
NPM
Inc,
but
we
do
have
some
guiding
principles
as
a
CLI
team.
D
You
know
my
team
has
its
own
has
its
own
like
goals,
so
those
guiding
principles
in
the
most
important
here
is
that
we
have
a
responsibility
towards
the
community.
Above
all,
we
are
here
to
make
sure
that
this
thing
is
reliable,
consistent
and
performant
for
the
entire
community,
or
as
much
of
it
as
we
can
manage
that
will
override
most
things
that
we
that
we
that
we
mean
to
do
after
that.
D
There
are
things
that
we
do
with
the
purpose
of
adding
value
to
the
CLI
and
the
larger
ecosystem
and
drawing
more
people
in
or
drawing
people
to
respond,
acts
and
stuff.
Like
that,
we
are,
you
know,
we're
part
of
a
proprietary
company,
even
though
I'm
I
do
open
search
all
the
time
which
is
really
great.
D
So
what
are
our
products
initiatives
as
far
as
that
goes
beyond
just
like
a
so,
you
have
a
quality
and
robustness
improvements.
That
means
that's
our
big
bucks
push
that
is
making
sure
that
shrink-wrap
works
well,
making
sure
that
our
cash
works.
Well.
All
that
stuff
is
really
really
important
to
us
right
now.
You
want
performance
improvements
and
PMA.
3
is
pretty
fast
now,
like
a
lot
of
the
performance
issues
were
addressed,
but
we
can
make
it
better.
D
D
You
know
reliable
repeatable
installs
on
the
on
the
closer
to
registry
stuff
side,
we
have
an
improved
logging
experience
for
that,
we're
going
to
be
doing
we're
kind
of
overhauling
the
way
NPM
login
works,
and,
on
top
of
that,
we're
adding
single
sign-on.
That's
the
first
thing
that
we're
going
to
add,
we
might
add
two-factor
authentication,
which
would
be
fantastic
for
some
of
y'all,
especially
like
on
bigger,
open
source
projects
and
yeah.
That
should
go
out
like
if
you're
using
other
registries
you'll
be
able
to
like,
hopefully
take
advantage
of
that
too.
D
And
finally,
we
want
Tiger,
tighter
integration
with
the
new
registry,
where
there's
a
new
version
of
the
registry
API
coming
out,
that's
going
to
add
some
fancy
new
features
like
bundling
installs
together.
That's
part
of
the
of
the
of
the
cash
push,
so
you
know,
instead
of
doing
thousands
of
tiny
requests,
you're
going
to
collect
all
the
things
that
you
need
see.
D
What's
in
your
cache,
send
that
request
over
to
the
registry
and
you
get
one
big
tar
ball
back
and
then
we,
but
then
where
it
needs
to
go,
which
is
probably
going
to
make
a
lot
of
people's
routers
a
lot
happier,
and
that's
it
please
talk
to
us.
We
are
available
for
you.
You
can
talk
to
us
on
Twitter.
You
can
please
go
ahead
and
post
issues.
I
know,
there's
a
lot.
We
might
take
a
while
to
get
to
it,
but
we
will
do
our
best
to
get
to
it
anytime.
D
Finally,
I
do
like
so
inclusivity
diversity,
stuff
kind
of
on
top
of
that.
There's
this
community
called
VLJ
s.
It
is
a
it
is
a
general
JavaScript
community
that
kind
of
prioritizes
trying
to
get
people
together.
If
you
want
people
who
are
like
you,
that's
probably
a
good
place
to
go.
It's
also
has
a
lot
of
general
support
resources.
It
also
has
a
big
European
population.
C
A
I
can
attest
that
the
the
progress
bar
is
totally
fine
now,
and
it's
very
fast
and
great
some
I'm
super
excited
about
this.
Next
talk,
Doug,
well,
wha.
Everybody
knows
who
Doug
Wilson
is
right:
okay,
like
he's
basically
been
like
Atlas
holding
up
the
whole
Express
world
for
quite
a
while
Oh
Doug's
actually
never
spoken
at
a
big
conference
like
this
before.
So
this
is
awesome
that
we
were
able
to
give
him
here.
Anybody
give
him
for
Doug
and
his
talk,
and
just
all
of
the
work
that
he's
done
in
the
community
over
the
years.
E
All
right,
so,
if
you
probably
all
know
me
at
least
a
little
bit
from
github,
my
name
is
Doug
Wilson
and
you
know
I'm
going
to
talk
a
little
bit
about
the
State
of
the
Union
for
the
Express
project
and
like
how
it
actually
like
is
right
now
not
code
wise,
but
just
project
management
wise,
so
I
want
to
start
off
a
little
bit
kind
of
like
an
overview
of
kind
of
like
what
Express
is
just
in
case.
Anybody
who
didn't
know
so
Express
is
just
a
node
web
server
project.
E
It's
actually
built
on
top
of
the
core
No
EP
server
itself
and
basically
adds
a
little
bit
of
routing
and
sugar.
On
top
of
that,
so
like
it
provides
a
way
where
developers
can
declare
that,
given
this
method
in
this
path
execute
this
piece
of
code,
it
gives
like
a
basic
little
bit
of
a
middleware
pattern.
E
Develop
errs,
can
say
this
piece
of
code
run
under
these
conditions.
It
allows
them
to
kind
of
like
compose
them
together.
It's
actually
been
a
big
driver
force
of
like
the
ecosystem
of
express
itself,
allowing
module
or
module
developers
to
publish
little
pieces
of
code
that
just
manipulate
the
requests
and
responses
in
a
reusable
way
that
everybody
can
incorporate
into
their
applications.
E
E
E
In
fact,
the
incubating
project
is
meant
to
help
make
projects
more
participatory,
transparent
and
effective
part
of
this
is
they
actually
helped
us
outline
project
governance,
we're
actually
pretty
much
using
kind
of
like
a
default
template
really
that
the
actual
incubating
project
kind
of
like
gives
us,
but
over
time,
we'll
iterate
that
to
make
it
a
lot
more
suited
to
to
how
we're
going
to
be
run.
But
right
now
it
was
a
really
great
staining
starting
point.
In
fact,
anybody
could
use
the
template
even
if
they're
not
part
of
this
program.
E
We
also
part
of
this
we
went
through
and
we
try
to
determine
like
what
the
actual
founding
core
contributors
to
Express
was
over
time.
We've
expressed
has
actually
been
around
first
commits
we're
actually
in
the
summer
of
2009
and
then
first
published
to
NPM
winter
2010.
It's
been
around
for
a
long
time
in
his
head,
people
come
and
go
from
the
project,
and
we
just
had
a
pretty
big
mess
of
who
the
actual
contributors
even
were
so
we
actually
went
through
and
actually
took,
data
points
and
figured
out.
E
E
So
what
we
did
was
from
that
and
part
of
this
initial
governance
template
is.
We
actually
came
up
with
a
technical
of
committee,
very
much
similar
to
the
technical
committee,
that
is,
with
the
node
core
itself.
It's
just
basically
just
people,
a
group
of
people
that
just
guide
the
project
I
mean
it's
it's
very
much
like
just
whatever
we
need
to
do.
E
We
basically
just
meet
every
other
week
to
discuss
topics
so
the
last
one
was
last
week
this
week
was
often
the
next
week
is
our
next
one
and
we
just
usually
just
discuss
whatever
we
need
to.
We
make
decisions
if
there's
some
kind
of
objections
so
like
most
of
the
decisions
made,
are
not
made
by
the
TC,
so
the
TC
isn't
like
a
gatekeeper
to
all
decisions.
E
The
projects
inside
there
there'll
be
discussions,
everybody
people
we
try
to.
Let
people
participate
in
them
and
only
if
there's
something
this
doesn't
seem
to
be
getting
resolved.
Do
we
actually
have
to
come
in
and
actually
say?
Okay,
let's
try
to
make
a
decision
on
this,
yes
or
no.
What
do
we
need
to
do?
Is
there?
Maybe
an
action
item
try
to
get
that
going
and
we
also
just
discuss
new
topics
to
align
in
direction.
E
So,
whether
or
not
we
need
to
change
some
aspect
of
how
the
website
operates,
or
maybe
we
need
to
bring
up
like.
Oh,
is
this
part
of
the
governance
not
working
for
us,
or
maybe
this
would
be
a
cool
thing.
If
we
could
do
this-
or
you
know
some
recent
ones
where
maybe
we
should
standardize,
although
the
readme
x'
across
all
our
repos
look
similarly
like
okay
cool,
let's
do
that,
and
so
it
wasn't.
How
do
we
do?
That
necessarily
is
like
yeah.
It
sounds
like
a
great
idea.
E
Let's
start
that
conversation,
and
then
that's
been
going
on
all
by
itself.
Tc
is
not
really
involved,
I
mean
the
same
members
that
are
all
the
core
contributors
are
on
the
TC,
so
the
same
people
are
making
the
conversation
just
not
really
like
out
there
in
this
actual
meeting
and
I
just
wanted
to
give
a
quick
overview
of
who
these
actual
TC
members
are.
So
we
actually
have
nine
members
and
you
may
or
may
not
recognize
some
of
our
all
of
them,
and
they
don't
all.
E
Do
everything
and
express
express,
is
actually
a
pretty
large
project.
Different
people
focus
on
different
areas.
Some
do
a
more
broader
focus.
Some
are
more
narrow,
focused
you
actually
have
Blake
Rand
myself,
yappa,
Linus,
Nick,
Troy,
Jonathan
and
Jeremiah.
Just
to
give
off
the
kind
of
list
so
express
is
actually
a
fairly
large
project.
E
We
actually
had
two
we
actually
are
composed
of
dozens
of
modules,
all
actually
managed
the
people
in
express
not
including
the
modules
that
we
actually
just
use
that
are
not
managed
by
Express
we.
Actually,
this
was
actually
before
this.
This
was
actually
I.
Think
2015
is
when
we
did
all
this,
but
we
actually
decided
that
it
was
getting
really
unmanageable
being
inside
one
github
org.
So
we
actually
split
among
three
I
just
wanted
to
talk
about
this
because
I
know.
This
is
a
point
of
confusion.
E
E
The
expressjs
organization
is
really
like
the
main
entry
point
organization,
you'll
find
the
actual
Express
module
under
there
you'll
find
its
website
and
then
all
the
middleware
that
essentially
are
maintained
by
the
Express
team
or
under
there.
Those
aren't
really
like
official
or
unofficial
or
somehow
better
quality
than
anything
else.
They're
just
maintained,
and
that
comes
from
the
legacy
of
especially
with
Express.
E
It's
like,
where
do
people
get
started,
so
these
are
kind
of
like
some
wheels
that
we
give
them
and
a
lot
of
them
might
have
better
ones
out
there,
and
we
certainly
welcome
to
collaborate
participate
in
fact,
some
of
the
ones
in
there.
Actually
we're
started
outside
of
Express
and
we're
actually
essentially
said
hey.
E
You
know,
maybe
I
don't
have
a
lot
of
time
for
this,
and
actually
they
got
brought
in
to
the
Express
organization
from
outside
pillar
j/s
is
kind
of
like
our
next
kind
of
like
layer
down
it's
the
built
you
can
think
of
it
as
like.
The
building
blocks
of
express
so
express
the
module
is
made
up
of
various
different
code
pieces
like
the
router.
How
does
it
actually
tie
in
your
render
request
to
a
view
engine?
E
This
is
actually
where
we
sit
all
of
our
low-level
HTTP
related
things,
so
we
have
a
lot
of
different
code
in
there.
In
fact,
traditionally
people
would
actually
get
to
this
back
in
old
Express
days
by
requiring
Express,
and
there
was
an
export
called
utils
and
they
would
use
that
to
get
to
a
lot
of
these
low-level
functions
because
they
needed
them.
You
got
things
like.
How
do
you
generate
etags?
How
do
you
parse
content
type
header
stringify
them?
E
You
know
parse
range
headers,
all
kinds
of
different
things,
there's
a
lot
of
things
where
in
the
node
core,
where
it's
it's
available,
it's
possible
to
do
certain
things,
but
you
have
to
add
a
ton
of
event
listeners
and
do
all
these
weird
things,
and
so
we
bundle
them
up
into
a
couple.
Things
like
on
finished
and
on
headers
to
under
to
add
hooks
into
the
node
core,
a
lot
easier
that
we
use
in
ourselves,
and
then
it
kind
of
like
gives
like
an
idea
of
how
this
actually
fits
into
the
actual
structure.
E
So
this
is
a
very,
very
simplistic
view
of
the
dependencies.
Now,
our
other
dependencies,
just
a
few
of
them
just
to
kind
of
like
highlight
how
it
actually
fits
in
these
three
organizations,
so
up
in
Express,
JSU
have
Express
itself
and
then
it's
middleware,
which
of
course
aren't
a
dependency
of
Express.
E
Pillo
jsut
actually
have
some
named
ones
or
there's
a
module
called
router.
That's
that
is
expresses
router.
So
if
you
ever
wanted
to
actually
do
the
same
thing
where
it's
like
you
app
get
app
dot
post
app.
That
put
all
of
that
is
actually
available
in
this
model
called
router.
So
you
don't!
Even
if
you
don't
care
about
anything
else,
but
routing
and
Express,
and
you
don't
need
a
sugar,
then
you
could
actually
just
require
that
module
directly
send
is
another
pretty
popular
one
to
direct
require.
E
E
And
then
you
have
final
Handler
and
that's
kind
of
like
that's
how
we
actually
do
like.
If
you
don't
have
any
specific
thing,
how
do
we
write
out
the
404s,
those
500s
from
those
errors
that
you're
getting
giving
or
not
handling
anything,
and
that's
kind
of
like
all
the
logic,
for
that,
in
fact
come?
If
you
combine
router
and
final
hell
handler
together,
you
actually
pretty
much
have
excel.
You
have
almost
everything
that
Express
is
without
express
itself
the
sugar
which
we
will
be
exporting
into
another
module
soonish,
then,
under
that
you
have
Jas
HTTP.
E
So
that
has
like
the
send
module
needs
to
generate
etags
that
will
do
it
through
there.
It
needs
to
understand
if
a
conditional
request
is
going
to
be
a
304
or
200
based
on
if
the
cache
is
fresh
or
not.
So
that's
a
fresh
module
range,
parser,
parses
range
header,
then
on
final
hand.
Larry,
for
example,
also
has
a
dependency
on
unfinished,
so
does
send
as
well,
and
that's
kind
of
like
how
two
hooks
into
all
that
stuff
to
understand.
E
When
a
response,
for
example,
is
finished,
so
I
can
clean
up
file
descriptors
and
send
even
no
matter
what,
if
the
response
got
cut
off,
even
if
the
client
cut
it
off,
this
thing
will
trigger
and
so
will
understand
that
we
have
to
clean
it
up,
and
all
of
this
is
available
for
especially
like
the
biggest
reason
we're
splitting.
This
up
is
because
a
lot
of
these
third-party
module
middleware
needs
to
do
a
lot
of
these
similar
things,
and
so
we
kind
of
like
say:
hey.
You
don't
have
to
reinvent
these
wheels.
E
Five
days
has
an
alpha
currently
published
and
we
actually
are
actively
working
on
things.
So
these
are
a
few
different
things:
they're,
not
everything.
That's
going
to
be
an
Express
five
they're,
not
even
what
is
definitely
going
to
be
an
Express
five,
but
they
are
all
the
stuff
that
we
actually
either
have
current
code
proposals
or
active
discussions
on
right
now
and
a
lot
of
them
are
really
cool,
like
native
promised,
support
and
routing.
So
this
doesn't
get
rid
of
callbacks
or
anything
like
that,
but
a
lot
of
people
these
days.
E
They
like
you
promises
and
they
want
to
be
able
to
use
promises
and
their
routing
like
their
middleware.
They
want
to
just
return
a
promise,
for
example,
and
let
it
you
know,
go
to
the
next
or
not,
depending
on
resolve
or
reject,
and
exactly
how
that
works
is
actually
in
a
lot
of
discussion.
There's
actually
a
few
different
proposals
that
we're
working
through
and
trying
to
figure
out
what
will
be
the
best
and
most
compatible
for
the
existing,
because
we
would
love
we
would
hate
to
break
everybody
from
this,
especially
with
it
being
entry
point.
E
So
many
books
written
on
this
is
that
we
actually
care
a
lot
about
that
improve
template,
rendering
system
right
now.
You
didn't
really
realize
this,
but
we
actually
read
the
templates
off
your
file
system
synchronously
now,
by
default,
when
you're
in
production
mode,
it
will
cache
the
template
in
the
memory.
So
we
don't.
Actually
we
only
synchronously
read
on
first,
but
that's
a
big
pain
point.
E
We
would
like
that
to
not
do
any
sync
actions,
because
that's
the
best
way
for
everybody,
so
that
requires
redoing
the
way
the
whole
template
system
works,
which
is
being
worked
on
improved
query,
string,
handling,
there's
a
lot
of
discussions
all
about
query
string
handling
in
the
way
it
works
there
and
how
you
should
parse
it.
How
you
shouldn't
parse
it
and
so
kind
of
like-
has
a
lot
of
discussions
about
how
we
can
actually
make
that
a
lot
better.
E
For
you
guys,
cookie
handling
is
a
big
one,
I'm
sure
a
lot
of
you
uses
Express.
If
you
ever
use
cookies,
you
got
to
require
that
cook,
you
probably
requiring
cookie
parser
module
kind
of
ridiculous
cookies
are
like
a
pretty
center
part,
yet
expressed
consent
cookies
built
into
it,
so
both
setting
and
getting
will
actually
be
built
into
expressive.
Sugar
is
the
idea
here,
because
it's
just
a
basic
thing:
to
do
we're
working
on
new
route,
syntax
additions,
so
Express
for
had
increased,
really
increase
the
amount
you
could
do
with
the
express
routing.
E
E
But
we
have
a
bunch
of
new
stuff
that
will
be
in
there
too,
and
then
we're
talking
a
lot
about
how
to
decompose
our
project
structure
even
more
like
so,
for
example,
the
whole
view
rendering
system
and
how
that
works
is
all
actually
still
within
express
itself.
So
we
need
to
strip
that
out
all
the
sugar
so
by
sugar
I
mean
we
attach
Express,
takes
the
raw
rec
and
res
from
node
core
and
attaches
a
bunch
of
stuff
to
it.
E
Like
rec
type
e
res
dot
send
all
those
are
very
convenient,
but
it's
hard
you
have
to
use
express
to
get
them.
You
can't
just
pick
and
choose
so
we're
moving
to
kind
of
like
pull
all
of
that
out
into
their
own
modules.
Express
will
still,
of
course,
have
them
perfectly
fine,
but
you
can
actually
be
able
to
use
them
even
if
you're
not
using
Express.
E
So
we're
going
a
lot
to
get
a
lot
of
our
project
documentation
out,
like
the
biggest
one,
is
what
our
SAR
stated
goals
right,
we
have
pretty
much.
Express
has
always
has
been
lived
goals
as
what
you
could
say
like
living
goals.
We
we
know
what
our
goals
are,
but
you
guys
it's
hard
for
you
to
know
what
our
goals
are.
Until
you
say
something,
and
then
we
tell
you,
no,
that
doesn't
make
sense
according
to
our
goals.
You
know
not
a
great
way.
I
mean
I.
E
Guess
it's
some
way,
but
it's
not
great,
so
we're
working
on
getting
those
goals
stated
plus
it
really
helps,
especially
when
you
bring
on
new
contributors.
So
there's
an
understanding
of
what
it
is.
Also
the
community
can
understand
what
they
are
and
then,
until
you
understand
what
they
are
it's
hard
to
even
know
what
to
object
about.
You
can't
say:
I,
don't
like
I,
don't
I,
don't
think
that
that
should
be
a
goal
of
the
project.
You
don't
know
without
it
being
written
down
working
on
contributing
guides.
E
So
we
have
actually
part
of
the
incubation
processes.
We
brought
a
default
contributing
guide.
It's
pretty
generic
and
we've
actually
gotten
a
bunch
of
feedback
on
it
and
we're
trying
to
make
that
not
only
be
more
specific
to
the
Express
project
on
how
its
managed,
rather
than
just
make
pull
requests
blah
blah.
Maybe
they
we
should
tell
them
they
need,
should
make
it
on
a
different
branch,
how
they
should
decide
stuff
like
that,
but
also
try
to
get
these
contributing
guides
out.
E
So
we
can
actually
apply
it
to
all
of
our
different
repos
in
those
three
orgs,
because
right
now,
it's
just
in
the
Express
org
we're
trying
to
get
that
very
sadly,
debt
structure
that
I
presented
on
is
actually
the
most
documentation.
We
have
about
our
organization
structure
besides
just
what's
in
the
heads
of
the
TC,
so
we're
working
on
actually
getting
that
documented
and
up
on
our
website.
C
E
Of
modules,
we're
also
working
to
better
document,
our
location
of
resources,
so
what
I
mean
by
that
is
like?
Where
do
people
ask
for
help?
How
what
you
know?
Where
do
they
file
issues?
How
should
they
do
that?
You
know
who
are
you
know
who
are
the
TC
members
which
we
actually
just
recently
added
you
know
and
how?
How
do
I
see
these
meetings,
so
we
actually
I
just
created
a
YouTube
channel
recently,
so
we'll
be
getting
that
up
on
the
dock.
E
For
all
these
recorded
meetings,
you
know
how
do
I
watch
them
live
if
I
wanted
to?
How
do
I
know?
What's
the
upcoming
one,
so
we're
working
on
trying
to
document
all
the
locations
of
those
things
and
finally,
we're
working
on
some
level
up
guides,
which
is
part
of
being
participatory
and
transparent,
like
when
people
contribute
code,
I
mean
what,
if
they?
E
What
if
you
know
for
people
who
say
I
really
want
to
be
a
I
want
to
have
commit
bits,
essentially
on
either
the
Express
module
or
one
of
the
other
modules
in
our
orgs
right?
What
is
the
actual
process,
instead
of
it
just
being
like?
However,
someone
feels
that
day
like
try
to
get
that
kind
of
written
down
and
then
how
they
would
become
a
TC
member
which
is
partially
documented
in
our
governance,
but
it's
still
very
generic.
E
A
Great,
it's
really
great,
then
something
to
see
you,
alright,
everybody
I
hope
you
had
a
great
time
really
really
I
can't
encourage
you
enough
if
you've
ever
thought
about
doing
anything,
encore
please
come
back
tomorrow
morning
we
have
so
many
great
mentors
in
town,
including
people
that
know
very
deep
things
about
note.
That
you'll
probably
never
be
anxious
to
again
so
really
at
tomorrow's
code
and
learned
it.
We
have
an
opportunity
for
you
to
contribute
to
any
part
of
core
if
you
have
any
kind
of
skill
set.