Hatena::Groupcatalyst

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

2008-03-24

今週末tomyheroさんが囲ってくれるんですが、いつのまにかプチCatalystConになりつつある件について

22:08 |  今週末tomyheroさんが囲ってくれるんですが、いつのまにかプチCatalystConになりつつある件について - dann@catalyst を含むブックマーク はてなブックマーク -  今週末tomyheroさんが囲ってくれるんですが、いつのまにかプチCatalystConになりつつある件について - dann@catalyst  今週末tomyheroさんが囲ってくれるんですが、いつのまにかプチCatalystConになりつつある件について - dann@catalyst のブックマークコメント

id:tomyheroさん、id:hidedenさん、id:vkgtaroさん、id:a666666さんといったlazy-peopleな人たちと、id:typesterさん、id:lyokatoさん、id:ikasam_aさんといったCatalystな人たちといった、えらく豪華なメンバーが集まってます。

最初はlazy-peopleの飲み会だったはずなんですが、いつの間にかプチCatalystConですね。lazy-peopleな人たちをはじめ、Perl界隈で活躍されてる人に会えるのはとても楽しみです。これも一重にlazy-peopleな人のおかげです。

lazy-people++

# けど、誰も店を予約してないけどどっか店に入れるんだろうかw 想定外の人数になっている気がするよ!

# tomyheroさんから店予約しといて!って言われてる>_<。囲われる人なのに、店の予約しちゃってるんですけど!tomyhero--

TDD神話

22:08 |  TDD神話 - dann@catalyst を含むブックマーク はてなブックマーク -  TDD神話 - dann@catalyst  TDD神話 - dann@catalyst のブックマークコメント

自分は常々、テスト駆動開発とサービス開発は相性が悪いなと思っていました。新しい機能を作っているときや、新しいサービスを作っているときは、自分でも答えが見えていない状態で作っていることが多くあります。コードを書いているうちに少しずつ問題が解決されていって、最初は見えていなかったものが見えるようになり、答えがみえるようになる、ということが多々あります。作っては壊しを何度も繰り返すこともあります。

http://d.hatena.ne.jp/naoya/20080324/1206354054

naoyaさんのTDDの話はリアリティがありますね。僕も2003-2005にかけてTDDとテスタビリティについて真剣に取り組んだ時期があって、当時以下のような記事を書いていました。

http://d.hatena.ne.jp/dann/20050823

当時はとあるプロダクト開発で痛い目にあっていたので、真剣にテスタビリティについて考えていました。以下の3冊は、そんなときに読んだ3冊で、テスタビリティを重視した設計を行う方法を考えさせてくれたとても貴重な本だったと思います。以下の本で勉強したことは今も役に立っています。

  • Agile Software Development - Principles, Patterns and Practices
  • Working Effectively With Legacy Code
  • Test Driven Development

最近は、テストのためのパターン本の集大成の本もでていて、テスタビリティを考慮した設計を考えるうえでのボキャブラリもそろってきた感じがします。

そんなこんなで、Javaで培ったノウハウをどうやったらPerlでも活かせるかを考えながら、Catalystを触っている今日この頃です。

トランザクション境界の設定について

20:33 |  トランザクション境界の設定について - dann@catalyst を含むブックマーク はてなブックマーク -  トランザクション境界の設定について - dann@catalyst  トランザクション境界の設定について - dann@catalyst のブックマークコメント

トランザクション境界はサービス層のインタフェースで設定されるべきものなんだろうなと思っています。Java界隈ではこのようなトランザクション境界になるインターフェースをもつクラスをサービスと呼ぶことが多いです。

Serviceのメソッド内でトランザクションの開始や終了のコードを記述してしまう場合、そのServiceクラスのロジックがDBに依存してしまうため、Testabilityを考えると望ましくありません。DBなしではテストがしにくくなるからです。Java界隈ではAOP + DIコンテナでこの問題を解決しています。具体的には、AOPのインターセプタでサービスクラスのメソッドの前後でトランザクションの開始・終了をできるようにするということをやっています。このようにすることで、サービスクラスのロジックには、トランザクションの開始・終了のロジックが入らないため、そのクラスはトランザクションマネージャには依存せず、単体でテストができるようになります。

DBIx::Classを使う場合、どのようにしたらよいのかを少し考えてみました。

DBIx::Classでは、Schemaのtxn_doのメソッドを使って、Unit of workの実行をするのが推奨されているようです。このメソッドは、実行したいUnit of workを、トランザクションの開始と終了で挟んでくれるラッパーメソッドなのですが、これを使うということは、Serviceのロジック中にトランザクションの開始・終了のコードが埋まってしまうことになります。

これだとテストがしにくくなるので、ServiceのロジックをDBに依存せずに単体でテストをするには、どのような方法があるかを考えてみました。

コードをみた限りでは、

Schemaのtxn_doをオーバーライドして、トランザクションの開始、終了を行わないコードにオーバーライドする」

というのが一番簡単でLLらしい解なのではないかと思いました。

これだったら簡単にできますし、割と現実的な気がします。Perl界隈でAOPが流行らないのも、こうしたmonkey patchingで回避できてしまうからというのもあるのかなという気もします。

# LogicパッケージはServiceパッケージに名前を変えることにしました(名前だけ変えただけなんですが)

connectionの永続化

20:54 |  connectionの永続化 - dann@catalyst を含むブックマーク はてなブックマーク -  connectionの永続化 - dann@catalyst  connectionの永続化 - dann@catalyst のブックマークコメント

http://d.hatena.ne.jp/naoya/20060912/1158058322

「各ウェブサーバーのプロセスごとにデータベースへの接続をメモリ内で保持して解放しないでおいて、次のリクエストでもそれを使いまわす」

というものらしい。

  • メリット
    • 1プロセスの中での接続は共有できて節約できる
  • デメリット
    • 複数台のアプリケーションサーバーを並べたときに、プロセスが立ち上がるため、同時接続数がWebサーバーのプロセス数と同一になるため、DB側のリソースを消費する。

だから、connectionを永続化するのはスケールさせるためには、DB側のリソースを消費しすぎるために良くないという話のようです。

MySQLでは毎回コネクションを開いて閉じても、それが遅さの原因となるほど支配的にならないので、1リクエスト内でハンドラを共有すればよい。」

ということなので、1リクエスト内でdbhを共有してもいいんじゃないかということです。こういうのは確かにやってみないとわからない情報でとても貴重ですね。

# この前書いたモデルクラスは、Schema取得する度にconnectしちゃうので、あそこをどうするのがいいのかなと思っていたのでした。

リクエスト毎にconnectする方法について

20:54 |  リクエスト毎にconnectする方法について - dann@catalyst を含むブックマーク はてなブックマーク -  リクエスト毎にconnectする方法について - dann@catalyst  リクエスト毎にconnectする方法について - dann@catalyst のブックマークコメント

DBIx::Classの場合、リクエスト毎にconnectして、そのSchemaを保持しておけばいいということでいいのかな。

リクエスト毎にconnectして、そのスキーマを保持しておくのは、CatalystのPluginを作って、prepareメソッドでconnectすればよさそう。SchemaFactoryを用意しておいて、PluginのprepareメソッドでSchemaのオブジェクトを保持させる。Schemaオブジェクトを参照する側では常にSchemaFactoryを参照して、Schemaを取得するようにするという形にしとけばいいのかなぁ。

mod_perl下で動かす場合に、生成したSchemaインスタンスはどこで破棄すればいいのかな。破棄しないで、リクエストを処理する度にSchemaクラスでconnectして、Schemaのオブジェクトを上書きする形にすればいいのかな。

mod_perlDBICについて、少し知識が足りないので、ここら辺はちょっと勉強しないといけないな。Catalystは何とかなりそうな気がしてきたから、mod_perlDBICについて誰かえろい人に詳しく解説してもらいたい!mod_perlDBICMLの過去ログを一通り少しみてみるかなぁ。

しかし、あまりまとまった情報というのがどこにも書いてないなぁ。誰か知ってたら教えてください!

ChiekoChieko2012/11/01 15:31I was struck by the honesty of your potisng

aiyuyrgcaiyuyrgc2012/11/02 09:387BKNqu <a href="http://ijiiwgkjkaif.com/">ijiiwgkjkaif</a>

ilriywkxakilriywkxak2012/11/02 14:161SPQ1u , [url=http://zmmsipceuptq.com/]zmmsipceuptq[/url], [link=http://tusdfnnozdtx.com/]tusdfnnozdtx[/link], http://opfewxqzzglm.com/

zurniozurnio2012/11/04 22:5754iu8a <a href="http://zxsyrcqrfrng.com/">zxsyrcqrfrng</a>

rohkpwrohkpw2012/11/05 12:17OwmVsT , [url=http://ckwpxlidpoej.com/]ckwpxlidpoej[/url], [link=http://wgbfbocmmjow.com/]wgbfbocmmjow[/link], http://pwztavcxwtnm.com/

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