Google Summer of Codeの真実-パート3

パート1

パート2

パート4



1.中間まで生き残る方法（中間評価の締め切り）



夏の半ばには、Googleへの非常に重要なレポートがあります。 あなたがそれを放棄した場合、あなたはあなたのお金を受け取ります;そうでなければ、飛び出します。 レポート自体は簡単です-アンケートに記入し、メンターがアンケートに記入します。 メンターがあなたに満足している場合、すなわち 彼はアンケートに記入しました-そうでなければ、あなたは大金を得ます-そして彼らはあなたに別れを告げます。







中間試験に合格するための主な基準は、タイムラインに約束のコードを提供することです。 コードなし-お金なし。 公式には、Googleは何をどのように行うのかについては関心がありません。主なことは、コミュニティが幸せであることです。 コミュニティが幸せであれば、Googleも幸せです。 そのため、報告書を遵守するには、コミュニティを幸せにする必要があります。



コミュニティを幸せにするために、 定期的に報告してください （「民主主義」という言葉を忘れないでください）。 誰もあなたにニュースレターで報告することを禁じていない場合-そこに報告書を送ってください。 ブログの場合は、ブログの完全な記事へのリンクを記載した短いレポートをニュースレターに送信してください。 コミュニティは、メンターだけでなく、あなたが働いていることも認識することが重要です。 ブログにアクセスするのを忘れるかもしれませんが、全員がメールをチェックします。



他の開発者とチャットします。 時々、あなたが得ることができる最大の助けはあなたのメンターからではなく、コミュニティの他のメンバーからです。 そのため、ある学生には問題があり、ニュースレターで報告しました。 彼のメンターは、彼が現在の結果に失望していると答え、ハローワールドコードが機能しなかった理由を知りませんでした。 しかし、残りの開発者は問題に対処して解決策を見つけるために多くの努力をしました。 スレッドの最後のメンターは、アドバイスに従うことのみを許可しました。



クリーンなコードのみをコミットします。 メンターは、各生徒がコミットすることをめったに見ません。 通常、コードとレポートを持っているという事実で十分です（ただし、私の友人が何らかの形ですべてのコミットを確認するメンターに出会ったのですが、これはバイオロボットであると判断しました）。 しかし、これは特定の時間までです。 メンターは自由な一日を過ごし、最終的にあなたのコードをテストすることにしました。そして今朝あなたは夜仕事をしました（そう、最も素晴らしいコードは夜に書かれています）。 そのため、結果にコミュニティを満足させるのではなく、すべての作業に疑問を抱きます。 そして、これが悪名高い中間期の前に起こった場合、メンターがあなたに成績を与える準備ができているとき-二重に良くありません。 そのため、ごみ箱のどこかに自分で作成し、ブランチを作業コード用に残します。



問題がある場合、または期限に間に合わない場合は、できるだけ早く報告する必要があります。すべての開発者が支援するように、リストに送信することをお勧めします。 あなたのメンターとコミュニティは、あなたが最初の日からすぐに輝いて引きずり始めることを期待していません（いいえ、彼らは確かに望みますが、彼らはこれが起こらないことを理解しています）。



ブルドーザーからタイムラインを作成した場合は、実行可能な計画を作成できるようになり次第、それを実行してメンターにコピーを送信します。 そのため、彼は開発プロセスを管理しやすくなります。 ほとんどの場合、メンターはまさにそのような質問をします：「あなたはあなたの計画に従って何をしましたか、そしてあなたは今何をしていますか？」



開発の初期段階で小さな部品の詳細な研究に従事しないでください。 すべての顧客は同じように考えます-最初は誰もがスケルトンを見たいと思っています。 中期までに、磨き上げられたいくつかの機能ではなく、実用的なプロトタイプを提供する必要があります。 「todo」カメラで穴をマークし、さらに開発を続けます。



2.中期的に生き残るには？



このイベントの開始の2週間前に、メンターがあなたの仕事に満足しているかどうか、そして彼が中期的にどのような結果を期待しているかを尋ねてください。



あなたが非常にうまく働いて、あなたの計画を厳密に守ったとしても、それはあなたのメンターが彼の頭の中で中間結果について彼自身の考えを持っていないという意味ではありません。 たぶん彼は、いくつかの部分は間違いなく機能すると考えており、あなたはレポートの後でのみそれをテストすることを計画しました。 違いは1週間のようなものですが、ある場合には動作するコードがあり、別の場合にはそこにあります。 テレパシーは最悪のコミュニケーション手段です。 そのため、すべてを事前に明確にすることをお勧めします。 中間期の前の週、あなたは間違いなくその答えを知っているべきです。



ニュースレターでプロジェクトについてあまり説明していない場合は、今すぐ説明しましょう。 開発の過程で、特にプロジェクトが研究であり、1か月中1つのタスクだけでハンマーをかけたり、非常に複雑な1つの小さな機能をコーディングしたりする場合、説明することはありません。 レポートの前半で自慢できることがなかった場合は、これまでのすべてをペイントし、テスト結果と次の開発手順の説明を追加できます。 覚えておいてください-「民主主義」、「幸せ」。



いずれにせよ、あなたがどこまで来たかを示すために、中期前にダーティコードをコミットしません。 わずか1、2週間で、開発者は結果に興味を持つようになります。 また、ドラフトバージョンがシステム全体を厳密に配置している場合、あまり良くありません。 同じ理由で、テストを無視しないでください-コードは監視されず、テストされます。



3.プロジェクトとレポートの加速。



中間期の2、3週間前のどこかで、プロジェクトはオーバークロックしています。 つまり コミットごとに、より多くのコードと機能が追加されます。 しかし、あなたの作品はまだ通常のテストに合格することができません。そのため、あなたとあなただけが、テーブルの上に粘土の断片だけではなく、水差しが迫っているのを見ることができます。



残念ながら、メンターはテレパシーの賜物を奪われているため、彼らはあなたの水差しを見ません。 彼らは、粘土が増加したこと、そして大幅に増加したことだけを見ています。 そのような瞬間、彼らはわずかなパニックを起こし、そこから2つの方法で出てきます-あなた自身のコードを分析するか、メガレポートを書くように頼みます。 コード分​​析-スクリプトはほとんど素晴らしいので、カウントしないでください。 ほとんどの場合、メガレポートを作成する必要があります。このレポートでは、メンターが水差しを見るか、彼がそこにいることを証明します。



ダーティーハック2。



もちろん、レポートはコミュニティを幸せにしますが、これは初期段階に過ぎません。 そして、誰もがすばらしい作業コードを見たいと思っています。あなたの仕事は、このコードを彼らに提供することです。



しかし、コードをコーディングしてからテストを実行すると、何か間違ったことをして、非常に大きな部分をさらに開発または処理する必要があることがわかりました。 そして、ちょうどあなたのメンターがコードを見てそれをテストしたいのです。 良い生徒は、メンターがそのようなことを見てすべてを書き直し始めるのは良いことではないと考えますが、賢い人はそのままコミットします。



第一に、どういうわけかあなたのコードはまだ機能します。そして、それがいくつかのテストに合格するという事実はあなたを少し満足させました。 また、これらの結果はあなたのメンターを喜ばせることができます。なぜなら、彼は何かがうまくいくのを見て、それがうまくいくと信じているからです。 第二に、あなたのプロジェクト全体が作品で構成されています（4年目にはそのようなテーマがありましたが、当時はこの哲学がどういうわけか好きではありませんでした）。 それらのいくつかは重要であり、連続して実行する必要があり、いくつかは時間的にシフトすることができます。 重要なものの1つをやり直す必要があり、レポートが近いことがわかったら、作業コードをそのままにして、他の作業に集中します。 そのため、あなたとレポートは、レポートの後に重要な部分を完成させるために時間を費やします。 第三に、ドラッグせずにコードが正常に機能しない場合（またはさらに悪い場合）、メンターはあなたをまったく信じないかもしれません。 まあ、彼はあなたが本当に働いており、彼に嘘をついていないことをどのように知っていますか？ コミットしますが、スマートな方法で。



他の学生があなたと協力します。 あなたの目の隅から、彼らの進歩を見て、彼らより悪くならないようにしてください。 メンターは、生徒が最も弱いリンクであるという事実に満足しません。 そして、すべての生徒が平等ではないことを覚えておいてください。 すでにコミュニティに参加している学生がおり、コミュニティが必要とする場合は、少なくともプログラム全体で調査を実施できます。 しかし、これはあなたができるという意味ではありません。



生徒に問題があり、それを解決する方法を知っている場合、すでに似たような問題に遭遇しているので、生徒を助けてください。 第一に、人を助け、第二に、社交性を+1します。



トリッキーなレポートを送信するように求められても、彼らがあなたから何を望んでいるのか理解できない場合は、少なくとも何かをしてください。 長い間黙って言うよりも、コメントからテキストの壁を取得して10倍後に書き直した方がよいでしょう。



黄金律。



ロシアの専門学校はテレパシーが大好きです。 大学で一晩中Googleで検索したり、Runetのすべてのテクニカルフォーラムでトピックを作成する方が、教師に行って自分が何も考えていないことを馬鹿にしていることに耳を傾けるよりも簡単な場合、これは実行されません。 助けが必要かどうか、メンターに尋ねてください。 最後に、彼らは飼いならされた人に責任があります。



4.メンターの使用方法



ソースへの参照として。



5.対立。



競合の事実は、Googleとコミュニティの両方のすべての人に認識されています。 私は思う、なぜなら コーディングの夏は最初の年には行われません。その後、状況を分析するためのメカニズムがすでに開発されています。



あなたが持っている場合：

1.実用的なプロトタイプ

2.定期報告を行った

3. 5月末にコードのコミットを開始しました

4.あなたの計画に従った



とにかくメンターがあなたに満足していない場合は、コミュニティに連絡してください。 メンターが開発に不満を持っている場合、他の開発者もあなたの結果を気に入らないという意味ではありません。 「賛成」する人の数は「反対」よりも多いと思われます。 コミュニティにGSoC全体を担当する人がいる場合は、あなたの将来について明確にするために彼に連絡してください。 コミュニティに耳が聞こえない場合は、Googleに連絡してください。 しかし、学生のせいではなくても、コミュニティが不幸な場合にGoogleがどのように動作するかは、Googleだけが知っています。 Google自身は、エンジニアにこの状況を分析する準備ができていると言っています。 つまり 前置詞、タイムライン、およびコードに従って、コミュニティまたはあなたのどちらが正しいかを決定します。 そして、この決定は最終的なものです。

これは、あなたが動作するコードを持っていて、すべてのルールを守っており、誰もがあなたに不満を抱いている状況だと思いますが、それは現実よりもむしろ素晴らしいです。



Googleの学生と協力するためのガイドラインに従っている場合、次の場合は学生に別れを告げるべきです。

1.中期的に約束されたコードはありません

2.学生はあまり社交的ではなく、彼とさらに仕事をすることは難しい

3.学生がプロジェクトを完了するという完全な確実性はありません。

4.学生はコミュニティの期待に応えていません



6.失敗したプロジェクト。



成功するプロジェクトは、3つのバランスの取れたパラメーターで構成されます：期限、予算、リソース。 予算とリソースがあれば、ここですべてが明確になります。学生だけが納得できない期限があります。 最も失敗するプロジェクトは次のとおりです。



a）最初から開発の複雑さを評価できない場合の研究。

どのようにすべてが始まりますか？

研究プロジェクトの最大の問題は、研究を無限に実行できることであり、どこで停止する必要があるのか​​がわからない場合があります。 最初は、学生はゆっくりと熱心にさまざまな記事、書籍を読み、ソースを詳しく調べますが、コードの時間になり、研究を続けます。 リターンのないポイント-これはコーディングを開始する1週間前です-この時点で、「hello world」プログラムの作成を開始し、読まないようにするとよいでしょう。 学生はニュースレターにリンクと疑念のあるテキストの壁を書きますが、メンターはすでに不透明で、少なくとも何かを選択してコーディングを開始する時が来たことを暗示しています。 学生はすべてを読み、読みます。

どうする

研究プロジェクトに参加しないでください。 しかし、それが本当に間違っている場合、または特に招待されている場合は、読み終えてスケジュールどおりにコーディングを開始するための厳しい締め切りを設定してください。 後で多くの変更を行う必要がある場合でも、コードに基づいてすでに心理的にそれを行うことは、遅れて開始するよりも簡単になり、メンターは落ち着きます。



b）初期段階で複雑なアーキテクチャまたはAPIの設計が必要なプロジェクト。

どのようにすべてが始まりますか？

生徒は1つのバージョンを作成します。その後、開発のある段階で、放棄する必要があることを理解します。 コードは完全に書き直されているため、2、3回繰り返されます。 ここでは珍しいことは何もありません-通常の開発プロセスであり、誰もがすぐに拡張可能な理想的なソリューションを見つけることができるわけではありません。 少し経験。

どうする

ロールバックの時間があるように、できるだけ早く開発を開始してください。 まあ、それらを実装する前に、すべてのアーキテクチャ上の決定を注意深く考えてみてください。 困難な状況では、特にコーディング時間が始まっており、まだ有効な選択肢がない場合は、メンターと相談してください。



c）コミュニティ自体による開発の目標が明確に設定されていないプロジェクト。 たとえば、プロジェクトのアイデアが最初に「このような未知のゴミがあり、同じものが欲しいが、それが何なのかわからない」というスタイルで説明されていた場合、開発のある段階で、あなたが少しやっていることがわかる可能性がありますあなたに期待されること。

どのようにすべてが始まりますか？

プロジェクトのオーバークロック後、コードが最初のテストに合格し始めたとき、学生は結果がわずかに異なるはずであることを突然知ります。 次に、プロジェクトと遅延の詳細な分析が開始されます。

どうする

毎週、できればタスクを処理している5月に詳細なレポートを作成してください。 開発の初期段階ですべての誤解をつかむか、中期直前にコミュニティの開発の有用性を再検討する必要があります。



d）非現実的なプロジェクト、すなわち 3か月以上実装するのに時間がかかるプロジェクト、または開発者の要件が高すぎる（「私たちは教祖が必要」と書いていますが、学生はこれについてだと考えています）。

どのようにすべてが始まりますか？

生徒はスケジュールに沿ってコーディングを開始し、次々と締め切りに間に合わないことに気付きます。 コードは作成されているようですが、バックログは成長し続けています。 処理をコンパイルする段階では見えなかった落とし穴がますます発見されています。

どうする

そのようなプロジェクトを行わないでください。 組織が健全であれば、8月までに現実的な結果に同意するようにしてください。 さもなければ、あなたはただ飛び出します、なぜなら コミュニティの期待に達しませんでした。 友達に連絡できます。 私は、あなたが一人で働いても誰かがあなたを助けても組織は気にしないと思います、主なことはコードがそこにあるということです。



7.彼らは私を追い出しますか？



しかし、それはコミュニティの経験に依存します。 以前の生徒の態度は、メンターの意識に消えない痕跡を残しています。 1回目または2回目に参加する「若い」コミュニティがあります。 彼らは怠け者の生徒に出会っていないので、最後まであなたを信じることができます。



不可抗力。



多くの場合、プログラム中に予期しない状況が発生します。 病気になったり、家族に問題が発生したり、重大な事故に見舞われたりします。何があっても関係ありませんが、締め切りに間に合わなくなります。 もちろん、延期やシフトについてメンターに同意することはできますが、契約はすべて途中でキャンセルされます。 つまり、中期的には、コードはそこにあるかどうかです。 完了した作業に対して支払われます。完了した作業が合意された作業よりもはるかに少ない場合、支払われません。 すべてがシンプルで、犯罪はありません。朝のお金で-夜の椅子で、夜のお金で-朝の椅子で。



組織がプロジェクトに失敗するのはなぜですか？



はい、何もありませんが、それは起こりました。 コミュニティが最近関与しており、学生との連携方法がまだわからないか、彼らが何ができるかわからないか、メンターが自分で判断します。 。 また、コミュニティで失敗したプロジェクトがなく、進行中であることが判明する場合があります。 複雑さを増し、学生は引きずってしまいます。 しかし、今回は正確に-彼らはドラッグしませんでした。 または、あるメンターでクレイジーなアイデアが生まれ、多様性のためにリストに追加された後、学生が見つかりました。 もちろん、組織はアイデアのリストに責任を負っており、どのアイデアも3か月で実装できることを保証しているように見えますが、頭を抱えて考えることもできます。 あなたはそれを疑います-プロジェクトを引き受けないでください、おそらく引きずられるであろう別の学生があるでしょう。