nakatani @ cybozu labs

プレゼンしているその画面の上に、聞いている人達のコメントがニコニコ動画風に流れるのが楽しいそうで。それ、Yahoo! Widgets でできるよ。
というわけでさっくり作ってみたのが LingrTickr です。

まず、名前からわかるように Lingr のルームを一つ作ります。
そしてプレゼンに使うパソコンにて LingrTickr 起動し、設定画面でその Lingr のルームIDを指定します。文字サイズ、フォント、流れるスピードなどもこの設定画面から行います。
これでそのルームでのチャット内容が画面上を流れます。簡単。
マウスやキーボードの全ての操作を透過するので、プレゼンツールによらずニコニコメソッドなプレゼンを展開して、愛のあるツッコミを全身で享受することが可能です。
ちなみに、チャット文の先頭に "green:", "red:", "blue:", "yellow:" などを付けることで流れる文字色を指定できたりします。

なお、LingrTickr は何もしていない時は画面上に何も出していないので、設定画面はタスクトレイの Yahoo! Widgets アイコンから開いて下さい。
同様に LingrTickr を終了させる時も通常の Yahoo! Widgets の方法では終了できないので、この設定画面にて「ウィジェットの終了」にチェックを入れて終了して下さい。

ツールを選ばないという特質から、プレゼン以外で使ってみても面白いかも。例えば、
・ペアプログラミングで「ぬるぽかよ……orz」とツッコんでみる
・スポーツの放送を観戦しながら、実況チャットをスーパーインポーズで流してみる。
とかとか。

---

≫5/7 更新

動的生成したビューオブジェクトの消滅処理を勘違いしていた（どうやら version="3.0" では delete 文は意味がないらしい）のでそれを修正しました（1000メッセージほど流してGCが働くことを確認したので、今度はおそらく大丈夫）。上記リンクから更新版をダウンロードできます。
また長いコメントは流れるスピードが速かったのですが（それはそれでおもしろいとも思ったけど）、やっぱり同じスピードの方が良いだろうと思ってそちらも調整してあります。

なお、Yahoo! Widgets さんは出し惜しみなしなので、アニメーションにCPUフルパワー使おうとします。
万一実利用を考えてしまった場合は、タスクマネージャから優先度を「通常以下」あたりに下げておいた方が幸せかもしれません。

---

≫5/2追記

ニコニコメソッドプレゼン - coding my life

あとは非公開の社内勉強会で気軽に使えたらいいのですが。というわけでぜひ親会社のサイボウズ社さんの方で製品作っていただいて、モニター協力させていただけないですかね :-)

ありがとうございます。是非製品化したいですね～ｗ。チャットエンジンとセットにして……（とうそぶいてみるテスト）。
Yahoo! Widgets は意外といろいろおもしろいです。日本語の扱いが若干怪しいところはありますが……こういう類のものを軽く作るのには悪くないです。

Apollo でニコニコメソッド プレゼン

リッチクライアント系の得意分野ですから、他の実装もあれこれできそう～。でも見た目ではさすがに macromedia に一日の長？

Erlang の「軽量プロセス間の非同期 tuple メッセージのやりとりによる分散」というのが今やっていることの色々参考になるんじゃないかという気がして、少し勉強ということで "Programming Erlang" をせっせと読んでみました。

＃Erlang のメッセージは別に tuple じゃなくてもなんでも送れます。一応念のため。

いきなり余談。"Programming Erlang" の書籍版はまだ出てないんですが、直販で $45.95、amazon.com だと $36.95 なのに、amazon.co.jp だと ￥7264 もするのはなぜ！？　まあ、PDF版 ( $22.50 ) を買ったので関係ないんですが。　（5/18 追記：Amazon に Programming Erlang をリコメンドされたのでふと見てみたら￥4,118 になってました。これなら書籍でも良かったかな～）
ちなみに、PDF 版を購入すると特典として「全ページ」に自分の名前を入れてくれます(笑)。買ってからダウンロードできるまでにえらい時間かかるなあと思ったらそんな事してたのね。

閑話休題。中谷は何か作ってみないとわからない人なので、分散に向いている何か題材は……という頃合いに こんな記事 を見かけてしまうわけです。
あー大昔に作ったなあ。あの頃は X68000 だったのでメモリがなく、深さ優先で作るしかなかったんだけど、200～300歩クラスの問題なら解けるところまではなんとかたどり着いたなあ（しみじみ）。

というわけで、「分散対応 倉庫番 solver for Erlang」です。
まあ Erlang の勉強の題材としてということなので、単純幅優先＆枝切り無しという solver としてはおもちゃなレベルなんですが、荷物３、４個の問題ならだいたい十数秒クラスで解けます。
注目を浴びている理由の 対C10K なネタじゃなくてすいません(笑)。

ソース： solver2.erl

関数型言語でまともにコードを書くのは初めてなので(XSLT除く)、おいおいなんだこりゃというところがぽこぽこあるでしょうが、生暖かくスルーするか添削してもらえると嬉しいです……

まずはシングルプロセスでの実行方法。

# カレントに solver2.erl を置いて、erlang を起動
$ erl

% モジュール読み込み
> c(solver2).

% 組み込まれているテスト用問題の解法を実行
% ######
% #@  .#
% # +++#
% # . .#
% ######"
> solver2:test4().
solution: 22 steps ([{5,3,"v"},{4,3,"^"},{4,2,">"},{3,3,"v"}]), goal (3, 3)
solution: 22 steps ([{5,3,"v"},{4,3,"^"},{3,3,"v"},{4,2,">"}]), goal (4, 2)
finish.

% 自分で問題を指定して解法を実行
% ##########
% #@.. #   #
% # +++    #
% ##.  #####
% ######    
% ・制限歩数 50
% ・自ノードで１プロセス実行
% 解法は複数出力されます。最短解法のみコピペ。
> solver2:start( [{self,1}], 
>  ["##########","#@.. #   #","# +++    #","##.  #####","######    "], 
>  50).
solution: 35 steps ([{4,3,"v"},
                     {5,3,">"},
                     {3,3,">"},
                     {4,4,"<"},
                     {4,3,"^"},
                     {6,3,">"},
                     {7,3,">"},
                     {8,3,"<"},
                     {7,3,"<"},
                     {6,3,"<"},
                     {5,3,"<"},
                     {4,2,"<"},
                     {4,3,"^"}]), goal (4, 3)

問題は下記のように記述します。ちなみに上記問題は自作ｗ
プレイヤー初期位置がゴール上な場合が記述できないですが、まあいいや。

 # : 壁
 @ : プレイヤー初期位置
 + : 荷物
 . : ゴール
 * : ゴール上にある荷物

解法結果は（歩数、解法履歴、最終のプレイヤー位置）が出力されます（最終のプレイヤー位置は意味なかったなあ……）。
解法履歴は荷物の座標と、その荷物をどの方向に動かすかで表示されています。座標は左上を（１，１）としています。


では、続いて分散実行の方法。

# マシン２にてノード名とクッキーを指定して erlang 起動
# 以降、マシン２は手を触れる必要はありません。
# マシン２台無ければ同じマシンでも可
$ erl -name sokoban2@192.168.0.2 -setcookie solver

# マシン１にてノード名とクッキーを指定して erlang 起動
# setcookie には上と同じ値を指定
$ erl -name sokoban1@192.168.0.1 -setcookie solver

% マシン１にてモジュール読み込み
> c(solver2).

% マシン１にて分散解法実行
> solver2:start( [{self,1}, {'sokoban2@192.168.0.2',1}], 
>    ["##########","#@.. #   #","# +++    #","##.  #####","######    "], 
>    50).

start() の第１引数で {ノード名, プロセス数} を列挙することで、指定されたノードにて分散解法が開始されます。モジュールは自動的にマシン１からマシン２に渡されて読み込まれるようになっているので、マシン２は本当に erlang を起動しておくだけでＯＫです。
手元の環境では上記問題は１台実行で１１秒、２台実行で７秒だったので、確かに分散の効果ありありって感じです(笑)。

というわけで、ここからはプログラムの説明。

前回の倉庫番solver for Erlang は Erlang の勉強のためだった割には Erlang の良さを活かしていないつくりだったので、もう少しまじめに作り直してみました。

ソース： solver3.erl

今回はひとまず分散は置いといて、軽量プロセスの恩恵を発揮させる方向で攻めています。

プロセスの構造は manager と solver の２種類だけ、やりとりされるメッセージは基本的には solver → manager の branch メッセージだけという簡単なものに。
manager は branch メッセージを受け取ったら、最大歩数を超えてないか、解けてないか、探索済みの局面ではないかをチェック、問題なければ solver プロセスを起こしてデータを渡します。
solver はデータを１手進ませた枝（その局面で押せる荷物を全部押してみたもの）を作り、branch メッセージに付けて manager に送ります。

前回のプログラムは solver プロセスの数は固定、生存期間は解法開始から終了までというものでしたが、これは Erlang にはちょっと適してなさすぎでした……。今回、生存期間は１手進ませる間だけ、プロセス数も状況の許す限りという形に変わっています。
また solver の処理そのものも Erlang のリストを間違った形で使っていて（参考１・参考２）、「重量プロセス」になってしまっていたのを改め、タプルで良いところはタプルに、リストを残すところは正しく「リスト」として使うように変更（これが一番大変だったかも。自分の頭の中身から変えていかないといけないので……）。立派な「軽量プロセス」に生まれ変わりました。

これで解法実行すると、解ける問題は数秒で解けるのですが、そうでない問題は瞬間同時プロセス数 1000～1500 くらいでがんがん探索を進めた後、１分くらいでメモリ不足で落ちます（苦笑）。同時プロセス数が 1000 程度で頭打ちになってしまうのも、メモリ不足に陥るのも、どちらも探索済み局面チェックがボトルネックになっていることがわかっているんですが、そこを Erlang でがんばるのは大変そうなので見ないふりしてます……
ともあれ、そのわずかな時間の間に延べ数十万プロセスをハンドリングできているので、さすがは軽量プロセスの面目躍如というのを感じさせられました。

ちなみに探索方式についても、本当の最低限（評価関数すら導入してない……）ではあるんですが、単純な田の字（荷物がかたまって動けなくなった状態）の枝切りと、探索済みの局面チェックだけは行うようにして、ちょっぴり性能向上しています。
解法アルゴリズムの何が楽しいかって、前回のプログラムでは全く歯が立たなかった問題もこういった工夫を加えていくことで、わずか数秒で解けてしまったりするところ。昨日丸一日解法プログラムを走らせていても解けなかった問題が（今回のプログラムはそこまで行く前に落ちますが……）、あっけなくパンと解けたりするとぞくぞくしてしまって、じゃあ次はあの問題だ！　とかなっちゃうんですよね(笑)。

プログラム的にはだらだら長い田の字チェックが追加されているくらいで、それ以外は前回のものよりずっとシンプルになってしまい(プロセスは２種類、メッセージ１種類、solver もループしないし)、わざわざ説明するところがない感じ……
じゃあいっそ、前回は省略してしまった倉庫番解法まわりの説明でもしてみましょうか。

Twitter ライクなサービス「もごもご」に API ができたということで、もうこれは早い者勝ちだろ～と、Yahoo! ウィジェット 版クライアント Twiggee を Twitter & もごもご両対応にいたしました。

設定画面で もごもごのログイン用メルアド＆APIパスワードを設定することで、もごもごの「いま、なにしてる？」更新と「みんなのもごもご」の確認が出来るようになりました。
また両対応の名に恥じないよう、Twitter だけ、もごもごだけ、Twitter & もごもごの併用に対応しています。併用する場合、ステータスの更新は両方に対して行われますが、自分のステータスは Twitter のものだけが表示されます。

また、以前のバージョンでは長いステータスが自動スクロールするとちょっと負荷が高くなってしまう場合があったので、表示している範囲のみ自動スクロールするように変更しました。これでかなり Twiggee の動作の負荷も減少したのではないかと思います。

ちなみに「もごもご」のAPIですが、もう Twitter そっくり(笑)。XML フォーマットで Twitter クライアントを作っていたなら、URL を変えるだけでほぼ対応できたかもしれません。
ただ、若干の難があります。

・friends_timeline の since に指定する日時のフォーマットが、created_at のフォーマットと違っているので、自前で変換しないといけない
・レスポンスはXMLながら、Yahoo! Widgets の XHR では responseXML で DOM が取れない（おそらくヘッダの content-type が間違っているため？　未確認）。自前で XMLDOM.parse する必要がある。

まあα版ということですし、おそらく遠からず改善されるのではないかと思います。

しっかし、ユーザがまだ多くないからでしょうけど、それにしても もごもごの動作は軽いなあ～。