ViscuitLand 構想 原田 康徳 ∗ 平成 16 年 1 月 19 日 で車が停止するルールを追加すると，図 2 のように 概要 なる． プログラミング楽しさをエンドユーザに伝える目 的で Viscuit (ビスケット) は開発された．本稿では， このシステムを多人数参加型のアプリケーションへ 拡張する (ViscuitLand) ための，デザインとその実 装法を考察する． 1 はじめに Viscuit [1] はエンドユーザが簡単にプラグラミン グの楽しさを体験できるビジュアルプログラミング 言語である．プログラムは図形の配置を書き換える 図 1: 車が動くルール というルールによって定義する．その実行は，対象 の図形の配置が近いものを，その近さに応じて (つ Viscuit の設計ポリシーは，プログラミングの最も まりルールのパターンに近ければ近いほど，書き換 基本的な部分は何か，という問いに答えている．例 え結果もルールの結果に近いものになる) 書き換え えば，Viscuit には変数はない．状態は絵の数や配置 て行く．この結果，プログラムをできるだけ柔軟に などで表現できるので，変数は状態を表す絵が置か 解釈して計算がすすむ． れている場所であろうか．このように，プログラミン Viscuit の 実 行 原 理 は 柔 軟 な 書 き 換 え (Fuzzy グ言語を単純に可視化したのではなく，どこまで単 Rewriting) である．これまでの書き換えをベースに 純にしても，その基本的なものが失われずに済むか したビジュアル言語 (StageCast[2] など) では厳密な という問題に挑戦したことである．ちなみに Viscuit 書き換えしか提供できなかったので，オブジェクト で無限に広い紙があれば，チューリングマシンと等 の配置が格子上に限定され，オブジェクトの回転も 価な計算ができる． 許されていなかった． この思想を活かしつつ，Viscuit をネットワーク対 簡単に Viscuit でのプログラミングの例を示そう． 応にし，多人数参加型のアプリケーションに拡張す ここでは簡単のため，柔軟な動きをする例は示され る．そのときに 2 つの側面での議論が必要である． ていない．図 1 は，車が前進するルールとその実行 1. 新しいメタファ 例である．これに，信号が変わるルールと，赤信号 従来の Web，メールなどのインフラをそのまま ∗ HARADA, Yasunori: 日本電信電話株式会社 NTT コミュ ニケーション科学基礎研究所 利用して，それにあった拡張をするのか，それ 1 の利用など，新しい実装技術は年々進歩してい る．それらを具体的なアプリケーションイメー ジを持ちながら進めることができる． 2 新しいメタファ Viscuit のプログラムはルールで表現され，その ルールは計算対象と同じ紙の上に置かれている．ま た，書き換えは，紙の上で行われている．つまり，紙 がプログラムやデータを格納する場所であると同時 に，計算をする場所でもある．この性質を利用して， 図 2: 赤信号で車が停止 新しいメタファを考える． とも，まったく新しい分散システムのメタファ を導入するのか．ここでは，後者を選びたい．新 2.1 無限に広い 1 枚の紙 しいメタファが必要な直接的な理由は，現在の システムが原理的に様々な欠点を持ち，それを 無限に広い紙が 1 枚あり，それを多人数で書いた つぎはぎ的に解決してきた，という経緯がある り読んだりする，というメタファを導入する．ユー からである (たとえば，メールだと，遅配，紛 ザは紙の一部を見ている．いくつかの性質を良くす 失，詐称など)．これらの古いシステムは，その るために，紙のスケールは導入しない．すなわちす 性質をよく理解した上で使う必要があり，とて べてのユーザは同じ粒度で紙を見ている． 計算は紙の上で行われるアニメーションを生成す もエンドユーザが安心して使えるシステムでは ることである．粒度が統一されているので，それぞ ない． れのアニメーションが極端に異なった複雑さを持つ 間接的な理由としては，新しい分散システムの ことはない．そのため，紙の面積あたりの記憶容量 提案はいつもできるけれど，それを普及させる と計算能力は，ほぼ一定に保つことができる．逆に のは極めて困難である．しかし，今回は Viscuit 記憶容量と計算能力を面積あたり一定として制約を というコンテンツがあるので，その展開に載せ 与えても，ユーザが困ることはない，と考えること ることが可能である．つまり，これまで温めて もできる． いたアイデアを試してみる滅多にないチャンス この制約はユーザに対してリソースの直感的なビ であるといえる． ューを与えることに相当する．つまり，広い面積を 技術的な背景も大きい．VPN, FreeNet/Winny 持っていれば，それだけ計算と記憶のリソースが必 などインターネットの上に新しいレイヤをかぶ 要であるということである．また，実装的な利点も せて，新しい性質のネットワークを作ることが， 大きく，単純に適当な大きさで領域を分割すること 技術的，性能的に容易にできるようになってき でリソースの分散を実現できる． た．つまり，求められている性質を実装をあまり 重視せずに考えることが可能になってきている． 2.2 2. その実装 単純にはクライアントサーバ式，サーバのクラ ポインタ 紙の位置を指し示すポインタを導入する．ここで， スタ化，もっと進んで p2p や遊休コンピュータ ポインタに対して，著者がかねてから証明したかっ 2 たことを実験してみたい．それは，双方向性の導入 使われる．面ポインタの一方の領域に置かれている である．双方向性があるということは，メールアド オブジェクトを他方の領域に表示させる．これは双 レスを知っているということは，逆に自分のメール 方向ではあるが，対称ではない．面ポインタの入力 アドレスが知られている，ということ (一方的にア 側はオブジェクトの配置を参照するもので，それ自 ドレスを知っているということはない) である．著 身はオブジェクトの動きに影響を与えない．一方，面 者は双方向性の欠如が情報化社会のいやらしさの一 ポインタの出力側は，そのポインタの領域自身を一 因ではないかと考えている．これを今回の実装で解 つのオブジェクトのように扱う．つまり，入力側に 消したい．また，双方向性の実装はポインタを格納 配置されているオブジェクトをグループ化して一つ する領域的にみて，高々3 倍の記憶域があれば実現 のオブジェクトのように見せることができる．また， でき，仮にそんなに役に立たなくても大きな問題に 入力側でオブジェクトが動いている場合には，その はならない． 出力側では動いているオブジェクト自身を一つのオ ポインタは 2 種類考えられる．一つは離れた 2 点 ブジェクトとして扱うことができるようになってい を結ぶもの (点ポインタ)，もう一つは離れた 2 つの る．さらに，面ポインタの出力側は複製して使うこ 領域を結ぶもの (面ポインタ) である．後者には 2 つ とができ，一つの入力にある図形を複数の場所で表 の領域が同じ形状，スケールであるという制約を持 示できるようにできる．書き換えのときのオブジェ たせる．いずれも双方向性を持っている． クトの同一性は，同じ入力を持つポインタであるか 点ポインタは，ワープトンネルのように利用する． を調べることで行う． すなわちポインタの一端をクリックするともう一端 簡単なアプリケーションイメージを見てみよう． へ移動する，という使い方ができる．トンネルは双 ユーザは誰かが作ったクリップアートへ移動して， 方向になる． 気に入った絵を使おうと思ったとしよう．その絵は ここで，紙上の座標が XY で指し示すことができ 作者しかアクセスできない領域に直接描かれ，それ ることから，座標 (X,Y) が IP アドレスの置き換え を入力とする面ポインタの出力を公開の領域に置か である，と考えることができる．また，点ポインタ れている．ユーザは自分のクリップボードにその出 の導入により，システムを Web のようなハイパーテ 力を複製して，自分の領域に戻ってくる．そのクリッ キストとして扱うことができる． プボードから複製しながら，ルールと動かす対象を ここで，簡単なアプリケーションイメージを説明す 配置する．それらはすべて同じ領域を入力とする面 る．ユーザがこのシステムにログインすると，自分用 ポインタであるので，同一のオブジェクトとして書 き換えが行われる．これは，URL やファイル名の代 の土地が割り当てられ，そこには世界共通のポータ ルへの点ポインタがあらかじめ用意されている．例 用となっている．ViscuitLand ではファイル名に相 えばある趣味の情報を載せたければ，まず，ホーム 当するのも座標であるし，ローカルなストレージと へ移動し，そこから適当なカテゴリへ移動する．そ いうのも存在しない． こで，新しい点ポインタを生成する．その一端を空 一方，クリップアートの作者は自分の絵がどこで いている場所において，その下に簡単な説明を書く． 使われているかということを，面ポインタを逆にた 次に，点ポインタのもう一端を持って自分の土地に どることで完全に把握できる．また，面ポインタの 移動して，適当な場所に点ポインタのもう一端を置 出力がさらに別の面ポインタの入力の一部になって く．これで，リンクを貼ることができ，他人がいく いた場合 (たとえば，2 つのオブジェクトを組み合わ つかの点ポインタを経由して，自分の土地にやって せてアニメーションを作ったとき，そのアニメーショ くることができるようになる． ン全体をさらに一つのオブジェクトとして扱うよう にした) は，再帰的に面ポインタをたどることでそ 面ポインタは構造をもったドキュメントの表現に 3 3.1 のような間接使用も確実に知ることができる． 2.3 ビジネスモデル ViscuitLand は MMORPG(多人数オンライン型 RPG) に似ているので，実装もそれに似せることが できる．例えば，複数のサーバクラスタによる実装 がそれである．これは，紙が領域で表現されている ので，ネットワーク上の距離などを考慮して，うま い分割をすれば，よい実装が可能である．しかし， MMORPG と同様に，集中サーバの運営にコストが 発生する． 属性のシート 紙の上にはオブジェクトを自由に配置できる．オ ブジェクトには所有者の属性がついている．そのオ ブジェクトの配置を変更したり新しいオブジェクト を紙の上に載せたり，さらに，紙の上のオブジェク トの配置を見せたり，といった許可を細かく設定し たい．それを紙にシートをかぶせることで実現する． 一方で，SETI@home のように，遊休コンピュー タを利用するという方法もある．本当に無限の広さ シートもオブジェクトであるから，所有者が決めら れている．このシートが，土地の所有の概念になる． の (64bit 整数などといわず，多倍長整数の相対アド レスで座標を表現する) 空間を用意すれば，土地に アプリケーションイメージとしては，最初にログ 関するリソースの制約はなくなる．すると，自分の インするとあらかじめそのユーザ用のシートがひか 土地は自分のコンピュータとネットワークで面倒を れている土地が与えられ，その領域を分割しながら， 見る，という実装も可能である．これらが常時運用 他人への読み書きの属性を付けて行くことにある． されているという保証も自分の責任で行わなければ この上でメールのように個人間のコミュニケーショ ならない．しかし，グローバルには，自分の土地は ンを行うには，誰でも書き込めるが，書き込んだ所 世界のどの場所に配置されるのか，ということの合 有者しか見えないという領域を郵便箱として用意し 意を取りさえすればよい． ておき，そこに手紙の内容のポインタを置くという 小学校などの組織では，大きなサーバを導入して， ことになるだろう． そのメンバーの面倒をみる，という実装もある．一 この所有者の情報はシステム全体で統一が取れた 方，どの組織にも属さずに，自分でサーバを起動さ ものであるため，例えば，グループにしか見せない せることもできない人には，有料で提供する，とい という情報は (システムそのものがクラックされる うモデルが成立する． 以外には) 見られることがない． 所有者の ID も，土地上の位置で表現するのがよ 3.2 いだろう．読み書きの許可は，集合の演算になるだ ろうが，面白い表現があるだろう． ミラーリング Viscuit の特徴として，紙の上の情報ですべての 計算が決定されるので，紙を複製して，同じ計算を 実行すると，同じ結果が得られることが保証されて 3 実装 いる．この性質を利用して，領域のミラーリングが 可能となる．両サイトで同期をとる必要があるのは， ユーザのインタラクションなど，非決定的な操作が 実装は集中的，分散的にいろいろな方法が考えら 行われたときのみである． れる．それらの比較の際に，運用するための費用を これによって適度な負荷分散 (特にネットワーク どのように分担するかという視点を導入する必要が トラフィックの分散化) が可能となる． ある． 4 3.3 3.5 リゾルバ オフライン モバイル環境など，ViscuitLand に接続していな ここで必要な技術は，与えられた座標 (または領 くてもそれを使用できるのが望ましい．これには当 域) はどのサーバにアクセスすればよいかを求めるこ 然制約がついてくるが，例えば，自分だけしか書き とである．この計算では，空間の粒度は一定で，2 次 込むことのできない領域では，自由に書き込みが許 元で均一であるという性質を利用して，空間の 2 分 されるだろう．それらは，オンラインになったとき 探索などのアルゴリズムが適用できる．つまり，あ に自動的に更新される． たりをつけてあるサーバに聞きにいき，それよりもっ と下なのか上なのかといった情報で目的のサーバに たどり着く． 4 考察 もちろん，集中管理や階層構造による管理も問題 ViscuitLand はこれまでのネットワークコンピュー ない． ティングをどのように変えたのだろうか? ここまで， 説明してきた機能を組み合わせると (もちろん，非常 3.4 に高度な実装を仮定してであるが)，ほとんどのこと セキュリティ が実現できてしまう．例えば，ローカルなディスク， そのバックアップ，ファイル名，URL，IP アドレス， まず，サーバとクライアントの実装はオープンで 行なうのか，クローズで行うのかという選択がある． メールアドレス，メールサーバ，FTP，といったも のは，それぞれの時代の実装の過程で登場したもの さらに，情報の取扱に関して，ViscuitLand で流 であるが，しかし，より高度な実装技術に包含して， れる情報を不正に操作してならない，という考え方 見せなくすることができるのであった． と，自分の土地にあるもので，自分が所有する情報 Viscuit の書き換えは，まだポインタを含むよう に拡張されていない．これが実現できると，ポイン タを経由して情報を送ることができるかもしれない． つまり，メールの配送に相当するものをユーザが自 分達の手で記述できる，ということになるだろう． は自由に操作してもよい，という考え方の違いもあ る．後者は自分の土地を操作するアプリケーション を自由に記述できる (つまり，Web のブラウザはい ろいろな種類があると同じ) ことである． 無限に広い紙のメタファは Viscuit のような書き 歴史が証明しているのは，実装はオープンで行い， かつクライアントも自由に開発できる仕組みを採用 換え言語以外にも導入可能である．テキスト言語へ するべきである． の拡張なども考えてもよいのかもしれない． 著者はこの方面の専門ではないので，この方面に 直感が働かないが，このような実装で不正を防ぐ仕 5 組みが可能なのだろうか． まとめ エンドユーザにプログラミングの楽しさを簡単に 一つ言えるのは，土地を割り当てるメカニズム (サーバ) はクローズに行う必要があることである． 伝えるために Viscuit を開発した．その簡単さの延長 このサーバでは，認証を行って，土地の所有者であ 線上として，簡単にコミュニケーションできる Visステムに接続できない．一方で，この証明の発行者 cuitLand をデザインし，それをどのように実装すれ ばよいか検討した． であっても，ユーザが隠したい情報をアクセスでき Viscuit は http://www.viscuit.com に簡単なアニ るという証明を発行する．この証明がなければ，シ ない仕組みも必要である． メーションが紹介されている． 5 参考文献 [1] Y. Harada, R. Potter : Fuzzy Rewriting – Soft Program Semantics for Children –, HCC 2003, IEEE. [2] Stagecast Creator http://www.stagecast.com/ . : 6
© Copyright 2024 Paperzz
