稼働中サーバのサービスの状態を監視するためのプラガブルフレームワークGarudaというのを作ったので、codereposに置いておきました。 Plaggerとか、mizzyさんのAssurerみたいなやつです。というか最初はそのAssurerを使う予定だったんですが、自分とこの環境に合わない部分を改造してるうちに、最初から作ってみたくなったんです。 とはいいつつ、かなりの部分をAssureから頂いたり参考にさせてもらっています。Garudaって名前も、Assurer(阿修羅)と同じく八部衆の迦楼羅からとりました。迦楼羅って鳥らしいんで、サーバ間飛び回ってる感じで意味的にもいいかなぁと。 プラグインアーキテクチャに関してはClass::Componentをベースにしたので、さほど考える必要はなかったんですが、仕様とか設計で結構悩んで、思ったより時間かかっちゃいましたね。経験値の足りなさを痛感
Perlで特異メソッドでは「標準モジュールにも特異メソッドを実現するものはない」と書いたが,そういえばPerl 5.10.0から標準モジュールになったObject::Accessorというものがあることを思い出した。これは直接特異メソッドを定義するのではないが,振る舞いとしては特異メソッドそのものである。実際,Class::Monadicもadd_field()というアクセサを作成する機能を提供している。 Object::AccessorのSYNOPSISより: ### using the object as base class package My::Class; use base 'Object::Accessor'; $obj = My::Class->new; # create base object $bool = $obj->mk_accessors('foo'); # cr
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
微妙に Moose とは異なるのでメモ MyApp::Roleクラスが必須になる Moosenize された時に MyApp::Role クラスに requires with after before などの必須メソッドをエクスポートする import メソッドを突っ込む。 そして、 MyApp::Plugin の register メソッドを拡張して、この register フェーズで requireses のチェックやら Role で定義された after, before の install などを行う。 Class::Component の Plugin は register メソッドが、初期化フェーズにあたるので、ここで全部やっちゃう。 ただし、同じ名前のPluginでもloadされた数だけ register 呼ばれるので、最初の一回だけ初期化する。 Role 作る時のルールとして
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
HTTP::Engine - Perl版 WSGI のような物、 Catalyst::Engine を抜き出したような物 先週のCatalystConでHTTP::Server::Wrapperというのを発表したのですが、やっぱり名前長いしわかりにくいよねということで、HTTP::Engineという名前でやり直して CPAN に上げました。 http://search.cpan.org/dist/HTTP-Engine/ 実は Catalyst の svn repos に HTTP-Engine のディレクトリ掘ってある事は知っていたんだけども、4ヶ月くらい前に作ってからそれっきりっぽいので、DISられ覚悟でうpたわけです。 簡単に説明すると、mod_perlやfastcgiやHTTP::Server::SimpleやPOEやCGIなど様々なWebエンジンを透過的に扱って簡単にフレームワー
エンジニアにとって仲間とはどういう存在なのだろうか。極端なことをいえば、自分1人で作業が完結できてしまうエンジニアにとって、仲間とのコミュニケーションにはどんな意味があるのか。エンジニア同士のネットワークを通じて、エンジニアにとっての仲間とは何かを探る。 |1 2|次のページ 前回「コミュニティは『知り合い系』から『出会い系』へ変化する」で登場していただいた竹迫良範氏からの紹介で、今回はモバイルファクトリー システム開発部 松野徳大氏に話を聞いた。Perlコミュニティをはじめ、さまざまなコミュニティに参加し、エンジニア仲間とつながっている松野氏にとって、エンジニア仲間とはどういう存在なのだろうか。 ■ブログでは怖い存在? 紹介者である竹迫氏から松野氏への伝言を預かっているので、まずはそこから。 「ブログでは怖いと思われているけど、実際社内ではどうなんでしょうか」 その問いに松野氏は笑みを浮
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた HTTP::MobileAttributeの最適化祭りに突発的に参加してみた。 正直言うと未だにHTTP::MobileAttributeの中身であるClass::Componentを分かってない。なのでできることも限られてるわけだが。 今回のミニ祭りを見ていてよくわかるのは結局のところスピードに最も影響があるのは端的なコードの書き方ではなく構造(ストラクチャ)を見直す事であるというだ。id:tokuhiromのところでパフォーマンスチューニングの結果を追ってる人はわかると思うけど、結局俺が参加したのはもう本当にコードの書き方をチューニングするというレベルのところで、例えばループをアンロールしてif/elseで実装してみるとかね。でもそこはどんなにがんばっても数%のパフォーマンスゲインにしかならない。
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
もしかして、MyClass::Plugin::FooBar というプラグインを汎用化しようと思ったら、Class::Component::Plugin::FooBar て名前にしなきゃアカンのかな。。。 なんとなくDBIx::Simpleとかプラグインにしておこうかと思ったから、気になっただけなんだけど。 たとえば、こんな感じ? package Class::Component::Plugin::DBIS; use strict; use warnings; use base 'Class::Component::Plugin'; use DBIx::Simple; use SQL::Abstract; sub dbis_connect : Method { my($self, $c, $args) = @_; my $DBIS = DBIx::Simple->connect( @{$se
プラグインだけで構成するもん これってもうCPANにあるのかな。 Plaggerみたいにプラグインで構成するライブラリが欲しいんだけど、別にアグレゲーターしたいわけじゃなくて、全然違う用途に使いたいのです。しかも、フックポイントをアプリケーション毎に変えたいから、それさえも設定ファイルに入れたいわけ。 で、ないのかと思って書いてみた。 もしよかったらコメントしてください。同等のモジュールを見落としてるだけという可能性もあるのでそれPla的なコメントでもいいので。 =head1 NAME Plugal - Generic Plugin Execution Framework =head1 SYNOPSIS use Plugal; Plugal->bootstrap('config.yaml'); Plugal->run; =head1 DESCRIPTION Plugal is a simp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く