►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
I'm
Cory
Butler
I'm,
going
to
be
talking
about
CLI,
first
development.
The
CLI
first
strategy
is
a
thought
framework
for
managing
development
projects.
The
main
activity
is
prioritizing
the
design
and
evolution
of
a
command-line
interpreter
throughout
the
software
development
lifecycle
in
simple
terms,
I'm
going
to
show
you
how
to
develop
a
CLI
tool
that
serves
as
the
core
of
your
app,
both
back-end
and
front-end,
and
your
workflow.
A
The
CLI
first
strategy
is
similar
to
the
traditional
software
development
lifecycle.
It
shares
the
same
goals
but
differs
and
how
they're
achieved.
Unlike
the
traditional
approach,
CLI
first
encourages
coding
at
every
stage.
Both
strategies
rely
on
a
team's
ability
to
agree
about
what
is
going
to
be
made.
This
means
teams
must
convert
intangible
concepts
and
ideas
into
something
tangible.
The
CLI
first
strategy
strikes
a
balance
by
replacing
or
augmenting
the
specification
with
a
shared
command-line
utility.
I'll
show
you
how
to
do
this,
but
first,
let's
review
the
tools.
A
We're
going
to
use
I'll
be
demonstrating
the
strategy
with
the
author,
shell
library,
it's
a
lightweight
shell
framework
for
creating
CLI
experiences
in
any
modern
JavaScript
runtime
on
the
Left
we
have
node.js
and
the
right
shows
the
browser
code.
You
can
see.
The
functional
code
is
the
same
for
both
runtimes.
It
only
differs
in
the
import
source
and
how
user
input
is
collected
and
passed
to
the
show.
A
I'll
also
be
using
a
CLI
dev
tools.
Extension
for
browsers,
which
mimics
a
terminal
experience
with
Auto
completion,
hints
suggestions
and
more
to
illustrate
the
planning
stage
of
the
CLI
first
strategy.
Let's
consider
building
a
team
communication
app
an
application
like
this
is
going
to
have
a
couple
of
different
core
features,
may
be
a
member
directory
wall
or
discussion,
feature
profile
management
where
you
can
manage
your
avatar
email
name
so
forth,
and
some
sort
of
notification
feature
that's
going
to
notify
you
when
you
have
a
new
message
or
when
you've
received
a
reply.
A
Now,
like
any
system,
there's
a
number
of
different
concerns
or
disciplines
that
are
gonna
be
required
to
actually
implement
such
a
system
like
the
user,
interface
and
API
database
or
data
store
devops
process,
Quality
Assurance.
This
is
just
a
short
list.
Obviously
there
are
more
in
most
applications,
but
you
get
the
idea.
A
Remember
that
in
the
traditional
software
development
lifecycle,
the
requirements
gathering
process
ends
with
a
specification,
whereas
the
CLI
first
approach
ends
with
software,
and
the
reason
this
is
important
is
because,
in
the
traditional
approach
it's
a
sequential
process,
meaning
that
the
features
are
defined.
First,
then,
you
worry
about
the
implementation
concerns
with
the
CLI
first
approach
were
combining
those
we're
thinking
about
features
and
concerns.
At
the
same
time,
now
the
way
to
address
this
is
fairly
simple.
We
just
need
to
align
on
what
those
features
and
concerns
are
to
do
this
with
a
CLI
tool.
A
It's
actually
pretty
straightforward.
We
need
a
dictionary
of
some
sort
and
what
better
way
to
do
that
than
with
a
help
screen
on
the
right
side
of
the
screen,
you
can
see
a
configuration
for
our
shell.
This
is
designed
specifically
for
the
author,
shell
library
and
we're
providing
a
couple
of
configuration
options.
First,
we're
gonna
call
this
application
team
got
our
description
and
a
version,
and
then
we've
identified
a
several
different
commands.
A
Now
you
may
notice
that
these
commands
are
loosely
related
to
the
features
that
we
have
so
there's
the
user
directory
wall
notification
with
a
small
description
of
each
of
these
now
to
implement
this
we're
importing
this
configuration
into
our
shell
library-
and
this
happens
to
be
the
node
version.
Similarly,
we're
doing
the
same
thing
in
the
browser.
Let's
take
a
look
at
the
results
of
this
and
switch
over
to
a
terminal
here,
and
we
immediately
have
a
help
environment
with
everything
defined.
Now,
let's
take
a
look
at
this
in
the
browser.
A
I'll
open,
dev
tools
here
and
follow
the
instructions
just
tells
us
to
type
team
help,
and
you
can
see
we
have
the
exact
same
information
accessible
in
both
the
browser
and
in
terminal
and
I
mentioned
that
we
were
going
to
be
using
the
shell
I'm.
Sorry,
the
command-line
extension
for
this.
So
let's
take
a
look
at
that.
That's
installed
here,
I'm
gonna,
clear
this
out,
so
you
can
see
the
same
thing
this
by
default.
A
Has
the
help
feature
you
could
type
it
in
like
that
or
you'd
simply
hit
enter,
and
it
provides
you
the
information,
the
same
way
that
you
would
do
if
you
were
executing
this
as
a
command
through
the
console.
So
this
is
a
little
bit
easier
and
you'll
see
that
more
throughout
the
rest
of
this
presentation.
But
at
this
stage
we
have
created
a
very
simplistic
command-line
tool
that
documents
our
system
and
the
features
within
it
that
is
accessible
on
the
desktop
on
a
server
and
in
the
browser.
A
In
a
matter
of
minutes,
the
project
momentum
just
increased
by
creating
a
basic
CLI
help
screen
groups
are
forced
to
trim
the
fat
in
an
almost
surgical
manner.
The
incredibly
direct
nature
of
the
command
line
enforces
ruthless
simplicity,
command
service
standard
terminology
to
define
the
systems
and
applications
being
built.
My
favorite
benefit
of
this
stage
is
the
fact
there
is
working
software,
it
software
that
doesn't
do
anything,
but
the
ideas
are
baked
into
the
core.
This
serves
as
inspiration
and
it's
an
excellent
onboarding
tool.
We
also
have
a
strong
sense
of
competence
in
our
project.
A
A
You
can
see
here
that
it
just
says
not
implemented.
Yet,
let's
take
a
brief
look
at
that
in
the
browser
as
well.
Okay,
so
here
we
can
see
the
exact
same
command
provides
the
exact
same
output
again,
if
we
put
in
user
help
we'll
be
able
to
see
the
same
help
command
as
well,
everything
that
we
did
in
the
planning
stage
immediately
transfers
into
the
prototyping
stage,
and
we
also
have
just
a
small
tiny
bit
of
functionality.
A
Again,
it
doesn't
really
do
much,
but
it
serves
as
a
placeholder,
and
this
is
something
that
we
can
use
to
build
upon
the
future.
The
beautiful
part
about
this
is
that
teams
can
still
work
independently,
regardless
of
the
pace
that
you
go
at
by
providing
some
placeholders
you're
able
to
then
start
incrementally
adding
functionality
into
your
application
into
your
system.
A
Hopefully
it's
obvious
how
rapid
the
transition
is
between
the
phases
of
the
strategy
by
inheriting
the
progress
of
the
planning
phase.
Prototyping
can
be
very
quick
and
super
flexible.
So
far,
the
CLI
tool
has
a
user
authenticate
command.
I'd
like
to
see
this
working
from
a
terminal
and
the
browser
so
I'm,
going
to
start
by
creating
a
basic
working
API,
then
we'll
build
an
API
client
into
the
CLI
tool.
I
pre
built
a
simple
node
API
skeleton
using
the
common
API
library.
A
This
library
provides
many
features
for
rapidly
creating
backends
I've
added
several
endpoints,
representing
the
features
of
the
application
that
we
care
about
along
with
basic
auth
security.
You
can
also
see
I've
launched
the
server
in
the
top
terminal,
I've
also
updated
the
CL
eyes
user
authenticate
command
with
an
HTTP
request
for
an
access
token.
A
So
as
you
can
see,
this
process
is
still
inheriting
the
progress
from
the
stages
before
it
allows
for
us
to
work
independently
in
our
own
area
of
expertise,
UI
API
data
anywhere
else,
yet
we
remain
unified
in
our
approach,
as
software
systems
are
always
changing.
The
CLI
first
approach
can't
prevent
this
from
happening,
but
it
can
provide
a
predictable
way
for
responding
to
change.
Think
of
it
like
having
a
go
to
battle
plan
for
any
situation
to
illustrate.
A
Let's
pretend
the
group
communication
system
has
been
in
use
for
a
while
and
is
proven
to
be
a
reliable
way
to
communicate
with
the
entire
workforce.
In
an
effort
to
boost
morale,
the
system
needs
to
provide
a
new
inspirational
quote
of
the
day.
There
are
a
few
challenges
with
this.
First,
it
involves
a
new,
unproven
third-party
service
to
provide
quotes.
It
also
means
the
implementation
of
the
user.
Experience
may
differ
between
runtimes.
A
At
this
point,
we
can
restart
the
CLI
first
process
for
this
portion
of
the
system.
Think
about
this
in
a
real
production
system.
This
can
be
a
huge
benefit
because
it
reduces
the
price
of
fixing
technical
debt.
In
other
words,
it
won't
cost
you
as
much
time
or
stress
to
change
your
system.
Since
a
command-line
tool
is
flexible,
it
can
be
introduced
to
the
development
workforce
incrementally
the
same
way.
The
original
features
and
functionality
were
introduced.
This
buys
time
reduces
stress
and
keeps
the
system
clean
instead
of
avoiding
change.
People
start
to
embrace
it.
A
A
At
this
point
we
have
the
user
directory
wall
and
notification.
Now
I've
already
pre-configured
this
to
add
a
new
command
called
quote:
we're
using
quotes
dot
rest
here
for
our
quote
of
the
day,
so
we
don't
actually
know
what
we're
gonna
get
back
from
this
right
now.
But
what
we
do
know
is
that
their
API
documentation
shows
us
that
we
get
back
contents
with
some
quote:
it's
basically
a
JSON
object
that
comes
back
now.
We
need
to
present
this
in
different
ways,
depending
on
the
runtime
that
we're
running
in.
A
So
you
can
see
here
that
we're
using
we're
leveraging
the
new
global
this
feature
of
echo
script,
to
determine
whether
or
not
the
window
object
exists,
that's
unique
to
the
browser.
So
we
know
that
if
the
window
object
exists,
we're
in
the
browser,
otherwise
we're
assuming
that
we're
in
no
js'
or
another
runtime.
So
all
we're
doing
here
is
providing
a
block
of
text.
We're
saying
we're.
Gonna
insert
this.
This
block
quote
into
the
the
web
app
with
the
quote
and
the
author
in
node.
A
A
A
In
this
case,
we
simply
made
a
change
to
the
web
page,
so
you
can
see
here
a
kind
of
interesting
concept
where
you
can
come
in
to
the
CLI
dev
tools
extension
or
into
the
console
type
in
a
command,
and
it's
going
to
update
the
UI
now
that
doesn't
work
the
same
way
in
the
terminal,
but
think
about
the
power
behind
this.
If
you
are
an
API
developer
and
your
UI
developer
comes
to
you
and
says
I'm,
not
getting
the
data
back,
that
you're
saying
I
should
be
getting
back
as
the
API
developer.
A
You
can
say
well,
please
provide
me
the
command
that
you
use
to
capture
that
data,
so
the
UI
developer
can
provide
that
command.
The
API
developer
can
go
in
to
the
browser
and
run
the
exact
same
command,
see
the
error.
Take
that
offline
and
use
that
in
their
own
development
environment,
however,
they
see
fit
because
they
have
the
same
command
line
tool.
So
now
you
can
start
troubleshooting.
So
not
only
is
it
troubleshooting
that
way,
but
you
can
take
this
concept
significantly
further.
A
If
you
wanted
to
think
about
unit
testing
integration
testing,
all
kinds
of
things
that
you
could
potentially
automate
with
a
command
line
tool,
that's
the
same
across
runtimes
or
at
least
the
input
and
output
is
the
same,
even
if
the
implementation
is
different
as
it
is
here.
If
you
need
to
integrate
this
with
other
things,
such
as
an
approval
process,
you
could
you
don't
have
to
release
this
quote
command.
You
don't
even
have
to
use
this
quote
command
in
all
runtimes
until
you're,
confident
in
it.
A
So
it's
a
very
light
amount
of
overhead
to
give
you
a
significant
amount
of
flexibility
in
your
development
process.
As
you
can
see,
the
process
of
pivoting
is
very
adaptable
and
it
provides
predictability
in
how
you
adapt
to
change
a
flexible
approach
like
this
has
a
wonderful
effect
on
tech
teams.
It
enables
behaviors
that
create
organic
growth,
which
fundamentally
change
your
development.
Culture.
We've
already
seen
how
the
tooling
and
the
process
can
adapt
to
changing
plans,
new
features,
heavier
development
and
complete
pivots.
The
final
phase
is
maintenance.
A
The
word
maintenance
is
often
thought
of
as
work
done
in
the
aftermath
of
a
new
feature.
The
CLI
first
way
of
thinking
views
it
more
as
growth
activities
is
both
the
end
of
a
cycle
and
seeds
of
the
next
cycle.
For
example,
pretend
the
organization
introduces
a
new
JavaScript
runtime
to
your
standard
stack
like
denno.
Perhaps
the
runtime
has
some
characteristics
that
require
some
modification
to
your
code.
In
demo.
There
is
a
global
window
object
just
like
the
browser
with
the
existing
command
code.
A
A
A
A
A
The
important
thing
to
note
here
is
that
the
app
didn't
break,
despite
the
fact
that
we
made
some
changes
now,
if
it
had
broken,
we
could
roll
back
to
a
prior
version
of
the
tool.
So
you
can
see
that
the
maintenance
process
is
still
inheriting
progress
from
all
of
the
phases
before
it.
You
can
also
start
to
see
that
the
process
itself
can
be
version
control
simply
because
you
can
maintain
multiple
versions
of
your
COI,
such
as
a
fork
or
another
feature
branch.
Anything
that
you
really
want.
A
So
you
have
point
in
time
understanding
of
your
process.
This
whole
project
is
a
lot
easier
with
the
CLI
tools,
simply
because
the
help
is
documenting
the
system
as
we
go
so
as
we
make
changes,
we're
only
changing
that
documentation
when
something
important
changes,
such
as
a
new
feature
or
a
change
to
the
way
that
something
is
accomplished.
A
You
can
use
it
to
ease
into
planning
with
a
tool
that
provides
help,
prove
your
stack
works
by
wire,
framing
placeholders,
together
with
actual
code,
develop
your
part
of
a
system
with
confidence.
Knowing
the
work
you
do
will
be
understood
by
others.
You'll
be
prepared
with
a
battle
plan
for
addressing
change,
maintain
your
applications
with
repeatable
practices.
All
this
can
be
done
well
with
the
assistant
code.
A
At
every
stage,
this
flexible
strategy
can
be
used
for
testing,
onboarding,
documentation,
DevOps
applications
and
even
tooling
whether
you
choose
to
use
it
for
one
purpose
or
many
you'll
benefit
from
the
speed,
simplicity
and
standardization,
a
command-line
utility
provides
for
teams.
It
provides
a
more
streamlined
approach
for
collaboration
and
automating
workflows.
A
Many
organizations
already
have
their
own
homegrown
CLI
tools.
If
this
describes
your
organization,
you
already
have
a
set
of
standards
to
build
upon
and
integrate
into
your
systems
if
you've
never
considered
using
a
CLI
concept
in
the
browser
before
I
recommend
trying
it
out.
In
my
personal
experience,
browser
Co
lies
have
increased
our
productivity
by
an
order
of
magnitude.
Testing
and
debugging
alone
is
far
simpler
when
we
don't
have
to
point-and-click
through
every
user
journey,
we
just
run
a
command.
A
A
If
you
are
interested
in
trying
out
the
CLI
first
strategy,
you
can
use
the
same
tools
you've
seen
today.
I'll
be
posting
more
information
about
the
CLI
for
strategy
on
the
github
repo
listed
here
and
I
can
be
reached
on
Twitter
and
Cora.
If
you
have
questions
about
it,
I
will
most
likely
make
follow-up
videos
as
well
in
the
near
future.