うにゅーん、って感じだ

だいたいのコンテストサイトで橙か赤です、よく C#を書きます。

東京工業大学プログラミングコンテスト2019 (TTPC2019) の運営

東京工業大学プログラミングコンテスト2019 (TTPC2019) がどのように運営されたかを書いていこうと思います。
atcoder.jp

メンバー

主犯

  • riantkb

Writer/Tester

カッコ内は今回のコンテストで使用された問題における writer/tester 数

  • rickytheta (3/2)
  • riantkb (3/11)
  • noshi91 (1/6)
  • goodbaton (2/1)
  • abc050 (3/1)
  • mikit (1/1)
  • kcvlex (0/7)
  • arkark (1/1)
  • ninja7 (1/2)

オンサイトお手伝い

  • Ashurnasirpal
  • monman53

テストプレイ (OB)

  • camypaper
  • tokoharu

体制

Writer 陣のレートが低くなかったため、基本的には原案者がそのまま作問までやる方針になりました。
各問題 Tester は最低でも 1 人、基本的には 2 人以上つくようにして、また少なくとも 1 人は橙以上が Writer または Tester に含まれるようにしました。

全ての問題のテストは Rime を使って行われ、かつ全ての問題に対し testlib.h を用いた generator/validator が用いられました。

github.com
rime.readthedocs.io

Rime, testlib に対する知見がかなり溜まったので、そのうち余裕があったら何か記事を書くかもしれません(一生書かなさそう)。

みんなレートは高いんですが作問経験がほぼなかったので(しいて言うと自分が yukicoder で 15 問くらい作ったことがあるのと別の場所で作問のおしごとをしたことがあるくらい)、基本的に自分が問題準備のやり方を整備してみんなに準備してもらい、細かい問題文の修正などについては全て自分がやるようにしました(これは自分に半角英数字の前後は必ず半角スペースを開けたい、みたいなこだわりが色々多かったのも理由にあります)。

オンサイトイベント

tsukammo さんに多大なご協力をいただき、オンサイトイベントを同時に開催できることになりました。本当にありがとうございました!!!

atnd.org

活用したサービス

TTPC2019 において活用されたのは主に以下のサービスです

Slack

主に以下のようなチャンネルが存在していました。

  • #general, #random
  • #problem_idea(問題案の投下)
  • #meeting-日付(Slack 上でのミーティング)
  • #nittei_chosei(ミーティングの日程調整)
  • #githubGitHub へのコミットやコメントなどが垂れ流される)
  • #ci(Travis CI のテスト結果が垂れ流される)
  • #ttpc2019_0831(当日の連絡用)
  • #jikkyo(コンテスト中の実況)

問題案については最終的には 30 問ちょいくらいありました。

Google スプレッドシート

色々な用途で使用されましたが、一番大きく使用されたのは問題案整理だと思います。

#problem_idea に書かれた問題案をシートに書いて、難易度や推薦度などの投票をしていました(結局この投票はそこまで意味を持たなかったですが…)

f:id:riantkb:20190902005907p:plain

あとはテスター進捗状況を管理したりするのに使われていました。

GitHub

問題準備には GitHub のプライベートリポジトリが使われました。

実際の使い方としては、問題を 1 問準備するときはその問題用のブランチを master から切ってその中で準備をし、ある程度完成したら master にプルリクを飛ばす、というようにしていました。
問題文や制約の修正提案などはプルリクのコメントで行われていたような気がします(ほんまか?)。
ちなみにマージされる条件は定義されておらず、コンテストが終わってこの記事を書いている現時点でもマージされていません。

各問題の作業ブランチが分離しているためわかりやすく作業もしやすい反面、generator/validator を書いているときに他の問題からコピーしてこようとするときや、実際にサーバーに問題をアップロードするときなどに面倒だったので一長一短だったような気もします。

Travis CI

rime test を CI で回していました。
どうせ GitHub にコミットする前に手元でテストをするのでそこまで必要感はなかったのですが、Tester の中で PC のスペックが異なるときの実行時間計測などにおいて一つの指標になった(有用かは置いておいて)のでまぁあってよかったかなという気持ちです。

Google スライド

解説を書くのに使いました。
各々で同時に編集ができるので、各問題で別々に作ってあとでマージする手間が省けて良いと思います。
数式が書けないのと PDF にエクスポートする時に微妙に崩れるのが難点。

所感

  • 問題案は集めまくって損することはないのでどんどん溜めたほうがよい
  • Java, C#, Python あたりをそこそこ自由に書ける人がいるとよい
  • きちんとスケジュールを立てて計画的に準備すべき(TTPC2019 では失敗しました)
  • 誰か 1 人はものぐさでなく、外部とちゃんと連絡を取ったり会議の調整とか進捗を煽ったりできる人間がいるとよい
    • しかし、それが 1 人だけだとその人に仕事の 95% くらいが集中して危険



おまけ(大まかな流れ)

2月初め

TTPC Slack, GitHub リポジトリが作られる

ゴールデンウィーク

作問合宿(大学に集まって問題アイデアを出しまくる会)が開かれる
確か N法陣、Inversion Numbers of Tree あたりはこの時に作られた気がします

7月中旬〜後半

日程が決まる
オンサイト会場も決まる
コンテスト時間は 4 時間のつもり
この頃から毎週末に Slack 上で meeting を始める
問題の準備の仕方が確立する(やっと!?)

8月初め

オンサイトの atnd を公開し、参加者の募集を始める
丸 1 日くらいで埋まってウケる
参加者に銀冠がいてウケる

8/18 あたり

大まかな採用問題が決まる
問題準備とテスターをがんばる

8/25 あたり

採用問題に嘘が見つかり冷える
制約を変更することで事なきを得る
採用問題が確定する
死ぬほど問題文を修正する
テストプレイをしてもらったら虐殺セットであることが判明した
とりあえずコンテスト時間を 5 時間にすることにした

8/30

銀冠に 3 時間で全完される恐怖に打ち勝ち、セットの中で一番難しい問題を抜いて Next TTPC(この日に思いついた)を入れた
問題の順序がずれたので死ぬ気で修正する
なぜか麻雀をした

8/31

本番
胃が痛い
なんとかなってよかった