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

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

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

参照用 記事

ハイパーバリデーションに向けて

1年たって、手書きから自動描画へ」は、曖昧で断片的な情報をチョっと書いただけですが、絵(画像)を載せたせいか、思いのほかブックマークとかスターが付きました。そこで、もう少し説明を追加しようかと。

現時点では、まだ試行錯誤的なところも多く、あまり詳しく述べることはできないのですが、Catyにおけるハイパーリンクの扱いは概ね目星が付いた、と思っています。

思い起こすに、ハイパーリンクをどう扱うかを考え込んでいたのは、やはり1年以上も前からです。

去年の年末から今年の正月あたりにもウンウン考え込んでいました。

それから紆余曲折、いろいろと変化がありましたが、ハイパーリンクを合理的に扱う技術的なピースは揃ったと感じています。

当初は、JSONハイパースキーマ仕様を使おうとしていたのですが、JSONハイパースキーマは僕の要求に応えるものではありませんでした。結局は自前の仕様とあいなりました。

可視化すれば分かりやすい

ハイパースキーマとは、ハイパーリンク構造とその制約を定義・記述するものです。Catyのなかでは、ハイパースキーマをcara(キャラ; Caty Resources-and-Actions description)モジュールと呼んでいます。1つのWebアプリケーションはいくつかのcaraモジュールで定義されますが、簡単なアプリケーションなら1つのcaraモジュールでも十分です。

caraモジュールはテキスト構文(Catyスキーマ言語+CatyScript)で書かれていますが、ハイパーリンクのグラフを可視化(ビジュアライズ)すれば、構造の把握が容易になります。次はスクリーンショットです。

Python Imaging Library と IrfanView」で述べた方法で、自動描画した結果をIrfanViewに渡して表示しています。

IrfanViewの裏にいる地味なウィンドウがCatyコンソールシェルです。僕もKuwataさんも「コマンドラインインタープリタが一番使いやすい」という偏見に凝り固まっているので、Catyの主たるUIはコンソールシェルなのです。コマンドラインを拡大して見ると:

描画コマンド viva:draw と、表示コマンド ct:show-image をパイプで繋いでいるのが分かると思います(コマンドの名前はちょくちょく変わったりします)。

画面遷移中心の設計

Webサイトの企画や制作の途中で、画面遷移の図をよく見せられたことがあります。画面遷移から設計を始めるのがよく行われていて、それが分かりやすい方法なら、Catyでも同じ方法を採用しようと思ったわけです。「Webサービスを設計するための単純明快な方法」は、この判断に対するラショネールです。

先のスクリーンショット内の図は、簡単なWikiシステムですが、単一のcaraモジュールから構成されます。黄色い四角は画面(Webページ)です。小さな薄緑の丸はサーバー側の処理単位(アクション)です。4つの画面を簡単に説明しておくと:

  1. Wiki index 画面: Wkiページの一覧(リンク集)
  2. Wiki page 画面: 特定のWikiページの表示
  3. Wiki edit 画面: 新規または既存のWikiページを編集するUI
  4. Wiki plain 画面: Wiki原稿をプレーンテキストとして表示

画面の遷移は矢印をたどればいいのですが、矢印の色の説明をしておくと:

  1. 紫: リクエス
  2. 赤: レスポンス
  3. 青: リダイレクト

例えば、左上のindex画面から出る + new (新規作成の意味)と書かれた紫の辺をたどってみます。

新規作成のリクエストはサーバーに届き、赤いレスポンス辺を経由してedit画面をブラウザに表示します。edit画面からsubmitすると、青いリダイレクトと赤いレスポンスを経由してpage画面に至り、新規作成したそのWikiページが表示されるのです。

可視化したってダメみたい

分かりやすい図が表示されるとウレシクなるのですが、「ハイパーリンクはホントウに難しい」と同じ時期(2日後)に書いた記事「状態遷移指向Webサービス設計の課題:可視化したってダメみたい」を引用しましょう。ダメみたいと悲観的なことを言ってます。

ハイパーリンク(=クライアント側の状態遷移)を記述するデータを別に持てばいいだろう、と。それをもとにグラフを描けるでしょう、と。

仮に、なんらかの「ハイパーリンク(=クライアント側の状態遷移)を記述するデータ」が定義できて、それをもとに有向グラフが描けたとします。果たしてそれでいいのでしょうか? 僕は最初「それでいい」と思っていました。

なにはともあれ、ハイパーリンクの全貌が目視で確認できたら、それは気持ちいいでしょう。精神衛生上は非常にヨロシイ。ですが、そのハイパーリンク -- グラフ構造ですが、それが正しいのを目視で確認するのは容易じゃないです。例えば、ノードが100個ある有向グラフを見せられて、「これは正しい?」と聞かれても答えられません。

事情は型システムと同じです。目の前に出されたデータが、型の制約を満たしているかを人間が目視で判断していたらやってられない。だから型システムがあるわけです。型はスキーマで定義され、バリデータでチェックされます。同様に、“ハイパー型”が“ハイパースキーマ”で定義され、“ハイパーバリデータ”でチェックされないとやってられない。

「ハイパー型システムが必要だなー、欲しいなー」と、僕は切実に思っています。

ハイパースキーマとハイパー型システムはだいたい準備できました。あとはハイパーバリデータです -- これは、実際のWebアプリケーションがハイパースキーマに記述された制約を満たしていることをチェックするソフトウェアです。ハイパーバリデータは、ハイパーリンク・グラフのトポロジーはもちろん、遷移(矢印)に沿って受け渡されるデータの整合性もすべてチェックします。

ハイパーバリデータ、今はジェンジェン出来てません(苦笑)。ですが、1年前/半年前に僕が考え込んでいた事が実装として動き始めているので、また少しずつ少しずつでも進んでいけば、半年後/一年後にはナニか形になるんじゃないかな、と。