論文を書こう・自動化のススメ

先週、諸般の事情によって実に3年ぶり（！）に論文を投稿しました。いろいろと時代は変わったわけで、やや出遅れ感はありますが時代にあわせた執筆スタイルにしようとしていろいろ試行錯誤してみました。普段バリバリ論文書いている方々にはむしろ時代遅れの内容のような気がしますが、未来の自分のためにも結果をまとめておきたいと思います。

自動化は正義

自動化できることはなんでも自動化することで、未来の自分を救います。「どうせ一度しかやらないし」と思っているあなた、本当に一度ですむと思っていますか？ LaTexのコンパイルは論文提出までに何百回実行しますか？ その評価のパラメータ、本当に正しいですか？ 実験データは何回更新されますか？ むしろ、今まで一度で済んだことがあるんですか？ （ということで、一度ですんだことがある人にこの記事は不要です）

自動化のメリットは主に2つだと思っています。1つ目は言わずもがなですが、人間の作業を省力化できること。これは単純に作業時間を短縮できるというだけでなく、いちいち気持ちの切替をしなくていいというメリットがあります。論文執筆では思いの外いろいろな作業をしなければならないので、なるべく大切な作業に集中できるように、機械ができる仕事は機械にやらせるのがよいです。2つ目は各種作業の再現性が高いことです。論文投稿した結果、めでたく（？）条件付き採録で返って来ました。でも評価が足りないからもう少しデータを足してね、という査読者からの指摘があったとき、「あれ、この評価ってどういう手順でやったっけ？」という記憶喪失事件は枚挙に暇がありません。その結果、同じデータを使っているはずなのになんか結果が微妙に違うのはなぜなんだぜ…、と悩んで時間を無為に消費してしまうこともあるあるだと思います（僕だけ？）。

もちろん自動化するということは、それだけ初期投資が高くつくというのは間違いなく、かつ忙しい時にそんなことをしている暇など無い！という考えも、もっともだと思います。ただ、忙しくなるほど手間を省き手順通りに作業を実行してくれる自動化の恩恵が大きくなるのも事実です。最終的には個人のバランス感覚だと思いますが、個人的には今後も積極的に自動化していきたいと思っております。

LaTexからPDFの作成

自作のautobuildというツールを使いました。指定したファイルの更新を検知して、特定のコマンドを走らせるOMakeなどのツールと同じ発想ですが、極力シンプルに動作するものが欲しかったので、ちょろっと作りました。nodejsで動く60行ほどのしょっぼいコードです。（oremakeというツールを参考にさせてもらいました）これを使って*.texや*.epsファイルを指定し、変更があったらplatexなどを自動的に走らせることが可能です。私はMakefileにコマンドをまとめていたので、設定ファイル(build.js)はこんな感じ。同一ディレクトリの*.texファイルとfigsディレクトリの*.epsファイルを指定しています。

{"build_command": "make",
  "build_args":  [],
  "file_list": {".": [".*\\.tex"], 
                "figs": [".*\\.eps"]}
}

執筆はMac上でやっていたので、PDF viewerにはSkimを使っていました。Skimはファイルの変更を検知してファイルの再読み込みをしてくれるので、継続的に自動ビルドされれば勝手に表示を更新してくれます。今まで「ファイル保存 → ターミナルに移動 → makeコマンド実行 → 完了後にPDF viewerを一度閉じる → PDF viewerを再度開く」みたいな行程が必要だったのが、ふと横を見ると常に最新版のPDFが見れるようになります。

テストの実行

皆大好きJenkinsさんの登場です。今回は実装の一部をC++で書いていたので、コンパイルは先程のautobuildというツールを使っていましたが、デバッグ作業をしている時は変更とコンパイルを繰り返さなければならないので、その度にテストが走るというのは少々、いやかなり鬱陶しいわけです。というわけで、今回はJenkins（またのなを高機能crontab）を利用して定期的にテストを実行するようにしました。これはこれでテスト結果がおかしいままだと、際限なく「早く直せよー、おらー」と言うメッセージが出続けるので別の鬱陶しさがありますが、ToDoをせっつかれるという意味では良いのかもしれません。

設定は5分毎にコンパイル実行＆テストコード実行で、終了後にPost build taskでスクリプトを実行させました。実行時にテスト結果などのステータスを直接環境変数で渡せないのがちょっと面倒でしたが、HTTPでJenkinsをたたけば結果を返してくれるのでお手軽です。こんな感じのスクリプトを用意して実行していました。テストに失敗するとGrowlが失敗メッセージを表示し、マリオが死んだ時のSEが流れます。（本当はGrowl pluginとJenkins sound pluginで実行すればいいだけなんですが、なんかうまく行かなかったので）

評価の実行

普通、評価は条件をそろえてやるものなので、継続的に結果を出力し続ける必要はないと思うのですが、手順をまとめて実行できるようにしておくことは必要だと考えられます。あくまで個人的な経験ですが、ソフトウェア（あるいはPoCコード的なプロトタイプ）を実装して、その出力をそのまま評価結果として使えるというケースは稀だと思います。だいたいは10段階ぐらいのone liner shell scriptをかませたり、適当なスクリプトを書いたりして結果を正規化、集計することが多いと思います。しかし、往々にして後からどういうone linerを実行したかわからなくなったり、断片的なコードが散乱したりという自体に陥ります（僕だけかもしれませんが）したがって、テストの実行とデータの加工までを一気通貫で実行できるというのがとても便利でオススメです。

特にこれといったツールやフレームワークがあるわけではないですが、データの加工まで一気にやることを考えると、Shell scriptで頑張るのはちょっとしんどい事が多いので、少なくとも一部はPythonやRubyなどお手軽にデータ集計ができるLLを導入するのがよいかと思いますが、そこは個人の趣味で。

グラフの作成

いくつかグラフ作成ツールを試してみましたが、結局某先輩に教えてもらったmatplotlibに落ち着きました。最大のポイントは自分がPythonでデータ加工など大まかな処理はPythonにべったりだったので、習得が容易である＆データをそのまま流し込めるという2つのメリットがありました。ggplot2とかも検討したのですが某氏の「ggplot2は3日経つと使い方忘れるあたりで挫折した」という発言に胸を打たれて諦めました。

評価とグラフ作成は別々のスクリプトでまとめていましたが、Makefileで連続実行できるようにしておくと、make testとか打ち込むだけで、

1. 自分の実装と関連研究の実装を順次実行
2. 実行結果の集計
3. グラフ作成 + epsに出力
4. epsの変更を検知してPDFを再出力
5. 最新のPDFを表示

までをフルオートでやってくれるようになります。

さいごに

まとめてみたものの、改めて見返してみるとほとんど当たり前のことばかりでしたが、これで救われる学生さんとかが1人でもいれば嬉しいです。あと「なんという時代遅れ。今時こっちのツールだろうJK」みたいなツッコミがあればぜひこっそり教えてください。

nodejs addon サンプルコード

サーバサイドのJavaScriptエンジンであるnodeで遊ぶことがあったので、addon作成時にまとめたサンプルコードを貼り付けておきます。addonはC++で記述できるので、サンプルとしてまとめたのは

• 引数＋返り値のオーソドックスな関数呼び出し
• 新しいオブジェクト（連想配列）を返す
• 処理の途中でコールバックを呼び出す
• 独自のC++クラスを使う
• 独自のC++クラスにコールバックを設定して任意のタイミングで呼ぶ
• libuvで非同期処理させる

です。サンプル本体はgithubにおいてあります。基本的には公式ドキュメントを参考にしているだけなので、必要に応じてそちらも御覧ください。あまり深く検証しているわけではないので、特にご利用は自己責任でお願いします。

「オンラインゲームを支える技術 --壮大なプレイ空間の舞台裏」読んだ

新年読書大会第二弾。オンラインゲームを支える技術 --壮大なプレイ空間の舞台裏を読みました。別にゲームを作りたいとかではあまりないのですが、オンラインゲームはよくやるので、興味本位で読んでみました。ちなみに、ここではソシャゲのように非同期で連携するものではなく、リアルタイムでユーザ間のインタラクションがあるものが想定されています。

IT技術中級者〜上級者向け

内容としてはオンラインゲームの歴史にはじまり、どのような企画ができるか、インフラ（ネットワーク、計算機）の見積りはどのようにすればいいか、どのようなアーキテクチャが考えられるか、パフォーマンスを維持するにはどうすればいいか、運用はどうすればいいか…、というようなことがかなり広くざっくりと書かれています。「ざっくりと」というのは決して適当に書かれているという意味ではないのですが、それぞれの話の粒度がまちまちな印象でした。新しいゲームを作るための企画段階の話から、具体的なコードはどのように書けるか、というような話まで、かなり雑多に入り交じっている感じでした。

これはどういうことなのかというと、おそらく「君はそれなりにIT技術者として経験積んでいるつもりかもしれないが、オンラインゲーム業界に行こうと思ったらここに書かれていることぐらいは押さえておいてね！」ということなのかと思いました。自分はCSの基礎は嗜む程度にやっていますが、あまりエンジニアよりの職種ではないで、ゲームならではの視点みたいなところで「なるほど」と思うところは多かったです。

先に書いた通り、この本ではリアルタイムでのオンラインゲームを重視しており、最近のソシャゲの隆盛を考えると今後どうなるかよくわかりませんが、その方面に就職・転職を考えている人は一読して、ここでのべられている能力（技術・政治・金勘定）が網羅できているか考えるとよかったりするのでは、とか思ったりします。・・・実際どうかは本職の人に聞いてみたいところですが。

「デザイニング・インターフェース ―パターンによる実践的インタラクションデザイン」読んだ

正月休みを利用して、デザイニング・インターフェース ―パターンによる実践的インタラクションデザインをざーっと読みました。
だいぶ前に買って積み本になり、引越しするときに実家に放置してきたのですが、UIを作る機会がちょこちょこ出てきたのと、実家に帰る＆休みができるというイベントが重なったので、一気に走り読みしました。

基本的には事例集

プログラミングにおけるデザインパターンと同じように、UIのデザインをする際にどのような鉄板手法があるか？ ということをまとめた本です。数が多いのですが、「グローバルナビゲーション（全頁に共通して定常的に使えるナビをおく）」や「動的なメニュー項目（必要に応じて項目を有効化・無効化・追加・削除）」のように様々なアプリケーションで使われている手法なので、言われてみれば「そりゃそうだね」と容易に理解できるものですが、いざ自分がそれを使おうとしたとき、各機能がどのような特性を持つのか？ということが良くまとまっていました。

おそらく、プロのUIデザイナーの方々は経験則として知っていることばかりなのだと思いますが、UIデザインが本職ではないんだけど、UIデザインをしなければいけなくなった！ というような人が、どのような機能をどう組み立てていけばいいのか、この機能はどういう状況なら有効なのかを調べつつ使うのに適しています。本の中には9つのデザインに対する考え方がそれぞれ概論で示され、その後個別の100個弱のパターンが細かく解説されています。よくデザイン解説のWebページなどでは直感的に解説されていることが、（少なくとも自分の知っている範囲では）体系的に説明されているため、わかりやすく、自分がそれを使おうと思った時にも安心感があります。

UIデザインの素人だけどUIを作らねば、という人は手元にあるといいのでは

自分のように特にデザイン能力が高くないんだけどUIを作らないといけない場合、手元1冊において辞書的に使うのがよさそうな良書だと思います。UI（ユーザとインタラクション）がある部分に特化しているので、カッコイイ感じのデザインができるようになるというわけではないんですが、定石がまとまっているので、使いやすいさの向上には大いに役立ちそうです。