2019年の目標

アメリカで太らない

145lbs近辺を維持する。

ボイロ動画を作る

最近ボイロ動画ばっかり見てるので作りたくなってきた。

個人用途でWebインフラを作って管理する

業務で勉強するだけだと速度に限界を感じてきた。mikutter plugin archiveも作らないといけないし……。

旅行に行く(3回以上)

せっかくアメリカにいるんだしね(と去年も言っていた)。

ICFPCで1位を取る

恒例。Unagiを滅ぼす。

本を読む / 映画を見る / ゲームをする

どうせ目標にしなくても達成するっぽいことが分かってきたが、年末に振り返るときに便利なのでとりあえず書いておく。

2018年振り返り

人生三万日しかない。今年は有意義だったか?

目標設定

osak.hatenablog.jp

アメリカで生き残る (1/1)

まだ生きてる。ビザ周りでちょっとゴタゴタがあったものの、概ね生活はうまく回っている。

アメリカで太らない (1/1)

ボルダリングジムで定期的に体重を測っていたけど、145lbs(65.7kg)から動かなかった。ていうか元の体重を書いてないのはどういうことなんだ。

アニメや映画を10本見る (12/10)

覚えてるやつ

割と見てるな。

本を読んでログを残す (15くらい/1)

リゼロはアニメの後になろうで全部読んだ。感想も書いた。

osak.hatenablog.jp

読書メーター(ディファレンス・エンジンからドリフターズ6巻まで)

漫画を一気読みしたら最終巻だけ登録するようにした。各巻の感想には対して興味がないので結構便利。

旅行に5回行く (2?/5)

旅行のカウント方法が微妙だけど(日本に帰るのは旅行なのか?)、とりあえず3月に東北旅行と、9月にICFPCがてらSt. Louis観光に行った。アメリカ国内旅行とか南アメリカとかは全然行ってないですね……。来年はがんばる。

公開できるWebサービスをなんか作って運営する (0/1)

mikutter plugin archiveを作って公開しようとしていたが結局完成しなかった。悲しい。

ICFPCで1位を取る (0/1)

2位は取れたものの、またUnagiに負けたし、なんなら2016年と同様にほぼ全順序が付くような形で負けた。悲しい。 チームは結局ビデオチャット経由で会話することにしたけど、物理的に集まったほうがやっぱりやりやすいなと思った。

osak.hatenablog.jp

osak.hatenablog.jp

ゲームで遊ぶ (8/1)

去年と比べるとかなりまともに色々遊んだ。

どれも面白かった。特にNieR: Automataは初めてタイムを測るRTAまでやったし、結構練習もしたのでやり込んだと思う。Celesteも最後までプレイし続けられるか少し不安だったけど、育成要素がまったくなく、リスタートのテンポもかなり良いので結局100%クリアまでできた。こっちはRTAやろうと思ったら世界レベルが既に人間をやめていたので早々に諦めた。

育成要素がなく、プレイヤーが成長するタイプのゲームが好きなことが分かってきた(ってずっと言ってる気もするな)。来年はPrismataとStarCraftをやりたい。

そういえばMtGは全然やらなくなってしまった。なんか直接人と話すような環境じゃないとやる気が起きなくて、それならカードショップでトーナメントとかに出ればいいという説はあるけど、英語で遊べる気がしなくて気後れしているまま1年が経過してしまった。来年はやりたい。

ボイロ実況はたくさん見たけど自分では作らなかった。インプットを増やしたり、仕事関連でちょいちょい機会を得たのもあって、人に伝えるものの作り方がちょっと掴めてきたのでそろそろ作れそう。

osak.jpを作り直す (0/1)

osak.jpは何も触らなかった。サーバは1年間無駄に走り続けた。

目標達成率5/9。人生の充実度は上がったのでいい年だったと思う。プログラミング関係の目標を全然達成できてないのがちょっとつらいけど、技術的なあれこれは仕事の方で結構できたので完全に不満足という訳ではない。来年はブログとかで公開できる成果を出していきたい。

Re: ICFP Prorgamming Contest のチーム戦テクニック集

pepsin-amylase.hatenablog.com

ICFP Prorgamming Contest のチーム戦テクニック集」を読んで、大半の内容はなるほど確かになぁという感じだったんだけど(それはそう)、一箇所この部分

大量に同時実行したAIの出力を POST リクエストでポータルサイトに投げるような設計をした場合はその負荷にも注意が必要です。ポータルサイトボトルネックになって計算結果が失われるという悲しいながらも割と起こる事故があります。ISUCONするはめにならないよう。*4

*4:個人的にはこういう設計がそもそもダメなんじゃないかという気もします。jsonメタデータを書くしょぼエンジニアリング最強なのでは??

だけちょっと思うところがあったのでメモします。*1*2

この主張には一理あり、ICFPCをやっているとそもそもの問題サイズが大きかったり、中間結果もビジュアライズのために取っておきたくなったり等の理由により、プログラムの出力が数MBから数十MBに膨れ上がることが稀によくあります。そういうとき、序盤で雑に書かれたFlask製サーバなんかがスケーリングされずにアップロードを待ち受けていたりすると一瞬で死んでしまうため、そんな辛い思いをするくらいなら最初からrsyncとファイルI/Oで頑張ればいいじゃんと考えるのは自然な発想ではあります。

しかしJSONメタデータ戦法は検索性が致命的に悪い。例を挙げると、何かしらの検索をしたければ、全てのデータを舐めながらマッチするデータだけ拾ってくる必要があるため自明に遅いという点が1つ。また、検索したい軸が1つしかないという状況もまずあり得ず、こういうカスタムクエリが欲しいという要望が無限に飛んできて、似たような検索ロジックをコピペで量産した挙句に全部バグって死ぬことになります(断言)。

……みたいなことを考えて、実際2016年はこの方針だったけど途中でスケールしなくなってMySQL建てたと記憶してるので、まあどうせみんなMySQL書けるし、大人なんだから自分の好きな言語でMySQLに繋ぐ方法くらい分かるでしょ(大嘘)という感じで思考停止でMySQL使う→MySQLの認証情報を配るのめんどいし、Webサーバを建てといてアップロードした解答を勝手にインデックスすると楽だよね、という感じで上記の記事に書いてあるようなシステムが出来上がったんだったと思います。そしていつの間にかISUCONが同時開催されます。勝手にコンテストの問題が増えるなんてお得ですね。

で、まあこうやって読んでるとなんとなく分かると思うんですが、上の理屈には飛躍があります。ICFPCのポータルサイトはデータ解析基盤なので厳しいリアルタイム性が要求されることはほぼなく、新しい結果が届いてから反映されるまで2、3分のラグがあってもまあええやろという雰囲気であることがほとんどです。ということは、アップロードを司る何かがインデックスを作る必要は特になく、各人が勝手にファイルをrsyncで所定の場所に置くようにして、それを適当なcronがMySQLなりElasticSearchなりに順次突っ込んでいけば良いのでは?

ということを思いついたので記事を書きました。誰か試してみてください。

*1:本当はコメント欄にもっと雑な版を書こうと思ったんだけど、なんかコメント欄が存在しなかった

*2:と思ったら下の方にボタンがあるのをこれを書き終えてから見つけた。おのれはてな

リゼロ(原作)感想

先日アニメを見終わった後、リゼロの原作が小説家になろうで読めることを知ったので読み始め、今日現在で公開されている6章56話までをようやく読み終わった。読み続けてたわけじゃないけど2週間半くらいかかってしまい、読書速度の衰えを感じる。

続きを読む

リゼロ感想

  • 2018年9月5日、毎週を生きる活力となっていたシュタインズ・ゲート ゼロが更新されず、生きる気力をCelesteに注ぎ込む。
  • 2018年9月9日、Celesteを100%クリアしてしまう。
  • 生きる意味を取り戻すため、シュタゲと同じくタイムループものとして評判がよく、心の中のヒープに積まれていたリゼロを見始める。

ということで今日ようやくリゼロを最後まで見ました。せっかくなので感想を書きます。

続きを読む

Arch on VirtualBoxのグラフィック周りでハマった話

トラックパッドトラックポイントもFull HDの画面内を動き回るには使いづらい(カーソルが遅いと移動に時間がかかる上に変に力をかけ続けないといけないので疲れるし、速いと目的の場所に止めるのが難しい)ので、タッチパネル装備のThinkpad X1 Carbonを買った。実際使いやすいかはまた別の機会に書くとして、例によってセットアップが辛い感じになったのでログを残しておく。

マシン:Thinkpad X1 Carbox Gen6 ホストOS: Windows10 Pro ゲストOS: Arch Linux on VirtualBox 5.2.16

Archなので、例によってArch Wikiを見るとvirtualbox-guest-utilsというパッケージを入れれば万事ok的なことが書いてある。しかしなぜかIntelliJの描画が遅く、カーソルを動かすだけでCPUを150%くらい食い始める。これはどうもグラフィックドライバが良くないっぽいぞと思ってとりあえずglxgearsしてみると、150fpsくらいしか出ない上に描写がなんとなくカクカクしている。FirefoxWebGLのページを見てみると動かない。また、glxgearsの起動時に以下のようなエラーが出る。

libGL error: pci id for fd 37: 80ee:beef, driver (null)
libGL error: No driver found
libGL error: failed to load driver: (null)

Xorgの起動ログを見ると、DRIのドライバが読めていないように見える。

glados% grep EE .local/share/xorg/Xorg.1.log.old
[  1771.207] Current Operating System: Linux glados 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1771.217] (EE) Failed to load module "vboxvideo" (module does not exist, 0)
[  1771.217] (EE) Failed to load module "fbdev" (module does not exist, 0)
[  1771.218] (EE) Failed to load module "vesa" (module does not exist, 0)
[  1771.298] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x80ee / 0xbeef
[  1771.298] (EE) modeset(0): Failed to initialize the DRI2 extension.
[  1771.298] (II) Initializing extension MIT-SCREEN-SAVER
[  1771.438] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1/1-1:1.0/0003:80EE:0021.0001/input/input5/event4"

こういう系のエラーは例によってぐぐってもまったく情報が出てこないので苦戦を強いられることになる。2時間ほど検索してもそのものズバリという回答は見つからなかったが、glxinfo | grep rendererするとllvmpipeというのが出てきて、これがどうやらソフトウェアレンダラらしい。つまり、VirtualBoxのグラフィックドライバが読まれていない。

もしかしたらVirtualBoxOpenGLドライバなんてものは存在せず想像上の存在に過ぎないかもしれないので、一応確認しておく。

glados% pacman -Ql virtualbox-guest-utils
virtualbox-guest-utils /etc/
virtualbox-guest-utils /etc/xdg/
virtualbox-guest-utils /etc/xdg/autostart/
virtualbox-guest-utils /etc/xdg/autostart/vboxclient.desktop
virtualbox-guest-utils /usr/
virtualbox-guest-utils /usr/bin/
virtualbox-guest-utils /usr/bin/VBoxClient
virtualbox-guest-utils /usr/bin/VBoxClient-all
virtualbox-guest-utils /usr/bin/VBoxControl
virtualbox-guest-utils /usr/bin/VBoxService
virtualbox-guest-utils /usr/bin/mount.vboxsf
virtualbox-guest-utils /usr/lib/
virtualbox-guest-utils /usr/lib/VBoxOGL.so
virtualbox-guest-utils /usr/lib/VBoxOGLarrayspu.so
virtualbox-guest-utils /usr/lib/VBoxOGLcrutil.so
virtualbox-guest-utils /usr/lib/VBoxOGLerrorspu.so
virtualbox-guest-utils /usr/lib/VBoxOGLfeedbackspu.so
virtualbox-guest-utils /usr/lib/VBoxOGLpackspu.so
virtualbox-guest-utils /usr/lib/VBoxOGLpassthroughspu.so
virtualbox-guest-utils /usr/lib/security/
virtualbox-guest-utils /usr/lib/security/pam_vbox.so
virtualbox-guest-utils /usr/lib/systemd/
virtualbox-guest-utils /usr/lib/systemd/system/
virtualbox-guest-utils /usr/lib/systemd/system/vboxservice.service
virtualbox-guest-utils /usr/lib/sysusers.d/
virtualbox-guest-utils /usr/lib/sysusers.d/virtualbox-guest-utils.conf
virtualbox-guest-utils /usr/lib/udev/
virtualbox-guest-utils /usr/lib/udev/rules.d/
virtualbox-guest-utils /usr/lib/udev/rules.d/60-vboxguest.rules
virtualbox-guest-utils /usr/lib/virtualbox/
virtualbox-guest-utils /usr/lib/virtualbox/mount.vboxsf
virtualbox-guest-utils /usr/lib/xorg/
virtualbox-guest-utils /usr/lib/xorg/modules/
virtualbox-guest-utils /usr/lib/xorg/modules/dri/
virtualbox-guest-utils /usr/lib/xorg/modules/dri/vboxvideo_dri.so
virtualbox-guest-utils /usr/share/
virtualbox-guest-utils /usr/share/licenses/
virtualbox-guest-utils /usr/share/licenses/virtualbox-guest-utils/
virtualbox-guest-utils /usr/share/licenses/virtualbox-guest-utils/LICENSE

よくわからんが、VBoxOGL.soというのがそれっぽい。じゃあ今のlibGL.soはなんなんだ?

glados% pacman -Qo /usr/lib/libGL.so
/usr/lib/libGL.so is owned by libglvnd 1.0.0-1

どうやらベンダのOpenGL実装を発見して動的にディスパッチしてくれるやつっぽいが、君動いてないよね?とりあえずこいつを無視してそれっぽい感じにしてみる。

glados% ln -sf /usr/lib/VBoxOGL.so /usr/lib/libGL.so.1.0.0

こうすると、glxgearsが300fpsくらい出るようになった。glxinfoも確認しておく。

glados% glxinfo | grep renderer
OpenGL renderer string: Chromium

Chromiumっていうのはブラウザではなく、他のレンダラにプロキシするレンダラらしい。あとxf86-video-fbdevとxf86-video-vesaもロードに失敗しているっぽいので入れておく。こうするとWebGLが動くようになった(俺達は雰囲気でLinuxをやっている)。

しかしIntelliJは依然としてアホみたいにCPUを食っているので厳しい……。レンダリングじゃなくて純粋にJavaVMと相性悪いのか?

ICFPC2018

ICFPC2018にチームmanarimoとして参加しました。マナリモとは何か一応説明しておくと、東北地方以北に分布するナリモ科の藻です。水質のきれいな湖にしか生息せず、「自然の水質管理官」と呼ばれることもあります。

メンバーは去年と同じく

  • mkut
  • osa_k
  • pepsin_amylase
  • y3eadgbe
  • yuusti
  • kawatea

の6人でした。僕はアメリカの自宅から、他の5人は日本のIndeedオフィスから参加しており、コンテスト中はHangoutでビデオチャットしてコミュニケーションを図っていました。

リポジトリ

github.com

1日目

開始と共に問題を読み始める。今年は問題文が整然としていて読みやすい。どうやら3Dプリンタ的なものを実装するゲームらしい。あと公式が必要そうなツールを一通り提供してくれていてありがたい。

問題文を一通り把握したので、インフラのセットアップを始める。とは言ってもJenkinsはコンテスト開始前にサーバを立てて入れてあったし、ポータルサイトもしばらく必要にはならなそうな上作ろうと思えばすぐ作れるので、公式のビューワを使って問題のサムネイルを生成することにした(2016年にサムネイル生成が遅れて進行が詰まったことの反省)。ビジュアライザがJSで実装されているのでseleniumとかで叩けば簡単にできそうだったが、あまり自動化の経験がないので、mdlファイルを順番に読みながらcanvasに描画されたものをcanvas.toDataUrl()で画像に変換し、手元に立てたExpressサーバに送りつけるという方法を取った(f58a9b)。画像を保存するツールなので名前はSaver Wingにした。モデルの描画が思ったより遅くてウエイトを調整したりする必要があったものの、しばらくして無事に生成できた。

サムネイルの公開や、今後割とすぐに発生するであろう改造版公式ツールの公開をどうするか考えて、git pushに反応して即座にサーバ上でリポジトリをpullするようにして、nginxでリポジトリのルートを配信するようにした。これは結構便利だった。

そんなことをしていたらid:pepsin_amylaseがnanachiという名前のポータルサイトを生成したため、systemd化してnginxから配信するようにして、ついでにサムネイルもナナチから見れるようにした。あとモデルビューワを改造してファイルをセレクタから選ばなくても見られるようにしたり、マウスで回せるようにしたりした。

f:id:osa_k:20180725145833p:plain f:id:osa_k:20180725145851p:plain

採点部分も公式がそれなりに速そうなものを提供してくれていたものの、本体がSMLをコンパイルしたやばそうなJSになっていて人が触れる感じではなかったのでNodeで動かすのは諦め、公式のシミュレータで走った結果を自動でナナチにサブミットすることでDBにログを残すようにした (8fe362)。しかしコンテスト終わってからnya3氏のコードを見たら割とお手軽にNode.js対応できたっぽいのでやればよかった……。ダミーのDOM実装を生やして無理やり動かすのはアイデアとしてはあったけど、何が呼ばれているのかちゃんとログする方法を思いつかなかったのと、DOM周りのAPI(特にファイルセレクタ)の挙動を理解している自信がなかったので諦めてしまった。次は大丈夫です。

その間にmkutがアセンブラを完成させ、kawateaとyuustiがそれを利用してAIを書いたり、y3eadgbeがモデルの解析をしたりしていた。非自明なAIが完成するのが思ってたより早かったので、これは流石に自動で採点する仕組みがないと後々困るなと思い、シミュレータの実装を始める。仕様がかなりはっきり書かれていて、特にinvariant周りが充実していたので、とりあえず書いてある通りに頑張って実装すればまあ動くだろうみたいな安心感はあった。久々にC++を書いたら細かい文法とかメソッド名とかかなり忘れていてエラー出しまくったのでつらい(JavaScriptを書きすぎてconst hoge = ...とか書いて、型名がないことで長大なエラーを生成したりしていた)。自動で採点するやつなので、名前はオートスコアラーにした(3a4a08)。結局4時間くらいかかって、書き上げた当初はあまり自信がなかったけど、一部アサーションが間違っていたり、最後にモデルとの形状一致を判定するのを忘れていたりした以外には、結局致命的なバグは最後まで見つからなかったので良かった。

オートスコアラーの導入で機械的に提出を評価する目処が立ったので、とりあえずその時点で存在していたAI全部を全ての問題に対してぶん回してトレースを生成し、後からオートスコアラーで点数を付けるというパイプラインを構築した。APIエンドポイントはJenkinsで、c5.18xlargeをSlaveにして186個のジョブをリモートトリガでキューに突っ込むことで、お手軽並列実行環境にした。これをやった結果、yuustiのAIがバグっていることを発見したりした(「大体正の点数を取る.cpp」というAIなのに正の点数を取れておらず、おもしろコミットが生えたりした)。

このへんで朝の6時(開始から19時間)になり、流石に眠くなってきたので、186個並列キューのやり方をy3に託して寝た。

2日目

ずっと眠くてあまり覚えてない。こういうときオンラインだと人と話してモチベーション高めつつ眠気を飛ばすみたいなことがやりにくくて不便。とりあえず起きたら昼の12時で、寝てる間に来ていた更新をmkutがまとめていた。モデルを壊す問題と作り変える問題が増え、更に範囲コマンドも追加されたらしい。範囲コマンドの実装やばそうだけど、まあこれ以上変更が来ないならアドホックに行けるかなぁと思いつつ昼飯を食べに行く。

とりあえず面倒くさそうなシミュレータ実装は後回しにして、新しく増えた問題を確認してみる。すると、どうもほとんどのモデルがLightningそのままっぽいことが分かった。再構築問題はいくつか新しいモデルがあったものの、密度の高い立方体を切り出して彫刻するやつとか、逆にモデルを埋め立てて立方体にするやつとかで、Lightning以上に見た目がやばそうな問題は増えてなさそうだった。

新しく増えたVoidコマンドの実装はしばらく考えたものの、voxelを削除すると地面に結合している判定に使っていたUnion Find木が壊れるためどうもうまい方法が思いつかない。結局Voidは後回しにして、簡単なGFill対応とDisassembly, Reassembly問題の対応を先にやって、うまい実装をもう少し考えることにした(後から考えると、ここでAIに時間を割いとけばよかったかもしれない)。

結局Union Find木が壊れるのは防げなさそうだが、kawateaが作ったAIはGVoidを使っていっぺんに大量のvoxelを消すものだったので、じゃあ普通のVoidはあまり使わなくて大半がGVoidになるだろうし、GVoidで最大303とか消されたら流石に1からUF木を再構築するしかないだろうと思って、とりあえずVoid系が来たらUF木を作り直す実装を書いた(127541)。その後しばらくして、消されたvoxelの隣接6セルがVoid後も連結ならUF木をアドホックに修正するだけでいいことに気がついて、枝刈りを入れた(4c1723)。

その後はy3がDBの変更をしたのでオートスコアラーを追随させたり、AIのコードを読んだりしていたら寝落ちしていた。

起きたら8時くらいだった(確か)。公式のStandingsをインポートして内部ランキングに表示したり(437646)、評価がまだ終わっていないtraceを採点するために、接地判定をスキップしてオートスコアラーを高速化したりしていた。

3日目

そのまま3日目に突入。Voidを入れると接地判定をスキップしても構築モードよりえらく遅くなるのでなんでだろう、と思って調べていたら、Union Find木を再構築するときに無とブロックをuniteしていたのを発見して直した(2729ce)。

id:pepsin_amylaseがこの辺りでアセンブラの最適化を行っており、結構な成果を残したっぽい。詳細は以下のブログを読もう。

pepsin-amylase.hatenablog.com

この頃になると結構サーバの稼働率も上がってきて、それに伴ってナナチが謎の死を遂げたりするようになったので、プロセス数を増やしたりしてアドホックに対応していた。あとyuustiのAIが無限にログを吐いて、300GB割り当てたはずのEBSをまるまる食い尽くしていたりした。ログ問題はともかく、ナナチはよくMySQLのコネクションが取れないと言って死んでいたので、これMySQLに1MBくらいのBlobを突っ込んでるのがよくないんじゃないの、という話から今までMySQLに保存していたtraceをS3に移行する作業をしたりして、当面はなんとなく安定している風になった。

日付が変わる頃になって、オートスコアラーにアホみたいな最適化漏れを仕込んでいたことに気がつく。GVoidはどうせUF木を再構築するから接続判定とかいらないじゃん、と言ってたのに、普通のVoidとコードを共有したせいでGVoidで消される各セルごとに接続判定が走っていた。これを消したらめちゃくちゃ速くなって、今まで大きいマップで3分以上かかっていたスコアリングが30秒くらいで終わるようになった(([9d8025]https://github.com/osak/ICFPC2018/commit/9d8025b609515c5d99743d0e6e029f9710b7ecb2))。

しかしこの高速化でサーバへのアクセス頻度が上がったせいか、ナナチがまた不安定になり、解答のSubmitがコケまくるという非常事態が発生した。ログを見たところ、またMySQLのコネクションが取れなくて死んでいるっぽい。PythonMySQLコネクタのドキュメントを調べてコネクションプールを有効にしたが、それでも改善しない。結局MySQLとコネクタの気持ちになって考えたところ、毎リクエストごとにmysql.connector.connect()を呼ぶ必要があるっぽいという気持ちになったので、試してみたところそれ以降全然落ちなくなったので正解だったらしい(53a2eb)。仕事ではJDBCに飼い慣らされているので、クエリごとに裏で勝手にコネクションプールしてくれるだろみたいな雑なイメージを持っていたが、どうもそんなに甘くはないらしい……。

サーバが一段落して、残り12時間を切ったけど誰もReassembly問題を解いていないっぽいので聞いてみると、全消しと普通の構築を組み合わせてReassembly問題の解にするという案があるらしい。やるだけっぽいので書いた(a2d7b6)。なんかファンシーな名前にしたかったが、3日目の脳は限界だったので安直にcombinerという名前になった。これを走らせると、自分は何も賢いことをしていないのにReassembly問題が次々と埋まっていってかなり面白い。一部のモデルはそもそも単純な構築や破壊問題になっていないので、これらに対して良い解を見つけるためにダミーの問題を追加したりした。

Jenkins上でyuustiのAIが延々と走りながらログを吐いてディスクを食いつぶしていくことに文句を言ったところ、どうやら中が空洞のモデルを作ろうとして、中にNanobotがいるのにGFillでフタをして脱出不能になることがあるらしく、労災と呼ばれていた。このままだと色々と不便なので、労災者が出たら心中することになった

終了3時間前くらい、y3が色々なものを手動で解いてSubmitし始める。やばい。kawateaも当然のように文字の形をした問題を手動で解いている。やばい。

スコアボードを見てUnagiの強さに絶望したりしつつ、特にドラマチックな逆転とかはなく終了。最終提出一覧

総評

インフラ構築は一部トラブルが起きてつらい気持ちになったものの、全体的には悩むことなくスムーズに構築できたので良かった。インフラができた後はちょいちょい管理業務があったものの、総じてちまちまと余裕はある感じだったので、もっとAI構築に時間を割くべきだったと思う。しかしHangout参加だと人と議論するのが難しいのでうまくできたかは謎……。そもそも例年だと、暇になったらAI作ってる人に欲しいものがないか聞いて回ってたんだけど、今回はそういうのできなかったし、遠隔のコミュニケーションは難しい。

MySQLのBlobをやめてS3に移行したのが正しかったのかは謎。実際Blobが大量に詰まってるテーブルにカラムを追加しようとしたら激烈に遅かったので何かまずい使い方ではあるっぽいが、最終的にはコネクションプールの仕方を間違っていて死んでいただけだったので、Blobがどれくらい悪いのかは分かっていない。ただ、最初の方でid:pepsin_amylaseがファイルをS3に上げることを主張していたのに、自分がS3にファイルを置くと取り扱いが面倒くさそうだしBlob突っ込めばいいでしょみたいに言ったのは良くなかったと思う。フタを開けてみれば、S3はpublicなhttpのURLも取れるし、権限付与もEC2インスタンスにIAMロールをくっつけるだけなので、超簡単だった。

シミュレータは、この記事を書きながら、そもそも各人のマシンで公式JSを走らせてもらう手もあったなあと今更ながらに思った。ファイルを複数選択してもらえるので、適切にmdlとnbtをシミュレータに突っ込んでいけば半自動でサブミットできたはず。大きい問題に対してどれくらい公式シミュレータが対応できていたかよく分からないが、その方針で一度は実装するべきだった。

チームでAWSを使うにあたって、Organizationを使って支払いは自分のメインアカウントでやりつつ、IAMにしか実体のないサブアカウントでまっさらなAWS環境を作り、そこから更にIAMユーザをぶら下げるという環境を作った。これはかなり勉強になった。

チームでコンテストやるならやっぱりリアルで集まったほうが楽だし楽しいですね。しかしUnagiに勝ちたかったなあ(勝てなかったと会社のマネージャー氏に報告したら「また勝てなかったの???」みたいな感じで煽られた)。

補足

マナリモの話はid:pepsin_amylaseのでっち上げです。