►
From YouTube: dry-rb, collection of next-generation Ruby libraries
Description
dry-rb helps you write clear, flexible, and more maintainable Ruby code. Each dry-rb gem fulfils a common task, and together they make a powerful platform for any kind of Ruby application.
Join bdougie and friends live for Open Source Fridays at https://www.meetup.com/GitHub-Virtual-Meetup
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
Google+: http://google.com/+github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
All
right,
hello,
welcome
to
open
source
friday
figuring
everything
out
right
now.
Let's
see,
I've
got
all
my
screens
everywhere,
yeah
thanks
very
much
for
coming
to
the
at
this
point.
This
is
technically
the
second
edition,
though,
if
you
did
come
to
the
first
one
that
was
sort
of
the
first
edition,
but
we
didn't
really
publish
that,
but
yeah
today
is
a
very
special
day,
because
not
only
is
it
friday,
we
actually
have
tim
riley
here
and
tammy.
You
want
to
say
hello
hi
thanks
for
having
me
excellent
yeah.
A
A
I
do
want
to
also
call
out
if
you
do
have
questions
about
open
source
questions
about
the
project.
I
want
to
talk
about
questions
about
tim
or
about
github.
Please
use
the
chat
to
ans
to
ask
those
questions
and
we'll
address
them
as
we
have
some
breaks,
and
especially
at
the
end
as
well.
I
have
time
permitting.
I
know,
tim's
family
is
actually
out
in
on
a
stroll,
giving
us
some
some
bandwidth
so
which
is
amazing,
clear
yeah.
So
tim
I've
talked
enough.
Do
you
want
to
introduce
yourself
tell
us
why
you're
here.
B
So
I
am
tim
riley.
I
am
a
software
developer
based
in
canberra,
in
australia
and
in
the
open
source
world.
I
work
predominantly
in
the
ruby
community
and
I'm
involved
in
in
several
ruby
open
source
organizations.
One
of
them
is
dry
ib,
which
will
be
our
topic
today,
but
of
late.
I've
also
been
quite
heavily
involved
in
the
hanami
project
and
which
is
a
which
is
an
effort
between
dryabi,
hanami
and
another
organization.
A
B
Well,
my
involvement
mostly
began,
I
guess,
for
background.
I've
been
working
with
ruby
for
a
very
long
time
and,
like
many
other
rubyists
ruby
on
rails
was
my
tool
of
choice,
my
daily
driver,
but
over
many
years
and
many
projects
I
began
to
feel
somewhat
dissatisfied
with
some
of
the
outcomes
I
was
getting
with
rails
and
I
wanted
to
find.
B
B
I
worked
for
a
long
time
in
an
agency,
but
at
the
same
time
not
feel
like
I
had
to
make
so
many
shortcuts
to
get
the
project
out
the
door
under
commercial
pressure,
and
that's
when
I
started
discovering
a
community
of
people
who
were
building
up
this
alternative
ecosystem
of
tools
in
ruby,
and
this
was
back
in
2014,
2015
and
yeah.
So
I
followed
some
people
on
twitter
followed
some
of
the
work
that
I
do
on.
Github
sent
a
few
emails
and
that
ended
up
in
a
collaboration.
B
Now
that
has
lasted
for
nearly
five
years.
It
spans
three
different
organizations
and
the
the
gems
we've
made
to
my
knowledge
are
used
by
thousands
of
developers
around
the
world
and
in
some
rather
large
organizations.
So
it's
it's
kind
of
great
to
see
how
a
a
personal
desire
to
change
some
aspect
of
your
programming
practice
can
actually
turn
into
something.
So
much
bigger.
A
B
You
know
you
can
you
can
bundle
in
your
project,
hit
bundle
open
on
any
gym
and
instantly
dig
in,
and
this
is
not
necessarily
an
experience
you
get
with
other
ecosystems,
and
you
know
github
has
been
a
part
of
that
flow
for
a
very
long
time
too.
So
you
see
the
you
see
this
as
a
collaborative
hub
and
an
easy
way
to
see
what
people
are
doing
and
reach
out
to
others.
So
yeah
I
was,
I
was
familiar
with
open
source.
I
hadn't
done.
B
I
hadn't
made
any
serious
investments
in
it.
I
dabbled,
you
know
you
threw
up
your
personal
projects
online.
I
made
a
couple
of
gems,
which
I
used
myself,
but
perhaps
of
limited
usage
to
others.
So
yeah
it
wasn't.
It
wasn't
from
ground
zero.
I
guess
I'd
done
enough
to
start
to
feel
confident,
and
that
was
some
useful,
some
useful
background,
because
when
the
moment
did
arrive,
when
I
felt
like
there
was
an
opportunity
for
me
to
actually
create
something
of
value
that
people
would
use
to
a
great
extent.
B
A
Awesome
yeah,
I
so
me
personally.
My
introduction
to
programming
at
open
source
was
ruby
on
rails
as
well
like
I
haven't,
contributed
to
ruben
or
else,
but
my
introduction
was
in
that
ecosystem
so
like
having
a
clear
path
to
solve
a
problem
which
was,
I
was
building
web
apps
and
or
I
had
an
idea
for
web
app
and
ruby
on
rails
sort
of
gave
me
all
sort
of
batteries
included
with
it.
B
So
they
try
and
tackle
a
range
of
problems
and
they
do
it
in
a
fairly
coherent
way.
So
a
lot
of
the
dryer
b.
What's
interesting,
a
lot
about
a
lot
of
the
driving
libraries
is
that
they
follow
this
blended,
functional,
object-oriented
approach
to
ruby,
which
hasn't
always
been
very
widespread
in
the
ruby
community.
But
we've
found
it
to
be
really
helpful.
Ruby
is
a
multi-paradigm
language.
B
You
can
write
highly
functional
code
in
it,
but
you
can
also
write
highly
object-oriented
code
in
it.
That's
one
of
the
amazing
things
about
the
language
it's
so
malleable,
but
what
we've
found
is
that,
if
we,
if
we
just
do
a
few
things
like
minimizing
mutable
state
in
our
applications,
minimizing
globals
making
it
so
that
the
objects
that
you
work
with
can
have
a
really
clear
flow
of
data
through
them,
then
what
you
achieve
is
a
really
clear
understanding
of
the
the
flow
of
logic
in
your
application.
A
Okay,
so
like,
if
my
correct
and
like
the
we
started
with
talking
about
ruby
on
rails
and
like
all
batteries
included-
and
you
mentioned-
you
could
choose
what
batteries
you
want.
So
could
you
technically
build
a
ruby
on
rails
with
a
bunch
of
next
like
these
next
generation,
libraries
that
you
had
mentioned.
B
Yeah,
absolutely,
and
for
the
last
few
years
it's
been
something
that
you
have
to
do
with
sort
of
a
lot
of
perseverance
on
your
own
own
behalf.
You've
got
to
figure
out
how
to
connect
things
we
did.
We
did
create
a
few
different
sort
of
umbrella
helpers
that
combined
the
gems
together
and
we
integrated
them
with
the
rotor
routing
framework,
which
is
a
sinatra
style,
micro,
routing
library,
but
using
routing
trees,
but
now
we're
doing
it
with
the
hanami
project,
because
an
army
already
has
a
lot
of
visibility.
B
It
has
a
strong
user
base,
luca
the
maintainer
of
that
project.
His
vision
for
a
web
framework
experience
very
much
aligns
with
ours,
and
so
what
we're
seeing
here,
I
think,
is
a
new
model
of
collaboration
in
the
ruby
open
source
community,
where
we
have
multiple
distinct
groups
working
together
to
create
something
that
is
coherent
and
batteries
included,
while
each
project
still
maintains
its
own
identity
and
while
each
project
still
provides
a
set
of
clear,
independent
abstractions.
B
So
often,
if
you
spin
up
a
rails
project,
you
get
everything
from
the
rails
organization,
bundled
up
there
together
for
you,
but
because
they're
all
developed
together
it
does
mean
that
sometimes
it's
a
bit
harder
to
dig
down
and
tease
things
apart,
and
you
know
there
are
ongoing
efforts
for
that.
But
it's
not
it's
not
their
priority.
The
rails
community,
whereas
ours
is
very
much
a
bottom-up
approach
to
development.
B
We've
implemented
all
the
driver,
libraries
on
their
own
first
to
be
independently
useful,
and
then
we
made
sure
that
they
are
composable
as
gems
so
that
you
can
bring
them
together
in
a
way
that
the
sum
of
their
parts
that
the
end
result
is
greater
than
the
sum
of
their
parts.
So
that's
how
that's
how
we're
looking
that's
the
model
for
this
project,
which
is
yes,
a
coherent
battery
is
included
framework
experience
up
top
powered
by
independent
and
still
independently
useful.
A
Okay
and
then
I'm
curious
about
the
hanami.
I
know
we
started
talking
about
dryer
b
but
like,
and
we
were
focused
on
dryer
b,
but
it
seems
like
there
is.
A
part
of
your
fan.
Club
is
actually
here
well
fan
club,
one
of
your
contributors,
or
I
guess
users,
I
don't
know
we
wouldn't
call
them
customers
in
this
space,
but
so
iowaski
actually
came
through
and
asked
a
question
in
the
chat
he's
familiar
with
nami
2
in
the
template.
A
B
B
We
do
it
because
we
we
love
doing
it
and
we're
trying
to
create
tools
that
we
want
to
use
in
the
future,
but
it
takes
as
long
as
it
takes,
but
in
the
meantime,
I've
actually
been
using
hanami
2
for
over
a
year
using
the
unstable
branches
of
many
of
the
gems,
and
so
I
figured
people
out
there
in
the
community
who
are
interested
in
it.
Shouldn't
have
to
wait
until
we've
shipped
the
next
alpha
which
we're
working
very
hard
on
doing,
but
that
might
still
be
another
month
away.
B
So
that's
what
I
did
just
a
couple
of
weeks
ago,
I
made
a
github
template
repository
that
that
shows
the
that
shows
how
you
can
make
a
hanami
2
application
today,
if
you're
willing
to
live
on
the
bleeding
edge
and
willing
to
figure
a
few
things
out
and
and
really
that's
a
great
way
for
people
who
are
interested
in
seeing
the
progress
of
development,
because
they
can
follow
that
template
as
it
evolves.
They
can
go
in
and
try
things
for
themselves
and
it
just
gets.
B
A
A
B
Excellent,
so
if
you
scroll
up
a
little
bit
so
these
represent
some
of
the
things
that
the
dry,
ib
libraries
do,
and
the
question
was
about
adoption-
and
I
think
one
of
the
benefits
from
approaching
creating
ruby
gems
in
this
way
is
that
it's
very
easy
to
adopt
particular
gems.
You
don't
need
to
throw
out
everything.
You've
done
your
whole
app
framework.
You
know,
hanami
is
an
ambitious
effort
to
create
a
framework
of
the
future,
but
it's
it's
fair
to
say
that
not
everyone's
going
to
rewrite
their
application
on
hanami
2.
A
A
B
Validation
is
a
library
to
help
you
validate
any
kind
of
data
that
you
want
your
application
to
process.
So,
if
you're
building
a
web
app
in
ruby,
what
I
always
recommend
is
trying
to
validate
your
data
as
close
to
the
edge
of
your
application
as
possible.
So
as
soon
as
as
soon
as
you've
received
your
http
request
or
as
soon
as
you've
got
a
json
document
that
you
want
to
process
and
drive
validation,
lets
you
do
that
via
standalone
validation
contracts.
B
So
that
means
you
can
make
a
validation
contract
for
every
single
different
use
case
in
your
application,
whereas
with
the
active
record
or
active
model
style
validations,
those
are
often
bundled
up
with
the
actual
domain
object.
That
they're
meant
to
concern,
which,
which
is
helpful
in
some
ways,
because
they're
all
together,
but
as
soon
as
your
application
grows
and
applications.
Always
do
you
start
to
want
to
break
out
and
validate
things
differently
in
different
contexts
and
drive
validation.
A
B
So
an
example
might
be
say,
say:
you're
building
a
blog,
and
you
have
two
types
of
users
in
your
admin
area.
You've
got
regular
publishers
and
you've
got
sort
of
editors,
and
the
editors
might
be
permitted
to
set
some
more
flags
on
articles
like
they
might
be
allowed
to
set
the
publication
date
or
or
some
other
sort
of
publishing
workflow
flags.
B
So
in
this
case
you
need
to
you,
have
two
different
people:
editing
your
blog
posts,
one
of
them.
The
regular
author
can
only
set
the
title
in
the
body,
and
so
in
this
case
we
can
set
a
validation
contract
just
to
model
those
validations,
whereas
the
the
super
users
or
the
editors,
we
can
write
a
validation
contract
that
models
the
the
full
breadth
of
attributes
that
they
might
want
to
change
on
the
articles.
B
So
here
you
end
up
with
two
separate
ruby
classes:
two
different
ruby
objects
with
different
responsibilities,
and
you
can
work
with
them
much
more
easily
and
understand
each
one
much
more
easily
and
that
that's
a
really
big
part
of
the
drive
philosophy,
which
is
we
value
single
responsibilities.
And
we
try
to
let
our
gems.
A
Okay,
yeah
you're
you're
speaking
like
the
what's
the
sandy
mets
practical
object;
programming,
yes,
which,
for
anybody
who's
unaware
the
putter
book.
This
is
something
I
read
early
in
my
programming
career.
It
actually
changed.
So
I
it
was
like
my
first
job
as
a
junior
engineer.
It
actually
changed
my
approach
about.
B
Yeah
when
I
read
that
book
for
the
first
time,
I
had
that
brain
explode,
I'm
enlightened
moment,
but
then
I
had
immediately
after
this
moment
of
confusion
because
sandy
preaches
such
amazing
practices.
But
then
I've
looked
back
at
the
tools
that
I'm
using
at
the
time,
and
I
just
wouldn't
know
how
to
exercise
those
practices.
Using
those
tools,
like
I
thought,
I'd
be
finding
my
tools
to
exercise
them,
and
all
I
wanted
to
be
able
to
do
was
look
sandy
mitts
in
the
eye
and
feel
good
about
the
code
that
I'm
writing.
B
B
But
it
is
helpful
to
lay
on
some
strictness
where
it
makes
sense
for
your
domain.
So
dry
types
is
a
data
typing
library
you'll
see
the
example
there.
It
gives
you
the
opportunity
to
create
well-named
types
that
represent
certain
cert,
the
structure
for
certain
pieces
of
data
that
you
want
in
your
application.
B
So
you
know
you
might
make,
for
instance,
a
type
that
represents
an
article
slug,
and
you
want
to
make
sure
that
some
piece
of
data
is
conformant
with
a
slug
and
for
example's
sake
we
might
say
a
slug
has
to
be
lowercased
and
dashes
only
so
you
can
create
a
type
that
represents
that,
and
once
you
do
that,
once
you
can
reuse
that
logic
throughout
the
entirety
of
your
application.
Okay,
including
by
making
your
own
struct
classes,
which
is
the
the
dry
structure
there.
Okay.
A
B
A
B
B
They
have
a
state
that
can
be
mutated
in
a
thousand
ways
which
makes
it
hard
to
test
them
hard
to
understand
how
they're
used-
and
it
means
that
you
have
to
be
really
careful
when
you
pass
them
around
your
application,
because
some
view
over
over
a
way
on
the
other
side
of
your
app
might
make
a
query
to
the
database
by
accident
and
suddenly
you've
got
an
n
plus
one
problem
with
dry
struct.
You
have
the
opportunity
to
model
your
domain
entities
as
simple
value
objects,
so
this
is.
B
This
is
an
immutable
object
that
carries
just
the
data
and
allows
you
to
add
extra
behavior
around
that
data.
If
you
want
and
you'll
know,
they'll
always
be
valid
because
they
can't
be
initialized
unless
that
data
is
already
conformant
to
all
those
types
and
attributes.
So
you
get
a
lot
more
confidence
when
you
pass
these
structs
around
and
work
with
them
in
your
application.
A
A
I
was
going
to
hammer
everything
I
knew
or
everything
I
approached
because
I
had
like
all
this
knowledge,
but
you
find
that
really
quickly,
especially
if
you're
in
a
rails
project
that
you
didn't
have
to
build
all
these
other
abstractions.
That
then,
I
think,
might
be
counter
and
productive
like
I
had.
There
was
another
clean
ruby
book.
Actually
I
read
around
shortly
after
that.
I
forgot
the
author
of
that,
but
his
approach
was
like
these
service
objects
and
ice.
We
started
me
and
a
few
other
people
on
our
team
started.
B
There
we
include
that
module
which
defines
the
default
dependencies
that
you
want
to
be
injected
and
each
one
of
those
dependencies
is
a
is
an
identifier
in
this
container
that
that
organizes
the
components
in
your
system,
so
it
actually
becomes
really
low.
Friction
to
start
to
write
single
purpose,
composable
components
that
can
be
tested
independently,
thought
about
in
isolation,
but
then
brought
together
to
achieve
far
more
powerful
results.
A
B
Right
there,
that's
that's
the
last
aspect
of
our
sort
of
functional
approach,
but
I
use
them
a
lot.
They
come
with
some
baggage,
but
I
actually
find
they're
really
helpful
if
you
just
think
about
them
as
a
way
to
signal
successful
failure
for
your
operations,
and
once
you
start
to
do
that,
you
also
get
some
really
amazing
benefits
like
being
able
to
chain
them
together
safely
and
create
sort
of
railways,
railway
style,
programming,
yeah
in
ruby
of
all
places.
B
B
So
the
the
benefit
of
splitting
these
up
is
that
you
can
pick
and
choose
which
of
these
you
want
to
work
with.
If
you
don't
want
to
use
them
all
together
and
so
we've
we've
had
we've
we've
got
thousands
of
users,
I'm
sure
around
the
world.
I
know
that
drive
libraries,
dry
validation
is
used
in
shopify.
They
have
probably
some
of
the
most
gnarly
validations
on
the
planet
when
it
comes
to
shopping,
cart,
validation
and
things
like
that.
Netflix
uses
dry
structure
and
dry
types.
B
That's
because
I
think
I
think
there
are
two
types
of
people
looking
at
dry
bee
projects:
they're
the
types
that
wonder
why
it's
even
necessary,
because
they're
writing
simple
applications
that
rails
serves
beautifully
and
then
the
other
type
is
a
person
who
instantly
recognizes
the
need
for
these
sorts
of
tools
and
and
knows
exactly
how
they
might
want
to
slot
them
into
their
application
and
by
splitting
them
up
like
this.
We've
made
it
possible
for
that
to
happen.
A
A
Actually,
I've
seen
you
in
my
repos,
I'm
very
happy
you're
here
and
a
couple
other
people
too,
as
well
just
been
talking
about
the
fact
that
we're
not
we're
not
playing
games
on
twitch
right
now,
we're
actually
we're
we're
showing
off
code,
which
is
how
games
are
made.
I
guess
I'm
not
sure
if
there's
any
games
that
are
using
this
library,
but
perhaps
the
websites
that
power
those
those
login
dashboards,
I'm
sure.
B
B
A
A
B
B
In
my
in
my
previous
job,
I
was
one
of
the
owners
of
the
company,
so
I
got
to
spend
a
bit
of
company
time
on
it,
but
these
days
it's
all
nights
and
weekends,
and
it's
just
something
that
we've
all
learned
to
become
patient
with
open
source
happens.
When
it
happens,
I
think
ruby
in
particular
doesn't
have
the
huge
corporate
backing
that
you
see
in
some
language,
ecosystems
or
tooling
ecosystems.
B
So
we
just
do
our
best
and
fortunately
our
community
is
really
accommodating
of
that.
You
know
these
two
to
our
benefit.
These
are
still
relatively
small
projects
and
it
is,
it
is
manageable
to
stay
on
top
of
them
as
a
side
project,
but
yeah.
That's
how
that's
how
it
happens
and
I
think
all
of
us,
the
one
nice
thing
about
it-
is
that
we're
not
just
making
this
exclusively
on
the
side.
We
get
to
use
all
of
these
gems.
B
B
You
really
need
to
be
able
to
see
the
problems
and
feel
the
problems
in
your
day-to-day
application.
Development
life
identify,
needs,
try
and
help
satisfy
those
needs
by
building
tools
and
then
use
those
tools
again
to
see
if
they
actually
fit.
That's
a
really
important
feedback
cycle
and
I'm
really
happy
that
I've
been
able
to
work
through
that
feedback
cycle
over
many
years
and
I
think
they
make
you
know
they've
made
for
some
really
well-rounded
tools
today.
A
B
That's
a
good
question
and
I
would
say
that
for
projects
like
ours,
which
are
mostly
volunteer
driven,
those
sorts
of
pieces
of
feedback
and
contributions
are
extremely
welcome.
You
know
if
someone
sees
a
need
and
discusses
it
with
us,
and
we
all
agree
together
that
it's
it's
an
adjustment
or
an
improvement
or
a
new
feature
that
we
think
would
fit
with
the
ethos
of
these
libraries.
B
Then
that
is
really
really
welcome,
and
I
know
piotr
has
certainly
said
on
a
number
of
occasions,
where
he's
gone
through
a
whole
month,
where,
with
tools
like
dry
validation,
most
of
his
job
has
been
merging
community
contributions,
which
is
you
know,
an
amazing
thing
when
you
see
that
open
source
network
effect
start
to
happen,
but
we're
friendly
people,
we
have
a
code
of
conducts
all
our
projects.
These
are.
A
Excellent
yeah,
we
have
some
questions,
I
think
I
said
ayawski,
but
it
had
to
be
10.
10
waski,
but
yeah
twitch
handles
are
challenging,
but
we
didn't
really
address
the
whole
migration
from
version
one,
but
I
think
we
could
probably
if
we
have
time
we
can
jump
into
the
other
project
and
maybe
talk
about
that.
But
I
did
want
to
address
that.
Some
people
are
asking
if
you're
the
maintainer
of
ruby
gems-
and
I
don't
know
if
you
want
to
address
that.
B
A
So
with
the
and
my
understanding
of
like
ruby
gems
is
the
I
get
the
gem
stack.
Actually
I've
built
one
gem,
which
is
I'm
only
going
to
mention
it
because
I
love
mentioning
it
mainly
because
I
built
it
on
a
weekend
like
a
saturday
and
it's
it's
called
marky
markdown,
which
is
not
an
original
name.
I'm
just
gonna
say
that
out
loud
if
anybody's
wondering,
but
this
was
actually
my
first
gym,
I
actually
published
rubygems.
I
built
a
couple
other.
A
I
take
variables
and
markdown.
Actually
my
action
is
called
variables
and
markdown
and
then
my
example
is
like
the
way
it
works.
Actually
I
didn't
do
a
good
job
in
explaining
the
the
code
and
the
readme
as
I'm
looking
at
it
now,
but
I'm
just
taking
a
transformer
and
then
I'm
transforming
that
transformer
and
then
outputs
the
body
with
the
variables
been
transformed.
A
B
A
Took
care
of
that
by
coming
out
with
a
very
simple
rule
yeah
and
we
actually
skipped
over
the
fact
of
dryer
b,
actually
being
the
acronym
itself,
and
we
I
picked
up
on
the
sandy
met's
philosophy
of
practical
object,
project
practical
object,
oriented
design
in
ruby,
but
dry
is
also
our
acronym,
which
is.
Do
you
want
to
explain
dry.
B
Yeah,
it
stands
for,
don't
repeat
yourself,
the
idea
being
that
if
you
have
a
thing
that
you
need
to
do
multiple
times
over,
it
makes
sense
to
build
some
abstraction
to
help
you
do
that
thing
without
repeating
the
the
steps
it's
it's
so
yeah,
we
sort
of
co-opted
that
for
our
organization
name,
because
each
of
these
tools
helps
you
avoid.
You
know
repeating
yourself.
A
A
B
So
the
lib
directory
is
where
all
the
implementation
code
lives
and
that's
the
same
for
all
ruby,
ruby
projects,
typically
ruby
libraries
I
mean
apps-
can
be
a
bit
different
yeah
and
the
directory
structure
more
or
less
mirrors
your
module
name
space.
So
all
of
our
modules,
all
of
our
gems,
live
within
the
dry
name
space.
So
we
have
that
top
level,
dry,
folder
and
so
everything
dry,
validation
related
will
be
nested
inside
validation.
B
So
contract
there
would
be
the
sort
of
that's
the
main
class
that
you
use
when
you
work
with
dry
validation.
So
you
see
that
requires
a
whole
lot
of
other
behavior
yeah.
We
we
use
the
standard,
ruby
tool
for
docs
inline
api
docs,
which
is
called
yardock
so
that
lets
you
define
introductory
help.
Api
api
example
usages
as
well
as
parameter
specifications
for.
A
B
A
A
B
Yeah
I
mean
so
we're
already
seeing
other
drivi
libraries
in
usage
right
here.
We
use
dry
equalizer,
that
is
another
dryabi
library
which
provides
equality
behavior
to
objects.
So
dry
equalizer
here
says
that
a
contract
is
comparable
to
another
object,
a
contract.
If
it's
schema
rules
messages
match
that's
that
top
line
there.
B
So
that's
just
a
very
simple
mixing
that
gives
us
equality
behavior,
it's
a
really
powerful
tool
to
use.
We
also
use
dry
initializer
and
that's
what
gives
us
these
options
below.
So
each
of
those
options
are
options.
You
can
pass
to
the
initializer
of
the
contract
class
when
you
create
an
instance
of
it.
So
that's
these
are
really
kind
of
nitty-gritty
details
about
the
contract.
Okay,
typically
though
yeah
call
here
is
the
main.
B
That's
a
good
one
to
point
out
call
here
is
the
main
interface,
so
you
define
a
contract,
you
specify
your
validation,
schema
and
any
other
validation
rules,
and
then
you
initialize
your
class,
so
you've
got
a
contract
instance
at
that
point
and
then
to
use
it.
You
call
it
with
some
input
data,
and
we
use
call
quite
meaningfully
here
because
each
of
these
objects-
and
this
pattern
is
followed
across
many
of
the
dryabi
projects.
B
Each
of
these
objects
can
be
considered
a
functional
object
or
even
like
a
function
on
its
own.
So
the
idea
is
that
this
is
a
pure
function.
You
call
it
with
some
input.
Data
it'll,
give
you
the
same
output
every
single
time
and
that
class
that
object
can
be
called
multiple
times
over
with
different
inputs,
and
you
get
different
outputs
and
there's
no
sort
of
there's
no
mutable
state,
which
means
that
you
can
much
more
readily
pass
validation
contracts
around
your
app
and
reuse
them
in
different
places.
B
Also
means
you
can
mix.
These
call
for
those
who
are
new
to
ruby
is
the
interface
that
ruby
uses
for
its
closures,
which
are
like
blocks
landers
procs,
whatever
there
are
various
ones,
but
this
makes
our
objects
inter
interchangeable
with
those
which
means
that
sort
of
data
processing
pipelines
become
possible
and
you
can
mix
and
match.
B
B
A
B
Lambda
will
I'm
on
the
spot
here
I
didn't
talk
about
this
years
ago.
You
you
can
do
an
a
lambda
has
stricter
arity
checking.
So
arity
is
like
the
number
of
parameters
that
that
it
takes
and
with
a
proc
or
a
block,
you
don't
have
to
pass
exactly
the
number
of
parameters
that
are
defined
in
those
but
a
lambda.
You
do
and
a
lambda.
You
can
also
do
an
early
return
from,
whereas
you
can't
necessarily
do
that
in
all
situations
with
a
proc
or
a
block.
A
B
Mean
that's
one
of
the
that's
one
of
the
things
that
makes
ruby
great
is
that
there
are
more
than
one
way
to
do
anything.
Yes,
and
it
gives
you
the
the
space
to
to
work
within
to
express
your
logic
in
the
most
concise
or
most
correct
or
or
the
nicest
way
possible,
and
that's
to
its
credit
and
to
its
fault.
But
I
think
it's
why
so
many
people
love
the
language.
A
B
B
So
all
the
behavior
you
get
on
the
output
of
calling
that
contract
is
all
on
the
result.
Object
and
result
does
have
an
errors
message,
so
you
can
check
if
it
was
a
successful
result
or
a
failure,
result
and
then
inspect
the
error
messages
and
you
get
you
get
the
information
about
whether
your
validation
succeeded
and
if
it
didn't
why
it
didn't
succeed.
A
A
B
While
you
change
your
code,
the
more
effort
that
you
put
into
making
those
tests
nice,
the
better
that
cycle
becomes
so
yeah.
We
use
aspect
to
test
all
of
our
all
of
our
libraries
and
in
fact
the
test.
Suite
is
a
great
way
if
you
have
questions
about
how
things
work
and
the
documentation,
maybe
hasn't
quite
explained
it
being
a
volunteer
around
project.
The
docs
are
sometimes
the
last
things
we
do
and
there's
always
more.
We
could
do
there,
but
the
test
suite
is
also
a
great
way.
B
A
I
did
actually
the
first
thing
I
did
when
I
joined
github
I'd
mentioned.
I
don't
actually
contribute
to
github's
github.com,
but
I
did
start
reading
the
test.
Once
I
got
my
laptop
and
had
my
my
github
locally,
I
just
started
just
scrolling
through
because
I
it
was
a
wealth
of
information
because
I
long
term
long
time
rubyist.
B
B
Yeah,
we
actually
have
a
fairly
sophisticated
setup.
If
you
hop
back
to
the
drive
organization,
you
know
one
of
the
things
you'll
see
there
is
that
we
actually
have
more
than
20
different
repositories
that
we
look
after,
and
so
one
of
the
challenges
was
actually
making
it
manageable
to
work
on
all
of
these
and
to
keep
them
consistent
over
time
and
piotr
actually
put
in
a
huge
effort
to
do
this.
B
B
B
A
B
We
also
use
actions
to
build
our
website.
The
website
was
previously
just
a
single
repository
made
with
middleman,
which
is
a
ruby
static
site
generator.
But
you
know
we
had
this
challenge
here,
where
the
docks
would
drift
away
from
the
actual
implemented
features,
because
they're
in
different
repositories.
A
B
Now
we
have
a
doc
site
directory
in
every
repository,
so
dry
validation
has
one
and
that
actually
has
the
markdown
files
for
our
user
documentation
and
then
every
time
there's
a
change
in
those
directories.
We
use
a
github
action
to
incorporate
them
into
the
documentation
website
and
spin
up
a
new,
build
and
push
that
up
to
github
pages.
So
it's
a
really
a
really
nice
cycle
and
it
lets
us
update
docs
and
code
in
the
same
place,
which
is
which
is
something
that
means
we
can
take
care
of
the
both.
At
the
same
time,.
A
B
B
A
B
I'm
not
sure
how
I'm
not
sure
how
the
migration
path
will
look
for
version,
one
to
version
two,
the
the
nature
of
the
applications
isn't
changing.
We
still
have
views
as
standalone
objects.
Actions
are
standalone
objects.
You
still
have
a
routes.
File
hanami
model
will
become
more
powerful,
but
we're
still
building
these
things
and
we're
yet
to
get
to
the
point
where
we
think
about
the
migration
path.
A
Excellent,
so
I
appreciate
you
taking
time
that
they
answered
that
question
too
and
hopefully
ayawski
tenwoski.
I
apologize.
I
didn't
see
if
you
actually
corrected
me
on
your
name,
but
perhaps
she
can
help
and
jump
into
the
the
issues
and
help
triage,
which
brings
me
to
well
one
I'm
gonna
yg.
Actually,
I'm
just
gonna
mention.
I
did
triage
your
issues
in
mutual
fund.
So
just
gonna
just
call
you
out
there
and
answer
your
question.
A
B
Well,
I
think
the
first
place
is
to
go
to
the
website
to
peruse
the
list
of
gems
learn
about
how
they
work
and
start
to
use
them.
You
know
we
are.
These
are
used
by
thousands
of
people
but
relative
to
the
size
of
the
ruby
community,
the
ruby
ecosystem
in
general.
That's
still
a
very,
very
small
number
of
people
yeah.
So
there
are
a
lot
of
use
cases
that
maybe
haven't
been
touched
upon,
because
everyone
has
a
different
application.
Everyone
has
a
different
context.
B
If
there
are
any
gaps
where
they're
not
satisfying
your
requirements
and
then
come
back
to
us
and
chat
about
them,
we
have
a
discourse
forum
where
we
we
talk
about
the
gems
and
we
do
support
and
we
have
a
chat
room
in
zulu,
which
is
a
great
way
for
a
little
a
bit
of
a
faster
back
and
forth.
What
is
is
zoolop,
yeah
zulip
is
the
the
chat
system
there
on
the
right.
Okay,
it's
it's
like
slack,
but
it's
topic-based.
B
So
threads
are
like
a
first-class
feature
and
they
they
support
open-source
organizations
by
giving
free
accounts.
So
we
found
it's
a
really
useful
tool
for
us.
Okay,
so
that
would
be
the
first
step
would
be
just
to
try
them
out
and
then,
if
you're,
using
them-
and
you
want
to
understand
how
things
work
drop
into
the
code
start
to
explore
and
then
come
to
us
in
the
forum
with
questions
and
ultimately,
if
we,
if
we
decide
that
something
can
be
implemented,
then
that's
that's
your
opportunity
to
to
do
something.
B
The
good
thing
about
the
gems,
I
think,
is
that
because
they're
focused
it
is
easy
to
get
a
sense
for
what
they
do.
It's
not
an
insurmountable
task
to
read
through
the
code
of
one
of
these
gems
and
understand
what
it
does
and
because
they're
because
they're
focused
and
because
they
have
a
clear
boundary
like
they're,
not
trying
to
do
everything
which
means.
Hopefully,
contributions
are
more
possible
than
you
know,
gems
that
are
three
four
times
as
old
or
three
four
times
as
big.
B
So
that
would
be
my
my
recommended.
First
steps.
Other
things
you
could
do,
we
have
issues
on
github
and
we
tag
them
as
help
wanted.
Whenever
we,
whenever
we
can
oh
yeah
there
we
go
help
wanted.
You
know,
there's
only
29
of
them.
A
lot
of
these
gems
are
actually
getting
close
or
have
just
recently
passed
their
1.0
release,
which
is
a
big
milestone,
which
means
we're
we're
happy
with
the
initial
functionality.
A
Cool
sorry,
I
was
answering
a
question
about
our
10,
our
non-1080p
stream,
we're
we're
streaming
in
high
output
of
720,
and
it's
really
around
legibility.
I
think
I
spent
a
lot
of
time
in
the
last
stream
zooming
and
doing
a
lot
of
stuff
and
this
stream
I've
not
zoomed,
hardly
ever
so
yeah.
This
is
addressing
that
question
and
yeah.
I
appreciate
this.
This
tour
also
want
to
point
out.
A
B
B
A
B
A
B
B
A
Yeah,
I'm
actually
looking
forward
to
starting
to
use
it
for
my
projects.
I've
had
access
to
it
for
a
bit,
but
it's
hard
to
really
test
the
feature.
When
only
you
have
access,
oh-
and
it
looks
like-
perhaps
I
spelled
it
wrong,
but
it
should
be
stairs
somewhere
team
management-
maybe
it's
not
on
here.
A
For
sure
yeah
we
only
have
a
handful
of
projects
using
it
today,
but
highly
recommend
checking
that
out,
but
yeah
also.
Actually
I
did
want
to
wrap
up
and
wind
down
to
see
github.com
stars.
So
if
you
don't
mind-
and
I
if
I
spelled
that
right,
not
stars
but
stars,
do
you
mind
going
to
that
on
your
your
screen?
Yep
I
like
to
I'm
curious.
A
A
No,
it's
gonna
be
eight
hours
from
now
yeah,
so
we're
doing
a
meetup
with
india.
So
it's
gonna,
be
the
india
meetup
and
highly
recommend
we're
gonna.
Do
it
here
on
twitch.tv
github?
So
if
you
are
around-
or
you
happen
not
to
be
in
this
time,
zone
feel
free
to
check
it
out.
So
I
started
that
repo
because
I'm
announcing
it
right
now
and
then
the
other
thing
is
crazymax
was
actually
on
the
stream.
A
He
was
in
the
chat
earlier
today
and
he
has
a
github
action,
freaking
pages.
So
I
just
started
because
he's
super
helpful
and
he's
answers
a
lot
of
questions
and
shows
up
on
my
streams
and
I
didn't
know
he
actually
had
actions.
Actually,
I
never
even
looked
at
his
his
his
get
up
account
until
today.
So
it's
cool
to
see
crazymax.
It's
got
some
code
out
there
and
87
stars,
that's
pretty
good
too!
B
A
B
He
is
an
amazing
speaker
and
he
shares
his
ideas
openly
and
what
he's
doing
here
is
particularly
interesting
to
me
because
it's
it's
blending
these
two
modes
of
building
websites-
I'm
I
love
writing
with
ruby,
so
I'll
keep
doing
it
for
as
much
as
I
can,
but
not
everything
needs
a
full-blown
app,
so
justin's
experimenting
out
in
the
open
here
with
this
approach
of
writing
a
rails
app,
but
also
having
that
app
host
a
statically
generated
website
for
content
that
doesn't
need
to
be
dynamic.
Yeah.
B
I
think,
trying
to
angle
at
this
from
the
from
the
ruby
side,
which
I
think
is
really
interesting,
because,
despite
ruby,
perhaps
having
gone
past,
that
peak
of
the
hype
cycle,
there's
still
a
lot,
you
can
do
with
it
and
there's
no
reason
that
we
should
give
up
give
up
all
that
we've
learned
necessarily
just
to
try
a
different
application
deployment
or
configuration
methodology.
So
this
is
a
cutting
edge
thing
and
I'm
just
following,
along
with
his
experiments.
A
Yeah
and
it's
funny
that
I
actually-
I
was
completely
unaware
of
this-
so
actually
I
I've
I've
been
watching
justin
since
beginning
of
my
career,
so
I
went
to
my
first
conference.
He
spoke
at
and
I've
just
been
hooked
on
his
his
presence
on
stage,
but
also
the
all
the
libraries
that
he
puts
out
as
well
as
test
double.
They
do
a
lot
of
great
work,
but
this
term
jam
stack.
A
B
B
But
there
is
always
the
opportunity
for
someone
to
try
something
new
and
interesting
in
this
language
and
in
fact
the
language
makes
it
possible
to
try
new
and
interesting
things
easily,
because
it's
so
flexible-
and
this
is
just
another
piece
of
evidence
that
you
can
still
use
ruby
for
so
much
today.
Yeah.
A
Yeah,
it's
awesome.
I
need
to
actually
reach
them
out,
so
this
is
my
podcast
and
I'm
definitely
gonna
reach
out
to
justin
to
see
if
he
wants
to
chat
about
static
rails
and
the
that's
the
story
behind
that
project
and
also
I
just
gave
it
a
star.
I
encourage
everybody
in
the
the
chat
to
also
give
it
a
star.
I
want
to
shout
out
that
someone
starred
the
hanami
2
application
template,
which
was
your
project.
B
A
All
right,
excellent
yeah,
so
I
gave
that
a
star,
so
they
you
have
16.
Everybody
else
falls
to
share
stars.
I
mean
they're
free,
so
like
don't
hold
out
and
yeah
tim
thanks
very
much
for
for
jumping
on
and
chatting
with
me.
I
had
a
lot
of
fun
learning
about
this
project.
I
don't
know
if
you
have
a
hard
stop,
but
if
anybody
has
any
other
questions
feel
free
to.
A
A
Cool
well,
there's
no
questions
yeah.
I
I
think
this
was
super
insightful
and
I
I'm
always
looking
for
reasons
to
write
ruby
code
and
that's
why
some
of
my
actions
are
powered
by
ruby,
and
I
was
super
pleased
to
see
that
you
had
that
you're
using
actions
to
keep
all
your
your
project
in
sync,
so
I'm
gonna
actually
dig
deeper
into
that,
and
actually
I
should
even
start
that
repo
too
as
well.
I
I'm
a
big
fan
of
starring,
so
I'm
just
gonna.
A
Excellent
yeah,
it's
also
cool,
like
I
think
mine,
are
actually
mostly
javascript
projects,
because
that's
what
I
spent
the
last
three
years.
Writing
is
tons
of
react
code
at
my
previous
employer,
but
yeah
I'm
at
52,
ruby,
254,
javascript.
So
there's
a
bit
of
an
imbalance
in
my
actually
in
47
go
so
actually
I
start
as
much
ruby
as
I
do
go.
A
So
that
was
a
that
was
another
life
though
the
go
code,
excellent!
Well,
I'm
gonna,
I'm
gonna
end
the
stream.
I
think
let
me
just
give
a
last
check
with
the
chat
this
everybody's
just
dropping
emojis
and
stars
and
yeah
big
fan.
So
if
you
wanna
sit
good
chat,
chat
still
stays
on,
but
the
stream
will
stop
now.
So
everybody
have
a
good
weekend
and
go
ship
some
code
just.