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

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

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

参照用 記事

Caty:そろそろ公開の予定

昨日、Kuwataさんと打ち合わせて、そろそろ最初のリリース(公開)をしよう、ということになりました。まだ実務で使えるステータスにはありませんが、試作バージョンというか、proof-of-conceptデモという位置付けですね。

9月エンドくらいに公開します。ライセンスは GNU Affero GPL です。公開の直前や直後に解説をまとめて書くのはシンドイので、ちょとずつパラパラ書いていきます。そのことは、以下でも言及しました。

「Catyプロジェクト/ソフトウェアについて」より:

ソフトウェア自体は、一段落したところでソースも含めて公開します。しかし、それで「何を目指しているのか」「何に使えるのか」「他と何が違うのか」などが分かるとも思えないので、説明の労力を省くことはできないでしょう。

後でまとめて文書を作るなんてことは出来そうにないので、折に触れて「何を目指しているのか」「何に使えるのか」「他と何が違うのか」を書いていこうと思います、断片的にでも。

「Catyスクリプト:まだ出来てないけどチュートリアル」より:

ソフトウェアを公開してない今の段階で解説を書いても、実感がなくてツマンナイでしょうが、後でまとめて書くことも負担なので、書けることは書いておくことにします。


Catyが対象と想定しているWebサイトは、デザイン重視でビジネスロジックが余り複雑でなく、応答性能への要求も厳しくないようなサイトです。そのようなサイトについては、Webデザイナだけでも構築できる、あるいはWebデザイナとプログラマが快適に分業・並行作業ができる環境を提供しようとしています。

Catyには、数値的に表現できる優位性は特にありません。何を置いてもとにかく「簡単でわかりやすく/間違いをおかしにくい」と、それが突出して重要な要件で、他の機能性や利便性が犠牲になるのもやむなし、という方針です。

最初の時点で既に書いたように、「簡単さ/わかりやすさ」という言葉に厳密な定義があるわけでもなく、相対的/主観的な面があるので、「簡単さ/わかりやすさ」の我々の定義と尺度を求めて四苦八苦しています。もちろん、最終的には使った人の評価により「簡単さ/わかりやすさ」の正否が決まるのですが、設計実装段階でなんの基準もないのではホントに困ってしまうので、なにやらでっち上げるわけです。

最近考えた尺度のひとつが、変なこと/意図しないことが起きたとき、その原因をユーザー(Webデザイナ、サイト運用・管理者)が突き止める(トラブルシューティングの)とき、どのくらいの知識や手間を要するか? というのがあります。

典型的なトラブルとして、ブラウザでとあるURLにアクセスしたときに、期待している表示が得られない状況を考えます。Catyでは、次のアンケート風のステップに答えていけば、トラブルシューティングができるはず、というかそうなるようにと作っています。箇条書きの各項目の説明は、特別な概念を使わず手短に、かつ具体的な手順として説明できます。

ただし、以下に出てくる「コマンド」、「スクリプト」という言葉はCaty独特の意味で使っています。

  1. Webサイトのトップにブラウザでアクセスできますか?
  2. URLに対応するファイルはサーバー上にありますか?
  3. そのファイルのアクセス権限は適切ですか?
  4. そのファイルはテンプレートですか?
  5. テンプレートの記述は正しいですか?
  6. テンプレートに関連したスクリプトファイルはありますか?
  7. そのスクリプトの記述は正しいですか?
  8. そのスクリプト(メインスクリプト)で他のスクリプトを呼び出していますか?
  9. 呼び出されているスクリプト(サブスクリプト)の記述は正しいですか?(この問は再帰的に適用)
  10. メインスクリプトでコマンドを呼び出していますか?
  11. 適切なスキーマ・ファイル内にコマンドの宣言はありますか?
  12. その宣言の記述は正しいですか?
  13. コマンドはインストールされていますか?
  14. コマンドのインストールは正しくされていますか?

これらのステップに従ってチェックがスムーズに進むには、誰でも、関連するファイル/ファイル内該当箇所を、何の迷いもなく次から次へと追うことができる必要があります。目視では面倒な(不可能であってはいけない)作業には、検証/検査用のツールが備わっている必要があります。

人間はどうせ間違うので、間違う可能性を少なくしたり、間違っても容易にそれを探して修正できることは、Webフレームワークとしても意味があると思っています。それより重要な機能性や価値があるかもしれませんが、他で既に実現されているでしょう。僕からみて一番不足しているように思えたのは、人間の間違い/勘違い/行き違いなどを防いでくれる明快さ(clarity)だったので、そこにフォーカスしようと決めたのです -- それがCatyの動機と方針です。Caty、近日公開。