►
Description
Presented by: Claudio Wunder
Find out how how GitHub Copilot empowers developers at HubSpot, and helped it identify a critical bug in their codebase.
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
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
A
Er
I'm
very
excited
to
have
you
here.
My
name
is
Claudia
and
I'm
a
platform
engineer
at
HubSpot.
My
job
is
to
maintain
a
sustainable
tracking,
an
experimentation
platform
that
serves
the
hundreds
of
different
engineering
teams.
We
have
at
HubSpot
I'm,
always
a
collaborator
at
the
node.js
project,
I'm,
the
member
of
the
genome
Foundation.
A
We
are
mainly
contributes
during
my
free
time
today,
I'm
going
to
talk
about
the
developer
story
of
how
GitHub
co-pilot
helped
me
identify
a
critical
bug
in
our
code
base
and
how
it
can
do
the
same
for
you
and
save
you
time
headaches.
So
what
is
copilot?
You
could
say,
there's
an
extension
that
suggests
code
in
real
time
within
your
editor,
but
for
me,
GitHub
compiled
as
an
assistant
that
helps
me
day
to
day
to
provide
better
code
as
it's
powered
by
open,
Ai
and
millions
of
lines
of
code
from
open
source
repositories.
A
Now,
let's
talk
about
the
story
of
when
co-pilot
identified
a
Dorman
bug
in
our
code
base
and
what
happened
next,
but
before
we
jump
to
what
compiled
exactly
identified,
I
feel
I'm
in
need
of
giving
a
little
bit
of
context
about
the
library
it
impacted
without
further
Ado.
This
is
user
tracker.
Either.
Tracker
is
a
library
responsible
of
tracking
user
Behavior.
A
It
is
an
in-house
library
of
the
likes
of
segment
or
Century,
if
you
say,
and
that's
because
it
monitors
user
Behavior
identifies
its
interaction
and
then
respectively
processes
and
sends
the
information
of
the
network
for
Server
sort.
Hundreds
of
teams
at
HubSpot
relay
daily
honor
is
a
Tracker
to
drive
or
data-driven
platform
and
allow
our
engineering
teams,
data,
analysts
and
product
experts
to
make
high
level
decisions
that
affect
our
entire
business
as
Matt
says,
is
a
Tracker
is
a
library
responsible
of
tracking
user
Behavior.
A
It
allows
us
to
grow
better
and
provide
better
experience
to
our
teams
and
customers,
and
that
is
true,
because
teams
rely
on
easy
tracker
to
be
able
to
make
decisions
paid
by
data.
But
what
if
something
was
wrong
to
a
certain
degree,
of
course,
is
a
Tracker
operates
by
resolving
parameters
and
data
as
synchronously
allowing
the
change
that
usage
to
supply
parameters
and
data
on
as
a
needed
fashion.
This
means
that
the
data
is
resolved
when
needed
and
then
merged
with
pre-existing
static
information
like,
for
example,
your
screen
size.
A
Finally,
after
the
data
being
resolved
validated
and
processed,
it
gets
queued
and
then
is
patched
over
the
network
after
certain
circumstances
are
met,
Iron
Works
fabulously,
but
if
everything
was
Evergreen,
I
wouldn't
be
here.
Conducting
this
talk
so
I'm
here
to
talk
about
a
bug
called
pilot
found
a
very
important
one,
but
very
well
hidden.
A
A
Well,
we
are
tracking,
for
example,
if
an
user
clicks
a
button
which
user
clicked
a
button
on
which
page
and
that's
very
important,
because
without
knowing
what
are
the
actors
of
our
systems,
we
cannot
reliably
create
cards
of
data
streams
and
determine
specific
outcomes
and
decisions
that
should
be
done
based
on
what
we
are
tracking
like.
How
can
we
know
if
a
certain
feature
introduced
only
for
starter
Tire
users
is
actually
being
adopted?
A
If
you
don't
know
which
kind
of
users
are
actually
using
in
the
future?
Yes,
but
then
what
went
wrong
well
on
a
regular
day
as
any
other
I
was
working
on
update
of
a
function
that
is
responsible
for
well
resolving
that
set
at
synchronous
data
and
ensuring
that
unhandled
rejections
get
filtered
out,
meaning
the
data
phase
resolve
should
be
removed
from
the
final
processing
pipeline,
for
example,
if
the
system
fail
to
resolve
the
current
user
email
address,
it
would
flag
that
the
email
address
was
not
resolved
without
breaking
the
execution
thread.
A
But
if
the
system
was
unable
to
identify
the
user
by
any
of
the
available
methods,
then
it
should
prevent
tracking
from
being
done
on,
because
we
cannot
identify
the
user
and
here's
where
copilot
gets
introduced
to
the
story.
When
was
writing
a
new?
If
statement
with
element
function,
copile
made
a
strange
code
suggestion.
Well
the
suggestion
being
to
add
a
case
to
alerted
the
data
that
fate
resolve.
A
Well
fate
resolve,
but
doesn't
it
doesn't
really
make
sense
least
where
it
added
that
suggestion
and
that's
because
our
logic
slices
the
data
that
fail
to
resolve
out
of
the
equation
completely
or
so
imagined,
diving
deeper
after
the
data
gets
resolved,
we
actually
merge
the
non-resolved
data.
What
we
call
static
parameters,
what
to
resolve
data
and
where
the
data
that
fatally
resolve
is
sliced
out
by
marking
it
as
a
non-defined
or
AKA
undefined,
but
looking
closely
the
function
that
we
use
to
merge
data
by
default
overrides
the
same
entries
of
data
from
the
resolved
data.
A
If
the
values
of
the
resolved
data
is
undefined,
meaning
our
system
would
falsely
think
that
we
succeeded
in
identifying
the
user
when
actually
we
did
not
and
that's
because
the
system
failed
to
detect
all
of
the
identifying
matters
failed.
Keep
in
mind
that
this
is
an
edge
case,
because
in
a
reality
we
usually
are
able
to
identify
the
user
successfully
with
at
least
one
more
identifying
methods.
A
Those
are
many
does
very
effectively
hide
in
the
existence
of
this
bug
because
we're
doing
the
Sea
of
data,
it
would
only
affect
the
small
scenarios
or,
for
example,
a
network
request,
favorite
or
testing
environments,
but
even
just
being
an
ad
scenario.
It
also
means
that
if,
in
any
given
moment,
we
change
how
any
of
those
asynchronous
identify
matters
work,
it
will
transform.
The
small
ad
scenario
into
massive
spread
Azure
system
would
just
keep
thinking
that
it
was
able
to
successfully
identify
the
user
when
it
was
not.
A
So
this
is
why
it
lives
on
this
circumstance.
Co-Pilot
was
essential
not
because
if
any
incident
happened,
we
wouldn't
be
able
to
identify
the
bug,
but
because
it
simply
gave
a
suggestion
based
on
how
you
read
or
exist
in
code
base,
it
won't
effectively
prevent
such
incident
from
happening.
Remember,
co-pilot
makes
suggestions
based
on
the
existing
code
base,
you're
working
with
and
improved
that
in
our
case,
that
can
be
a
very
helpful
paper.
A
So
what's
next
well,
because
of
that,
we
created
better
processes
to
ensure
that
this
kind
of
AD
situations
wouldn't
happen
anymore,
like
documenting
those
sort
of
lines
of
code.
So
we
understand
why
this
was
done
before
an
ounce
of
effectively
creating
more
tests
for
specific
ad
scenarios
and
add
more
monitoring
tools.
It
can
preemptively
notice,
Jurassic
data
change
sets
from
normal
patterns,
also
I'm
still
advocating
for
copilot
and
hoping
to
do
one
day
without
it.
Org
wide
who
knows
stars
like
these
are
what
Drive
change.