►
From YouTube: Accelerate your Digital Transformation
Description
Accelerate your Digital Transformation [I] - Michael Dawson, IBM
Digital transformation is more than a buzz phrase. Learn how companies are evolving to Cloud, systematically leveraging existing workloads on their current platforms for competitive advantage. This session explores the transition to Cloud using Node.js technologies and unlocking the power of your existing data sets and what you can expect from the Node.js Foundation and community moving forward. See how the ability to start on known and familiar platforms and environments and to maintain a bridge to data on these platforms using new technologies like Node.js can be one of the keys to success of the move to cloud native.
Come learn about the work IBM is doing to ensure to that:
- Node.js is available across platforms and environments
- that key tools and capabilities are available (monitoring, post mortem investigation)
- you can leverage existing datasets in your cloud native applications using the IBM SDK for Node.js is based on the Node.js™ open source project. It provides a compatible solution for IBM Power™, Intel® and z Systems™ products that require Node.js functionality and package management.
Michael Dawson
IBM
Senior Software Developer
Ottawa, Ontario
Twitter Tweet
Michael Dawson is an active contributor to Node.js and a CTC member. He contributes to a broad range of community efforts including platform support, build infrastructure, N-API, LTS as well as tools to help the community achieve quality with speed (ex: ci jobs, benchmarking and code coverage reporting). Within IBM he leads the Node.js team driving IBM’s Node.js runtime deliveries and their contributions to Node.js and v8 within the Node and google communities. Past experience includes building IBM's Java runtime, building and operating client facing e-commerce applications, building PKI and symmetric based crypto solutions as well as a number of varied consulting engagements. In his spare time he uses Node.js to automate his home and life for fun.
A
A
Dancing
or
adding
features
to
node
we're
gonna
do
that
out
in
the
community
and
for
that
reason,
you'll
see
that
you
know
I'm
a
contributor
I'm,
a
member
of
the
CTC
and
TSC,
which
are
the
boards
that
sort
of
steer
the
direction
for
nodejs
overall,
as
well
as
we're
very
active
in
a
whole
bunch
of
the
working
groups,
where
a
lot
of
the
work
on
sort
of
focused
topics,
like
benchmarking,
long
term,
support
and
so
close,
so
so
forth,
take
place.
Our
team
has
also
done
some
interesting
things
like
porting
v8.
A
If
you
know,
nodejs
v8
is
the
core
JavaScript
engine
that
supports
it,
and
we've
done
work
to
port
those
to
PowerPC
and
s/390
architectures,
and
really
it's
much
more
than
a
regular
port.
Where
you
start
ported
over
v8
includes
a
compiler.
So,
basically,
every
week
we
have
to
keep
up
with
all
the
changes
that
are
being
done
in
that
just-in-time
compiler
to
keep
those
ports
going.
A
A
That
and
getting
it
to
cloud
native
deployments
so,
for
example,
in
Cloud
Foundry
as
part
of
that
I'm
going
to
touch
on
the
locality
of
data,
because
often
you
know,
if
you
have
an
existing
data
set
or
existing
applications,
that's
one
of
the
things
that's
hard
to
just
move
out
into
the
cloud.
Once
I've
identified
a
number
of
those.
A
You
know
that
the
potential
obstacles
on
that
journey
I'm
then
going
to
give
you
some
insight
into
the
work
that
we've
been
doing
out
in
the
nodejs
community
to
try
and
sort
of
work
around
those
or
find
solutions
to
the
obstacles
you
might
run
into
and
finally,
I'll
just
end
up
with
a
summary
and
wrap
up.
We've
gone
over,
so
some
common
adoption
parents.
You
know
we
often
see
you
know
nodejs
almost
coming
in
through
the
back
door.
A
You
know
a
developer
comes
up
with
a
nice
solution,
not
necessarily
an
official
project
but
comes
up
with
something
that
solves
a
problem
for
the
business
shows
that
it
goes
up
the
executive
chain
and
it's
like
yeah.
We
really
want
to
do
this
and
the
decision
is
well.
Okay,
we're
not
going
to
re-implement
that,
and
it
actually
ends
up
going
into
production,
so
it
kind
of
sneaks
into
the
back
door,
and
that
initial
success
then
starts
to
more
and
more
use
of
noches
within
the
enterprise.
A
Of
course,
if
there's
always
greenfield
development,
where
people
just
start
with
a
whole
new
idea
or
you're
in
a
start-up,
that's
obviously
easier
and
that
you
don't
have
to
deal
with
existing
data
and
infrastructure
and
all
that,
so
most
of
the
obstacles
I'll
be
talking
about,
are
more
likely
in
one
of
the
three
cases
where
you
know
you're,
starting
with
an
existing
enterprise.
You
have
systems
and
data,
and
you
want
to
continue
to
leverage
those
as
you
move
forward.
A
Vocality
of
data
turns
out
to
be
an
issue.
One
of
the
you
know
one
of
the
important
issues
because
moving
the
data
can
be
hard.
It
may
just
be
that
you
have
you
know
it's
sensitive,
it's
confidential
data.
You
don't
want
to
move
it
out
into
the
cloud.
There
may
even
be
regulation
that
prevents
you
from
doing
that.
So
if
you
work
in
the
federal
government
or
certain
industries,
it
may
be
that
your
data
has
to
be
located
in
a
particular
place
and
you
can't
easily
move
it.
A
You
may
even
be
using
a
legacy
data
store.
So
you
know,
even
though
the
cloud
and
cloud
foundry
is
fairly
rich
in
terms
of
the
different
data
bases
that
it
supports.
Maybe
you
know
the
the
legacy
database
system
they're
using
just
isn't
available
there
and
finally,
it
just
takes
effort.
So
if
you
haven't
have
an
established
data
store
moving
it
somewhere
else,
you
know
the
effort
to
do
that.
May
just
be
a
roadblock
in
itself.
A
The
other
thing
is,
even
if
you,
if
you
know,
if
you're
in
the
situation,
you
can't
move
your
data,
then
the
locality
of
the
data
can
affect
performance.
So
one
of
the
things
we
did
is
we
put
together
a
sample
application
where
we're
using
day-trader,
which
is
a
benchmark.
That's
often
used
to
benchmark
java
systems,
and
we
add
it
to
that
benchmarking
infrastructure,
some
new
nodejs
layers
to
basically
provide
a
new
way
to
get
at
some
of
that
data.
That's
one
of
the
common
use
cases.
A
Basically,
you
had
two
systems,
your
legacy
system
and
your
your
new,
no
GS
front-end,
and
then
we
we
ran
it
the
other
way
where
we
actually
ran
nodejs
on
the
legacy
hardware
as
well,
and
we
measured
the
difference,
and
you
know
we
could
see
that
you
know.
In
this
case
we
saw
two
and
a
half
times
better
throughput
by
having
co-located
your
nodejs
application
and
the
data
and
the
the
response
times
were
60
60
%
better,
and
so
really,
you
know,
being
able
to
run.
A
So,
having
said
that,
you
know
some
of
the
potential
roadblocks
if
you're
starting
on
one
of
those
initial
three
ways
of
adopting
nodejs.
Is
you
know
if
you
have
an
existing
environment
and
existing
standard
within
your
development
organization?
If
you
have
to
change
all
of
that
to
get
started,
that's
a
barrier,
so
it's
important
to
be
able
to
start
to
use.
Node
experiment
build
up
experience
with
the
tools
you're
already
familiar
with,
so,
if
you're,
using
a
particular
operating
system,
you're
using
a
particular
set
of
hardware.
A
A
The
next
thing
is,
you
know,
for
traditional
applications
we're
familiar
with
using
products
and
services
that
have
a
certain
level
of
support.
So
you
want
to
make
sure,
like,
in
the
case
of
nodejs,
that
you
have
good
confidence
that
the
diversions
you're
using
and
we're
gonna
simply
supported
how
long
they're
going
to
be
supported
for
and
that
they're
they're
gonna
be
stable
and
I'll
talk
about.
You
know
some
of
the
things
we're
doing
just
to
provide
that
as
well.
Unfortunately,
things
will
go
wrong.
A
So,
if
you're
have
your
applications
in
production,
you
want
to
know
that
if
things
do
go
wrong,
you're
going
to
have
the
tools
to
be
able
to
investigate
and
resolve
those
problems.
So
monitoring
and
problem
investigation
is
important
to
have
the
infrastructure
framework
and
tools
that
you
need
and
then
there's
just
sort
of
a
certain
just
as
important
but
more
of
a
sort
of
baseline
set
of
requirements
where
you
know
for
doing
a
real
application,
we
need
internationalization.
We
need
to
know
our
applications
to
be
secure.
A
We
want
to
know
that
the
the
infrastructure
we
relying
on
is
is
apply,
quality
and
stable,
and
finally,
we
want
it
to
be
performant
as
well,
so
that
we
maximize
the
use
of
the
hardware
and
infrastructure
that
we're
investing
in
so
before
I
get
into
the
things
that
we're
acting.
Actually,
you
know
working
on
in
the
community
to
address
those
issues
just
a
little
bit
about
IBM's
involvement
in
the
community
itself.
A
We've
been
very
active
right
from
the
beginning.
Ibm
was
one
of
the
platinum
sponsors
in
terms
of
the
the
initial
platinum
sponsors
for
the
foundation,
and
we
helped
you
know,
sort
of
pull
that
together
we
have
nine
collaborators.
So
these
are
people
who
can
like
commit
code
review,
pull
requests.
We
have
two
CT
CT
SC
members,
which
I
said
are
the
Pete?
Are
the
the
boards
that
basically
chart
the
direction
for
no
resolve
conflicts,
we're
active
in
many
of
the
working
groups?
A
So
if
you
or
you
know,
have
an
interest
in
things
like
benchmarking
or
api's,
or
the
build
infrastructure,
you'll
see
that
you
know
we're
actively
involved
in
there.
And
you
know
these
are
the
people
in
the
faces.
So
if
you
go
to
github
you're
interested
getting
involved-
and
you
see
us
it's
a
very
open
and
friendly
community,
so
just
say
hi
and
get
involved.
A
So
the
first
thing
that
we
focused
on
was
the
the
environment.
We
wanted
people
to
have
the
choice
of
platforms
when
they
came
to
use
nodejs.
So
we
worked
hard
to
make
sure
that
you
know
our
IBM
platforms
are
supported,
so
binaries,
for
you
know,
Linux
on
P
Linux
on
Z,
as
well
as
AI
IX
are
now
all
available
on
the
community
download
sites
we
shipped
earlier.
A
You
know,
as
we
worked
on,
that
we
shipped
the
IBM
SDK
for
nodejs
since
2013
and
all
the
way
back
to
node
zero,
ten
and
we're
currently
working
on
support,
even
for
z/os.
So
if
you
have
some
data,
that's
located
on
z/os
and
you
want
to
leverage
that
there's
already
a
tech
preview,
and
actually
this
is
a
little
out
of
date.
We
have
a
beta
that's
available
now.
So
if
you
want
to
try
that
out,
it's
already
there
but
more
in
general.
So
you
know
this.
A
We
of
course
focused
on
our
platforms,
but
we
also
have
and
are
involved
in
just
generally
supporting
the
broad
platform
support
that
no
GS
has
you
know,
including
things
like
even
alpine.
You
know
some
of
our
internal
groups
are
saying:
hey
we'd
like
to
build
it
to
play
in
smaller
containers.
So,
that's
something
that
we
know
we're
looking
to
get
involved
in
to
help
facilitate
to
make
sure
that
you
know
when
you
want
to
get
started.
You
can
just
start
with
the
existing
environment
and
platforms
that
you're
you're
familiar
with
the
next
thing.
A
A
So
just
a
few
things
that
you
know
we
recommend
on
that
front
is
that
you
know
when
you're
developing
to
develop
for
deployment
independence.
Don't
don't
you
know,
sort
of
tightly
bundle
in
dependencies
on
local
infrastructure
or
a
particular
logging
mechanism
plan
to
leverage
the
services
that
are
available
in
the
infrastructure
for
you,
so
you
know
environments
like
Cloud
Foundry
give
you
ways
to
do
logging.
They
give
you
ways
to
do
load,
balancing
and
scaling
in
and
out
so
don't
build
those
into
your
application.
Make
sure
you
plan
to
leverage
whatever
infrastructure.
A
One
of
the
things
we
recent
were
recently
worked
on
were
pattern,
generators
which
would
basically
give
you
the
scaffolding
for
the
application
that
you
wanted
to
develop,
the
throw
so
using
the
DX
dev
command
line,
which
is
an
extension
of
the
cloud
foundry
command
line.
You
can
basically
select
a
pattern
for
the
type
of
application
you
want
to
develop
and
then
based
on
that
pattern,
it
asks
you
what
kind
of
services
do
you
want
to
plug
in
authentication?
A
So
you
know
if
I
have
an
application
in
production
and
I'm
running
on
a
particular
version
of
node
I
want
to
know
that
I'm
gonna
have
support
for
that
version
and
not
have
to
say
update
two
months
from
now.
So
one
of
the
things
we've
worked
hard
in
the
community
is
on
the
long
term,
support
strategy.
When
the
foundation
came
together
and
I
ojs
and
Jess
came
together,
there
really
wasn't
a
plan,
for
you
know
how
long
are
the
binaries
that
we
put
out?
A
They're
gonna,
be
supported
and
have
updates,
and
we
worked
in
the
community
to
develop
this
one
where
basically
there's
a
plan
where
every
six
months,
a
current
release
is
cut
and
every
alternating
current
release
becomes
a
long-term
release.
So
no
date
was
just
announced
about
a
couple
weeks
ago,
as
the
next
current
six
months.
Six
months
from
then
roughly
in
October,
it's
going
to
become
the
next
LTS
release
and
we've
had
you
know.
Two
years
ago
we
had
no
GS
four
in
October,
no
GS,
six,
the
there.
A
You
know
one
year
ago
in
October
and
we're
gonna
have
no
GS
eight
in
October,
and
you
get
about
thirty
months
of
support.
There's
a
there's,
an
initial
18
months
of
very
active
support
where
you
get
lots
of
changes
and
fixes,
and
even
some
features
going
in
followed
by
a
shorter,
12-month
maintenance
phase,
where
it's
really
just
critical
security
fixes
and
things
that
are
that
are
really
important.
A
But
the
key
thing
here
of
you
know
what
we,
when
we
got
involved,
are
and
and
what
I
think
we're
proud
of
what's
been
achieved
here
is
there's
very
regular
and
predictable
releases.
Every
year
you
have
a
new
LTS
release
that
releases.
You
know
supported
by
30
months,
and
we
now
have
a
couple
years
of
history
of
the
releases
coming
out
on
that
predictable
and
and
sort
of
consistent
pattern,
which
is
it
which
is
as
an
enterprise.
This
is
something
that
I
think
most
people
are
looking.
A
The
next
thing
is,
you
know:
if
I
have
my
I've
got
my
long-term
releases,
I
have
them
in
production
when
things
go
wrong,
I
really
want
to
know
that
I
can
actually
dive
in
and
figure
out.
What's
going
on,
I
was
involved
on
our
Java
team
for
10-12
years,
and
you
know
we
found
there
really
three
key
tools
that
you
needed
to
figure
out
a
lot
of
the
gnarly
problems.
The
first
one
is
is:
is
like
a
first
data
capture,
easily
consumable
easy
to
create
human
readable.
A
That
gives
you
a
you
know,
quite
a
lot
of
information
about.
What's
going
on
that,
you
can
quickly
look
at
and
figure
out,
as
you
know,
often
what's
going
on
just
with
that
that
one
piece
of
information,
if
you're
familiar
with
Java,
that's
called
a
Java
core
and
know
didn't
have
an
equivalent,
so
our
team
got
involved
and
we
helped
the
community
to
develop
Notre
part
which
I'll
show
you
a
picture
of
which
serves
the
same
purpose.
You
can
easily
generate
and
it
gives
you
lots
of
information.
A
What's
going
on,
that's
often
enough
to
solve
the
problem.
The
next
piece
is
heap
heap,
dump
generation,
so
we're
still
working
in
the
community
to
make
it
easy
to
generate
heap
dumps.
It's
something
I'd
like
to
see
bundled
right
in
with
the
core
node
runtime
itself
and
then
core
inspection,
where,
if
your
your
application
fails
in
production,
you
can't
really
stop
and
attach
a
debugger
or
that
kind
of
stuff.
A
You
want
to
basically
just
generate
a
core
file
which
is
an
image
of
the
memory
of
what
was
running
at
the
time
and
then
look
be
able
to
look
at
that
and
figure
out
what
the
problem
was
from
that
and
I'll
talk
a
bit
more
about
that
as
well.
So
just
on
node
report,
you
know,
basically
it
gives
you
a
human,
readable
summary
of
the
state
of
your
nodejs
runtime
in
its
application.
A
It
gives
you
things
a
summary
of
the
events
versions
of
nodejs
and
even
some
of
the
modules
that
are
running
inside
you
get
things
like
Java
and
native
stack
traces.
It
tells
you
things
like
your
OSU
limit
settings.
So
if
somebody
is
set
your
you
limit
to
low
for
say
the
number
of
file
handles
and
your
application
isn't
being
able
to
open
new
files.
Well,
maybe
that's
a
pretty
good
example
of.
What's
going
on,
that's
one
in
particular,
you
know
the
limits.
A
We've
seen
a
lot
of
times,
you
look
at
those
and
you
can
immediately
figure
out
what's
going
on
if
somebody
just
hasn't
configured.
Something
right
so
no
report
is,
is
something
I'd
recommend
it's
bundled
into
the
IBM
sdk
for
node.js,
which
is
what's
available
in
in
bluemix
our
cloud
foundry,
our
product
that
supports
cloud
foundry
and
we're
working
in
the
community
to
have
a
sort
of
a
track
where
it's
going
to
be
bundled
into
the
core
runtimes
in
terms
of
heap
generation.
A
There's
a
heap
dump
module
written
by
VIN
Nordhaus,
one
of
my
co-workers
that
lets
you
generate
a
heap
dump
programmatically.
You
can
then
open
those
core
dumps
in
the
chrome
developer
tools,
and
it
has
some
nice
screens
where
you
can
actually
tell
the
difference
the
GC
state
before
you
know.
If
you
have
sorry,
if
you
have
multiple
heap
dumps,
you
can
tell
the
difference
between
two
of
those
heap
dumps.
A
A
So
we're
still
working
on
that
front
in
the
community
in
the
post-mortem
working
group
to
try
and
you
know,
improve
to
make
it
just
easier
to
generate
them,
consume
them
and
so
forth
and
finally,
core
inspection.
So
if
you're
really
stuck-
and
all
you
have-
is
that
core
file
there's
been
a
few
solutions
over
time,
so
MDB
was
a
basically
a
debugger
available
from
joint
who
was
one
of
the
early
Stewart's
of
node.js.
A
It
had
a
few
limitations
and
that
you
could
only
run
it
on
smart
OS.
So
if
you're
running
in
production,
you'd
have
to
take
your
core
files
from
Linux
move
them
over
a
different
system.
Do
some
inspection
IBM
had
a
product
we
called
ID
de
which
allowed
you
to
do
similar
things
basically
take
core
files
open
them
up,
both
of
them
understood
the
structure
of
v8
and
node
structures,
so
you
could
basically
say
it
like
print
out.
A
This
object,
giving
you
know
a
C
pointer
and
it
would
interpret
the
whole
structure
and
say
like
okay,
it's
a
string,
here's
the
contents
of
the
string,
it
could
do
things
like
find
roots
and
all
all
sorts
of
very
useful
things
with
a
tool
that
a
tool
can
do
if
it
has
enough
knowledge
of.
What's
going
on.
Unfortunately,
idd
had
some
technology
that
we
couldn't
open
source,
so
we're
currently
working
in
the
community
to
standardize
on
ll
node,
which
is
an
open
source
debugger.
Well,
actually,
LOD
B
is
the
open
source.
Bugger
and
ll.
A
Node
is
a
plugin
that
goes
on
top
of
that,
so
that
you
can
get
those
same
things
in
a
solution
that
will
be
standard
and
open
source
for
all
no
js'
users.
The
end
goal
really
is
that
you
know
you'll
be
able
to
create
your
core
dump
on
any
platform
use
ll
DB
with
LL
node,
to
read
in
those
core
files,
it'll
have
the
understanding
and
it
already
reuses
the
metadata.
That's
in
nodejs
in
terms
of
the
structures
of
v8
the
structures
of
node
and
has
command.
A
You
know,
command-line
options
and
the
debugger
to
print
those
out,
but
we'd
also
like
to
build
in,
and
we
have,
you
know,
have
started
working
on
a
JavaScript
API
that
would
be
layered
on
top
of
that,
so
that
people
could
even
use
JavaScript
to
write
things
that
are
going
to
introspect
the
the
core
files
and
we're
hoping
that
will
open
up.
You
know
even
more
people
getting
involved
in
that
that
end
of
things
as
well.
A
Of
course,
we
want
to
bring
these
tools
that
we're
working
on
into
the
cloud.
So
this
is
actually
a
picture
of.
You
know
one
of
the
the
dashboards
we
can
see
or
will
be
able
to
see
zoom
through
bluemix,
and
you
know
we
want
to
easily
make
options
to
generate
node
reports,
display
them
save
heap
snapshots
or
generate
course
for
your
running
applications.
A
Monitoring
is
also
important
and
and
you'll
see
if
you
go
out
to
the
booths,
there's
lots
of
companies
that
are
developing
products
to
monitor
your
applications
and
production,
so
dynaTrace
off-beat.
We
do
believe,
though,
that
there
should
be
some
level
of
monitoring
that
you
can
get,
which
is
open
source.
So
if
we've
worked
on
an
open
source
monitoring
set
of
tools
called
app
metrics,
it's
out
there
in
github,
you
can
go
collect,
you
can
go,
you
know
download
it
use
it.
A
That
health
center
is
a
client
that
actually
shows
similar
data
for
Java,
and
you
can
use
that
same
client
to
connect
to
both
Java
and
nodejs
instances
to
sort
of
visualize
the
data,
so
at
metrics
itself
as
a
data
source,
it's
an
NPM
module,
you
install
and
then
it
generates
data
about.
What's
going
on,
you
know
your
CPU
usage.
A
Your
HTTP
requests
really
all
sorts
of
things
that
are
going
on
within
your
application.
You
can
actually
write
your
own
consumers
of
that
data,
so
in
JavaScript
you
could
register
for
the
events
and
then
use
those
events
to
say
well,
I'm
going
to
keep
track
of
the
GC
information.
Well,
one
of
the
things
we
put
together
is
this
app
metrics.
So
simply
through
one
line
in
your
application,
you
can
basically
add
a
dashboard
that
will
show
up
on
a
particular
port
of
your
application.
A
You
can
just
h-2b
in
to
see
what's
going
on,
so
if
you're
interested
on
that,
you
can
just
go
to
MPN
and
install
that
particular
package
and,
as
I
said
app.
Metrics
is
another
client
that
that
supports
Java
as
well,
and
so
you
can
use
that
if
you
want
to
as
a
UI
to
connect
to
a
running
application-
and
you
know
basically
see
a
visualization
of
all
the
data
that
app
metrics
is
going
out
there.
A
A
The
first
thing
is
that
you'll
notice
there's
a
bunch
of
different
release
types
there's
nightly
releases,
there's
the
current
releases
I
mentioned,
and
then
there's
the
LTS
releases
and
really
the
goal
is
that
we
we
don't
want
to
trade
off
quality
for
speed.
It's
very
important
in
the
node.js
community,
for
us
to
be
able
to
innovate,
change,
get
things
in,
but
at
the
same
time
we
need
high
quality
runtime
for
people
using
the
production
and
often
people
sort
of
talk
about
those
as
a
trade-off.
A
We
looked
at
as
it
more
in
terms
of
you
know.
How
do
you
maximize
both
of
those
at
the
same
time,
so
the
different
release
types
allow
us
to
have.
You
know
nightly
releases
where
you
have.
You
know,
write
up-to-date
latest
latest
changes
that
went
in
current,
which
is
updated
very
regularly.
So,
every
once
or
two
weeks
you
get
a
new
release.
A
That
has
the
features
that
are
in
master
and
if
you
want
to
sort
of
live
on
the
bleeding
edge,
you
can
work
with
that,
and
then
we
have
the
LTS
releases
where
those
are
the
ones
we
recommend
for
production
and
as
changes
flow
into
the
system.
You
know
that
they're
tested
out
and
master
people
can
try
them
out
in
the
nightly.
Then
they,
you
know
once
they've
sort
of
proved
themselves
there.
For
a
few
weeks
they
flow
into
the
current
release.
A
The
people
who
are
living
more
on
the
on
the
bleeding
edge
can
try
and
validate
those
some
people
like
to
do
that
and
then
only
after
all
that
happens.
Do
we
pull
them
back
into
the
LTS
releases
and
there's
an
additional
level
of
scrutiny
so
that
by
the
time
changes
get
into
LTS
releases
the
chances
that
they're
gonna
regress
things
are
much
lower
and
will
be.
You
know
we
may
not
pull
back
the
really
high-risk
type
changes
so
by
having
the
different
release
types,
you
can
keep.
A
We
have
processes
like
the
enhancement
proposal
process
which
lets
us
discuss
and
sort
of
come
to
agreement
on
larger
changes
so
that
if
you're
gonna
have
bigger
things
in
there,
they're
documented-
and
you
have
more
discussion-
there's
a
very
strong
push
in
the
community
on
automation
and
testing.
So
you
know,
if
you
look
at
the
functional
test,
every
change
it
goes
in
gets
regression
test
against
all
the
platforms.
It
runs
in
about
twenty
minutes,
which
is
pretty
good
depending
on
the
number
of
testing
that
gets
done.
A
In
addition
to
that
testing,
we
have
canary
in
the
gold
one
which
runs
functional
testing
on
a
number
of
modules
that
probably
you're
using.
So
you
know,
there's
lots
and
lots
of
modules
they
out
there
for
hundred
thousand,
but
we've
chosen
the
small,
a
small,
much
smaller
subset
of
the
ones.
We
know
lots
of
people
use
and
are
really
important,
and
we
run
before
every
release
goes
out.
A
We'll
run
testing
on
those
to
make
sure
the
new
release
hasn't
broken
those,
and
we
continue
to
work
on
this
in
terms
of
you
know,
we're
looking
on
building
up
stress,
testing
and
test
based
on
development,
workflows
to
sort
of
continually
raise
the
bar
in
terms
of
the
quality
that
we
can
have
out.
There.
We've
also
worked
in
the
performance
and
benchmarking
workgroup
to
get.
Basically,
you
know
the
Canaries
to
tell
us:
are
we
regressed
in
performance?
A
The
other
thing
that
I've
been
personally
involved
in
I
think
quite
interesting
is
that
native
modules
and
having
to
recompile
them
for
every
version
of
node
has
been
a
bit
of
a
challenge
if
you've
written
a
native
Molly
knowledge,
you
know
that
they're
very
today,
quite
tightly
bound
to
v8
v8
moves
very
quickly.
They
only
support
each
release
for
six
weeks,
and
so
that
basically
means
every
time
you
upgrade
you're
gonna
have
to
recompile
your
your
modules.
Don't
always
have
want
to
have
compilers
in
production,
so
this
makes
things
more
difficult.
A
So
any
p.I
is
an
interface.
That's
going
to
be
provided
by
node
itself
that
wraps
and
how
basically
hides
v8
behind
the
scenes
and
breaks
the
dependency.
So
it's
a
new
set
of
functions
that
you
can
use
in
developing
native
native
modules
that
basically,
once
you
compile
against
one
release,
it'll
can
continue
to
work
without
recompilation.
As
you
move
up
to
new
versions
of
No.
A
Internationalization
was
something
you
know
it's
quite
important
to
ibm's
customers,
and
I
know
lots
of
big
companies,
so
Stephen,
Loomis,
Ric,
Lu,
I,
see
you
lead
with
an
IBM,
was
instrumental
in
working
in
the
community
to
get
ICU
bundled
into
nodejs
and
today.
The
other
thing
we're
working
on
is
the
internal
messages.
Today
are
just
a
string.
A
It
makes
it
very
difficult
for
us
to
upgrade
those
strings,
because
if
we
find
a
typo
or
something
we're
reluctant,
because
that's
potentially
a
breaking
change
to
an
application,
if
it's,
depending
on
the
string
type,
so
we're
going
through
and
introducing
codes
for
every
string,
which
will
let
us
do
things
like
easily
more
easily
change
the
strings,
but
also
then
opens
up
the
opportunities
for
things
like
internationalization
as
well
of
those
strings.
So
that's
that's
another
thing.
A
We're
participating
in
in
terms
of
security,
there's
sort
of
two
aspects,
there's
things
like
features
so
bluemix
needed
a
FIPS
version
of
nodejs.
The
community
had
done
some
work
to
enable
an
option
where
you
could
compile
in
that
way,
and
we
helped
out
by
making
sure
that,
like
the
full
test,
suite
would
actually
pass
when
you
turned
on
Phipps
and
have
it
added
to
part
of
the
nightly
regression
runs
so
that
we
know
that
it's
going
to
stay
consistently
green.
So
we
have
a
job
that
runs
all
the
time.
A
So
really
you
know
the
the
approach
there
was
to
define
the
use,
cases,
identify
and
build
benchmarks
and
run
and
capture
of
the
results.
You
can
see
the
results
that
we
run
every
night
and
it's
still
a
work
in
progress.
In
terms
of
you
know,
we
need
to
get
more
benchmarks
and
we
need
to
run
them.
Those
add
those
to
the
set
of
what
we
read.
We
run
every
night
in
terms
of
building
our
safety
net.
A
A
You
know
how
people
commonly
get
started
on
the
journey
to
cloud
native
and
some
of
the
obstacles
that
might
get
in
your
way
and
then
I
went
into
the
work
that
you
know
we're
working
with
the
community
doing
to
work
with
the
community
to
try
and
work
around
and
provide
solutions
to
those
those
problems,
and
you
know
my
last
pitch
will
be
it's
a
really
open
and
welcoming
community.
So
if
any
of
these
things
are
interesting
to
you,
you
know
come
meet
us
at
github
get
involved,
and
you
know
we'd
love
to
see
you
there.