diff --git a/jp/2-Intermediate/Judgment/01-How to Tradeoff Quality Against Development Time.md b/jp/2-Intermediate/Judgment/01-How to Tradeoff Quality Against Development Time.md index 0f1bb61..a33dd4d 100644 --- a/jp/2-Intermediate/Judgment/01-How to Tradeoff Quality Against Development Time.md +++ b/jp/2-Intermediate/Judgment/01-How to Tradeoff Quality Against Development Time.md @@ -1,13 +1,13 @@ # How to Tradeoff Quality Against Development Time [//]: # (Version:1.0.0) -Software development is always a compromise between what the project does and getting the project done. But you may be asked to tradeoff quality to speed the deployment of a project in a way that offends your engineering or business sensibilities. For example, you may be asked to do something that is a poor software engineering practice and that will lead to a lot of maintenance problems. +ソフトウェア開発は、プロジェクトが行うこととプロジェクトを完了させることの間で常に妥協です。しかし、エンジニアリングやビジネスの感性を傷つけるような方法でプロジェクトの展開をスピードアップするために、品質をトレードオフするように求められることがあります。たとえば、ソフトウェアエンジニアリングの慣行が貧弱で、メンテナンスの問題が多く発生するような作業をするように求められる場合があります。 -If this happens your first responsibility is to inform your team and to clearly explain the cost of the decrease in quality. After all, your understanding of it should be much better than your boss's understanding. Make it clear what is being lost and what is being gained, and at what cost the lost ground will be regained in the next cycle. In this, the visibility provided by a good project plan should be helpful. If the quality tradeoff affects the quality assurance effort, point that out (both to your boss and quality assurance people). If the quality tradeoff will lead to more bugs being reported after the quality assurance period, point that out. +これが起きた場合は、まずチームに知らせ、品質低下のコストを明確に説明することです。結局のところ、あなたの理解はあなたの上司の理解よりはるかに良いはずです。何が失われているのか、何が得られているのかを明確にし、次のサイクルで失われた地面をどのようなコストで取り戻すのでしょうか。この中で、良いプロジェクト計画が提供する可視性が役立つはずです。品質のトレードオフが品質保証の努力に影響を及ぼす場合は、それを指摘してください（上司と品質保証担当者の両方に）。品質のトレードオフが品質保証期間後に報告されるバグを増やす場合は、それを指摘してください。 -If she still insists, you should try to isolate the shoddiness into particular components that you can plan to rewrite or improve in the next cycle. Explain this to your team so that they can plan for it. +彼女がまだ主張しているなら、次のサイクルで書き直しや改善を計画することができる特定のコンポーネントに不自由さを分離しようとするべきです。これをあなたのチームに説明し、計画を立てることができます。 -NinjaProgrammer at Slashdot sent in this gem: +SlashdotのNinjaProgrammerがこの宝石を送った： -> Remember that a good design will be resilient against poor code implementations. If good interfaces and abstractions exist throughout the code, then the eventual rewrites will be far more painless. If it is hard to write clear code that is hard to fix, consider what is wrong with the core design that is causing this. +>優れた設計は、貧弱なコード実装に対して回復することを忘れないでください。コード全体で良好なインタフェースと抽象概念が存在する場合、最終的な書き換えははるかに無痛になります。修正が難しい明確なコードを書くのが難しい場合は、これを引き起こしているコアデザインに何が問題なのかを検討してください。 Next [How to Manage Software Dependence](02-How to Manage Software System Dependence.md) diff --git a/jp/2-Intermediate/Judgment/02-How to Manage Software System Dependence.md b/jp/2-Intermediate/Judgment/02-How to Manage Software System Dependence.md index 86900ca..e46fc50 100644 --- a/jp/2-Intermediate/Judgment/02-How to Manage Software System Dependence.md +++ b/jp/2-Intermediate/Judgment/02-How to Manage Software System Dependence.md @@ -1,13 +1,13 @@ # How to Manage Software System Dependence [//]: # (Version:1.0.0) -Modern software systems tend to depend on a large number of components that may not be directly under your control. This increases productivity through synergy and reuse. However, each component brings with it some problems: +現代のソフトウェアシステムは、あなたのコントロール下に直接存在しないかもしれない多くのコンポーネントに依存する傾向があります。これにより、シナジーと再利用により生産性が向上します。しかし、各コンポーネントにはいくつかの問題があります。 -- How will you fix bugs in the component? -- Does the component restrict you to particular hardware or software systems? -- What will you do if the component fails completely? +- コンポーネントのバグをどのように修正しますか？ +- コンポーネントが特定のハードウェアまたはソフトウェアシステムに制限していますか？ +- コンポーネントが完全に失敗したらどうしますか？ -It is always best to encapsulate the component in some way so that it is isolated and so that it can be swapped out. If the component proves to be completely unworkable, you may be able to get a different one, but you may have to write your own. Encapsulation is not portability, but it makes porting easier, which is almost as good. +コンポーネントが何らかの方法でカプセル化され、コンポーネントが分離され、スワップアウトできるようにすることが常にベストです。コンポーネントが完全に機能しないと判明した場合は、別のコンポーネントを手に入れることができますが、独自のコンポーネントを作成する必要があります。カプセル化は移植性ではありませんが、移植が容易になりますが、これはほぼ同じです。 -Having the source code for a component decreases the risk by a factor of four. With source code, you can evaluate it easier, debug it easier, find workarounds easier, and make fixes easier. If you make fixes, you should give them to the owner of the component and get the fixes incorporated into an official release; otherwise you will uncomfortably have to maintain an unofficial version. +コンポーネントのソースコードを持つことは、リスクを4倍に減少させます。ソースコードを使用すると、より簡単に評価し、簡単にデバッグし、回避策を見つけやすくなり、修正を簡単に行うことができます。修正プログラムを作成する場合は、コンポーネントの所有者に修正プログラムを渡し、修正プログラムを公式リリースに組み込む必要があります。それ以外の場合は、非公式のバージョンを維持する必要があります。 Next [How to Decide if Software is Too Immature](03-How to Decide if Software is Too Immature.md) diff --git a/jp/2-Intermediate/Judgment/03-How to Decide if Software is Too Immature.md b/jp/2-Intermediate/Judgment/03-How to Decide if Software is Too Immature.md index 93f03ff..18512b4 100644 --- a/jp/2-Intermediate/Judgment/03-How to Decide if Software is Too Immature.md +++ b/jp/2-Intermediate/Judgment/03-How to Decide if Software is Too Immature.md @@ -1,18 +1,18 @@ # How to Decide if Software is Too Immature [//]: # (Version:1.0.0) -Using software other people wrote is one of the most effective ways to quickly build a solid system. It should not be discouraged, but the risks associated with it must be examined. One of the biggest risks is the period of bugginess and near inoperability that is often associated with software before it matures, through usage, into a usable product. Before you consider integrating with a software system, whether created in house or by a third party, it is very important to consider if it is really mature enough to be used. Here are ten questions you should ask yourself about it: +他の人が書いたソフトウェアを使用することは、堅牢なシステムを迅速に構築する最も効果的な方法の1つです。それは落胆すべきではありませんが、それに伴うリスクを検討しなければなりません。最も大きなリスクの1つは、ソフトウェアが使用可能な製品に成熟する前に、しばしばソフトウェアに関連している、バグと不完全な動作の期間です。ソフトウェアシステムとの統合を検討する前に、社内で作成されたものであろうと第三者によって作成されたものであろうと、実際に使用するには十分に成熟しているかどうかを検討することが非常に重要です。ここであなた自身に尋ねるべき10の質問があります： -1. Is it vapour? (Promises are very immature). -2. Is there an accessible body of lore about the software? -3. Are you the first user? -4. Is there a strong incentive for continuation? -5. Has it had a maintenance effort? -6. Will it survive defection of the current maintainers? -7. Is there a seasoned alternative at least half as good? -8. Is it known to your tribe or company? -9. Is it desirable to your tribe or company? -10. Can you hire people to work on it even if it is bad? +1.蒸気ですか？ （約束は非常に未成熟です）。 +2.ソフトウェアに関する知識のあるアクセス可能な本体がありますか？ +3.あなたは最初のユーザーですか？ +4.継続に強いインセンティブはありますか？ +5.メンテナンスに努力していましたか？ +6.それは現在のメンテナの崩壊から生き残ることができますか？ +7.少なくとも半分の味付けの代替品がありますか？ +あなたの部族や会社にそれは知られていますか？ +あなたの部族や会社には望ましいのですか？ +10.あなたが悪い場合でもそれに取り組む人々を雇うことができますか？ -A little consideration of these criteria demonstrates the great value of well-established free software and open-source software in reducing risk to the entrepreneur. +これらの基準を少し考慮すれば、起業家のリスクを削減するための十分に確立されたフリーソフトウェアとオープンソースソフトウェアの大きな価値が証明されます。 Next [How to Make a Buy vs. Build Decision](04-How to Make a Buy vs Build Decision.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Judgment/04-How to Make a Buy vs Build Decision.md b/jp/2-Intermediate/Judgment/04-How to Make a Buy vs Build Decision.md index 64d69e7..7bfd78f 100644 --- a/jp/2-Intermediate/Judgment/04-How to Make a Buy vs Build Decision.md +++ b/jp/2-Intermediate/Judgment/04-How to Make a Buy vs Build Decision.md @@ -1,16 +1,16 @@ # How to Make a Buy vs. Build Decision [//]: # (Version:1.0.0) -An entrepreneurial company or project that is trying to accomplish something with software has to constantly make so-called *buy vs. build* decisions. This turn of phrase is unfortunate in two ways: it seems to ignore open-source and free software which is not necessarily *bought*. Even more importantly, it should perhaps be called an *obtain and integrate vs. build here and integrate* decision because the cost of integration must be considered. This requires a great combination of business, management, and engineering savvy. +ソフトウェアを使って何かを達成しようとしている起業家の企業やプロジェクトは、常に「購入」対「決定」の決定をしなければなりません。このフレーズのターンは、2つの点で不幸である。オープンソースと、必ずしも*買っていないフリーソフトウェアを無視しているようだ。さらに重要なのは、統合コストを考慮する必要があるため、ここで取得して統合するか、ここで構築して決定するかを統合することです。これには、ビジネス、管理、エンジニアリングに精通した人材が必要です。 -- How well do your needs match those for which it was designed? -- What portion of what you buy will you need? -- What is the cost of evaluating the integration? -- What is the cost of integration? -- Will buying increase or decrease long term maintenance costs? -- Will building it put you in a business position you don't want to be in? +- あなたのニーズは、それが設計されたものとどれくらいよく合っていますか？ +- あなたが購入するもののうち、どの部分が必要ですか？ +- 統合を評価するコストはいくらですか？ +- 統合のコストはいくらですか？ +- 購入は長期的な維持費を増減させるだろうか？ +- それを構築することで、あなたが望んでいないビジネスポジションにあなたを置くことはできますか？ -You should think twice before building something that is big enough to serve as the basis for an entire other business. Such ideas are often proposed by bright and optimistic people that will have a lot to contribute to your team. If their idea is compelling, you may wish to change your business plan; but do not invest in a solution bigger than your own business without conscious thought. +あなたは、他のビジネス全体の基礎となるほど大きなものを構築する前に、二度考えなければなりません。そのようなアイデアは、あなたのチームに貢献することがたくさんある明るく楽観的な人々によって提案されることがよくあります。彼らのアイデアが魅力的であれば、ビジネスプランを変更したいかもしれません。意識がなくても自分のビジネスよりも大きなソリューションに投資しないでください。 -After considering these questions, you should perhaps prepare two draft project plans, one for building and one for buying. This will force you to consider the integration costs. You should also consider the long term maintenance costs of both solutions. To estimate the integration costs, you will have to do a thorough evaluation of the software before you buy it. If you can't evaluate it, you will assume an unreasonable risk in buying it and you should decide against buying that particular product. If there are several buy decisions under consideration, some energy will have to be spent evaluating each. +これらの質問を検討した後、おそらく建築用と購入用の2つのプロジェクト計画案を準備する必要があります。これにより、統合コストを考慮する必要があります。また、両方のソリューションの長期的なメンテナンスコストも考慮する必要があります。統合コストを見積もるには、ソフトウェアを購入する前に完全な評価を行う必要があります。あなたがそれを評価することができない場合、あなたはそれを購入する際に不合理なリスクを想定し、その特定の製品を購入することを決定する必要があります。考慮中の購入決定がいくつかある場合、それぞれを評価するためにいくつかのエネルギーを費やす必要があります。 Next [How to Grow Professionally](05-How to Grow Professionally.md) diff --git a/jp/2-Intermediate/Judgment/05-How to Grow Professionally.md b/jp/2-Intermediate/Judgment/05-How to Grow Professionally.md index 5ad8576..f3ab647 100644 --- a/jp/2-Intermediate/Judgment/05-How to Grow Professionally.md +++ b/jp/2-Intermediate/Judgment/05-How to Grow Professionally.md @@ -1,11 +1,11 @@ # How to Grow Professionally [//]: # (Version:1.0.0) -Assume responsibility in excess of your authority. Play the role that you desire. Express appreciation for people's contribution to the success of the larger organization, as well as things as that help you personally. +あなたの権限を超えた責任を負います。 あなたが望む役割を果たしてください。 大規模な組織の成功への人々の貢献、そしてあなたが個人的に役立つものへの感謝を表明してください。 -If you want to become a team leader, instigate the formation of consensus. If you want to become a manager, take responsibility for the schedule. You can usually do this comfortably while working with a leader or a manager, since this frees them up to take greater responsibility. If that is too much to try, do it a little at a time. +あなたがチームリーダーになりたいなら、コンセンサスの形成を促す。 マネージャーになりたい場合は、スケジュールを担当してください。 リーダーやマネージャーと一緒に仕事をしている間は、通常これを快適に行うことができます。これにより、リーダーやマネージャーがより大きな責任を負うことになります。 それが試しすぎるなら、一度に少ししてください。 -Evaluate yourself. If you want to become a better programmer, ask someone you admire how you can become like them. You can also ask your boss, who will know less but have a greater impact on your career. +あなた自身を評価してください。 あなたがより良いプログラマになりたいなら、あなたがどのようにそれらのようになることができるか賞賛する人に尋ねなさい。 上司に聞くこともできます。上司には知っていますが、あなたのキャリアに大きな影響を与えます。 -Plan ways to learn new skills, both the trivial technical kind, like learning a new software system, and the hard social kind, like writing well, by integrating them into your work. +新しいソフトウェアシステムを学ぶことのような、些細な技術的なものでも、あなたの仕事にそれらを統合することによって、うまく書くようなハードな社会的なものでも、新しいスキルを学ぶ方法を計画する。 Next [How to Evaluate Interviewees](06-How to Evaluate Interviewees.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Judgment/06-How to Evaluate Interviewees.md b/jp/2-Intermediate/Judgment/06-How to Evaluate Interviewees.md index cf24614..766438e 100644 --- a/jp/2-Intermediate/Judgment/06-How to Evaluate Interviewees.md +++ b/jp/2-Intermediate/Judgment/06-How to Evaluate Interviewees.md @@ -1,15 +1,15 @@ # How to Evaluate Interviewees [//]: # (Version:1.0.0) -Evaluating potential employees is not given the energy it deserves. A bad hire, like a bad marriage, is terrible. A significant portion of everyone's energy should be devoted to recruitment, though this is rarely done. +潜在的な従業員を評価することは、それにふさわしいエネルギーが与えられていない。悪い結婚のような悪い雇用はひどいです。みんなのエネルギーのかなりの部分は募集に費やされるべきですが、これはめったに行われません。 -There are different interviewing styles. Some are torturous, designed to put the candidate under a great deal of stress. This serves a very valuable purpose of possibly revealing character flaws and weaknesses under stress. Candidates are no more honest with interviewers than they are with themselves, and the human capacity for self-deception is astonishing. +インタビュースタイルはさまざまです。候補者の中には非常にストレスを感じるように設計された拷問家もいます。これはストレス下でのキャラクターの欠陥や弱点を明らかにする非常に貴重な目的を果たします。候補者は自分自身と比べてインタビュアーには正直ではなく、自己欺瞞に対する人間の能力は驚くべきものです。 -You should, at a minimum, give the candidate the equivalent of an oral examination on the technical skills for two hours. With practice, you will be able to quickly cover what they know and quickly retract from what they don't know to mark out the boundary. Interviewees will respect this. I have several times heard interviewees say that the quality of the examination was one of their motivations for choosing a company. Good people want to be hired for their skills, not where they worked last or what school they went to or some other inessential characteristic. +あなたは少なくとも、2時間の技術スキルの口頭試験に相当するものを候補者に与えるべきです。練習では、自分が知っていることをすばやくカバーし、境界線をマークするために知らないものからすばやく取り戻すことができます。面接者はこれを尊重するでしょう。私は、インタビューで、試験の質は企業を選ぶ動機の1つであると数回聞いたことがあります。善良な人たちは、彼らが最後に働いた場所や彼らが行った学校、または他の不可欠な特徴ではなく、彼らのスキルのために雇われたいと思っています。 -In doing this, you should also evaluate their ability to learn, which is far more important than what they know. You should also watch for the whiff of brimstone that is given off by difficult people. You may be able to recognize it by comparing notes after the interview, but in the heat of the interview it is hard to recognize. How well people communicate and work with people is more important than being up on the latest programming language. +これを行うにあたっては、自分が知っているよりもはるかに重要な、学習する能力も評価する必要があります。また、困難な人たちによって払われた有害物質の欲求を監視する必要があります。あなたはインタビューの後でノートを比較することによってそれを認識することができるかもしれませんが、インタビューの熱でそれを認識することは困難です。最新のプログラミング言語を上回るよりも、人々がコミュニケーションをして人々とどのくらいうまくやっていくかが重要です。 -A reader has had good luck using a 窶take-home窶 test for interviewees. This has the advantage that it can uncover the interviewee that can present themselves well but can't really code - and there are many such people. I personally have not tried this technique, but it sounds sensible. +読者はインタビュー対象者のためにテイク・ホーム・テストを使って幸運を祈っています。これは、自分自身をうまく提示することができますが、実際にはコード化することができないインタビュイーを明らかにすることができるという利点があります。私は個人的にはこのテクニックを試していませんが、それは賢明なようです。 -Finally, interviewing is also a process of selling. You should be selling your company or project to the candidate. However, you are talking to a programmer, so don't try to colour the truth. Start off with the bad stuff, then finish strong with the good stuff. +最後に、インタビューは販売のプロセスでもあります。候補者にあなたの会社やプロジェクトを売っているはずです。しかし、あなたはプログラマと話しているので、真実を色づけしようとしないでください。悪いものから始めて、次に良いもので強く仕上げてください。 Next [How to Know When to Apply Fancy Computer Science](07-How to Know When to Apply Fancy Computer Science.md) diff --git a/jp/2-Intermediate/Judgment/07-How to Know When to Apply Fancy Computer Science.md b/jp/2-Intermediate/Judgment/07-How to Know When to Apply Fancy Computer Science.md index 8575639..761a94f 100644 --- a/jp/2-Intermediate/Judgment/07-How to Know When to Apply Fancy Computer Science.md +++ b/jp/2-Intermediate/Judgment/07-How to Know When to Apply Fancy Computer Science.md @@ -1,15 +1,15 @@ # How to Know When to Apply Fancy Computer Science [//]: # (Version:1.0.0) -There is a body of knowledge about algorithms, data structures, mathematics, and other gee-whiz stuff that most programmers know about but rarely use. In practice, this wonderful stuff is too complicated and generally unnecessary. There is no point in improving an algorithm when most of your time is spent making inefficient database calls, for instance. An unfortunate amount of programming consists of getting systems to talk to each other and using very simple data structures to build a nice user interface. +アルゴリズム、データ構造、数学、その他のほとんどのプログラマが知っていることはほとんどありませんが、あまり使われていないことについての知識があります。実際には、この素晴らしいものはあまりにも複雑で一般的には不要です。ほとんどの時間が非効率的なデータベース呼び出しを行うのに費やされたときには、アルゴリズムの改善には何の意味もありません。プログラミングの不幸な量は、システムがお互いに話をしたり、非常に単純なデータ構造を使ってすばらしいユーザーインターフェイスを構築することから成ります。 -When is high technology the appropriate technology? When should you crack a book to get something other than a run-of-the-mill algorithm? It is sometimes useful to do this but it should be evaluated carefully. +高度な技術はいつ適切な技術ですか？あなたは、本物のアルゴリズム以外の何かを得るためにいつ本を解読すべきですか？これを行うのが便利なこともありますが、慎重に評価する必要があります。 -The three most important considerations for the potential computer science technique are: +潜在的なコンピュータサイエンス技術の3つの最も重要な考慮事項は次のとおりです。 -- Is it well encapsulated so that the risk to other systems is low and the overall increase in complexity and maintenance cost is low? -- Is the benefit startling (for example, a factor of two in a mature system or a factor of ten in a new system)? -- Will you be able to test and evaluate it effectively? +- 他のシステムに対するリスクが低く、複雑さと保守コストの全体的な増加が少ないように、十分にカプセル化されていますか？ +- 利益は驚異的です（例えば、成熟したシステムでは2倍、新しいシステムでは10倍）。 +- それを効果的にテストし評価することができますか？ -If a well-isolated algorithm that uses a slightly fancy algorithm can decrease hardware cost or increase performance by a factor of two across an entire system, then it would be criminal not to consider it. One of the keys to arguing for such an approach is to show that the risk is really quite low, since the proposed technology has probably been well studied, the only issue is the risk of integration. Here a programmer's experience and judgement can truly synergize with the fancy technology to make integration easy. +わずかに複雑なアルゴリズムを使用する孤立したアルゴリズムでは、システム全体でハードウェアのコストを削減したり、パフォーマンスを2倍に高めることができれば、犯罪者はそれを考慮しないことになります。そのようなアプローチを主張する鍵の1つは、提案された技術がおそらく十分に研究されているので、リスクが実際にはかなり低いことを示すことです。唯一の問題は統合のリスクです。ここでプログラマの経験と判断は、統合を容易にするための派手な技術と相乗効果があります。 Next [How to Talk to Non-Engineers](08-How to Talk to Non-Engineers.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Judgment/08-How to Talk to Non-Engineers.md b/jp/2-Intermediate/Judgment/08-How to Talk to Non-Engineers.md index a2b6211..54921d7 100644 --- a/jp/2-Intermediate/Judgment/08-How to Talk to Non-Engineers.md +++ b/jp/2-Intermediate/Judgment/08-How to Talk to Non-Engineers.md @@ -1,19 +1,19 @@ # How to Talk to Non-Engineers [//]: # (Version:1.0.0) -Engineers and programmers in particular are generally recognized by popular culture as being different from other people. This implies that other people are different from us. This is worth bearing in mind when communicating with non-engineers; you should always understand the audience. +特にエンジニアやプログラマーは、一般的な文化によって、他の人々とは異なると一般に認められています。これは、他の人々が私たちと異なることを意味します。これは、エンジニア以外の人とコミュニケーションをとるときには留意する価値があります。あなたは常に観客を理解する必要があります。 -Non-engineers are smart, but not as grounded in creating technical things as we are. We make things. They sell things and handle things and count things and manage things, but they are not experts on making things. They are not as good at working together on teams as engineers are (there are no doubt exceptions.) Their social skills are generally as good as or better than engineers in non-team environments, but their work does not always demand that they practice the kind of intimate, precise communication and careful subdivisions of tasks that we do. +ノンエンジニアはスマートですが、私たちのように技術的なことを作成することに根ざしたものではありません。私たちは物事を作る。彼らは物事を売り、物事を扱い、物事を数えたり管理したりしますが、物事を作る専門家ではありません。エンジニアのようにチームで一緒に仕事をするのはあまり良くありません（例外はありません）。彼らのソーシャルスキルは一般に、チーム以外の環境のエンジニアと同じかそれ以上ですが、親密な、正確なコミュニケーションの種類と私たちが行う仕事の慎重な細分化。 -Non-engineers may be too eager to please and they may be intimidated by you. Just like us, they may say 窶yes窶 without really meaning it to please you or because they are a little scared of you, and then not stand behind their words. +エンジニア以外の人はあまりにも喜んでいるかもしれませんし、あなたに脅かされるかもしれません。私たちと同じように、彼らは本当にあなたを喜ばせることを意味するものでも、あなたのことを少し怖がっているのではなく、言葉の背後に立つこともありません。 -Non-programmers can understand technical things but they do not have the thing that is so hard even for us - technical judgement. They do understand how technology works, but they cannot understand why a certain approach would take three months and another one three days. (After all, programmers are anecdotally horrible at this kind of estimation as well.) This represents a great opportunity to synergize with them. +プログラマー以外の人は技術的なことを理解することができますが、技術的な判断でさえ私たちにとってさえ難しいことはありません。彼らはテクノロジーの仕組みを理解していますが、なぜ特定のアプローチが3ヶ月かかるのか、そしてもう1つは3日かかるのか理解できません。 （結局のところ、プログラマーはこの種の見積もりにも驚異的なことがあります。）これは、それらと相乗効果を発揮する絶好の機会です。 -When talking to your team you will, without thinking, use a sort of shorthand, an abbreviated language that is effective because you will have much shared experience about technology in general and your product in particular. It takes some effort not to use this shorthand with those that don't have that shared experience, especially when members of your own team are present. This vocabulary creates a wall between you and those that do not share it, and, even worse, wastes their time. +あなたのチームと話をするときには、思考せずに、一般的な技術や特にあなたの製品に関する多くの経験を共有するため、短縮された言葉を使用して効果的です。この速記を、特にあなた自身のチームのメンバーがいるときに、その経験を共有していない人には使用しないようにするには、多少の努力が必要です。このボキャブラリーは、あなたとそれを共有しない人との間に壁を作り、さらに悪いことに、自分の時間を無駄にします。 -With your team, the basic assumptions and goals do not need to be restated often, and most conversation focuses on the details. With outsiders, it must be the other way around. They may not understand things you take for granted. Since you take them for granted and don't repeat them, you can leave a conversation with an outsider thinking that you understand each other when really there is a large misunderstanding. You should assume that you will miscommunicate and watch carefully to find this miscommunication. Try to get them to summarize or paraphrase what you are saying to make sure they understand. If you have the opportunity to meet with them often, spend a little bit of time asking if you are communicating effectively, and how you can do it better. If there is a problem in communication, seek to alter your own practices before becoming frustrated with theirs. +チームでは、基本的な前提と目標を頻繁に再記述する必要はなく、ほとんどの会話は詳細に焦点を当てています。部外者の場合、それは逆になります。彼らはあなたが当然のことを理解していないかもしれません。あなたはそれらを当然受け取り、それらを繰り返さないので、本当に大きな誤解があるときにお互いを理解するという外部者の考えを持って、会話を残すことができます。あなたは、この誤ったコミュニケーションを見つけるために、コミュニケーションを誤って慎重に見ていると想定してください。あなたが理解していることを確認するためにあなたが言っていることを要約したり言い換えたりするようにしてください。頻繁に会う機会がある場合は、効果的にコミュニケーションを取っているかどうかを尋ねる時間を少し費やしてください。コミュニケーションに問題がある場合は、自分の慣行を変えてから、自分に不満を募らせてください。 -I love working with non-engineers. It provides great opportunities to learn and to teach. You can often lead by example, in terms of the clarity of your communication. Engineers are trained to bring order out of chaos, to bring clarity out of confusion, and non-engineers like this about us. Because we have technical judgement and can usually understand business issues, we can often find a simple solution to a problem. +私は非エンジニアとの仕事が大好きです。それは学び、教える大きな機会を提供します。あなたは、コミュニケーションの明確さの観点から、しばしば例を挙げることができます。エンジニアは、混乱から秩序を引き出すこと、混乱からはっきりさせること、そしてこのような非技術者は私たちについて訓練を受けています。私たちは技術的な判断を下し、通常はビジネス上の問題を理解することができるため、問題を簡単に解決することができます。 -Often non-engineers propose solutions that they think will make it easier on us out of kindness and a desire to do the right thing, when in fact a much better overall solution exists which can only be seen by synergizing the outsider's view with your technical judgement. I personally like Extreme Programming because it addresses this inefficiency; by marrying the estimation quickly to the idea, it makes it easier to find the idea that is the best combination of cost and benefit. +しばしば技術者以外の人たちは、あなたの技術的判断と外部者の見解を相乗させることによってしか見えない、より良い全体的な解決策が存在するときに、優しさから逃れやすくして正しいことをしたいという希望を簡単にするソリューションを提案することがあります。私は個人的には極端なプログラミングが好きです。なぜなら、この非効率性に対処するからです。見積もりを素早くアイデアに結び付けることで、コストと利益の最良の組み合わせであるアイデアを簡単に見つけることができます。 Next [Advanced skills](../../3-Advanced) diff --git a/jp/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md b/jp/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md index aa7a9b3..a210a4a 100644 --- a/jp/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md +++ b/jp/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md @@ -1,15 +1,15 @@ # How to Stay Motivated [//]: # (Version:1.0.0) -It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful, or nifty. This desire is not unique to programmers nor universal but it is so strong and common among programmers that it separates them from others in other roles. +プログラマーが、美しく、有益な、または気の利いた人工物を作成したいという欲求によって高い意欲を持っていることは、素晴らしい、驚くべき事実です。この要望は、プログラマーにとってもユニバーサルでもなく、プログラマー間で非常に強く共通しているため、他の役割のメンバーとは分かれています。 -This has practical and important consequences. If programmers are asked to do something that is not beautiful, useful, or nifty, they will have low morale. There's a lot of money to be made doing ugly, stupid, and boring stuff; but in the end, fun will make the most money for the company. +これには実用的かつ重要な結果があります。プログラマーが、美しくない、有益な、または気の利いたものでないことをするよう求められた場合、彼らは低い士気を持つでしょう。醜い、愚かな、退屈なものをやって作るためにたくさんのお金があります。しかし、結局のところ、楽しみは会社のために最もお金を稼ぐでしょう。 -Obviously, there are entire industries organized around motivational techniques some of which apply here. The things that are specific to programming that I can identify are: +明らかに、ここにはいくつかの動機づけ技術が組み込まれた業界全体があります。私が特定できるプログラミング特有の事柄は次のとおりです： -- Use the best language for the job. -- Look for opportunities to apply new techniques, languages, and technologies. -- Try to either learn or teach something, however small, in each project. +- 仕事に最適な言語を使用してください。 +- 新しい技術、言語、技術を適用する機会を探します。 +- それぞれのプロジェクトで、小さいものの、何かを学び、教えるようにしてください。 -Finally, if possible, measure the impact of your work in terms of something that will be personally motivating. For example, when fixing bugs, counting the number of bugs that I have fixed is not at all motivational to me, because it is independent of the number that may still exist, and it also affects the total value I'm adding to my company's customers in only the smallest possible way. Relating each bug to a happy customer, however, *is* personally motivating to me. +最後に、可能であれば、自分の仕事の影響を、個人的に動機付けられるものとして測定します。たとえば、バグを修正するとき、私が修正したバグの数をカウントすることは、それがまだ存在するかもしれない数とは無関係であり、私の会社可能な限り小さな方法でお客様に提供します。しかし、それぞれのバグを幸せな顧客に結び付けることは、私の個人的な動機です。 Next [How to be Widely Trusted](02-How to be Widely Trusted.md) diff --git a/jp/2-Intermediate/Personal-Skills/02-How to be Widely Trusted.md b/jp/2-Intermediate/Personal-Skills/02-How to be Widely Trusted.md index c115d4e..4bbcf5e 100644 --- a/jp/2-Intermediate/Personal-Skills/02-How to be Widely Trusted.md +++ b/jp/2-Intermediate/Personal-Skills/02-How to be Widely Trusted.md @@ -1,7 +1,7 @@ # How to be Widely Trusted [//]: # (Version:1.0.0) -To be trusted you must be trustworthy. You must also be visible. If no one knows about you, no trust will be invested in you. With those close to you, such as your teammates, this should not be an issue. You establish trust by being responsive and informative to those outside your department or team. Occasionally someone will abuse this trust, and ask for unreasonable favours. Don't be afraid of this, just explain what you would have to give up doing to perform the favour. +あなたが信頼されるためには、信頼できるものでなければなりません。 あなたも見える必要があります。 誰もあなたについて知っていなければ、あなたには信頼は投資されません。 あなたのチームメイトのような、あなたに近い人たちと、これは問題ではありません。 あなたは、あなたの部署やチーム外の人に敏感で有益であることによって信頼を確立します。 時々、誰かがこの信用を乱用し、不当な恩恵を求めることがあります。 これを恐れてはいけません。好意を遂行するためにあなたがしなければならないことを説明してください。 -Don't pretend to know something that you don't. With people that are not teammates, you may have to make a clear distinction between 'not knowing right off the top of my head' and 'not being able to figure it out, ever.' +あなたがしないことを知っているふりをしないでください。 チームメートではない人たちには、「私の頭の上から右に分からない」と「それを決めることができない」との明確な区別をしなければならないかもしれません。 Next [How to Tradeoff Time vs. Space](03-How to Tradeoff Time vs Space.md) diff --git a/jp/2-Intermediate/Personal-Skills/03-How to Tradeoff Time vs Space.md b/jp/2-Intermediate/Personal-Skills/03-How to Tradeoff Time vs Space.md index e58a029..08e64fb 100644 --- a/jp/2-Intermediate/Personal-Skills/03-How to Tradeoff Time vs Space.md +++ b/jp/2-Intermediate/Personal-Skills/03-How to Tradeoff Time vs Space.md @@ -1,15 +1,15 @@ # How to Tradeoff Time vs. Space [//]: # (Version:1.0.0) -You can be a good programmer without going to college, but you can't be a good intermediate programmer without knowing basic computational complexity theory. You don't need to know 'big O' notation, but I personally think you should be able to understand the difference between 'constant-time','n log n' and 'n squared'. You might be able to intuit how to trade-off time against space without this knowledge, but in its absence you will not have a firm basis for communicating with your colleagues. +あなたは大学に行かなくても良いプログラマーになることができますが、基本的な計算複雑性理論を知らなくても、優れた中間プログラマーになることはできません。あなたは 'big O'表記法を知る必要はありませんが、私は個人的には、 '一定時間'、 'n log n'と 'n squared'の違いを理解できなければならないと思います。この知識がなくても、時間と空間とのトレードオフの仕方を知ることができるかもしれませんが、不在の場合、同僚とのコミュニケーションのための確固たる基盤はありません。 -In designing or understanding an algorithm, the amount of time it takes to run is sometimes a function of the size of the input. When that is true, we can say an algorithm's worst/expected/best-case running time is 'n log n' if it is proportional to the size ($n$) times the logarithm of the size. The notation and way of speaking can be also be applied to the space taken up by a data structure. +アルゴリズムの設計または理解にあたっては、実行に要する時間は入力のサイズの関数であることがあります。それが真であるとき、アルゴリズムの最悪/予想/最良ケースの実行時間は、サイズの対数（$ n $）に比例すると 'n log n'と言うことができます。表記法および発声法は、データ構造によって占められる空間にも適用することができる。 -To me, computational complexity theory is beautiful and as profound as physics - and a little bit goes a long way! +私にとって、計算の複雑さの理論は美しく、物理学ほど深く、そして少しは遠くに行くのです！ -Time (processor cycles) and space (memory) can be traded off against each other. Engineering is about compromise, and this is a fine example. It is not always systematic. In general, however, one can save space by encoding things more tightly, at the expense of more computation time when you have to decode them. You can save time by caching, that is, spending space to store a local copy of something, at the expense of having to maintain the consistency of the cache. You can sometimes save time by maintaining more information in a data structure. This usually costs a small amount of space, but may complicate the algorithm. +時間（プロセッサー・サイクル）とスペース（メモリー）はお互いにトレードオフできます。エンジニアリングは妥協であり、これは良い例です。必ずしも体系的ではありません。しかし、一般的には、デコードする必要があるときに計算時間を犠牲にして、より厳密にエンコードすることでスペースを節約できます。キャッシュの一貫性を維持しなければならないため、キャッシュすることで時間を節約することができます。つまり、何かのローカルコピーを格納するためのスペースを費やすことができます。データ構造内でより多くの情報を保持することによって、時間を節約することができます。これは通常、わずかなスペースしか必要としませんが、アルゴリズムが複雑になる可能性があります。 -Improving the space/time trade-off can often change one or the other dramatically. However, before you work on this you should ask yourself if what you are improving is really the thing that needs the most improvement. It's fun to work on an algorithm, but you can't let that blind you to the cold hard fact that improving something that is not a problem will not make any noticeable difference and will create a test burden. +空間/時間のトレードオフを改善することは、しばしば一方または他方を劇的に変えることができる。しかし、これに取り組む前に、あなたが改善しているものが、本当に最も改善が必要なものなのか、自分自身に尋ねてください。アルゴリズムで作業するのは楽しいですが、問題ではないものを改善することで目立った違いはなく、テストの負担をかけることはありません。 -Memory on modern computers appears cheap, because unlike processor time, you can't see it being used until you hit the wall; but then failure is catastrophic. There are also other hidden costs to using memory, such as your effect on other programs that must be resident, and the time to allocate and deallocate it. Consider this carefully before you trade away space to gain speed. +現代のコンピュータのメモリは、プロセッサ時間とは異なり、壁に衝突するまで使用されていないため、安価に見えます。失敗は壊滅的です。常駐しなければならない他のプログラムへの影響や、割り当てや割り当てを解除する時間など、メモリを使用するための隠されたコストもあります。スピードを上げるためにスペースを取り除く前に、これを慎重に検討してください。 Next [How to Stress Test](04-How to Stress Test.md) diff --git a/jp/2-Intermediate/Personal-Skills/04-How to Stress Test.md b/jp/2-Intermediate/Personal-Skills/04-How to Stress Test.md index 30c4418..5af320a 100644 --- a/jp/2-Intermediate/Personal-Skills/04-How to Stress Test.md +++ b/jp/2-Intermediate/Personal-Skills/04-How to Stress Test.md @@ -1,14 +1,14 @@ # How to Stress Test [//]: # (Version:1.0.0) -Stress testing is fun. At first it appears that the purpose of stress testing is to find out if the system works under a load. In reality, it is common that the system does work under a load but fails to work in some way when the load is heavy enough. I call this *hitting the wall* or *bonking*[1]. There may be some exceptions, but there is almost always a 窶wall窶. The purpose of stress testing is to figure out where the wall is, and then figure out how to move the wall further out. +ストレステストは楽しいです。最初は、ストレステストの目的は、システムが負荷の下で動作するかどうかを調べることです。実際には、システムが負荷の下で動作するのは一般的ですが、負荷が十分に重い場合は何らかの方法で動作しません。私はこれを壁*または*ボンキング* [1] に当てています。いくつかの例外があるかもしれませんが、ほとんど常に「壁」があります。ストレステストの目的は、壁がどこにあるかを把握し、壁をさらに遠ざける方法を理解することです。 -A plan for stress testing should be developed early in the project, because it often helps to clarify exactly what is expected. Is two seconds for a web page request a miserable failure or a smashing success? Is 500 concurrent users enough? That, of course, depends, but one must know the answer when designing the system that answers the request. The stress test needs to model reality well enough to be useful. It isn't really possible to simulate 500 erratic and unpredictable humans using a system concurrently very easily, but one can at least create 500 simulations and try to model some part of what they might do. +ストレステストの計画は、期待されることを正確に明確にするのに役立つことが多いので、プロジェクトの早い時期に開発する必要があります。 Webページ要求が悲惨な失敗か成功したのは2秒ですか？ 500人の同時ユーザーが十分ですか？それはもちろん、依存していますが、要求に答えるシステムを設計するときは答えを知る必要があります。ストレステストは、実用性を十分に発揮できるようにモデル化する必要があります。 500人の不安定で予測不能な人間をシステムを使って同時に簡単にシミュレートすることは実際には可能ではありませんが、少なくとも500のシミュレーションを作成し、それらが行う可能性のある部分をモデリングしようとします。 -In stress testing, start out with a light load and load the system along some dimension - such as input rate or input size - until you hit the wall. If the wall is too close to satisfy your needs, figure out which resource is the bottleneck (there is usually a dominant one.) Is it memory, processor, I/O, network bandwidth, or data contention? Then figure out how you can move the wall. Note that moving the wall, that is, increasing the maximum load the system can handle, might not help or might actually hurt the performance of a lightly loaded system. Usually performance under heavy load is more important than performance under a light load. +ストレステストでは、軽負荷で始動し、壁に当たるまで、入力速度や入力サイズなどの寸法に沿ってシステムをロードします。メモリ、プロセッサ、I / O、ネットワーク帯域幅、またはデータの競合は、壁があなたのニーズを満たすには近すぎる場合は、ボトルネックとなるリソース（通常は支配的なもの）を把握してください。次に、壁を動かす方法を見つけます。ウォールを動かす、つまりシステムが処理できる最大負荷を増やすことは、負荷の軽いシステムのパフォーマンスを低下させたり、実際に害する可能性があります。通常、負荷が軽い場合のパフォーマンスは、負荷が重い場合のパフォーマンスよりも重要です。 -You may have to get visibility into several different dimensions to build up a mental model of it; no single technique is sufficient. For instance, logging often gives a good idea of the wall-clock time between two events in the system, but unless carefully constructed, doesn't give visibility into memory utilization or even data structure size. Similarly, in a modern system, a number of computers and many software systems may be cooperating. Particularly when you are hitting the wall (that is, the performance is non-linear in the size of the input) these other software systems may be a bottleneck. Visibility into these systems, even if only measuring the processor load on all participating machines, can be very helpful. +あなたはそれの精神的モデルを構築するために、いくつかの異なる次元を可視化しなければならないかもしれません。単一の技術で十分ではない。たとえば、ロギングでは、システム内の2つのイベント間のウォールクロック時間をよく知ることがありますが、慎重に構築しない限り、メモリ使用率やデータ構造サイズの可視性はありません。同様に、最新のシステムでは、多くのコンピュータと多くのソフトウェアシステムが協力している可能性があります。特に、壁に当たったとき（つまり、入力の大きさに応じてパフォーマンスが非直線的である）、これらの他のソフトウェアシステムはボトルネックになる可能性があります。参加しているすべてのマシンのプロセッサ負荷を測定するだけであっても、これらのシステムの可視性は非常に役立ちます。 -Knowing where the wall is is essential not only to moving the wall, but also to providing predictability so that the business can be managed effectively. +壁がどこにあるかを知ることは、壁を動かすだけでなく、予測可能性を提供してビジネスを効率的に管理できるようにするためにも不可欠です。 --- diff --git a/jp/2-Intermediate/Personal-Skills/05-How to Balance Brevity and Abstraction.md b/jp/2-Intermediate/Personal-Skills/05-How to Balance Brevity and Abstraction.md index e7112b0..e99a0ad 100644 --- a/jp/2-Intermediate/Personal-Skills/05-How to Balance Brevity and Abstraction.md +++ b/jp/2-Intermediate/Personal-Skills/05-How to Balance Brevity and Abstraction.md @@ -1,9 +1,9 @@ # How to Balance Brevity and Abstraction [//]: # (Version:1.0.0) -Abstraction is key to programming. You should carefully choose how abstract you need to be. Beginning programmers in their enthusiasm often create more abstraction than is really useful. One sign of this is if you create classes that don't really contain any code and don't really do anything except serve to abstract something. The attraction of this is understandable but the value of code brevity must be measured against the value of abstraction. Occasionally, one sees a mistake made by enthusiastic idealists: at the start of the project a lot of classes are defined that seem wonderfully abstract and one may speculate that they will handle every eventuality that may arise. As the project progresses and fatigue sets in, the code itself becomes messy. Function bodies become longer than they should be. The empty classes are a burden to document that is ignored when under pressure. The final result would have been better if the energy spent on abstraction had been spent on keeping things short and simple. This is a form of *speculative programming*. I strongly recommend the article ['Succinctness is Power' by Paul Graham](http://www.paulgraham.com/power.html). +抽象化はプログラミングにとって重要です。あなたはどのように抽象的である必要があるかを慎重に選択する必要があります。プログラマーの熱意は、しばしば本当に有用なものよりも抽象度を高めます。これを示す一つの兆候は、実際にコードを含まないクラスを作成し、抽象的なものを提供する以外は何もしないクラスを作成する場合です。これの魅力は理解できますが、コードの簡潔さの価値は抽象化の価値に対して測定されなければなりません。時折、熱狂的な理想主義者が間違いを犯したことがあります。プロジェクトの開始時には、抽象的に思える多くのクラスが定義され、発生する可能性のあるすべての事態を処理すると推測します。プロジェクトが進行し、疲労が入り込むにつれて、コード自体が乱雑になります。関数本体は、必要以上に長くなります。空のクラスは、文書化の負担であり、プレッシャー下では無視されます。抽象化に費やされたエネルギーが、物事を短く簡単に保つために費やされたなら、最終的な結果はより良いものになりました。これは投機的プログラミング*の一形態です。私は、[Paul Grahamによる[ 'Succinctness is Power'（http://www.paulgraham.com/power.html）の記事を強くお勧めします。 -There is a certain dogma associated with useful techniques such as *information hiding* and *object oriented programming* that are sometimes taken too far. These techniques let one code abstractly and anticipate change. I personally think, however, that you should not produce much speculative code. For example, it is an accepted style to hide an integer variable on an object behind mutators and accessors, so that the variable itself is not exposed, only the little interface to it. This does allow the implementation of that variable to be changed without affecting the calling code, and is perhaps appropriate to a library writer who must publish a very stable API. But I don't think the benefit of this outweighs the cost of the wordiness of it when my team owns the calling code and hence can recode the caller as easily as the called. Four or five extra lines of code is a heavy price to pay for this speculative benefit. +*情報隠蔽*やオブジェクト指向プログラミング*などの便利なテクニックに関連したドグマがあります。これらの技術は、1つのコードを抽象的なものにし、変化を予期する。私は個人的には、多くの投機的なコードを生成すべきではないと思います。たとえば、変数自体がエクスポーズされないように、ミュータラとアクセサの背後にあるオブジェクトの整数変数を非表示にして、それに対する小さなインターフェースだけを受け入れるスタイルは容認されています。これにより、呼び出しコードに影響を与えずにその変数の実装を変更することができ、非常に安定したAPIを公開しなければならないライブラリライターにとってはおそらく適切です。しかし私は、私のチームがコーリングコードを所有しているので、呼び出し元を簡単にコーラーと同じように再コーディングすることができるので、これの利点がその言語のコストを上回るとは思わない。 4つまたは5つの余分なコード行は、この投機的な利益のために支払うための重い代償です。 -Portability poses a similar problem. Should code be portable to a different computer, compiler, software system or platform, or simply easily ported? I think a non-portable, short-and-easily-ported piece of code is better than a long portable one. It is relatively easy and certainly a good idea to confine non-portable code to designated areas, such as a class that makes database queries that are specific to a given DBMS. +移植性にも同様の問題があります。コードを別のコンピュータ、コンパイラ、ソフトウェアシステム、またはプラットフォームに移植するか、簡単に移植する必要がありますか？ポータブルではない、短くて簡単に移植できるコードは、長い移植可能なコードよりも優れていると思います。特定のDBMSに固有のデータベースクエリを作成するクラスなど、ポータブルでないコードを指定された領域に限定することは比較的簡単であり、確かに良い考えです。 Next [How to Learn New Skills](06-How to Learn New Skills.md) diff --git a/jp/2-Intermediate/Personal-Skills/06-How to Learn New Skills.md b/jp/2-Intermediate/Personal-Skills/06-How to Learn New Skills.md index d025b46..04d828d 100644 --- a/jp/2-Intermediate/Personal-Skills/06-How to Learn New Skills.md +++ b/jp/2-Intermediate/Personal-Skills/06-How to Learn New Skills.md @@ -1,13 +1,13 @@ # How to Learn New Skills [//]: # (Version:1.0.0) -Learning new skills, especially non-technical ones, is the greatest fun of all. Most companies would have better morale if they understood how much this motivates programmers. +新しいスキル、特に非技術スキルを学ぶことは、すべての人の最大の楽しみです。ほとんどの企業は、これがプログラマーのモチベーションをどのくらい理解するかによって、より良い士気を得ることができます。 -Humans learn by doing. Book-reading and class-taking are useful. But could you have any respect for a programmer who had never written a program? To learn any skill, you have to put yourself in a forgiving position where you can exercise that skill. When learning a new programming language, try to do a small project in it before you have to do a large project. When learning to manage a software project, try to manage a small one first. +人間はやって学ぶ。ブックリーディングとクラス授業は便利です。しかし、あなたはプログラムを書いたことのないプログラマーを尊敬することができますか？スキルを学ぶためには、そのスキルを発揮できる寛容な位置に自分自身を置かなければなりません。新しいプログラミング言語を学ぶときは、大きなプロジェクトを行う前に小さなプロジェクトを実行してみてください。ソフトウェアプロジェクトを管理する方法を学ぶときは、まず小さなものを管理してください。 -A good mentor is no replacement for doing things yourself, but is a lot better than a book. What can you offer a potential mentor in exchange for their knowledge? At a minimum, you should offer to study hard so their time won't be wasted. +良い指導者は、自分でやることに代わるものではありませんが、本よりはるかに優れています。彼らの知識と引き換えに、潜在的なメンターをあなたに提供することはできますか？最低でも、勉強して時間を無駄にしないように奨励するべきです。 -Try to get your boss to let you have formal training, but understand that it is often not much better than the same amount of time spent simply playing with the new skill you want to learn. It is, however, easier to ask for training than playtime in our imperfect world, even though a lot of formal training is just sleeping through lectures waiting for the dinner party. +あなたの上司に正式な訓練をさせてもらうようにしてください。しかし、あなたが学びたい新しいスキルで遊んでいるのと同じくらい多くの時間はそれほど良くないと理解しています。しかし、不完全な世界では、演劇よりもトレーニングを求めるのが簡単です。正式なトレーニングの多くは、夕食会を待っている講義を通して寝ているだけです。 -If you lead people, understand how they learn and assist them by assigning them projects that are the right size and that exercise skills they are interested in. Don't forget that the most important skills for a programmer are not the technical ones. Give your people a chance to play and practice courage, honesty, and communication. +あなたが人を導く場合、彼らが興味を持っている適切な規模のプロジェクトを割り当てることによって、彼らがどのように学び、援助するかを理解する。プログラマーにとって最も重要なスキルは技術的なものではないことを忘れないでください。あなたの人々に、勇気、正直さ、コミュニケーションをして練習する機会を与えましょう。 Next [Learn to Type](07-Learn to Type.md) diff --git a/jp/2-Intermediate/Personal-Skills/07-Learn to Type.md b/jp/2-Intermediate/Personal-Skills/07-Learn to Type.md index c678ddd..de0269e 100644 --- a/jp/2-Intermediate/Personal-Skills/07-Learn to Type.md +++ b/jp/2-Intermediate/Personal-Skills/07-Learn to Type.md @@ -1,5 +1,5 @@ # Learn to Type [//]: # (Version:1.0.0) -Learn to touch-type. This is an intermediate skill because writing code is so hard that the speed at which you can type is irrelevant and can't put much of a dent in the time it takes to write code, no matter how good you are. However, by the time you are an intermediate programmer you will probably spend a lot of time writing natural language to your colleagues and others. This is a fun test of your commitment; it takes dedicated time that is not much fun to learn something like that. Legend has it that when Michael Tiemann was at MCC people would stand outside his door to listen to the hum generated by his keystrokes which were so rapid as to be indistinguishable. +タッチタイプを学ぶ。 これは中級のスキルです。コードを書くことは非常に難しく、入力する速度が無関係で、コードの書き方に時間がかからないようにすることができます。 しかし、中間プログラマーであれば、おそらくあなたの同僚や他人に自然言語を書くのに多くの時間を費やすでしょう。 これはあなたのコミットメントの楽しいテストです。 そのようなことを学ぶのはあまり面白くない専用の時間がかかります。 伝説によれば、Michael TiemannがMCCにいたとき、人は、彼のキーストロークによって生成されたハム音を聞くためにドアの外に立つことになりました。 Next [How to Do Integration Testing](08-How to Do Integration Testing.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Personal-Skills/08-How to Do Integration Testing.md b/jp/2-Intermediate/Personal-Skills/08-How to Do Integration Testing.md index 2e111a0..aaaa6e1 100644 --- a/jp/2-Intermediate/Personal-Skills/08-How to Do Integration Testing.md +++ b/jp/2-Intermediate/Personal-Skills/08-How to Do Integration Testing.md @@ -1,7 +1,7 @@ # How to Do Integration Testing [//]: # (Version:1.0.0) -Integration testing is the testing of the integration of various components that have been unit tested. Integration is expensive and it comes out in the testing. You must include time for this in your estimates and your schedule. +統合テストは、単体テストされたさまざまなコンポーネントの統合テストです。 統合は高価であり、テストで出てくる。 あなたの見積もりとあなたのスケジュールにこれの時間を含める必要があります。 -Ideally you should organize a project so that there is not a phase at the end where integration must explicitly take place. It is far better to gradually integrate things as they are completed over the course of the project. If it is unavoidable estimate it carefully. +理想的には、統合を明示的に行う必要があるフェーズが最終段階にないようにプロジェクトを編成するのが理想的です。 プロジェクトの過程で完成したものを段階的に統合する方がはるかに優れています。 やむを得ない場合は注意深く見積もってください。 Next [Communication Languages](09-Communication Languages.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Personal-Skills/09-Communication Languages.md b/jp/2-Intermediate/Personal-Skills/09-Communication Languages.md index 8d39438..0ea3a3b 100644 --- a/jp/2-Intermediate/Personal-Skills/09-Communication Languages.md +++ b/jp/2-Intermediate/Personal-Skills/09-Communication Languages.md @@ -1,11 +1,11 @@ # Communication Languages [//]: # (Version:1.0.0) -There are some languages, that is, formally defined syntactic systems, that are not programming languages but *communication languages* - they are designed specifically to facilitate communication through standardization. In 2003 the most important of these are UML, XML, and SQL. You should have some familiarity with all of these so that you can communicate well and decide when to use them. +プログラミング言語ではなく、通信言語*である形式的に定義された構文システムのいくつかの言語があります。これらは、標準化を通じたコミュニケーションを容易にするように特別に設計されています。 2003年には、これらの中で最も重要なのがUML、XML、SQLです。あなたはよくコミュニケーションし、いつ使うべきかを決めるために、これらすべてに精通している必要があります。 -UML is a rich formal system for making drawings that describe designs. Its beauty lies in that it is both visual and formal, capable of conveying a great deal of information if both the author and the audience know UML. You need to know about it because designs are sometimes communicated in it. There are very helpful tools for making UML drawings that look very professional. In a lot of cases UML is too formal, and I find myself using a simpler *boxes and arrows* style for design drawings. But I'm fairly sure UML is at least as good for you as studying Latin. +UMLは、設計を記述する図面を作成するための豊かな正式なシステムです。その美しさは、それがビジュアルでもフォーマルでもあり、作者と読者の両方がUMLを知っていれば、大量の情報を伝えることができます。あなたはそれについて知る必要があります。なぜなら、その中でデザインが伝えられることがあるからです。非常に専門的に見えるUML図面を作成するための非常に有用なツールがあります。多くの場合、UMLは正式なものであり、設計図面にはより単純な*ボックスと矢印*スタイルを使用しています。しかし、私は、UMLが少なくともラテン語を勉強するのにぴったりであると確信しています。 -XML is a standard for defining new standards. It is not a solution to data interchange problems, though you sometimes see it presented as if it was. Rather, it is a welcome automation of the most boring part of data interchange, namely, structuring the representation into a linear sequence and parsing back into a structure. It provides some nice type- and correctness-checking, though again only a fraction of what you are likely to need in practice. +XMLは新しい標準を定義するための標準です。データ交換の問題の解決策ではありませんが、まるでそれが存在するかのように表示されることがあります。むしろ、データ交換の最も退屈な部分の自動化、すなわち表現を線形シーケンスに構造化し、構造に構文解析することを歓迎する自動化です。実際に必要と思われるもののほんの一部であるにもかかわらず、いくつかのタイプチェックと正しさチェックがあります。 -SQL is a very powerful and rich data query and manipulation language that is not quite a programming language. It has many variations, typically quite product-dependent, which are less important than the standardized core. SQL is the *lingua franca* of relational databases. You may or may not work in any field that can benefit from an understanding of relational databases, but you should have a basic understanding of them and the syntax and meaning of SQL. +SQLは、プログラミング言語ではない非常に強力で豊富なデータクエリおよび操作言語です。標準化されたコアよりも重要ではない、多くのバリエーション（通常は製品依存）があります。 SQLは、リレーショナルデータベースの* lingua franca *です。リレーショナル・データベースの理解の恩恵を受ける可能性のある分野で作業する場合もあれば、作業しない場合もありますが、SQLの構文と意味については基本的に理解しておく必要があります。 Next [Heavy Tools](10-Heavy Tools.md) diff --git a/jp/2-Intermediate/Personal-Skills/10-Heavy Tools.md b/jp/2-Intermediate/Personal-Skills/10-Heavy Tools.md index d5fcb55..59ed429 100644 --- a/jp/2-Intermediate/Personal-Skills/10-Heavy Tools.md +++ b/jp/2-Intermediate/Personal-Skills/10-Heavy Tools.md @@ -1,14 +1,14 @@ # Heavy Tools [//]: # (Version:1.0.0) -As our technological culture progresses, software technology moves from inconceivable, to research, to new products, to standardized products, to widely available and inexpensive products. These heavy tools can pull great loads, but can be intimidating and require a large investment in understanding. The intermediate programmer has to know how to manage them and when they should be used or considered. +私たちの技術文化が進むにつれて、ソフトウェア技術は、想像もできないものから、研究、新製品、標準化された製品、広く普及した安価な製品に移行しています。 これらの重い工具は大きな負荷をかけることがありますが、威圧することがあり、理解に大きな投資を必要とします。 中間プログラマーは、それらを管理する方法と、それらをいつ使用すべきか、または考慮すべきかを知る必要があります。 -To my mind right now some of the best heavy tools are: +今私の心には、最も重いツールのいくつかがあります： -- Relational Databases, -- Full-text Search Engines, -- Math libraries, -- OpenGL, -- XML parsers, and -- Spreadsheets. +- リレーショナルデータベース、 +- 全文検索エンジン、 +- 数学ライブラリー、 +- OpenGL、 +- XMLパーサー、 +- スプレッドシート。 Next [How to analyze data](11-How to analyze data.md) diff --git a/jp/2-Intermediate/Personal-Skills/11-How to analyze data.md b/jp/2-Intermediate/Personal-Skills/11-How to analyze data.md index dccc36a..c53bed6 100644 --- a/jp/2-Intermediate/Personal-Skills/11-How to analyze data.md +++ b/jp/2-Intermediate/Personal-Skills/11-How to analyze data.md @@ -1,11 +1,11 @@ # How to analyze data [//]: # (Version:1.0.0) -Data analysis is a process in the early stages of software development, when you examine a business activity and find the requirements to convert it into a software application. This is a formal definition, which may lead you to believe that data analysis is an action that you should better leave to the systems analysts, while you, the programmer, should focus on coding what somebody else has designed. If we follow strictly the software engineering paradigm, it may be correct. Experienced programmers become designers and the sharpest designers become business analysts, thus being entitled to think about all the data requirements and give you a well defined task to carry out. This is not entirely accurate, because data is the core value of every programming activity. Whatever you do in your programs, you are either moving around or modifying data. The business analyst is analysing the needs in a larger scale, and the software designer is further squeezing such scale so that, when the problem lands on your desk, it seems that all you need to do is to apply clever algorithms and start moving existing data. +データ分析は、ソフトウェア開発の初期段階のプロセスで、ビジネスアクティビティを調べ、それをソフトウェアアプリケーションに変換するための要件を見つけ出すプロセスです。これは正式な定義であり、データ分析はシステムアナリストに任せておくべき行動であると信じるかもしれませんが、プログラマーは誰かが設計したものをコーディングすることに焦点を当てるべきです。厳密にソフトウェアエンジニアリングのパラダイムに従えば、正しいかもしれません。経験豊富なプログラマーがデザイナーになり、鋭いデザイナーがビジネスアナリストになり、すべてのデータ要件について考えることができ、明確なタスクを実行することができます。これは、データがすべてのプログラミング活動の中核となるため、完全には正確ではありません。あなたのプログラムで何をしても、あなたは移動しているか、データを変更しています。ビジネスアナリストはニーズをより大規模に分析しています。ソフトウェアデザイナーは、このような規模をさらに絞り込んで、問題があなたの机の上に着くと、巧妙なアルゴリズムを適用して既存のデータを移動するだけです。 -Not so. +そうではありません。 -No matter at which stage you start looking at it, data is the main concern of a well designed application. If you look closely at how a business analyst gets the requirements out of the customer's requests, you'll realize that data plays a fundamental role. The analyst creates so called Data Flow Diagrams, where all data sources are identified and the flow of information is shaped. Having clearly defined which data should be part of the system, the designer will shape up the data sources, in terms of database relations, data exchange protocols, and file formats, so that the task is ready to be passed down to the programmer. However, the process is not over yet, because you (the programmer) even after this thorough process of data refinement, are required to analyze data to perform the task in the best possible way. The bottom line of your task is the core message of Niklaus Wirth, the father of several languages. "Algorithms + Data Structures = Programs." There is never an algorithm standing alone, doing something to itself. Every algorithm is supposed to do something to at least one piece of data. +どの段階で見ても、データはうまく設計されたアプリケーションの主な関心事です。ビジネスアナリストが顧客の要求からどのように要件を取得しているかを詳しく見れば、データが基本的な役割を果たすことがわかります。アナリストはいわゆるデータフローダイアグラムを作成し、すべてのデータソースが識別され、情報フローが形成されます。どのデータをシステムの一部にするかを明確にした上で、データベース関係、データ交換プロトコル、およびファイル形式の観点から、設計者はデータソースを整形してプログラマに渡す準備が整います。しかし、プロセスはまだ終わっていません。この徹底したデータ洗練プロセスの後であっても（プログラマ）、可能な限り最良の方法でデータを分析する必要があるからです。あなたの仕事の最終行は、いくつかの言語の父であるNiklaus Wirthの中核メッセージです。 "アルゴリズム+データ構造=プログラム"単独でアルゴリズムを立てることは決してありません。すべてのアルゴリズムは、少なくとも1つのデータに対して何かを行うことになっています。 -Therefore, since algorithms don't spin their wheels in a vacuum, you need to analyze both the data that somebody else has identified for you and the data that is necessary to write down your code. A trivial example will make the matter clearer. You are implementing a search routine for a library. According to your specifications, the user can select books by a combination of genre, author, title, publisher, printing year, and number of pages. The ultimate goal of your routine is to produce a legal SQL statement to search the back-end database. Based on these requirements, you have several choices: check each control in turn, using a "switch" statement, or several "if" ones; make an array of data controls, checking each element to see if it is set; create (or use) an abstract control object from which to inherit all your specific controls, and connect them to an event-driven engine. If your requirements include also tuning up the query performance, by making sure that the items are checked in a specific order, you may consider using a tree of components to build your SQL statement. As you can see, the choice of the algorithm depends on the data you decide to use, or to create. Such decisions can make all the difference between an efficient algorithm and a disastrous one. However, efficiency is not the only concern. You may use a dozen named variables in your code and make it as efficient as it can ever be. But such a piece of code might not be easily maintainable. Perhaps choosing an appropriate container for your variables could keep the same speed and in addition allow your colleagues to understand the code better when they look at it next year. Furthermore, choosing a well defined data structure may allow them to extend the functionality of your code without rewriting it. In the long run, your choices of data determines how long your code will survive after you are finished with it. Let me give you another example, just some more food for thought. Let's suppose that your task is to find all the words in a dictionary with more than three anagrams, where an anagram must be another word in the same dictionary. If you think of it as a computational task, you will end up with an endless effort, trying to work out all the combinations of each word and then comparing it to the other words in the list. However, if you analyze the data at hand, you'll realize that each word may be represented by a record containing the word itself and a sorted array of its letters as ID. Armed with such knowledge, finding anagrams means just sorting the list on the additional field and picking up the ones that share the same ID. The brute force algorithm may take several days to run, while the smart one is just a matter of a few seconds. Remember this example the next time you are facing an intractable problem. +したがって、アルゴリズムは真空で車輪を回転させないので、他人があなたのために特定したデータとコードを書き留めるのに必要なデータの両方を分析する必要があります。簡単な例では、問題がより明確になります。ライブラリの検索ルーチンを実装しています。あなたの仕様によると、ユーザーはジャンル、著者、タイトル、出版社、印刷年、ページ数の組み合わせで書籍を選択できます。ルーチンの最終的な目標は、バックエンド・データベースを検索するための正当なSQL文を生成することです。これらの要件に基づいて、いくつかの選択肢があります。「switch」ステートメント、または複数の「if」ステートメントを使用して、各コントロールを順番にチェックします。データコントロールの配列を作成し、各要素が設定されているかどうかチェックします。すべての特定のコントロールを継承する抽象コントロールオブジェクトを作成（または使用）し、それらをイベントドリブンエンジンに接続します。要件に特定の順序で項目がチェックされていることを確認して、クエリのパフォーマンスをチューニングすることも必要な場合は、コンポーネントのツリーを使用してSQL文を作成することを検討することができます。ご覧のとおり、アルゴリズムの選択は、使用する、または作成するデータによって異なります。このような決定は、効率的なアルゴリズムと悲惨なアルゴリズムとの間のすべての違いを生じさせる可能性がある。しかし、効率だけが懸念事項ではありません。あなたは、あなたのコードに名前付きの変数を12個使用し、これまでどおり効率的にすることができます。しかし、そのようなコードは簡単に保守できないかもしれません。おそらく、変数の適切なコンテナを選択することで同じスピードを保つことができ、さらに、来年には、同僚がコードをよりよく理解できるようになります。さらに、明確に定義されたデータ構造を選択することで、コードの書き換えを行わずにコードの機能を拡張することができます。長期的には、データの選択によって、コードの終了後にコードが存続する期間が決まります。もう一つの例を挙げてみましょう。思考のための食べ物はもう少しあります。アナグラムが同じ辞書内の別の単語でなければならない、3つ以上のアナグラムを持つ辞書のすべての単語を見つけることがあなたの仕事であるとしましょう。それを計算の仕事と考えるならば、あなたは無限の努力に終わり、各単語のすべての組み合わせを試して、それをリストの他の単語と比較しようとします。しかし、手元のデータを分析すると、単語そのものとその文字のソートされた配列をIDとして含むレコードで各単語を表すことができます。そのような知識を身につけて、アナグラムを見つけることは、追加のフィールドでリストをソートし、同じIDを共有するものを選ぶことを意味します。ブルートフォースアルゴリズムは、実行に数日かかることがありますが、スマートなアルゴリズムはほんの数秒です。難しい問題に直面しているこの例を覚えておいてください。 Next [Team Skills - How to Manage Development Time](../Team-Skills/01-How to Manage Development Time.md) diff --git a/jp/2-Intermediate/Team-Skills/01-How to Manage Development Time.md b/jp/2-Intermediate/Team-Skills/01-How to Manage Development Time.md index 94d473e..292aa28 100644 --- a/jp/2-Intermediate/Team-Skills/01-How to Manage Development Time.md +++ b/jp/2-Intermediate/Team-Skills/01-How to Manage Development Time.md @@ -1,11 +1,11 @@ # How to Manage Development Time [//]: # (Version:1.0.0) -To manage development time, maintain a concise and up-to-date project plan. A project plan is an estimate, a schedule, a set of milestones for marking progress, and an assignment of your team or your own time to each task on the estimate. It should also include other things you have to remember to do, such as meeting with the quality assurance people, preparing documentation, or ordering equipment. If you are on a team, the project plan should be a consensual agreement, both at the start and as you go. +開発時間を管理するために、簡潔で最新のプロジェクト計画を維持する。プロジェクト計画とは、見積もり、スケジュール、進行状況を示すマイルストーン、見積りの各タスクへの自分のチームまたは自分の時間の割り当てです。品質保証担当者との面談、ドキュメンテーションの準備、機器の注文など、忘れてはならないこともあります。チームに参加している場合、プロジェクトの計画は、開始時と終了時の両方で合意した合意でなければなりません。 -The project plan exists to help make decisions, not to show how organized you are. If the project plan is either too long or not up-to-date, it will be useless for making decisions. In reality, these decisions are about individual persons. The plan and your judgement let you decide if you should shift tasks from one person to another. The milestones mark your progress. If you use a fancy project planning tool, do not be seduced into creating a Big Design Up Front (BDUF) for the project, but use it to maintain concision and up-to-dateness. +プロジェクト計画は、あなたがどのように組織化されているかを示すのではなく、意思決定を支援するために存在します。プロジェクト計画が長すぎるか最新でない場合、意思決定には役に立たないでしょう。実際には、これらの決定は個人に関するものです。計画とあなたの判断は、仕事をある人から別の人に移すべきかどうかを決定させます。マイルストーンはあなたの進歩を示します。ファンシーなプロジェクト計画ツールを使用している場合は、プロジェクトのBig Design Up Front（BDUF）を作成するのに惑わされるのではなく、それを使用して簡潔で最新の状態を維持します。 -If you miss a milestone, you should take immediate action such as informing your boss that the scheduled completion of that project has slipped by that amount. The estimate and schedule could never have been perfect to begin with; this creates the illusion that you might be able to make up the days you missed in the latter part of the project. You might. But it is just as likely that you have underestimated that part as that you have overestimated it. Therefore the scheduled completion of the project has already slipped, whether you like it or not. +マイルストーンが欠けている場合は、上司にそのプロジェクトの予定完了がその金額だけ紛失したことを知らせるなど、すぐに行動する必要があります。見積もりとスケジュールは、決して完璧なものではなかったかもしれません。これは、あなたがプロジェクトの後半で欠席した日を補うことができるという錯覚を作り出します。そうかもしれない。しかし、あなたがそれを過大評価しているということをあなたが過小評価している可能性もあります。したがって、あなたが好きか否かにかかわらず、計画されたプロジェクトの完了はすでにスリップしています。 -Make sure your plan includes time for: internal team meetings, demos, documentation, scheduled periodic activities, integration testing, dealing with outsiders, sickness, vacations, maintenance of existing products, and maintenance of the development environment. The project plan can serve as a way to give outsiders or your boss a view into what you or your team is doing. For this reason it should be short and up-to-date. +内部チームミーティング、デモ、文書化、予定された定期的な活動、統合テスト、外部者との対処、病気、休暇、既存製品のメンテナンス、開発環境のメンテナンスなど、計画に時間が含まれていることを確認してください。プロジェクト計画は、あなたやあなたのチームがやっていることを外部者や上司に見せる方法として役立ちます。このため、短期間で最新のものにする必要があります。 Next [How to Manage Third-Party Software Risks](02-How to Manage Third-Party Software Risks.md) diff --git a/jp/2-Intermediate/Team-Skills/02-How to Manage Third-Party Software Risks.md b/jp/2-Intermediate/Team-Skills/02-How to Manage Third-Party Software Risks.md index 336f3e8..6bfa43b 100644 --- a/jp/2-Intermediate/Team-Skills/02-How to Manage Third-Party Software Risks.md +++ b/jp/2-Intermediate/Team-Skills/02-How to Manage Third-Party Software Risks.md @@ -1,11 +1,11 @@ # How to Manage Third-Party Software Risks [//]: # (Version:1.0.0) -A project often depends on software produced by organizations that it does not control. There are great risks associated with third party software that must be recognized by everyone involved. +プロジェクトはしばしば、管理していない組織によって作成されたソフトウェアに依存します。関係するすべての人が認識しなければならない第三者のソフトウェアには大きなリスクがあります。 -Never, ever, rest any hopes on *vapour*. Vapour is any alleged software that has been promised but is not yet available. This is the surest way to go out of business. It is unwise to be merely sceptical of a software company's promise to release a certain product with a certain feature at a certain date; it is far wiser to ignore it completely and forget you ever heard it. Never let it be written down in any documents used by your company. +決して、蒸気にどんな希望もしてはいけません。 Vaporは、約束されているがまだ利用可能ではないと主張されているソフトウェアのことです。これは最悪の方法です。特定の機能を備えた特定の製品を特定の日付にリリースするというソフトウェア企業の約束を単に懐疑的にするのは賢明ではない。それを完全に無視し、あなたがそれを聞いたことを忘れることはずっと賢明です。あなたの会社が使用している書類に書き留めてはいけません。 -If third-party software is not vapour, it is still risky, but at least it is a risk that can be tackled. If you are considering using third-party software, you should devote energy early on to evaluating it. People might not like to hear that it will take two weeks or two months to evaluate each of three products for suitability, but it has to be done as early as possible. The cost of integrating cannot be accurately estimated without a proper evaluation. +サードパーティのソフトウェアが枯渇していない場合でも、それはまだ危険ですが、少なくともそれは取り組むことができるリスクです。サードパーティのソフトウェアを使用することを検討している場合は、早期に評価して評価する必要があります。人々は、3つの製品のそれぞれについて適切性を評価するのに2週間か2か月かかると聞いていないかもしれませんが、可能な限り早く行う必要があります。適切な評価なしに、統合のコストを正確に推定することはできません。 -Understanding the suitability of existing third party software for a particular purpose is very tribal knowledge. It is very subjective and generally resides in experts. You can save a lot of time if you can find those experts. Often times a project will depend on a third-party software system so completely that if the integration fails the project will fail. Express risks like that clearly in writing in the schedule. Try to have a contingency plan, such as another system that can be used or the ability to write the functionality yourself if the risk can't be removed early. Never let a schedule depend on vapour. +特定の目的のための既存のサードパーティソフトウェアの適合性を理解することは、非常に部族的な知識です。それは非常に主観的で、一般に専門家に居住しています。それらの専門家を見つけることができれば、多くの時間を節約できます。多くの場合、プロジェクトはサードパーティのソフトウェアシステムに依存するため、統合が失敗するとプロジェクトは失敗します。そのようなリスクをスケジュールで書面で明確に表現してください。リスクを早期に除去できない場合は、使用可能な別のシステムや機能を自分で作成するなど、緊急時対応計画を立ててください。スケジュールは蒸気に依存しないようにしてください。 Next [How to Manage Consultants](03-How to Manage Consultants.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Team-Skills/03-How to Manage Consultants.md b/jp/2-Intermediate/Team-Skills/03-How to Manage Consultants.md index 6b632b9..8ef504a 100644 --- a/jp/2-Intermediate/Team-Skills/03-How to Manage Consultants.md +++ b/jp/2-Intermediate/Team-Skills/03-How to Manage Consultants.md @@ -1,9 +1,9 @@ # How to Manage Consultants [//]: # (Version:1.0.0) -Use consultants, but don't rely on them. They are wonderful people and deserve a great deal of respect. Since they get to see a lot of different projects, they often know more about specific technologies and even programming techniques than you will. The best way to use them is as educators in-house that can teach by example. +コンサルタントを使用しますが、それに頼らないでください。彼らはすばらしい人々であり、大いに尊敬されるべきです。彼らは多くの異なるプロジェクトを見ているので、特定のテクノロジやプログラミングテクニックについての知識が、あなたのものよりもしばしば分かります。それらを使用する最善の方法は、教師が社内で教えることができるようにすることです。 -However, they usually cannot become part of the team in the same sense that regular employees are, if only because you may not have enough time to learn their strengths and weaknesses. Their financial commitment is much lower. They can move more easily. They may have less to gain if the company does well. Some will be good, some will be average, and some will be bad, but hopefully your selection of consultants will not be as careful as your selection of employees, so you will get more bad ones. +しかし、通常の強みと弱みを学ぶのに十分な時間がないため、通常の従業員と同じ感覚でチームに参加することはできません。彼らの財政的コミットメントははるかに低いです。彼らはより簡単に動くことができます。会社がうまくいくなら、彼らの利益はあまり得られないかもしれません。いくつかは良い、いくつかは平均で、いくつかは悪いですが、あなたのコンサルタントの選択はあなたの従業員の選択ほど慎重ではないでしょう、あなたは悪いものを得るでしょう。 -If consultants are going to write code, you must review it carefully as you go along. You cannot get to the end of the a project with the risk of a large block of code that has not been reviewed. This is true of all team members, really, but you will usually have more knowledge of the team members closer to you. +コンサルタントがコードを書くつもりなら、それを慎重に検討しなければなりません。レビューされていない大きなコードブロックのリスクを伴うプロジェクトの最後には到達できません。これは実際にはすべてのチームメンバーに当てはまりますが、通常はあなたに近いチームメンバーの知識が増えます。 Next [How to Communicate the Right Amount](04-How to Communicate the Right Amount.md) \ No newline at end of file diff --git a/jp/2-Intermediate/Team-Skills/04-How to Communicate the Right Amount.md b/jp/2-Intermediate/Team-Skills/04-How to Communicate the Right Amount.md index 2e16157..e27e0c4 100644 --- a/jp/2-Intermediate/Team-Skills/04-How to Communicate the Right Amount.md +++ b/jp/2-Intermediate/Team-Skills/04-How to Communicate the Right Amount.md @@ -1,7 +1,7 @@ # How to Communicate the Right Amount [//]: # (Version:1.0.0) -Carefully consider the cost of a meeting; it costs *its duration multiplied by the number of participants*. Meetings are sometimes necessary, but smaller is usually better. The quality of communication in small meetings is better, and less time overall is wasted. If any one person is bored at a meeting take this as a sign that the meeting should be smaller. +慎重に会議費を考慮してください。 その期間に参加者の数を掛けた*費用がかかります。 会議が必要な場合もありますが、通常は小規模です。 小規模な会議でのコミュニケーションの質は向上し、全体的に無駄になる時間は少なくなります。 会議に誰かが退屈している場合は、会議を小さくするべきであるという兆候としてこれを取る。 -Everything possible should be done to encourage informal communication. More useful work is done during lunches with colleagues than during any other time. It is a shame that more companies do not recognize nor support this fact. +非公式のコミュニケーションを促進するためには、可能な限りのことが行われなければならない。 より便利な作業は、他の時間よりも同僚とのランチ中に行われます。 多くの企業がこの事実を認識したりサポートしていないことは残念です。 Next [How to Disagree Honestly and Get Away with It](05-How to Disagree Honestly and Get Away with It.md) diff --git a/jp/2-Intermediate/Team-Skills/05-How to Disagree Honestly and Get Away with It.md b/jp/2-Intermediate/Team-Skills/05-How to Disagree Honestly and Get Away with It.md index 7ced830..c2c882d 100644 --- a/jp/2-Intermediate/Team-Skills/05-How to Disagree Honestly and Get Away with It.md +++ b/jp/2-Intermediate/Team-Skills/05-How to Disagree Honestly and Get Away with It.md @@ -1,11 +1,11 @@ # How to Disagree Honestly and Get Away with It [//]: # (Version:1.0.0) -Disagreement is a great opportunity to make a good decision, but it should be handled delicately. Hopefully you feel that you have expressed your thoughts adequately and been heard before the decision is made. In that case there is nothing more to say, and you should decide whether you will stand behind the decision even though you disagree with it. If you can support this decision even though you disagree, say so. This shows how valuable you are because you are independent and are not a yes-man, but respectful of the decision and a team player. +意見の不一致は良い判断をする絶好の機会ですが、微妙に処理する必要があります。あなたが思考を適切に表現し、決定が下される前に聞いたと思うことを願っています。その場合は何も言うことはありません。あなたがそれに同意しなくても、あなたが決定の背後に立つかどうかを決めるべきです。あなたが同意しないにもかかわらずこの決定を支持することができれば、そう言いなさい。これは、あなたが独立しており、イエス・マンではなく、決定とチーム・プレーヤーを尊重しているため、あなたがどれほど貴重なのかを示しています。 -Sometimes a decision that you disagree with will be made when the decision makers did not have the full benefit of your opinion. You should then evaluate whether to raise the issue on the basis of the benefit to the company or tribe. If it is a small mistake in your opinion, it may not be worth reconsidering. If it is a large mistake in your opinion, then of course you must present an argument. +意思決定者があなたの意見を十分に生かせなかったときに、あなたが反対する決定を下すことがあります。その後、会社や部族の利益に基づいて問題を提起するかどうかを評価する必要があります。それがあなたの意見の小さな間違いであるなら、それは再考する価値がないかもしれません。あなたの意見に大きな間違いがある場合は、もちろん議論を提示する必要があります。 -Usually, this is not a problem. In some stressful circumstances and with some personality types this can lead to things being taken personally. For instance, some very good programmers lack the confidence needed to challenge a decision even when they have good reason to believe it is wrong. In the worst of circumstances the decision maker is insecure and takes it as a personal challenge to their authority. It is best to remember that in such circumstances people react with the reptilian part of their brains. You should present your argument in private, and try to show how new knowledge changes the basis on which the decision was made. +通常、これは問題ではありません。ストレスの多い状況では、いくつかのパーソナリティタイプでは、これは個人的なものにつながる可能性があります。たとえば、非常に優れたプログラマーのなかには、それが間違っていると信ずる正当な理由がある場合でも、意思決定に挑戦するために必要な自信がないものがあります。最悪の状況では、意思決定者は不安定であり、自らの権限に対する個人的な挑戦と見なす。このような状況では、人々は脳の爬虫類の部分に反応することを覚えておくことが最善です。あなたは議論を非公開で提示し、新しい知識がどのように決定が下されたかを示してみるべきです。 -Whether the decision is reversed or not, you must remember that you will never be able to say 窶露 told you so!窶 since the alternate decision was fully explored. +意思決定が逆転しているかどうかにかかわらず、代替決定が完全に調査されたので、あなたは「あなたにそう言った」と言うことは決してできないことを忘れないでください。 Next [Judgment - How to Tradeoff Quality Against Development Time](../Judgment/01-How to Tradeoff Quality Against Development Time.md)