うかべん 大阪 #4 簡単な纏めと感想

伺か周辺のネタを発表し合ふ「伺的ソフトウェア勉強会」，略して「うかべん」といふイベントがあります。今回は2008年11月3日に難波で開催された「うかべん 大阪 #4」に行って来ました。講義内容は公式サイトの各資料や他の方のレポートを見れば解るので，ここでは私が個人的に，簡単な纏めと感想(⇒の後)を述べます。一部敬称略で失礼します。

時系列に従った纏め

今回の参加者は，私が朝に見渡した限りは約30人でしたが，最終的には約40人に達したさうです。勉強会毎に増えてきてゐるのだとか。

[10:35] ぽな@ばぐとら: 開会の挨拶・聯絡

11月2日は何の日? …ぽなさんの誕生日! ⇒おめでたうございます! 会場からも暖かい拍手が。

「伺的」: 技術分野に限らず，気軽に開発ネタを話し合って欲しいとの思ひ。⇒ぽなさんはSSPの偉い人(一作者)として，良いツッコミをしたり弄られたりしてゐた。

[10:47] 早坂千尋: 「伺かをフロントエンドに使ってみたら」

SETIの進捗をモニタリングするSAORIを作り，ゴーストに喋らせてみた。伺か自体がリソースを喰ふので実用的ではない。技術デモ止り。

コンピュータが単なる事務機械なのは情けない。(SFチックに)寝てる間に空気を読んで仕事をしといて欲しい。人はキーボード・マウスに拘束されるべきではない。⇒究極的にはさうあるべき(コンピュータを意識しなくても誰もが仕事を機械に任せられる)だが，私が生きてゐる間にその域に達するか。

伺かをフロントエンドとしたタスクの自動実行。最近は流行らないの? ⇒みんな飽きっぽいから?

加速度センサを利用してゴーストを動かす。一部のThinkPadには標準で内蔵されてゐることを知らない人が多い。⇒私も知らなかった。うにゅうが滑り落ちてゆく様はシュール。

[11:15] 休憩

[11:26] どっとステーション駅長: 「やめといた方が良い栞の作り方」

SHIORIを作るのは理系のマゾ以外止めとけ。⇒私のことですね，わかります。

SHIORI: API呼び出しに応じて(主に)会話を返すDLL。ゴーストの会話を制馭するエンジン。SHIORIを作る=APIをDLLに実装する。

世の中の出来事の順番は決まってゐない。因果はそれぞれ個別に存在する。神様はどうやって世の中を管理するか…フラグ(条件)とそれに対応するイベント(行動)を集めた膨大なルールブック，つまり辞書を持ってゐる。

辞書管理方法が肝。会話の組み立て方と速度が問題。ここに推論エンジン(ルールエンジン)を使ってみる。

ルールエンジン: 最近金融などで流行の兆し。モノ自体は1960年代からある。

CLIPS: ルールエンジンの一実装。文法はほぼLISP。組み込み向けで速いが入出力が弱い(プリミティブな入出力函数が少ない)。素性が良く(他のDLLへの)依存性が少ない。但しファイルサイズは大きめ。⇒ルールエンジン自体知らなかったが，LISP風と聞いて俄然興味。

前向き連鎖と後ろ向き連鎖。CLISPは前向き，つまりフラグが立ってからイベントが発火する。事実駆動ともいふ。後ろ向きは詰め将棋のAIなど，原因を推論したい場合に用ゐる。

SHIORIへの実装は…? できたとしてもデモのしやうがない。SAORIにはデカ過ぎる。⇒もしかしたらベースウェア(SSP等)向きかも，との意見が出たが，会話などを作るのはやっぱりSHIORIの仕事であるべき，との別意見。

CLIPSはトレースも簡単(イベントが何故起こったのか，原因が直ぐ解る)。イベントの同時発火可。LISPのマクロのやうに，自己プログラマブルかどうかは不明(後ろ向き推論が必要かも)。ルールは動的に変更可。⇒イベント管理のみに特化した印象。確かに伺か向きかも。

[12:14] 昼食休憩

会場の直ぐ上のフロアがレストラン街。値段は百貨店並み，廉くはない。

[13:01] ケノ: ライトニングトーク: キャラクターなんとか機のゴースト版

そのまんま。着せ替へ・色変更・ユーザの自作パーツ追加可能。パーツは必ずカテゴリに属し，z軸(重なりの優先順序)はカテゴリで決まる。最終的には着せ替へセットをシェルとしてZIP出力可。将来的にはゴーストの出力も…? ⇒その場の意見でも出たが，もうかなり出来上がってゐる印象。何をするゴーストなのかが非常に解り易い。

[13:11] しらたま: ライトニングトーク(飛び入り): なでしこ勉強会の宣伝

[13:15] どっとステーション駅長: 懇親会参加者の最終集計について

[13:18] しお: 「シェル@SVGのはなし」

SSPでシェルとしてSVGを使ふと拡大・縮小しても綺麗だよと述べようとしたら，SSPがSVGに対応してゐなかった羂。⇒しかしぽなさんの「実装します」宣言。流石! 心強い!

SVG等のベクター画像は，パスを引くのが慣れるまでしんどいのと，複雑な色を表現しにくいのが缺点。簡単な変形はパスの点を動かすだけなので得意。⇒例ではInkscapeが出てゐた(他にSVGで保存できる無料のお絵描きツールは少ない)。私も実はレポートの図(簡単な白黒絵)を書くとき等に利用してゐる。キャンパスサイズを変へるとグリッドがずれるのがやりにくいし，何か全体的に重いのだが，最近は慣れてきた。ベクターを扱えるのは大きい。

[13:40] 休憩

[13:55] さとー: 「梨の季節」

華和梨の話。良いエディタを使ってKIS(辞書)を編輯しよう。⇒例ではサクラエディタが出てゐた(KIS用のキーワードファイルもある)が，私としてはxyzzyも御奨め。特にparenが便利すぎる。

デベロッパとして標準的なデバッグの仕方を実演。リアルタイムモニタリングツールとしてtailが便利。(ぽなさんのツッコミ)最近SSPにもリアルタイムログが実装された。⇒printfデバッグ等，やはり共通なデバッグの文化があるんだと再認識。

[14:36] 休憩

[14:48] 酔狂: 「Webカメラでゴーストとお話」

Augmented Reality(拡張現実，AR)。ゴーストに対するマウス・キーボード以外のアプローチとして，ウェブカメラを使ってモノとディスプレイの距離を計測し，モノがディスプレイに接触したり，或る特定の動きをするとゴーストが反応，といふ形が理想。今回は認識制度が向上した所まで。

会場の照明が明る過ぎて，手と背景の区別が認識されず。照明を落としたら，手が暗過ぎて認識されず。会議用の部屋は照明の調整が難しかった。⇒恐らく一般家庭の環境なら割合上手く行くのだらう。ノートPCなら本体を動かして照明の良い場所まで持ってゆくのは簡単。

カメラに偏光板を上手い角度で(液晶が透過する偏光方向と垂直に交叉するやうに)附けると，カメラから見たディスプレイが真っ黒に映る。当然液晶ディスプレイのみ可。キャリブレイションは最初に一回，ディスプレイにモザイクパターンを映して行ふが，その際には偏光板を外す必要があり，多少面倒。

近づけるモノは今は取り敢へず指先。これを使ってどういふゴーストが考へられるか? ⇒会場で出た案は，ジャンケン，ツッコミ，リアル髭男爵，猫じゃらし，魚つり・卓球・もぐら叩き，ディスプレイの前にケーキを置いて誕生日祝ひ，指をしゃぶらせる，等。皆の発想の涌き方が凄い。後になるほどネタ(紳士?)っぽいのはなんでだらう。

[15:23] 休憩

[15:34] zick: 「里々とLispとリーダマクロ」

里々の辞書ファイルをリードマクロ(リーダマクロ)でLISPのS式に変換し，会話を作る作業をLISPクライアント上でやらせてみた(このリードマクロを作るのが大変!)。ベースウェアに生成した会話をそのまま渡せるECLは日本語が上手く通らないので，ベースウェアとLISP処理系の間にはCで記述したパイプDLLを使用。

里々だけで処理するのと速度を比較すると，単純な数値演算は速かったが，括弧の中に括弧が含まれるやうな場合は，リードマクロが展開してから式全体を評価し直さないといけないので遅い。

里々は遅い。∵ぽなさんによると，3つ(単語・トーク・函数?)の名前空間を実行毎に全部走査する必要があり，しかも毎回全角半角変換が入るので。会話が簡単に書けることに特化して作った結果，速度が犠牲になった。

里々のif文は引数が全部評価される! ⇒ぽなさん解説: 里々は仮令ifでも，外部に処理を投げてゐるので，引数を全部評価してから渡す必要があるため。

オーバーヘッドを除き，純粋に計算時間だけ比較するには，例へば200回計算した時と400回した時の時間差を見ればよい。⇒当たり前の手法だけど，私の周りにあまりかういふ方法で検証をしてゐる人が居ないので新鮮に映った。

今回作った里々を読めるLISPプログラムは，正に作ってみただけで，全く役に立たない。⇒さうでもないとの意見が。私にはよく解らなかった。

LISPに興味を持ち，LISPの処理系を7つ作った。⇒zickさんは私と違って根柢にある技術力が凄い。今日リアルで見たzickさんは，正に自分の分野である技術的な話ができてとても嬉しさうに私の眼には映った。

[16:04] 休憩

[16:12] 畝傍: 告知: 伺か＠Lingrの宣伝

[16:17] ディスカッション (司会進行: ぽな@ばぐとら+さとー) お蔵入りネタのサルベージ

里々の文法を書ける華和梨を作る案。基本は里々で，複雑なスクリプトを書きたい時のみ華和梨の文法を使へるやうにする。⇒LilyPondのLISP構文呼び出し #(…LISP文法…) に似てゐると感じた。

SF作家について語るゴースト…十分な量の会話を作れずお蔵入り。

ゴーストセンター/マネージャが激重なので，代りのものをなでしこで作ってみると，やっぱり重くなってしまった。

過去の版まで含めたあらゆるゴーストを一元管理するサーバを立てようとしたが，規模が大きすぎてお蔵入り。特に再配布可能(=サーバに収録可能)かを訊くのに一番時間と手間が掛った。Creative Commons等のライセンスが滲透していれば…。過去にはまゆらが「商用だから」と断られたことも。

Macintoshでまともに動くベースウェアを作りたい。(禁じ手: Wine: WineでEmilyを使ふとアニメーション毎にずり落ちてゆくバグがあるらしい。)

没(になりさうな)ゴースト案が二，三。自分が決めた最低会話数に達しないと公開できない。60は多い? ⇒40といふ方も。自分はゴーストを作ったことがないので数値に対して実感が涌かない。

多人数でゴーストを作るのは成功し難い。牽引役が必要。(稀有な例外: Emily，虹のうらがわ)⇒虹のうらがわは今回初めて知り，帰宅して早速入れてみたが，結構好きになれさう。ふたば文化を少し知ってゐたからニヤニヤし易いのかも。

RPGっぽい登場人物多数なゴースト。膨大・激重で挫折しさう。

共有変数(異なるゴースト間で共有可能な変数)プラグインの実装まだー? 変数をどこまで隠すか。スクリプトログを見れば内部状態が丸見え。

[16:49] 閉会

⇒御疲れ様でした。大半の方は後の懇親会(飲み会)に流れて行った模様。

総論

理系の端くれである私が昂奮するような技術的内容が連続し，大変気持ち良い時間を過ごせました。時時飛び出たネタでも笑ひ和めましたし。本当に有難うございました。

かういふ場に出席すると，自分も何か技術的に頑張ってみようといふ刺戟を受けます。実際に何か世に送り出せるモノが出て来るかどうかは別ですがorz。