Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

42 SILICON VALLEY Piscine 2017資料を読み解く 印象、考察、そして余談。

42 Tokyoというエンジニア養成機関が話題だ。私は42 Tokyoを受験しないのだが、選抜方法とその内容に関心があり調べていた。シリコンバレー校の資料がGitHubで公開されている。私が参照している資料は2017年のものだ。GitHub上にはその他にC++PHPのPiscine資料の存在も確認したのだが、内容は確認していない。リポジトリには、他にも42関連と思われるファイルがアップロードされている。
オンライン・テストを通過した志願者は、Piscineと呼ばれる4週間の入学試験を経て選抜される。このPiscineの内容が関心の的だ。

試験日ごとにPDFが用意され、該当日の課題が掲載されている。一通り確認したところ、良問に通じる雰囲気を感じた。
今時のwebプログラミングや、データベースの要素はかけらも含まれていない。課題の成果物はプログラムなのだが、プログラミング・スキルを評価するものではなく、コーディングの巧拙以外の何か、例えばロジックの組み立て、情報に基づいて実装する理解、作業の丁寧さ、繊細さ、根気強さなどを評価しようとしている意図を感じた。

Day00~Day13の資料を基に、いくつか印象的だった部分を紹介する。その他のプロジェクト資料、特にBSQという最終プロジェクトの資料には気になる箇所もあるのだが、この投稿では話題として取り上げない。それらについては別に投稿する。

42 SILICON VALLEY Piscine 2017プロジェクト資料を読み解く 印象、考察、そして余談。
42 Piscine Examを読み解く 印象、考察、そして余談。

ちなみに、ここで紹介する情報が東京校のPiscineに通用する保証はなく、内容の正しさを保証するものでもないことを申し添えておく。
関連サイトのハイパーリンクは投稿末尾にまとめている。

印象的な仕掛け

各ドキュメントには共通の指示事項が添えられていた。印象的だったのが、次の2項目だった。

• Only this page will serve as reference; do not trust rumors.
Watch out! This document could potentially change up to an hour before submission.

分からなければインターネット検索し、それでも分からなければ人に聞け、というスタンスの養成機関なので、ノイズに振り回されず、規定されていることについては資料に従え、ということなのだろう。付け加えれば、この投稿に書いてあることもノイズだ。
2番目がショッキングだ。文書の内容は課題提出1時間前までに改訂される可能性がある。何も言うことはない、気の毒にも受験者は最後の瞬間まで気を抜けない。全部終わったので、今日は早めに帰ります、には勇気が必要だ。

コーディング規則

Cの学習が始まるDay02(0スタートなので3日目)に、コーディング規則の資料が添付されている。命名規則など、実務経験者にはお馴染みの話題が掲載されている。
初学者もいるための配慮か、教えられていない関数の利用が禁止されている。使用した場合はチートと見なされ-42点。ごく一部の課題で利用可能な関数として、ファイル操作関連とmalloc、free、writeが明記されている。
ただdefineは利用できるようで、関数マクロを定義しているコードがあった。

• Using a forbidden function is considered cheating. Cheaters get -42, and this grade is non-negotiable.

さらに面白いのが関数だけでなく、for、do...while、caseなどの制御文も禁止されている。ループはwhileのみ、分岐はifだけ利用できる、ということだ。最低限の機能でロジックを評価する試みなのだろう。

• You’re not allowed to use :
◦ for
◦ do...while
◦ switch
◦ case
◦ goto

カリキュラム

詳細はGitHub上の資料とコードを確認してみてほしい。決して難しい内容ではないものの、ロジックの閃きは考え抜いたからといって結果の出るものではないし、論理的考察と試行錯誤の積み重ねでは、時間を費やしすぎて生産性が落ちる場合もある。何よりコードを書くだけでなくPeer learningで、他の候補者もサポートしなければならない。
その他のプロジェクトに対応することも考慮すると、感じ方は人それぞれだろうが、受験者の負担はかなり大きいと予想する。

Day00~01 UNIXの操作。
Day02~Day08 Cの学習。
ポインタはDay03で登場。
ヘッダー・ファイルがDay08で登場。
Day09~Day13 Cの学習なのだが、Day09には例外的な意図を感じる。
Day10でMakeが登場。

明示されてはいないものの、課題には1度限りで完結させず、他の課題への関連や発展を含意するような仕掛けが目に付いた。以前に経験した課題の知見を引き継ぐ前提で設計されているようだ。おそらく、この知見の再活用を前提に負荷を考慮しているのだろう。とにかく課題数に容赦がないのだ。
全ての課題を一から考え直す場合、知見の応用、再活用ができることに気付いた場合では、負荷は大きく違うことだろう。

課題は、ただロジックを組み立てればよいというものではなく、ある課題ではmanを参照して指定コマンド(例えばstrcmpやtailなど)を実装する、というものもある。
GitHubには課題のコードが掲載されているものの、一部のコードには、あからさまにダミーが記述されているものもある。おそらく該当課題の評価対象がロジックそのものであり、肝心の部分を公開する意図はない、ということだ。

Day09について

シリコンバレー校では1課題、1時間を連続24時間実施したようだ。この日の資料だけ課題ごとに分割されており、制限時間が明記されている。奇妙なのは他の日の課題に比して、その内容が異常なほど簡単なことだ。
これはコーディングやロジック以外の何かを評価するテストなのだろう。課題の中心は文字列表示なのだが、この文字列には大文字、小文字が入り交じり、細かい繰り返しが含まれている。コーダーとレビュアーの注意深さ、根気強さを測ろうとしているだと察した。
ちなみに資料の表紙にはDay24と記載されている。本当はDay09ではなく、意図して何かの途中で突発的に挿入される課題なのかもしれない。

余談

初学者に向けて

受験に際しC言語の事前知識を求められていないとはいえ、限定的な範囲での事前学習はしておいた方が良いのではないか、というのが私の印象だ。それは予習、試験対策というよりも、Piscine期間中の学習負荷を極力軽減し、試行錯誤やPeer learning等へのリソースを確保するためだ。期間中の作業負荷は相当高いと感じるし、何より試験という性質上、普段とは異なる緊張状態で、連日、対応する必要がある。
事前にGitHub上で公開されているコードに記載されている範囲の機能、知識は知っておいて損はないと思う。

C言語の参考書というと、次の2冊が定番として挙げられるのだが、Piscineのためだけの学習であれば、私は勧めない。あまりに無味乾燥すぎるし、何より理解するのが難しいと思う。ただC言語流の記法を学ぶに当たっては、無視するに惜しいところはある。

C言語には今時のweb系スクリプト言語とは異なり、初見殺し的な要素がある。なるべく初学者向けに「理解させる」説明の多い書籍、特にポインタと配列の関係を意識させることなく説明している物をお勧めする。例えば次の書籍だ。
1Kのchar配列で疑似的に文字列型を定義し、「からくり構文」というポインタと配列を上手く組み合わせた用法を活用する。同時にサンプル・プログラムにも、いわゆるパズドラ的なゲームを採用することで、読者をひきつけ、理解させようとする工夫が感じられる1冊だった。
いずれの書籍にせよ、一度立ち読みなり、図書館で借りて内容を確認してみると良い。
impsbl.hatenablog.jp

負荷、負担の予測

初見でこのボリュームを見せつけられては圧倒されるのではないだろうか。東京校のPiscineがどのようなものかは定かではないが、シリコンバレー校と同程度のボリュームであると仮定するだけでも、体感できる程度に想定できることだろう。
一度、どれか適当な日にちの資料を参照し、一日かけて課題に取り組んでみると良いと思う。検索と学習、コーディングだけでどれ程の労力、時間を要するか把握できるはずだ。実際には、その負担にPeer learningの時間、労力も加わることになる。一日の負荷がどれくらいで、連日対応する負担はどれほどになろうか、主観的に想定できるはずだ。

最後に、次の言葉で締めくくるのが、Piscineのプロトコルのようだ。
By Odin, by Thor ! Use your brain !!!

Piscineで実施されるプロジェクトの話題については、次のエントリで取り上げている。
impsbl.hatenablog.jp