自分の最近のCatalystのモデル部分の書き方 こちらのブログでなんか呼ばれた気がしたのでとりあえず書いてみた。 あくまで自分はどうしてるか、って話ですが、最近はCatalystでなんか書くときはこんな感じで使ってます。 色んな事がこの図に詰まっているので、箇条書きしてみる： Model::APIがAPIオブジェクトを作成して、使用時にはModel::APIに対して`find()`というメソッドを使って実際のAPIオブジェクトを持ってくるSchema等はMyApp::Schemaに定義し、Model::APIのアトリビュートとして持っている。cacheも同等。これらの初期化引数は設定ファイルのModel::APIから取れるようにしておくCatalyst::Model::DBIC::Schemaは＊使ってない＊Model::APIではACCEPT_CONTEXTが呼ばれた時点で、もしまだ初
UML::Class::Simple ってモジュールがあります。このモジュールを使うと既存のプログラムを解析してクラス図を作成することができます。業務で仕様書を書く必要がでた場合、もしくは Catalyst のようなフレームワークをより深く知りたくなったときなどに大いに役立つモジュールです。 http://search.cpan.org/~agent/UML-Class-Simple/lib/UML/Class/Simple.pm UML::Class::Simple is a Perl CPAN module that generates UML class diagrams (PNG format, GIF format, XMI format, or dot source) automatically from Perl 5 source or Perl 5 runtime. Per
The document discusses extending modern Catalyst applications. It covers several ways to extend applications including using plugins, roles, helper methods, and extending the base controller. It also discusses extending controllers using roles, MooseX::MethodAttributes, and action classes. The document provides examples of extending applications and controllers with Moose. It covers additional top
新しく作った開発プロセスの問題点が見えたわけだから、それはそれとして改善すればいいのに。プロジェクトに併せてテーラリングされてないのとか。そういうことを自発的にやれる人たちが必要だというのもわかるけど ■ [catalyst][perl] 最近の Catalyst の構成 最近 Catalyst のエントリをよく見かけるので自分の構成をさらしてみます。コードは CodeRepos にあります。 share - Revision 30441: /lang/perl/Chaostr/trunk 元々は、作ろうとしたアプリがあったんですが、去年の Catalyst confernce 以降、MyApp 的実験場になってます。仕事で作ったものはさらせないので、構成だけ表に出す感じ。ちなみに今のところ Catalyst 5.7 系でしか使ってないです。 あと、Controller クラスのベースで
Web Application Framework Description Ark は perl で書かれたウェブアプリケーションフレームワーク（WAF）です。 Ark はおなじく perl 製のフレームワークである Catalyst を参考に開発されており、その多くの特徴はそのまま引き継いでいます。 そのため Catalyst の経験のある開発者であればすぐに使い始めることができるでしょう。 Catalyst とのいちばんの違いは、Catalyst は実用的に運用するためには基本的に mod_perl や FastCGI など永続的なプロセス実行環境を要求するのに対し、 Ark は CGI でも実用的に動作するという点を重視して開発されています。 もちろん mod_perl/FastCGI でも動作します。 より詳しい説明はドキュメントを参照ください。 Download 現在の最新バージ
はじめまして。面白法人カヤックの村瀬と申します。ArkというWebアプリケーション作成用のフレームワークを開発しました。今回から4回にわたって、このリリースしたばかりの「Ark」について紹介させていただきます。 Ark（アーク）とは Arkは、Perlで作られたWebアプリケーションフレームワーク（WAF）です。 Arkの特徴としては Catalystに似たインターフェース CGI／FCGI／mod_perlなどさまざまな環境で実用的に動作する CGI用モードの存在 日本製であり、日本語ドキュメントが充実している などが挙げられます。 Catalystに似たインターフェース Catalystは、Arkと同様にPerl製のWebアプリケーションフレームワークで、現在、Perlのフレームワークでは標準となりつつあるものです。 Arkは開発動機の1つが「CGIでも実用的に動作するCatalyst
Catalyst は Web アプリケーションを開発するときに、フレームワークとしてとても便利です。 ひとつの Web サービスを作ろうとすると、以下のような様々な処理が必要になってきます。 ユーザーに見せるWeb インターフェイス アクセス集計などの日次バッチ処理 アバター画像などの生成・変換処理 ユーザー通知やメルマガ配信などのメール送信処理 これを、すべて Catalyst にやらせてしまうと、プロセスが太りすぎてしまいますし、アプリケーション設計として不自然です。 結論から先に言ってしまうと、モデルやロジックだけでなく、ヴァリデーション処理なども Catalyst から分離してしまい、Catalyst はリクエストのディスパッチと View だけを担当するのがスマートで、拡張・メンテナンス・テストがしやすいやり方なのかなと、最近うっすらと考えています。Catalyst 在りきではな
モダンPerlの世界へようこそ 第7回Catalyst::DispatchType::Chained：チェーンドアクションはむずかしい？ 5.7系列の目玉だったチェーンドアクション 3年前に登場したCatalyst 5.7系列で導入された機能のひとつに、チェーンドアクションと呼ばれるものがあります。これは慣れると非常に便利な機能なのですが、それまでのURLとクラスの対応を根底から覆してしまう大転換だったわりにドキュメントが不足していたため、活用の仕方がわからないという声もありました。 今回はCatalyst 5.8系列で導入された新しいツールを使いながら、このチェーンドアクションの使い方を紹介していきます。スペースの都合でCatalystの基本はある程度理解しているものとして話を進めますので、わからないことがあったらCatalyst本体のドキュメントやCatalyst::Manualなどを
Catalystのstashをグローバル変数的に使うのは - Charsbar::Note ビューのテンプレート設定とかもそう。古くさいC::V::TTではstash経由でテンプレを渡しているけど、新しいC::V::Templated ベースのものはstashなんぞ通さず、$c->view(...)->template('template')のような形で直接指定できるようになっている。 これはいいですね。 jrockwayがC::M::Adaptorに続き、Viewまで汎用化してくれました。 で、C::V::Templatedとstashの関係ですが、ちらっとソースを見てみるとtemplateメソッドでテンプレートを渡すようになったけどstashを使ってないわけではないんですね。 templateメソッドの実装を見ると $self->context->stash($self->_ident
基本的に古い時代の名残なんじゃあるまいか。 stash は local なグローバル変数として利用されているとおもうのですが、あれはあんまりよくないんじゃないかなーと感じている。 stash じゃなくて各オブジェクトに明示的に渡した方が幸せだとおもう。 http://d.hatena.ne.jp/tokuhirom/20080608/1212897923 たとえば、Catalyst本で使いまくっていたら先日「使うな危険」とラベリングされてjrockway涙目のC::C::BindLex。これはstashの中身はすべて（場合によっては複数のものを連続して／切り替えて使う）ビューの出力に使うデータである、という前提があるから成り立っている。 ビューのテンプレート設定とかもそう。古くさいC::V::TTではstash経由でテンプレを渡しているけど、新しいC::V::Templatedベースのもの
3年前の大混乱 モダンPerl界を代表するウェブアプリケーションフレームワークといわれるCatalystが2006年半ばに5.6系統から5.7系統に移行したとき、創始者のゼバスティアン・リーデル氏を追い出す形で集団管理体制に移行した開発チームが最初にしたことは、プロジェクト開始当初から使われてきたCatalystという名のディストリビューションはそのままに、Catalyst-Runtimeという新しいディストリビューションをつくることでした。 このようなディストリビューション名の変更は、CPANクライアントを使っている分には（内部でモジュール名からディストリビューション名への変換が行われるので）問題にならないのですが、外部のパッケージ管理者たちには少なからぬ負担をかけました。なにしろ突然100を越す関連パッケージの依存が変更になるのです。基本的にはメタ情報だけ書き換えれば済む話とはいえ、従
JPA セミナー #1 「Catalyst フレームワークを120% 使う／Perl開発最新ベストプラクティス（予定）」 内容 未定 （Catalyst, Moose, ウェブアプリケーション ベストプラクティスの予定） 講師 Jay Shirley氏 海外で近代的なPerlでのシステム構築技術の普及に努める Enlightened Perl Organisation (EPO) のコアメンバーであるJay Shirley氏はDBIx::ClassやCatalyst 等のフレームワークを使ったスケーラブルかつ堅牢なシステムの構築を日々行っている、世界でも屈指のPerl系 エンジニアです。 EPO EPOはレガシーなPerlではなく、現在現場で実際にアプリケーション開発に使われているPerl、そして最先端のベストプラクティス等の教育を通してPerl 技術を理解してもらうための団体です。 会場
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
JPAサイト構築中 結局ユーザー管理だとか、お金を振り込む事だとか、なんか色々やらざるを得ないと言うことから、自分で書いたほうが速いという決断でJPA用のサイトを一からCatalystで書いてます。 今回はこれをgithubで晒しているわけですが、今ふと思ったのは、普段から我々PerlプログラマはCPANでいろんなCatalystのプラグインだとかを見ていたり、もしくはあちこちで細かいティップスみたいなものを聞きかじってるわけだけど、ひょっとすると俺たちほとんど他人のCatalystアプリケーションって見たことない？ よくよく考えたら自分でさえも2，3回しかなかった。もちろん、社内のものは除く。完全に外部の奴ね。MojoMojoみたいな完全にできあがってるアプリケーションってなかなか外に出てこないし、そもそも一回作ってそのままインスコしておしまい、みたいなの多いもんな。 まぁそんな事を踏ま
Catalystがモダンかどうかは置いておいてCatalystのコンポーネントを書く時のお作法として 大昔は ... use base qw(Catalyst::Action); use NEXT; sub execute { my $self = shift; $self->NEXT::execute( @_ ); ... ちょっと前は ... use base qw(Catalyst::Action); use Class::C3; sub execute { my $self = shift; $self->next::method( @_ ); ... モダンなのは ... use base qw(Catalyst::Action); use MRO::Compat; sub execute { my $self = shift; $self->next::method( @_ )
MojoとHTTP::Engine ここまでMojoとそのサンプルフレームワークであるMojoliciousについて見てきましたが、国内でもYappoこと大沢和宏さんとtokuhiromこと松野徳大さんが中心となって、HTTP::Engineという同じような趣旨のフレームワークが開発されていることをご存知の方も多いと思います。今回はそのHTTP::EngineとMojoを比較しながら、Mojoの歴史や展望を見ていきましょう。 HTTP::Engineの誕生 HTTP::Engineも、もとをただせばMojoの作者ゼバスティアン・リーデル（Sebastian Riedel）氏が4年ほど前にリリースしたCatalystというフレームワークから派生したものです。だから、Mojoとは義理のおじ、あるいは いとこ・はとこ くらいの関係になるでしょうか。 CatalystもCPANモジュールをつなぐ「
下のやつをModule::Setup::Flavor::CatalystStarterとしてcodereposにコミットしました。 module-setup --init --flavor-class=CatalystStarter catalystすると~/.module-setup/flavors/catalystにflavorがインストールされます。 module-setup MyApp catalystとすればcatalyst.pl MyAppと同じことをしてくれます。 で、これの何がうれしいかというと、~/.module-setup/flavors/catalyst/以下をいじくればオレオレcatstarterが作れるってことです。 ディレクトリ構造がそのままなので視覚的にいじれるのでわかりやすい。 で、保存しておきたくなったら module-setup --pack MyCat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
