エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
perl5.22 おれの注目 features(changes)
perl5.22 が登場したということで一通り Changes 読んでみた上で気になった点を列挙しておく。 キャプチャしない正規表現オプション n Non-Capturing Regular Expression Flag 正規表現に n オプションというのが加わったようだ。これまでは (?:nocapture) というように ?: を使っていたのが、/(nocapture)/n という風に n オプションで明示できる。これで ?: だか :? だか迷う必要がなくなった！ Unicode 7.0 対応 Unicode 7.0 is supported ロシア通貨のルーブルの通貨記号文字が使えるってことですね！ 無限大や数値ではない引数を渡すと、死ぬ Packing infinity or not-a-number into a character is now fatal chr("foo
git リポジトリからプロジェクトの概要をつかむ
もうすぐ春ですね。この時季は異動したり転職したりで新しいプロジェクトにジョインする人が多いのではないでしょうか。 さて、そんな新しいプロジェクトにジョインしたとき、プロジェクトの状況を git リポジトリからざっと見てみようというのが今日のテーマです。 よくマージしてる人ランキング マージしてる人とレビュアーは同じことが多い。つまりコードをよく知る人がこれでわかる(マージも自分でやるプロジェクトだとそうではないだろうけど)。 $ git log --merges --format="%cn" | sort | uniq -c | sort -r | head コミッタごとのコミット数ランキング 誰がよくコード書いてるかがわかる。もしくは、こいつ他人のコード削除してばっかだなとか。 add/delete 合計コミット $ git shortlog -sn コミッタごと add/delete
PerlCasual #6 で正面衝突してきました
YAPC の前くらいに @yusukebe さんに PerlCasual もまたやりたいよねーという話をしてて、YAPC 終わったらすぐやるかーって言ってたんだけど、なんだかんだ間を開けてやることになってついに昨日 開催の運びとなりました。 @xaicron の基調講演は後半意外な展開でイイ話になって泣けたし、@Niratama さんのラーメングラフの話もとっても面白かった。 と言いつつ自分も LT でベンチマークについて話したんだけど、これが @kfly8 さんとネタ丸被りで、本当に失礼しました。まあ、こんなこともありますよね！！ もう最初 @kfly8 さんが話し始めたとき、自分でも何が起きてるのかよくわかりませんでした(汗 というわけで、僕の資料はこちらです。 Benchmark Casual ベンチマークってもっとみんなカジュアルに取りまくってるかと思ったんですけど、そんなでもない
Perl を学ぶとき、真っ先に覚えたいモジュール
春ですね！ 新年度ですね！ Perl 書くことになってしまいましたか！ 奇遇ですね！ sigil が意味わかりませんか！ 特殊変数がググれませんか！ リファレンスが謎ですか！ 1; の存在が不明ですか！ オブジェクト指向が難しいですか！ むしろオブジェクトじゃないコードの方がゆるくて大変ですか！ XS が読めませんか！ ええ、XS は僕もあんまり読めません＞＜ さて、この春から Perl を学ぶことになった人も多いかと思いますが、なにはなくともこれまず覚えたら後が楽になるんじゃないかというモジュールを、いくつか紹介したいと思います！ (まあ、自分の初期を思い返すと、この辺はやく知っておきたかったなあというリストです) Data::Dumper, YAML 変数(リファレンス)やオブジェクト(blessされたリファレンス)をダンプする用途では、Data::Dumper が一番メジャーのような
リストを任意件数ごとにぬるぬる処理する用のモジュール書いた
なんらかのリストの要素、要素に処理をするなんて場面よくありますよね。んで、そんなとき、リストが長大で 1 件ずつやってたら埒が明かなくて、適当な件数ごとに分割してぬるぬるしないとやってられない、みたいな深遠な事情もありがちですよね。 さて、まあ、そんなのを、毎度書くのに飽きたので、少し楽できそうなモジュール書いてみました。 Sub::Sequence こんな感じです。 use Sub::Sequence; my @user_id_list = (1..10_000_000); seq \@user_id_list, 50, sub { my $list = shift; my $in_id = join ',', map { int $_; } @{$list}; # UPDATE table SET status=1 WHERE id IN ($in_id) sleep 1; }; us
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ページを開く
github の PR を全文検索して例文を探す