►
From YouTube: Walk Through - Ops Section Object Naming
A
Hello,
everybody,
my
name
is
kenny
johnston,
I'm
a
director
in
our
product
organization.
I
am
going
to
do
a
walkthrough
today
for
what
I'm
calling
ops
section
naming.
So
this
is
something
that
I'm
going
to
go
ahead
and
share.
My
screen
that
I
have
been
thinking
about
recently,
as
we
have
had
a
couple
of
this
one
right.
A
A
And
show
you
a
couple
of
these
examples,
so
the
first
one
I
want
to
show
you
is
pipelines.
So
let's
go
to
this
one.
This
has
some
old
pipelines
and
when
I
look
at
my
cicd
view
and
look
at
the
pipelines,
I
see
this
big
list
of
pipelines
and
the
like
primary
thing
that
jumps
out
to
me
is
this
number,
like
the
thing
that
I
can
click
into
to
drill
down
into
this
pipeline
is
the
number,
but
the
number
is
meaningless
to
me.
A
Even
when
I
drill
into
this
specific
pipeline,
it
gives
me
the
commit
name
which
is
kind
of
helpful,
but
I
really
want
to
know
that
commit
name
and
whether
or
not
I
think
for
me
it's
that
it
is
a
master
pipeline
and
that
this
is
the
commit.
So
maybe
some
kind
of
hash
of
master
dash,
the
first
couple
of
maybe
first
20
or
30
characters
of
the
commit
would
help
me
when
I'm
looking
at
it
in
a
pipeline
view,
or
someone
sends
me
a
link
with
a
reference
instead
of
just
seeing
the
number.
A
I
see
something
actually
useful
to
me.
That
would
help
me
understand
what
I'm
looking
at.
It
takes
a
little
bit
of
cognitive,
cognitive
load
for
me
to
just
go
from
now.
Let's
just
say
somebody
randomly
sent
me
this
link,
I
follow
the
link
here.
I
am
looking
at
this
pipeline.
It
takes
me
some
time
to
figure
out
what
exactly
am
I
looking
at.
I
have
to
parse
master
that
this
is
the
commit.
A
This
is
the
commit
reference
down
here.
I
believe
yeah.
So
this
would
be
the
reference
for
that
commit
shaw
and
telling
me
what
changed,
but
would
be
great
if
at
the
top,
instead
of
just
saying
that
the
name
and
this
pipeline
number,
it
said
something
more
useful
that
helped
me
identify
what
this
pipeline
was
doing.
The
exact
same
pattern
happens
with
jobs.
A
When,
when
I'm
looking
at
this,
I
don't
have
to
think
like
what.
What
in
the
world
are
all
these
various
numbers
and
then
go
look
over
here
for
that?
What
job?
What
stage
was
in
my
pipeline
and
what
the
name
of
the
job
was.
So
that's.
Jobs
are
another
example
where
I
think
we
add
a
bunch
of
cognitive
load
for
our
users
when
we
don't
necessarily
have
to
that,
there's
a
way
that
our
users
think
about
these
objects
in
in
our
application,
and
we
should
just
surface
those
more
natively.
A
Let's
look
at
some
other
things
in
the
ops
section
and
see
if
we
can
spawn
any
other
examples.
Let's
look
at
environments,
okay,
so
environments
make
sense
deployment
217,
I'm
actually
not
sure
if
that
is
a
job
number.
So
this
deployment
number,
maybe
is
a
place
where
we're
using
a
number,
but
we
don't
have
to.
This
is
the
actual
job
that
did
the
deployment,
but
maybe
we
keep
separate
track
of
this
number,
but
it
would
be
great
to
reference
more
yeah.
A
I
look
at
the
status
okay,
so
yeah.
This
id
is
just
number
of
deployments
so
that
you
could
do
things
like
roll
back.
Those
are
deployment,
jobs,
probably
specifically
and
we've,
given
them
a
unique
number,
but
again
that
infer
this
id
number
is
not
super
useful,
but
it's
the
first
thing
we
put
in
front
of
users
line
of
sight
when
they're
looking
at
this
list-
and
I
don't
know
the
job
information-
is
pretty
much
useless
because
it
cuts
off
where
I
would
actually
find
some
valuable
information.
A
If
there's
any
way,
I
can
get
it
big
enough
to
give
me
anything
more
than
that
number
yeah,
and
so
the
commit
is
interesting.
It
would
be
great
if,
instead
of
id
and
job,
we
had
some
something
that
gave
me
a
useful
way
to
look
at
this
and
understand
what
the
actual
change
was
or
maybe
at
a
minimum.
You
just
move
the
commit
column
over
since
that's
the
kind
of
core
thing
that
appears
to
change.
A
In
this
case
it
looks
like
they're
doing
some
semantic
versioning
with
their
commit
messages,
so
even
that
just
only
having
a
handful
of
characters,
you're
already
using
a
bunch
of
them
for
that
automation
was
of.
I
would
imagine
some
release
content.
Okay,
let's
go
back!
This
is
my
examples.
My
example
app
that
I
run
a
bunch
of
these
pipelines
a
long
time
ago
hold
on
that
happened
to
me
once
before,
when
you're
in
zoom,
and
you
accidentally
zoom
with
your
magic
mouse,
it
gets
stuck.
A
So
maybe
it's
like
production
and
when
there
are
these
generic
kind
of
uuids,
you
would
do
just
numbers
to
help
our
users
understand
and
maybe
the
mouse
over
gives
you
some
more
detail,
and
then
this
postgres
sidecar
app.
We
would
want
to
call
just
what
we're
calling
it
the
fact
that
I'm
already
scoped
to
production
and
it's
still
timing
production.
You
know-
maybe
not
as
useful
to
duplicate
that
there,
but
overall,
not
the
same
pattern
that
we
are
seeing
error
tracking.
Let's
look
at
errors,
so
this
one's
cool
and
open
errors.
A
A
A
Yeah,
so
severity
is
probably
the
most
important
thing
time
most
recent
c
is
great
and
then
the
alert
name
has
both
a
number
and
some
brief
description.
That's
cool!
We
don't
need
the
number
in
that
case,
when
I
click
on
it.
It
takes
me
to
the
alert
detail
yeah.
So
maybe
the
alert
is
not
super
helpful.
Sorry
that
alert
number
is
not
super
helpful,
but
still
great,
that
we've
got
an
actual
alert
name.
A
Let's
look
at
incidents,
okay,
so
here's
a
bunch
of
instance
similar.
I
like
this
start
with
severity,
then
we've
got
an
instant
name
time
created
sla.
That
makes
sense,
for
instance,
yeah
I'll
have
a
name,
and
in
these
cases
I
think
in
the
incident
you
users
can
edit
the
name
except
true
of
alerts
too.
A
Can
I
edit
the
name?
No,
I
can't
so,
let's
call
it.
It
picked
a
useful
name,
even
though
I
didn't
a
user
didn't
provide
it.
This
was
probably
in
some
automated
fashion
when
creating
the
alert
integration
but
great
to
see
that
it's
not
yeah
that
we're
using
the
right
using
something
that
doesn't
add
a
bunch
of
cognitive
load
to
our
users
by
making
a
smart
kind
of
conventional
choice.
A
A
We
talked
about
environments,
oh
pods,
those
sorts
of
things
yeah,
so
here's
an
example
where
the
environments
show
pods
and
in
this
case
they're
all
not
super
useful.
I
know
there's
five
of
them.
I
can
hover
over
them,
but
their
names
don't
distinguish
anything
for
me.
So
it's
not
like
I
can
reference
them
easily,
maybe
having
some
other
way
to
reference
them
would
be
great.
Let's
look
at
feature
flags
yeah.
My
future
flags
have
an
id,
but
they
also
have
a
name,
and
I
get
to
supply
that
name.
A
A
So
in
this
case,
I
have
a
cluster
great
look.
It's
showing
me
super
important
information.
I
think
this
logo
tells
me
that's
in
gke.
It
has
the
name
of
the
cluster,
then
it
talks
about
environment.
Scope,
never
mentions
that
this
is
cluster
number
106958
right,
and
I
think
this
is
probably
a
shining
example
of
what
I'm
highlighting.
In
fact,
I
would
never
know
when
I
were
looking
at
this.
A
Had
I
not
looked
at
the
url,
what
the
cluster
id
is-
and
I
think
that's
probably
the
behavior
we
will
want
to
go
for,
which
is
the
the
id
of
these
individual
objects,
doesn't
matter
and
our
users
generally
don't
reference
or
think
about
them.
That
way,
what
is
useful
is
that
we
provide
information
when
they're
shown
in
context
that
is
immediately
useful.
A
It
doesn't
require
some
deciphering
and
if
we
can
obfuscate
the
num,
the
id
entirely,
even
better
so
yeah,
actually
I'm
going
to
use
this
kubernetes
clusters
is
kind
of
like
my
shining
example
of
what
lists
of
things
should
look
like.
This
only
has
one
cluster.
Let
me
see
if
I
can
find
one
that
has
multiple.
A
Yeah,
okay,
so
here's
a
couple
of
different
clusters
that
are
available
to
this
project.
The
project
itself,
like
the
this
display,
is
not
telling
me
individual
numbers.
In
fact,
some
of
them
are
like
in
wildly
I'm
looking
at
the
urls
down
here.
Some
of
them
are
in
wildly
different
projects,
but
what's
important
is
that
I'm
showing
useful
information
to
my
user
upfront
and
hiding
not
useful
information
like
the
id.
B
A
Tags
for
my
gear
yeah,
so
here's
another
example
where
latest
is
useful.
That's
I
don't
know
what
that
means,
but
these
other
ones
the
uid
or
whatever
this
hash
is,
is
not
super
useful
to
me
and
it's
not
really
something
I
would
ever
reference
so
maybe
having
something
like
the
the
date
it
was
published
over
on
this
side.
A
I
get
that
I
would
want
to
copy
this
so
that
I
could
retrieve
this
specific
one.
But
in
terms
of
my
readability,
I
would
want
when
it
was
published.
If
that's
the
best
information,
we
have
maybe
there's
some
other
information
about
published
to
some
other
digest
information,
but
maybe
that's
the
best
information
we
have
about
this
container
image-
and
I
imagine
similar
is
true
for
package
registry.
I'm
trying
to
think
if
we.
A
A
A
Yeah,
in
this
case,
it's
great
you're
showing
test
case
is
the
primary
thing
you
you
named
it.
Then
you
get
the
id.
I
think
issues
do
a
good
job
of
this
too.
Let's
just
look
yeah,
it's
the
exact
same
kind
of
behavior,
where
you're
giving
the
most
useful
information
with
the
number
being
not
super
useful,
so
that
I'm
going
to
stop
my
recording.
Let
me
just
stop
my
share.
A
A
I
would
describe
as
anti-pattern
among
in
the
op
section
where
a
lot
of
our
objects
were
not
thinking
through
and
making
it
easy
for
our
users
to
think
through
what
is
that
object
specifically
compared
to
the
other
ones
in
the
list
and
by
just
giving
the
number
we're
not
making
it
easier
for
our
users
to
understand
the
distinction
between
the
different
items
in
a
list.
So
with
that,
I
will
stop
sharing.
Thank
you
all
very
much
for
listening,
and
I
hope
this
is
helpful.