シャドーイング練習: The easy way to keep your repos tidy. - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

78 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

Hello and welcome.

I'm James Murphy and today we're talking about PreCommit, which is a really cool tool that you can use to keep your codebase tidy

and catch some simple mistakes before things ever get committed into Git.

It happens.

There's a new person on your team that doesn't really know about PEP8, or you just forget to run your code formatter, or you just make a typo in a config file somewhere.

But at the time, you don't really notice, so you just go ahead and git commit.

Then either something breaks, or just the quality of your codebase has gone down just a little bit.

Well, a bad config you can fix, and code you can just reformat.

But still, wouldn't it be better if you could just catch those errors before the commit happens?

That's what pre-commit is for.

Here's the story of pre-commit.

Basically, git has a notion of what are called commit hooks.

These are things that happen either before you commit or just after you commit or when you push or when you pull, things like that.

Git will store this and a whole bunch of other information in the .git folder inside a directory.

Depending on your editor, this folder might be hidden, so just look out for that.

You might have to unhide it.

This hooks folder is where git stores all these different hooks.

The ones you see here are just samples.

If you were to get rid of that .sample on the end of the file name, then git would actually run that action at that corresponding So if I have a file named pre-commit,

then Git will run that script right before a commit happens.

But you don't need to go out and waste your time writing something like this yourself.

A lot of really good scripts have already been written.

The pre-commit project just makes it really easy to pick

and choose things that you want to check for your own code base.

Let's start simple.

All I want to do is make sure that before I commit anything, I run my code formatter on it.

Of course, I can just run the code formatter before I commit, but the point is I shouldn't have to remember to do that.

Why not just make it automatic?

Well, it's super simple to set up.

Open up your terminal and just pip install pre-commit.

Then, at the root of your project, just make a new file called .precommitconfig.yaml.

Then, it's just this easy to add automatic code formatting on every commit.

You specify precommit hooks by just giving a git repository.

In this case, I'm using GitHub, but you can actually use any git repository, even a local one.

You specify the git tag that it's going to use, and then some information about what command to run and what arguments to give it.

In this case, I'll be using black to do the actual code formatting.

Then you use pre-commit to install the githooks into your githooks folder.

Now if we go and look in our githooks folder, we see that we have this new pre-commit file.

Alright, now let's add our files to git, commit, and see what happens.

As you can see, it ran black and the commit failed because some modifications were made, and it's not going to commit anything automatically.

I can go and manually inspect the hello file and see that everything looks good, or just compare the diff like I normally would before a commit.

Note that these modifications to the hello file were made after the file was staged.

That means I need to git add this file again, or if something went wrong and I don't like the changes that were automatically made,

then I can git restore the file to go back to the way it was before.

In this case, I'm happy with the changes, so I will add and then try to commit again.

This time, since everything passed, the commit went through.

Note that some graphical editors like this one, PyCharm, have built-in Git support and they will automatically add tracked files when you try to commit.

So if that's the case then it might look more like this.

Here I have a spurious space in there and I'm going to go ahead and try and commit.

Then I try to commit and I see the commit failed and I can go to the console to see what errors.

I see that it deleted the extra space

and then I can just go ahead and click commit again and then this time it will succeed.

So what else can you do besides automatically formatting your code?

Well you can write your own commit hooks so you can pretty much do whatever you want, but there are a ton of really good ones already written on this website here.

Here are just a few of my favorites.

You can delete trailing whitespace, make sure a file is either empty or ends with a new line, make sure that any yaml files have valid yaml in them,

make sure you're not accidentally committing any really big files into your repository, and check for any spurious breakpoints that you forgot to delete before committing.

You can also run your linter like flake 8, you can reorder and standardize the order that your imports happen in, you can check for outdated syntax and replace it with its modern equivalent,

and this would also be a good place to run your type checker, like MyPy.

Pre-commit is most popular in the Python world, but it's not something that's just limited to Python.

There are premade scripts for doing things like running clang-tidy or clang-format, or some other code formatter for a different language.

You don't have to reinstall anything if you change the YAML file, just go ahead and commit.

We see the commit failed because of a MyPy error, telling us that we passed the wrong kind of argument to this function f.

Also note that most hooks will only run if an applicable file actually changed.

So it's not going to be reformatting code that it already formatted and hasn't changed.

Finally, there's the question of safety.

How safe is it to automatically run programs on your source code before committing them?

Well, this ultimately goes down to the project and whether or not you trust the project to do the right thing.

Of course, these little scripts can be written by anyone, so if they put something malicious in, then you're going to be out of luck.

You can fix a specific version or even a specific hash in the config file.

This helps mitigate things like what if this project gets hacked and an attacker uploads something malicious.

But as always, only use projects that you really trust.

As far as accidental errors go though, like what if black accidentally changed the meaning of the code?

Well, that's something that I haven't actually run into.

If something did go wrong, it would really be up to you to catch it in the git diff or by running tests.

Of course, for an accidental mistake, you can always revert using the git restore command that I talked about earlier.

Well, that's all I've got.

I hope this makes your repos better.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

FOR YOU

このレッスンの語彙とスピーキングのポイント

この動画には、シャドーイング用の文が78文、単語が1244語あります。音声の長さは5:52です。話す速さは速く、1分あたり約212語です。音のつながりや弱く発音される音が多くなります。英語の頻出3,000語に含まれる単語は80%だけなので、語彙は難しめです。

この動画の重要語彙

動画に出てくる覚えておきたい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
commit 動詞	/kəˈmɪt/	預ける, 任せる
hook 名詞	/hʊk/	鉤, フック
format 名詞	/ˈfɔːɹ.mæt/	書式, フォーマット
folder 名詞	/ˈfoʊldɚ/	フォルダ
script 名詞	/skɹɪpt/	文書, 文章
delete 動詞	/dɪˈliːt/	消す, 削除する
automatic 形容詞	/ˌɔː.təˈmæt.ɪk/	自動の, 自動的な
accidentally 副詞	/ˌæk.sɪˈdɛnt(ə)li/	無意識的に, 偶然
restore 動詞	/ɹɪˈstoɹ/	立て直す, 再建する
install 動詞	/ɪnˈstɔl/	導入する, インストールする
malicious 形容詞	/məˈlɪʃəs/	悪意のある
tidy 形容詞	/ˈtaɪ.di/	きちんとした, こざっぱりした
compare 動詞	/kəmˈpɛɚ/	比べる, 比較する
trail 名詞	/tɹeɪl/	跡, 痕跡
valid 形容詞	/ˈvælɪd/	有効な

動画に出てくる句動詞

単語	発音	意味
go ahead 動詞	/ˌɡoʊ əˈhɛd/	どうぞお先に
go down 動詞		降りる, 降下する
go out 動詞		出る

注意したい発音

話し手はdon't, I'm, you'reなど、短縮形や弱形を18回使っています。聞こえたとおりの短い形で発音しましょう。

「sh」と「zh」の音: modification /ˌmɑdɪfɪˈkeɪʃən/, malicious /məˈlɪʃəs/, notion /ˈnoʊʃən/, hash /ˈhæʃ/
長い単語（アクセントの位置に注意）: automatic /ˌɔː.təˈmæt.ɪk/, accidentally /ˌæk.sɪˈdɛnt(ə)li/, modification /ˌmɑdɪfɪˈkeɪʃən/, applicable /əˈplɪk.ə.bəl/, directory /dɪˈɹɛktəɹi/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。commit, hook, formatなどの単語に特に注意しましょう。

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	are called · might be hidden · been written
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	has gone · have already been written · have built

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: The easy way to keep your repos tidy. - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

おすすめ動画

GitHub Copilot now controls your command line...

The 7 Quality Control (QC) Tools Explained with an Example!

DRY Often Makes Your Code Worse

STOP Running Code On Your Computer

Prompt Engineering - Guidelines

Did Anthropic Kill Git?

How To Land Your First Junior Dev Role

Git Explained in 100 Seconds

Go’s Big Mistake

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

9 Insane Claude Mods I Already Can't live Without

Video