今更Mooseの話題かよ、と思われることでしょうが、自分は常に流行の３年遅れぐらいを全力で追いかけるタイプなので、自分にとっては今が旬。というわけで、Moose的なはなしを書きます。 突然ですが、現役バリバリのperl使いのみなさんに質問です。 POEやらAnyEventやらでちょっとしたアプリケーションサーバを書く場合、みなさんはどうやって「デーモン化」してますか？ 自分はもう何回もこの手のものを書いてきたつもりですが、実は未だにベストな手法を編み出せてません。。。 App::DaemonやDaemon::Genericあたりでなんとなく自分流な形を模索した時期もありましたが、結局どれも面倒くさくなって、最近では「もう nohup perl hoge_server.pl & でいいじゃん」みたいな。「止める時は pkill -f hoge_server でいいじゃん、文句アッカ」みたいな
久しぶりのPerlネタです。新年早々のPerl関連ブログで面白かったのは、Mooseのオリジナル作者であるStevan Little氏の"The Moose Ecosystem"でした。この私訳を以下に載せておきますが、読んでいただければ分かる通り、MooseもしくはモダンPerl万歳な風潮に対して、これまたPerl界で著名なbrian d foy氏が釘を刺したことに端を発します。 私は正直言って、Stevan氏、brian氏両方は全く問題がなくて、問題なのは混乱している人々だと思います。確かに初期のMooseはドキュメントも乏しく、理解するのは簡単でありませんでしたが、今日Dave Rolsky氏の書いたドキュメントを始め至れり尽くせりなのにもかかわらず、混乱する事自体がおかしいと思うのです。Moose系のどれを選べばいいのか、って? お好きなものをどうぞ。そもそもPerlをやろうと思っ
ずっとやろうと思っていてやっていなかったMooseX::NonMoose の Mouse版をようやく書き上げました。なかなか完成しなかったのは、いい名前が思いつかなかったのと、Mouse本体に組み込めるかどうかの検討をしたかったからです。検討の結果、Mouse本体に組み込むのは無理があるという結論に達したため、モジュールとしてリリースすることにしました。 http://search.cpan.org/dist/MouseX-Foreign/ http://github.com/gfx/p5-MouseX-Foreign 以下のようにすることで、Mooseクラスを含む任意のクラスを継承できます。ただし、ハッシュリファレンスベースのオブジェクトでなければならないのと、複数の「foreign class」を親に持つことができないという制限はありますが。 #!perl package MyDate
Mooseを使うべきでない理由とMooseを使う理由 twitterにでも書いて終りにしようと思ったけど140文字じゃ無理なんで。 Mooseの欠点やら利点やらMouseがどうだとかは今更感過ぎて割愛するし、下手な抽象的な表現も面倒なんでしない。 あなたが、再利用性の高いライブラリを作りたい場合はMooseを使うべきではない。 なぜならMooseはフレームワークだからであるからだ。 たとえ有用な再利用性の高いライブラリを作ったとしても、Mooseというフレームワークに依存してしまっては、あなたの有用なライブラリを選択してもらえない事もあるだろう。 誰かが小さいスクリプトを書くために、あなたが書いた有用なライブラリを使う事で楽が出来るとする、だがMooseというフレームワークに依存したばっかりに、その有用なライブラリの後ろに控えるものの大きさに臆して選択してくれないかもしれない。 もちろんM
I have released Mouse 0.42 "Mouse::XS". http://search.cpan.org/dist/Mouse/ From this version, Mouse generates constructors, destructors, and accessors in XS. These generated mehtods are much faster than pure Perl methods, especially in attributes with type constraints. How fast is it? Accoding to a benchmark for HTTP::Engine, Mouse::XS is about 100% faster than Mouse::PurePerl in command line appl
Moose/Class::MOP開発スポンサー (JPA Sponsors Moose/Class::MOP Work)の報告です。 まずは現状ですが，Moose 0.90/Class::MOP 0.93のロード時間が約176msであるのに対し，ベースラインとしたMoose 0.88/Class::MOP 0.89のロード時間が約209msであるので，約18%高速になっています。当初の目的が20%以上であるので，目標値には達しなかったことになります。しかし，現状では作成中のブランチすべてが取り込まれたわけではないため，ゆくゆくはさらに高速になる見込みです。 今回行った高速化に大きく寄与したのは次の二点です。 ボトルネックであったget_method_map()をできるだけ使わないようにした(C::MOP) C::MOPが生成するコードの一部を手で展開し，実行時evalを減らした(C::MO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く