最近どんな感じで、何を目指してやっているのかを簡単に紹介します。目指していることはイッパイあるのですが、特に「インスタントモックアップ」と我々（僕とKuwataさん）が呼んでいる機能にフォーカスします。インスタントモックアップは、最近着手したばかりで何も出来てないのが実状ですが、できたらけっこう便利そう。すごく便利かもしれません。 インスタントモックアップの目標は「Webサイト／Webアプリケーションのプロトタイプ作成の労力を、百分の一にする」ことです。効率を二桁上げたいわけね。なんかホラ話みたいでしょ。実際、誇張表現なんですが、まったく根拠がないわけでもないんですよ。 内容： 例題「ユーザー管理業務」 Catyの用語を少しだけ モジュールの構造 定義が書いてないモジュール 何をすべきかはナントナク予想できる どんなに中途半端・不完全な設計でも動かす 例題「ユーザー管理業務」 「1年たって

「アイレンベルグ／ムーア圏 その1」において、アイレンベルグ／ムーア圏の定義をいちおうは述べたので、実例を挙げましょう。（[追記]List.map総称関数の型パラメータが間違っているなー、後で直す。[/追記]）（[さらに追記]直しました。[/さらに追記]） 内容： リストモナド リスト関手の余タプル表現 モナドの代数の単位律 モナドの代数の結合律 短いリストで確認する 結局、リストモナドの代数って リストモナド アイレンベルグ／ムーア構成が一番鮮明な形で見えるのは、リストモナドの場合じゃないかと思います。 一般に、圏C上のモナドを (M, η, μ) と書くことにします。ここで、M:C→C、η::IdC⇒M:C→C、μ::(M;M)⇒M:C→C。リストモナド（クリーネスターモナド）を、プログラマに馴染み(?)の記法で定義するなら次のようでしょう。 C := Set M0(A) := Lis

「Webサービスを設計するための単純明快な方法」や「Webサービスの設計：Webの状態遷移図の描き方」で、Webにおける状態遷移の図を示しました。もう少し図の描き方について考えます。そして、それらの図がいったい何を意味するかにも触れます。 内容： アクション、ハイパーオブジェクト＝状態、モジュール＝サブシステム モジュールの図示 いいことありそうだ アクション、ハイパーオブジェクト＝状態、モジュール＝サブシステム まず図の描き方の復習をしましょう。サーバー側の処理であるアクションは小さめの黒丸で表します。アクションのレスポンスとして返されるハイパーオブジェクトは大きめの白丸です。ハイパーオブジェクトはクライアント側の状態と解釈され、リクエストを発行するボタンであるトリガーを持ちます（トリガーが必須ではありませんが）。 いくつかのアクションとハイパーオブジェクト（＝状態）のノード達は互いに繋

最近の記事群で、「クライアント側の状態遷移を中心にしてWebサービスの設計をしたらいいよ」と僕は言っているわけで、実践もしているのですが、まー課題もありますね。 もともと僕は、ハイパーリンクのグラフ構造を正確かつ完全に把握したいという強い要求・願望を持っていました。その1つの方法を提案したのが次の記事です。 Caty：サイトのハイパーリンク構造を把握する 少し長くなりますが、上の記事の最後を引用します。 一旦有向グラフが出来てしまえば、ノード間の可達性、ハブノードの存在、ノード間の経路距離などを判定／算出できます。入次数／出次数（in-degree/out-degree）などから何か計量的な指標が得られるかも知れません。特定のノード（Webコンテンツ）から距離nの近傍（距離がn以内のノードの集まり）を観察したり、可能な経路をすべて列挙してみることで、サイトに関する知見が得られるかも知れませ

「Webサービスの設計： ハイパーオブジェクトとトリガー」において： 僕は「Webとはハイパーリンクなり」と考えているので、Web APIでもなんでもハイパーリンクを使ってないなら「Webっぽい」とは思いません。RPC（遠隔手続き呼び出し）的な要素を取り入れても、ハイパーリンクを活用しているならWebっぽいでしょう。「っぽい」とか「らしい」は単なる趣味嗜好の問題ではなくて、ハイパーリンクの活用は大きなメリットがあります（そのメリットの説明は今日[注：2010年8月11日]はしませんが）。 「ハイパーリンク活用の大きなメリット」について、今日（2010年8月25日）は説明します。 内容： 遠隔呼び出しとHTTP インターフェースと手順の合意 あなたに任せるわ、私は言われるまま 理想のケースは人間がクライアントのとき 状態遷移モジュール インターネット／Webの驚嘆すべき頑健性 遠隔呼び出しと

以前から僕はフローチャートが大好きなのですが、最近いくつかの状況証拠がさらに付け加わって、「計算やアルゴリズム記述の切り札はフローチャートだ」と、ますます強く思うようになりました。 フローチャート大好き フローチャートが、地味ながらも*1計算科学（computing science）の中心部分に在り続けたことは、「フローチャート大好き」とカミングアウトした次の記事に書いています。 フローチャートからマゾ・テストまで 謎の一元体エフイチ（F1）の新しい定式化であるシャイ・ハランのF理論では、直和（双積）とテンソル積を持つ圏をベースにするのですが、これはフローチャート研究の第一人者ステファネスク師匠の半環圏（semiringal category）と同じ概念なのでした。不思議な因縁を感じます。 僕がエフイチにハマる打算的理由（と、ステファネスク師匠） コンヌとマニン 僕がエフイチを知ったキッカ

前置きも書いたことだし、実質的な話を進めましょう。 以前の2つの記事をザッと読んでおいて欲しいのですが、ホントに大事なところはこのエントリー内でも繰り返します。 Webサービスを設計するための単純明快な方法 Webサービスの設計： ハイパーオブジェクトとトリガー 内容： 画面遷移とはクライアント側の状態遷移のこと アクションが起動して結果を返すまで ハイパーオブジェクトとしての状態 アクションノードの内部構造 リクエスト辺と内部辺の切断 ログイン処理の例 状態遷移をモジュールにする 状態遷移モジュールの意義 画面遷移とはクライアント側の状態遷移のこと ここで状態遷移と呼ぶのは、Webクライアント（典型的な例はブラウザ）の状態遷移のことです。サーバー側の状態（リソース状態）は、今は考えないので注意してください。クライアント側の状態をアプリケーション状態と呼ぶこともあります（あんまり適切な用語

「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH

入力値の集合がA、出力値の集合がBである関数fを、f:A→B と書きます。ｆは純関数です。関数が状態に影響を受けるときは、f:S×A→B となります。Sは状態空間です。単に直積の記号「×」では、状態と入力の区別が付かないので、セミコロンで区切ることにします。f:S;A→B 。セミコロンの左が状態ね。fが副作用を持つとき、つまり状態空間Sに作用するときは、f:S;A→S;B と書きます。S→S は状態遷移を表すことになります。 副作用があるかもしれない関数を、次のように分類すると便利です。1は単元集合（シングルトンセット、ユニットセット）です。 f:A→B 純関数 f:S;A→B バートランド・メイヤーの言葉で「問い合わせ」 f:S;A→S;1 バートランド・メイヤーの言葉で「コマンド」 f:S;A→S;B 一度にいろいろするメソッド 以下では、単元集合1は省略します。 メイヤーは、最後の「

「マイクロフォーマットとクリーンHTML」からの引用： 僕がマイクロフォーマットを思い出したキッカケは、WebAPIのデータ形式について考えていたときです。マイクロフォーマット方式でマークアップされたHTML断片をWebAPIで使えないかな？と思ったのです。 「プログラマ／デザイナの境界としてのクリーンHTML」からの引用： もし今後、「要素構造の単純化＋CSSデザインの拡大」がさらに潮流となるなら、プログラマ／デザイナ境界をクリーンHTMLにずらしてもいいのじゃないか、というのが今の僕の考えです。 「WebAPI」の話と「プログラマ／デザイナ境界」の話は、異なる話題のようですが、実は同じ文脈のなかにあるのです。そのことを説明します。 まず最初に断っておくと、僕はXMLやJSON形式の使用を否定しているわけでは全くありません。もう一つの選択肢としてクリーンHTMLを加えてはどうだろう、と言