http://eventdots.jp/event/591027 (2016-07-30追記：Rails 5.0からproductionでもDEBUGがデフォルトらしいです) (2020-09-23追記：https://github.com/rails/rails/pull/39707 INFOに戻りそう)
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable（EJB除く）である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
Python を初めて間もない頃、自分も print デバッグしてました。効率の悪さを認識しつつも、IDEを導入してデバッグする方法を調べてセッティングして、という手順が面倒でずっと放置してました。 // 普段は vim で開発してます そうこうしてたら print デバッグではどうにもならないバグにぶち当たり、仕方なくデバッグポイントを置く方法を調べたわけです。するとどうでしょう。 ソースコード中に以下の一文を入れるだけではないですか。 import pdb; pdb.set_trace() たったこれだけで、上の一文を挿入した行で処理が停止し、コンソール上でステップ実行が出来るようになります。最高かよ。 個人的にですが、デバッガー起動中によく使うコマンドとしては以下です。 コマンド 説明 s(tep) ステップイン n(ext) ステップオーバー r(eturn) ステップアウト l(
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
2021年2月26日追記 最近は PCOV が良いらしいです。 PCOV は PHPUnit8 以降の対応なので、この記事は PHPUnit8 未満の方向けです。 2021年8月2日追記 が、phpdbg と比べてカバレッジが下がってしまう場合もあるようです ユニットテストの評価に、コードカバレッジを使用することは、よくあると思います。 従来より、 PHPUnit にはコードカバレッジ解析機能が実装されており、 HTML をはじめとするいくつかの形式で、レポートを出力可能です。 PHP5 では、 xdebug が提供するステートメントカバレッジ機能が利用されてきましたが、これが大変遅く、1100 Assertions ほどの EC-CUBE3 のカバレッジを出力するまで、2時間以上かかります。 しかも、速い CPU にしても大して速くならないのです。 Windows 環境では特に遅くなるら
この記事は、アムステルダムで2015年に開かれたFronteersのカンファレンスで私が行った講演、「デバッグの技術」に対応するものです。 要約：利用可能なあらゆるツールの使い方を学び、必要なときにそれを使うことで、バグの撃退を楽しみましょう。そのほうが、キーボードを無暗に叩いて6か月も費やしてしまうより、ずっと楽しいものです。 本題に入る前に… この記事を終わりまでスキップしたければ…… Don’t. Write. Bugs. とはいえ…… おそらくこれを読んでいるあなたはロボットではないでしょうから、1個や2個のバグぐらいは書いてしまったことがあるでしょう。「銀の弾丸」は存在しないのです。 実際、先ほどジョークで申し上げた『バグを書くな』というのは、デバッグの仕方を学ぶことの対極にあるものです。必要なのは経験です。バグに対するアプローチを見つけられるようになるためにはバグに遭遇しなけれ
以前の記事で、 Webアプリケーションのデバッグの仕組み について触れました。今回は実践的なJavaScriptのデバッグについて掘り下げていきたいと思います。 ブラウザデベロッパツール 私の個人的なお気に入りはChromeデベロッパツールです。SafariやFirefoxはChromeほどの高水準に達していません。しかし、徐々に改善されてきています。FirefoxにはFirebugと改良されたFirefoxデベロッパツールが組み合わされた機能が備わっています。もし、Firefoxチームがビルトインされているデベロッパツールの改良の中で素晴らしい仕事をし続けたとしたら、Firebugはいつか、すたれるかもしれません。 個人的な好みにかかわらず、ターゲットとするあらゆるブラウザで、全てのコードのテストやデバッグができるようにすべきです。”あらゆるブラウザ”には、かの有名なInternet E
Action unavailable We're sorry! This is a static copy of Wiki.eclipse.org and not a functional wiki installation, so actions(edit,talk,history,etc.) do not function. For software licensing,website privacy policy, website terms of use, and legal FAQs, please see our legal stuff page. Eclipse logos and graphics are found on our logos page. For problems with the eclipse.org site, please contact the w
先日来、Android アプリのデバッグ作業の必要に駆られ、あまり好きではない Eclipse さんと向き合っております。 くそう、Android なんて興味無いのに（暴言）。 …嘘です。ちょっと嫌いなだけです。ドロイド君のことは愛していますが、本名は “Bugdroid” ということを最近知ってショックを受けました。好きな食べ物は林檎とペンギンです。 で、ある Out of memory Error を調べるために、Eclipse に Memory Analyzer Tool(MAT) を導入した際の、メモ。 インストール 環境は Mac OSX 10.7.5 + Eclipse Juno、ADT は 22.0.1 です。 Eclipse の “Help” → “Install New Software” で “Available Software Site” をクリックして 下記 UR
– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 – その5: Memory Analyzer でヒープダンプを解析(最終回) 延々と連載してきたメモリリークトラブルシューティング記もいよいよ最終回です。 今回のメモリリーク現象はリークの再現方法がわからないため、運用環境から詳細なデータが取得できるheapdumpを取得した、というのが前回までのあらすじです。 次は、ヒープダンプの解析。 ヒープダンプは JDK に付属の jmap コマンドで取得します。 jmap -heap:format=x [pid] または jmap -heap:format=b [pid] といった形で実行するとヒープダンプを xml 形式、またはバイナリ形式で記録できます。 通常生のヒープダンプ
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
javascriptでちょっと賢いロガーっぽいのを作ったとしても、最終的にはconsole.logを使ったりすると、ログの表示箇所が全て同じファイル、行になるのでいまいち不便。 そこで、V8エンジンのブラウザだけだけど、スタックトレースを取得してログメソッドが実行された行数、ファイル名などを一緒に出力する方法を調べた。 を使えばいける。例えばこんな感じ。 Error.prepareStackTrace = function( e, st ) { return { functionName: st[0].getFunctionName(), lineNumber: st[0].getLineNumber(), //いろいろお好きに }; }; function log( msg ) { var obj = {}; Error.captureStackTrace( obj, log ); co
お久しぶりです。野瀬です。 最後の投稿から約1年が経っており、時が経つのは早いなぁ〜と感じる今日この頃。 最近自分の周りでの開発環境はVagrantを使うのが増えてきています。 自分も流行に乗っかりVagrantを使って開発しています。 今回はそんなVagrantとPHPとXdebugを使ったステップ実行をする手順をご紹介したいと思います。しかもWebブラウザからだけではなくCommandLineからもステップ実行させる設定方法です。すご〜くいまさらな感じはしますが・・・ ググってもWebブラウザからのステップ実行は結構あるのですがCommandLineからのステップ実行の設定があまりなかったので同じように困った方の為に。 環境確認 あくまでも例ですので適宜自分の環境に置き換えてください。 Vagrant ver1.5.2 CentOS release 6.5 (Final) PHP ve
Home > Laravel | PHP | PhpStorm | Vagrant > PhpStorm から Vagrant VM の PHP アプリケーションをリモートデバッグする（Web & CLI） PhpStorm から Vagrant で構築した VM の PHP アプリケーションをリモートデバッグする方法です。Web アプリケーションだけでなく、CLI アプリケーションでもリモートデバッグできるように設定していきます。 VM スペック 192.168.33.41 を private network で設定 PHP + Xdebug がインストール済み ホストと VM は、synced folder でディレクトリを共有（/path/to/src -> /share） 0. Xdebug によるリモートデバッグの仕組み リモートデバッグを設定する前に PhpStorm と Xd
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
