forcoder
diff --git a/‎jp/1-Beginner/Personal-Skills/01-Learn To Debug.md
Lines changed: 10 additions & 10 deletions b/‎jp/1-Beginner/Personal-Skills/01-Learn To Debug.md
Lines changed: 10 additions & 10 deletions
diff --git a/‎jp/1-Beginner/Personal-Skills/02-How to Debug by Splitting the Problem Space.md
Lines changed: 6 additions & 7 deletions b/‎jp/1-Beginner/Personal-Skills/02-How to Debug by Splitting the Problem Space.md
Lines changed: 6 additions & 7 deletions
diff --git a/‎jp/1-Beginner/Personal-Skills/03-How to Remove an Error.md
Lines changed: 3 additions & 3 deletions b/‎jp/1-Beginner/Personal-Skills/03-How to Remove an Error.md
Lines changed: 3 additions & 3 deletions
@@ -1,21 +1,21 @@
 # Learn to Debug
 [//]: # (Version:1.0.0)
-Debugging is the cornerstone of being a programmer. The first meaning of the verb "debug" is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind.
+デバッグはプログラマになるための基礎です。動詞 "debug"の最初の意味はエラーを取り除くことですが、実際に重要な意味は、プログラムの実行を調べて調べることです。効果的にデバッグできないプログラマーは目が見えません。
 
-Idealists, those who think design, analysis, complexity theory, and the like are more fundamental than debugging, are not working programmers. The working programmer does not live in an ideal world. Even if you are perfect, you are surrounded by and must interact with code written by major software companies, organizations like GNU, and your colleagues. Most of this code is imperfect and imperfectly documented. Without the ability to gain visibility into the execution of this code, the slightest bump will throw you permanently. Often this visibility can be gained only by experimentation: that is, debugging.
+理想主義者、設計、分析、複雑さの理論などがデバッグよりも基本的だと考える人は、プログラマーを働かせていません。働くプログラマーは理想的な世界に住んでいません。あなたが完璧であっても、大手ソフトウェア会社、GNUのような組織、およびあなたの同僚によって書かれたコードに囲まれていなければなりません。このコードのほとんどは不完全であり、不完全に文書化されています。このコードの実行を可視化する機能がなければ、わずかなバンプはあなたを永遠に投げ捨てます。多くの場合、この可視性は実験（デバッグ）によってのみ得られます。
 
-Debugging is about the running of programs, not programs themselves. If you buy something from a major software company, you usually don't get to see the program. But there will still arise places where the code does not conform to the documentation (crashing your entire machine is a common and spectacular example), or where the documentation is mute. More commonly, you create an error, examine the code you wrote, and have no clue how the error can be occurring. Inevitably, this means some assumption you are making is not quite correct or some condition arises that you did not anticipate. Sometimes, the magic trick of staring into the source code works. When it doesn't, you must debug.
+デバッグは、プログラムそのものではなく、プログラムの実行に関するものです。あなたが大手ソフトウェア会社から何かを購入した場合、通常はそのプログラムを見ることはできません。しかし、コードがドキュメントに準拠していない場所（マシン全体をクラッシュさせることは一般的で壮大な例です）やドキュメンテーションがミュートされている場所が発生します。より一般的には、エラーを作成し、書き込んだコードを調べ、エラーがどのように発生する可能性があるのか??わかりません。必然的に、これはあなたが作っているという前提がかなり正しくないこと、あるいはあなたが予期していない状態が発生したことを意味します。時には、ソースコードを眺めている魔法がうまく動作することもあります。そうでない場合は、デバッグする必要があります。
 
-To get visibility into the execution of a program you must be able to execute the code and observe something about it. Sometimes this is visible, like what is being displayed on a screen, or the delay between two events. In many other cases, it involves things that are not meant to be visible, like the state of some variables inside the code, which lines of code are actually being executed, or whether certain assertions hold across a complicated data structure. These hidden things must be revealed.
+プログラムの実行を可視化するには、コードを実行してそのコードを観察できる必要があります。画面に表示されているもの、または2つのイベント間の遅延のように、これが目に見えることがあります。多くの場合、コード内のいくつかの変数の状態、実際に実行されているコードの行、または複雑なデータ構造にわたって特定のアサーションが保持されているかどうかなど、目に見えないものが含まれます。これらの隠されたものは明らかにされなければなりません。
 
-The common ways of looking into the ‘innards’ of an executing program can be categorized as:
+実行プログラムの "nnards"を調べる一般的な方法は、次のように分類できます。
 
-- Using a debugging tool,
-- Printlining - Making a temporary modification to the program, typically adding lines that print information out, and
-- Logging - Creating a permanent window into the programs execution in the form of a log.
+- デバッグツールを使用して、
+- Printlining - プログラムを一時的に変更します。通常、情報を出力する行を追加します。
+- ロギング - プログラムの実行に永続的なウィンドウをログの形で作成します。
 
-Debugging tools are wonderful when they are stable and available, but printlining and logging are even more important. Debugging tools often lag behind language development, so at any point in time they may not be available. In addition, because the debugging tool may subtly change the way the program executes it may not always be practical. Finally, there are some kinds of debugging, such as checking an assertion against a large data structure, that require writing code and changing the execution of the program. It is good to know how to use debugging tools when they are stable, but it is critical to be able to employ the other two methods.
+デバッギングツールは、安定して利用可能な場合は素晴らしいですが、印刷ライティングとロギングはさらに重要です。デバッグツールは言語開発に遅れをとることが多いため、いつでも利用できない可能性があります。さらに、デバッグツールが微妙にプログラムの実行方法を変更する可能性があるため、必ずしも実際的ではない場合があります。最後に、大きなデータ構造に対するアサーションのチェック、コードの記述、プログラムの実行の変更など、いくつかの種類のデバッグがあります。デバッグツールが安定しているときにデバッグツールを使用する方法を知っておくことは良いことですが、他の2つの方法を使用できることが重要です。
 
-Some beginners fear debugging when it requires modifying code. This is understandable - it is a little like exploratory surgery. But you have to learn to poke at the code and make it jump; you have to learn to experiment on it and understand that nothing that you temporarily do to it will make it worse. If you feel this fear, seek out a mentor - we lose a lot of good programmers at the delicate onset of their learning to this fear.
+いくつかの初心者は、コードを変更する必要があるときにデバッグを恐れています。これは理解できる - それは探索的手術のようなものです。しかし、あなたはコードを突き刺してジャンプさせることを学ばなければなりません。あなたはそれを試して、あなたが一時的に行うことはそれを悪化させるものは何もないことを理解することを学ばなければなりません。この恐怖を感じる場合は、メンターを探してください。この恐怖への敏感な始まりで、多くの優れたプログラマーを失います。
 
 Next [How to Debug by Splitting the Problem Space](02-How to Debug by Splitting the Problem Space.md)
@@ -1,15 +1,14 @@
 # How to Debug by Splitting the Problem Space
 [//]: # (Version:1.0.0)
-Debugging is fun, because it begins with a mystery. You think it should do something, but instead it does something else. It is not always quite so simple---any examples I can give will be contrived compared to what sometimes happens in practice. Debugging requires creativity and ingenuity. If there is a single key to debugging it is to use the divide and conquer technique on the mystery.
+デバッグは楽しいです。なぜなら、それは謎で始まるからです。あなたは何かをすべきだと思うが、代わりに何かをする。それはいつも非常に簡単なわけではありません---私が与えることができる例は、実際に時々起こるものと比較して考案されます。デバッグには創造性と創意工夫が必要です。デバッグする単一のキーがある場合は、ミステリーで分割と征服のテクニックを使用することです。
 
-Suppose, for example, you created a program that should do ten things in a sequence. When you run it, it crashes. Since you didn't program it to crash, you now have a mystery. When you look at the output, you see that the first seven things in the sequence were run successfully. The last three are not visible from the output, so now your mystery is smaller: ‘It crashed on thing #8, #9, or #10.’
+たとえば、シーケンスで10個を実行するプログラムを作成したとします。あなたがそれを実行すると、クラッシュします。あなたがクラッシュするようにプログラムしていないので、今あなたは謎を持っています。出力を見ると、シーケンスの最初の7つが正常に実行されたことがわかります。最後の3つは出力から見えないので、今はあなたの謎は小さくなります： 'それは＃8、＃9、または＃10の物に墜落しました。
 
-Can you design an experiment to see which thing it crashed on? Sure. You can use a debugger or we can add printline statements (or the equivalent in whatever language you are working in) after #8 and #9. When we run it again, our mystery will be smaller, such as ‘It crashed on thing #9.’ I find that bearing in mind exactly what the mystery is at any point in time helps keep one focused. When several people are working together under pressure on a problem it is easy to forget what the most important mystery is.
+どのようなものがクラッシュしたかを確認するために実験を設計できますか？確かに。 ＃8と＃9の後に、デバッガを使用することもできますし、printline文（またはあなたが作業している言語に相当するもの）を追加することもできます。私たちがもう一度それを実行すると、「それは事9番に墜落しました」というような私の謎は小さくなるでしょう。いくつかの人々が問題に圧力をかけて一緒に働いているとき、最も重要な謎が何であるかを忘れるのは簡単です。
 
-The key to divide and conquer as a debugging technique is the same as it is for algorithm design: as long as you do a good job splitting the mystery in the middle, you won't have to split it too many times, and you will be debugging quickly. But what is the middle of a mystery? This is where true creativity and experience comes in.
+デバッグ技術として分割して克服する鍵は、アルゴリズム設計と同じです。ミステリーを途中で分割すると、何度も分割する必要はなくなります。迅速にデバッグすることができます。しかし、謎の真ん中は何ですか？これは、真の創造性と経験が生まれる場所です。
 
-To a true beginner, the space of all possible errors looks like every line in the source code. You don't have the vision you will later develop to see the other dimensions of the program, such as the space of executed lines, the data structure, the memory management, the interaction with foreign code, the code that is risky, and the code that is simple. For the experienced programmer, these other dimensions form an imperfect but very useful mental model of all the things that can go wrong. Having that mental model is what helps one find the middle of the mystery effectively.
-
-Once you have evenly subdivided the space of all that can go wrong, you must try to decide in which space the error lies. In the simple case where the mystery is: ‘Which single unknown line makes my program crash?’, you can ask yourself: ‘Is the unknown line executed before or after this line that I judge to be executed in the middle of the running program?’ Usually you will not be so lucky as to know that the error exists in a single line, or even a single block. Often the mystery will be more like: ‘Either there is a pointer in that graph that points to the wrong node, or my algorithm that adds up the variables in that graph doesn't work.’ In that case you may have to write a small program to check that the pointers in the graph are all correct in order to decide which part of the subdivided mystery can be eliminated.
+真の初心者にとって、考えられるすべてのエラーの領域は、ソースコード内のすべての行のように見えます。実行された行のスペース、データ構造、メモリ管理、外部コードとのやりとり、危険なコードなど、プログラムの他の次元を見るために後で開発するビジョンはありません。単純なコードです。経験豊富なプログラマーにとって、これらの他の次元は、間違っている可能性があるすべての事柄の不完全だが非常に有用な精神モデルを形成する。その精神モデルを持つことは、謎の真ん中を効果的に見つけるのに役立ちます。
 
+間違っている可能性のある領域を均等に細分したら、エラーがどの領域にあるかを判断する必要があります。私のプログラムがクラッシュする単一の不明な行はどれですか？単純なケースでは、自分が実行しているプログラムの途中で実行されると判断した行の前または後に未知の行が実行されていますか？ '通常、エラーが単一の行に存在するか、単一のブロックであるかを知ることは大変幸運なことではありません。しばしば、ミステリーは、「間違ったノードを指し示すポインタがそのグラフにあるか、またはそのグラフ内の変数を加算するアルゴリズムが機能しません」という場合があります。その場合は、分割された謎のどの部分を除去できるかを決定するために、グラフ内のポインタがすべて正しいことを確認する小さなプログラム。
 Next [How to Remove an Error](03-How to Remove an Error.md)
@@ -1,9 +1,9 @@
 # How to Remove an Error
 [//]: # (Version:1.0.0)
-I've intentionally separated the act of examining a program's execution from the act of fixing an error. But of course, debugging does also mean removing the bug. Ideally you will have perfect understanding of the code and will reach an ‘A-Ha!’ moment where you perfectly see the error and how to fix it. But since your program will often use insufficiently documented systems into which you have no visibility, this is not always possible. In other cases the code is so complicated that your understanding cannot be perfect.
+私は意図的にプログラムの実行をエラーを修正する行為から調べるという行為を分けた。もちろん、デバッグはバグを取り除くことを意味します。理想的には、コードを完全に理解し、エラーが完全に表示され、修正する方法を示す「ハハ！」の瞬間に到達します。しかし、あなたのプログラムでは、可視性のない文書化されたシステムを使用することが多いため、必ずしもそうであるとは限りません。他のケースでは、コードが複雑であるため、理解が完全ではありません。
 
-In fixing a bug, you want to make the smallest change that fixes the bug. You may see other things that need improvement; but don't fix those at the same time. Attempt to employ the scientific method of changing one thing and only one thing at a time. The best process for this is to be able to easily reproduce the bug, then put your fix in place, and then rerun the program and observe that the bug no longer exists. Of course, sometimes more than one line must be changed, but you should still conceptually apply a single atomic change to fix the bug.
+バグを修正するには、バグを修正する最小限の変更を加えたいと考えています。あなたは改善が必要な他のものを見るかもしれません。同時にそれらを修正しないでください。一度に一つのこと、ただ一つの事を変える科学的方法を採用しようとする。このための最良のプロセスは、バグを簡単に再現し、修正プログラムを適用してからプログラムを再実行し、バグが存在しなくなったことを確認することです。もちろん、時には複数の行を変更する必要があるかもしれませんが、バグを修正するために概念的に1つのアトミックな変更を適用する必要があります。
 
-Sometimes, there are really several bugs that look like one. It is up to you to define the bugs and fix them one at a time. Sometimes it is unclear what the program should do or what the original author intended. In this case, you must exercise your experience and judgment and assign your own meaning to the code. Decide what it should do, and comment it or clarify it in some way and then make the code conform to your meaning. This is an intermediate or advanced skill that is sometimes harder than writing the original function in the first place, but the real world is often messy. You may have to fix a system you cannot rewrite.
+時には、実際には1つのように見えるいくつかのバグがあります。バグを定義して一度に修正するのはあなた次第です。時々、プログラムが何をすべきか、または元の著者が意図したものが不明である。この場合、あなたは自分の経験と判断を行い、コードに自分の意味を割り当てる必要があります。何をすべきかを決定し、コメントしたり、何らかの方法でそれを明確にしたりして、コードをあなたの意味に適合させます。これは、最初の場所に元の関数を書くよりも時には難しい中級または上級のスキルですが、実際の世界はしばしば面倒です。書き換えができないシステムを修正する必要があるかもしれません。
 
 Next [How to Debug Using a Log](04-How to Debug Using a Log.md)