Coding with an AI pair programmer: Getting started with GitHub Copilot

Summary

クリス托ファー・ハリソン氏は、GitHub Copilotの使い方を紹介し、開発者向けにコード補完ツールの活用方法を解説します。CopilotはOpenAIを活用し、コードとコメントをもとに提案を生成しますが、正確な動作にはプロンプトの工夫が必要です。ファイル全体や開いているタブをコンテキストとして使用し、意図や具体性を明確にすることで、より良い提案を得られます。デモを交えながら、モデルやビューの作成方法を学ぶことができます。

Takeaways

• 🔧 GitHub Copilotはツールであることを忘れがちだが、コード補完を始めとした一連のツールとして機能します。
• 🛠️ GitHub Copilotはコードやコメントをもとに提案を生成し、開発者がIDEでそれらを受け入れるか拒否するか選択できます。
• 🌐 コンテキストの理解が重要で、現在作業しているファイル全体や開いているタブがGitHub Copilotに送信されます。
• 📚 タブの順序によってGitHub Copilotは関連性の高いファイルに焦点を当て、最も関係のあるものを優先的に解析します。
• 💡 プロンプトの工夫（prompt crafting）は、GitHub Copilotが最も効果を発揮するようにコードやコメントを記述する技術です。
• 📝 コードのコメントや変数名は簡潔明瞭で、専門用語や省略形は避けるべきです。
• 📉 具体性は重要で、具体的な要件を満たすためには、詳細なプロンプトを提供することが有効です。
• 🔄 GitHub Copilotは確率的であるため、同じ状況でも異なる提案が返される可能性があることを理解し、柔軟に対応する必要があります。
• 📖 良いコードは良いコードを生み出し、変数名やコードの命名規則に注意することでGitHub Copilotがより良い提案を生成するようになります。
• 📝 コメントはコード生成のアーティファクトとして残しておくことが役立つため、削除するべきではないと考えられています。
• 🌟 最も重要なのは、GitHub Copilotと一緒の流れに沿って柔軟に対応することで、最大限に活用することができる点です。

Q & A

GitHub Copilotはどのようなツールですか？

GitHub Copilotはコード補完を含むツールのセットで、エディター内でコメントやコードを追加する際に、その文脈に基づいて提案を生成するツールです。

GitHub Copilotがどのように動作するのか教えてください。

GitHub Copilotは、入力されたコードやコメントを受け取り、OpenAIの技術を利用してその文脈を理解し、提案を生成してIDEに戻します。

GitHub Copilotが送信するコンテキストには何が含まれますか？

現在作業しているファイル全体や、IDE内で開かれているタブの情報が含まれます。特に、現在作業しているタブに近いタブの情報に重きが置かれます。

プロンプトクラフトとは何を意味していますか？

プロンプトクラフトは、コメントやコードをどのように入力するか、どのようなフレーズを用いてGitHub Copilotから最大限の利益を得る方法を意味します。

なぜコメントをコードの先頭に記述することが重要なのですか？

コメントをコードの先頭に記述することで、GitHub Copilotはコードの目的や意図を理解しやすくなり、より適切なコード提案を生成することができます。

なぜGitHub Copilotは確率的な動作をするのでしょうか？

GitHub Copilotは機械学習に基づくため、同じ状況で同じ入力をしても異なる提案が返されることがあります。これは確率的な動作と呼ばれています。

GitHub Copilotが提案を改善するために使用する例を提供することの重要性は？

例を提供することで、GitHub Copilotは開発者が何を目指しているのかをより明確に理解し、より正確なコード提案を生成することができます。

なぜ変数名やコードの命名規則が重要なのですか？

適切な変数名やコードの命名規則を用いることで、コードが明確になり、GitHub Copilotもそのコンテキストを理解しやすくなります。

GitHub Copilotが生成したコードをどのように微調整するべきですか？

必要に応じて、GitHub Copilotが生成したコードを手動で調整し、特定の要件に合わせて修正することで、より適切な結果を得ることができます。

GitHub Copilotの使用でコメントを残すべきか、それとも削除すべきですか？

コメントはコード生成の過程を記録しており、後のコードの微調整や理解に役立つため、残した方がよいとされています。

どのようにGitHub Copilotと協調してコードをより良くすることができるか？

正確なプロンプトを提供し、良いコードの命名規則に従い、GitHub Copilotが生成するコードに対して柔軟かつ具体的なフィードバックを提供することで、より良いコードを構築できます。

Outlines

00:00

😀 GitHub Copilotの紹介と使い方

クリス托ファー・ハリソン氏はGitHubのシニアデベロッパーアドボケイトとして、GitHub Copilotの紹介を行います。Copilotは開発者向けのツールで、コード補完を提供します。コードやコメントを入力すると、そのコンテキストに基づいて提案が生成されます。CopilotはOpenAIの技術を利用しており、開発者がIDEで作業している間にリアルタイムのサポートを提供します。また、ファイル全体や開いているタブの情報からコンテキストを取得し、最も関連性の高いものを優先的に扱うことが強調されています。

05:04

🔍 コンテキストとプロンプトの重要性

プロンプトの工夫（prompt crafting）について説明し、GitHub Copilotを最大限に活用する方法を提案します。コンテキスト、意図、明確性、そして具体性という4つの要素が重要です。コメントやコードを記述する際には、これらの要素を念頭に置いて明確で具体的に情報を提供することで、より良い提案を得ることができます。また、開発者が自然な作業パターンでファイルを開くことで、Copilotは関連性の高いファイルに焦点を当てることができます。

10:04

🛠️ GitHub Copilotの活用テクニック

GitHub Copilotを活用するための具体的なテクニックについて説明します。コードの例を提供することで、Copilotが求めているものを見つけやすくなります。また、モデルの構築やビューの作成など、実際のコーディングデモを通じて、Copilotがどのように開発者の意図に従ってコードを生成するかを示します。コメントを通じて意図を明確にし、Copilotがより適切なコードを提案できるようにすることがポイントです。

15:06

🔧 命名とコードの質の重要性

良いコードの命名とコードの質がGitHub Copilotの提案に与える影響について説明します。Copilotはコードの命名規則やベストプラクティスに従うことで、より適切な提案を行います。開発者は一貫性のある命名規則を用いることで、Copilotがより理解しやすくなり、効率的なコード生成が促進されます。また、開発者が行う変更に基づいてCopilotが学習し、より良いコードの生成を続けることが強調されています。

20:08

📝 コメントの役割とコード生成

コメントを通じてGitHub Copilotに意図を伝え、コード生成を促進する方法について詳述します。コメントはコード生成の過程で非常に重要で、Copilotはコメントを読み取り、それに応じたコードを提案します。また、開発者が行う変更に対してCopilotは柔軟であり、必要に応じてコメントを調整することで、より適切なコード生成が可能になります。

25:12

🌟 GitHub Copilotの学習能力と柔軟性

GitHub Copilotの学習能力と柔軟性を強調し、開発者がCopilotと協調して最良の結果を得る方法についてまとめます。Copilotは開発者の行動に基づいて学習し、それに応じてコードの生成を調整します。また、開発者はCopilotが提供するコードに対して柔軟に対応し、必要に応じて調整することで、より良い結果を得ることができます。最後に、コメントを残しておくことで、コード生成の過程を記録し、後で参照することが可能になる点も紹介されています。

Keywords

💡GitHub Copilot

GitHub Copilotは、コード補完を支援するツールです。開発者がコメントやコードを入力する際に、その文脈に基づいて提案を生成し、開発者の生産性を高めることを目的としています。このツールは、開発環境に統合されており、開発者がIDEで作業している間も動作します。ビデオでは、このツールの使い方や、その動作原理について説明しています。

💡コード補完

コード補完とは、開発者がコードを書く際に、開発環境が自動的にコードの続きを提案する機能です。GitHub Copilotでは、開発者が入力するコードやコメントに基づいて、その場で最も適切なコードを推測して提案します。ビデオでは、コード補完がどのようにして開発者の作業効率を高めるかが説明されています。

💡コンテキスト

コンテキストとは、GitHub Copilotがコードを提案する際に使用する情報のことです。これは、開発者が現在作業しているファイル全体や、開いているタブの内容などから得られます。ビデオでは、コンテキストが正確なコード提案にどのように重要であるかが強調されています。

💡プロンプトクラフト

プロンプトクラフトは、開発者がGitHub Copilotに対して、より正確なコード提案を得るためにコメントやコードをどのように記述するかの技術です。ビデオでは、プロンプトを明確にすることで、ツールがより適切な提案を生成するように導く方法が紹介されています。

💡インテント

インテントとは、開発者がGitHub Copilotに対して伝えたい具体的な意図や目的のことです。ビデオでは、インテントを明確にすることで、ツールがより適切なコードを提案するように促す方法が説明されています。

💡クラリティ

クラリティとは、コメントやコードでの意図の表現の明確さを指します。ビデオでは、開発者がコードを記述する際に、簡潔で明確な言葉を使うことの重要性が強調されています。これは、GitHub Copilotが正確な提案を生成するのを助けるためです。

💡具体性

具体性とは、開発者がGitHub Copilotに対して求めるコードの詳細を具体的に伝えることを指します。ビデオでは、具体性を高めることで、ツールがより正確なコードを提案することができると示されています。

💡Django

DjangoはPythonで書かれた、高レベルのWebフレームワークです。ビデオでは、Djangoを使用してウェブアプリケーションを作成する際に、GitHub Copilotがどのように役立つかが説明されています。また、Djangoのモデルやビューを作成する例が示されています。

💡柔軟性

柔軟性とは、開発者がGitHub Copilotの提案に対して適応し、必要に応じてコメントやコードを再構成する能力を指します。ビデオでは、ツールの提案は確率的であり、同じ状況でも異なる結果が返されることがあるため、開発者は柔軟に対応する必要があると説明されています。

💡良いコード

良いコードとは、読みやすく、メンテナンスしやすいコードを指します。ビデオでは、良いコードの書き方、例えば適切な変数名の使用や、一般的なコーディング規約への従順が、GitHub Copilotがより良い提案を生成するのを助ける方法として紹介されています。

Highlights

Christopher HarrisonはGitHubのシニアデベロッパーアドボケイトであり、GitHub Copilotの活用方法について話します。

ツールは時に魔法のように感じるが、最終的にはIDEと同じくツールであることを忘れずに、最大限に活用する方法を見極めましょう。

GitHub Copilotはコード補完を中心としたツールで、コメントやコードを入力すると提案を生成します。

GitHub CopilotはコードやコメントのコンテキストをOpenAIモデルに送信し、提案を生成して返送します。

コンテキストは現在作業しているファイル全体や、IDE内の開いているタブに基づいて送信されます。

タブの順序によってGitHub Copilotは最も関連性の高いファイルに焦点を当て、提案を生成します。

プロンプトクラフトは、コメントやコードの入力方法を学ぶことでGitHub Copilotを最大限に活用できる技術です。

コンテキスト、意図、明確性、特定性を含んだプロンプトを用いることで、GitHub Copilotはより正確な提案を生成します。

開発者が最初にGitHub Copilotを試した際の大きな失敗は、十分なプロンプトを提供しないことで、期待する大きな結果を得られなかったことです。

ファイルの先頭に目標を記述することで、GitHub Copilotが現在の作業内容を理解しやすくなります。

ツールは確率的であるため、同じ状況で異なる提案が返されることがあることを理解し、フレキシブルに対応しましょう。

具体例を提供することで、GitHub Copilotが求めている結果をより明確に伝えることができます。

Djangoフレームワークを使用してウェブサイトのモデルを作成するデモンストレーションを行いました。

適切な変数名を使用することで、GitHub Copilotがより良い提案を生成するのに役立ちます。

GitHub Copilotは見たコードに基づいて学習し、ユーザーが従うべき命名規則やベストプラクティスに従うようになります。

関連するファイルを開くことで、GitHub Copilotはより適切な提案を生成することができます。

GitHub Copilotはユーザーの行動に従い、コードの生成を支援することで学習を進めます。

最終的に、GitHub Copilotを最大限に活用するためには、流れに従い柔軟に対応することが重要です。

Transcripts

Good morning.

Good afternoon. Good evening.

Depending on where in the world you happen to be, my name is Christopher Harrison.

I'm a senior developer advocate at GitHub and I'm really excited to talk today

about GitHub Copilot and about how to get the most out of this tool.

That one thing that we will sometimes forget when we're looking at

these tools is the fact that they are tools.

They can often feel like magic.

I type out a few words and while I've got this really, really cool thing,

but at the end of the day, it's a tool just like our IDE,

and we should spend a little bit of time seeing how we can get the most out of it.

So I want to start off by talking a little bit

about GitHub Copilot and how it works behind the scenes,

and then we'll get into some tips and tricks

that you can start to implement as you get in and explore the tool.

So what is GitHub

Copilot ? So GitHub.

Copilot is a suite of tools.

I'm going to be primarily focused in on code completion.

So this is the embedded experience inside

of your idea, inside of your editor, where as you add in comment,

as you add in code, it's then going to generate suggestions, generate

what it thinks that you are looking for based on that information.

So how does it do its thing behind the scenes?

Well, as you're typing out your code, as you're typing out your comments,

context is sent up to GitHub.

Copilot I'm going to talk about that context in just a moment,

but from right now, let's focus in on that processing

so that context is sent up to GitHub Copilot.

GitHub Copilot then uses the OpenAI allow them

behind the scenes, sees what it is that you're trying to do and then in turn

generate suggestions and send those sends those down to your I.D.E.

You can then accept those, reject those, accept and modify,

use that as the foundation.

And it really does help keep you in the zone and help

you avoid having to go off and maybe look up obscure syntax and things like that.

Now, let's talk a bit about that context, because a lot of times

there's some confusion about this, exactly what is going to be sent up to GitHub

Copilot? Well, the first and kind of the most obvious is the file that you are

currently working on, and that's going to include the entirety of the file.

So it's not just from where my cursor is and everything above it,

but rather it's the start of the file, the bottom of the file,

the middle of the file.

So if I'm going in and I'm making updates, I'm adding new code,

I'm making changes.

It's going to look at the entirety of the file, not just from the cursor

and above.

The next big thing is the tabs

that are open inside of your idea.

This sometimes cause and causes confusion and I'll admit for me personally,

it also caused a little bit of confusion because I honestly did think

that it summed up the entirety of my project.

And if we stop and think about that, that would be an awful lot of context

for Copilot to try and figure out,

try to parse out, try to figure out what's most important.

Because like, if I think about, you know, reading

a very long article, I want to focus in on what's most important.

And if there's like, you know, 5000 words

and this is really the only section that I'm interested in

for this moment, the rest of that becomes a little bit superfluous.

So we want to focus GitHub Copilot's attention on what's most important,

and that's where those tabs come into play.

It's going to focus in on what's most important based on those tabs.

Additional.

It's also going to start from the outside our inside and work its way out.

So the tabs it will start with are the ones that are closest

to the tab that I am currently working on. Now,

one thing that sometimes people will do

is they'll get a little bit too focused on trying to control the tabs,

on trying to control the context that's going to be sent up.

And honestly, if we think about the way that we typically write code,

that if you're anything like me and I know I am, that

I will open up a file, I'll make some modifications.

I'm going to open up a related file,

I'm going to make some modifications, I'm going to open up another related file.

And this is normally the way that we wind up doing our work.

So by having GitHub Copilot focus in on those tabs,

it's typically naturally automatically going to get the files

that are already most related to what it is that I'm doing now.

If I'm shifting tasks, if I'm maybe going to be taking a look

at something that's a new feature that I'll be implementing

or if I know that I'm going to be working with a library or framework

that Copilot has never seen before, then I might go ahead and

very specifically open up a file, open up some representative example

of what it is that I'm building, or maybe I'm switching tasks,

or maybe I am not getting the suggestions that I'm looking for back

from GitHub Copilot.

Then at that point I might take another look at the files

that I have open and maybe readjust at that point.

But again, I really do want to highlight the fact that you will find

most of the time just through your normal usage patterns

of an idea of your editor, that you'll just inherently be opening up

the files that are most closely related to what it is that you are working on.

Now let's get in and start to

kind of build upon that and see how we can get the most out of this tool.

And I'm going to potentially introduce a term that's that's new

you a thing called prompt crafting.

And in a nutshell, this is really about how it is

that we are going to phrase and type out our comment phrase

and type out our code phrase and type out our prompts

to get the most out of these tools that, as I highlighted at the start,

I is a tool and I really do want to make sure

that I've spent a little bit of time learning how to get the most out of it.

Just like with my idea this is what prompt crafting is all about.

Now, if we break this down into a couple of components

about how it is that we can help GitHub Copilot help us.

The first is going to be the context.

This is that surrounding information.

What is it that we're trying to build?

How is it that we are trying to build it

to start to then drill a little bit further down?

The next is the intent.

What is it that I'm doing?

How is it that I'm trying to do?

Why is it that I am trying to build that out?

Next is the clarity.

As a friend of mine likes to joke,

don't use a big word when a diminutive one would use that.

As I'm typing in my comment, as I'm trying to describe what it is

that I'm doing, I want to make sure that I'm clear

so I might start to avoid a lot of vernacular.

I might try to avoid maybe abbreviations that make sense to me internally,

but might not be as clear, might not

define truly what it is that I am trying to build.

Last but not least, is specificity.

This is where I'm going to get in

and identify exactly what it is that I want.

Let's take, for example, the phrase Go get me some ice cream.

Now I've provided enough information to complete that task.

You know that you should go off and go grab some ice cream.

That's wonderful.

But what flavor of ice cream?

What vessel should there be?

Sprinkles. Don't know.

So have I given enough information to complete the task?

Yeah.

Am I going to be satisfied with the result?

Maybe not, because I'm going to be looking for salted caramel in a waffle cone.

And the answer is always sprinkles.

Yes, always sprinkles.

So what I really wanted to do, if I was going to craft that out, say

using Prime crafting, is make sure that I'm providing all of that

specificity, all of that information upfront.

And this is one of the big mistakes that I see developers make

when they first get in and start playing around with copilot

that they assume, I can just type out a couple of words, I can type out

a couple of sentences, and voila, I'm going to get this very big thing.

That's not really how it works that we want to make sure

that we're providing good, clear prompts.

I think the best way to do this is really start to put it into action.

So before I get into this demo, I promise you there's going to be a demo

here in just a moment.

Let's take a look at a couple of real quick best practices.

First up is describe the goal.

I like to view this as adding a header, if you will, to the file.

This doesn't have to be anything real in-depth per se, just three or four

quick sentences describing what it is that I'm looking to build.

If the framework isn't implied

based on the file that I'm working on, maybe I'll add that in.

You know, kind of what's the goal?

How is it that I'm trying to do this?

Just a couple, three lines up at the very top, add those in.

Next is be flexible.

We always need to remember that our tools are

probabilistic, not deterministic.

And so what this means is that I could be in the exact same scenario.

So I can type out a comment, I could type out a phrase and get one suggestion.

And then in that exact same scenario, the next day, I might get back

something different.

The tools are probabilistic.

This is simply how these work.

And that's all right.

So I just need to be a little bit flexible.

If I don't see what it is that I'm looking for the first time,

maybe rephrase, reframe what it is that I am doing.

And one big thing that you can do to really help out is to provide examples.

So let's say that I'm going to be processing data.

Let's say that I'm going to be doing some validation if I give a set of examples,

then I'm going to be very clearly defining to GitHub Copilot

what it is that I'm looking for.

So let's take a look here.

I've got an application that I'm going to be building out

using Python, Django, Python, Django, one of my favorite frameworks.

It's there to create frontend for backend databases.

And the first thing that I need to do

is to build out my models to describe my data here.

So I'm going to start

towards the top of my file here and describe what I'm doing.

I'm building out a conference website, so build out a conference website

and I'm going to have add a speaker,

a track and a talk

and make sure that parrot

can't be deleted if there are children.

So in other words, what I'm trying to specify here is

if I have a primary foreign key relationship

and I try to delete that primary, but there are foreign keys,

don't allow those to be deleted.

So just a couple of three sentences that describe what it is that I'm doing.

Add some constraints and now I'm ready to start adding in my code

and you'll actually notice that great italicized text there.

That's GitHub Copilot and action.

It's making those suggestions.

I actually haven't done anything yet and it's already

starting to make code suggestions.

I'm going to accept what this is going to give me by hitting tab,

but I'm going to be a little bit more specific.

So I want a speaker.

Speaker should have name,

email and LinkedIn like that.

And let me just give it one quick extra return here.

And let's see, I'm speaker.

What's let's do this.

Let me be more specific here.

I'm learning from my self here.

Create a speaker model

with name, email and LinkedIn.

There we go

in this moment. Perfect.

So what you notice there is previously was saying, should I

now I'm being a little bit more specific about what it is that I want.

I'm being flexible, rolling with it.

I go back, I tell it create and now it's doing its thing.

And so now if I had Tab, now

it's got all of that information that I specified.

So it's got my name, it's got my email and it's got that linked in URL.

You might also notice it's including a little thing that I didn't ask for.

It's including that override of the SDR function.

This is something that's very common in Django and it just automatically added

that in I could, you know, remove that if I want to, but I actually like that.

That's a very common convention inside of Django.

So with that speaker created

the next thing that I want to do is let's create a track.

So let's say create track

with name and description.

Sure. And maybe an abbreviation

like that.

There we go.

Give that a moment and that will go ahead and set that up for me.

Again, it's reading that comment and then adding the rest down below.

Now, as I've highlighted, be specific.

You'll notice that I said abbreviation.

And so it said, All right, fine, I'll give you an abbreviation.

Abbreviation is probably three characters.

And that's what I'm seeing right here.

Is it set up that abbreviation with that max length of three characters.

But chances are, if I'm going to be looking for

an abbreviation, I want something that's a little bit more specific.

So I want this abbreviation to be specifically

three letters and maybe three uppercase letters.

So let's go back and just make that modification.

I'm just going to get rid of that and I'm just going to say abbreviation

should be three uppercase letters just like that.

And now it will go ahead and build that out

with that regular expression. Now,

I don't know about you, but at least for me,

I can read regular expressions and something like this

I could certainly have typed out off the top of my head,

although if I'm being perfectly honest, I do sometimes forget which is which.

If it's the carried character,

the dollar sign to pin to the beginning, pin to the end.

So it's nice not to have to always go look those types of things up.

So I was able to just describe this is what I want.

It generated that regular expression.

So I was flexible there, I was specific and it gave me back that that value there.

Pretty cool.

Last but not least, let's

go ahead and create that torque.

It's already adding in that comment.

I'm going to go ahead and hit tab to accept this.

Let me read a title description Speaker Track and date.

Perfect. Let's go ahead and accept that

and give it 2 seconds here.

Perfect.

And now we'll go ahead and put all of that in.

So now it's got my title, it's got my description,

it's got my speaker, it's got my track, it's got my date,

and then a little bit of extra stuff down at the very bottom here.

And I'm going to kind of leave that the way that it is for the moment.

But the big thing that I want to point out is that unfortunately,

it didn't quite pick up what it was that I was looking for, that if we remember

from the very beginning here, let me scroll all the way back up.

I specified in my little header

that I wanted to make sure

that a parent can't be deleted if there are children.

Unfortunately, this didn't pick up on that.

Maybe I just wasn't clear enough.

Maybe I needed to use the specific vocabulary.

Who knows?

But that's all right.

I could go back and I can modify it. Now.

Before I do that, though, I actually want to get in to the next set of tips here.

And the first is to name things properly.

I'm going to bounce back and forth a little bit

between the slide in this code here to kind of make some points.

And the first is right here on Linked In,

what you're going to notice is that when I added in that comment

of create speaker model with name, email

and LinkedIn that it automatically set up that LinkedIn

as a new URL field, which is probably exactly what I wanted.

How did it do that?

Well, it did that because it's actually reading my variable name here.

So it sees LinkedIn.

It goes, okay, you probably want a URL and it will automatically put that in there.

Which also then means that if I'm looking for good suggestions from GitHub Copilot

that I want to make sure that my variable names are also good.

One of my pet peeves encoding

is abbreviations is single letter variable names.

Because when I go back and I take a look at that code,

it's not always clear to me what that code is supposed to be doing.

And when it comes to abbreviations, sure, maybe we've got documented somewhere

what abbreviations mean and so forth, but that's now institutional knowledge.

That's something that my developers would need to learn.

And the exact same thing would then wind up holding true with GitHub Copilot

is it's not going to have that same experience as my developers.

It's not always going to be able to pick up what those abbreviations mean.

So if I've got good code, if I'm spelling these things out,

I'm not only making it clear to my other developers, but

I'm also making it clear to get a Copilot, which going back to that analogy of

it being in a pair programmer, I kind of want to treat it as such.

I want to make sure that I'm being clear to it.

So because of the fact that I use LinkedIn here,

it was able to go, okay, I know what you're doing.

And it added in that that you are our field.

Now keeping along with that, using good code.

Let's come back down here

to where that little problem is that I highlighted a moment ago.

Right now the speaker and track are both set to cascade.

If you're not already familiar with Django, what that means

is that if I had a speaker and they had talks, I delete that speaker.

All of those talks are now going to go away.

That was not what I was looking for.

So fortunately I can change this, may actually

just get rid of that full track line right there.

And let me do sound effects help, by the way.

There we go. Perfect.

Let me go ahead and say protect.

So by saying protect what that now means

is it's going to prevent a talk

from or a speaker from being deleted if they have talks.

That was the behavior that I was looking for.

Now that I've done that, let me have return here.

And what you're going to notice

is that with track, it's going to follow that pattern.

So it's going to learn by watching me.

So it's picking up that context.

Following along, one of the most common questions that I get asked

is, Hey, we have certain conventions, that we have certain conventions

for naming our variables or whatever it is that it might be.

How do I make sure that GitHub Copilot will follow with this?

The simplest way that you can do that is show it some code

that's written, the way that you're looking for it to be written,

and it will then follow along with you,

kind of reads perfectly in to following best practices.

GitHub Copilot is going to what you're doing

and it will follow right along with that.

Last but not least is like I highlighted up at the the towards

the middle I guess is to make sure that you are opening up relevant files.

So if I'm adding in code, not quite getting what I'm looking for,

make sure that I've got my relevant files open.

All right.

Let's some keep building here and I want to create some views

to display the data that I've now got for my website.

So I need to import it a little, little bit of code here.

So GitHub Copilot sees that I'm doing Django automatically.

Pull that in.

Let me just go ahead and hit tab hit a couple of carriage returns

and now notice this next line here.

The next line that it automatically is adding in

is it's importing in my talk, my track, my speaker.

It's doing that because it's now

seeing my model's tab open.

It knows what's inside of there and we'll automatically import those in.

Let me go ahead and now start creating

views for my let's aim for my talk.

So let's go ahead and say create a list view

for my talks to become

and it will go ahead and set that up for me.

Now, what this is doing in Python, Django,

is this is specifying that the model that we're going to be working with

is talk that when I actually go to display the data, it's

going to have an object name of talks in the HTML

template that it's going to use is going to be that talk list.

Now, this is probably one of my favorite

little things about Django is because this is a framework

that is built to very quickly allow me to front ends for databases.

It includes a lot of pre baked code

for me that I don't have to go in and create.

But as with most frameworks, I would say

it's not always going to be the most performant right out of the box

that by default what this is going to do is it's going to do a thing

called lazy loading, meaning that when it goes to display

every single talk, it's going to have to go back and go get the speaker.

It's going to have to go back and get the track to display that out.

Obviously, I don't want all of those roundtrips to my database.

That's all right.

I can avoid that.

That what I can do is I can add in a comment

describing what I want so I can say, Hey,

select the name and ID for the track.

Oops,

I have a great memory.

It's just really short.

When I said tracked, I say name. I did.

Let me go.

Never do it yourself.

And the name and ID for speaker.

And now when I add that in

let's say pre-select.

There

we go.

Boop.

There we go.

And so now it's going to go ahead and it's going to do the select

related for my track and for my speaker.

And unfortunately pick up on that name or on that ID that is not a problem.

I can just go back and again, kind of just roll with it here, be flexible.

So I'm going to say trac,

underscore, underscore ID, and now

I'll say track name and this should pick up here.

Let me just get rid of that reproof.

There we go.

And now it's picked up on that ID

and it's picked up on that name for me.

So again, be flexible with it, kind of roll with it and it will

then help you out.

Now, that's for all of my talks.

Let me go ahead and create one for a detail for my talks.

Copilot knows where I'm going, so I'll go ahead and hit tab.

Except that

there we go and accept that.

And just like we saw before, because of the fact that I did

that pre-select previously and automatically adds that in.

So it's following along based on what it is that I am doing here.

And that's going to be one of the big takeaways again,

that I want to make sure that I highlight it will follow along with you.

Okay.

One last little thing to highlight here

is let's go back over here to

my talk and let's add in one last little thing.

So up until now, what I've been focused in on

is trying to kind of get the most out of GitHub

Copilot to build out my model, to build out my view.

And now I want to see how I could, you know, take this little talk here.

Maybe to one last little level add

in a dynamic field for my code.

So every talk should have a code.

That should be the in my case, my track,

maybe a level and then the ID for the talk.

And I'm going to build that out here.

So let me first up add in a level, add a level field

with value range

from 1 to 3,

just like that.

And so it's got my men and my max of 1 to 3.

That's perfect.

And now let's go ahead and create a

computed field called code.

Code should have

the track a dash,

the level and two digits from the ID.

Now, if you remember previously, one of the things that we talked about

is give it an example so it might be able to pick this up from.

But I don't know about you, but at least for me, I always like to see examples.

Examples are a great way to kind of describe and also to document.

So I put it in one more comment and it automatically kind of picked this up.

So it automatically added an example of in this case P by t-101

That's I'll accept that and then go ahead and hit return.

It's going to add in with my property hit return

and then now it will build out that property for me.

So now it's got that abbreviation,

it's got that level and it's got this idea of zero two.

Now in this case it already did that by utilizing F string.

Again, going back to specificity, if I want to make sure

that it does it a particular way, just ask it to do it that way.

So if it didn't give me that level of specificity, sorry,

if it didn't give me that F string,

then I can go back and be a little bit more specific.

So I kind of want to go back here

and flow back through all of this one last time.

Number one, describe the goal at the top of the file.

Add in a little quick comment.

Couple lines, three lines, four lines.

What you're doing, how it is that you're going to do it, Any relevant

information that you think that GitHub Copilot might need?

Number two, be flexible.

We saw this as we went through our demos here.

That GitHub Copilot is probabilistic that it's not always going

to give you back the exact same values in the exact same situation.

Things will sometimes change and we want to be flexible with that.

Number three is provide examples and this can be really helpful to GitHub

Copilot to be able to understand what it is that I'm trying to accomplish.

As a side note, one question that I very frequently get asked

is about those comments. Should we remove them?

Should we add them?

My personal opinion is leave them behind.

And the reason for that is because they are artifacts.

It was how my code was generated and I want to be able to see this.

And if we're later going to go back and do any fine tuning on that model,

having that text describing

what it was that was built is going to be really helpful.

Always remember, and this is kind of a universal truth,

I think that good code begets good code,

name things properly follow best practices.

When you do that GitHub, Wolf or GitHub Copilot will follow along with that.

And then finally, the most important part, probably the theme of this entire

presentation is above all else, go with the flow.

With that, I want to thank you for your time.