InflateColumnを使っているときに問題があったため、修正版を新しいエントリに起こしました。 修正版：DBIx::Class ＋ Catalyst::View::JSON（２） - ヒルズで働く@robarioの技ログ 昔書いたメモが出てきたので転載。 DBIC::ResultSet#findやDBIC::ResultSet#searchしたものをそのままJSONにしたいじゃないですか。 でもCatalyst::View::JSONにそのまま渡すとCatalystが落ちるんですよ。 なので適当に展開してくれるサブルーチンを作って使っています。 Catalyst::View::JSON以外でも使うので、アプリケーションクラスに置いています。 ### lib/MyApp.pm sub expand_dbic { my ( $c, $obj ) = @_; if ( !Scalar::U

JPA セミナーの時に jshery 氏も勧めていましたし、近頃 Geek の話題で目立つようになってきた、Catalyst を mod_perl でなく、外部 FCGI として走らせる設定方法を紹介します。 Catalyst プロセスの起動管理は DJB 氏の daemontools による管理がお勧めです。プロセスが死んでも自動的に再起動してくれます。手動での再起動も楽です。screen からショートカットキー登録して Catalyst を再起動する方法も後ほど紹介します。 Catalyst の FastCGI 起動の設定 まずは daemontools の run スクリプトです。 run #!/bin/sh exec 2>&1 exec env - \ PATH='/bin:/usr/bin:/usr/local/bin:/var/www/www.example.com/scrip

Catalyst は Web アプリケーションを開発するときに、フレームワークとしてとても便利です。 ひとつの Web サービスを作ろうとすると、以下のような様々な処理が必要になってきます。 ユーザーに見せるWeb インターフェイス アクセス集計などの日次バッチ処理 アバター画像などの生成・変換処理 ユーザー通知やメルマガ配信などのメール送信処理 これを、すべて Catalyst にやらせてしまうと、プロセスが太りすぎてしまいますし、アプリケーション設計として不自然です。 結論から先に言ってしまうと、モデルやロジックだけでなく、ヴァリデーション処理なども Catalyst から分離してしまい、Catalyst はリクエストのディスパッチと View だけを担当するのがスマートで、拡張・メンテナンス・テストがしやすいやり方なのかなと、最近うっすらと考えています。Catalyst 在りきではな

前代未聞のPerl軽量ウェブアプリケーションフレームワーク祭りの中、いかがお過ごしでしょうか？ 紆余曲折があってこんなことを言ってたわりに何もしてないでぼーっとしている間に、腕に覚えのある兵達が我も我もと手を動かしてくれたので、申し訳なさ半分で懲りずにベンチマークを取ってみました。 http://d.hatena.ne.jp/tokuhirom/20081111/1226418572 NanoA というウェブアプリケーションフレームワークをかいてみた - kazuhoのメモ置き場 YappoLogs: Yacafi という軽量CGIフレームワーク書いたよ みんな基本的に軽量なフレームワークをうたっていて、開発効率よりも軽さや配布のしやすさを売りとしているので特に問題ないと思います。 比べたのは上の3つと モジュールを使わないcgi CGI.pmでヘッダ出力をするもの 軽量フレームワークの代

NAME Catalyst::View::TT - Template View Class SYNOPSIS # use the helper to create your View myapp_create.pl view Web TT # add custom configuration in View/Web.pm __PACKAGE__->config( # any TT configuration items go here TEMPLATE_EXTENSION => '.tt', CATALYST_VAR => 'c', TIMER => 0, ENCODING => 'utf-8' # Not set by default PRE_PROCESS => 'config/main', WRAPPER => 'site/wrapper', render_die => 1, # D

話してないけど、資料はあるので公開しまっする。 Customization of DBIC::Schema::Loader 概要 開発中にスキーマに変更が発生して、make_schema_at()を何度も叩く際に困ることと、Schema::Loaderで比較的意図した通りにSchema, Tableクラスを生成する為に、こんな風にするといいおって内容です。 せっかちな人向け こんな感じ。 内容の解説はプレゼン資料を見てくだしあ。 #!/usr/bin/perl use strict; use warnings; use FindBin; use File::Spec; use lib ( File::Spec->catfile( $FindBin::Bin, qw/.. lib/ ), File::Spec->catfile( $FindBin::Bin, qw/.. schema/ )

2. Catalyst のいやんなところ component が context に依存してるー＞特に Model! MyApp::M::Foo にビジネスロジックを実装すると Catalyst でしか使えない Test が面倒くさい！ 4. 作り方 Helper がついてる script/myapp_create model Foo Adaptor Foo::Class create package MyApp::Model::Foo; use strict; use warnings; use base 'Catalyst::Model::Adaptor'; __PACKAGE__->config( class => ‘Foo::Class', constructor => ‘create', ); 1;

今回は竹迫さんのリクエストもあったのでなるべくゆっくりめに話そうと思うには思っていたのですが、結局だれだったかが「時間が長くなっても話のペースは変わらんと思う」と予言していた通りになってしまったのが申し訳ないというかなんというか。 すべては当日の朝、スライド書いている最中に 10:20 <t********> Catalyst 年表とかほしいとふとおもいますた 10:20 <t********> 2005年 sri 独裁政権時代 10:20 <t********> とか、そんな感じの。という天の声を聞いて、ちょろっとだけ差し替えるつもりが100％増量になってしまったのが敗因、ということにしておきたいと思います。 なにはともあれ資料はこちら。 http://www.tcool.org/talks/catalyst_conf1.pdf それから、今回自重したCatalystで軽量版のJifty

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

2. アジェンダ WAF における MVC と WAF と M の関係 Catalyst(WAF) から M を切り離す方法 MVC の M を構築するためのアーキテクチャ 4. WAF の役割 WAF は基本的に Web/Http の世界の仕事をする セッション管理 認証処理 URL ディスパッチャ フォームバリデーション Controller としての役割 M と V のノリとしての役割 モデルへ処理の委譲 モデルの処理結果を View にフォワード 5. WAF の役割でないこと モデルの管理 モデルのビジネスロジック モデルの Caching の機構 Etc.. Catalyst で良くない点 Catalyst::Model::* M が Catalyst に依存している Model をプラガブルに拡張するのは、 AF の役割

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

「なんでＭＶＣなんて使うの？」という牧さんの記事には全面的に賛成なわけですが、ここでCatalystを出してくるんだったらひとつDISっておかないといけないものがある。 Catalyst::Model::DBIC::SchemaとかCatalyst::Model::Jifty::DBIとか、O/Rマッパをそのままモデルにしちゃってるヤツだ。 自分でも書いておきながら何を、と思わんではないけれど、MVCのキモは、Mで起こっていること、Cで起こっていること、Vで起こっていることをそのまま相手に見せてはならない、ということ。 CatalystのCはMの要素とVの要素を併せ持たされてしまうことが多いわけですが、MVC的には、ふつうの人がC（やV）でやっていることのほとんどはMの中に戻してやらないといけない。O/RマッパはあくまでもMのなかでこっそり使うものであって（現代的にはMMVCパターンの一方

Cookbook長いので分割。 デプロイについてのレシピ。Webサーバーエンジンとアプリケーションの効率化も含む。 http://search.cpan.org/~jrockway/Catalyst-Manual-5.700701/lib/Catalyst/Manual/Cookbook.pod#Deployment mod_perl Deployment mod_perlは多くのアプリケーションに対しての最適解だけど利点と欠点を述べる。他の方法としてはFastCGIがある。 Pros Speed mod_perlはとても高速で、それぞれのApacheプロセスのメモリにアプリケーションをロードすることによって恩恵を受けられる。 Shared memory for multiple apps 同じサーバーで複数のCatalystアプリケーションをする必要がある場合、mo_perlは共通のモジ

英国放送協会(BBC)がPerl on Railsを名乗るMVCフレームワークを開発したという話が一部をにぎわしていたので、簡単なまとめ。英語で話を追える人は下記を（コメント欄含めて）順に読んでいけばOKです（これ以外にもスラッシュドット（本家）をはじめ、いくつかのソースに情報が分散していますが、必要な流れはだいたいこの三つで把握できるはず）。 http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml http://derivadow.com/2007/11/30/perl-on-rails/ http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ さて、本題。2007年11月30日に「BBCが自社フレームワークとして

何とタイムリーな記事。まつもとさんが「仕様の継承」と「実装の継承」について語っているので勝手にまとめてみる。 まつもとさんがITProに書いた記事がきっかけになったのか、最近 Mixin に関する話題をよく目にする、気がします。 Perl は多重継承をサポートする一方で、Exporter を使った Mixin も可能です。この辺はmiyagawa さんのメールマガジンのバックナンバーに詳しく書いてあります。 Object-Oriented Programming with Perl Vol.29 - Exporter による Mixin Object-Oriented Programming with Perl Vol.30 - Exporter::Lite Exporter で関数を export しつつ、それを import した側で、関数ではなくインスタンスメソッドとしてそれを利用す