ちょっと硬派なコンピュータフリークのBlogです。

カスタム検索

2009-07-29

GUI開発におけるコロンブスの卵 - KSCS

先日、とあるUI技術がひっそりとデビューした。このUI技術 - KSCS - を手がけたコンサルタントは友人なので、以前彼の取り計らいでKSCSについて話を聞く機会があった。KSCSは「なるほど!」と唸らされるアイデアを用いていながら、デビューしたにも関わらず巷であまり話題になっていないようなので、このブログで皆さんに紹介しようと思う。

KSCSの凄いところは、ズバリその言語構造そのものである。プログラム言語の紹介と言えばやはりまずはHello Worldからだろう。というわけで以下のソースコードを見て欲しい。


K(_hello){
U{
R(#m,"???")
Rb("Push"){
Bs{
#m?="Hello, world!";
}
}
}
}


恐らくこのソースコードを見て、プログラマ諸氏は「ナンジャコリャァァァーーーッ?!」と思うのが素直な感想ではないだろうか。私も初めて見た時はさっぱりワケが分からなかった。KSCSがGUI開発のためのものであることを思い出して欲しい。このソースコードをKSCSで実行すると、次のような画面が表れる。


この画面を見ただけで、勘の良い方なら気づいただろう。そう、つまりさきほどのソースコードは画面のレイアウトそのものを示すものだったのである。Basicもアセンブリ言語もC言語もC++もJavaもPerlもRubyも様々なプログラミング言語は、そのプログラムの先頭から順番に逐次命令を実行するというのが原則である。PHPのようにページに埋め込むことを主眼に置いて設計された言語も存在するが、それでもページ内に埋め込まれた各命令文は、基本的にページの先頭から実行されるわけであり、そういった意味では他のプログラミング言語と変わりはない。

しかしKSCSは違う。ソースコードそのものが画面の要素に対応しているのであり、プログラムは完全にイベント駆動型で実行される。まさにUIのために設計された言語というわけである。ちなみに、上記のHello Worldでは、「Push」を押すと下記のように「Hello, World!」の文字が表れる。


KSCSは、各要素をごく単純な記号をツリー構造に並べるという文法を持っている。レイアウトの表現に用られる記号には、次のようなものがある。
  • K ... 全ての要素のroot要素。
  • U ... レイアウトが規定されていない要素。レイアウトのroot要素として利用される。
  • R ... 行を表現する要素。
  • Rb ... Rのボタンバージョン。
  • C ... 列を表現する要素。
  • Cb ... Cのボタンバージョン。
  • I ... 代入のための要素。(後述)
これらをツリー構造(入れ子)にすることにより、様々なレイアウトを表現する。例えば「U{C{RRRR}C{RR{CC}}}」という文字列の並びも、れっきとしたKSCSのソースコードである。この文字列は次のようなツリーを表現している。

このソースコードを実行しても何も表示はされないが、次のような枠を内部的に構築することになるのである。上のツリー構造と下のレイアウトを対比してみてもらいたい。


このようにレイアウトを表現しただけでは、プログラム言語であるとは言い難い。(むしろレイアウトを定義するための言語であると言えるだろう。)ではどうやってプログラミングを行うのかというと、各レイアウトの子要素の中にプログラムを記述するわけである。KSCSの各要素のひとつは、次のように表現することができる。

要素名(属性){子要素}

要素名は既に説明したK、R、Cといったもので、予め意味が定められている。

子要素にはレイアウト要素を入れることも出来るが、イベントを記述する要素を入れても良い。ボタン操作に対するイベントを記述するには、例えば次のような要素がある。
  • Bs ... ボタンが選択された。
  • Bp ... ボタンが押された。
  • Br ... ボタンが放された。
  • Bt ... マウスオーバー。
これらのイベント要素の子要素として、何を実行するかを記述するわけである。ボタンを押した時に他の要素に何らかの変化をもたらしたい(表示されているテキストを変更したい)なら、他の要素のラベルを用いてその要素の属性などを変更するわけである。例えば「#label?="this is a test!"」とすると、#labelというラベルのついた要素のテキスト属性(表示されている文字列)が変更されるといった具合である。ラベルは各要素の属性として記述する。

ここまで解説したところで、ようやく上記のHello Worldのソースコードを理解することが出来るだろう。既存のプログラム言語とあまりにも発想が違うので、頭の切り替えが必要かも知れない。しかしこの発想は凄いのではないだろうか。逐次実行する文法からレイアウト主導型の文法への切り替えというのは、言葉にしてみれば簡単であるが、それを実行に移すのは難しい。まさにコロンブスの卵である。レイアウト主導型のプログラム言語を用いることにより、GUI開発に劇的な変化がもたらされるのは容易に想像がつくだろう。まるでプレゼンでも作るような感じで、スイスイとGUIプログラムが開発出来てしまうのである。

上記の例はごく簡単なものなので、KSCSによる開発がどういったものかというイメージがあまり実感できないかも知れないので、もう少しだけ複雑な例を紹介する。(複雑なアプリケーションを開発したければ、それだけプログラムを大規模化すれば良い。)

以下がそのテストアプリケーションの初期画面である。


で、これがソースコード。


K(_test2){
U(#top,@s1){
C{
R
Rb("画像1"){
Bs{
#child?="_gazo"
}
}
Rb("文章1"){
Bs{
#child?="_bunsho"
}
}
Rb("入れ子"){
Bs{
#child?="_test2"
}
}
Rb("クリア"){
Bs{
#child?="";
}
}
R5
Rb("終了"){
Bs{
E(_quit);
}
}
}
C6{
R("タイトル")
R8{
I(#child)
}
}
}
}

K(_bunsho){
U("Hello, World!")
}

K(_gazo){
U{
C(img="Winter.jpg")
}
}


まず注目して頂きたいのが「C6」や「R8」という風に、要素名に対して数字がついている部分。これは現在の枠の分割比を設定するのである。これにより、縦横の分割であればかなり自由なレイアウト設計が可能になる。

このプログラムは、ボタンを押すと余白の部分にいろいろなオブジェクトが表示されるという、至極単純なものである。「文章1」を押すと、先ほどと同じように文章が表示される。



この例で先ほどと違うのは、I要素の子要素として他のツリーを代入していることである。KSCSのソースコードは生け垣構造になっていて、K要素をいくつも定義することが出来る。それをそのまま現在表示されているレイアウトの子要素として利用出来るのである。

次は画像の例。画像の表示も至って簡単だ。


これは自分自身を子要素にした例。


KSCSの最大の特徴として、解像度フリーな動的レイアウトというものがある。レイアウトの分割方法とか比率を前述の文法に従って決めておくと、文字のフォントやボタンのサイズなどを自動的に決めてくれるのである。従って、自分自身を子要素にしたときには、与えられた領域に対して自動的に大きさを調整して自分自身を再描画するわけである。無限ループか?!と思われるかも知れないが、描画が出来ないぐらい各要素が小さくなると、KSCSはループを停止するので心配は無用である。

一般的なGUI開発において、レイアウトの設計はかなり手間のかかる作業である。一カ所を変更すると、全体のバランスを取るためにあちこちを調整しなければならないという副作用が生じてしまったりして、変更要求があったときなどは涙目にならざるを得ない・・・。だが、KSCSは自動的にレイアウトを調整してくれるので、GUIアプリケーション開発の手間は格段に減ることになるのだ。

ちなみに、上記のように入れ子状になっている場合でも、ボタンはちゃんと動作する。以下は3階層目の「画像1」ボタンを押した時の様子。


このような開発環境がどんなものに応用できるの?というと、開発元の(株)カテナスは以下のようなものを想定しているらしい。
  • デジタルサイネージ
  • テーブルトップオーダーシステム
  • プレゼンテーションツール
KSCSはとにかくタッチパネルと相性が良いので、家電への組み込みなんかにも向いてるんじゃないだろうか。

KSCSは現在プライベートβの段階だそうで、開発&実行環境は一般には公開されていない。使って見たい人は以下の問い合わせフォームから連絡してほしいとのことである。
http://www.kathenas.com/contact.html

KSCSのデモ動画(YouTube)もおいてあるので、興味のある人は是非見てみるといいだろう。

なお、上記の説明では出来るだけKSCSの専門用語を省いて解説したので、(株)カテナスのホームページを見るときには専門用語に注意して欲しい。ちなみに、KSCS上で実行出来るプログラム言語はKI言語、インタープリタはSaLaという。個人的には、これらをまとめてもっと分かり易くて親しみ易い名前にするべきじゃないかと思う。Sun Microsystemsが「Java」を名付けたときのように。

2009-07-15

Chrome OSアーキテクチャ大予想!

Chrome OSが出るぞ!というニュースを聞いたとき、ある種の衝撃が走った。というよりとても腑に落ちたと言った方がより正確に俺の心情を表しているかも知れない。そう、まるで心の鍵穴にChrome OS発表のニュースが鍵となって、今まで開くことが出来なかった心の奥底にある謎の扉を開いたような感覚だった。世間的には「ChromeブラウザがのっかったLinuxの1ディストリビューション」だという見方が趨勢であるように思うが、俺はChrome OSが断じてそのような安易で在り来たりなものとして登場するのではないと予感している。そしてまだ見ぬChrome OSにワクワクしながら、そのアーキテクチャを想像してニヤニヤしたりしているのである。まだChrome OSのアーキテクチャについては詳細が公表されていないが、以下のようなものになるんじゃーないだろうか。

この図はあくまでも個人的な予想というか妄想によるものなのでその点は了承して欲しい。公式にGoogleからChrome OSの詳細が発表されたとき「全然違うじゃないか!」となったら、笑いぐさにでもして頂ければ幸いである。



さて、この図(俺の心の中で想像しているChrome OSのアーキテクチャ)を解説しよう。

1. UIはChromeのみ。


一つ確信していることがある。それは、Chrome OSにおいてユーザーが触れることができるUIはChromeブラウザだけになるだろうということだ。Linuxだからといって、UNIXユーザーが慣れ親しんだシェルが搭載されることはないだろう。ギークなユーザーにとっては「なにー?!そんなものはLinuxではない!言語道断!!」と激高してしまう仕様かも知れないが、そもそもChrome OSはそのようなギークをターゲットにしていないだろうと思われる。全ての操作はChromeを通じて行われることになるだろう。

2. Webサーバを搭載

上記の仮説が正しければ、Chrome OSにはWebサーバが搭載されるはずである。lighttpdやApacheのような。何故かって?それは、そのコンピュータ自身を操作するためである。おそらくはコンピュータの電源を切る操作すら、ブラウザを通じて行うことになるだろうが、その場合ブラウザでクリックした操作を誰が実際に実行するのかと言えば、HTTPリクエストを処理するWebサーバーでなければいけない。コンピュータの管理や設定は、そのWebサーバー上で動くアプリケーションとして実装されることになるだろう。

3. ユーザーアプリケーションはサーバープログラム

Chrome OSはGoogleのサービスやその他Web上にあるリソースを活用するOSであるのは言うまでもない。しかし本当に全ての処理(電卓アプリのようなネットを一切必要としない)アプリケーションまで、Googleのクラウド上で実行するとしたらそれは愚かなことであり、Googleのデータセンターは大量のリクエストによって飽和してしまうことになるだろう。従って、いくらブラウザだけで操作するChrome OSとて、ローカルにアプリケーションが一切必要ないというわけではないだろう。そうすると、アプリケーションはJavascriptによって実装されるか、ローカルのWebサーバー上でWebアプリとして実装されることになるのではないだろうか。今、巷にはWebアプリを得意とするプログラマが溢れているので、彼らはきっとChrome OS用アプリの開発も活発に行ってくれるに違いない。

4. ファイル管理からの解放

おそらくここがChrome OSの最も革新的な側面になると思われるが、Chromeブラウザから自身のコンピュータ上の「ファイル」へアクセスする手段はないだろう。WindowsのExplorerのようなファイルマネージャーっぽいアプリケーションは、おそらく存在しない。そもそもであるが、静止画像や動画、音声、プレゼンテーション、文書、テキストなどの各種データを「ファイル名」で識別して、それをツリー状のファイルシステムで管理するというやり方は如何にも古典的であり、本来の人間の要求であるはずの「データを整理し、確実に保存し、必要なときに素早く検索する」ということからはかけ離れた方法であると言えよう。その代わり、Chrome OSではデータは全てデータベースへ格納され、Webサーバー上で動くアプリケーションがデータベースからの検索や保存を肩代わりしてくれることだろう。その結果、人間は「ファイル名と中身を紐付けて覚える」という無駄な行為から解放されることになる。

ここで一つ疑問が生じる。Chromeがデータベースを搭載するとしたら、どのデータベースソフトウェアを搭載するのだろうか?ということだ。これまでにGoogleがsqliteを(AndroidやGoogle Gearsなどで)採用してきたことを考えると、sqliteのような気がしなくもない。しかし、もし上記のような使い方を本気で考えるのであれば、sqliteではスケーラビリティの問題に直面することが容易に予測できる。そうするとやはり、MySQLやPostgreSQLのように大規模なデータを扱えるRDBMSを搭載して欲しいところであり、MySQLerとしてはぜひMySQLを薦めたい。もし、MySQLのライセンスがGPLv2であることがFOSS Exceptionを適用するといいだろう。そうすれば、GPLv2であるMySQLを搭載しつつ、Chrome OS全体のライセンスを例えばApache 2.0ライセンスにすることができる。

5. 強固なセキュリティ

Chrome OSでは恐らくユーザーが直接コマンドを実行することはないし、システム的にそれは出来なくなっているだろう。実際、ユーザーが起動することができるプログラムは何もなくても良い。もちろんブラウザプロセスでさえ。じゃあ誰がブラウザを起動するんだ?!と思うかも知れないが、起動するプログラムがブラウザだけで良いならば、Chrome OS自身が事前にブラウザのプロセスを起動しておけば良い。そうすれば、Chromeブラウザの実行ファイルの所有者をrootにすることによってrootだけがコマンドを実行可能に出来るように出来るし、rootが起動したChromeブラウザのプロセスは、自身が起動後にsetuid()をして実効ユーザーを切り替えれば良い。このようにすれば、ユーザー自身の手によってブラウザを起動せずともブラウザを利用することが可能になるわけである。

極端に言えば一般ユーザーは通常ファイルへのアクセス権限が一切なくても良い。(ただしブラウザはバックグランドで動くプロセスにはアクセスするかも知れない。)この場合、ブラウザがバッファオーバーフローなどによっていくらクラッキングの被害にあったとしても、クラッカーが実行出来るコマンドは存在しないので被害は最小限にとどめることが出来るだろう。クラッカーが何か悪事を働くには、さらにそこからroot権限を奪取するか、Chromeを操ってローカルのWebサーバーで動くアプリケーションにアクセスするように仕向けるかである。だが、そのような場合もローカルのWebサーバーで不正なアクセスをブロックする仕組みを実装しておけば、いくらChromeブラウザを乗っ取ったところでクラッカーは何もすることが出来ないだろう。(せいぜい他の悪事を働くための踏み台=ボットとして利用する程度であろう。)

このように、実行可能なコマンドが存在しなければ「ウィルススキャン」という煩わしい行為から解放されることになる。なぜなら、スキャンする対象の「プログラムファイル」が一切存在しないから。

・・・


このような「Chrome OS」が本当に実装されれば、確かにGoogleが言うように「OSの再考」であると言えるだろう。こんな具合に俺の妄想は広がっているわけであるが、果たしてこの予想はどれほど当たっているのだろうか?一つだけ言える事は、もし俺の予想が当たっていたら、俺は確実にChrome OSのファンになるだろうということである。