昨日10月30日(金曜)の夜、BPStudy#26にて、Kuwataさんと一緒にCatyについて発表しました。みなさん、お疲れさまでした。
けっこう空席があるなー、と思ったのですが、もともと80席用意されていたので、60人ほど集まったとのことです。かなりヘンテコリンでまだ出来上がっていないソフトウェアの話を聞きたいという酔狂な方が、そんなにいるとはちょっとビックリしました。
以下に、感想とか補足とか反省とかをダラダラと:
[追記]Kuwataさんも補足説明を書いてます:http://return0.dyndns.org/log/2009/10/31#s_1
資料(スライド)は、http://return0.dyndns.org/doc/bpstudy/bpstudy26.odp[/追記]
ロールとワークフロー
まず感じたことは、水曜のリハーサル「やっぱりパスタの会」がすごく役に立ったなー、ということです。「やっぱりパスタの会」参加者のみなさん、再度ありがとうございます。
パスタの会での指摘をもとに、BPStudy前日(29日)に導入したロールという概念、特にスーパーバイザ・ロールにより、説明がすごくクリアになったと思います。これで、僕が「デザイナ」という言葉を使うたびに(相手に)生じていた違和感、齟齬がだいぶ解消されます。
ロールに関して言えば、業界でマークアップ・エンジニアと呼ばれている職種・職能に対応するロールはどうよ? みたいな話も出ました。「「プレBPStudy」または「やっぱりパスタの会」の後日メモ」にも書いたように、ロールとワークフローはまだ十分に理解してないことなので、これから考えます。
ラーメン屋さんのため
「ラーメン屋さんのサイトを作るためのフレームワーク」というキャッチフレーズは、「やっぱりパスタの会」参加のid:bonotakeさんの提案です。これも、Catyの特性を表現するには非常に有効でした。次のような質問には、「ラーメン屋さんのサイトに、そんなのいらないでしょ」と答えれば済むので。
- スケーラブルじゃないのか?
- 大量アクセスをどうやってさばくのか?
- 数百万件規模のデータベースを扱うには?
Catyは言語処理系なので、インタプリタのパワーを上げれば、上記の要求に応えられなくもないですが、そこをガンバル気はありません。柔軟性を上げるためにURLを動的にディスパッチするなんてのは、鼻からやるわけありません。
テンプレートエンジン
言語処理系としてのCatyにとって、テンプレートエンジンはprintコマンドの実装のひとつ(one-of)に過ぎないのだけど、実務上では重要な部分です。(狭義の)Webデザイナやマークアップエンジニアが直接に触るのはテンプレートの部分なので、問題点の指摘とか良いアイディアがあれば、それは取り入れます。テンプレート展開エンジン(VM)が構文とは切り離されているので、ある程度の融通は効きます。
現状、Smarty風構文のほうばかりやっていて、Genshi風構文がほったらかしなんですが、Genshi風構文にも良い点や独自の可能性があるので、Smarty風が安定したら、Genshi風も使えるようにしたいと思います。
Catyスクリプト
僕たちの心づもりでは、「ラーメン屋さんのためのWebフレームワーク」としてのCatyの紹介が主眼で、インサイドCatyの話題は時間が余ったらのオマケ、という位置付けでした。しかしやっぱり、集まったメンバーが技術者/プログラマなので、オマケのほうがウケた感じでしたね。Kuwataさんのテンションも上がって(上がりすぎて)いたし -- 用途はWebフレームワークなんだから、Yコンビネータが短く書けてもエラクはないんだけど。
構文を決めた僕が言うのもナンですけど、Catyスクリプトは、いいかげん変な、クセのある構文を持ちます。ただ、経験上、ああいう変態構文をいじくりたがる変態人間はヤッパリいるもので、Kuwataさん以外でも、20行もある膨大なCatyスクリプトを書く人間が現れるかもしれません。
構文はともかくとして、強い型付け、並列処理モデル(現在の実装は逐次だけど)、マップ関数あたりは、割とまっとうなんですよ、いやマジで。
Catyスクリプトは、JSONのスーパーセットなんですが、動作する部分(コマンド呼び出し)を取り除いても、次の4つの点でベターJSONになっています。
- 余分なカンマを許す
- コメントが書ける(/* ... */ と // ... が使えます)
- 三重引用符(''')により、WYSIWYG文字列が書ける
- 任意のデータにタグが付けられる
コメント以外は、通常のプレーンJSONにマーシャリング可能で、JSONに対するシンタックスシュガーとして利用可能です。[追記]ただし、拡張されたJSONを使い慣れると、プレーンなJSONとしてはエラーが出て困惑するかもしれません。使い勝手と互換性のトレードオフが難しいですね。[/追記]
この「データ記述言語としてのCatyスクリプト」の話は予想外にウケたみたい。みんな、「JSONのココが不便」と思っていたのかな?
型システム
Catyは、安全性(セキュリティ、フールプルーフなど)には力を入れているのですが、それを支えるのは型システムです。JSONデータしか扱わない! と割り切った上で、JSON上にかなり精密な型システムを構築しています。
型システムを定義する実体はスキーマモジュール(拡張子が.casm, .pcasmのファイル)ですが、スキーマモジュール内でユーザー型定義(type文を使用)とコマンド宣言(command文を使用)が行えます。インタプリタ(Catyシステムの中核)は、実行環境内のすべてのスキーマモジュールをロードしてから実行開始します(効率上の都合で遅延ロードも予定してますが)。
外部から来たデータやテンプレートコンテキストも含めて、ありとあらゆるデータに対して、すべてのタイミングで型チェックが走ります。当然にこれは効率上のオーバヘッドを招きます。しかし、効率より安全性を優先するので、型チェックをやめる気は毛頭ありません。ただし、静的に確認できることはできるだけコンパイル時に済ませ、実行時型チェック=オーバヘッドの最小化は目指します。
ファシリティとmafs(マフス)
([追記]この節は後から足しました。[/追記])
ファシリティについてあまり話せなかったので、ここで補足しておきます。
Catyジャーゴンでは、コマンド/スクリプトが実行されるサンドボックス環境を「Catyちゃんハウス」と呼びます(リカちゃんハウスにインスパイアされました)。Catyちゃんハウスは、外部(OS、Webサーバー、ファイルシステム、コンソールとウィンドウシステムなど)から完全に遮蔽されています。Catyちゃんハウス内で動いているコマンド/スクリプトは、外部について知るすべはありません。
しかし、ファイルシステムをはじめとするストレージ(IOの対象物)がないと、たいていのプログラムは仕事ができません。外を見ることはできない(窓もドアもない)Catyちゃんハウスなんですが、電気・ガス・水道はないと困るだろう、ってわけです。そのようなインフラ設備を提供するのがファシリティです。OSに例えると、デバイスドライバのようなもので、コマンド/スクリプトが要求するストレージアクセスと、実際のIO資源との仲介をします。
特に、ファイルシステムを抽象化/単純化したファシリティをmafs(minimum abstract filesystem)と呼びます。現状、まともに動くファシリティはmafsだけですが、JSONストレージ・ファシリティ、ログデバイス・ファシリティなどは近いタイミングで利用可能となるでしょう。
コマンドから見ると、ファシリティはインターフェースだけで規定され、シェルからのインジェクションで提供されます。コマンドはファシリティの実体を知ることはできません。ファシリティ実装は自由に切り替えることが出来るのです。これにより、コマンドのIOを監視したり、キャッシュ/キューイングしたり、セキュリティラッパーを付けたり、排他制御をしたりが、任意に追加削除できます。別な言い方をすると、コマンドは余計なことを考えずに、素朴にIOすればよくて、面倒なことは(必要があれば)シェルとファシリティがやってくれます。
追記:コマンドのプログラミング
[追記 date="2009-11-04"]デザイナとスーパーバイザの作業負担を軽くする話が多いので、プログラマは難しい作業を強いられる、とか思ったら、それは誤解ですよ。プログラマの作業を軽減するにはどうしたらいいかは、容易に想像も実現もできるので、あえて話題にする気力が湧かないのですが、Catyコマンドのプログラミングは簡単です。
「Catyに関して重要で一般的な注意:表側と裏側は違う」を参照 -- コマンド・プログラマもCatyを使う側の人に分類されます。
ファシリティのプログラミングはそこそこの技量が要ります。が、ファシリティを作る人は少数でも十分です。[/追記]
今後
Catyが解こうとしている問題は単純明快です:低スキル、低予算、短期間の条件下で、ラーメン屋さんのサイトをちゃんと立ち上げてちゃんと運用することです。
サイト作成に関わる人々に、知識や技量を要求することはしません。まー、正確に言えば、要求する知識と技量を最小にすべく努力しますよ、ってことですがね。やり方や選択肢が多ければ人間は迷うので、可能ならば1つのやり方だけを提供し、オプションや設定は極力排除します。柔軟性とカスタマイズ性? そんなの知りません。
悪意のあるなしに関わらず人間は間違います。間違いや混乱を誘発する要因をできるだけ少なくして、人間が間違ってもソフトウェアがそれを検出する。検出が事前にできなかった場合でも実行時に「良くないデータ/コード」の処理/実行を食い止めようとします。
僕とKuwataさんにとってこれらの要求は自然であり、それが実現できないフレームワークでは、「気持ちよく安心して使えないよな」と感じるのです。でも、「ラーメン屋さんのサイトを迅速に作るときに、気持ちよく安心して使える」をマジメに実現しようとすると、解決すべき問題と実装すべき機能のリストが、ちょっと気が遠くなる長さになってしまうのですよね。たまにタメ息をつくのだけど*1、まー、やってみよう。
*1:僕より大きなため息をついているのはKuwataさんですけど。