うかべん大阪#4
本日、大阪・なんばにて伺的ソフトウェア勉強会（うかべん）大阪 #4 が開かれています。
幸い、現地入りすることができましたので、今日のエントリで内容を速報中継することにしてみました。
【この記事の内容について】
この記事は、私がSpeakerの皆さんの発表を聞き、自分なりに理解し、かみ砕いて書き下し、感想を付け加えたものです。
（各発表の末尾にある項目「感想」は、私自身の意見・感想です。）
とくに私の理解力不足により、Speakerの皆さんが発表された内容と相違している可能性があります。
誤りや問題点がありましたら、コメント・拍手等でご指摘ください。
- （11/4 9:20）一部追記および修正しました。
- （11/4 10:07）【この記事の内容について】を追記しました。
- （11/4 11:47）感想等を追記しました。
- （11/5 19:20）講演者ご本人の補足により、記事を修正しました。
- （11/5 20:05）講演者ご本人の日記の内容に基づいて、記事を修正しました。
- （11/11 13:00）恥ずかしいスペルミスを修正しました。
重くなってきたので折りたたみます。本文はこちらから。
『伺かをフロントエンドに使ってみたら』／早坂千尋様
- 「伺か」をコマンドラインアプリケーションの情報入出力インタフェース（フロントエンド）に使うことについて
- 伺かプラットフォームは「入力」「出力」が揃っているため、コマンドラインソフトウェアのフロントエンド（入出力インタフェース）に使うことができるのではないか。
- デモンストレーション。SETI@home（地球外生命体探索プロジェクト）の計算進行状況を取得し、表示するゴーストを起動（黒姉シェル）。
- 仕組みの解説。setimon.dllというSAORI（伺かゴースト用外部ライブラリ）を使用。setimon.dllはSETI@Homeクライアントが吐き出すステータスファイルを解析し、SHIORI（nasino.dll）に投げ渡す役割をする。
- SETI@Homeクライアントの吐くステータスファイルを勝手に読むので、実装としてはあまり綺麗ではないとのこと。
- このシステムの欠点は、SETI@HomeはCPUパワーを食えるだけ食うので、進行具合をモニタするためだけに伺かを起動するのは割に合わなかった。（2000年代当初の話）
- 解決のために：SSTPでネットワーク越しにモニタればよい。SETI計算用のマシンでは、SSTPを投げる小さなプログラムを動かすだけでよい。また、複数台で計算をおこなう際は、情報を一箇所にまとめることができ、さらに便利。
- なぜこのようなことを考えたのか：理想のコンピュータは、ユーザが寝ている間に勝手に仕事をしてくれるのが理想。さまざまなアプリケーションがバックグラウンドでタスクを実施し、伺かプラットフォームに報告し、「ゴーストが」ユーザに結果や経過をまとめて報告してくれる、ということをしたかった。
- 昔はSSTPで情報を投げるプログラムが流行っていたんだけど、今はどうよ・・・？
『やめといた方が良い栞の作り方』／駅長様
- 【テーマ】 SHIORIを作ろうと思ったときにぶちあたる壁のあれこれ、について。
- どこいつ文章を作るAIを実現するための一手法、「ルールエンジン」
- 「SHIORIとは、辞書管理である」＝辞書をいかに管理しやすく記述効率のよいものにするかがカギ
- 世の中の複雑な事象を管理する手法として、「ルール」を考える。ルールは、「フラグ」と、フラグが立つことで起こる「イベント」から成る。
- LHS（Left Hand Side）＝条件、フラグ。「Handに触られた」
- RHS（Right Hand Side）＝行動、イベント。「叫ぶ」
- LHSとRHSの組み合わせ＝ルール。
- すべてのルールの集合を「ナレッジベース」（知識の集合）と呼ぶ。ルールによって記述される世界の全て。
- 発火＝ルールのフラグが成立しイベントが発動すること。
- 連鎖＝ルールの発火により新たなフラグが立ち、別のルールが発火すること。
-
- ルールエンジンの例：フラグ「投手がすっぽぬけ球を投げる」＋フラグ「ランナーが一塁にいる」＋フラグ「ライトの守備はイチロー」→最終イベント「レーザービームで人類滅亡」
- 最初に単発的なフラグがいくつか成立することで、いくつかの連鎖を経て、最終的なイベント（結果）が生じる。（ナレッジベースにランダム要素が含まれていない場合、「世界」の全てを決定的に記述しているルールに従って状態が推移していくため、同じ初期条件からは同じ結果が決定的に生じることになる。）
- このような思考を通常のプログラム言語で表現することは困難。（条件文の嵐になるうえ、フラグ数の累乗で組み合わせが増えるため）
- それを簡単に実現できる「推論エンジン」（ルールエンジン）というものがある。
- ルールエンジンの例：フラグ「投手がすっぽぬけ球を投げる」＋フラグ「ランナーが一塁にいる」＋フラグ「ライトの守備はイチロー」→最終イベント「レーザービームで人類滅亡」
- ルールエンジン CLIPS（C Language Integrated Production System）の紹介
-
- コマンドプロンプトによるデモ。
-
- ゴーストによるデモ。
- まとめ
- 前向き連鎖（事実駆動）は、フラグ→イベントという流れを一本追っていけば結論にたどりつくため、動作が速い。ゲームやゴースト向け。
- 後向き連鎖（仮設駆動）というものもある。結果から、それの成り立つ条件を探す。計算量は莫大。結論（ゲームでいえば、勝利条件）から現状までの流れを求めるような用途に向く。詰め将棋や、オチを最初に考えてネタを作る芸人のようなもの。
- 前向き連鎖のナレッジベースはゴースト向けである。CLIPSは比較的カベが低いので、興味のある人は試してみてほしい。.netならWF付属のエンジンが使えそう。
- 質疑応答
- SAORI向きではない。SAORIは一時的に呼ばれるもので、イベント連鎖を延々と続けていくゴーストの動作そのものに適用するにはSHIORIにするしかなさそう。
- 動的にルールを追加することも可能。（runコマンドを実行した段階の「世界」の中でイベントが連鎖していくため、runコマンドを打ち直せばOK）
- ルールエンジンには、「ステップ実行（どのようにイベントが連鎖するかを参照する）」「トレース（なぜこのフラグが立ったかを参照する）」機能がついており、デバッグが可能。
- CLIPSにおいては厳密にいえばイベントは同時に発生しないが、実装によっては同時（並列）にイベントが発生・進行していると「見なす」ことができるので、ニューロコンピューティング的な思考も可能になるかもしれない。
- 感想
- ルールエンジンの動作原理は単純なので、既存のSHIORI（文など）でエミュレートすることもできそうな感触。（動作速度を考えなければですが。文の関数として実装するのも面白そう・・・）
- ナレッジベースを作る作業は非常に網羅的であることを要求されるため、かなり大変ではないかと感じます。将棋ゲームの話が出てきましたが、現在進行形で対局中のある局面に関しては最善手を指すことができても、「すべての局面における最善手を網羅する」となるととんでもないことになってしまいます。現実的にそれは無理なので、プログラマには「すべての局面」を「いくつかの特徴的な局面」に抽象化する作業が要求されるでしょう。
- とはいえ、「ルール」という断片だけを用意してやって、いざイベントが発火し連鎖が起こり（予想もしなかった素晴らしい）結果が生まれたら、それは至福の時だと思います。私、そういうのが大好きなんです。
ライトニングトーク『ゴーストなんとか機的何か』／ケノ様
- キャラクターなんとか機をゴースト上で実現する試み。
-
- ゴーストなんとか機のデモンストレーション
- 実際に、Emily/Phase4のデフォルトシェルとそっくりなちびシェルを作成。
- 製作時間3分。（アセンブルにかかった時間。Emily/Phase4のシェル風パーツは事前に製作してあった）
- ゴーストなんとか機のデモンストレーション
- 感想
- 髪、目からはじまり、各所のパーツの色まで細かく指定できるツワモノ仕様でした。（カラーピッカーまで出る！）ライトニングトークの短い枠での発表でしたが、もっと長い枠でじっくり見てみたかったです。ぜひ触ってみたいと思います。
ライトニングトーク『なでしこ勉強会』／しらたま様
- 来週11月9日（日）13:30〜、大阪・千里公民館にてなでしこ勉強会をおこないます。
- なでしこ作者の「なでしこの将来」展望の発表
- なでしことデータベースとの連携について
- しらたまさん「なでしこで配列変数」
- あと10名ほど参加募集中。よろしく！
- 感想
- こぢんまりとした会場での勉強会ということのようです。言語作者さんと触れ合えるチャンスですね。
『シェル@SVGのはなし』／しお様
- 【テーマ】 ベクタ形式の画像（SVG画像）をゴーストのシェルに使ってみませんか？
- SVG（Scalable Vector Graphics）＝拡大縮小が自由なベクタ形式。（ベジェ画像、ベクタ画像）
- SVGを編集できるソフトウェア：Illustrator、Inkscapeなど。（PhotoshopやGIMPでも読めるが問題が多い）
- ベジェ画像の得意なこと・苦手なこと
- 曲線の形を計算式で生成するため、拡大縮小が自由。さまざまな大きさのデスクトップに登場する必要があるゴーストにとって絶大なアドバンテージになりうる。
- 単純な形状の変更も簡単。
- アンカーポイントで、線の位置や曲がり具合を指定するので、作成に手間がかかる。
- 色塗りの自由度が低い。（複雑なグラデーションなどが不得手）
- SVGファイルにラスタ画像（通常の画像）を埋め込むこともできるが、拡大縮小が自由である利点が消えるうえに、ファイルサイズが巨大になるために勧めない。
-
- ベクタデータの編集デモンストレーション
『梨の季節』／さとー様
- 【テーマ】 伺か用SHIORI「華和梨」を使う上での、様々なノウハウについて。
- エディタを選ぼう！
- ゴーストのデータは基本的にテキストファイルである。
- Notepadで編集せず、キーワード色分け機能などのある高機能エディタを使うとよい。編集効率が段違いに良くなる。
- エディタのカッコ対応チェック機能は必須。華和梨向けにカスタマイズするなら、Sakura Editor＋おば9氏の華和梨キーワード色分け設定の組み合わせが便利*1。
- 華和梨の書き出したログを読もう！
- ツールログファイルを楽に見よう！
- 「tail」というツールを使うと、専用ログツールのようにリアルタイムでログ表示を参照できる。
- Tail for Windows（軽量）
- Tail for Win32（高機能、英語版のみ）
- tailツールの画面表示例
- 「tail」というツールを使うと、専用ログツールのようにリアルタイムでログ表示を参照できる。
- 情報をログファイルに積極的に書き出そう！
『Webカメラでゴーストとお話』／酔狂様
- 【テーマ】 ディスプレイ上のゴーストに、ユーザが直接触ったり叩いたりできるインタフェースを作れないか？（前回のうかべん横浜#2の話題の続編となります）
- AR（Augumented Reality）＝カメラで三次元空間を撮影し、ディスプレイ上に表示し、バーチャルなデータ（ゴーストや3Dキャラクターなど）と合成する。
- でも人間が直接に触ることはできない
- 前回の提案＝ウェブカメラをディスプレイ周辺に向け、「ユーザの動きを撮影」
- ユーザが直接、ゴーストの支配空間に対してアクセスすることができる（ユーザがディスプレイに手を近づけるとゴーストが逃げる、など）
- 今回、実際にユーザの手をウェブカメラで検出してみた。
- 前回（うかべん横浜#2）から進んだこと
- カメラの姿勢推定が正確になった
- 背景からオブジェクトを切り出す精度が上がった
- 名前が決まった「Ruchia」（語源：アイマス）
- Ruchiaの基本アルゴリズム
- ウェブカメラで撮影したディスプレイ周辺の映像から、まさに今ゴーストに触ろうとしているユーザの手を切り出す方法は？
- 偏光シートを使い、ノートPCの液晶モニタを（画面に何が写っているかにかかわらず）真っ黒にすることができるので、手のリージョン（＝領域）を切り出すのが容易になる。
- Ruchiaを使うと何ができる？
- モノや指がディスプレイの近くにいることがわかる、そのだいたいの場所がわかる
- モノや指がディスプレイに触った、そのだいたいの場所がわかる
- ゴーストと乾杯、ゴーストとジャンケン、ゴーストに指をしゃぶらせる、等
- 次のステップ：物理エンジン
- 物理エンジンとは物理的な動き（固体、液体などの物質の動きを）エミュレートする
- 画像をメッシュ化し、格子点に質点を配置し、それぞれの間の拘束条件を設定して物理的な動きをエミュレートする。例：PCを傾けるとうにゅうが坂を転がっていく
- 質疑応答
- 必要なカメラの解像度は？
- 今は30万画素くらいのカメラでもOK。将来は、撮影した画像をシェルに取り込むなどのアクションを想定しているので、その瞬間は高い解像度が必要。
- 必要なカメラの解像度は？
- 感想
- 前回のセッションの続き。実際に手の切り出しのデモンストレーションをされていました。照明条件さえ整えば十分「手」のリージョンを切り出すことができそうな感じです。今後は、いかにカメラの前に差し出される「物体」（ここからは、手だけでなく、ワイングラス、カッターナイフなどさまざまなもの）に特化した検出パラメータを作りあげるか、という、ある意味一番キツいカットアンドトライの領域に入っていかれることと思います。いや、楽しみ。
『里々とLispとリーダマクロ』／zick様
- 【テーマ】里々の辞書をLispのプログラムに変換して実行できないか？
- そもそも、里々とLispは似ているのか？
- Lisp（Common Lisp）は汎用のプログラミング言語、里々は単一目的のスクリプト言語
- 共通点はカッコが沢山出てくること
- 里々では、（（季節）の食べ物）→（秋の食べ物）→サンマ のように、カッコは内側から順に解釈される
- Lispでも、(defun 食べ物of (季節) if... ) のようにカッコの内側から解釈されていくが、食べ物of (季節) のように「関数」「引数」に分離される。
- Common Lispではマクロ機能を搭載しているので、里々と全く同じ記法をすることも可能（Lisp最強説）
- まとめ
- 里々とLispは構文は似ているが、評価規則は全く異なる
- Common Lispで読めるように里々のプログラムを書き換えて実行した
- Lisp化できればマルチプラットフォーム環境化の夢が！（Macでも動く）
CMタイム
- 畝傍氏による伺か@Lingrの宣伝。新しい方に来ていただき、話題に新風を吹かせたいとのこと。デバッグをして欲しいときに役にも立つよ！ http://www.towano.net/room/ukgk/
『お蔵入り伺かネタを今すぐにサルベージするシンポジウム（OUISS!2008）』／ディスカッション
※以下敬称略
-
- （さとー）さて、これまでいろいろな都合によってお蔵入りになったネタを順次挙げていただきます。
- （さとー）華和梨と里々の融合。トークを里々で書き、やりにくいことを華和梨で書ける環境。
- （Ponapalt）文にもそういうアイデアはあった。
- （さとー）ひたすらSF作家の話ばかりをするゴーストがお蔵入りになってる。2001年ごろ、華和梨チームによるサンプルゴーストとして企画された？
- （畝傍）SFファンを集めてプロジェクトを作ったら？
- （さとー）SFファンを集めた段階で空中分解のフラグが立ってしまうのでは。
- （しらたま）ゴーストセンターの登録をする「ゴーストマネージャ（NGM）」の軽量版を作ろうと思いなでしこで作り始めたが、ListViewで作ったら重くなってしまった。また、ゴーストセンターに外部アプリが勝手にアップロードしていいのか？という問題があったので中断。
- （Ponapalt）管理者さんに連絡取りましょうか？
- （畝傍）私の環境ではNGMでアップロードできない。
- （カトマンズ）かつて自営サーバでゴーストの古いアーカイブを保管する企画をしたことがあるが、結局途中で倒れてしまった。一番面倒なのが二次配布の可否を調べること。
- （Ponapalt）人の資源が足りない。
- （カトマンズ）CCなどの使用許可の話になると大変。ほかに、伺かForgeのような、伺かのコードを保管するサーバを作りたかったが、実現していない。あとMacOS Xで安定して動くベースウェア？
- （Ponapalt）（困笑）
- （カトマンズ）Mac環境は無い物づくし。みんなマック買って下さい。芝やん氏によるiTunes4uもいつか掘り返したい。
- （畝傍）地球上が森林に占拠されている世界で、一人で住む女の子との対話ゴースト。好感度等のフェイズ進行が多く、シェルのパターンも膨大になるうえ、トークが40くらいしか作れなかったのでお蔵入り。
- （畝傍）トークの自分的最低ライン（60）を越えないネタがたくさんある。
- （Ponapalt）60でも多いと思う人！（挙手多数）
- （畝傍）多人数で合作という手もある。私よりもトークを書ける人、がんばって下さい。
- （一同ツッコミ）
- （おぞん）伺か界隈入ってから2年。まだ手をつけていないネタが多い。
- （畝備）実現可能性が低いものは？技術的にとか
- （おぞん）次の次に公開する予定の制作中ゴーストがコケかけている。
- （Ponapalt）具体的にどこが問題？
- （おぞん）データ量が多すぎて扱いきれないこと。具体的には×××なんですけど。
- （一同）（驚き）
- （畝傍）そういうのが得意な作者さんに聞いてみるとか？
- （おぞん）そもそもデータ読み出しの段階で重すぎる。
- （質問）フェーズが替わるごとにネットワーク更新で別のゴーストにするとか・・・
- （さとー）専用プラグインを作るとかは？
- （おぞん）それはやる気です。
- （さとー）また一つ忘れていたの思い出した。共有変数プラグイン・・・
- （Ponapalt）キャラクタ間でデータをやり取りしたり保存したりするモノですね。
- （Ponapalt）駅の黒板形式（誰でもデータを入れられるし、データは古い順に削除される）という形の共有変数を考えたことがある。
- （航）伺かを始めて間もない。なかなか時間がないが、現在開発中のゴーストで、【これからやりたいことにつき検閲削除】を考えている。
- （Ponapalt）私はお蔵入りのカタマリだから言わなくていいですね。
- （一同）（総ツッコミ）
- （さとー）本体更新！
- （Ponapalt）（絶句）
- ここで時間切れにつき終了。
- 感想
