Google ChromeのJavaScriptデバッガの進化がすごい - os0x.blog
Chrome版のFirebugことGoogle Chrome Developer Toolsですが、以前gihyoで解説したときよりさらに便利になっているので、少し紹介します(元はWebKitなので、そのうち(近いうちに)Safariでもそれなりに使えるようになるはずです)。 圧縮されたコードの整形 まず、目立つところからいきましょう。ちょうど先日更新されたChromeのdev版(12.0.742.0)に搭載されたばかりの機能で、minifyされているJavaScriptコードを読みやすいように整形して表示してくれるというものです(IE9の開発者ツールにも実装されている機能です)。 例えば、Google Analyticsのコードは圧縮されていて普通は読めません。 しかし、Chromeのデベロッパーツールなら、 このように整形してくれます。 やり方は簡単で、デベロッパーツールのScript
[JS]MicrosoftからJavaScriptのメモリリーク検出ツール
MicrosoftのヨーロッパチームからJavaScriptのメモリリークを検出するツール「JavaScript Memory Leak Detector」のベータ版がリリースしました。 JavaScript Memory Leak Detector JavaScript Memory Leak Detectorは、Windows+IE専用のツールで、ダウンロード・インストールは以下の手順になります。 下記の「download link」からファイルをダウンロード。 Installation ファイルを解凍して、「JSLeaksDetector.msi」をダブルクリックして、インストール。 インストール時は、IEは終了しておく。 インストールが完了したら、IEを起動。 IE7の設定方法 [表示] - [エクスプローラ バー」 -[js memory leak detector]をチェック。
DSAS開発者の部屋:オープンソースを楽しむエンジニアの一日 〜 コードを楽しく読む工夫
C言語で書かれたソースコードを読んでいるとき、関数ポインタから呼び出されている機能の実体がどこに書かれているのかを探すのに苦しんだ経験はありませんか？ 私はあります、いっぱいあります！！ そんなときはどうするかというと・・・ 手順１： まずは気分転換をする！ 手順２： そして気合いを入れ直す！ 手順３： さらに気力で読み砕く！ 手順４： 最後に根性で発見する！ これが、ごく一般的な作業手順(?)かと思います・・・（ごめんなさい嘘です） でもまあ、実際にここまで出来れば、そのプログラムの大まかな構成とか癖みたいなものはだいたい把握できているはずなので、他の関数ポインタについてもある程度当たりをつけて見つけだすことが出来るようにはなるかと思います。 ・・・・・が、、できれば気合いと根性を使わずに追えるなら追いたいのが人情ですよね。 straceやltraceを使えばシステムコールやライブラリコ
Webアプリの問題点を「見える化」する7つ道具
Webアプリの問題点を「見える化」する7つ道具：現場から学ぶWebアプリ開発のトラブルハック（1）（2/3 ページ） その2：負荷生成ツール 負荷生成ツールは、Webサーバなどに対して複数のユーザーからの同時アクセスによる負荷を疑似的に発生させるツールである。 ■使いどころ パフォーマンスに問題がないかどうか確認したり、性能劣化などの現象が発生した場合、その現象を再現させるために利用する。Webシステムのトラブルやパフォーマンスの問題は、クライアントからのリクエストを大量に処理しているときに起こるものが多い。 例えば、10秒以内にユーザーが50人程度ログインしたときにシステムが無応答になる現象が発生している場合、再現を行うために人手でブラウザを操作するのは非現実的である。負荷ツールを利用すれば、何十、何百人分の負荷を簡単に発生させられる。 ■分析方法 負荷生成ツールの基本的な使い方は、負荷
IE版のFirebug IE Developer Toolbar[to-R]
IE版のFirebug IE Developer Toolbar みなさんはInternet Explorer Developer Toolbarというのを知っているでしょうか？ マイクロソフトが現在ベータ版として提供しているツールで、簡単に説明すればIE版のFirebugです。 IEで使えるFireBugとして聞くとFireBug Liteを思い浮かべがちですがFireBug Liteのようにソースにjavascriptを埋め込むことなく実行することが可能です。 ちなみにFirebugとはjavascritpやCSSのデバッグなどを行えるFirefoxのアドオン(拡張機能)になります。 すごく便利ですので、使ったことがない方はFirebugの方からお使いください。 話は戻りますが、Internet Explorer Developer Toolbarのインストール方法について解説したいと
![IE版のFirebug IE Developer Toolbar[to-R]](https://cdn-ak-scissors.b.st-hatena.com/image/square/a9717624309e36a795026e1b70982163687ccca2/height=288;version=1;width=512/https%3A%2F%2Fblog.webcreativepark.net%2Ficon_200x200.png)
Firebugの便利な組み込み関数 - 技術メモ帳
id:brazil さんのブックマークで知ったのだが、 Firebugには、便利な組み込み関数が定義されているようだ。 一通りさわってみたのだが、 $x() で 任意のXPath要素が取得できるのとかに感動した。 そして、やっぱりちゃんとドキュメント読むべきだなぁと思った。 XPathから要素を取得する。 $x("/html/body/h1"); -> 要素の配列が返ってくる。 selector名から要素を取得する。(getElementsByTagName) $$("h1") -> 要素の配列 所要時間測定 console#time, console#timeEnd time ~ timeEnd で囲んだ部分の所要時間を 計測することが出来るみたいで、 以下のような関数にまとめると良さそうだ。 function bench( callback ) { var uniq_id = Date
既に起動しているプロセスをgdbで制御する:Geekなぺーじ
デバッグやテストを行っていると、プログラムが無限ループに入り込んで返ってこないような状況が発生することがあります。 そのバグが再現の難しいものであれば「gdbを使って起動しとけば良かった。。。」というような気分になる時があります。 しかし、gdbには既に起動しているプログラムの制御を横から奪い取ってデバッグするというありがたい機能があります。 ここでは、既に起動しているプログラムをgdbでいじる方法を説明したいと思います。 実際にデバッグをする方法を説明するというよりは、gdbで動いているプロセスにアタッチする例を説明します。 その後のデバッグに関しては、いつものgdbの使い方をしていただければ大丈夫です。 とりあえずアタッチしてみる 既に起動しているプロセスをgdbを解析するのは非常に簡単です。 単にgdbでプロセスにアタッチするだけです。 gdbでプロセスにアタッチする方法は2つありま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
