Go for it!

はてブロドメインで仮運用中。

BPStudy#26に参加してきた

選手の土曜日にBPStudy#26に参加してきました。

今回は檜山正幸さん(檜山正幸のキマイラ飼育記)と鍬田力さん(Return 0)による「WebフレームワークCatyについていろいろ」でした。

檜山さんの話がはやくて追うのが辛く、かなり走り書きメモ状態です(汗;

動機:ちょっくらWebサイトでも

  • 少しだけ動的
  • デザインはプロに頼む
  • 頼み方が解らない

で、要件と問題点。

  • 小規模、少人数、予算は少なく短納期
  • 本格的なフレームワークはオーバースペック
  • 全部一人でやるのは大変
  • 2〜3人で使えるフレームワークが見あたらなかった

しょうがないので自分で作る。

厳密分離の原理

  • 厳密分離の原理
  • デザイナ(テンプレート):プログラマ(プログラム)を1:1で分離した
  • 間はコンテキストでつながる

catyの場合

  • 厳密分離の原理では1本で分離していたが3本に分離してみた
    • ファシリティ
    • コマンド
    • コンテキスト

図。 bpstudy26_caty_strictseparation

caty問題点

  • ロゴがない、マスコットが居ない
  • 募集中

→誰か作ってください。

重要キーワード

  • ロール
  • スーパーバイザー

ロール=役割(デザイナやプログラマ)、スーパーバイザ=サイト全体の構成考える人。

デザイナはテンプレートを含むUI部分だけ、プログラマはビジネスロジックだけ考えればいい。全体(ディレクトリ構成やURLなど)の統括はスーパバイザに任せることにする。小規模開発では兼任するケースも出てくると思う。

厳密分離の実現のために

  • ロールモデルの分業
    • プログラマ
    • デザイナ
    • スーパバイザ

いまと昔 昔はファイルを見ればサイト構造がわかった。 今はフレームワークを理解しないと(主にURLの?)構造がわからない。

どういうのがオーバースペックか こういうのを作るときに既存のフレームワークはオーバースペック。

  • 近所のラーメン屋
  • 美容院のサイト作り
  • 片手間の企業ウェブサイト

catyでのQuestion 最初にこういう疑問があった。

  • デザイナが作ったテンプレートにプログラムタグ埋め込み
  • プログラマが作ったHTMLをデザイナが調整

→ちゃんと分離できてないじゃん →これでいいのか?

catyの大事なこと 学習が容易なこと

catyのテンプレートでの機能

  • 変数参照
  • ループ
  • 真偽判定
  • インクルード
  • モディファイア、フィルタ

catyいらない機能

  • マクロ
  • ホスト言語の呼び出し
  • 算術演算

厳密分離の先 デザイナはテンプレートを書くが、テンプレートだけでは動作しない。

テンプレートに書いた変数に値を入れて確認したい。でも、プログラマに頼みたくない。ロジックは書きたくない(書けない)。

テンプレート変数にデータを流し込む仕組みが必要。

→caty-scriptでJSONを書いて値を投入する仕組みを作った。

caty-scriptで出来ないこと

  • 関数定義
  • 算術演算
  • ループ

あえて実装していません。複雑なことはプログラマに発注する方針。

URLマッピングありません URLがある=ファイルがある

URLマッピングは複雑で、フレームワークを理解しないと使えない。「URLと同等のディレクトリ構造で、ファイルがあればcatyが駆動する」ようにした。理解しやすいことが重要。

(以下、Caty真の姿ということでメモってませ。悪しからず)

CatyではBetter JSONを目標にJSONを拡張して、コメントやインライン表記などが行える独自記法=caty-scriptをサポートしています。各値の入出力をunix likeな表記=パイプでつなぐとフィルタのように、数珠つなぎで処理を行えるようになっていました。

後半はCatyの真の姿ということで、処理系としてのCatyについて紹介されていました。真の姿の方が時間長かったかも。caty-scriptの処理系を作ることが目的だったのかな〜と思わないでもないです。

Web Application Framework / Templateとしての内容以外はあまり興味がなかったので聞き飛ばしていました(すいません)。

厳密分離の原理=strict separationは分業をする上で有効と感じた。現在のフレームワークには、デザイナがテンプレートを記述しても値を投入する方法が無いし、プログラム側が未実装だと表示試験すら出来ないことが多い。

実際に採用するか?と言われると、いくつか未知数の部分があるので難しいです。

例。

  • 実行環境(python 2.4 or laterがあればOK?
  • モバイルへの対応
  • パフォーマンス

モバイル対応の技術的な可否は、もちろん可能でしょうけれど、Request/Response HTTPヘッダが処理しやすく、入出力フィルタ的なものが実装されていないと面倒だな〜という気分です。そのようなものがあるかどうかは聞き損ねてしまいました。

懇親会は恵比寿のZestで。

適当に座ったらBPのメンバーが5人くらい横並びになりました。あいかわらず顔と本名とnicknameが一致しない!自転車好きなmoriyoshitにも会えた。

顔と名前が一致しないので誰かよくわからんのですが、技術採択の方向性やその理由について熱弁していたところ「今のBPには大人力が不足している、key3のように大人力のある人間が必要だ!」と言われてちょっと嬉しくなりました。

オフショア開発にトラウマを持つharuさんとも少し話をして、オフショアをうまくやれそうな方法があるんですよ〜ゲヘヘ(だからやりましょう)と勧めてみました。最終的なアウトプット、主に品質ですが、については賛否両論あるものの、単純製造に関して言えばオフショア開発のコストメリットは大きいと考えています。ハイ。

23時半頃に流れ解散して家路に。寝過ごして上福岡で茫然自失とし、タクシーがぜんぜん居なかったので3時間くらい歩いて帰りました。

BPStudy参加の皆様おつかれさまでした。

[ad#text_wide]