Lazy Programmer :-p

フレームワーク勉強会

Kansai.pm, waft

kansai.pm

に参加させて貰いました。Thanks!

二つほど考えさせられることがあったので、まとめようと思います。

フレームワークと制約

色々なフレームワークの紹介がありましたが、私的に、一つ良いのがあれば（現在:Catalyst)、それを超えないかぎり他はいらないじゃないかな、と思っていましたが、今回参加したことによって、考えの幅が広がりました。

私がこれまで開発してきたのは、サーバの発注から行うことが一般的で、perlが5.0だけが入ってるとか、CPANのモジュールは使えないなどの制約などは気にしたことはほぼありませんでした。

つまりそうか、「制約の中で動かすようにする必要がある場合の、フレームワークという需要」があるのがわかりました。

ただ個人的に、制約の中でのフレームワークというのは、戦術レベルの対応であって、そういった状態を避けるための戦略的な努力をまずしてから、それでも駄目なケースのアイテムとして使用するべきかなぁとは思う。拡張性が古い環境でやるより、良い環境でやる方が最終的にお客様のためになると思う。

で、ふと思ったんだけど、機能や、不具合を直したりする際に、それが戦術レベルの良くないけど、それしかない対応なのか、戦略レベルの大筋にそった対応なのかという、ステータスがあっても面白い気がした。ちなみに、戦術レベルでの対応をできるだけ減らすのが、プロジェクトマネージャー、リーダの仕事だと思う。

cgi と　mod_perl|fcgi

cgiで動かす場合と、mod_perl,fcgiなどで動かす場合によって、フレームワークの作りを考えなければならない。

cgi

cgiで動かすフレームワークの場合、必要最低限のモジュールのみをuseするような仕組で作るべきだ。それがプラグインであっても、そのリクエストで必要ないならよませるべきではない。拡張しても他のリクエストのパフォーマンスに影響を与えないようにするということ。制限があるカンジ。

mod_perl,fcgi

ロード時に重たい処理をし、リクエストを軽くするフレームワーク。制限がないカンジ。

キーワードとか

• Simon Cozensさんのサインをもらいました。
• 100人集めれるなら、交通費(東京-大阪)出してくれるらしい。
• id:vkgtaro ,id:azurestone さんはできてる
• id:azurestoneさんは意外にカッコいい
• Waft! Waft! Waft!

Permalink | コメント(4) | トラックバック(0) | 21:48