RE;COIL (リコイル)メンバーのarc@dmzによる日記
「mixi日記で去年6月頃触れた、」…というふうに前の記事で書いたけど、mixi嫌いの人には不親切だったかも。というわけで、ここに再掲。当時からまた色々事情が動いているので、あくまでこれらが去年の時点での調べ・感想という点に注意されたい。
Microsoft Silverlight、Adobe AIR、Google Gears
- http://www.microsoft.com/silverlight/
- http://labs.adobe.com/technologies/air/
- http://gears.google.com/
デスクトップをWindowsで支配するMicrosoftが「Silverlight」でWebに進出したかと思えば、 元来Web向けの技術Flashを擁するAdobeは発展形のApollo改め「Adobe Integrated Runtime」でデスクトップに逆進出。 そして、検索エンジンやAjaxをフル活用したサーバありきのWebアプリ開発で一気に巨大企業へ成長したGoogleは、「Google Desktop」に続きサーバがなくてもアプリを使える技術「Google Gears」を一般公開。
デスクトップとWeb、インターネットとローカル環境の垣根を越える様々な技術が一斉に出揃ってきた今は、とても面白い時代だと思います。
細かいところに目を向ければ、DBMS(データベース管理システム)の一種でありながら、サーバがクライアントソフトウェアに組み込まれたかたち を取る(狭義のサーバを必要としない)「sqlite」がSafari 3などによってローカル環境でフル活用されるようになってきたこともその支流の一つとして捉えられそうです。
PlaceEngine
Webがらみの技術といえば、無線電波の状況から自分がどこにいるか判断できる「PlaceEngine」が公開されています。
GPSが衛星、はるかかなた上空から位置をトップダウンに測定する技術なのに比して、PlaceEngineは近くの電波状況を積み上げて現状を把握するボトムアップの測定法です。 現在地を把握する情報源となりうるほど、どこでも電波が飛び交う時代になりました。
Apple iPhone、Microsoft Surface、TED2006
- http://www.apple.com/iphone/
- http://www.microsoft.com/surface/
- http://jp.youtube.com/watch?v=UcKqyn-gUbY
そもそもマウスとキーボードなんて細いチャネルでコンピュータを操ろうとしている点に、今のユーザインターフェースの無理があると思うわけです。 とくにマウスは一つの場所しかポイントできないけれど、人間の手は普通二本なんだから、ポイントできる場所が複数あれば(Multi-touchと言います)、もっと優れたユーザインターフェースが実現できるのは自明でありましょう。
そこで、Mac OS Xを積んだiPhoneは指2本で直感的な操作ができるようになってるし、(今秋発売) Microsoftが開発しているSurfaceは机表面が自由に触って操作できるディスプレイになってるし、(今夏お披露目) 去年2月のTED(Technology, Entertainment, Design)2006の時点ですでにそういうプレゼンが行われていたりするのです。
ユーザインターフェースは一番気になる分野なんだけど、そういう研究が「研究」としてまだまだ成立していない感じがちょっと残念ではあります。
知能ロボット学研究室、robocasa.com、miuro.com
日本のロボット産業が、産業面でも文化面でも世界のトップを行っていることは疑いようがないわけですが、そろそろロボットが傍に「いる」(≠ある)生活が当たり前に近づいてくる頃なのかもしれません。
阪大の変態教授(褒め言葉)は娘に似せたロボットを作るし、ロボットと暮らす生活をテーマにしたWebサイトや製品が出てきたし、鉄腕アトムは(まだ)いませんが、昔なら夢だった生活が今や現実となりつつあるのは確かでしょう。
複合現実と強化/拡張現実、拡張現実感プログラミング
- http://bp.cocolog-nifty.com/bp/2007/05/mixed_reality_l.html
- http://www1.bbiq.jp/kougaku/ARToolKit.html
VR(Virtual Reality/仮想現実)は、まったく別の現実が目の前に広がる技術を指しますが、本当に面白いのは、今ここにある現実が、別のリアリティと組み合わ さったり拡張されて現出する技術、MR(Mixed Reality)やAR(Augumented Reality)ではないでしょうか。
例えば、防犯カメラをハッキングして顔にアイコンを被せて匿名化したり、信号機の映像をハッキングして青信号を赤に変えたり、「現実」と「計算された現実」が混じる世界では様々な事件が起きそうです。(元ネタが分かる人は…ご愁傷様)
SF的に詳しい話は一つ目のURLに譲ります。
二つ目のURLでは、そんなARを現在の技術水準、それも家庭用PCの環境でけっこう簡単に実現できてしまうことが分かります。
Webカメラを使ってビデオチャットする人がどれくらいいるのか知りませんが、Skypeなどを使えばタダでずーっと話し続けられるビデオチャットのサービスは、確実に利用者が増えてきていることと思います。 そこで使われるWebカメラは、ある意味コンピュータの目です。 Webカメラ→コンピュータ(全画面表示)→ヘッドマウントディスプレイ、という接続を作れば、Webカメラで見ている範囲がヘッドマウントディスプレイに表示され、「視野」がWebカメラの撮影範囲と同じ意味を持つようになるのです。
この状態を作り出した上で、Webカメラの撮影した画をリアルタイムでハッキングすれば、その人が見て現実だと思っている視野をいじることができます。 URLでは、3Dでモデリングされた、あるはずがないものを映してしまう例が書いてあります。視野が傾けばそれに応じてモデリングデータも角度と位置を変えてレンダリングされるため、比較的自然に視野がハッキングされる感じを味わえるはずです。
時間軸に沿ったオブジェクトの移動・変形に関するプログラミングを可能にするインタプリタ型言語「Streaming Text なんとか」と、その通信用プロトコル「Streaming Text Transfer Protocol」に関するまとめ。
ゲームのプログラムでキャラクタの画像をアニメーションさせながらテキストを表示するに当たり、画像を表示する順番やテキストを表示する時間間隔を指定できる汎用的なインタプリタ型言語があれば便利なので、既存の言語を参考にしながら新しく設計することにした。
その言語で書かれたソースコードは、ストリーミング配信し、クライアント側では受信したぶんから順次実行できるようにする(演出上の)目的があるため、 Streaming Text なんとかという言語名にするつもりだ。XML/HTML、Sakura Scriptで使われる概念をいくつか参考にしている。
ストリーミング配信に使うプロトコルは HTTP と同じレイヤーで極めてシンプルな STTP（Streaming Text Transfer Protocol）というものを想定している。
これらの言語仕様とプロトコルは、今後インターネットで動画をはじめとするマルチメディアがますます積極的に配信されるようになったとき実用的な内容・思想を含んでいると考えられるため、なるべく拡張が容易な設計にしたい。
以下いいところ、悪いところ、と書いているのは「STなんとかの目的のために」いいところと悪いところであって、一般に言語仕様としていい・悪いと言える点を指摘しているわけではない点に注意されたい。
XML/HTMLが今ほど(誤った言語仕様の解釈に基づいた解説がWeb上に散見されるほど)知られるようになったのは、言語記述とデバッグがしやすかったからではないだろうか。メモ帳でタグを書き、ブラウザでファイルを読み込めばすぐさま内容が確認できる手軽さがキモだったように思う。
STなんとかはそのような手軽さを保証するため、人間が読めるテキスト形式で全てを記述できる言語とする。（バイナリによる拡張はありうる。）
また、XMLには名前空間を追加して機能を拡張できる、メタ言語仕様的な仕組みがある。これもXMLファミリーの普及に一役買ったのだろう。
STなんとかは、必要に応じて読めるデータフォーマットを追加できるような言語にする。
ただ、STなんとかは次の一点においてXML/HTMLと根本的に異なる。「文書をむやみに構造化しない」のだ。
現在の主なプログラミング言語は手続き型と関数型に大別される。
XMLは主にインタプリタによって即時実行される高級言語であり、作成できるプログラムに制約が多いためあまりその分類が意識されることもないが、仕様としては手続き型と関数型の境界に位置しているように見える。
つまり、パースされる順番によって基本的には兄弟関係が時系列の意味を持ち、手続き型のようでありながら、プログラム全体が階層構造によって特徴づけされる点で関数型に近い構成を成している。
後者の、文書を構造化(structurize)によって意味づけ(mark up)する特徴は今ではXML/HTMLの根幹をなす思想だが、HTMLのインタプリタ(レンダリングエンジン)にとっては意外に厄介な性質だ。
文書全体が一つの根を持つ木構造をなしているため、文書の正当性は木を全部読み込んでからでないと判断できず、厳密なパースとレンダリングを目指すならいったん文書全体を読み込み終える必要がある。ブラウザがWebサイトを表示するとき、読み込みが終わるのを適当な時間待つ仕様になっているのもこのためだ。
ただし、HTML文書は多くの場合、原則画面上に表示される内容から順に記述される。人間の頭の中が時系列で物事を語るようにできているのだから当たり前といえば当たり前だろう。
その特徴をとらえれば、インタプリタが読み込みとレンダリングを同時並行で行えるような言語仕様を組み直せるはずだ。
そもそもすべてのタグは(構造を正しく保つために)閉じなければならない、というのはHTMLがXMLのサブセットとして定義され直した時期にスポットが当てられた原則であり、かねてより、閉じなくてもよいタグ、つまり(改行や水平線などのように)単体で何らかの機能を果たすタグは当然のように存在した。
タグという呼称は「くくりつけるもの」という意味を持っているが、何重にもテキストをくくりつける「構造化」思想は、行き過ぎると非人間的な(人間向きでない)言語仕様を生んでしまう。
Sakura Script は言語仕様がインタプリタのプログラム内で静的に定められており、基本的には拡張性に乏しい。しかし、その点を除けばストリーミング配信に向いており、実際SSTPというプロトコルで配信されている優秀な言語仕様であると言える。
STなんとかはソースコード全体がひとつの根を持つ木構造にまとまるわけではない。あくまでストリーミング配信を念頭に置いて文書の先頭からパースしていけるようにし、Sakura Script のように文書の途中に制御コード(簡単なタグ)を挿入することで機能を持たせる。制御コードという概念は Sakura Script を参考にしている。Sakura Script では で始まる文字列が制御コードだったが、STなんとかはHTMLライクに < で始まる制御コードを用意する。
Sakura Script とは異なり、閉じタグに相当するものも用意し、対応する既出のタグで適用された設定を取り消して元に戻す意味を持たせるが、閉じタグはなくても問題なくスクリプトが実行されるようにする。
ほとんど一緒の予定。(Keep-Aliveを基本にする？詳しくは未定。)
現在、一般に広く普及している主要OSのデスクトップが続々3D化されて(3Dの描画エンジンによって管理されるようになってきて)おり、近い将来、3Dのデスクトップマスコットをはじめ、多くの3DCGを普通のコンピュータのディスプレイ上でリアルタイムにアニメーションさせられる環境が整う。
また、人工知能研究のスピンオフで、人間工学的に使いやすいインターフェースとして、人間的な振る舞いをするエージェントが多くなってくることが予想される。
「構造化」思想を基本としたユーザインターフェース、例えばツリー構造で目的の文書にたどり着くまでに何階層も深く潜らなければならないヘルプファイルなどは、ときに情報量が多すぎるため、人間に扱いづらいものとして、一部でのみ使われるようになるのではないか。
そうしたとき求められるもののひとつが、時間軸上に生きている人間と同じように、時系列に沿う振る舞いをプログラムされたエージェントだろう。
すでにWeb上では、Ajax、Flash、あるいはそれらを使ったニコニコ動画のように、時間依存で動的に変化するコンテンツが人気である。
コンピュータ言語は、これまでに十分抽象化されてきた。その知見を踏まえ、活かしながら、人間にとって(組む側にも、組まれたプログラムを享受する側にも)自然な言語を考えられる時期がきたように思う。STなんとかは、前述の目的で設計された人間的な言語にしたい。
具体的な応用としては、静的なSTなんとかのスクリプトによってデスクトップマスコット(エージェント)の振る舞いを制御したり、サーバからストリーミング配信されてくるSTなんとかスクリプトによってクライアントのデスクトップ上でデジタルアイドルのライブを開いたり、といったことが考えられる。
初期の目的が2Dのデスクトップマスコットの制御のため、まずは2D向けのSTなんとかサブセットを作成するが、近いうち、3Dのモデリングデータを、関節定義や物理演算などで制御できる3D向けのSTなんとかサブセットも作成したい。
どれも一長一短。とくに伺か以外全部XMLベースというのは如何なものか。
タグ「ネット」を含む記事を全5件中1件目から計2件表示
© arc@dmz 2007