git challenge というイベントを開きました。
いよいよ、git challengeの第0問といいますか、チュートリアルが始まりました。スコアボード、実際には強烈なCircleCI画面が会場に映写されはじめています。#mixi_git pic.twitter.com/TiWcqqlk0q
— mixi engineers (@mixi_engineers) November 15, 2015
私は、企画、問題作成、インフラ構築、微妙にPM、みたいな感じで全般的に担当しています。 問題は全部で20問弱用意しているのですが、このうちの11問を作成しています。 これらの雑感を残しておきます。
企画について
私は Scrap Challenge というセキュリティのイベントがきっかけでミクシィに入社したので、challenge 系のイベントには思い入れがあります。 その縁もあって、Yet Another Challenge series の企画に携わりました。
この企画の少し前に、ひどい Git の混乱《カオス》を鎮める体験したことが、Git で問題作れるぞという確信につながりました。 この体験は git challenge の最高難易度の問題のコンセプトになっています。
どれぐらい混乱《カオス》なのかわかるような、コミットログの一部をお見せしましょう。
問題作成について
企画時点で特定のプログラミング言語などに依存させない方針を決めました。 そのため、リポジトリ内のファイルはほぼ CSV です。
そして、問題を作成しはじめて困ったのが、作成効率の悪さです。 CSV をエディタで開いて変更して commit するのもめんどうだし、commit log を汚すために merge してみたら CONFLICT してつらいとかいろいろありました。
この問題には、CSV の各種 git の操作をうまく扱うためのツールを作成してしのぎました。 ツールの作成作業は、問題の作成と並行しておこなえたため、YAGNI な感じでうまく実装できました。 ちなみに、問題作成＆ツール開発だけで2週間ぐらいかかっています。
そのあとハードルになったのが、自動テストによる採点スクリプトの実装でした。 git challenge のすべての問題の採点は、すべて採点スクリプトにより自動で正誤が判定されます。 ただし、思いもよらない解答がきてしまったとき、false negative/positive にならないように注意を払う必要が有ります。
たとえば、hoge というブランチに checkout することをひとつをとっても、落とし穴があります。
git checkout hoge
一見正しそうに見えますが、ブランチと同名のタグ hoge をつくってしまうと、解答はあっていたとしても不正解のように振舞ってしまいます（git からすると、hoge がタグなのかブランチなのか区別がつかないからです）。
そのため、下のように記述しなければなりません。
git checkout heads/hoge
他にも落とし穴は無数にあって、CircleCI 上でなんとか動く状態までこぎつけるのに数日かかった覚えがあります。
インフラ構築について
GitHub, CircleCI, Heroku など、いまどきのインフラで挑むことにしました。
1問1リポジトリということもあって、CircleCI との相性はかなりよかったです。
ただし、circle.yml を追加しないで、Web UI からの設定で頑張る方針がいろいろと面倒を引き起こしてくれました。
この方針には2つの理由があります。
circle.ymlが書き換えられちゃう手法の防御ができないこと、問題作成後に採点スクリプトに変更があると面倒なことです。
そのため、WebUI でがんばってたのですが、Node.js のバージョン指定が WebUI 経由だと簡単にはできなかったりとかいろいろとつらい感じでした。
あと、全体の解答状況がわかるようなスコアボードを作成しました。 これは Heroku 上で動作させてます。
このスコアボードですが、isomorphic + TypeScript + React というイケイケな構成で組んでいます。 なかでも TypeScript の恩恵は大きかったです。 静的型で守られているため、スコアボードの一部の複雑な箇所を除けばテストがなくても一撃で完璧に動作しました。 また、Server と Client の双方で同じモデルを使いまわしていたため、整合性の問題もまったく起こりませんでした。 Microsoftさん、マジでありがとう。あれは本当に素晴らしいプロダクトだ。
微妙に PM
このイベントのスタッフは、有志エンジニア + 人事という構成だったため、進捗管理したりする人が存在しないプロジェクトとして始まってしまいました。 これじゃイカンって感じだったので、Trello 使って、問題の作成状況やその他のスケジュールを可視化しながら進めてきました。 その甲斐あってか、スケジュールは遅延なく進行できました。
しかし、進行管理しながら主力としても開発していくのはかなりつらいですね。 進行管理する人は、それだけでそこそこの負担がかかるので兼任ヨクナイって思いました。
参加者の方々へ
今回の参加者の方々は、おしなべて素晴らしい技術力を持っていたと思います。 とくに、あるチームがおこなっていた、バックアップツールの投入は素晴らしい判断でした。
今回の git challenge で伝えたかったことは、協調開発の難しさや CI の便利さです。 様々なこんがらがったリポジトリを触って、雑なことをすると他の開発者が泣くことを、身を持って体験できたと思います。 また、採点が CircleCI 上でおこなわれることもあり、自然と CircleCI に慣れることもできたのではないでしょうか。 これらの経験を、将来の開発に活かしてくれればなによりです。
手伝ってくれたスタッフへ
kodam san, kikuchy san、問題作成助かりました。 2人のおかげで面白い問題が揃えられたのは間違いないと思います。 インフラまわりのツールについても、整えてくれた基盤が重要な役割を担ってます。 素晴らしい成果でした。
toma san 講義よかったです。 チュートリアルがすんなりいったのは、講義のおかげです。
社内レビューアの方々、レビューありがとうございました。 当日は、1問だけ採点スクリプトに不備が見つかったものの、それ以外について問題なく動作できたのはレビューアの方々のおかげです。 本当にレビューをおねがいしてよかったと感じています。
人事の方々、学生さんとのコミュニケーション、外部リソースの確保で協力くださりありがとうございました。 おかげで、インフラ構築や問題作成に専念することができました。 これからも、継続して開催していけたらと願っています。
なにはともあれ、無事にイベントを終えることができて本当によかった。 イベントの準備・開催に関わってくれた全ての方々に感謝します。
誰も気がつかなかった小ネタについて
実は、matoi-chan というデプロイ用のbotアカウントがいて、参加者と同じ GitHub Org にこっそり入っています。 このアカウントの《芝》に細工をしていたのですが、反応がなくて枕を濡らしていました。
