題名:Java Diary-108章

五 郎の 入り口に戻る
日付:2012/8/5
目 次に戻る


Gozen - Part3

論文をだしてしまうと、Gozenの開発は一旦お休みである。私は別の裏プロジェクトにとりかかる。(表の仕事はちゃんとやってますよ)しかし査読結果の事はいつも気にかかっている。去年まではプログラム委員をやっていたので会議の様子とかなんとなく把握できた。今年は「去年はこの時期に会議があったから」とか推察するだけである。

WISSのホームページには

「2012年10月 5日(金)  登壇発表採択結果通知」

と書いてある。その日になればきっとあれこれ悲喜いずれかの感情がわき起こってくるのであろうな、と思っていた9月27日の金曜日。それは突然訪れた。

「このたびは WISS 2012 への論文投稿をどうもありがとうございました。
貴殿の投稿された以下の論文は、WISS 2012 プログラム委員会における厳正な審査の結果、登壇発表として条件付き採択されました。
今年は57件の投稿から、条件付き採択を含む24件が採択されました(採択率 42%)。」

うわっと私は叫び声を上げる。なんだこれは。しかも初めて見る「条件付き採択」である。ああ、なんということだ。もちろん条件付きではあれ、採択されたのはいいニュース。しかし採択だが条件がついているのだ。期限までに論文を直して提出し、再度認可をもらわなくてはならない。つまりそこで「やっぱり不採録」もあり得るということだ。

いつも査読者からのコメントを見る前に一週間はうだうだする。だって怖いんだもん。しかし今年はそんな贅沢は言っていられない。いますぐみて論文を修正しなくては。しかしそれをやっても通るかどうかわからないのだ。

折悪しくこの頃表の仕事もかなりつまってきており、そこに追加+不確定要因はつらい。という具合に頭を抱えていたところ、次のメールが(13分後に)届く。

すみません,先ほど「条件付き」で送ったメールは間違いですので破棄してください.

-----------------------------------------------------------

は?私は口をあんぐりと開ける。今度のメールではただ「採択」と書いてある。これはどういうことだ?しかしどう読んでも二通目のメールは「採択」とある。よし。こうなったら条件付き採択で論文修正が云々の話は忘れてしまおう。そうしよう、と心に決める。

Twitterをあれこれ見ると、何人かが確かに査読結果を受け取っているようだ。となると一週間前だが結果が送付されたのは間違いないらしい。よし、とりあえず見なかったことにしよう。今こうして書いてみると気が狂っているとしか思えないが、その時は本当にそう考えていた。

というわけで私は表の仕事に励む(普段は違うのか)あれこれ作って目処が立つと、いろいろな問題が心の中にわき起こってくる。まずやってくるのが論文の修正。そのためには査読コメントを読まなくてはならない。例によってさんざん逡巡したり、わざと目のピントを外して読んでみたりしたあげく、コメントを読む。ふむふむ。指摘された点のなかから特に心に残った点を論文に反映させる。明らかに意図が伝わっていない、と思えるコメントもあるが、こういう時は、「論文の書き方が悪かった」と反省するのが正しい論文執筆者の態度なのだそうな。

というわけで論文は再提出してしまう。しかし問題は山積みだ。変な言い方だが、これでこのシステムをお蔵入りにすることはできなくなった。例えば他のアプリケーションならば、既に論文提出の時に撮影したビデオを使い回して発表をすることもできるのだが、今回のはプレゼンテーション用のシステムだ。つまり定義によってシステムを使ってプレゼンを行わなくてはならない。私はここ数年人前でプレゼンするときには、作ったシステムを動かすことを慎重に避けてきた。自分が作ったものが肝心な時に動くと思うほど私は自信家ではない。しかし今回それはできない。

正直いって、直したいところは山ほどある。しかし悪い要素が二つあった。まず10月20日にこのシステムのデビュー戦が控えている。それまでは大規模な改修を行うことができない。さらにWISSは12月の初旬だが、11月には2週間の海外出張が控えているのだ。つまり実質的には2週間ちょっとしか改修の期間がない。

などとキャーキャーわめいていても事態は改善しないので素直に直近のプレゼン準備を行う。何かと言えば、楽天という会社で年に一度行われるテクノロジーカンファレンスなのだった。正式な講演ではないが、5分間でしゃべる「ライトニングトーク」なるものがあるらしい。そこで表の仕事を発表しようと考えたのである。

さて、このプレゼンには特殊な事情があった。楽天株式会社の社内公用語は英語であり、この日のプレゼンも英語で行う事、となっていた。とはいえきっと聴衆の大半は日本人に違いない。私の英語はカタカナ英語だし、どちらにしても難しいことをしゃべることはできない。だから「解ってもらえるだろう」と期待もできるがそれだけにたよっていいものだろうか。よし。ここは字幕を出しましょう。

というわけでさっそくGozenの機能が活躍する。例えば同じ写真を見せながら、下に出す字幕だけはどんどん変えたい、という場合があるわけだ。これを「スライド」でやろうとすると同じ写真を出したスライドをたくさんつくるか、がんばって字幕を「アニメーション」機能を使って差し替える必要がある。しかしそれもGozenのプログラミングで書けば簡単だ、、とはならなかった。この時点では
「表示されているものを差し替える」
という機能がなかったのである。がんばって実装を追加するが、途中で「これはかなり考えないとできない」という結論に達する。しかし今は深く悩み大幅に変更する余裕は無い。どう考えてもおかしいのだが、「とりあえず動く」方式で妥協する。(結局この「妥協した」方式は最後まで残る事になる)

あれこれプレゼンを作っているうちに、そもそもアニメーションの実現方法がおかしいのではないかと思い当たる。ここでちょっと長い話をする。何度か書いた事だが、Mac OS Xの母体はNext StepというOSである。だからクラス名の頭にNSがついている。何かを表示する際に使う土台となるのがNSViewなるクラスだ。

しかし時代は変わり、iPhone,iPadに搭載されているOS XではそれがUIViewなるものにかわっている。NSがつくクラスも已然として使われているが、だんだんUIではじまるクラスが増えてきている。しかもこちらのほうが新しく作られただけあって使いやすかったりする。

それまでの一年間、UIViewの上であれこれやるプログラムを書いていた。それゆえ、NSViewに戻ったときはその上でアニメーションをするのが難しいことに驚いた。あれこれ探して、ようやく動かす方法を見つける。こんなんでいいのかなあと思いつつも動くからまあいことにしていた。しかし実際にプレゼンテーションを作ってみると、どうもおかしい。そもそもこれでは二つの物体を違うタイミングで動かすことができないではないか。問題にきがついたが今はなんともならない。とにかく楽天でのプレゼンに集中しよう。というわけで準備を続ける。4分間の短いプレゼンであり、かつそのうちの半分はビデオだ。だからGozenが制御するべき項目はそう多くないのだが、そもそもこのシステムは肝心な時にちゃんと動いてくれるのだろうか。

前の章 | 次の章


注釈