Catalyst試してみた

PerlハカーもすなるCatalystといふものを...ということで、今更感爆発ですがちょっといじくってみました。
というか、NDO::Weblogのnaoyaさんが取り上げておられたのをきっかけにしたのですが、実際のところnaoyaさんくらいに噛み砕いてくれないとさっぱり使い方が判らなかったというのでFA。

とりあえず作ってみたのは、このブログの個別エントリについている、記事関連商品のAmazonアフィリエイトを作ってくれるJavaScript貼り付けサービスを、ページへのアクセスがある度にサービスにJavaScriptを要求するのではなく、一度取得した後はしばらくここギコサーバにキャッシュさせておいてそれを表示する、というもの。
要するにjscacheや中継君JSみたいなのを自前で用意した、という事ですが、これは、これらのサービスでキャッシュすると、キャッシュしてくれるのはいいのですが、キャッシュが切れた時（＝再度サービスに結果を聞きに行く時）のサイトアクセスが重くなる、というのが気に入らなかったので、JavaScriptの発行は飽くまでキャッシュされているものを表示するだけで、キャッシュの更新はcron等でアクセスとは非同期に行うものが欲しかったので、作ってみました。
（あ、ちなみに作ってみて完成してますが、以下の記事作成過程の説明やチュートリアルではないです。飽くまで使ってみた印象の記載だけなので、その辺期待しないように）

とりあえず、naoyaさんのチュートリアルに倣うかたちで、Catalystのインストールから...といきたいところだったんだけど、なぜかCPANモジュール経由でインストールできない。
どうも依存性のあるモジュールを再帰的に取得するのに失敗しているっぽい。
仕方ないので、Catalyst本体、及びBundle::Catalyst::Everythingに記載されている副モジュール群を、依存性を確認しつつ手動インストール。
これだけで半日仕事、ちょっと萎え。

インストール後、再びチュートリアルの手順に沿ってCatalystのヘルパースクリプトを走らせる。
するとプロジェクトソースのスケルトンが、Perlの標準インストーラ形式でさくさくっとできてしまう。
トリガスクリプトまで自動作成されて、FastCGIバージョンのトリガも作ってくれるので、デバグ用簡易HTTPサーバでテストしてやった後、バグがなくなればインストーラでPerlのモジュールツリーにインストールして（外部ライブラリでもいいけど）、とりがスクリプトだけApacheのドキュメントルート上で実行してやれば、後はよきにはからってくれる。
チョー楽チン。

ただ、この程度の軽い処理のものをサクッと作るのにはSledgeと比較してもとても楽なんだけど、ケータイサイトとかでっかいものを作ろうとすると、使い慣れてる事もあるし、またセッションやセッション管理先や入出力のエンコーディング変換等、脂っこいところがシステム化されているSledgeの方がまだ今のところ作り易いかな、という感じがする。
Catalystはヘルパースクリプトの充実等、開発環境を整えるというアプローチではSledgeより格段上を行ってるような気がするけど、実際のコーディング上でのデータ処理のフローはそれほどシステム化されてなくて、開発者任せにされているような気がする（逆に言えば自由度が高いわけだけど）。
一方Sledgeは、開発環境を整えること自体は割とプリミティブに手探りな感じ（俺に腕がないからそうなるだけかもしれないけど）なんだけど、一旦案件にあった枠組みができれば、セッション管理や入出力処理なんかから一切解放されて、本当にロジックだけを組むのに集中できる感じがする（処理全体のデータフローの中で、前処理・後処理をフレームワークに安心して任せきって、今のターンの処理だけに集中できる、という感じ）。
そんな印象。まだCatalystでそんなたいしたもの組んだわけではないので、今のところまででの思い込みだけだけれど。

ただ、それぞれの特徴は無視した上で、「モノ」としての完成度を比べれば、デバグモードでのログの出力機能の充実や、デバグ支援機能の充実で、Catalysｔの方が上かな、とは思う。
デバグ支援機能で驚いたのは、Catalystフレームワーク上に乗っかったうえで動作している際に、例外が発生すると、美麗なバグレポート画面が自動生成されて、主要なオブジェクトの中身が自動でダンプされる機能がついている事。
これはかなり便利。

という感じで、まだまだ使いでがありそうで楽しげなアレですが、今日のところのレポートはそんな感じです。

[composed and posted with ecto]