►
From YouTube: hyper TSC September 7 2021
Description
Monthly update of the hyper project
* Intro to hyper-test and hyper-connect
* using cloud.hyper.io to build hyper-cloud dashboard
* getting close on bounty contracts for open source contribution
* working on hyper-cloud dashboard documentation using git markdown and archbee
A
A
You
can
give
it
an
endpoint
and
it
will
pull
the
list
of
services
from
that
endpoint
and
then
run
full
end-to-end
tests
for
those
services.
So
it'll
really
help
us
validate
adapters
and
the
the
nice
thing
about
it
is.
Is
it
it
tests?
It
tests
everything
it
tests
all
the
features
of
a
given
api
and
will
be
made
more
robust
over
time,
but
it
tests
both
happy
and
sad
paths
test
all
kinds
of
options
like
for
querying
or
listing
documents.
A
A
And
then
the
other
thing
that
that
I'm
working
on
and
and
I
think,
is
pretty
exciting-
is
hyper
connect.
I
think
we
have
a
pretty
solid
api
kind
of
dsl
and
we
actually
took
the
attack
of
it.
Returning
a
request,
object
and
with
the
fetch
api,
you
can
take
a
request.
You
can
pass
either
a
string
of
a
url
to
the
fetch
call
or
a
request
object.
A
So
what
this
allows
us
to
do
is
build
the
request,
object
inside
the
connector
library
and
then
just
return
it
back,
and
then
the
user
of
that
connect
object
can
extend
it
to
whatever
they
want
if
they
want
to.
So
it
really
comes
together
as
kind
of
this
nice
kind
of
primitive
that
you
can
build
on.
You
can
either
just
call
fetch
or
if
you
wanted
to
call
your
own
version
of
a
fetch
command
or
use
axios
or
other
things
you
can.
A
A
A
You
know
in
the
next
couple
weeks,
if
not
sooner,
I've,
I've
been
able
to
verify
two
data
adapters
and
two
cache
adapters
with
hyper
tests
so
far
and
I'm
jumping
on
search
and
then
I
have
storage
and
q
and
as
I
do,
those
I'm
building
out
the
connect
and
the
test,
we're
also
working
on
hyper
cloud
and
I'll.
Let
tyler
talk
to
that
tyler.
If
you
want
to
spend
a
few
minutes
talking
about
the
hyper
cloud
dashboard
and
where
we're
at.
B
B
Placing
all
of
its
data
inside
of
cloud.hyper,
so
that's
a
bit
confusing,
but
basically
we
are
dog
fooding
cloud.hyper,
to
build
out
the
hypercloud
dashboard,
so
the
hypercloud
dashboard
has
its
own
application
inside
of
cloud.hyper
and
that's
so.
It's
and
we've
set
up
the
zero
touch
dev
environment
inside
of
git
pod.
To
where,
when
you
spin
up
a
branch,
you
check
out
anything
on
your
git
pod.
B
It
will
automatically
bootstrap
the
hyper
cloud
application
within
cloud.hyper
and
spin
up
all
those
services.
It
will
seat
it
with
a
bunch
of
stub
data
that
we've
been
using
and
then
it
just
hooks
everything
together
and
hooks
together.
The
dashboard
with
the
locally
deployed
hyper
application-
and
it's
been
really
nice
so
far,
so
I
can
just
check
out
any
branch
and
just
start
plugging
away
and
coding
away.
It
feels
really
good
nice
in
terms
of
feature
work.
We
are
just
chugging
right
along.
B
I
just
got
the
create
account
mutation
working
inside
of
hyper
cloud.
Everything
is
being
sourced
from
from
hyper
now
in
terms
of
our
our
queries
exposed
through
our
graph,
we're
using
graphql
on
the
back
end
of
hypercloud
and
where
you've
started
to
implement
all
of
the
mutations.
Now,
and
I
have
the
happy
path
for
create
account
which
goes
and
given
like
a
name.
B
But
with
all
of
that
in
place
the
rest
of
these
mutations
around
like
creating
new
teams
and
creating
new
applications,
those
will
be
spun
up
much
more
quickly.
I
think
so.
Making
good
progress,
we're
still
trying
to
sort
of
stick
to
the
trying
to
keep
our
code
as
functional
as
possible,
heavily
using
those
algebraic
data
types
from
crocs,
where
we
can
and
just
trying
to
keep
everything,
nice
and
composable.
B
So
that's
been
fun
but
making
really
good
progress
there.
I
know
tripp
has
made
a
lot
of
progress
on
the
front
end,
but
I
can't
speak
specifically
to
all
the
work
that
he's
done.
I
know
he's
put
together
the
the
form
right
now
he's
currently
working
on
docs
for
hyper
cloud
that
will
be
hosted
in
archbie
and
he's
using
like
the
markdown
approach.
So
we
can
keep
all
of
our
diversion
control
and
just
deploy
those
directly
from
from
the
repo
which
will
just
all
by
presumably
just
ci,
which
would
be
really
nice.
A
B
B
As
we
talked
about
earlier
today,
we
did
find
one
issue
with
the
versailles
fetch
a
sort
of
opinionated
library
which
kind
of
wraps
fetch.
Unfortunately,
it
doesn't
accept
a
request.
Object
like
the
right,
like
the
vanilla
fetch
does
so.
Hopefully,
I've
put
in
an
issue
with
them
as
a
sort
of
feature,
request,
slash
business,
sort
of
thing
going
to
be
supported,
but
keeping
our
finger
on
the
pulse
there.
A
C
A
Cool
and
then
the
other
kind
of
side
note
has
been
working
with
casey
on
and
and
tyler.
You've
looked
at
it
too,
as
on
kind
of
a
a
contract
approach
to
building
out
adapters,
and
I
think
we're
pretty
close
with
with
that
approach,
and
hopefully,
next
update
we'll
have
have
something
ready,
but
casey
any
updates
from
from
your
end
that
you
want
to
share
on
that
experience.
You
feel
like
we're
getting
close
to
like
a
really
well-defined
kind
of
contract
and
statement
of
work.
D
Yeah,
I
think
getting
close
as
as
you're
aware.
That's
what
we've
talked
about
it's
kind
of
hard
to
find
the
lines
like.
Oh
you
got
open
source
software
you're
making.
What
do
you
what's?
What's
you
know
all
the
all
the
challenges
of
doing
open
source,
but
having
it,
I
guess,
sort
of
proprietary
open
source.
I
don't
know
how
else
to
describe
but
yeah.
No,
I
think
it's,
I
think,
we're
getting
close
yeah.
A
Some
other
folks
are
doing
is
is
is
essentially
offering
grants,
but
I
don't
have
a
lot
of
experience
with
grants
and
and
how
those
work,
I'm
just
more
accustomed
to
kind
of
contract
development
work
so
in
in
the
one
you
know,
one
challenge
with
contract
is
is
really
you
have
to
have
language
in
there
that
covers
a
very
broad
area
and
then
and
with
open
source.
You
know
a
lot
of
the
you
know
like
like
a
non-disclosure
right.
If
you've
ever
looked
at
a
non-disclosure
agreement,
it's
not
to
decl
disclose
anything.
A
That's
this
ip
related
well
with
open
source.
You
shouldn't,
be
you
shouldn't,
have
anything!
That's
a
trade
secret
or
anything
like
that.
So
it
shouldn't
be
an
issue,
but
do
you
take
that
out
or
or
not
you
know
kind
of
thing?
Do
you
just
because
it
shouldn't
doesn't
mean
that
it
can't
and
and
those
are
kind
of
the
hard
questions
to
answer
and-
and
you
know
same
thing
with
non-compete
and
and
that's
a
difficult
question
to
answer.
A
But
you
know
our
open
source
is
apache
too,
but
but
I
think
we
want
to
figure
out
how
to
contract
developers
and
pay
them
to
build
adapters,
but
also
they
shouldn't.
You
know,
I
don't
think
we
want
them
to
start
their
own
hyper
kind
of
company
and
compete
with
us
or
or
do
we
care.
You
know
those
are
questions
to
to
think
about
and
answer.
A
B
Yeah,
there's
a
yeah
there's
a
lot
to
unpack
there
I
mean,
I
think,
a
lot
of
the
the
way
that
we
license
the
the
work
that's
produced,
or
maybe,
if
they're
already
like
working
on,
they
like
they're,
fixing
a
bug
and
a
pre-existing
like
adapter
or
something
like
that
or
adding
a
new
feature
to
an
existing
adapter,
because
the
the
license
will
be
important.
But
in
terms
of
if
it's
like
something
brand
new,
I
guess
it's
a
there's.
Some
nuance
there
that,
frankly,
I'm
not
a
lawyer.
So
I'm
not
exactly.
A
A
A
And
and
so
we're
working
towards
that,
but
I
think
from
the
kind
of
the
statement
of
work
or
the
requirements
document.
I
think
that
that
we're
pretty
good
with
that
there's
a
couple
little
adjustments,
tyler
that
you
recommended,
but
overall,
I
think
from
what
casey
said
that
he
felt
like
that
was
pretty
clear
of
the
ask.
So.
D
So
hyper
test
will
be
a
game
changer
for
that,
if
you
know
I
mean
that
that's
the
majority
of
what
the
the
tests
are.
You
know
that
the
adapter
developer
would
be.
Writing
would
be
sort
of
covered
in
that
use
case
or
you
think.
So
what
are
you
thinking
as
far
as
would
the
developer
of
the
adapter
at
that
point?
Basically
be
just
testing
almost
more
like
unit
type
stuff,
or
would
they
still
be
doing
more
internal
tests
of
their
services
like?
What
are
you
thinking
there.
A
Yeah,
so
with
with
what
I've
played
with
so
far,
I
I
would
be
really
comfortable
moving
towards
more
of
a
unit
test
approach
and
then
running
hyper
test
in
in
the
ci,
but
I
think
I
think
we
have
to
go
through
kind
of
two
steps
I
think
one
is
is.
I
want
to
get
all
the
services
kind
of
tested
through
hyper
test
and
then
circle
back
and
get
trep
and
tyler
to
kind
of
review
it
and
and
basically
say
well.
A
You
know
we
need
to
add
this
test
and
this
test
and
this
test
and
just
do
an
iteration
just
to
get
a
second
pair
of
eyes
on
it,
but
I
think
at
that
point.
Yes,
I
I
think
that
if
we
feel
comfortable
after
a
pretty
thorough
review
or
audit,
that
that
we
could
say
you
know
and
and
I'd
love
to
say
is
if,
if
hype,
if
hyper
test
passes
your
adapter,
then
that's
immediately
a
v1
stamp
right.
You
know
you
should
be
able
to
to
stamp
that
as
a
version
one.
A
So
that's
that's
where,
where
I
would
like
to
be,
I
think
we
just
have
to
make
sure
that
we
we're
all
confident
in
hyper
tests
to
to
to
be
that
and
and
once
we
are,
I
think
that's
that
would
be
be
totally
fine
with
me.
I'm
I'm
like
as
long
as
long
as
the
tests
are
covering
the
code
and
if
hypertest
does
a
a
really
good
job
of
that
coverage,
then
then
I
would
only
write
unit
tests
for
adapters
and
use
hypertest
to
test
the.
B
Yeah,
I
think
I
think
a
lot
of
adapters
will
have
with
with
the
addition
of
hyper
test.
I
think
a
lot
of
adapters
will
have
very
small,
like
test
footprints,
the
ones
that
I
think
will
be
larger
and
have
sort
of
might
have
more
unit
tests
than
I
agree
with
what
tom
was
saying.
As
far
as
what
most
of
the
tests
that
a
developer
is
going
to
be.
Writing
is
specific
to
their
implementation
or
any
sort
of
utilities.
B
They
build
out
to
fill
out
their
adapter,
but
I
could
see
the
adapters
for
the
data
port
where
they
have
to
implement
like
the
query
api.
That
might
be
something
that
developers
might
have
more
unit
tests
for,
but
again,
like.
I
think,
hypertest
will
try
and
hit
all
of
like
the
big
parts
of
that
query
api
as
much
as
much
as
it
can
just
to
give
developers
more
confidence,
and
then
they
just
have
to
worry
about
the
little
parts
of
their
specific
implementation.
B
But
I
suspect
that
most
of
like
they
would
it's
going
to
drastic
hyper
tests,
would
drastically
decrease
the
amount
of
tests
that
a
developer
would
need
to
write,
because
it
I
mean
hyper
tests,
tom
craig.
If
I'm
wrong,
it
tests
the
adapter
as
just
a
black
box,
that
it
mounts
it
on
a
hyper
instance
and
then
just
consumes
hyper,
and
so
it's
testing
like
a
full
like
integration
test
with
like
a
hyper
router
or
the
hyper
application
and
like
what
goes
into
it
and
what
goes
out
of
it.
B
A
Yeah,
speak
speaking
for
me.
It
really
once
I
got
both
the
and
the
dndb
adapters
passing.
I
had
a
lot
of
confidence
in
both
of
those
implementations
because
it
is
going
and
end
in
and
yeah.
I
I
mean
there's
def,
but
the
nice
thing
is:
is
we're
going
to
continue
to
add
to
hyper
test,
but
what
what
I
think
is
really
cool
about
it
is,
we
add
it
once
and
then
all
the
adapters
get
that
robust
test.
B
A
Yep
yeah
and-
and
I
think,
yeah
and
again
you
know
this
is
probably
three
steps
down,
but
I
think
we
can
take
the
the
template,
the
the
adapter
template,
and
you
know
we
we
have
the
harness
in
there
that
runs
hyper.
Then
we
can
kind
of
attach
hyper
test
to
that
template.
So
when
you
start
to
build
an
adapter
out
of
the
gate,
you've
got
hyper
test
ready
to
rock.
A
So
I
think
that
that's
what's
really
exciting,
because
you
know
we're
moving
from
a
process
like
casey
when
you
first
started
that
it
was
completely
cumbersome
and
having
to
go
all
these
places
to
tie
all
the
bits
together
to
probably
by
the
end
of
the
year,
a
very
frictionless
process.
Where
literally
you,
you
know
fork
the
adapter
template
spin
it
up
in
github
and
start
writing
your
implementation
and
start
running
hyper
test
against
that.
D
Yeah,
that's
the
single
biggest,
I
would
say
individual
like
most
significant
individual
technical
change
that
I
can
think
of
from
the
perspective
of
an
adapter
developer.
That'll
that'll
not
only
solve
a
lot
of
the
setup
problems,
but
it'll
also
resolve
a
lot
of
the
ambiguity
of
well.
I
think
I
implemented
what
you're
trying
to
say,
but
I'm
not
really
sure
I
think
it
will
yeah.
I
think
it'll
make
that
just
in
general
way
way
easier
and
way
way
faster,
so
very
excited
about
that.
A
C
C
Just
it's
mainly
low
hanging
fruit
right
now,
just
keep
myself
busy.
So
it's
going
well,
it's
in
my
current
branch
posted
to
a
few
times
today.
Sorry,
I'm,
like
I've,
got
my
conversation
with
the
wife
lost
track
of
time.
Yeah,
no
problem,
I'm
late,
I
apologize
but
yeah.
I
would
say
overall
it's
going
well,
it
would
be
nice
to
you
know
next
steps.
C
A
C
A
Got
it
all
right
sounds
good,
hopefully,
they'll
get
it
resolved
soon
and
yeah.
So
that's
all
that
I
have.
We
are
going
to
be
we're
going
to
have
a
a
booth
at
all
things
open
in
october,
we're
heading
october
17th
through
the
19th,
so
that's
exciting
and
we'll
be
giving
a
talk
there
and
I
think
it'll
be
a
really
cool
conference.