単体テストでxUnitを使う場合、クラスに対して1つのテストクラスを作るのが一般的です。例えば、Dogクラスがあれば、Dog::Testというクラスを作り、Dogの振る舞いに対してテストを書きます。クラスの振る舞いごとに、テストメソッドを書いていきます。テスト…

プラグインの仕組みを少し考えてみます。フックポイントにPluginの処理を差し込んで、フレームワーク側の処理に手を加えるものは、いわゆる世間一般にプラグインと言われているものなんじゃないかと思います。これはMooseのRoleのmethod modifireは相性はよ…

今回の一連のプラグインの話を見ていても、作る側の視点と使う側の視点で、大分話の視点が違っているのが印象的です。利用者視点だと、 副作用があっても、副作用のないものを作ってから使うなんてことはそもそもしたくない 副作用があっても、多くのプラグ…

Catalyst::Plugin::* になにを置いていいのか、というのがわかりにくかったというのはある。今は方針があきらかになってるからいいけど。View にたいするプラグインも、Controller にたいするプラグインも、Request も Engine も Context も。ぜんぶ Catalys…

Controllerの拡張の現状のベストプラクティスということで、 http://search.cpan.org/src/JCAMACHO/Catalyst-Controller-FormBuilder-0.04/lib/Catalyst/Controller/FormBuilder.pm があるよ！というのをcharsbarさんに教えてもらいました。 メソッドバッテ…

YAMLのconfigのほうが好きだから、ちと残念だなぁ。YAMLはデータ構造を書くのに向いてると思うし、可読性も高いと思う。設定ファイルやfixturesのようなシンプルなデータ構造を表現するのには、YAMLのほうがいいと思うんだけどなぁ。space sensitiveな問題っ…

テストを意味ある単位でグルーピングするのとテストケースを管理しやすい テストで必要になりやすいテストの前準備と後処理の機構がデフォルトで組み込まれている(setup/tearDown) という点で、xUnit系のTest::Classは気に入っています。テストである意図を…

catalystグループにも以前書いたのだけれど、Catalystプラグイン使うな！じゃなくて、以下の条件を満たすとき以外は使うなっていう話なんだと思うんだなぁ。そういう側面を強調してみるのはどうだろう。http://search.cpan.org/dist/Catalyst-Manual/lib/Cat…

Catalystのinternalな処理をフックさせて処理させるには、MooseのRoleは最適だと思うなぁ。フックして処理実行するほか、フックポイント対して登録する処理の実行タイミングを細かく調整できるから。Request Lifecycleにフックするタイプのものは、MooseのRo…

Controllerレベルで共通化したいものもあるはずで、そうしたときにもMooseのRoleは役に立つかもしれない。この場合は、method modifierではなくて、Rubyのmodule likeにMixin用途で使われるようになる。従来Controllerレベルで共有されていたものも、Control…

#!/usr/bin/env perl use strict; use warnings; use Moose::Autobox; use Perl6::Say; my $a = [ '1993,Richard E. Stearns', '1994,Edward Feigenbaum', '1991,Robin Milner', '1990,Fernando J. Corbato', '1996,Ami…

日記に書いた内容をまとめるためのコストを極力減らすために、グループに移行したという理由があります。ブログのようなフロー情報を効率的にストック情報にするための方法を、はてなグループを使って試してみようと思っています。そのためにはてなの本体の…