タグ

mooseに関するbeth321のブックマーク (6)

  • 第19回 Who's Who on IRC:Perl界の紳士録(IRC編) | gihyo.jp

    あの人はだれ? Perlの世界でいちばんホットな話はIRCでかわされている、ということを知っていくつかのIRCチャンネルに入ってみたはいいものの、そこで話をしているのがいったいだれかわからない、という経験はだれしも一度はするもの。なかにはIRC上でのニックネームとCPAN/PAUSE ID(と名)が同じ、という人もいますが、さまざまな事情からIRCとCPANでは似ても似つかぬ名前を使っているという人も(筆者を含めて)少なくありません。 今回はそんな「だれがだれだかわからない」「⁠業界の勢力図を知りたい」という悩みや希望にお応えして、おもにIRC上のPerl関連チャンネルでよく見かける人をPAUSE IDつきで簡単に紹介してみます。人選については、筆者が入っているいくつかの英語チャンネルの過去ログから、今年特に活発に発言していた人を機械的に抽出してみました。 マップにするとこんな感じ 単純

    第19回 Who's Who on IRC:Perl界の紳士録(IRC編) | gihyo.jp
  • 第8回 Reaction:CatalystをもっとDRYに | gihyo.jp

    アプリケーションの枠組みを越えた再利用 前回は、Catalyst 5.7で登場したチェーンドアクションを利用して適切なベースコントローラをつくれば、CRUDのような定型処理は再利用できるようになる、という話をしました。これはコンテントマネジメントシステム(CMS)のように同じようなインタフェースを持つ画面が多いシステムをつくるときには特に効果的なのですが、その再利用を、ひとつのアプリケーション内だけで完結させてしまうのはもったいない話。自社でつくるアプリケーションにはどんどん使い回していきたいものですし、コピー&ペーストを避けるためには、なんらかの名前空間上にその共通コードをまとめていく必要があります。 もちろんそのコードが小さく、十分に一般化できるものなら、Catalyst、あるいはCatalystXという名前空間に入れてもかまいませんが、コントローラの部品だけでなく、モデルやビューまで

    第8回 Reaction:CatalystをもっとDRYに | gihyo.jp
  • 第7回 Catalyst::DispatchType::Chained:チェーンドアクションはむずかしい? | gihyo.jp

    モダンPerlの世界へようこそ 第7回Catalyst::DispatchType::Chained:チェーンドアクションはむずかしい? 5.7系列の目玉だったチェーンドアクション 3年前に登場したCatalyst 5.7系列で導入された機能のひとつに、チェーンドアクションと呼ばれるものがあります。これは慣れると非常に便利な機能なのですが、それまでのURLとクラスの対応を根底から覆してしまう大転換だったわりにドキュメントが不足していたため、活用の仕方がわからないという声もありました。 今回はCatalyst 5.8系列で導入された新しいツールを使いながら、このチェーンドアクションの使い方を紹介していきます。スペースの都合でCatalystの基はある程度理解しているものとして話を進めますので、わからないことがあったらCatalyst体のドキュメントやCatalyst::Manualなどを

    第7回 Catalyst::DispatchType::Chained:チェーンドアクションはむずかしい? | gihyo.jp
  • 第3回 Moose::Role:役割単位のクラス分け | gihyo.jp

    多重継承しないほうがよい場合 前回は多重継承を利用してクラスを拡張するときにありがちな問題と、そのひとつの解決策を見てきましたが、クラスにいくつかのメソッドを追加したいだけであれば、むしろ継承を利用しないほうがふさわしい場合もあります。 たとえば「コウモリ」というクラスを実装するとき、「⁠乳を出す」というメソッドのために「ほ乳類」というクラスを、「⁠空を飛ぶ」というメソッドのために「鳥類」というクラスを継承するのは――たしかにそれで当座の問題は解決するかもしれませんが――違和感が残ります。 use strict; use warnings; use Test::More tests => 4; package Mammal; sub new { bless {}, shift; } sub produce_milk { print "I can produce milk.\n"; } pa

    第3回 Moose::Role:役割単位のクラス分け | gihyo.jp
  • 第6回 Catalyst::Upgrading:検証はお早めに | gihyo.jp

    3年前の大混乱 モダンPerl界を代表するウェブアプリケーションフレームワークといわれるCatalystが2006年半ばに5.6系統から5.7系統に移行したとき、創始者のゼバスティアン・リーデル氏を追い出す形で集団管理体制に移行した開発チームが最初にしたことは、プロジェクト開始当初から使われてきたCatalystという名のディストリビューションはそのままに、Catalyst-Runtimeという新しいディストリビューションをつくることでした。 このようなディストリビューション名の変更は、CPANクライアントを使っている分には(内部でモジュール名からディストリビューション名への変換が行われるので)問題にならないのですが、外部のパッケージ管理者たちには少なからぬ負担をかけました。なにしろ突然100を越す関連パッケージの依存が変更になるのです。基的にはメタ情報だけ書き換えれば済む話とはいえ、従

    第6回 Catalyst::Upgrading:検証はお早めに | gihyo.jp
  • 第4回 Any::Moose:なにがどうでもムースはムース | gihyo.jp

    CPANTSは情報の宝庫 Perlを使う最大の利点といわれるCPANですが、CPANは単なるモジュール置き場ではありません。CPANはまたPerlの利用状況を知るうえで不可欠な統計情報を得る場でもあります。そのような統計情報のいくつかは、いわゆるCPAN検索サイトからも確認できますが、より突っ込んだ情報が欲しい場合はCPANTS(CPAN Testing Service)と呼ばれるサイトを確認するのが便利です。 国内ではnipotanこと谷口公一氏が始めた「輝け!全日最強 CPAN Author 決定選手権」のネタ元として知られていますが、このサイトでは個々の作者やモジュールの品質だけでなく、そのモジュールが実際にどこで使われているかという情報を得ることもできます。 たとえば前回取り上げたロール関連のモジュールの利用状況を調べてみると、古き良きExporterを依存モジュールとして取り上

    第4回 Any::Moose:なにがどうでもムースはムース | gihyo.jp
  • 1