今回は数年ぶりの参加で、@riesz先生と一緒にMox Camlというチーム名で出ました。@riesz先生による記述はこちら。

前日の夜遅くにPNGを解析して”Lambda The Gathering”であることを知るも、”Lambda”よりも”The Gathering”に引っ張られてギャザリングのルールを教えてもらったりしていました。カードを何枚手元に置けるとか。。。ここで”Lambda”の方を学んでおけばもうちょっとマシな結果だったかもしれないです。

当日朝起きて、問題を読みながら移動。合流して問題の内容を確認。ギャザリングについて調べつつチーム名を決めました。（Mox RubyとかMox Pearlとかいう強いカードがあるらしいです）

シミュレータはどうみても関数型言語で書くべきだろうということで、OCamlで書くことにしました。OCamlは私が全然書けないという問題はありましたが、昔exampleプログラムとかは書いたことあるはずなので採用。シミュレータに全ステートを出力させて、C++のルーチンで手を考えるという可能性も検討しましたが、自由度が下がりそうなので避けました。

夕方ころ、match構文や再起の使い方を学んでいる時点で、@riesz先生がシミュレータを完成させました。このシミュレータの完成度は高く、後に2箇所小さな修正が入るものの、他は完全に動作していました。初日の夕方にこのレベルのものがあったのは大きなアドバンテージだったと思います。

その後どういう抽象度で思考ルーチンを書くかという議論をしました。各ステートに置いて、複数の取り得る手から最善の手を取るという観点から、後に評価関数を作れるような仕組みにすることや、ある程度大きなまとまり(attack(i, j))のブロックでプログラムを構成し、一度決めた動作は必ず実行するという仕組みにすることなどを検討しました。議論の末、相手の攻撃などで状態が常に変わり続けることを考え、ステートレスに毎回状況を判断して最善のことをするという構成にしました。

Exampleをきちんと見ていなかったため、attackやhelpなどの使い方が分からず、いろいろいじってみたりGoogle先生をフル活用したりして、なんとか使い方を「発見」していました。それをステートレスを前提としたコードにある程度見やすく書く方法を模索したりして、この日は終了。

2日目は「いろいろな機能を追加する日」であると信じて始まり、必要に応じてHelpを実行したりする機能の追加などをしていました。Invalidでの負けが多かったので、HelpやAttackの構築途中や発行時点で引数の値を確認する仕組みを作ったりなど。この時点ではまだ繰り返しが実現することを知らず、「くり返しとかはできないようにルールを作ってあるんじゃないかな」とか今考えればとんでもないことを言っていました。ルールを読み直していた@riesz先生がApplication Limitについて書かれていることを発見し、もしかしてループが可能なのではないかという説が再び浮上し、SKIをひたすら捏ねくり回した末に（まだ親切なExampleの存在を知らず）ループが構成可能なことを発見して驚いていました。

2日目未明〜3日目は、@riesz先生はループによるHelp爆弾を作り、その後も新たな兵器の開発に注力していました。その間にぼくは新たに得られた「殺されて爆弾を埋め込まれたらおしまい」という知見を元に「殺されない」ようにする努力をしていました。敵が構成中のAttackを読みだしてスロットが死ぬ危険があれば早急にHelpの用意をはじめるといった仕組みや、ステートレスの利点を生かしてHelpやAttackの対象を柔軟に変更しつつも、行動の変化によって構築途中の式が無駄になりにくい仕組みを作っていました。

最終的に出来上がったものは、8割方勝つくらいのものでした。調子がよければExcellentですが、そうでなければ普通に戦って勝ちます。負ける時も、Excellentで負けたり、戦って競り負けたり。

もうちょっと早い段階からSKIで何が出来るのか真剣に考えていれば、もうちょっといい結果が出せたかもしれないです。問題文は隅々までよく読みましょうということですね。あとは、2人チームというのは中途半端だったかもしれないです。2人しかいなくてもコード共有や他人のコードを理解する作業などの手間はかかるので。プログラムが小さいうちは「パッチができあがった頃にはプログラムの構造が変わっていて全部書き直し」みたいなことが結構ありました。普通ならシミュレータ係とAI係みたいに分けるところが、@riesz先生が一瞬でシミュレータを作ってしまった一方ぼくはOCamlの文法を調べていために分担などなくなったというのも原因だと思いますが。

学んだこと：
・問題文はよく読みましょう。
・モジュール分けとか、コードの管理をどうするかとか大切。
・学校の授業はちゃんと聞いておきましょう。SKIコンビネータとか聞いたことはあったのに。
・関数型言語１つくらいちゃんと使えるようにしておいても悪くない。

とても教育的な問題でした（少なくともぼくにとっては）。計算理論についてもですし、関数型プログラミング言語についても勉強になりました。何日も1つの事に集中する経験ができて、久しぶりに関数の世界に触れられて、楽しかったです。すばらしい問題を作っていただいた運営者様と、足手まとい感満載のぼくに付き合ってくれた@riesz先生に感謝感謝です。

では、おやすみなさい。

具体的には、Plaggerでmixiの日記をとってきて、RSSにしてGoogle Readerで読んでます。快適。もっといい方法あったらぜひ教えてください！

Google App Engineとか使ってみようと思って試しているうちに、ふとevalが使えるか試したところ使えたので、MapReduceをGAEでやってみました。完全におもちゃですが、何かできそうってことは伝わるかと。

Javaを使う機会は少ないので、恥ずかしいことにこんな会があること自体知らなかったのだけれど、知らない世界を見ることができて楽しかったです。

もともとJavaがエンタープライズで花開いたこともあって、エンタープライズでの利用に関する視点での話が多く、その視点での知識がほとんどないぼくには勉強になりました。データベースを中心に設計されているシステムをいわゆるCloudに移行するためには、データベースを分散可能な形にしないといけない。でもエンタープライズではACIDのトランザクション特性が本当に重要な場所も多かったり、また本当は重要ではなくてもその特性を利用してシステムを作ってしまっているため移行はなかなか難しい。みたいな。

でも、分散データベースの利点に関する認識は広まっているし、とりあえずたくさんの人がスケーラビリティに興味を持ってきはじめているという印象をもちました。

あと、関係ないけどScala使ってみようと思いました。

1. 就職しました。
   もう１年前です。
2. 一人暮らしはじめました。
   家具選びとか楽しかった。いまもまだ続いています。
3. １年で合計３ヶ月くらいアメリカで生活してました。
   2006年にも３ヶ月いたので、結構楽だったかな
4. お国にスーパークリエイターとして認定されました。
   どういういいことがあるのかは謎ですが、ありがたいことです
5. 自分の作ったもの億単位の人に使われるように
   これはけっこううれしい。１機能を作っただけだけど

こんなもんでしょうか？ こんなの知り合いの人はみんな知ってるかなと思いきや、そうでもないっぽいので。就職して１年経っての感想は、やっぱり世の中すごい人は無尽蔵にいるということを思い知りました。ぼくもがんばっていこうと思います。

ありそうな影響：

・携帯では見られないコンテンツが多くなる→PC使うようになる→コンピュータリテラシが向上する

・新しいサービスを作っても未成年はほとんどアクセスできない→中高生の携帯利用者が少ないのと同じ状況→「モバイル向けサービスはおいしくない」となる

・勝手サイトはアクセスできないことが多い→キャリアの公認サイトが躍進→キャリアの力増大

総じて、ここ何年かのモバイルの躍進と勝手サイト急増という傾向が急激に逆方向に向かうんじゃないかと思う。

フィルタリングについてはたくさんの人が賛成・反対いろいろいっている。おーくらとしては、当事者でもないし、どちらの意見ももっともだと思う。ただ、モバイル向けサービス事業者は大変ですよね。こういうことが急に平気で行われると、国内でのサービス開発における余計なリスクが増えて（コスト増大に相当）良くないと思うんだけどなぁ。最初からフィルタリングするならともかく、途中で急に導入するのはどうかと思う。

まぁなんにせよいろんな人に会うことはすなわちいろんな経験を持っている人に会うということなわけで、小説を読むことによる疑似体験じゃないけれどバーチャルな経験値が上がります。まぁ経験値を得ることとワザを使えるようになることは等価ではないので何かにすぐに役立つわけではないですが。でもよいことかと思います。