-*- outline -*- todo: 普通の渦巻きを実装 todo: 円のアニメーション todo: inward を関数として実装 todo: inward のシンメトリ todo: アニメ todo: forever の実装 todo: 無限リスト todo: 仮引数 Array.prototype.scale を実装する？ * Javascript で Turtle Geometry * タートルグラフィックスで関数プログラミング プログラミングで大切な考え方に、プログラム自体をデータとして扱うという 話がある。プログラム変換とも言う。Turtle Geometry がヒントになって、も しかしてタートルグラフィックスでプログラム変換を語れるのでは！と思った。 - http://www.cs.wustl.edu/~taoju/research/TurtlesforCADRevised.pdf にあるように、タートル操作をアフィン変換と考える。 - 個々のタートルコマンドは2x2行列で表現出来る。 - するとプログラムはただの行列のリストになる。 - Turtle Geometry にある問題を、リスト操作として実装する。 ここで、ちょっと巻き戻ってタートルグラフィックスとは何かについて考える。 本当はペンを上げ下げ出来るけど、ここでは簡単のため全ての点は一筆書きに 繋がっていると考える。するとタートルグラフィックスの結果はただの点の集 まりで表現出来る。つまり、タートルグラフィックスとは - プログラム -> 点の集合 という関数になる。ここで、プログラムも点の集合もリストと考えると、結局 タートルグラフィックスはリスト変換だと言える。 具体的には、入力が >|| ((forward 10) (turn 90) (forward 15)) ||< のようなリストで、出力が - ((0 0) (0 10) (10 15)) になる関数がタートルグラフィックスだ！という事になる。実装は省略して、これでどんな事が出来るか考える。 ** 正多角形を作る。 (repeat 4 (forward 100) (turn 90)) で四角形が書ける。では、n 角形を描くプログラムはどうやったら書けるだろうか？ (define (rectangle n) (repeat n (forward 100) (turn (/ 360 n)))) todo: 円周率を求める事 * Chalkboard のトレードオフ。アクティブエッセイ用のツールについて(3) 某締め切りの関係で、不本意ながらソースコードも書かず文章ばかり手をかけています。ようするに、こういうのを訳して文体を変えて latex に貼付けるわけです。 前提として、プログラミング言語が高度に発達した将来。人々はプログラミング言語を日常的に書き、語り合う事になるというのを想定しています。機械が自然言語を理解するのでも無く、人間が機械に合わせるのでもなく、両者が歩み寄った形の言語が生まれるでしょう。おそらく 50 年ぐらい未来の話です。私にそのような言語は想像出来ませんが、そんな世界の紙と鉛筆はどうあるべきかというのを今現在の技術で試してみようというわけです。 という戯言はおいといて、デザイン上のトレードオフについて書いてみます。というのも、こういうのを見せると、こんな風に画面のこの位置がこんな風に役割が固定されてあるのが嫌だとか、もっと画面を自由に使って自由にズーム出来るのが良いとか、そういう未来的な意見に接する事があります。自由度という点では明らかに Squeak より劣っている以前に C5 でデモした TileScript より劣っている訳で、これではまるで牙を抜かれた虎ではないか。しかし何事も理由があるのです。 Chalkboard では、プログラムは一連のテキストです。つまり、一つのファイルにメソッドや文章がある順番で並んでいます。C や PASCAL ではメソッドの順序に制限があって、メソッドを定義する前に参照する事が出来ないですが、Javascript にはそういった制限は無く、プログラマが自由にメソッドの順序を決める事が出来ます。Literate Programming の議論であったように、プログラムの動作を説明するのに適した順序で並べるのが望ましいです。 画面構成は、上下スクロールバーのついたエディタが固定した場所を占めています。これは Squeak のようなマルチウインドウな UI と一番違う所です。Squeak ではウインドウを上下左右に自由に配置し、好きなメソッドを同時に参照する事が出来ます。LivelyKernel は SVG 描画機能を使って同じ機能をウェブブラウザ上に再現する事に成功しています。Chalkboard があえて単純な構成を使っているのは二つの理由があります。 まず Chalkboard の目的はウェブブラウザ上に優れた環境を構築する事では無く、表現手段としてのプログラミングを実現する為の最低限必要な要素を提供する事です。そのため Chalkboard は出来るだけ基本的な HTML 要素のみを使い、既存のウェブブラウザの機能を流用する事に重点を置いています。また、数多くのプラットフォームで動作する事を期待出来ます(IE も是非対応したいです)。 もう一つは、自由度を制限する事でアクセスしやすくなる事を狙っています。Chalkboard のエディタにスクロールバーは一つしか無いため、上下の配置さえ覚えていれば望みの位置に素早く移動出来ます。マルチウインドウのシステムでは画面を好きに配置出来るため、複雑な意味ネットワークを持つプログラムでは特に有効ですが、Chalkboard の対象とするような単純なシステムでは上下左右の位置関係、ウインドウの重なりを把握する手間が大きすぎると思います。 Chalkboard では、ファイルフォーマットに HTML をそのまま使っています。実行時にはその中から PRE タグの内容を取り出し、順に評価して行きます。編集は H1 や PRE など、行単位の編集のみで、単語単位の強調は出来ません。また、フォントなどの表示属性の変更は出来ません。これは、ブラウザごとの編集機能を標準化する目的と、文書の論理構造が壊れるのを防ぐ目的があります。つまり、自由度の大きすぎる WYSIWYG 編集機能によってユーザが予期しない事が起こらないようにとの配慮です。　これらのデザイン上の決定は、今までのプロジェクトの反省を基に行いました。Chalkboard にはまだユーザは居ませんが、フィードバックを基にさらに最適化してゆく予定です。 * 概要 この論文では、プログラム言語を使ったインターネット上の学習とコミュニケー ションを支援するツールについて述べます。最新の成果として Active Essays の考えを元にしたウェブアプリケーション Chalkboard の実装と応用について 紹介する他、そこへ至までの試行錯誤と設計上の決定、未解決の問題について 述べます。 プログラミング言語は作業手順を機械に伝える手順として始まりました。最初 はただ効率よく機械に手順を伝えるだけの目的だった物が、メモリと速度の改 良によりアルゴリズムを小さな部分に分割し、人間に分かりやすく表現する事 が可能になりました。また、長期間運用されるプログラムが現れ、機械への指 示以上にメンテナンスのしやすさ、人間にとっての読みやすさが重視されるよ うになりました。ここではさらに考えをすすめ、プログラムを学習とアイデア 交換のためのツールとして捉えます。 プログラムを学習の為のツールとみた時に、自然言語にも数式にも無い特徴が あります。それは曖昧さを含まず、機械によって実行可能であるという点です。 ある正しいアイデアにたどり着く最も簡単な方法はプログラムを書いてみる事 です。初めて書いたプログラムはまず最初動きません。プログラマはコンピュー タに悪態を付くでしょうがすぐに間違いがコンピュータでは無く自分自身にあっ た事に気がつきます。そしてエラーとデバッグの繰り返しによって正しい答え に近づいてゆきます。こうして作られたプログラムは他の人が同じ問題につい て学ぶ際に役に立ちます。 一方で、自然言語の利点は細部にとらわれず全体像を捉えるのに適している点 です。また、プログラムに表しにくい why や what を表現する事も出来ます。 そこで、自然言語とプログラムを組み合わせたメディアを作る事で、使いやす い教科書とノートの代わりになると考えます。 インターネットの普及は多くの人に沢山の知識にアクセスする機会を与えまし た。しかし、多くの情報はまだ既存のメディアの模倣にとどまり、この新しい 技術の利点を生かしているとは言えません。ここで述べるインターネットとプ ログラム、そして文学の融合により、新しい可能性が開けると考えています。 * 論文の構成 ** Abstract ** Background Active Essays とは何か？ Literate Programming との関係 Web 技術 Micro world ** Former attempt of Active Essay tools *** OMeta/JS ** Trade offs 画面レイアウト 1D/2D/3D 制限と互換性 ** Chalkboard ** Use case Example ** Conclusion * 構成主義 http://d.hatena.ne.jp/abee2/20080130 ピアジェは「構築主義(コンストラクティビズム)」、パパートが唱えたのが「構成主義 (コンストラクショニズム)」です。 http://en.wikipedia.org/wiki/Constructivism_(learning_theory) http://en.wikipedia.org/wiki/Constructionist_learning Situating Constructionism http://www.papert.org/articles/SituatingConstructionism.html Piaget’s Constructivism, Papert’s Constructionism: What’s the difference? http://learning.media.mit.edu/content/publications/EA.Piaget%20_%20Papert.pdf http://en.wikipedia.org/wiki/Constructivist_teaching_methods 批判意見 In developing this instruction these educators produce materials that require learning to be behaviorally active and not be "cognitively active."[7] * Literate Programming　について http://en.wikipedia.org/wiki/Learning_by_teaching 構成主義(Constructionism)は子供たちが何かを為し作ることを通して学ぶという教育の哲学です。 * 学習と日記と教える事と学ぶ事について。 私も日記には色々勉強中の事を書いてます。というか、ちゃんと知っている事は書かずに知り立てほやほやであやふやな事しか書かないので嘘ばかり書いてあるかも。そういう学習ノートとして日記を活用している人は多いと思います。 誰かに説明すると勉強の理解が深まる事は誰しも感じている事だと思います。紀元前にはすでにセネカという人が、教える事によって我らは学ぶのじゃ。と言ったそうです(http://en.wikipedia.org/wiki/Docendo_discimus)。 で、きっとこういう話は学習理論やらで体系的な理論があるはずだと思って調べてみると、同じく Wikipedia に Learning by teaching を語学教育に使っている例(http://en.wikipedia.org/wiki/Learning_by_teaching)がありました。 なぜ教える事が学ぶ事と結びつくのかについてはよくわかりません。そこで、調べる前にまた持論を展開します。 アフォーダンス的な見方では、動物は環境からの刺激に反応して動くのではなく、環境を操作してみた結果を取り込む事によってのみ動くそうです。これは、いわば目が光線を受けて見えるのでは無く、目からビームが出て物を補足するから見えるのだと言ってるような物で一見荒唐無稽ですが一方成る程と思わせる面もあります。 なぜなら、目はビームが出るように振る舞うからです。 目はカメラと違って、物を見るために常に動かす必要があります。じっと一点を見つめると眼前がぼやっとし白くなって見えなくなってしまうというからです。デジカメこうだったら欠陥商品です。逆に歩きながらでもピンボケせず物を見るというのはカメラに出来ない芸当です。それどころか、人間はどんなに落ち着いた人でも実は微妙にゆらゆら動いているそうです。どうしてこんな状態ではっきり物を見る事が出来るのでしょうか？ アフォーダンスの説明では、動物は見るために光を受け取るだけでなく、体を動かし、目を動かし、結果光線が揺らぐのを感じて対象の位置を割り出すそうです。動き続けるのは織り込み済みどころか不可欠です。動かないと見えないのです。という事は常に対象に刺激を与える可能性があります。だからふと視線を感じたり、見られると美しくなるとか言うのは比喩では無いのです。 こうして自分の運動と対象からの光から作り出すモデルと不変項と呼びます。例えばテーブルを見ると目をいくら動かしても向かい合う辺が平行なのは変わらないですが(遠近法的には無限遠点の位置が不変)、これで、ああ、このテーブルは四角だと感じるわけです。 何かを学ぶ時にも、感覚器と同じ原理が働いているんじゃないかなと思います。つまり、人から話を聞いたり本を読んだりした後の状態というのは目に光が入っただけの状態で、まだ不変項が生まれていません。覚えた知識を使ってみたり、人に話たりして、あれ？なんか違うぞと試行錯誤を繰り返すうちにだんだん不変項が生まれてくる訳です。私のように友達の少ない人は仕方が無いから日記にでも書けば良いです。 面白い事に、この例えを進めて試行錯誤が本当に学習に不可欠なのかというと、そうでも無い事も分かります。丸暗記は役に立たないでしょうか？例えば料理を覚えるのに、分量を覚えるか舌を鍛えるかの違いと言えます。分量を覚えるのは、味の試行錯誤で生まれる不変項の代わりに分量という数字を覚えるという訳です。味を覚えなくても分量を覚えれば料理は作れます。この方法の欠点は応用が利かない事です。逆に、私はよく自分のアフォーダンス力を高めるために本も読まず自分の舌だけを信じて料理をしますが、この方法で作った事の無い料理をするのは至難の業です。 最後ぐだぐだですが、ではでは。 Software Design as a Learning Environment ftp://sunsite.univie.ac.at/pub/languages/logo/cher/el-publications/EL-Memos/memo7.PS.gz 勉強日記の書き方 http://www.hyuki.com/d/200510.html#i20051005165639 * 進捗。アクティブエッセイ用のツールについて(2)。 Chalkboard-ja あれからちょっとサンプルを足しました。Javascript で遊ぶためのツールです。阿部さんの作ったサインカーブも使わせて頂いております。あれから3日程 IE への対応で悩みましたが停滞中。私が阿呆なのか IE が悪いのか分からないが、特にレイアウトが理解に苦しむ難しさです。 http://tinlizzie.org/chalkboard/ja.html 今後、画面構成や機能はもうほとんど変えない予定ですが、細かい部分で色々 問題があります。例えば今エディタに IFRAME と editorMode プロパティを使っ ていますが、これがベストなのかどうか。また、ページを表現するのに #ハッ シュ要素を使っている所。これは Javascript を何度も読まなくてよい利点が ありますが、IE のヒストリが上手く動かなかったり、リンクの張り方が不自然 になるので、諦めて普通にパスを読むを使った方が良いかなあとも思い中。 * ぼくが作った Wiki とワークスペースの歴史 ふと同じようなプログラムを何度も作っている事を思い出し。ちょっと振り返ってみる事にする。 ** Scamper Workspace Scamper Workspace は Squeak で書かれた Web ブラウザで、普通のウェブサイトに書かれた Smalltalk ソースコードを簡単な操作で実行出来るようにした物。 最初のきっかけはこれだった。よく Squeak コード入りの日記なんか書くでしょう。そうするとそれをつい実行したくなってくる。ただそれをコピペして実行するだけでたいした手間では無いのだけど、おや待てよ？Squeak　には最初からしょぼいながらも Web ブラウザ「Scamper」が付いてくる。何でわざわざ他にブラウザが居るのだ？しかし使ってみるとよく分かる違和感。Scamper が単純なテキストと画像しか表示出来ないのは我慢出来るとしても、それでもなぜわざわざコピペがいるのだ？ Squeak の理念は「アプリケーションなんて要らない」という事だ。Squeak の中のすべての部品は有機的につながっていて、例えばソースコードの中でワープロのようなキーバインドやハイパーリンクが使えるし、文字をうてる所ならどこでもそこから Smalltalk コマンドを実行出来る。Scamper もまたそういった環境の一部であるべきだ。つまり例えば日記の中に面白い Squeak のソースコードを書いたら、そのまま選択して実行出来るというのが自然なんじゃないか。というわけで Scamper に数行足して作ったのが Scamper Workspace。 必要な機能は最初から Squeak に備わっていたので、実現は非常に簡単だった。しかしその結果は我ながら思った以上に面白い物になったと思う。山本さんが沢山 Scamper Workspace 向けのコンテンツを作ってどんどん可能性を探求してくれた。 話の流れに沿ってコードを間に挿み、ユーザが順に実行していくという形態は、アイデアを伝えるのにとても効果的だと分かった。特に、そのページに画像が全く無くて文字列とコードだけで構成されている場合に特徴がはっきりした。最初ユーザがページを開いた時には単調な文字列しか現れないんだけど、コードを実行するにつれてそこから画像やアニメーションがどんどん出てくる。どんどんリッチになってゆくウェブ環境への強烈なアンチテーゼになるのでは無いかと僕は思った。なんしか目前の画面には文字しか無いまるで 1995 年のホームページなのに、ここまで面白い物になるとは驚きだった。 ** StackWiki StackWiki は Squeak で書かれた画像付き文書作成ソフトで、文書はウェブサーバーに独自フォーマットで保存する。 StackWiki は Zest and Marmalade に触発されて作った。Zest はローカルで動く Wiki のような物で、簡単な操作で新しいページやハイパーリンクが作れる他、ページの内容は Squeak オブジェクトなのでスクリプトを使ったダイナミックなページを作る事が出来る。StackWiki はこれに加えてさらに HyperCard と Wiki の特徴をさらに強く出した物だ。 StackWiki は複数のページをまとめた一つのプロジェクトから成る。普通ウェブでは、ページ間の関係はリンクだけで表現されて、ページ間に主従関係や階層関係、前後順などは無い。ウェブサイトによっては URL やリンクを工夫して仮想的にこのような構造をユーザに見せている。 ページ間に構造を持たせる事で表示されているコンテンツの全体からの位置が分かりやすくなる一方で UI は煩雑になる。つまり、過去の閲覧履歴に移動する前後ボタンの他、ページ構成に対しての前後移動が必要になる。階層関係のあるサイトではされに親要素、子要素にアクセスさせるため、計三次元的なナビゲーションが必要になる。StackWiki では HyperCard を踏襲し、階層の無い前後だけの構造を持たせた。 バックグラウンドによって、複数ページにわたる同じような構造を一つにまとめる事が出来る。HyperCard では一つのスタックにつき複数のバックグラウンドを作る事が出来たが、StackWiki ではバックグラウンドを一つだけ許した。バックグラウンドは特殊なバックグラウンドページとして実装されていて、そのページに何かを足すと、すべてのページの同じ位置に同じ物が現れる。ここにも高機能さと分かりやすさのトレードオフがある。似た構造が二カ所以上ある時、共通部分をくくりだして一カ所で表現した物をマクロと呼ぶ。マクロを使うと、データに冗長性が無くなり、簡潔でメンテナンス性が良くなる一方で、マクロを使ってマクロを定義なんかすると、だんだん抽象的になってきて扱いが難しくなる。一枚だけのバックグラウンドはマクロの大胆な一般化と言える。 StackWiki のデータはページごとにバイナリ形式で Swiki サーバに保存される。Swiki 自体が Web アプリケーションだが、ここでは Swiki のファイルアップロード機能だけを使っている。サーバーとの通信に HTTP を使う以外完全な独自方式で、Web スタンダードに従っていない。他の web アプリケーションとの連携が不可能だが、Squeak の独自機能を活用し三日で実装した。 ** Tinlizzie Wiki Tinlizzie Wiki とは。Tweak で作った Wiki で、ファイル形式に OpenDocument Format (ODF) を採用し、サーバに WebDAV を用いた物。 StackWiki のデータファイルは完全に独自形式だったが、Tinlizzie Wiki ではちょっと工夫して、出来る限り既存の形式を使う事にした。データ形式に ODF を使った理由は、Tweak のシリアライザが極めて不完全であった他、将来 eToys で作られたコンテンツを移植する際に利用可能なプラットフォームに寄らないデータ形式を調査するという目的もあった。フォーマット選定の基準は、テキストをベースとする事、画像の埋め込みが可能な事、独自要素の埋め込みが可能な事、リンクが可能な事があった。ODF は複数のフォーマットから成るが、特に Presentaion フォーマットが必要な形式に近かった。 ODF は XML を zip で固めただけの単純な形式で、画像などのマルチメディアデータも同じ zip 内に埋め込む事が出来るので、例えば作品から画像だけを取り出すというような事が簡単に出来る。他のプロジェクトへのリンクも画像の埋め込みも URL を使った統一的な手法で扱う事が出来るのも利点だ。また、独自のデータを埋め込めるので、Tinlizzie Wiki ではスクリプトを使ったダイナミックなページを作成し、Open Office Org でも静的ながら閲覧出来るという事も出来る。 出来るだけ自然な形で Tweak オブジェクトを ODF に書き出すために、データの保存には注意を払った。Tweak オブジェクトの最も単純な保存形式は、オブジェクトをシリアライズした物を独自形式で xml に埋め込むという方法だが、例えば、ブックオブジェクトをフレーム内のプレゼンテーションにするなど、他のアプリケーションからも自然に見えるようにした。 ここでの問題は、オブジェクトの状態をどこまで正確に保存するかという点だ。例えば編集中のテキストを保存する場合、テキストの内容だけを保存するのか(シリアライザ)、編集中のカーソル位置を含めてすべて保存するのかという選択肢がある。実装の観点から言うと、指定された変数以外すべて保存するか、指定された変数だけを保存するかという違いになる。Tinlizzie Wiki では後者を採用した。 これには二つのデメリットがある。まず Tweak ではユーザが勝手気ままに既存のウィジェットを組み合わせる事が出来るので、出来るだけすべての状態を保存する事を期待されている点。そして新しいウィジェットを開発するたびに保存ルーチンを書かなくてはならない点。しかしすべてをデフォルトで保存するという戦略は互換性に乏しい。例えばインスタンス変数名はある時点の実装に依存するので、それを元にシリアライズを行うと新しいバージョンのアプリケーションで読み込めない問題が起こる。特にインターネットでデータを共有する場合に頻繁に発生しやすい問題なので、単純なシリアライズは現実的ではないと考えた。作った当時は百年後でも読めるようなメディアを作ろうと思っていた。 サーバーには WebDAV を使った。StackWiki、Tinlizzie Wiki ともほとんどの機能をクライアントで実現し、サーバーはデータの保存だけしてりゃいいけど、WebDAV という共通基盤を利用する事で、サーバー側に Subversion を利用する事でバージョン管理機能を簡単に追加出来る。 ** Javascript Workspace Javascript Workspace はクライアントに通常のウェブブラウザ、サーバに Ruby CGI スクリプトを使ったプレインテキストだけで構成される Wiki だ。 ある日アランさんが、アドビがスクリプトエンジンを Mozilla に寄付したらしいとメールしたのがきっかけで、このプロジェクトは始まった。とにかく Javascrit を覚えなきゃと思ったんだけど、何年も Web の世界から離れていていわゆる AJAX とか言うのにも縁がなく、Squeak の安楽な世界に浸っていたのでまず最初にすべき事は Javascript 上に Squeak の楽ちん環境を構築する事だった。 ここで再度 Smalltalk の Workspace 機能について確認する。Workspace は単純なテキストエディタで、普通のテキスト編集機能に加えて二つのコマンド "do it" と "print it" がある。do it は選択されているテキストを Smalltalk 文として解釈して実行し、"print it" 文は実行結果をカーソル位置に出力する。機能的にはスクリプト言語における REPL 機能と同じだけど、使われ方は結構違う。Workspace の典型的な使われ方としては、あるライブラリの作者がドキュメントとともに利用例を Workspace の中に書いて、ユーザがそれを読みながら実行するという物だ。つまり、REPL が機械とユーザ間との二者対話なのに対して、Workspace はプログラムの著者、ユーザ、機械という三者間での対話となる。 Workspace は Smalltalk にとって欠かせない機能だが、決して Smalltalk の専用機能だという訳ではない。Javascript が使える Workspace があっても良いじゃないかという事で作ったのが Javascript Workspce だった。そしてブラウザの機能ではファイルを保存出来ないから、作ったプログラムを Wiki のように保存するというのは自然な発想だった。 しかし制作の途中で、また余計な事を思いついた。Javascript Workspace を使っていると、Javascript だけでいかに多くの事を表現出来るかに気がついた。例えば Javascript の location を変更する事で他のページに移動出来るなら HTML のハイパーリンクは必要ない。ページの保存に必要な最低限の UI さえあれば、ただテキストボックスがひとつあれば良いだけだ。これは Scamper Workspace にも通じる発想だ。ページの最初のみかけが単純でも、そこからどれだけ豊かな物でも生まれ得る。 この「画面にテキストボックスが一つだけ」という構成は、また隠れている物が一つも無いというラディカルな発想に繋がる。普通のウェブサイトは、表面に見えている情報以外に多くの隠された情報がある。例えばリンク先の URL なんかはマウスを上に置かないと分からない。しかし Javascript Workspace では目に見える物だけが全てだ。do it した結果何が起こるかは、プログラムという形式で目の前に示されている。どんなプログラムでも実行出来るという一見危険なシステムながら、実は何も隠れていないという最も安全なシステムが出来上がる。 Javascript Workspace は単純ながら極めて使いやすいので、そのアイデアは Ometa/JS の UI として採用された。 ** TileScript TileScript は GUI ライブラリとして Scriptaculous を利用し、サーバーに WebDAV を利用したタイルスクリプトが使える Wiki だ。データフォーマットは独自 JSON 使用。 一つの TileScript 文書は複数の段落からなり、段落は Javascript 文かタイルスクリプトか HTML 文だ。タイルスクリプトとは、数字や関数と言った Javascipt の文法要素を示すタイルをドラッグアンドドロップして、文法エラーに苦しまずにプログラムを書くツールだ。好きな HTML 文を書けるので、リッチテキストを使ったドキュメントの間に Javascript コードを埋め込んで、文書を読みながらプログラムを実行してゆくという事を想定している。 TileScript の最初の動機は、eToys を完全に Web 上に再現出来ないだろうかという事だった。その実験はまずタイルスクリプトの Web ブラウザでの実現から始まった。最初 Lively Kernel (SVG) の利用も考えたが、結局ドロップアンドドロップ機能を Scriptaculous で実現し、タイル自体は Table 要素を使う事で HTML DOM だけによるタイルの動作自体は出来た。 次に eToys 環境自体の移植という事になるが、すぐに大変そうだと分かった。見た目上のウェブの特性としては、ユーザのブラウズ環境によって文書のレイアウトが動的に変化するフローレイアウトという事がある。著者は文書要素の具体的な位置を指定せず、文書構造に注目する。結果文書要素は動的に配置され、画面からはみ出た部分は縦スクロールだけでアクセス出来る。 一方 eToys が前提とするのはページレイアウトだ。文書要素の縦横の配置が固定されていて、ある特定の画面解像度を前提としている。これは現実の紙の文書に近く、eToys のようなグラフィカルな制作環境にマッチする反面、画面がはみ出た場合左右スクロールかズームという煩雑な操作が必要になる。 TileScript の目的は単なる eToys の移植ではなく、Web ならではの新しい方向を模索する事だったのでフローレイアウトを採用した。フローレイアウトを使っても埋め込み画像の形式で絶対座標を使ったコンテンツを埋め込む事が出来る。eToys と同じくある時点の変数の内容をリアルタイムで表示する変数ビューワを提供したが、そういったウィジェットもフローレイアウトに沿って配置した。 ** その後 TileScript で想定したコンテンツがちょっと大人向きの物だったので、実はタイルなんか要らずに、普通に Javascript だけで良いじゃないかという事になった。今作っているのは簡単に言うと Javascript Workspace にリッチテキストが使えるようにした物だ。また、方向としてはイアンのやつを使った全然 Web とは関係ない仕組みも作る予定なのだが、Web アプリは継続して行こうと思っている。その理由はフィードバックだ。ここにあげたプロジェクトはほとんど全て内部的なデモの為に作られた物で、まったく外部への公開を意図していないにも関わらずどこから嗅ぎ付けるのかそれなりのフィードバックが得られる。内製ツールだけを使ってシコシコ誰も見ないプログラムを書くのとは全然やる気が違ってくるわけ。ウェブはすばらしい。