第１回Zend Framework勉強会@Tokyoに参加してきました
発表のダイジェストはlllnorikolllさんがまとめて下さってますので、私は雑感を。まとめじゃないです！
携帯対応とか
携帯対応については、いくつかの現場で体験してきたので、今回の発表はよくわかりました。
全部SJISで自社サーバ環境ならSET NAMESじゃなくてMySQL*1の設定ファイルに書いても良いよね。と思ったのですが、あれは質疑の中だったので行き違いとかもあったのかな？と少し思いました。
SET NAMESについては別の観点で、ZendFramework勉強会@Tokyo でしゃべってきましたよ | ブログが続かないわけにてまとめていただいています。他にSET NAMESだとセキュリティ面で気を使う面が増えたりもしますね。
この話を聞きながら、某プロバイダで開発したときのことを思い出したのですが、NDAにかからない範囲で書きますと、端末の違いを吸収する機能をフレームワーク、もしくはアプリケーション層内に実装してしまうとメンテナンスコストがあがってしまうので、携帯専用のコンテンツ出力系と画像変換出力プロキシは別途持った方がいいように思いました。現在は各SIerの武器になっていると思うんですが、近いうちにSaaS提供してくるところが出ると思いますね。たぶん。セキュリティ面の考慮がうまくいけば従量課金でがっぽり儲かりそうです。（金の話をしてしまったｗ）
Perlには強力なMobaSiFがオープンソースで提供されているんですが、ZFからMobaSifに接続するコードをだれか書いてませんかね。
規約とか
ZFとCakeの対比の中でZFは良くも悪くも縛りが緩いから・・というお話がありました。自分がなんでZFをやっているかといえば、縛りの少なさ、自由度の高さだったりするわけですが、最近ちょっと不安に思っているのは、ZFも結局Cake化するんじゃないか？っていうあたりです。Zend Framework1.8で盛り込まれるZend_Applicationの"縛り"が当然になっていってそれ前提ってなるとちょっと苦しいなぁと。RoRの後追いをするだけならZF使う意味なんてないよ？とも思いますし。
柔軟性を確保したまま、初期開発工数を最小化するためのツールというのがZend_Toolの目的だとすると、1.8でのZend_ToolとZend_Applicationの出来栄えを注視する必要はありそうです。
junichiroさんの発表の中でgitからプロジェクトをビルドするというお話がありましたが、Cakeほどしばらずにサクッとプロジェクトを立ち上げるための最適解をご紹介いただいたという感じがします。
Zend_Formとか
Zend_Formを使い始めるにあたってのポイントが紹介されていました。基本が網羅されていて、わかりやすかったと思います。
Zend_Formって結局、Zend_Filter_Inputとフォーム系ビューヘルパーとファクトリの集約コンポーネントだと思います。こういう集約型のコンポーネントを使う時って、マニュアルの説明ではアクションコントローラー内のgetForm内でフォームをビルドしているんですが、これはちょっと誤解を生みがちかも？と思いました。コンポーネントのビルドをどこでやるかっていうのは設計依存だと思います。人によってはモデル内だろうし、人によってはプラグインローダーで処理するかもしれない。ActionController内っていうのも当然ありなんで、そのへんで小さな宗教論争を生んでしまうのはもったいない感じがします。
個人的には
- コンポーネントは最初に使うところでビルドする
- ビルドタイミングが分散するときはファクトリーを別に立てる
っていうルールにしているので、そのルールに従うと、設計ごとに最適な配置場所が変わるし、変えられます。コンポーネント化のメリットの一つと思います。コンポーネント指向抜きに、単純なMVC切り分けとなるとコンポーネント化する意味がほとんどないので、「Zend_Filter_Inputとビューヘルパー、モデルをそれぞれ普通に使えばいいんじゃない？」っていう話になってしまう。でも、それじゃコヒージョンが落ちるよねっていうことで、Zend_Formにまとめつつ各エレメントレベルに分離しても使えるよっていう内容まで含んでいて実践的かつ深い話になっていました。
Phwittrとか
http://d.hatena.ne.jp/heavenshell/20090405/1238934368
こちらにスライドが上がっています。内容がかなり濃かったです。勉強会は初参加だったのですが、こういう内容の濃い発表が聞けるとまた行きたくなります。
質疑の中で設計の話が少し出たのですが、その辺の話は大好きｗなので別エントリーを立てます
ログローテーションコンポーネント
私の場合は、鯖屋も兼ねているのでログローテーションをアプリ側で実装するという発想はなかったのですが、ASP（SaaSとは呼ばないで）での利用とか、ZFの利用はある程度規模のある仕事に向いているので、会員ごとにログローテーションのタイミングをアプリケーション毎に変えられるという展開もできそうです。
私がやりそこなった話の続きとか。
私がZend_Cacheを例に出してあげたかった話の核心と↑のログローテーションをPHPでっていう発想は意外に近い話でした。
触りだけで終わったしまったのですが、最後に追加したかったのはZend_Cacheでdos除けのプログラム書いたよっていう話でした。本来ならロードバランサーとかで実装するべきDOS対策をアプリケーションレベルで作れちゃうよ？それってハードウエアレベルで対応するのとちがって、混んでる時は管理者とかプレミアムユーザーだけ見れるようなサイトとか、状況依存で別の対応にしたりとか、そういう構築がサクッと出来ちゃうっていうお話と実例を出そうと思ったのですが、途中で終わってしまいました。他に、DBが落ちるとサイトが表示されないとかいうダサいアプリがいまだに出回ってると思うんですが、最悪でもスタティックなコンテンツぐらい表示させようよとか。
実行タイミングをコントロール出来ていれば状況ごとに違うキャッシュをマージして表示するとかできるんですけどね。
あと１分あればできたかな・・・という気はしてるんですが、時間配分が下手でした。前日に急ぎで作ったからとかいう言い訳はなしですね。
遠くから来ていただいた方やみなさんの貴重なお時間をいただいているのに申し訳ないです。いずれ、別な形でまとめさせていただきたいと思います。
翻訳の話とか
マニュアルの構築とか翻訳の話とかがありました。ちょっとずれますが、XSLTってすごい便利なんですよね。XSLTなテンプレートエンジンというのも考えたりしているんですが、XSLT慣れしているデザイナーさんというのもあんまり聞かない気もするのでそこだけ、ちょっと微妙かなと。（あれ何の話だったけ）
Zendのissueとか。
一応、私もCLA出して登録してます。
http://framework.zend.com/issues/secure/ViewProfile.jspa?name=noopable
issueを早く処理してもらいたいときは、パッチを書いて添付するといいと思うんですが、その場合CLA出しておかないと基本NGですよね？と思うんですがどうなんでしょ。詳しくはわかりませんが、みなさん、簡単なのでCLA出しましょう（笑
追記
ブクマコメントありがとうございます。＞またやりたいですね。
