2009.04.06 Monday
思い立ったらZF
僕が話したのは、「思い立ったらZF」という題目で、つまり、もっと気軽にZendFramework を使おうよという内容のもの。最近、CakePHP を使ってみて、なぜCakePHP は人気があってZendFramework は人気がないのか、僕なりにわかった気がしたので、その辺りをまとめつつ、じゃあ、ZendFramework を使う気になるにはどうすればよいかというようなことをまとめてみた。
スライドはこちら。
思い立ったらZF
スライドだけ見てもあまり伝わらない内容なので、その辺はご容赦ください。要約すると、CakePHP のようにある程度規約で縛りをつけて、それにあわせたファイルレイアウトを、いつでもgithub から手に入れられるようにしておけばいいよ！というもの。
そのgithub のURLはこちら。
junichiro's zf-starter at master - GitHub
自分なりの反省
僕の発表を聞いているうちは、「ほぅ」と思う場面もあったかもしれないが、終わってみるとなにも身に残らなかったのではないかという、きわめて時間つぶし的な発表になってしまったこと。他の発表についても簡単にまとめておく
bayside/ZFではじめる携帯サイト
携帯開発の内容がぎっしり詰まったよい話。ただ、全てをShift_JIS で書くというのにはとても抵抗感がある。
また、「MySQL で文字化けしてしまうのでは？」という質問に対して、常に「SET NAMES sjis」をつけるようにしているとのことだったが、これもZend_Framework で使う場合少し疑問が残る。会場で質問しようと思ったが、なんだかいじわるな質問になりそうだったので自重した。
なぜ、ZendFramework でこれが問題になるかということだが、それには少し確認が必要だ。ZF でどの場所でDBへの接続を行っているか？これはみなさん悩むところだが、おそらくイニシャライザか、アクションヘルパーでやっているだろう。そうすると、DB接続が不要なController やAction でも無駄にDB接続してしまうことになる。パフォーマンスが問題にならなければ、そうそう問題になることはないが、回避策は知っておきたいところだ。ところが、Zend_Db はそこそこできがよく、DBへの接続をどこに書いていようと、ちゃんと遅延評価してくれる。つまり、実際にDBへの接続が必要になったとき、要するに初めてのクエリの発行のタイミングでコネクトを張ってくれる。だから、いろいろなサンプルにあるようにイニシャライザなどでDB接続を行っても、まったく問題ないのだ。
これを踏まえた上で、「SET NAMES sjis」をつけるということを考えたい。おそらく、DBへの接続を行うタイミングでこれを発行しているのだと思う。しかし、ここでいうDBへの接続のタイミングというのは、コード上のことで、実際に接続に行くタイミング(遅延評価された最初のクエリのタイミング)ではないと思う。つまり、イニシャライザにDBへの接続を書いているとしたら、そこに「SET NAMES sjis」を書いているのではなかろうか。こうすると、せっかく本来は遅延評価されるDB接続も、「SET NAMES sjis」というクエリを発行するために、そのタイミングでコネクトを張ることになってしまう。結局、DBを必要としないController やAction でもDBへの接続が行われてしまうことになる。
ちなみに、Perl のDBIC などでは、「SET NAMES sjis」の発行そのものを、遅延評価に含めることができ、最初のクエリ(SELECT文など)が発行されるタイミングで、DB接続と「SET NAMES sjis」の発行を行うことができる。
確かにそう考えると、毎回「SET NAMES sjis」を発行していることが問題なのではなく、その部分を遅延評価することができないZend_Db の問題とも言えるかもしれない。もし、この部分もちゃんと遅延評価できているとしたら、そのやり方を教えて頂きたいと思った次第。
2009-04-04 - Devel::Bayside
twk/はじめてのZend_Form
これもよい話。Zend_Form を使いこなせると、開発効率は格段にアップする。
というのも、そもそものコード量を減らせるだけではなく、書き方が決まっているので、頭を悩ませる時間も大幅に削減できるからだ。また、Zend のよいところでもあるのだが、Zend_Form ひとつとってみても、使い方がいろいろとある。部分的に使ったり、フル機能を使ったり。その辺りも、順を追って説明してくれていて、とてもためになる。実用的で、僕の発表とはワケが違うと思った。コード中心の解説だったので、この発表の内容を紹介するのは大変かもしれないが、是非、ブログ等での公開を期待したい。
twk @ ふらっとへようこそ | twk @ ふらっと
heavenshell/Phwittrについて
九州からの参加。ZendFramework で総合的なサービス開発のソースコードが全部読めるのは、Phwittr くらいなので、これは非常に参考になる。ZendFramework の話というよりは、設計の話が多くなっていたが、僕にとってはそれがむしろありがたかった。みなさんも、ZendFramework を使ってなにかサービス開発するときは、Phwittr を参考にするとよいと思う。これが正解というわけではないとも思うが、ひとつの参考としてとても重宝している。コードはcoderepos にあるので、まとめてローカルにおいてあると、いざというとき手元に参考書があるような感じになるので、便利。おすすめ。
Zend Framework 勉強会＠Tokyo に行ってきた - Heavens hell
wads/自作のZFコンポーネントなど
Zend_Log にローテーションの機能をつけようという話。僕の個人的な感想としては、疑問符がつくないようだったが、まわりの反応は上々だったようだ。Zend のsyoshida さんも「proposal にあげてみたら？」というくらい評価していた。
僕が疑問に思った理由を簡単に書いておこう。そもそもの役割分担として、アプリケーションプログラマはログを吐く(もしくはそれを読む)ところまでが作業領分で、吐かれたログがたまるとか、定期的に掃除するとかは、サーバ管理者の作業領分だと思うからだ。wads さんは、ログに関する一切をZendFramework で完結させたいという考えがあったようだが、逆に僕は、ログのローテーションに関する一切はlogrotate で完結させたいと考えている。だから、仮にアプリケーションプログラマがログの定期的な掃除まで担当することになったとしても、僕はlogrotate に管理させる方がよいと思った。
logrotate と比較して、ZendFramework で実装することのメリットを提示してもらえたら、より面白かったと思う。
wadsのblog
noopable/たとえばZend_Cache
僕自身はZend_Cache をある程度使っていたので、そうでもなかったのだが、Zend_Cache をまだあまり使ったことのない方には非常によい発表だったと思う。そもそも、noopable さんはZend に対しての勉強量が多く、話している内容がわかりやすいのが非常によかった。noopな日々
m-takagi/ZFにまつわる何か
Zend のマニュアルをみんなで翻訳しようよ！という話。
m-takagi さんが話すと、とても説得力がある。
最後に
ust 配信してくださった、nekoget さんありがとうございます。会場を手配してくださった、ウノウ株式会社 Unoh Inc./coco1ban さんありがとうございます。
【参考】
events.php.gr.jp - ZendFramework勉強会@Tokyo