先日の投稿では42 Silicon valleyの2017年度Piscine資料を読み解いた。この資料は14日分の課題で構成されているのだが、Piscineは４週間開催される。残り２週間、あるいは14日の課題と並行して、志願者は複数のプロジェクトに参加する必要がある。参照資料に基づくならば、
- ３つの個人プロジェクト
- ３つのグループ・プロジェクト
- 最終プロジェクト
今回は、これらプロジェクトの資料を元に、印象的だった部分を紹介する。
ちなみに、ここで紹介する情報が東京校のPiscineに通用する保証はなく、内容の正しさを保証するものでもないことを申し添えておく。
関連サイトのハイパーリンクは投稿末尾にまとめている。
個人プロジェクト
例によって、資料には次の注意が記載されている。
• Only this page will serve as reference: do not trust rumors.
• Watch out! This document could potentially change up to an hour before submission.
• Using a forbidden function is considered cheating. Cheaters get -42, and this grade is non-negotiable.
課題同様、教えられていない関数の利用は禁止されている。プロジェクトだからと言って、使用可能な機能は変わらない。
実務経験者にとって、プロジェクトの突発的な仕様変更は常識的なアクシデントだろう。簡単なプロジェクトは早く終わらせて、別のことに取り掛かることを難しくする仕組みに思うのだが、そもそも、そのようなことは考慮されていないのかもしれない。それは次の項目から察することができる。
• These exercises are carefully laid out by order of difficulty - from easiest to hardest. We will not take into account a successfully completed harder exercise if an easier one is not perfectly functional.
プロジェクト課題は簡単なものから難しいものへ、難易度順に実施される。簡単なプロジェクト課題に失敗していたら、たとえ難しいプロジェクト課題が正解であったとしても、それは評価されないのだという。
そもそもプログラムが動作しなければ０点なのだが、それを次の課題で挽回することはできない仕掛けだ。
42らしい仕掛けが次の項目だ。Peer learningは個人プロジェクトにも適用されるようだ。クラスメートが検証、評価を担当するのだという。とはいえ、もちろん自動化された検証、評価システムも通過する必要がある。
• Your exercises will be checked and graded by your fellow classmates.
• On top of that, your exercises will be checked and graded by a program called Moulinette.
プロジェクト課題は難問、奇問の類ではなく、むしろ良問に類するものだ。教科書や参考書の章末に登場しそうな雰囲気の問題だ。
Day00～13の課題を一通り確認した限り、個人プロジェクトの難易度は課題とそれほど変わりがない。性質が異なるのは、課題が一つの問題、テーマにフォーカスしているのに対し、プロジェクト課題は、求められてる知識を包括的に組み合わせる必要があることだろう。
言い換えると、問われている課題をいくつかの機能、ロジックに分解して実装する必要があるということだ。
気になるのは、プロジェクト資料には実施期間、あるいは制限時間が記載されていないことだ。もし厳しい時間的制約が設けられているならば、そのプレッシャーがプロジェクトの難易度を上げるかもしれない。
課題、プロジェクトに通底していると感じるのは、評価するのはC言語への習熟ではなく、あくまでもロジックとその実装を評価する試みなのだろう、ということだ。使用言語は機能制限されたC言語とはいえ、それを使いこなすことが問われているのではなく、制約の範囲で何ができるか、要求を実装できるかが試されているように感じる。
グループ・プロジェクト
グループ・プロジェクトはRushと呼ばれている。慌ただしくさせられるに違いない仕掛けがあるのだろう。資料では「defense」という単語が多く含まれている。こんな感じだ。
• Each member of the group can register the whole group to defense.
• The group MUST be registered to defense.
• You must therefore do the project with the imposed team and show up at the defense slot you’ve selected, with all of your teammates.
• You project must be done by the time you get to defense. The purpose of defense is for you to present and explain any and all details of your work.
文脈から察するに、「defence」というのはグループ・プロジェクトに割り当てられたスケジュール期間のことを指しているようだ。defence期間中、グループ・メンバーはプロジェクトに専念しなければならないようだ。
そしてグループ・プロジェクトの「グループ」らしいポイントが次の項目だ。
you’ll be asked questions, and the final grade will be based on the worst explainations.
• It goes without saying, but gathering the group is your responsibility. ～＜中略＞～So don’t bother blurping up excuses. Life isn’t always fair, that’s just the way it is.
•However, if you’ve really tried everything one of your teammates remains unreachable : do the project anyway, and we’ll try and see what we can do about it during defense. Even if the group leader is missing, you still have access to the submission directory.
「you'll be asked questions」に続く項目は、グループ・プロジェクト内でのpeer learningを指しているのだろうか。評価は、そこで提供された最悪の説明で評価されるのだという。最高点ではなく最低点で評価されるのだ。
またプロジェクトからの脱落者も想定されているのだろう。メンバー、リーダーが不在でも課題は提出できるのだという。
Piscineは社会人生活と両立しようとする候補者も参加するようだ。defence期間中の対応については、自らの熱意だけで駆動するだけではなく、関与するメンバーに対する現実的な配慮が必要になるだろう。
グループ・プロジェクトはボーナス・ポイントの獲得機会でもあるようだが、これは挽回のための救済措置には見えない。あくまでもボーナスとして、余力のあるグループ、実力のあるメンバーが獲得できる、他者と差をつけるための仕掛けに見える。ボーナス課題はRushの最終課題資料に掲載されている。
• If you want bonus points, you may submit other subjects.
これまでの課題と異なり、課題の内容は詳細には語られていない。グループ・メンバーは課題を読み解くことから始めなければならない。例えばこんな感じだ。
rush(*, *) *には数字が入る。この出力結果が何パターンか与えられており、そのように出力するプログラムを作成するというものだ。呼び出しと出力結果からロジックを推察し、実装しなければならない。さらに課題の難易度が上がると、このようになる。
• Create a program that resolves a sudoku
「sudoku」とは数独（ナンプレ）のことだ。関心のある人は、是非GitHubの資料とコードを参照してほしい。
出題は大雑把で、触れられていない事柄がある。例えば
と言ったことだ。このようなことにどう対処すべきなのかには触れられていない。さらに、いやらしいのが次の一言だ。意地が悪すぎる。
• Any question concerning the subject would complicate the subject.
これは、余計なことを考えず言われたことに専念せよ、という意味と解釈すべきなのだろうか。だとすれば、やはり数独として不適なパズルを与えられたときはどうする？は考慮する必要があるだろうし、課題は複雑になるだろう。
あるいは、余計なことをを考えさえしなければ、課題は簡単なのだ、ということを示唆しているのだろうか。だとすると、暗黙に回答可能なパズルが与えられる前提で、ただ解くことだけを考慮したプログラムを作成することになるのだが、もし解けないパズルを与えられた時、プログラムはどのタイミングで正常終了するのだろうか？言葉通りならば、その対応は一切、無視することになる。
やはりパズルの事前評価は必要なのではないか、結果として課題は複雑になるのではないか、と私ならば思うところだが、他のメンバーはどのように考えるだろうか。
これは揉める。揉める仕掛けが意図的に盛り込まれている。とにかく「グループで」知恵を出し合って、解決しろということなのだろう。厳しい。
この数独を解くプログラムについては別の投稿で触れている。関心があれば参照してほしい。
42 SILICON VALLEY Piscine 2017 Rush01（前編） 「簡単な」数独を解くプログラム
42 SILICON VALLEY Piscine 2017 Rush01（後編） 「難しい」数独を解くプログラム
最終プロジェクト
最終プロジェクトが個人課題なのか、グループ課題なのかは明記されていないが、次の記述からグループ課題だろうと察した。
Only one group should get all 20 points. You’ll be graded depending on your BSQ’s rank compared to other BSQs.
評価点は、まず動作テストをクリアした時点で10点獲得。それをクリアしたプログラムにだけ、処理速度とメモリ消費の観点から、合計10点の加点評価が実施される。20点満点を得られるのは一グループだけの相対評価だ。
ただロジックを組み立てるだけでは最低限の要求であり、C言語について、特にポインタとループの習熟はここで問われることになる。Cへの習熟はあくまでも加点要素であり、それほど重視されていないのではないか、とも解釈できる。
出題はグループ課題と大差はないと感じた。参照している資料では、与えられたマップから最大の正方形を確保できる領域を識別表示することが求められている。正方形というのは見た目上の問題ではなく、縦、横の行列数が一致する領域を指している。こんな具合だ。
- 与えられたマップ
%>cat example_file 9.ox ........................... ....o...................... ............o.............. ........................... ....o...................... ...............o........... ........................... ......o..............o..... ..o.......o................
- 識別表示
%>./bsq example_file .....xxxxxxx............... ....oxxxxxxx............... .....xxxxxxxo.............. .....xxxxxxx............... ....oxxxxxxx............... .....xxxxxxx...o........... .....xxxxxxx............... ......o..............o..... ..o.......o................
奇妙に思うのは、最大の正方形は一つだけで良いのだろうか？ということだ。「x」が識別表示されている領域だが、「123456789AB」の領域を含めると、同サイズの正方形を複数検出できるのだが...
.....xxxxxxx....123456789AB ....oxxxxxxx....123456789AB .....xxxxxxxo...123456789AB .....xxxxxxx....123456789AB ....oxxxxxxx....123456789AB .....xxxxxxx...o123456789AB .....xxxxxxx....123456789AB ......o..............o..... ..o.......o................
長方形に延長可能な領域へ続く正方形の検出は不可、としても最大サイズの正方形が複数登場することはないのだろうか？こういう前提は明記されていないのだが、Perlで記述されたマップ生成プログラムは添付されている。Perlプログラムのマップ生成条件を調べ、課題の前提条件を特定したうえで取り組む必要があるということか。
グループ・プロジェクトでも触れたことだが、こういうところがいやらしく、また意地悪く感じるのだ。私は傍観者なので皮肉の一つで済ませられるのだが、当事者である受験者にとってはどうだろう。
こういう部分での対処、決断、合意がグループ・プロジェクトのキーなのだろう。総合的に合否を判定する前提では、プログラムの巧拙や厳密さには拘らない、ということなのだろうか。
余談
先日Twitterに、添付写真と共に次の主旨のことをつぶやいた
- テンションが高い人ほど冷めやすいのか、自ら高めた期待に追いつかない現実への幻滅からか、そんな人ほど挫折するのを多く見てきた。
- 特に協調、協働が必要な場面ではテンションを高め合うのではなく、皮肉や斜に構える姿勢を共有できるくらい、少し冷めたテンションの方がうまくいくのが、私の経験則。
ここでいう皮肉や斜に構える姿勢とは、グループ・プロジェクトで触れた「Life isn’t always fair, that’s just the way it is.」に通底するような諦念染みた感覚が、いつも心のどこかにあるような状態のことだ。
紹介した通り、グループ課題には不明瞭、不確実性が意図的に織り込まれている。課題に限らず、プロジェクトと呼ばれるものはいつもそうだ。要件の解釈のみならず、プロジェクト中の揉め事は絶えず、避けられないだろう。この点において、最低点で評価する仕組みは、上手く考えられている。
プロジェクトで揉めるとき、破綻に向かうライフサイクルが写真に図示されている。こういう状況に陥りそうなら要注意だ。
By Odin, by Thor ! Use your brain !!!
