Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-04-24

Catalyst::Model::DBIC::Schemaの困るところ

Catalyst::Model::DBIC::Schemaの困るところ - dann@catalyst を含むブックマーク はてなブックマーク - Catalyst::Model::DBIC::Schemaの困るところ - dann@catalyst Catalyst::Model::DBIC::Schemaの困るところ - dann@catalyst のブックマークコメント

Catalyst::Model::DBIC::Schemaの困るところは、例えば、Catalyst::Model::AdaptorでPOPOモデルに委譲したときも、そこからDBICのモデルを参照しようとすると、結局$c->model('DBIC::Member')などと参照しなければいけなくなってしまい、POPOのモデルが結局Catalystに依存してしまうところ。

Railsだと、Member.find のように書けるので、これに近い感じで書きたいなぁと思うんだけど、まだそこまで綺麗にかけてない。schemaを隠蔽するところまでは来たんだけれど。週末少し考えたい。

Class::Componentみたいな仕組みはJavaでもできるか?

Class::Componentみたいな仕組みはJavaでもできるか? - dann@catalyst を含むブックマーク はてなブックマーク - Class::Componentみたいな仕組みはJavaでもできるか? - dann@catalyst Class::Componentみたいな仕組みはJavaでもできるか? - dann@catalyst のブックマークコメント

技術的にはできる、正確にはできなくはないといったほうがいいかもしれません。ただ、Javaの場合、仮にできても使われない可能性が高いという感じでしょうか。

これは、

  • メタプログラミングが簡単にはできないこと
  • 静的言語ではあまりメリットがないこと
  • プラグインシステムが流行りにくいライブラリの提供形態であること

の3点の理由からなのかなと思ってます。

1つ目は、メタプログラミングが簡単にできる仕組みがJavaにないからです。バイトコードレベルで操作するライブラリは幾つかあって、AOPもそれらのライブラリで実現されているわけですが、LLと比べて簡単に出来るとはお世辞にもいえません。

2つ目は、動的にメソッドを追加したりということを静的言語でやることのメリットが殆どないということ。コンパイラによる静的チェックの恩恵とIDEでの補完を受けられるところが、Javaでの生産性を支えている要因なので、メタプログラミングなどをすることが多くの場合でメリットがないこと。

3つ目はプラグインのシステムとしての仕組み自身が、Javaのライブラリの提供単位と合わないという話。Javaだとライブラリがある程度大きな単位で提供されていて、CPANのようにミクロな単位でモジュールが提供されることは殆どない。Pluginを追加しようとするときには、割と大きな単位(Jar)での再利用形態しかモジュールを利用できないので、それはちょっと困るわけです。

それで、自分が思っているのは、LLにはLLらしい面白い手法や開発形態があるんじゃないかと思っていて、Perlで面白いなぁと思っていることの一つが、プラグインの仕組み。プラグインの仕組みそのものには、違いはあっても、プラグインの機構は流行っていて、それが面白いなぁと思ったりします。

LLでのDIとDIコンテナの利用

 LLでのDIとDIコンテナの利用 - dann@catalyst を含むブックマーク はてなブックマーク -  LLでのDIとDIコンテナの利用 - dann@catalyst  LLでのDIとDIコンテナの利用 - dann@catalyst のブックマークコメント

id:ZIGOROuさんから解説キボーンという話があるので、

  • DIの利点とDIコンテナの利点というのが違うという話
  • DIの概念そのものは昔からあったけど、DIコンテナの概念はあまりなかったこと
  • DIはLLだとどういうところで活きる可能性があって、どういうケースではいらないのか

については、少し書こうかなぁと思ってます。

LLでは、DIコンテナがなくても解決できる解があるので(それがBetterかはちょっと微妙で自分でもいいのかわるいのかは自分でもわかってはいませんが)、それについて書いていきたいと思ってます。

typesterさんに、もっとコードベースで!という話もあったので、Perlでのコードを交えて話を書こうかなぁとも思ってます。

最初、CatalystConのスライドには、もっとDIが前面に押し出たスライドになってたのですが、Catalystと全く関係なくなりそうだったので、ばっさり削ってしまいました。

ここらの話はYokohama.pmでかな?

ModelがWebのフレームワークから切り離されていることの重要さ

 ModelがWebのフレームワークから切り離されていることの重要さ - dann@catalyst を含むブックマーク はてなブックマーク -  ModelがWebのフレームワークから切り離されていることの重要さ - dann@catalyst  ModelがWebのフレームワークから切り離されていることの重要さ - dann@catalyst のブックマークコメント

JavaでModelをWebのフレームワークから切り離すのは、かなり早い段階から行われていました。で、これはTestabilityうんぬんという話ももちろんあるのですが、もっと切実な理由から行われていました。

JavaではWebアプリケーションをWARという形で、アプリケーションサーバーにデプロイするわけですが、このデプロイがとにかく遅い。普通に2-3分かかったりするわけです。

で、モデルが密にWAFにくっついているとどうなるか?コードを1行修正する度に、デプロイのために2-3分待ってテストとかいうことになります。

これだと生産性うんぬんというレベルではなくなってしまうわけです。だからこそ、JavaではWAFからモデルを切り離すっていう話がすごい受けたわけです。

Perlだったとしても、例えばmod_perlに完全に依存して、Apache再起動しないとテストができないなんて環境でやっている場合には、Perlでも同じように困るんじゃないかと思います。修正する度にデプロイしてテストなんてことになります。Catalystのテストサーバーもそれほど遅くはないですが、それでもモデルのテストをやるという目的には、あまりに遅すぎます。

テスト数が増えれば増えるほど、環境に結合されたモデルなどのテストの実行速度が影響がでてきます。機能規模が大きくなればなるほどテストの実行速度が遅くなります。

そうすると、どうなるか。

結果として、一部のテストしか実行されなくなり、コミットの度にデグレードが発生するということになります。製品開発やサービスの開発をしている人であれば、経験したことがある人は結構多いんじゃないでしょうか。

ですから、極力モデルはWAFからは切り離したほうがいいと思っています。

# 最近は、少しずつJavaでもホットデプロイメントの機構がぽつぽつと目立ち始めているけれど、それでも本質的にはJVMレベルで対応できないと特定の条件、特定の環境でしかホットデプロイメントができないわけで、Java界隈では解決にはもう少し時間がかかりそうです。

typestertypester2008/04/25 10:56> Catalyst::Model::AdaptorでPOPOモデルに委譲したときも、そこからDBICのモデルを参照しようとすると、結局$c->model('DBIC::Member')などと参照しなければいけなくなってしまい

えこれ全然そんなことないですよ。$c に依存していない限りSchema内だけで完結できると思います。

テーブルクラスのメソッドなら
$self->result_source->schema->resultset('Member') とかとか。

typestertypester2008/04/25 11:04隣の席の人に聞いたらそういうことを言ってるんじゃないってことがわかりました。

トラックバック - http://catalyst.g.hatena.ne.jp/dann/20080424