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

パート1

パート2

パート3



1.最終報告書（最終評価期限）を守る方法



一方で、ここではすべてがシンプルです-ただ働き続けるだけです。 一方、中期以降の期間は以前よりも複雑ではありません。 最初に、初期段階で大きな穴を残した場合は、それらを修正します。 以前にいくつかのバグがあなたを許していたなら、あなたのメンターはあなたのコードが毎日より良く動作することを期待しています。







第二に、この段階で最初に作成した設計エラーが発生する可能性があります。 機能を拡張する可能性を見ていない（または意図的に省略した）場合は、「骨の上に肉を植える」段階になりました。 そして、これらの骨が不適切に設計されている場合、肉を吊ることができなくなります。 まあ、アーキテクチャを少し調整する必要がある場合、または1つまたは2つの松葉杖とうまくやる必要があるが、アーキテクチャが元々間違っていた場合は、機能をカットするかすべてをやり直してください。 つまり 最終レポートで失敗する可能性があります。



正確に何をすべきかは、特定のケースに依存します。 1つでは、一部の機能の損失はほとんど認識できませんが、もう1つでは、リファクタリングが簡単になります。 どこか下手な松葉杖でできるようになります。 また、あなたがどのように設計したかは非常に重要です-単独で、またはメンターと共に 間違ったアーキテクチャが共同作業の成果である場合、それと一緒に何をすべきかを決定し、おそらく、最終報告に失敗しないようにするためにコミュニティがどの改善を行う必要があるかを決定します。 しかし、メンターに耳を傾け、自分のやり方ですべてをやった場合、これはすでにあなたの失敗です。 さらに、デザインだけでなく、コミュニケーションスキルも必要です。 この場合、彼らはあなたと働き続けることはまずありません。



休暇に行く方法は？



ほとんどの学生は、中間期後に短い休暇を取ります。 報告週中のいくつか。 しかし、メンターも含め、誰もが休暇に出かけます。



組織は通常、学生が休暇を計画するときに質問します。 あなたが尋ねられず、休暇を計画しているなら、正直に彼らにそれを認めてください。



休暇を正しく過ごすには、いくつかの主要なタスクを完了してみてください。 まず、リラックスしやすくなります。 第二に、休暇中は少しリラックスできるので、すでに動作しているコードで作業するのが少し楽になります。



コーディング期間中に卒業証書を書いたり、セッションに合格した場合、つまり 実際にはあなたのプロジェクトに対処しませんでした-それはあなたの休暇でした。 休暇は、個人的に休む時間ではなく、プロジェクトに取り組んでいない時間です。



何らかの理由で休暇を隠す必要がある場合は、この期間中にドキュメントのテストまたは作成を行ってください。 休暇中に仕事をしているかのように、休暇中にいくつかの作業を事前に行い、コミットしておくといいでしょう。 開発には浮き沈みの瞬間があるので、1週間の活動のわずかな減少は疑いを引き起こしません。



2.最終報告書を生き残るにはどうすればいいですか？



元気でフィニッシュラインに進む準備ができたら、ちょっとした驚きを期待できます。 メンターは、コードに対して1001の希望を持っているかもしれません。 あなたにとって、あなたはすべてをうまくやったようで、最終的なコードの準備ができています。 あなたの指導者の側で-あなたはお金を受け取った直後にとらえどころのないジョーになることができ、その図を終了します。 したがって、あなたのコミュニティは、さらなる開発なしで機能するコードを取得しようとします。 そして、このコードを書いた開発者がまだいるので、お金を得る前に開発を終わらせようとします。 これが、過去2週間で行うことです。 そのため、8月に何も計画することはできません。メンターの新しい要件を事前に知ることはできません。ところで、彼はその時点でもその要件を知りませんでしたが、今では彼に気付きました。



鉛筆を下ろします。



西洋の世界では、「鉛筆を下ろす」とは「鉛筆を下ろす」ことを意味します。 X日以降は何もコミットしません。プログラムには2つの期限があります-ソフトと最終です。 ソフトの後も、コミットして追加できます。 正直に言うと、組織は、ソフトな締め切りを「奴隷として働く、太陽はまだ高い」の締め切りだとは考えていません。 つまり ソフト期限の開始後、組織は要件の別のリストを提出する可能性があります。 しかし、最終期限はすでに完全に最終です。 公式には、GoogleはX日以降にコミットしたコードには関心がありません。 最後の期限にコミットしたコードをGoogleに提供するだけです。 そして、ここから少しzapadloが始まります-メンターが評価期間でのみコードをテストするように設計し、何かを修正する必要がある場合の対処方法。 ここでは、Googleのルールを読む必要があります。 この質問は学生から頻繁に聞かれ、期限後にコミットできるようですが、このコードをアーカイブに含めるべきではありません。 READMEファイルに「追加」コードを記述し、リンクをスローします。 ただし、評価期間の開始前にすべてを完了し、メンターにテストを依頼して、Googleの推奨事項へのリンクを提供することをお勧めします。



評価期間で肯定的な結果を受け取った後にのみ、コードを送信します。 アーカイブの作成には2週間または3週間が与えられます。 コードの送信が早ければ早いほど、Googleは2番目のパッケージをより早く送信します。



ダーティーハック3。



7月中旬のレポートで、深刻な問題があることを書くのを止めてください。 非常にトリッキーなテストまたはコードの詳細な分析でのみホールを検出できる場合、それらについては黙ってください。そうでない場合は、期限に間に合わないでください。 それでも火傷した場合は、フェルトブーツのふりをして、良いテストをしてくれたメンターに感謝します。 しかし、そうでない場合は、さらに作業を続けます。 時間があります-やり直し、いや-最終報告の後に終了します。



楽観的なレポートを作成します。 怪我をする方法に関するテキストは、バグや問題の説明以上のものである必要があります。



3.新鮮な血液。



このプログラムの公式目標は、コミュニティに新鮮な血をもたらすことです。 つまり あなたのコミュニティは眠り、あなたが彼らと一緒にいて、コーディングされ、コーディングされていることを確認します。 郵便のアンケートでは、もちろん、プログラムの終了後でもコードを書くと書いていますが、実際に学生が留まることはめったにありません。 しかし、無駄に。 コミュニティと連絡を取り続けると、来年の参加が保証されます。 だから、もしあなたがすべてが好きなら-彼らと一緒に仕事を続けてください。



4.良いGoogleは他に何を送ってくれますか？



プロジェクトを正常に完了したTシャツ、A4段ボール、すべてがそうです。 大規模なコミュニティは、中期終了後または仕事の終わりに、生徒に特別な贈り物を送ります。 まさにコミュニティが送信するものは、このようなチップのような大きな驚きです。



5.神話。



私たちは皆平等です：

メンタリティが重要です。 すべて同じ、異なる文化、異なる教育システムが彼らの仕事をします。 西洋の学生はそれほど複雑ではなく、より多くの質問をし、コミュニケーションを恐れません。



より多くのルール、より多くの問題：

組織内のルールが多いほど良い。 私の最後の組織には、コード内のスペースの数からコミットのサイズまで、一連のルールがありました。 さらに、メンターは、候補者がパッチを投稿した選択の段階でデザインのチェックを開始しました。 私の意見では、スタイルを「微調整」して何かを作り直す必要があることを知るのは、夏の真ん中（または最後）よりも良いと思います。



失敗したプロジェクトは成人期のみです：

プロジェクトを正常に完了したとしても、リリースされることを期待しないでください。 すべての学生の作品が後で使用されるわけではありません。



1つのprozalで渡さない：

奇妙なことに、私は1つの提案書で、なんとか通り抜けることができました。 しかし、ここには別の哲学がありました。将来のプロジェクトにパッチやコードを作成することはできないため、プログラムで作業することはまったくできません。



作業とGSoCを組み合わせることは不可能です。

大学院の最後の年に彼の若さを思い出すことにした私の友人は、丸一日働いてGSoCを無事に完了することができました。 彼は休暇に出かけ、転職し、別の都市に移りました。 私はそのようなマゾヒズムに従事することを強く勧めるのではなく、誰もが自分の最大の制限を持っているだけです。



インド人が愚か者であることは誰もが知っています。

プログラムに参加することで得られる奨学金は、インドではかなりまともなお金です。 当然、この国からの学生はプログラムに参加するためにかなりの熱意を示します。 そして、彼らと競争することは非常に困難です。 残りの生徒たちはパッチのルールやその他のコーディングに激怒しているが、インド人は静かにコミットしている。 プログラムに参加しない場合、コミットします。 そして、1年後に彼らが再び問題を解決するとき、彼らは連れて行かれます。

はい、彼らのコードは必ずしも美しく最適ではありませんが、私の学生の研究室は専門家の仕事のようではありません。 そして、あなたは違いを見ることができないとき、なぜ自慢しますか？



コードの主なもの：

時々、主なものはトリネデットであるように思えます。 コミュニティで試してみて、100行の機能を勇気を持ってコーディングしたか、コミュニティにとってプロジェクトがどれほど重要かを伝えるほど、それは「幸せ」になります。

ある学生は、自分の仕事で十分かどうか、また中間期を通過するかどうかをコミュニティに尋ねました。 メンターの一人は、彼が仕事に満足していると書いた。 学生のブログで、プロジェクトがコミュニティにもたらすメリットについて読んでいます。 確かに、彼は後でコードを見ていないと付け加えました。



女の子にとっては簡単です：

そうは思いません チーム全体が別の学生が自分の研究プロジェクトのコーディングを開始できるように逆立ちをしている間に、私の指導者からLinuxのソースコードを掘り下げてもらいました。 実際、プログラムでは誰もが平等であり、コミュニティは、より多くの助けを必要とする人やプロジェクトにもっと必要な人を助けます。 差別はありません。人種的、性的、言語的のいずれでもありません。



プログラムに入るのは難しいです：

コミュニティの最初からすべてのルールを順守し、コピーを真剣に書く（早めに投稿する、ソースと協力する、メンターとコミュニケーションする）ことをすれば、プログラムに簡単に参加できます。



プログラムに入るのは簡単です：

人気のないコミュニティでの競争（つまり、CやC ++などの人気のない言語でコーディングしたり、特定の数学の知識が必要な場合は聞いたことがない）。 人気のあるコミュニティへのアプリケーションの数は約100であるため、100人の中から注目され、選ばれるように一生懸命努力する必要があります。



私のメンターはすべてを知っています：

メンターは、プロジェクトのその部分だけを知っています。 もちろん、彼はあなたよりもはるかに多くの経験を持っていますが、彼でさえテレパシーのスキルはありません。 つまり あなたが彼にあなたの問題について話すとき、ほとんどの場合、彼は何も理解しないか、彼にもう一度すべてを説明するように頼むでしょうが、より詳細に。



コミュニティは私がやっていることを知っています：

プログラムの前に教育タスクのみで作業し、教師が混乱する場所を事前に知っていた場合、これはそうではありません。 自分だけが何をしているか、どのようにやっているか、どんな問題を抱えているかを知っているのはあなただけです。



問題がある場合は、メンターのみが問題について知る必要があります。

多くの学生が誤ってコミュニティから距離を置いています。 ただし、コーディングスタイル、ドキュメント、テスト、予備のメンターに関連する問題などの問題は、メンターではなくコミュニティ全体で対処するのが最適です。



すべての組織は、選択に関して同じルールに従います。

このようなルールはありますが、推奨事項はありませんが、コミュニティに独自の経験を放棄させることはありません。 組織にいくつかの失敗したプロジェクトがあり、学生は素晴らしいブレークスルーを持ちましたが、コードがなく、短いブレークスルーで成功したプロジェクトがありましたが、コードがあれば、次に組織はtryndetではなくコーディングできる学生を選択します。



私はこの分野で唯一の戦士です。

奇妙なことに、コミュニティでコーディングしているのはあなただけではありません。 関数Bをプルしない関数Aをコーディングしている限り、誰かがこの関数を書き換えることがあります。 マージを忘れないでください。 他の開発者は、バグを修正して新しいバグを作成できます。



すべては常にドキュメントに書かれています：

常にではありません。 時々、すべてのメンターが「コードを見てください」と言うことができます。 組織にドックがまったくない場合や、無料の文献ではあまり説明されていない標準に従ってコーディングしている場合や、すべてが適切に説明されている本が手に入らない場合があります。



2 * 2 = 4：

大学では、なぜそうでない可能性があるかを言うのではなく、いくつかのことが与えられたとしてあなたに説明されます。 簡単に言えば、ほとんどの学生は高度な知識が必要な状況に陥ることはありません。 GSoCでは、「標準」という概念が正しくないことがあります。



夏の間何をしたかは関係ありません。主なことは、レポートの前にドラッグすることです。

貴重なコードを投稿しても、メンターがすぐにそれを見るために急ぐということではありません。 おそらく彼はこれのための時間がないでしょう。 中期の直前に一人の学生が2000行のコードをコミットしました。実際、これが彼の最初のコミットでした。 彼のメンターは、中期の終わりまですべてをレビューしてテストする時間がないかもしれないと正直に言った。



私はメンターとのみ仕事をしています：

私のメンターは最初のテストを中期にのみ行った（またはおそらくまったくしなかった）前に、彼はコードを見ただけだった。 中間期の前に、別のメンターがテストを行いましたが、彼は私にいくつかのバグを見つけました。



私のメンターは官僚です。なぜなら、 定期的なレポートが必要です：

メンターは学生を追跡し、Googleはコミュニティを追跡します。 コミュニティがニュースレターまたはチャットで生徒と積極的にコミュニケーションをとる場合、来年はさらに多くのスロットを受け取ります。 そのため、「これらの愚かなレポート」は、Googleの要件の一部です。



さて、プロジェクトが卒業証書に関連付けられている場合：

しかし、これは必要ありません。 第一に、これは追加の心理的負担です。したがって、ほとんどの学生は防衛の卒業証書を嫌い、あなたは同様の何かを実装する義務があります。 第二に、私たちの科学コミュニティは、オープンソースコードに対して精神的に準備されていません。 私の大学はどこにでも無料のオフィスを設置していますが、彼はお金のために何かをするつもりはありません。 それで、あなたはそれをあなたの目に劇的に引きずり、貴重な科学的情報を大学の目で外国企業に売り、あなたの開発に対するすべての権利を大学から奪いました。 知的財産を盗みます。 そのため、プロジェクトを科学研究から遠ざけるか、悪用について黙ってください。



6.人生から。



私が最後に参加した組織はほとんど知られておらず、C言語で開発されています（現在は学生の間では人気がありません）。 参加の競争は1箇所あたり3〜4人で、すべての候補者はこの分野での開発経験がありました。 そのような経験はありませんでしたが、すでに同様の問題を解決しました。 コンテストを通過するために、私はすでに忍び寄る段階でプロジェクトの一部を書かなければなりませんでした。 メンターからの質問は2つだけで、1つ目はコード自体に関するもの、2つ目は実装段階の1つです。 投稿の前後に活発な議論はありませんでした。 さらに、このような郵便は私のプロジェクトから他の学生を怖がらせました。



私のクラスメートも同じことをしました。 移動中、彼はプロジェクト全体のコードの30％を提供し、最も複雑なバージョンを実装しました。 プロジェクトは正常に完了しましたが、そのような仕事の能力が、指導者を学生の能力について迷わせました。 翌年、彼らはタスクの複雑さを大幅に増やしましたが、すべての生徒がうまくいったわけではありません。



私のメンターは私の手紙すべてにすぐに答えました。 しかし、コードをテストするように依頼すると、1週間消えました。 別の学生の場合、彼の指導者は中間期の途中でのみコードをテストしましたが、時間内にすべての手紙に答えました。



部品の1つが欠落していました-プロジェクトの簡単な説明。 プログラムへの入場後、同じ説明が公開されます。 なぜなら プロジェクトコードは提供しませんでした。テキストを書く時間はあまりありませんでした。アイデアの説明をコミュニティのウェブサイトからコピーしただけです。



なぜなら 組織にはコードのスタイルに関する非常に厳しいルールがありました。スペースやマジックナンバーがないために受け取った最も深刻なコメントです。



GSoC向けに学生が生成するコードの量は、2〜5,000行のコードです。



私の組織では、生徒の一人がデザインに非常に大きな間違いを犯しました。 彼はこの瞬間についてメンターと話し合っていなかったため、すべてが中間期の前に現れました。 なぜなら すでに多くのコードがあり、機能を約束されたレベルに拡張することは物理的に不可能でした、メンター自身が要件を整えることを提案しました。



ある組織では、東ヨーロッパとロシアの学生がプログラムに参加しました。 すべての学生がコーディングし、週に1度メンターに手紙を書き、チャットしませんでした。 生徒は時間通りにコーディングしましたが、チャットしませんでした。 実際、すべてのメンターに負担をかけたのはこの事実でした。 数回、生徒たちは強制的にチャットに引きずり込まれましたが、会話は挨拶を超えて移動しませんでした。 プロジェクトは正常に完了し、組織はニュースレターを通じて参加ルールにコミュニケーションを追加し、チャットを拒否しました。



提案のアンケートでは、すべての学生がプログラムの終了後も密輸を続けると書いていますが、組織に残っている人はほとんどいません。 せいぜい、彼らは来年GSoCの学生として戻ってきます。



すべての学生は週40時間働くことを約束します。 実際には、労働時間が20時間を超えることはめったにありません。



すべての生徒は2つのタイプに分けられます-パッチルールを好む人もいれば、嫌いな人もいます。 すべての組織は2つのタイプに分けられます-いくつかは行方不明のアイテムとしてコードを望み、他は建設的な対話を望みます。



7.何を読む？



1. Google学生の推奨事項：

私はすべてに同意するとは言えません-仕事の多くの側面はコミュニティとプロジェクトに依存しています。 ただし、これらの推奨事項を必ずお読みください。



2. メンターに対するGoogleの推奨事項：

. , .



3. gimp:

, . .



4. :

. . .



5. Google , :

, GSoC, «» . , .



6. , :

, , . , , , , .