「WebアプリケーションフレームワークCatyの現状と今後」と似たような題名の記事、まー続きのようなものです。Catyのプロモーション的なことをしてないので、少し宣伝風に書いてみようかと。
「Catyプロジェクト／ソフトウェアについて」（2009年8月）あたりから勘定すると、Catyプロジェクトも2年以上が経過しました。Catyの開発は少しずつしか進んでいませんが、それでも歩みを止めたことはなかったので、気がつけば随分と成長しました。
~/ProjectCaty/OLD $ hg parent
changeset: 2343:753012695e08
tag: tip
user: m_hiyama
date: Thu Aug 11 11:38:50 2011 +0900
summary: 混乱を避けるため、仕様文書を削除 その2~/ProjectCaty/OLD $ cd ../dev
~/ProjectCaty/dev $ hg tip
changeset: 247:e318a0d5dd85
tag: tip
user: ckuwata
date: Tue Nov 08 10:22:19 2011 +0900
summary: Issue #163を修正~/ProjectCaty/dev $ hg locate | wc -l
804~/ProjectCaty/dev $
以前の古いリポジトリでリビジョン2343まで、今のリポジトリではリビジョン247です。公開リポジトリに登録されているファイル数は804、作業領域にはもっとたくさんのファイルがあります。
諸般の事情で、完成度が高い部分と放置状態の部分が混じってますが、特定の用途で安定した部分だけを使うなら、十分に実務で使える水準にあります*1。
しかしCatyは、どんな用途でも使えるかというと、そうではありません。特定の状況を想定して、その状況に対する極端な最適化をしているので、その想定から外れる用途ではウレシクナイことになります。そしてもちろん、「想定している状況」にハマれば、とてもウレシイと思います。その「想定している状況」を次の3つの観点から説明します。
- どのような体制でサイト／アプリケーションを作るのか？
- どのようにサイト／アプリケーションが運用されるのか？
- どのような設計手法を使うのか？
最後のほうで、思い出話とか雑感とかを付け足します。
内容：
- チーム、ロール、専用言語
- 徹底的に分業できる
- 頻繁で激しい変化に対応する
- クライアント中心で設計する
- まとめ
- 檜山にとっての課題
チーム、ロール、専用言語
Catyでは、目的のサイト／アプリケーションを比較的小規模のチームで作ることを想定しています。10人以内くらいです。少人数ではあっても、複数の人々が関与するのが重大なポイントです。一人で作ることは想定していません（一人で作っても別にいいですけどね）。
作業者の分類として3つのロールを仮定します。そのうち2つは、Webデザイナとプログラマです。残る1つ、これを何と呼んでいいか悩みます。以前はスーパーバイザーと呼んでいたのですが、なんか違うな、と。システムの設計者という意味ではデザイナなのですが、それだとWebデザイナと区別付かないし。最近は、指揮者の意味でコンダクターとしていますが、適切かどうかわかりません。とりあえずは、コンダクター、Webデザイナ、プログラマとします。
これら3つのロールが、作業者個々人と対応するとは限りません。一人三役でもかまいません。Webデザイナのロールを、複数の会社で担うこともあるでしょう。あくまでも役割なのです。それぞれのロールが行うことは：
- コンダクター： サイト／アプリケーション全体の構造を定義して、Webデザイナとプログラマの作業範囲を明確にする。
- Webデザイナ： 静的ファイルとHTMLテンプレートを作る。CSSスタイルシートやJavaScriptコードの作成なども作業範囲に入ります。
- プログラマ： CatyScriptまたはネイティブ言語（現在はPythonだけ）で、コマンドと呼ばれるプログラム実行単位を作成する。
それぞれのロールに対して、作業を進めていくための専用言語が与えられます。Catyに備わっている言語の種類は次のとおりです*2。
- CatySchema*3 -- Catyスキーマ言語： 型の定義、コマンドの宣言と定義ができます。
- CatyResAct -- Catyリソース・アクション（・状態）記述言語： Webから見えるインターフェースであるリソースクラスとアクションの宣言と定義ができます。「WebアプリケーションフレームワークCatyの現状と今後」を参照。
- CatyScript -- Catyスクリプト言語： 実行可能なコマンドのコーディングができます。
- CatyTemplate -- Catyテンプレート言語： Smartyとよく似た（完全互換ではない）テンプレート言語です*4。
ロールごとに使用する言語は：
- コンダクター： CatySchemaとCatyResActを使います。
- Webデザイナ： CatyTemplateとCatyScriptを使います。その他、標準的なHTML、CSS、JavaScriptなども当然使うでしょう。
- プログラマ： CatyScriptとネイティブ言語（Python）を使います。
これは、典型例を単純化したもので、実際には、コンダクターがCatyScriptでコマンドを書いてしまうこともあるし、プログラマがCatySchemaを書く必要もあります。どのロールであってもCatyScript（最低でもJSON構文）の知識は必要です。
徹底的に分業できる
ここで「分業できる」とは次のことを意味しています。
- 分割したパートごとの作業の範囲／境界線が明確である。
- パートごとの作業結果の正しさがソフトウェアにより（完璧じゃなくても）確認できる。
- 他のパートの進捗に影響されない。他のパートの作業が先行してようが、まったく未着手であろうが、それに無関係にパートごとの作業ができる。ただしコンダクターの作業は先行する必要がある（後述）。
- 他のパートの担当者と対面（face-to-face）による打ち合わせがほとんど必要ない。
これらのことを可能とするためには、コンダクターによる全体構造の記述が先行する必要があります。もし、コンダクターの作業負担が大きいなら、他のロール／パートの作業を開始できないので元も子もありません。だから、Catyはコンダクターの負担を減らすことに拘っています*5。
また、コンダクターとWebデザイナ／プログラマがほぼ同時に作業を開始できるためには、設計が不完全／未完成であっても、やれる部分からドンドンやっていける必要があります。仕様が変わるのは当たり前なので、変化に対する負担を最小化して、変化を前提に作業をするのです。
技術的に言えば、「分業できる」を支えているのは型システムとバリデータです。パートの境界線には必ず型が定義されており、型の制約が常にチェックされます。型のチェックだけでは完全ではありませんが、それでもあきらかな矛盾はソフトウェアが検出します。仕様の変更により不整合が起きても、型エラーで報告されます。これによる心理的な効果はかなり大きく、変更に対する恐怖心や嫌悪感は薄らぎます。
他のパートからの影響を最小化するためには、パート内で完結したテストが行なえて、単体テストを通ることが統合時の安全性までも保証しなくてはなりません。「単体テストなんてやっても意味ない」という意見を聞くことがあります。その理由は「どうせ統合テストでさんざんにバグが出て直すハメになる。二度手間なだけで無駄」。Catyは型システムの助けを借りて、コンポネントレベルの正しさが全体の正しさを保証するように努めています（100%確実じゃないですけど）。
頻繁で激しい変化に対応する
Webサイト／アプリケーションが、一度作ってソレッキリということは少ないでしょう。とはいえ、内容は更新されるが構造は変わらないサイト／アプリケーションは意外に多いかもしれません。そのようなサイト／アプリケーションにはCMSが向いているのでしょう。
Catyは頻繁で激しい変化に対応できることを念頭に置いてますが、内容の変化ではなくて、サイト／アプリケーションの構造そのものがドンドン変わってしまうような状況を想定しています。例えば、トップページしかない状況で公開して、出来た順に機能を追加し、問題があれば遠慮無く変更や破棄をするようなサイトです。
構造が変わるということは、内容の差し替えでは対応できません。プログラムを書き換える／書き足す必要があるでしょう。全体の構成も変えるかもしれません。そのような変更をしたときに、全体の整合性は保たれるでしょうか？ 稼動しているプログラムと、ヘルプやドキュメントが乖離してしまうのではないでしょうか？ Catyはこれらの問題に対処する手段を提供しています*6。
クライアント中心で設計する
Webサイト／アプリケーションは、主にサーバーサイドで動作します。よって、サーバー側に置いてあるデータベースとかバックボーンのシステムの構造に強く影響されることが多いと思います。
しかし、Webサイト／アプリケーションの利用者はWebクライアントを操作します。バックエンドの事情よりむしろ、クライアントからどう見えるかを重視すべきだと僕は思います。これは、クライアントが人間＋ブラウザのときに限りません。Web APIであってもやはり、クライアント状態とその遷移を中心に考えるべきです。
このことは、「Webサービスを設計するための単純明快な方法」で書いたので、そちらも参照してください。
CatyResAct言語は、クライアント状態を中心に記述する構文を持っています。また、「WebアプリケーションフレームワークCatyの現状と今後」で触れた未完の機能「インスタントモックアップ」は、宣言されたクライアント状態をオンザフライで生成する仕組みです。
まとめ
冒頭に挙げた問に答えておきましょう。
- どのような体制でサイト／アプリケーションを作るのか？ → 比較的少人数のチーム。メンバーは空間的地理的に離れていてもかまわない。それぞれの作業時間や進捗にバラツキがあってもかまわない。
- どのようにサイト／アプリケーションが運用されるのか？ → 頻繁に激しく構造が変化するかもしれない。内容だけでなく、プログラムの追加変更もよく行われる。
- どのような設計手法を使うのか？ → クライアント中心の設計。
檜山にとっての課題
「Catyプロジェクト／ソフトウェアについて」に次の記述があります。
後から思い起こしたのですが、だいぶ以前に小さな実験的なプロジェクト／ソフトウェアにKatyという名前（これもアクロニムじゃない）を付けたことがあるので、僕はこのての名前が好きみたいです。
メモ編でKatyを検索してみると：
2006年の日記が引っかかりますが、それより前からやっていたものです。2008年くらいに少し試していた実験的Webフレームワークの名前はcathandでした。cathand実験はCatyプロジェクトと時間的にオーバーラップしています。
いずれのときも、僕の興味と課題は、先にも挙げた「コンポネントレベルの正しさが全体の正しさを保証する」ことです。このことが、フレームワークの使命と価値じゃないかと思ってます。
「正しさを保証する」というのは、とても難しいことで、あまり生真面目にやるのは精神衛生上よくありません。「正しさを保証する」意図は保ちながらも現実的な妥協をして「手を抜く」必要もあります。それで、手の抜き加減がまた難しい、と。
なにはともあれ、ハッキリしてないことを実装してしまっては「正しさを保証する」なんて出来っこありません。いやまー、現実的な設計判断でハッキリしてない機能が入ることも“ナキニシモアラズ”ですけど … 。可能な限りではありますが、形式意味論（モデル、セマンティックス）を持たない機構は採用しない方針でやっています。
「Catyプロジェクト／ソフトウェアについて」の時点で既に次のように書いています。
コマンド（と呼ぶプログラム実行単位）は、半環圏の上のスタンピング・モナドのクライスリ射でモデル化できるようになっています。
[半環圏は] 2つのモノイド積を持ち、それらが半環（semiring）の法則を満たす圏です。2つのモノイド積を使って2種類のスタンピング・モナドを構成できます。一方が例外モナド、もう一方が副作用モナドに対応します。
昨日の「大量のモナド類似物を取り扱う方法：参考文献」とか、少し前の「デカルト作用圏が面白い」とか、その動機（の一部）はCatyのカテゴリカル・モデリングを確定したいからです。
理屈通りにはいかないのは承知ですが、だからといって理屈を無視してうまくいくわけもなく（破綻するでしょう）、「理屈通りにいったら素晴らしいだろう」という希望に賭けてみるほうがなんか楽しそうだ、と僕は思っています。
*1:インハウスで使う安定版がありますが、公開はしていません。
*2:CatySchemaとCatyResActは概念的には同じ言語で、実装もほとんど統合されています。用途が違うだけです。また、CatyScriptはCatySchemaに埋め込まれているので、CatySchema/CatyResAct/CatyScriptは、実質的には単一の言語です。
*3:SchemaをSchemeと書き間違えた。この間違えで検索とかに引っかかったらゴメンナサイ。
*4:仕組みとしては、テンプレート言語を自由に切り替えることが可能です。しかし、現在まともに使えるテンプレート言語はSmaty風のものだけです。
*5:IDEプラグインとかGUIデスクトップツールを用意できればいいんでしょうが、残念ながらそこまで手を回す余裕は全然ありません。
*6:カニンガムのFIT/FitNesseやクヌースの文芸的プログラミングに触発された機能です。が、高邁なものではなくて、安直で単純なものです。もう少し機能を追加して洗練させる必要があります。
