エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
さくっと Perl のメトリクスを取得する
ローカルにあるやつもリモートにあるやつも、ファイルごとでもディレクトリ内まとめてでも、よしなにサクッと Perl コードのメトリクスを取得したかったので書きました。 App::plmetrics cpanm App::plmetrics App::plmetrics をインストールすると、plmetrics コマンドが使えるようになります。 Perl::Metrics::Lite に同梱されている measureperl はローカルファイルまたはディレクトリを対象に解析を行いますが、plmetrics はローカルのものだけでなく、リモートの git リポジトリや tar.gz を対象に解析することが可能です。 plmetrics モジュール名で解析。--module $ plmetrics --module Test::AllModules /usr/lib/perl5/site_perl
Plack アプリで遅延ロードされるモジュールを見る
アプリケーションで利用するモジュールは、できる限り先読み(preload)しておきたい。先読みしておけば、アプリケーション全体のメモリ消費が抑えられるし、遅延ロード(Lazy Load)のコストがなくなります。 モジュールの先読みは、例えば以下のように行います。 starman --preload-app MyApp app.psgi or starman -MFoo -MFoo::Bar -MBaz::DBI app.psgi あえて遅延ロードするという場合を除いて、先読みは行って損はないはず(小さいアプリだと、効果は小さいですお ^-^)。 Plack::Middleware::Debug::LazyLoadModules 明示的に use するモジュール群のピックアップはたやすい。なにせ明示されているから。しかし、暗黙に遅延ロードされてるモジュールやライブラリは調べてみると多く見つか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
