JPA セミナー #1 (Session 2 Catalyst 改)
1. Plugin
プラグインの使用を控える
- 間違った使用方法、実装方法で定義されていることが多い
本当に使わない方向で
Catalyst::Plugin::Authentication はどうなの？
2. デバッギング
perl 5.10's "Unknown Error"
?dump_info=1
テストを書く
- Test::WWW::Mechanize::Catalyst で自動テストが大変書きやすくなる
- Controller のバグ早期発見につながる
3. 設定
config()
package MyApp::Controller::Foo; __PACKAGE__->config( 'foo' => 'bar' );
- どのコンポーネントも設定用の config アクセサが実装されているが、原則初期化終了前にする
- 初期化終了後で変更すると予想困難なバグの発生につながる
- 先行順位を高く設定するには、アプリケーションレベルで設定する
MyApp->config->( 'Controller::Foo' => { 'foo' => 'bar' } );
has 'foo' => ( is => 'rw', isa => 'Str', );
- 以前までの Class::Accessor::Fast 方式であれば以下のように
__PACKAGE__->mk_accessors('foo');
$self を使う
- アクセサを作らないのであれば $self 内でマージされている値を参照することも可能
$self->{'foo'}
これは止めましょう
package Controller::Foo; __PACKAGE__->config('foo' => 'bar'); sub method : Local { my ($self, $c) = @_; $c->config->{'Controller::Foo'}->{'foo'}; }
- 大抵のケースで多分正常に動くが、確実ではない
- この場合は、 $self->{'foo'} で取り出すのが正しい
package Controller::Foo; __PACKAGE__->config('foo' => 'bar'); sub COMPONENT { my ($self, $c, $config) = @_; $config->{'foo'}; # NO! }
- 先ほどの例はなんとなく動くが、こちらは多分動かない
常に $self を使おう
- コンポーネント範囲の設定は $self を利用するのが理想
- アプリケーションレベルの設定は $c->config から呼び出しても良いが、それも本当にアプリケーション全般に渡って必要な設定に限って使用したほうがよい
Config は使い過ぎでちょうど良い
4. コントローラー
より良いコントローラー
- 薄ければ薄いほど良い
- ベースクラスを利用して薄いコントローラーを実装する
ベースクラス
- 多くのコントローラーは機能ごとに大まかに分類することが出来る
- 大半は設定から動作をカスタマイズできるように実装することが可能
- 先ほどの設定の適用方法の延長で、ベースコントローラーから機能を継承しつつ、Model に最大限の機能を委譲することによって、ほとんど空の Controller を実装していくことが可能
5. Chained
基本的な考え方
実際に使用されるケース
- auto アクションは各コンポーネントで1回ずつ実行されるが、Chained の場合、経路で繋げた全てのアクションで実行することが可能
- Chained に切り替えてから一回も auto を使ったことが無い
- 実際の Chained の使い方は github にあるサンプルで
- http://github.com/jshirley/ (catalyst-example-chained)
6. デプロイ方式
External FastCGI
HTTP::Prefork
- C関数にできるだけのことを割り当てているため軽くて安定
- だが今のところ高負荷もしくは認知度があるサイトでの事例は無い
- unix ソケットの裏技は使えない
- ポートを分けることによる分散などでダウンタイムを最低限に抑えることはできる
7. ログ
8. Action('Classes')
Catalyst 5.7 でアクションクラスとして実装されているものは 5.8 では遥かに便利な Role として再実装されている
Catalyst::Controller::ActionRole
- ActionClass の概念を Role と入れ替えることができる
- Role とは、「あるオブジェクトの特徴・動作を表現する」ためのものなので Catalyst の Action を Role で実装するのは自然なこと
sub action : Does('moo')
- Role の概念をまだ理解してなかったり、使ったことがなければとりあえず今は無視
- 気になったら Moose::Role を参照のこと
ActionClass は Action の動作内容を Catalyst 外のメソッドにラップすることができる
使い時
- meta と思われる副アクションが本アクション以外に実行する必要のある時に有効
- 実装例は、アクセスされたページのプロパティを抜き出してスタッシュに保存するなど
- これは Model でも実装できるが、Action の Role を実装すると構文がすっきりしつつ、リクエストディスパッチにカスタムロジックを注入できるようになる
9. local::lib
Vendor Perl = Not Good
Makefile.PL を使う
- 管理をきちんとすれば、依存関係のあるモジュール類のインストールやエンドユーザー環境での動作も簡単に保障できる
- local::lib と一緒に使えばインストールされたパッケージが実際にアプリケーションが使っているパッケージだということも保障できる
- 複数ユーザーのシステムで同じアプリケーションを複数バージョン運用することも可能
アプリケーション権限はユーザー権限で
- 極力 root で実行しない
- 依存関係も root を必要とするべきではない
- External FastCGI を local::lib でデプロイすれば、サーバー設定以外のアプリケーションのデプロイと実行は root 権限が全くなくても行うことが可能
10. 参加
Catalyst に貢献するには
- 簡単
- 大半は技術力が必要というわけではない
- ドキュメントの提供
- テスト
- ブログ、宣伝活動
JPA セミナー #1 (Session 1 Better Perl Practices 最新 Perl 開発手法のススメ)
自己紹介
- Jay Shirley
- IRC に常駐 irc.perl.org (jshirley)
- http://search.cpan.org/~jshirley/
- http://github.com/jshirley/
ベストではなくベターを目指す
- どれだけやっても不満は残るもの
- 最初からうまくやらなくてもいい徐々に上を目指そう
- 失敗したらよく考え次は成功させる
設計
- ゴールをはっきりと
- 背伸びはしないさせない
リファクタリング
- 避けられない運命
- やるからには意義のあるものに
- 失敗から学ぶ
大事なこと
- 設計、テスト、リファクタリング
- 習慣にする
習慣にするには
- 大変だと思わせない
- 正しいことはしやすく
- 間違ったことはしづらく
テスト
- Test::Class
- Email::Send::Test
- Test::WWW::Mechanize
設計の仕方
- まずは動くものを作る
- 大まかな使い方を考える
- ひとつひとつゴール（メソッド）を設定する
ベターアプリのために
- ソフトの出来はツール次第
- 車輪の再発明はやめよう
ベター Perl
シンプルだけど
my $foo = $request->param->{foo}; my $bar = $request->param->{bar};
良いコードはタイプ数が少し増える
my $data = $request->params; my $foo = $data->{foo}; my $bar = $data->{bar};
タイプしなければいいってものでもない
my $s = ($api ? $api->params : $request->params) || $request->params; ${"__PACKAGE__::$_"} = ($s->{$_}) for keys %$s;
コードの短さを競うゲームではない
use strict; use warnings;
Test::Class
- テストモジュールとしてはベスト
- chromatic や Ovid もこれについて書いている http://modenperlbooks.com/
Test::Class の理由
- パッケージベース
- Test::名前空間 にテストコードをまとめられる
- .t ファイルより柔軟に書ける（コードの再利用）
- テストの設定もし易くなる
ベースクラスを利用する
- 共通の機能をまとめる
- 変更もかんたん
- Perl のいいところ（多重継承をサポート）
- それぞれのクラスでどこが同じでどこが違うか考え構築する
少ない手数でより多くのことを
- コードをより良く
- 手数は少なく
- その後は use Moose
Moose でハードコードを減らす
- 考えられる全てを設定可能に
- やり方はすぐに分かるようになる
- やればやるほど楽になる
- MooseX::SimpleConfig
お気に入り
with 'MooseX::SimpleConfig'; with 'MooseX::Getopt'; has +configfile => ( default => ( grep { defined $_ and -f $_ } @places_to_loook )[0] || "" );
複数パスから設定ファイルを抽出し、その中からオブジェクトに has() などで指定した要素を初期化してくれる
まとめ
- 書くコードを減らす（ベースクラス）
- 大事なところはテストする
- Moose（書くコードを減らす）
- 設定で動作変更可能に
遅い？
- Moose は別に遅くない
- 他のモジュールと比べて遅いだけ
- しかもほとんどは起動時の問題
- 線形スケーラビリティ（かかる時間は一定）
- 遅いと思ったらハードウェアを追加
少しずつ拡張していけば良い
- 必要なところだけ使えば良い
- 時期が来たらリファクタリング
- 斬新的開発
すぐに使いたいなら
- 型チェック
- 'ArrayRef[MyObject]' なんてことも可能
注意
- そのうちなんでもロールに見えてくるようになる
- それが普通
- でも誘惑にまけないように
- それでも必要だと思ったらロールに
JPA セミナー #1 (代表理事挨拶)
活動内容
補足
研修の料金やコース詳細については、以下に詳しく載っています。
http://japan.perlassociation.org/jpa/service/training
JPA セミナー #1 参加報告まとめ
昨日、4/21 秋葉原 UDX で JPA の第一回セミナーがあったので参加してきました。
同時翻訳の受信機が先着40名だったので、心配だったのですが、翻訳したスライドが用意されていたので大分助かりました。
スライドの翻訳だけではなく、プリントアウトされたものも配布していただいたので、会場が広いのもあったので、視力があまり良くない自分としては大分助かりました。
フリースポットもあったので、講演を聴きながら CPAN にアクセスできたりするのも良かったです。
講演終了後、個人的に牧さんに質問させていただきましたが、とても親切に回答してくださいました。牧さんありがとうございます。
各セッション毎にエントリ分けてまとめましたので、ブックマークする方は、今日の日付でブックマークすると良いと思います。
代表理事挨拶
1部 Better Perl Practices 最新 Perl 開発手法のススメ
2部 Catalyst 改
JPA では会員だけでなく、ボランティアも募集しているようなので、Perl コミュニティに貢献するべく、活動に参加して行きたいと思いました。技術的なことでなくとも、手伝えることは色々あるそうなので安心しました。とりあえず、個人会員・ボランティアから初めたいと思います。
