シェアデバッガーでは、コンテンツがFacebookでシェアされたときの表示をプレビューし、Open Graphタグの付いた問題をデバッグできます。
シェアデバッガーでは、コンテンツがFacebookでシェアされたときの表示をプレビューし、Open Graphタグの付いた問題をデバッグできます。
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
これまでに作ったアプリが、正しく動くときと動かない時があり、落ちていることにずっと悩んでいたのですが、どうにか解決しました。今のところ、落ちていません。 落ちるタイミングとして、NavigationControllerを使って移動した直後、しかも画面を読み込み中に戻ったりすると、落ちるパターンが数多くありました。作っているアプリがインターネットから情報を読み込むものが多く、読み込みの途中で前の画面に戻ったりした場合にインスタンスが開放されていて、落ちていたものと思われます。 対策例 例えばこのような場合 @interface test : NSObject { @private NSString* teststring; id testid; } @property (nonatomic, retain) NSString* teststring; @property (nonatomic
googleのAndroid開発者向け ブログに「Memory Analysis for Android Applications」という記事があったため、自分のために訳しました。参考になれば幸いです。本エントリを見るうえで、eclipse の基本的な使い方を理解している必要があります。 Androidアプリのメモリ解析手法 Dalvikランタイムは、ガベージコレクトしてくれるかもしれませんが、それはメモリ管理を行わなくてもよいというわけではありません。モバイル端末上でのメモリ利用状況は特に注意を払わなければなりません。本投稿では、開発するアプリのメモリ利用状況の把握を支援する Android SDK で提供しているメモリプロファイリングツール群のいくつかを紹介させて頂きます。 メモリ利用時の問題はいくつか明らかになっています。例えば、もしあなたのアプリがユーザの画面タッチ操作のたびにメモ
Java Advent Calendar -ja 2010 : ATND 11日目。昨日は、id:daisuke-m でした。 完全に Eclipse のこと書けとふられてる感じがしたので Eclipse について書く。 Eclipse の何について書こうかと考えたんだけど、先日、社会人になってからプログラム書き始めた弊社の若い子が、「デバッガ」の存在を知らなかったのでデバッガの基本的な使い方などについて書く。 PHPというちょっとしたWebページをさらっと書くには素晴らしい言語だけしか知らないみたいだから、あんまりデバッガ使う文化が無かった模様です。 var_dumpデバッグェ…。 今回は初心者向け記事なので、基本Java使い倒してる皆様は読まなくてよろしいが、Break Point Properties の Condition とかDrop To FrameとかExpressionの機
今や PHP で開発するときに Xdebug は誰もが当然つかってるよね！！ まあ、「俺はそのままのエラーが好きなんだ」って人は置いておくとして。。。 大体の人は、stack traceがあると嬉しいとか、var_dump() 見やすいとか、そういうことで Xdebug ってのは愛用だとおもうんですよ！ IDE のひとは remote debugger としてつかってるのかな？ で、Xdebug、わかりやすいんだけど、どうもカワイサが足りないよね？なんかこう、毒々しいというかなんというか。。 開発中にエラーだしたときちょうど後ろをかわいいデザイナーの女の子が通りかかって画面が目に入ったとき「プログラマーってなんて品のない画面を見てるのかしら」なんて思われたらモテないよね！！ ってことで、まあ冗談はこのへんにしておいて、見た目が綺麗だとやる気も出る（？）ってことで、Xdebug の出力をかわ
複雑な機能をいくつも実装したWebアプリケーションのデバッグはツールなしでは一苦労だ。Ajax処理やこまかいイベント制御・DOM操作をおこなっている箇所でバグを出してしまった日には、解析だけで大変な時間を割かなければならない。 そんなときは、FireCrystalを使えば解決するかもしれない。ユーザの操作を記録し「どのタイミングで」「なにがおこなわれているか」を一発で表示してくれる便利なアドオンだ。 本稿では、そのFireCrystalについて紹介しよう。 FireCrystalとは Stephen Oney氏は8月21日(米国時間)、Firefox上で動作するアドオン「FireCrystal」をリリースした。FireCrystalはThe MIT Licenseのもとで公開されている、Webデザイナ・デベロッパ向けのデバッガ。Webページ上でユーザの操作を記録し、内部でどのようなイベント
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
BOOK: WEB+DB Press TITLE: 常駐型サーバーのデバッグ手法(ドラフト版) AUTHOR: (株)プリファードインフラストラクチャー 太田一樹 ＊注: この文章はWEB+DB PRESS Vol.48に掲載された記事のドラフト版です はじめに 今回はデバッグ関連特集ということで、常駐型サーバープログラムを作成する際のハマりどころやそれに対する解析方法・解析ツール・対策を、実際の経験を交えながら紹介したいと思います。 筆者は(株)プリファードインフラストラクチャーでインメモリ分散検索エンジン「Sedue (セデュー)」を開発しています。モバイル向け検索エンジン「エフルート」や、2008/11/6にリニューアルされました「はてなブックマーク2」などの検索バックエンドとして使われております。 この検索エンジンはいくつかの常駐型サーバープログラムから構成されており
extension=xdebug.so xdebug.profiler_enable = 1 xdebug.profiler_output_dir = /tmp と設定して、apacheのリロードを行えばXdebugが動作します。 これで、あとは、ブラウザで調査したいページにアクセスすれば、 /tmp/ 以下にプロファイルデータが作成されていきます。 次にプロファイルデータの閲覧の為に、 http://sourceforge.net/projects/wincachegrind/からWinCacheGrindをダウンロードしてwindowsマシンにインストールします。 あとは、WinCacheGrindで作成されたファイルを取り込めば、関数ごとの 実行時間をたどりながら確認することができます。 ※WordPress2.7.1日本語版インストール直後のTOPページで試してみた場合です。 We
JavaScriptの部分は というわけでid:amachangに任せましょう。 というわけでそれ以外の部分でいったいどこが重いのか 何が重いの？ということで重たい箇所を分析していきましょう。 IBM PageDetailer 解析ツールとしてIBM PageDtailerを利用します。 alphaWorks Community 解説するよりも見てもらうほうが早いと思うのでさっそく使ってみるよ。 ちなみに上記ソフトのダウンロードにはIBMアカウント（無料）が必要なので、使いたい人は登録しよう！ http://b.hatena.ne.jp/HolyGrail/ の結果 こんな感じのグラフが出てきます。 では、詳細を見てみましょう。 このグラフですが、長い部分が http://b.hatena.ne.jp/HolyGrail/ のHTMLそのもののロード時間になっています。 内訳としては 濃い
はじめに 「新はてなブックマーク」になったということで、とっても便利になったのですが、ブックマーク一覧ページ*1が若干 JavaScript に時間が掛かっているみたいです。 というわけで 調査してみたいと思います。調査して、改善できそうなところは後で纏めて「はてなアイデア」にでも登録しようと思います。 この日記は調査しながら、過程を書いていくつもりです。 準備 まずは、人のサイトの JavaScript を書き換えて試してみるための環境を作ります。 作業用ディレクトリを作る とりあえず、ホームに HatenaJS というディレクトリを作ります。 $ mkdir HatenaJS $ cd HatenaJS CocProxy をダウンロードしてくる 以下から CocProxy というツールをダウンロードしてきます。 http://coderepos.org/share/wiki/CocPr
asActionScript 2 用のデバッグツールとして有名だった XRay が ActionScript 3 に対応したようです。DisplayObject の階層を表示してくれたり、オブジェクトのプロパティを修正したり、ログ用のコンソールになったりと機能豊富です。しかも、Flash CS3 だけでなく、Flex や AIR でも使えるようです。ということで、早速、試してみました。ダウンロードしてソースコードに２行追加するだけXRay のソースコードを拾ってきます。Google Code にあるので、SVN で拾ってきましょう。http://osflash-xray.googlecode.com/svn/trunk/as3/trunk/では、自分の Flash に仕込んでみましょう。ActionScript のソースコードに import 文を追加します。 import com.bli
Google Chromeはシンプルに見えてオフラインやWebアプリショートカット作成などいろんな機能が搭載されています。 そんな中、JavaScriptデバッガがあるのも発見！ どんなもんかと思ってみてみたら、なんとコマンドラインベースのデバッガです。Firebugみたいな物を想定していたのですが、まさかgdb（GNU製C/C++デバッガ）みたいなのがブラウザに載ってるなんて・・・しかも全然情報ないし。 でも開発者にとっては、JavaScriptをランタイムでデバッグできると言うのは非常に嬉しい事ですね。そこで、Chromeデバッガの使用法についてちょっと調べてみました。 デバッガは、開発者向けメニューの中から選択する事が出来ます。立ち上げてみると、コマンドの表示結果が表示されるエリアと、コマンドを入力するテキストフィールドが並んでいるだけ、と言うシンプルなUIが表示されます。 最下部の
先日のShibuya.pm #9のLightening Talkで「gdbでXS on mod_perlをデバッグ」という話をしてきました。XSを使い出すと、従来のPerl的デバッグだけでは不十分なのでgdbをうまく使って、効率的にデバッグしましょう、という話です。実は、はてな社内では1年近く前に勉強で話したネタだったのですが、ようやく公開することができました。 Shibuya.pmでは5分という枠があったのでショートver.でしたが、ここでは制限はないので、本来のロングバージョンの資料をアップします。ちょっと公開できない情報が混っていたので、xxxで隠していますが、ご了承ください。 ちなみに、Rubyとかでも似た感じでデバッグできると思うので、そちらの人も参考にしてください。長いよ!という人は、最後の「これは設定しておけ的gdb初期化マクロ」だけでもどうぞ。かなり便利です。 (資料公開が
DebugBar Home > Wiki > IETester :: Browser Compatibility Check for Internet Explorer Versions from 5.5 to 11 :: ANNOUNCE: If you are an Adwords user, The IETester team is proud to announce its new tool: SunnyReports, a simple and efficient Adwords reporting tools IETester is a free (both for personal and professional usage) WebBrowser that allows you to have the rendering and javascript engines of
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]をチェック。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く