Hatena::Groupcatalyst

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

2008-04-30

Moose::Roleのインターフェースとしての役

Moose::Roleのインターフェースとしての役 - dann@catalyst を含むブックマーク はてなブックマーク - Moose::Roleのインターフェースとしての役 - dann@catalyst Moose::Roleのインターフェースとしての役 - dann@catalyst のブックマークコメント

かっちり作りたいときに「これはインターフェースですよ」と明示する仕組みが重要で、JavaInterfaceは優れた言語仕様の一つです。Moose::Roleは、そのInterfaceとしての役割を果たしています(一応、Mixinとしての役割も)。

このMoose::RoleのInterfaceの仕組みは、実装するべき箇所を明文化するのにとても向いています。特にフレームワークを作りたい場合には、役に立つと思います。

YAPC::AsiaでもMooseでフレームワーク作ろうみたいなセッションがあったような。そこだけ聞きたいな。今ならid:tokuhiromさんのMoose版HTTP::Engineが、フレームワークにどうMooseを使うのかのわかりやすい例かも。特にMoose::Roleの使い方は。

# Mooseは、Perlの言語仕様にあったほうがよいものを補完する仕組みが色々とあって、いいなぁと思う今日この頃。OOのシンタクス補完もその一つだけれど、それだけだと思われてしまうとすごい勿体無い仕組みだなぁと。

Moose::Autoboxの拡張

Moose::Autoboxの拡張 - dann@catalyst を含むブックマーク はてなブックマーク - Moose::Autoboxの拡張 - dann@catalyst Moose::Autoboxの拡張 - dann@catalyst のブックマークコメント

Moose::Autobox->mixin_additional_roleでオレオレ拡張ができるようになってます。Moose::Autobox::Arrrayとかに足りないけど追加したいってメソッドは、これで生やしていくのがいいのかも。

以下例。

#!/usr/bin/env perl
use strict;
use warnings;
use Moose::Autobox;

{
    package    # hide me from PAUSE
        Moose::Role::List::More;
    use Moose::Role;
    use Moose::Autobox;
    use List::Util;
    use List::MoreUtils;

    sub sum {
        my ($array) = shift;
        List::Util::sum(@$array);
    }

    sub minstr {
        my ($array) = shift;
        List::Util::minstr(@$array);
    }

    sub maxstr {
        my ($array) = shift;
        List::Util::maxstr(@$array);
    }

    sub true {
        my ( $array, $sub ) = @_;
        List::MoreUtils::true { $sub->($_) } @$array;
    }

    sub false {
        my ( $array, $sub ) = @_;
        List::MoreUtils::false { $sub->($_) } @$array;
    }

}

Moose::Autobox->mixin_additional_role( ARRAY => 'Moose::Role::List::More' );
use Perl6::Say;

say [ 1, 2, 3 ]->sum;
say [ 1, 2, 3 ]->minstr;
say [ 1, 2, 3 ]->maxstr;
say [ 1 .. 10 ]->true( sub { defined($_) } );
say []->false( sub { defined($_) } );

# ActiveSupportっぽいのほしいなぁ。

LorenzoLorenzo2012/10/30 18:26Was totally stuck until I read this, now back up and rnuinng.

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

2008-04-29

Moose::AutoboxでList::RubyLike

Moose::AutoboxでList::RubyLike - dann@catalyst を含むブックマーク はてなブックマーク - Moose::AutoboxでList::RubyLike - dann@catalyst Moose::AutoboxでList::RubyLike - dann@catalyst のブックマークコメント

#!/usr/bin/env perl
use strict;
use warnings;
use Moose::Autobox;
use Test::More qw(no_plan);

my $list = [ 1 .. 2 ];
is $list->push(3)->join(','), '1,2,3';
is $list->map( sub { $_ * $_ } )->reduce( sub { $_[0] + $_[1] } ), 14;

Rubyっぽくなっていい。片っ端からRubyのメソッドを追加して遊ぶのもいいかも。

See also:

http://d.hatena.ne.jp/naoya/20080419/1208579525

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

2008-04-25

RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと

RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと - dann@catalyst を含むブックマーク はてなブックマーク - RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと - dann@catalyst RE:Catalyst::Component(Catalyst::Model::DBIC::Schema)を使った方がうれしいこと - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/charsbar/20080425/1209129640

ということをすると「そういうのはControllerで!」と全力でDISられるわけですが、

うーん、自分が考えている話とはずれてるようなので書いておきます。

既存のAuthentication系のPluginで$c->modelでユーザークラスを参照してたりしますよね。あれを使うためには、「CatalystのModel」を用意してやる必要があると。そうしたときに、POPOのUserのモデル作るだけだと、Catalyst::Model::Adaptorでラップして、Catalystのモデルにしてやる必要がありますよね。で、Catalyst::Model::DBIC::Schemaをベースクラスに使えば、その手間を省けるのかなと思ったわけです。

要するに、Catalyst下では、Catalystのモデルとしても扱いつつ、Catalyst外(内でも)ではPOPOっぽくも扱えるというメリットもあるのかなと思ったわけですが、charsbarさんがそう考えているわけではないというとこですかね。

AuthenticationもPlugin使うのではなくて、「Controllerで」と言われると、charsbarさんの発言の意味を多分理解していないのだろうなぁとは思います。

それはさておき、あらたまって「ベースクラスにすることの意味」と言われると、configのマージを実装しなくてすむ(スクリプトなどから必要な部分のみ上書きできるし、Catalystアプリ上からは ConfigLoaderで上書きできる)ことくらいしか大きな利点はないと思います。

Catalyst::ComponentにしておくとConfig周りの恩恵を受けられるってことですかね。DBICのベースクラスとしての利点よりも。

Configのマージ処理とWAF下で動作するときにPOPOのモデルにConfigをinjectするための仕組みを汎用化すれば、モデルを完全に切り離せるのかなって気がしました。

少し先が見えた気がします。

Catalyst::Model::DBIC::Schemaに依存していても困らないかも?

Catalyst::Model::DBIC::Schemaに依存していても困らないかも? - dann@catalyst を含むブックマーク はてなブックマーク - Catalyst::Model::DBIC::Schemaに依存していても困らないかも? - dann@catalyst Catalyst::Model::DBIC::Schemaに依存していても困らないかも? - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/charsbar/20080425/1209053541

id:charsbarさん、id:typesterさん、どうもありがとうございます。

Catalyst::Model(要するにCatalyst::Component)に依存しているといっても、実質はCatalystという名前がついてるだけで、WAFというレベルでの依存じゃないんだから、ベースクラスに使ったっていいんじゃないか?っていう話だと理解しました。名前にだまされてるっていうのは、こういう話なのかなと。

それで、Catalyst::Model::DBIC::Schemaを継承したクラスで、Catalyst依存にならないようにだけすれば、WAFに依存すると言うものではないので、いいんじゃないかという話なのかなぁと。

後は、継承したクラスをnewしたときに設定されるschemaのインスタンスを使えば、POPOも同然じゃないかって話なのかなと思いました。

あまりこれは考えていなかったんですが、案外これでもいいのかなぁという気もしました。Catalyst::Componentに依存することの気持ち悪さはありますが、実質上の大きな問題は確かにないわけなので。

ただ、POPOとしてだけ扱いたいというときに、schemaのインスタンスを生成して保持しといても大差ないように思えるので、ベースクラスにすることの意味がどれだけあるのかは、よくわかりませんでした。

ただ、CatalystのComponentとしても扱えるようにしておくと、例えばプラグインなどでCatalystのModelを参照している場合に楽できるというのはあるかなぁという気もします。何か他にあれば、是非教えてください!

Catalyst::Componentがベースクラスになっていることに、微妙に違和感はあるものの、Catalystありきという前提であれば、実用上はそれでも問題はないので、charsbarさんがDBIC::Schema isn't so bad...という表現をされているのかなぁという気もするのですが。

# RailsライクにMember->findのような形で扱いたいというのは、DBICの話で、Catalystの話とは関係ない話なので、ここではとりあえず触れずに。

charsbarcharsbar2008/04/26 00:23Authentication::Store::DBIx::Classは、::Userのnewを見ればわかる通り、

resultset => $c->model($config->{'user_class'})

という形で$c->modelがresultsetを返すことを期待していますので、そもそもACCEPT_CONTEXTが埋め込まれているModel::DBIC::Schemaを使うのが大前提です(Adaptorとかでも頑張ればできるでしょうが……)

danndann2008/04/26 02:34orz.. そう考えると、何となくModel::DBIC::Schema自身をベースクラスにすることの意味もある気がしますね。

または、POPOモデルだけを使えるようにするには、$c->model($config->{'user_class'})と参照しているところをオーバーライドできるようにしておいて、サブクラスでresultsetを返せるようにしておくんですかね(Schemaから)。なんだか、この話は前に日記に書いた気がしますね。

悩ましいところですが、Catalystを使う分だと、DBIC依存部分はModel::DBIC::Schema使ったほうが結局楽なのかなぁという気もしてきました。もうちょっと考えてみます。

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

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

2008-04-23

モデルを拡張していくための仕組み

モデルを拡張していくための仕組み - dann@catalyst を含むブックマーク はてなブックマーク - モデルを拡張していくための仕組み - dann@catalyst モデルを拡張していくための仕組み - dann@catalyst のブックマークコメント

モデルを切り離すことの意味として、

  • Testabilityを高めるため
  • Webのコンテキスト以外の再利用ができるようになる

と書いたのだけれど、モデルを切り離したいというのは、それだけが理由ではなかったりします。

モデルを切り離した後には、もう少し先があるんじゃないかなぁと思っていて、スライドの付録に書いていました。WAFとは独立させて、POPOのモデルだけを拡張していけるための仕組みがあったら、モデルを資産として残せる(これは幻想かもしれませんが)、もしくはモデルの後からの拡張が容易になるんじゃないかなぁと思っていました。

拡張する方向としては、以下の二つがあるかなぁと思いました。

  • プラガブルにモデルの機能を追加する仕組み
  • モデルから横断的な関心毎を切り離して、任意の箇所に適用する仕組み

POPOに上記の二つの拡張する仕組みを提供できると、Webの世界と切り離して、モデルだけを育てる仕組みができ、モデルを資産として残していける部分ができるんじゃないかなぁと思っていました。そうでなくても、拡張性の高いモデルを作れる可能性がありそうです。

1つ目。モデルをプラガブルに拡張するための仕組み。id:YappoさんのClass::Component。これはいかにもLLらしい面白いコンポーネントだなぁって思ってます。これはいかにもPerlっぽくて、絶対Javaの世界にはない話なんですよね。モデルをプラガブルに拡張するための仕組みがあれば、モデルを資産として残せる部分もでてきそうです。

2つ目。Javaな世界では、Caching、Transaction、Loggingなど、モデルの横断的な関心毎を切り離して、モデルの外からコードを付与してやる仕組みが流行りました(実際成功したのは、Transaction、Loggingくらいなわけですが。)Transactionなどが、POPOのコードから消えるので、POPOそのもののTestabilityが高くなるわけです。これはこれで価値がありますね。

Class::Component, Moose, (Class::MOP)は上記を実現できる可能性のある面白いライブラリだなぁと思っていて、とても注目しています。

Catalystかわいいよ!

 Catalystかわいいよ! - dann@catalyst を含むブックマーク はてなブックマーク -  Catalystかわいいよ! - dann@catalyst  Catalystかわいいよ! - dann@catalyst のブックマークコメント

自分のスライドも、「CatalystのModel」はいらないと一見DISってるようになってるけど、自分の場合、全然WAFはCatalystでOKなんじゃないかと思ってるということだけ、一応かいときたい!

Catalystの良くないところ

 Catalystの良くないところ - dann@catalyst を含むブックマーク はてなブックマーク -  Catalystの良くないところ - dann@catalyst  Catalystの良くないところ - dann@catalyst のブックマークコメント

CatalystConででたDISの殆どは、$c依存の強さ、Plugin、モデルのWAFへの依存の3点なんじゃないかと思った。けれど、$c依存の強さ、Plugin、については、実際大して問題ないんじゃないかなぁと思った。

というのは、

$cの依存の強さ」については、VC$cに依存していても、フレームワークから切り離して、VC使うことがないので、依存していても気にならないから。Vだけをテストしたいという要求も特になく、それでいいんじゃないかなぁと思ってしまう。だから、VCはフレームワークにある程度密に結合してても、いいんじゃないかと思う。

Pluginについては、プラグインのロード順に副作用があるのとアプリケーションワイドに機能を追加してしまうところが、気持ち悪さの原因なんじゃないかなぁと思った。

これは確かに気持ちが悪い。ただ、実際問題使うプラグインそのものがそんなに多くないわけで、そんなに気にすることないんじゃないかなぁという印象なんだけれど、そういうもんでもないのかなぁ。

仮に20個程度のプラグインをロードして、バッティングする組合わせが複数のセットで考えられますとなると、頭が痛い問題かもしれない。ただ、実際問題使うプラグインは数個と限られているわけで、どちらのケースも問題にならないんじゃないかと思った。ロード順を気にしなきゃいけないというのは正直どうかとは思うけれど、実用上問題ないんじゃないかってこと。

で、モデルについて。モデルについて切り離したほうがいいと思っているのは、単体テストのしやすさ、速度の問題と、他のコンテキストからの利用がありうるケースが多いから。逆に、これが問題にならない規模のアプリケーションでは、あえてモデルを切り離すことのメリットがないわけで、密に依存していても大きな問題にはならないんじゃないかと思う。

プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*)

 プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*) - dann@catalyst を含むブックマーク はてなブックマーク -  プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*) - dann@catalyst  プラグインを使ってはいけないケース (wrap some prepare_* or finalize_*) - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/charsbar/20080423/1208920975#seemore

wrap some prepare_* or finalize_*

If your functionality needs to wrap some prepare_* or finalize_* stages, you won't get around a plugin.

Catalystのマニュアルで言われていた、「wrap some prepare_* or finalize_* stages」っていうのは、charsbarさんが書いている以下の問題のことなのかな。

prepare_*とか)にNEXTで機能を突っ込むときにロード順を気にしないといけない

これは確かに気持ちが悪い。けど、実際問題使うプラグインそのものがそんなに多くないわけで、そんなに気にすることないんじゃないかなぁという印象なんだけれど、そういうもんでもないのかなぁ。

けど、ロード順に副作用があるから、実装見ないと使えないというのは「プラグイン」としてはいまいちだよねというのはわかる気がする。

ただ、実際問題プラグインも5-6個くらいしか使わないわけで、そう考えるとそんなに気にならないんじゃないかって気がするのだけれど。そんなにたくさんのプラグインを使うことが前提になってるような気もしないし。

CatalystCon#1資料-Catalystからモデルを切り離せ

CatalystCon#1資料-Catalystからモデルを切り離せ - dann@catalyst を含むブックマーク はてなブックマーク - CatalystCon#1資料-Catalystからモデルを切り離せ - dann@catalyst CatalystCon#1資料-Catalystからモデルを切り離せ - dann@catalyst のブックマークコメント

slideshareのほうにアップ。

http://www.slideshare.net/techmemo/catalyst-367905/

後で。

# slideshareだとやっぱりスライド変換途中でレイアウトが少し崩れるね。

BaysideBayside2008/04/24 12:30すごく同感です。Java の struts と PHP の Zend Framework に明示的なモデルがないのは、フレームワークは VC だけ用意しておけばOKということなのかもしれませんね。

danndann2008/04/24 22:57仮にWAFがMを提供するにしても、WAFにMが依存しない形でもMを使えるような形でも提供するべきだろうなぁとは思います。要するに、WAFのM --> POPOのM という感じで。

2008-04-22

プラグイン作るな、使うな その2

プラグイン作るな、使うな その2 - dann@catalyst を含むブックマーク はてなブックマーク - プラグイン作るな、使うな その2 - dann@catalyst プラグイン作るな、使うな その2 - dann@catalyst のブックマークコメント

マニュアル嫁って話なわけなので、とりあえず読んでみた。ただ、やっぱりプラグイン作るな、使うなって話はなんか書いてない気がしたなぁ。

http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/ExtendingCatalyst.pod

読む限り、

Pluginを使っていいと言ってるのは、以下の2点

  • request lifecycleの一部を変更したい場合。

When is a plugin suited to your task? Your code needs to be a plugin to act upon or alter specific parts of Catalyst's request lifecycle.

  • 本当にアプリケーションワイドに機能が必要なケース。
    • session, authenticationがその例

Another valid target for a plugin architecture are things that really have to be globally available, like sessions or authentication.

使うなってケースは、以下の二つ。

  • prepare_* or finalize_* stagesなどをwrapするケース。
    • wrapってのがいまいち意味がつかみきれないのと、なんでダメなのかがよくわからない。もっと別の解があるからかな。

If your functionality needs to wrap some prepare_* or finalize_* stages, you won't get around a plugin.

  • 適切なスコープがある場合には、Globalに機能追加するな。これはまぁそうだろうなぁ。
    • ただ、どのスコープでどんな拡張ポイントを用意するのかについては、フレームワーク側で明示すべき話な気はするけど。もっと例がほしいね、ここは。

Please do not release Catalyst extensions as plugins only to provide some functionality application wide. Design it as a controller base class or another suiting technique with a smaller scope, so that your code only influences those parts of the application where it is needed, and namespace clashes and conflicts are ruled out.

ということで、プラグインを使うなって話を、Catalystの中の人が書いているという話しではないというところまでは分かった。上記の中でも、まだ不明点があるから、もう少し考えないといけないね。

プラグイン使うなって話

プラグイン使うなって話 - dann@catalyst を含むブックマーク はてなブックマーク - プラグイン使うなって話 - dann@catalyst プラグイン使うなって話 - dann@catalyst のブックマークコメント

割と多くの人が言っていたのが、Plugin使うな!(作るな?)って話。多くの人が言っていたけど、その理由がよくわからなかった。

認証とかすんのに誰もプラグイン使ってないのかなという素朴な疑問。。。どういうコンテキストでプラグインを使うなと言っているのかが、全然わからなかったからここら辺をえろい人に解説してもらいたいなぁ。

時間あったら、ゆっくりid:charsbarさんとかに聞いてみたい。テーブルがちょっと分かれてしまったからあまり聞けなかったのだけど、ちょっと突っ込んで聞いてみたかったなぁ。

# エロイ人から、少しだけ教えてもらった。

  • Plugin作るな、使うなっていうのは、Catalystの制御フローに割り込むのを作るなってことなんじゃないか?prepare_xxx よんで NEXT するの全部。
    • けど、それが何故まずいのかが、いまいちよくわかってない。
  • C::P::Authentication なんかは controller で呼ぶから別物と考えればいいと思う
  • ExtendingCatalyst

あざーっす。まだ、全く何故ダメなのかということの理解はしてないのだけれど、ちょっと情報あさってみます。lazy-people++

エロイ人が言ってたからとか、マニュアルに書いてあるからという理由じゃ全然納得できないんだなぁ、自分の場合。なんか明確な理由がないと気持ち悪いなぁという。自分の言葉で説明できないと、なんか納得できないんだよね。

CatalystCon#1 感想

CatalystCon#1 感想 - dann@catalyst を含むブックマーク はてなブックマーク - CatalystCon#1 感想 - dann@catalyst CatalystCon#1 感想 - dann@catalyst のブックマークコメント

  • id:ikasam_aさんのROA+Catalystな話
    • Catalyst::Controller::ResourcesでROAって話。既に便利に使わせてもらってる!
  • id:charsbarさんのCatalystの歴史など
    • Pluginダメ、Component使えなど。$cの汚染よくないなど。
      • Pluginダメって理由をもっと詳しく聞きたかった。
  • id:YappoさんのCatalyst::Engineがらみの話
    • HTTP::Server::Wrapperだっけかな(ちょっと違うかも)。Yappoさんの話面白かったなぁ。Catalystと密な話でもないんだけど、WAFのデザインについての話。15分枠で聞きたかった。
  • id:tokuhiromさんのSledge+Catalystのネタ
    • ネタのインパクトが強くてすげー面白い。LTっぽい感じ。
  • id:hide-KさんのModel::Adaptorの話
    • Model::Adaptorが便利なケースがあるのは納得。
  • id:typesterさんの再利用の話
    • Validatorの話がcool. nameベースのValidatorほしい!

CatalystCon#1 プレゼン

CatalystCon#1 プレゼン - dann@catalyst を含むブックマーク はてなブックマーク - CatalystCon#1 プレゼン - dann@catalyst CatalystCon#1 プレゼン - dann@catalyst のブックマークコメント

何回かやった割にはさくっと時間オーバーしてしまった。さらに、コンセントがささってるのに休止状態に orz

本当に伝えたかったことは、

  • MVCのMはWAFの仕事じゃないよ
  • POPOモデル重要

これだけなんだけど、ちょっとスライド引っ張りすぎたのかも。スライドのアップは後で。

MildredMildred2011/08/04 09:52Short, sweet, to the point, FREE-exactly as information shulod be!

vivzenmrmvivzenmrm2011/08/04 22:13opiHjr <a href="http://sxhjtmarrmol.com/">sxhjtmarrmol</a>

ksxgjfokfjksxgjfokfj2011/08/05 20:29OZQ5Zv , [url=http://vsgviiwrgcye.com/]vsgviiwrgcye[/url], [link=http://poqjypxwnxkn.com/]poqjypxwnxkn[/link], http://qmjlmfohnnzo.com/

ihqiprzcgihqiprzcg2011/08/07 00:55ovLaIT <a href="http://irzktwxpxhea.com/">irzktwxpxhea</a>

ixricpqetwixricpqetw2011/08/07 22:07whA4Gx , [url=http://dizpwhgfquda.com/]dizpwhgfquda[/url], [link=http://wurmcvefktra.com/]wurmcvefktra[/link], http://lteysztnyloi.com/

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

2008-04-20

CatalystCon1

CatalystCon1 - dann@catalyst を含むブックマーク はてなブックマーク - CatalystCon1 - dann@catalyst CatalystCon1 - dann@catalyst のブックマークコメント

東京メトロ 銀座線・南北線「溜池山王駅」12番出口より徒歩約5分

東京都港区赤坂2-17-22 赤坂ツインタワー東館 15F

http://labs.cybozu.co.jp/access.html

# スライドは完成。一応14分.

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

2008-04-19

Data::ObjectDriverでmaster-slave構成にするには

Data::ObjectDriverでmaster-slave構成にするには - dann@catalyst を含むブックマーク はてなブックマーク - Data::ObjectDriverでmaster-slave構成にするには - dann@catalyst Data::ObjectDriverでmaster-slave構成にするには - dann@catalyst のブックマークコメント

頭の中では、D::ODからmaster,slaveを透過的に扱う方法をイメージしていたけれど、実はmaster用とslave用のモデルを分ければいいだけかもしれない。そもそも、masterにRWしたい場合には、透過的に扱えないような気がする。

DriverをMaster用、Slave用に用意すればいいってことかな。master, slave構成にするだけなら、DBICとそんなかわらなそうな気がしてきた。

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

2008-04-18

Data::ObjectDriverでのSlaveへの接続

 Data::ObjectDriverでのSlaveへの接続 - dann@catalyst を含むブックマーク はてなブックマーク -  Data::ObjectDriverでのSlaveへの接続 - dann@catalyst  Data::ObjectDriverでのSlaveへの接続 - dann@catalyst のブックマークコメント

Data::ObjectDriverのコードを見るとread用とwrite用のhandleが分けられるようになっている。実装は*r_handle = \&rw_handle;となっていて、r_handleをサブクラスで用意してねって形になっている。

ただ、これだとRead用のdbh取得の実装を分けられるだけで、上記のようなmasterでrwしたいってケースに対応できないように見える。Data::ObjectDriver使ってる人はどうしてるのかなぁと、先週思ったのでした。

#id:miyagawaさんのブクマコメントで 「master-masterだから関係ないよ!」という話が。ありがとうございます!あまり意図を理解してないかもしれないけれど、master-masterのreplicationをしていて、r_handleでreplicationしたmasterを見にいっているという話なのかなぁ。で、masterしかないからmaster-slave構成を考えなくてもよいということなのかなぁ。何か全然違う理解な気もする...

MasterとSlaveのconnectionを分ける

 MasterとSlaveのconnectionを分ける - dann@catalyst を含むブックマーク はてなブックマーク -  MasterとSlaveのconnectionを分ける - dann@catalyst  MasterとSlaveのconnectionを分ける - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/nitsuji/20080418/1208446612

以前、みんなどうやってるのかなぁと思って聞いてみたら、大体同じで、masterとslaveのconnectionを明示的に分けて管理しているという話でした。理由は、masterでRWしたいケースがあるからというもので、それはそういうケースがあって当然な気がする。

ただ、slaveのconnectionをアプリ側で複数管理すべきかはちょっと意見が分かれるだろうなという気がする。nitsujiさんのだと複数じゃなくて一つでもいいわけだけれど。

基本的にはアプリケーション側では一つの仮想Slave相手にして、仮想SlaveのバックエンドのリアルSlaveの存在はロードバランサに任せるという形にしないといけないんだろうなとは思う。そうしないと、ロードバランサの仕事を全部アプリケーション側で面倒みなきゃいけなくなるので、アプリケーション側のロジックが複雑になりすぎるから。

miyagawamiyagawa2008/04/19 09:51はい、その理解であってます。Master Master なのでアプリ側からは slave にかいてるか master に書いてるかは read も write も気にする必要なしです。気にしなきゃいけない場合はちょっとめんどうかもしれませんね。

nitsujinitsuji2008/04/19 10:44>基本的にはアプリケーション側では一つの仮想Slave相手にして、仮想SlaveのバックエンドのリアルSlaveの存在はロードバランサに任せるという形にしないといけないんだろうなとは思う。

今仕事とかではこういうことはやってなくてアプリ側で管理してるんですが、みなさんどうしているんでしょうか?
mysql proxyとか使うとできるみたいなんだけど本番で使われてたりするのかなあ・・
http://forge.mysql.com/wiki/MySQL_Proxy

danndann2008/04/19 10:48どうもありがとうございます。お陰様でよく理解できました!

danndann2008/04/19 11:42nitsujiさん> LVS(+keepalived) 使うのがpopularみたいですよー

danndann2008/04/19 12:34nitusjiさん> 自分の1行コメントだけでもなんなので... naoyaさんの説明がとてもわかりやすいですよー。http://d.hatena.ne.jp/naoya/20060901/1157109663

nitsujinitsuji2008/04/19 20:20おー、なるほど・・。ありがとうございますー。

novinhonovinho2012/07/22 02:40Aritlecs like this just make me want to visit your website even more.

crzhsdwmurcrzhsdwmur2012/07/22 19:23xxPvBo <a href="http://rgxyoqpvajqf.com/">rgxyoqpvajqf</a>

pvchsevzlpvchsevzl2012/07/23 09:10v9wrfc , [url=http://viruyuyhiaoa.com/]viruyuyhiaoa[/url], [link=http://xdspdffzbvzx.com/]xdspdffzbvzx[/link], http://dyviyoyelviu.com/

dfjapksxdfjapksx2012/07/24 08:39vI7Le1 <a href="http://iitpcphcpvdn.com/">iitpcphcpvdn</a>

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

2008-04-17

DBIx:::Class::Cursor::Cached

23:58 |  DBIx:::Class::Cursor::Cached - dann@catalyst を含むブックマーク はてなブックマーク -  DBIx:::Class::Cursor::Cached - dann@catalyst  DBIx:::Class::Cursor::Cached - dann@catalyst のブックマークコメント

コード見た限りでは、

  $rs->all
  $rs->next

のタイミングでキャッシュ。

searchした後とかに使うのはなんとなくイメージができるんだけれど、findとかで使う方法がいまいちわからない。findした結果をキャッシュとか、そういう用途に使うものではないのかな。

cursorとの関係がいまいち理解できてないからなのかも。後、keyが何になってるのかが、dumpしないと何なのかよくわからないから、後でそれは調べる。

update, deleteするときにcacheクリアしたりとかも、DBIx::Classのコンポーネントとして実現できないかと思ったけれど、cursorのことがわかってないからかよく分からなかった。

idをキーにしてキャッシュするというイメージから違うから理解が進まないというのもあるのかもしれない。

DBIx::Class

23:58 |  DBIx::Class - dann@catalyst を含むブックマーク はてなブックマーク -  DBIx::Class - dann@catalyst  DBIx::Class - dann@catalyst のブックマークコメント

ResultsetもCursorも含めて、JavaJDBCに凄い似ている。クラス構成もそっくり。mstな人は実はJava屋さんなんじゃないか。

rzfdltxuarzfdltxua2012/11/02 09:38qX7XOE <a href="http://sievvobronhc.com/">sievvobronhc</a>

ouqkgpouqkgp2012/11/02 14:187W41Zb , [url=http://idxpfqszcxyo.com/]idxpfqszcxyo[/url], [link=http://sqvltntpqyss.com/]sqvltntpqyss[/link], http://bynebjajlais.com/

hhhgrjqzogehhhgrjqzoge2012/11/04 22:58LJ09jb <a href="http://bebzuoaslxkb.com/">bebzuoaslxkb</a>

ccxmxqkdpclccxmxqkdpcl2012/11/05 12:19vrswjm , [url=http://tddwujvcmhqb.com/]tddwujvcmhqb[/url], [link=http://dhmunohsahnp.com/]dhmunohsahnp[/link], http://gaegtufejrjs.com/

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