We’re getting things ready Loading your experience… This won’t take long.
We’re getting things ready Loading your experience… This won’t take long.
Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち
追記 [20061103]: ライブラリ非依存なバージョンも書いてみました。id:reinyannyan:20061103:p1 でご覧下さい。 最近自分で書いた JS プログラムが驚くほど重かったので、どこに原因があるか調べたいと思いました。 その方法として、怪しいと思う箇所に (あるいは思わない箇所にも) 手作業でタイマーを仕掛けて、部分部分の実行時間を計測するのも手だと思うんですが、クラスのどのメソッドでどのくらい時間が掛かっているのかが自動的に分かる、というのが理想的かなと思いました。 (以下、prototype.js 的な (OO 的な) コーディングを対象とした話になります) まず思いついたのは、プロファイルしたいクラス (function オブジェクト) を受け取って、メソッドを動的に書き換えるという方法です: for (var m in klass.prototype) {
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
