このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

FIT/FitNesseと多重マークアップ/多重データ構造

先週末/今週初めにかけて、Kuwataさんに説教されました(→ http://twitter.com/ckuwata/status/9061149061)。どういうことかと言うと; Catyのテストシステム/テスト体制がまったくなってない、と、そんなことです。

ウォード・カニンガムのFIT/FitNesse

それで、「テストシステム作んないとね」となったわけです。テストとは言っても、プログラマがxUnitなどを使って行う構造テスト(ホワイトボックス・テスト)とは違います。実行可能な仕様記述に近いものが要求されます。そうはいっても、形式仕様記述言語(例えばOBJファミリー)を使うのはシンドイし、通常の開発作業とスムーズに接続するのが難しい。

安直に実行可能仕様記述を書ける方法として、僕が思い起こしたのはウォード・カニンガム(Ward Cunningham)のFIT/FitNesseです。おおざっぱに言えば、FITとは、HTML文書またはWiki文書内にプログラムのアサーション*1を混ぜちゃう手法です。FitNesseはFITの利用環境です。

FIT/FitNesseは、あんまり普及したとは言えません。アイディアは面白いし使い方も簡単なんですが、プログラマにかなりの負担をかけてしまうのがネックになっているんじゃないかな、と思います。

しかし、Catyに限定してしまうと、プログラマの負担*2がゼロになるので、FIT/FitNesseのアイディアが俄然現実的になってきます。FIT/FitNessの方式を拝借することにしました。

繰り返されるデジャブ -- 多重構造

そんな事情で、Caty専用のFITを考えはじめました。Wiki文書にアサーションを混ぜ込めるようにするのです。ということは、通常のWikiマークアップに多少の細工をしてアサーションとしての意味を与えればいいわけです。しばらく試行錯誤しているうちに「あれ?」。デジャブな感覚が湧き上がってくるのですよ -- 「こんなことを僕は何度もやっているぞ」


このダイアリーのなかで「多重マークアップ」という語を検索すると、2005年に書いた4つの記事がヒットします。

特に、タイトルに「多重マークアップ」が含まれる次の記事では、Microformatsを例に多重マークアップを説明しています。

上記の記事から引用すると:

同一の文書インスタンスに、“見た目と意味”とか“人間可読内容と機械処理指令”のような、異なる観点の情報が重ね合わさって含まれるとき、2種類以上のマークアップ・ボキャブラリを混在させてマークアップしなくてはなりません。昔、こういうのを並行文書構造と呼んだりもしました。

一般論としては、多重マークアップなんて、うまくいくわけないのですが、2つ以上のボキャブラリが同一の木構造を共有する(つまり、オーバラップ・レンジは生じない)前提なら、なんとかなります。

同じ記事に:

これ[注:Microformats]を見ると、「いつか来た道」というデジャブを感じますね。…

………

これ[注:Microformats]とまったく同じ多重マークアップ方式で、野望より無謀とも言える構想を提示したのが、時代を先駆けすぎて自滅した仕様「HyTime」です。

僕は、HyTimeには、ちょっと複雑な感情を抱いています -- 興味があればコチラをどうぞ。

2005年にHTMLベースのMicroformatsにデジャブを感じ、2010年にWikiベースのFITにデジャブを感じる -- そんな僕の原体験(デジャブのもと)は20世紀のHyTime体験です。HyTimeは、単一文書に「見た目と意味/人間可読内容と機械処理指令/空間的レイアウトと時間的遷移」など極めて多重多彩な構造を、鬼のような多重マークアップで詰め込もうとしたのです。当然に失敗しました。

しかし、多重文書構造/多重データ構造はやっぱり必要になるんですよね。だから、僕は何度も「いつか来た道」感覚を繰り返すことになるのです。今回のFITでは、通常の文書構造以外に、仕様とテストを記述する構造が重ね合わせてWikiマークアップされています。しかも、この2つの構造が「同一の木構造を共有する」ようになってないのです。2005年に「うまくいかない」と指摘した多重データ構造になっています。

ただし、FITから生まれる多重データ構造はまだしも扱いやすいほうで、2本の木が末端ノードを共有する形をしています。中間ノードが共有されたり、オーバーラップレンジが露骨に出てくることはないので、なんとかなります。

魅惑(?)の多重構造

多重構造が扱いにくのは分かっています。データの共有や絡まりがないクリーンなデータ構造のほうがいいですよね。でも、複数の木やグラフが、部分構造を共有してしまうことは避けられないこともあるし、積極的にそうすることもあります。

一番簡単な例として、複数じゃなくて、ひとつの木/グラフが自分自身の部分構造を共有する事態を考えてみます。これって、循環構造ですよね。循環構造は再帰による無限構造の有限表現だったりします。例えば、[1, 1, 1, ...] という無限リストを、右に無限に伸びる二進木で表すなら:


 ・
 /\
1 ・
   /\
 1  ・
    /\
   1 …

これは次の循環構造で表現できます。(○が小さすぎますが、ルートに舞い戻るループだと思ってください ^^;)


 ・○
 /
1

共有や循環があると扱いにくいのに、あるいは扱いにくいから、なにか惹かれるものがあるのかもしれません。

*1:エクスペクテーションと呼んだほうが適切ですが、アサーションと大差ないです。

*2:フィックスチャを作成する労力です。