►
From YouTube: Kubernetes Meetup: Go, go Kubernetes
Description
Leon Stigter, Developer Advocate at JFrog talked about implementing Go Centered modules for his Kubernetes Cluster. He also shared some of his favorite dad jokes and talked about his passon: cloud, serverless and cheesecake.
Check out jfrog.com for more about this awesome tool .
A
B
B
B
That
is
definitely
less
than
I
hope
for
so
obviously
I'll
hope
to
remedy
some
of
that
during
the
the
presentation
and
so
for
everyone
that
does
not
know.
Golang
I
want
to
take
you
to
a
on
a
trip
through
through
history,
essentially
and
and
talk
a
bit
about
about
about,
go
any
any
Java
developers
in
the
house
today.
B
Okay,
that's
actually
less
than
I
anticipated
dotnet,
no
chassé,
okay,
I
see
I
see
a
lot
of
node.js
people.
There
awesome
the
reason
why
I
asked
will
become
clear
in
a
second
trust
me
on
that.
So,
as
you
look
at
a
go
to
Mego
is
one
of
the
most
awesome
languages
as
it
combines
a
ton
of
stuff
from
from
all
the
languages.
I
just
talked
about,
and
it
started
off
in
in
Google
a
few
years
ago,
with
the
first
major
milestone
there,
one
dot
over
release
in
2012.
B
The
second
major
milestone,
at
least
from
my
point
of
view,
was
the
the
1.1
that
5
release
in
2015,
which
had
two
super
awesome
things
it
had.
It
was
the
first
release
where
everything
was
built
in
go,
so
there
were
no
external
dependencies
on
C
anymore,
with
the
obvious
exception
for
force
ego
and
the
other
thing
in
it
started.
Supporting
ven
during
and
ven
during
is
an
essential
concept
of
of
goldang
that
we'll
talk
a
bit
about
to
today
as
well.
B
So
third
major
milestone,
1.8
2017,
it
started
introducing
go
plugins
and
for
everyone
does
not
use,
go
Lang,
but
has
used
any
other
programming
language.
Then
plugins
are
essentially
the
dejar
files.
They
are
the
nougat
modules.
You
know
the
the
stuff
that
you
use
to
to
build
your
your
apps
and
then
in
1.10.
They
made
a
ton
of
changes
in
the
tool
chain
to
run
time
the
libraries
and
did
a
bunch
of
other
awesome
stuff
and,
as
you
look
at
all
their
release
notes,
there
is
one
massive
thing
missing.
B
At
least
from
my
point
of
view.
The
one
thing
that
is
missing
through
all
of
this
is
dependency
management,
as
you
look
at,
for
example,
nodejs.
If
you
look
at
java
who
does
dependency
management
without
our
npm
and
the
package
jason
or
things
like
like
maven,
there
is
an
awesome
way
to
do
version
management.
There
is
an
awesome
way
to
do
dependency
management.
B
Golang
does
not
have
that
today
or
almost,
and
if
you
look
at
a
Christopher
Bullock
who
said
it
is
impossible
to
be
sure
of
anything
but
death
and
taxes.
I
think
that
if
he
was
a
life
today-
and
he
was
a
software
developer,
the
quote
would
be
something
like
this
impossible
to
be
certain
of
anything,
but
that
taxes
and
software
dependencies,
because
who
builds
applications
without
any
third-party
libraries
wait.
We
actually
people
who
did
that
is
awesome.
B
I
really
want
to
talk
to
you
guys
after
this
to
learn
to
learn
about
that,
so
go
realize
that
they
had
to
do
something
because
you
know
building
a
language
with
no
dependency
management
in
there
is
not
that
great.
So
in
111
they
had
it
support
Fuko
modules
and
go
modules
is
essentially
a
great
way
to
do
to
do
version
management.
Why?
B
So,
first
of
all,
by
the
way,
it's
the
official
way
to
do
dependency
management.
So
if
you're
a
goal-line
developer-
and
you
use
anything
else,
then
you
might
want
to
look
at
moving
into
go
modules.
The
other
thing
which
is
super
awesome
to
me
as
a
developer,
ed.
It
no
longer
relies
on
a
go
path,
so
I
I
can
I
can
pretty
much
develop
micro
applications
anywhere
on
my
machine
that
I
want
to
I'm
no
longer
restricted
to
one
single
one.
Single
folder
and
everything
is
embedded
in
one
single
tool.
B
I
mean
I,
don't
have
to
install
a
bunch
of
different
version
management
systems,
a
bunch
of
different
dependency
management
systems
and
to
go
client
I
can
just
do
everything
through
go
now?
The
question
is:
if
you've
done
this
before
then
probably
you've-
and
this
was
one
of
the
the
highlights
that
I
talked
about-
then
you've
used
something
like
vendor
ink
and
great
question.
Why
not
use
vendor
it
I
mean
in
essence,
we've
done
this
before
it
works.
So
why?
B
Why
shouldn't
I
do
that
and
if
you
look
at
vendor
ring
what
vendor
actually
is
is
making
a
making
of
the
literal
copy
of
all
the
source
code
that
you're
using?
And
that
is
a
bad
idea,
because
that
actually
means
that
when
you're
building
your
app
when
you're
putting
it
into
something
like
github
or
whichever
version
control
system
that
that
you
end
up
with
you're,
essentially
making
a
heart
fork,
you
are
now
responsible
for
not
just
managing
your
source
code
of
your
application
but
you're,
essentially
managing
someone
else's
source
code
too.
B
Who
always
is
an
application
developer
here?
Good,
so
when
I
say
that
you
should
only
be
managing
your
own
source
code
and
not
someone
else's,
everyone
agrees
right,
good,
good,
I'm,
happy
that
everyone
is
still
awake,
so
it
actually
means
that
within
software,
immutable
and
repeatable
are
two
incredibly
important
aspects.
Why
is
that?
Well,
first
of
all,
if
you
look
at
immutable
dependencies,
then
it
allows
you
to
create,
builds
that
that
that
are
always
going
to
be
the
same.
B
If
you've
rely
on
vendor,
and
if
you
create
that
that
heart
copy
of
someone
else's
source
code,
then
that
also
means
that
someone
can
do
a
force
push
in
order
to
to
override
what's
already
and
get,
and
that
would
be
a
terrible
thing.
The
other
thing
is
lost
dependencies
I
mean
for
the
note,
G
s
developers
who
all
were
affected
by
left
pad
when
that
disappeared
from
github
right.
Yes,
I
see
someone
that
would
that
was
a
big
problem.
B
Just
making
sure
just
making
sure
okay,
if
you're
sitting
with
your
colleagues
and
someone,
did
not
raise
their
hand.
Just
saying
that's
gonna
be
an
interesting
discussion
tomorrow
morning.
Okay,
so
I'm
gonna
assume
everyone
trusts
our
colleagues.
But
what
about
the
rest
of
the
internet
I
mean.
Do
you
trust
that
single
developer
down
in
Australia?
B
Do
you
trust
that
developer
team
in
Brazil,
that's
making
some
some
awesome
dependency
that
you're,
relying
on
maybe
I,
mean
it's
probably
good
practice
to
do
so,
but
what,
if
they
for
some
reason,
decide
to
remove
their
source
code
from
somewhere?
That's
not
a
great
idea,
so
we
need
a
place
to
store
everything.
We
need
a
place
to
to
keep
all
of
our
of
our
modules
safe,
and
that
is
what
goes
Center
is
so
by
the
way
if
anyone's
wondering
who
that
person
up
on
stage
is
this
is
me
I'm.
B
A
developer
developer
advocate
that
@j
frog,
I'm,
passionate
about
all
things,
server,
those
containers
and
generally
all
things
in
the
cloud
and
especially
if
you
bring
all
of
those
together,
then
I,
love
that
I
love,
dat,
dokie,
that
jokes,
cheesecake
and
API,
so
I'm
gonna,
guess
that
cheesecake
and
api's
are
sort
of
familiar
with
in
this
audience.
Who
all
knows
that
jokes?
B
B
Deafening
silence
anyone
you
can
here
to
see.
Thank
you.
So
thank
you.
Those
are
debt,
jokes,
I
love
them.
So
let's
talk
a
bit
about
ghost
hunter,
because
that's
that's
the
actual
thing
that
we
want
to
talk
about,
because
that
is
the
thing
that
the
application
that
we
build
on
top
of
kubernetes
and
ghost
Center
is
essentially
a
go
repository
free
for
everyone
to
use,
because
we
wanted
to
make
sure
that
whoever
wants
to
build
apps
using
golang
and
once
to
use,
go
modules,
which
you
absolutely
should.
B
If
you,
if
you
use
go,
then
you
should
have
a
free
central
registry
that
that
you
can
make
use
of.
So
you
can
obviously
find
your
the
module
set
that
you're
looking
for
and
download
it
from
there
now.
How
did
we
get
to
kubernetes
because
in
in
essence,
this
is
this
is
the
central
thing
that
that
we're
talking
about
we
made
a.
We
made
a
very
deliberate
choice
to
go
with
kubernetes
for
essentially
for
two
reasons.
First
off
we
wanted
to
make
use
for
this
product
for
this
project.
B
B
Everyone
is
using
it,
and
obviously
there
are
a
ton
of
out-of-the-box
features
that
that
you
want
to
be
using
I
mean
Alex,
did
an
amazing
job
talking
about
that
that
just
now
so
I'm
not
gonna,
repeat
that,
so
we
decided
to
to
build
our
stuff
fun
on
Google
cloud
platform
that
was
there
really
nice
logo
over
there.
Why?
Simply
because
it's
the
most
mature
kubernetes
offering
that
manage
kubernetes
offering
that
exists
today
may
be
true,
we'll
change
it
out
and
then
we'll
obviously
consider
moving.
B
B
Okay,
that's
a
lot
more
Adger,
oh,
not
as
many
as
I
expected,
okay,
but
if
you're
deploying
to
to
do
any
type
of
kubernetes
platform,
there
is
a
very
important
thing
that
did
Alex
touched
on
in
his
presentation
as
well,
is
maintaining
state
and
I
mean
who
actually
needs
state
anyway?
Isn't
it
the
thing
that
we
decided
to
to
do
something
with
these
twelve
things
who
recognizes
this.
B
I
mean.
Why
would
you
why?
Wouldn't
you
use
something
like
Postgres
MongoDB
or
any
of
the
existing
databases
that
are
out
there?
It
makes
total
sense
to
do
that
unless
you're
a
database
engineer,
it
makes
total
sense
to
use
a
messaging
platform
like
pops
up
like
we
use
for
for
go
center,
simply
because
the
guys
that
built
that
that's
what
they
do
for
a
living,
we
don't,
and
it
also
makes
it
a
lot
easier
to
upgrade,
because
we
simply
use
the
latest
version
that
they
have
available
for
us.
B
B
It
also
doesn't
really
hurt
that
one
of
the
cofounders
of
helm
joined
our
company
to
really
make
sure
that
when
we
build
our
products
that
that
we
use
the
best
practices
that
his
and
his
team
set
out
to
work
to
build.
So
some
of
those
best
practices
that
that
we
learned
while
building
those
those
micro-services
are
these.
That
are
the
ones
that
that
are
behind
me
right
now.
So
probably
the
the
most
important
thing
is
setting
limits
and
adding
labels
to
to
your
deployments.
B
Labels
obviously
make
it
easy
to
to
select
stuff
as
you're
managing
your
your
cluster
limits
are
really
really
useful
to
make
sure
your
cluster
doesn't
die
and
yes,
we
found
that
out
the
hard
way,
obviously
doing
things
like
like
secrets,
because
who
doesn't
who
wants
to
have
hard
coded
passwords
in
their
in
their
apps
I
saw
one
person
saying
he
one's
hard
coded.
Okay,
that's
that's
great.
B
And
you
probably
want
to
have
different
namespaces
different
clusters
to
do
things
and
the
way
that
we
set
it
up
and
we'll
get
to
that
in
in
a
second
as
well
is
we
said
we
set
it
up
that
every
namespace
that
you
deploy
into
that
you
create
within
kubernetes
has
their
own
tasks.
So
we
have
things
like
a
an
admin
namespace.
We
have
things
like
a
logging
namespace,
a
monitoring
namespace
simply
so
that
we
can
make
sure
that
every
every
aspect
is
discovered.
B
So
how
did
we
build
our
infrastructure
and
for
people
that
that
no
jay
frog
we're
kind
of
being
on
on
building
pipelines
and
and
doing
promotions
and
stuff
like
that?
So
when
we
build
everything
goes
through
a
CI
server
and
in
our
case
we
went
with
Jenkins.
Simply
because
that's
that's
the
one.
We
knew
very
well
master
you
as
we
build
our
docker
containers,
the
ones
that
actually
go
into
production.
It
sort
of
follows
this
this
pipeline,
so
it
goes
into
integration.
B
It
goes
into
system
test,
but
only
if
certain
quality
requirements
are
met
simply
because
we
want
to
make
sure
that
we
provide
our
community
with
the
best
that
we
have
and,
as
you
look
at
our
entire
infrastructure
right
now,
we
have
five
clusters
running.
So
that's
all
about
the
Deaf
properity
I
mean
we
have
a
cluster
for
production.
Obviously
we
have
a
bunch
of
clusters
for
for
testing
and
we
have
a
bunch
of
a
bunch
of
clusters
for
development.
Our
development
cluster
is
probably
the
biggest
where
pretty
much
every
developer.
B
It
gets
to
have
their
their
own
complete
installation
of
go
center
so
that
they
can
test
out
their
code,
their
feature
branches-
and
that
is
probably
one
of
the
things
that
that
we
learned
is
that,
as
you
want
to
test
having
deaf
properity
having
the
the
exact
same
setup,
even
if
it
is
a
bit
slim
down,
is
incredibly
incredibly
important.
So
we
have
a
few
micro
services.
B
In
fact,
we
have
six
of
them
and
I
want
to
introduce
you
to
all
of
them
so
that,
as
we
go
to
the
next
slide,
you
sort
of
have
a
feeling
of
what
it
does
so.
First
off
we
have
teed
discovery
micro
service
and,
as
the
name
implies,
it
discovers
new
golang
projects,
so
it
essentially
goes
out
to
github
finds
the
most
awesome
projects
that
exist,
obviously
based
on
stars
and
things
like
that
and
sends
it
to
to
the
processor.
B
The
processor
then
takes
care
of
making
sure
that
a
certain
criteria
are
met
so
that
it
has
a
license,
because
you
know
licenses
are
really
important,
that
it
has
in
fact
the
right
number
of
stars.
Things
like
that
that
you
can
actually
do
a
Coquette
for
it,
because
that
is
that
is
pretty
important.
I
mean
how
terrible
would
it
be
if
you
were
to
try
to
get
a
module
that
ended
up
not
being
a
proper
go
much
of
terrible
thing
so
to
notifier,
as
the
name
kind
of
implies,
notifies
our
operations
teams.
B
If
something
is
going
wrong
because
we
highly
believe
in
having
relatively
autonomous
clusters,
but
they
need
to
check
in
with
with
our
teams
every
every
now
and
then
so,
the
other
three
that
that
we
have
are
develop
a
turd,
the
back
end
and
the
UI
and,
as
you
could
see
on
the
previous
slide,
and
this
slide
most
of
our
stuff
is
built
in
in
golang.
The
only
exception
is
the
the
UI
which
is
which
is
based
on
a
note.
B
Yes,
so
when
we
built
go
Center,
we
obviously
drink
our
own
champagne
and
yes,
we
use
go
Center
to
build
Co
Center.
So,
as
you
look
at
at
how
our
cluster
looks
like
this
is
sort
of
what
it
does
and
as
you
can
see,
there
are
the
exact
same,
the
exact
same
pictures
where
the
user
talks
to
the
web
UI.
The
web
UI
then
talks
to
that
that
that
Kent
server
and
all
of
the
communication
is
done
through
through
Google
pops.
B
Up
simply
because
that
helps
us
with
scaling
and
scaling
is
one
of
the
one
of
those
things
that
comes
out
of
the
box
with
with
kubernetes.
But
one
of
the
things
that
is
incredibly
important
as
you
as
you
grow
with
your
project
and
then
up
there.
You
see
things
like
slack
things
like
github
and
obviously
for
for
the
people
that
know
jay
frog.
B
We
obviously
use
artifactory
a
lot
simply
because
that
is
where
those
go
modules
end
up
as
you
start
out,
but
with
testing
the
probably
the
most
interesting
test
set
that
that
you
can
do,
at
least
from
our
point
of
view,
is
a
load
test,
because
it
not
only
tests
how
your
application
is
going
to
be
able
to
react
on
there
under
a
certain
load.
It's
also
going
to
be
able
to
tell
you
how
well
your
kubernetes
cluster
is
able
to
scale.
B
So
for
us,
we
tested
our
UI
with
about
10,000
users,
simultaneously
doing
a
bunch
of
requests
and
making
sure,
on
our
end
that
that
everything
was
I
was
still
properly
running
the
other.
The
other
test
that
we
did
is
we
loaded
our
back-end,
but
about
10,000
modules,
twice,
simply
to
see
what
was
gonna
happen.
So
if
you
look
at
the
the
bottom
craft
there,
you
see
a
bunch
of
spikes
where
the
the
load
was
was
high
enough,
and
you
see
those
those
truss
as
the
as
our
Karina
bless
you
as
our
kubernetes
cluster
scales.
B
B
However,
in
this
case
the
notebooks
are
obviously
the
the
GCP
node
poles
and
Bri
essentially
standard.
We
assad
chose
to
go
with
with
preemptable
vm
simply
because
it
totally
helps
our
helps,
reduce
our
cost
by
the
way.
If
for
people
who
don't
know,
preemptable
VMS
are
the
VMS
that
Google
can
shut
down.
Obviously,
when
you're
running
stateless
apps,
that
is
awesome,
because
in
that
case
it
doesn't
really
matter.
B
We
we
are
looking
into
and
removing
some
of
that
too,
to
the
preemptable
VMS.
So,
as
I
talked
about,
we,
we
did
a
bunch
of
things
using
using
helm,
essentially
making
sure
that
we
set
our
resources.
We
set
our
limits
and
probably
the
thing
that
I
found
most
interesting
simply
because
I
didn't
know
that
before
I
helped
out
with
with
this
project,
is
setting
node
affinity
as
well.
B
So
we
actually
make
sure
that,
as
we
learn
through
those
those
load
tests
which
are
the
most
heavy
use
micro
services,
that
we
sort
of
spread
them
out
through
our
collection
of
nodes
and
then
the
know,
the
pot
anti
affinity
is
you
know.
Sometimes
it
actually
happens
that
our
cluster
is
so
busy
that
every
node
is
utilized,
and
then
we
start
to
have
to
wonder
which
of
the
services
are.
We
are
we
going
to
decorate
first,
and
that
is
where
this
comes
in.
B
If
everything
goes,
ok
and
the
internet
is
going
to
work,
I'll
show
you
a
quick
overview
of
our
kubernetes
dashboard
in
a
sec.
Now,
one
of
the
things
that
that
is
really
important
in
in
twelve
factor
apps
is
that
you
have
one
single
thing
running
in
in
in
your
apps.
You
have
one
process,
however,
there
is
one
slight
exception,
because
you
know
sometimes
our
containers
get
a
bit
lonely.
So
the
only
micro
service
that
we
have
that
has
two
pods
two
containers
within
a
pod
is
our
UI
micro
service.
B
So,
as
I
said,
we
we
do
want
to
keep
in
touch
with
our
with
our
notes.
So
we
make
have
the
use
of
a
tool
called
call
cube
slack,
who
all
uses
slack
here.
Wow,
that's
a
lot
more
than
I
expected
nice,
so
I
don't
have
to
explain.
What's
lacus,
that's
that's
good
and
we
use
cube
slack
so
that
our
kubernetes
clusters
can
inform
our
operators
or
our
DevOps
teams.
What
is
happening
within
the
cluster
so
when
Jenkins
would
be
which
we
use
for
for
our
builds
starts
a
build.
B
They
actually
say
on
on
one
of
our
channels:
hey
guys
we're
gonna
upgrade
this.
So,
as
you
see
stuff
happening,
don't
be
too
alarmed,
then
you
see
a
bunch
of
things
of
where
pods
are
ready,
unready
and
you
know
being
being
scheduled,
and
ultimately
jenkins
is
also
going
to
tell
you
when
the
upgrade
is
done
so
that,
as
one
of
our
one
of
our
teams
pushes
a
new
feature
pushes
an
update
into
production.
Everyone
within
the
company,
everyone
that
that
has
subscribed
to
that
slack
channel,
can
see
what
is
happening.
B
So,
as
we
talked
about
scaling,
we
sent
a
scale
on
our
clusters
on
on
four
different
levels.
First
off
we
do
notes
gooding
so
that
our
notes
get
provisioned
whenever
we
need
to.
We
have
a
collection
of
or
a
maximum
of,
25
nodes
that
that
we
can
use
and,
depending
on
on
how
busy
it
is
Dave,
scale
up
or
scale
down,
and
obviously
let
kubernetes
manage
the
where
all
the
pots
are
gonna
land,
because
that
is
to
me.
B
One
of
the
most
awesome
features
that
kubernetes
has
out
of
the
box
and
one
of
the
reasons
why
we
went
with
kubernetes,
simply
because
it
does
that
now
the
probably
most
common
reason
to
do
skills,
obviously
compute.
So
based
on
on
CPU
usage
of
our
of
our
containers,
we
skilled
things
up
for
skill
things
down.
If
one
micro
service
gets
get
super
busy,
then
we
add
a
few
with
one.
If
that
collection
of
micro
service
is
less
busy,
we
essentially
scale
them
down.
B
The
other
thing
is
based
on
messaging
and,
as
I
said,
most
of
our
cluster
talks
to
each
other
using
using
message
based
systems.
So
if
a
queue
where
messages
land
is
is
getting
a
lot
of
traffic,
for
example,
because
a
lot
of
people
are
trying
to
add
new
modules
into
what
into
go
Center,
then
we
scale
out
the
scale
up.
B
I
should
say
the
the
micro
service
that
is
going
to
be
responsible
for
that,
and
as
soon
as
the
queue
is
less
busy,
then
we
have
to
be
skilled
in
them
too,
and,
as
I
said,
what
goes
up
must
come
down,
usually
speaking,
and
that
obviously
only
goes
for
four
containers.
Your
micro
services
themselves
should
not
go
down
that
made
sense
right,
just
just
making
sure,
and
we
dare
to
dream.
B
I
mean
for
us
go
Center
was
the
or
at
least
what
is
in
production,
now
was
sort
of
the
first
step
of
what
we
wanted
to
do
and
I
did
want
to
once.
You
talked
a
bit
about
what
we
want
to
do
within
everything
goes
go
center
and
it
starts
with
with
chat
ops.
So
we
we
love
slack
and
we
do
a
ton
of
stuff
within
slack
from
seeing
our
builds.
B
As
you
could
see
on
on
screen
to
congratulating
people
whose
birthday
it
is
because
that's
good
for
morale,
the
other
thing
is
that
we
want
to
make
sure
that
our
that
our
DevOps
teams,
who
use
slack
day-in
day-out
to
communicate
simply
because
we
have
a
distributed
company,
that
they
can
use
slack
to
take
control
of
the
kubernetes
cluster.
Take
control
of
the
deployments,
take
control
of
seeing
what
happens
within
the
cluster.
B
The
other
thing
is
that,
as
you
may
recall,
from
from
one
of
the
slides
right
now,
artifactory
sits
outside
of
our
kubernetes
cluster
and
we
really
want
to
get
it
in
there.
So
artifactory
ones
runs
on
a
separate,
separate
cluster
simply
because,
if
you
want
to
scale
artifactory
but
by
the
way
who
uses
artifactory,
okay
really
only
three
okay,
so
as
you
actually
want
to
scale
artifactory,
one
of
the
most
common
reasons
to
do
that
is
based
on
network
traffic
and
right
now,
kubernetes
does
not
allow
you
to
scale
based
on
network
traffic.
B
It
allows
you
to
scale
and
a
ton
of
other
things
except
the
one
that
really
matters
for
us
and
the
obvious
thing
is
we
want
to
have
your
feedback.
I
mean
to
me
as
a
developer
advocate
I.
Think
I
have
an
amazing
job
that
I
get
to
talk
to
all
of
you
and
I
really
want
to
know
your
your
feedback.
I
want
to
know
what
we
can
do
to
make
our
projects
better.
So,
in
order
to
do
that,
you
can
obviously
tweet
at
Jeff
Rock.
B
You
can
tweet
to
me
personally
at
Leon
stickler
or
at
Leyland
snifter
for
our
Dutch
colleagues
here
and
the
nice
thing
is
I'll
actually
tweet
out
a
link
to
the
slide,
so
everyone
that
took
pictures.
That
is
super
awesome,
though
technically
illegal,
with
the
the
new
copyright
laws
that
the
European
Union
just
passed.
B
Thank
you
yes,
but
I'll
allow
it.
So
if
you,
if
you
send
a
question
to
to
I
diverted
to
two
Twitter
handles,
will
make
sure
that
that
you
get
a
response.
So
any
questions
so
far
so
go
Center
is,
is
free
to
use.
When
you
go
to
go
centered
IO!
It's
it's!
A
public
registry
of
Camacho's
free
of
charge,
using
the
exact
same
tools
that
you
would
use
for
for
normal,
go
development.