Java: 本番環境でのデバッグスキルを磨く - ワザノバ | wazanova
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
Activity がシステムによって kill される状態をシミュレートする方法 - sandbox
Android で、メモリが逼迫した状況下特有の不具合に遭遇し、そのデバッグ方法が分からなかったので調べてみた。 まず、メモリが逼迫した状態でどの様な事が起こるかというと、公式のドキュメントに下記の様な記載がある。 if the system must recover memory in an emergency, then onStop() and onDestroy() might not be called. Therefore, you should use onPause() to write crucial persistent data (such as user edits) to storage. つまり、システムがどうしてもメモリを必要とする時には、既にスタックに詰まれている Activity が onStop や onDestory の呼び出しなしにプロセスが kil
[Xcode][tool] ランタイムデバッガーSpark Inspectorが便利！ | Natsu note
デバッグ時にビューについての情報（重なりや位置、色など）を解析したくなることがよくあると思います。ビューの階層構造を知るための方法はいくつかありますが、先日見つけたSpark Inspectorがものすごく便利そうなのでご紹介します。 Spark Inspector – Runtime Debugger for iOS Apps Spark InspectorはBonjourとMethod Swizzlingを利用したランタイムデバッガーです。プロジェクトにフレームワークを追加し、起動のためのコードを記述するだけで簡単に利用できます（実際には、これらの作業もアシスタントが自動で行ってくれるので、ほぼボタン一つで利用可能になります）。 できることは大きく分けて二つ。 ビューの状態を2Dまたは3Dで表示する。ビューやレイヤーをリアルタイムで編集する。 通知センター(NSNotification
android:debuggableでデバッグログ切り替えはやめた方がいい - ReDo
AndroidManifest.xmlのapplicationタグ指定する、android:debuggable属性によるデバッグログのON/OFF切り替えをしばしば見かけるのですが、SDKで警告が出るのもあって公式としては非推奨ぽいので、少し動作について調査してみました。 以下、検証コードと詳細。 ○結論 原則使わないのが望ましいです。書き換え忘れもありえますし、開発時のapkと公開時のapkが別であることは色々な不幸の元です。 やむを得ず使いたい際には独自staticがまだマシだと思います。 public class MyConfig { public static final boolean DEBUG = true; } ○android:debuggableの動作 以下の様なアプリを作って試してみました。（SDKr18, ADT18.0.0） package test.debug
ソースコード解析におけるアタリのつけ方とか（その１）
仕事でプログラムを書いていると，デバッグ以外に他人のソースコードを読む機会がたくさんあるわけですけれど，大抵の場合，漫然と読んでいるのではなく目的があります。例えば，字句解析する際のバッファ管理の方法を知りたいから GCC を読むとか，ベクタオブジェクトの描画系はどうやってるんだろと思って，Inkscape のソースを読むとかいった具合。もちろん，それらが最適なプログラムとは限らないわけですけれど，他の人の考え方を取り入れるには，下手な能書きが書かれた本を読むよりも，ソースを読む方が手っ取り早かったりします。 で，ま，目的をもってソースを読むわけですけれど，この場合，まずもって目的のソースにたどり着けなくちゃいけません。全然関係ないところを読むのは時間の無駄ですから。この点，巷には，ソースの読み方をあちこちで紹介しているわけですけれど，あたしはあまりこゆ読み方はしていない気がします。例えば
消えたUIButton | SpiriteK Blog
ユーザインタフェースは重要ですよね。 iPhoneがここまで広く支持されたのも、フリックやピンチといった独特の入力操作、それを視覚的にフィードバックするアニメーション効果によるところが大きいのではないでしょうか。 当然、これは我々アプリ開発者にも求められます。 Interface Builderでボタンやラベルを配置しておしまいではなく、タッチイベントに合わせて動的にUIを制御する必要が出てきます。 かくして、配置したはずのUIButtonが画面に現れない状況に遭遇するのです。 さまざまな原因が考えられます。それはもううんざりするほど。 表示する座標が間違っている hiddenプロパティをセットしている アフィン変換が何かおかしなことになっている 別のビューに隠れている 親ビューのクリップ領域外にある 背景色や画像等の設定ミスで親ビューの色と同化している そもそもビュー階層に正しく登録でき
デバッグコンソールを活用しよう | SpiriteK Blog
XcodeのコンソールをNSLogの出力結果を確認するためだけの場所だと思っていませんか？ ええ、筆者は思っていました。 Javaでの開発環境にEclipseを使っていると、コンソールは実質的に出力専用でした。標準入力を受け取ることもできますが、自分でそういうコードを書かない限りは使いませんし。 Xcodeはデバッガとしてgdbが使われており、コンソールはそのままgdbのコマンドラインインタフェースになっています。 Xcodeでアプリ実行中に一時停止ボタンを押すと、コンソールにgdbのプロンプトが出ます。ブレークポイントやクラッシュによって停止したときも同様です。 ここで対話的にコマンドを実行することができます。 gdbには呆れるほどたくさんのコマンドが用意されていますが、基本的な操作はXcodeのGUIからも実行できるので無理に覚える必要はないと思います。 しかし、print-objec
Flexible iOS Logging - Kazzz's diary
Flexible iOS Logging « The Brenwill Workshop Flexible iOS LoggingはBill Hollings氏によるCocoa Touch SDKの開発で使用することができるロギングライブラリィ。 元々Cocoa TouchにはNSLogというロギングのためのライブラリィがあるが、これはprintf同様の非常に簡易なものであり、 ロギングレベル(info/error/debug ..etc.)が選べない 条件を設定することが出来ずに必ず実行されてしまう という弱点があるが、"Flexible iOS Logging"を使うことで簡単にそれを解決することができる。 使い方は非常にシンプルであり、 1.Logging.hをインクルードする 2.ロギングのためのマクロを呼び出す これだけである。 既に内部ではレベル分けがされており、 LogTra
Objective-Cの @property と @synthesize の組み合わせが何をやっているのかを解説 - 強火で進め
改めて説明するまでも無いかと思ってたけど意外と知らない人は知らないみたいので解説を書いておきます。 @property と @synthesize の組み合わせは端的に言うと「setterとgetter(アクセッサメソッド)をコンパイルの前に生成させる」以上。 ※Objective-Cの場合、 @ で始まるものはプログラムでは無く、コンパイラへの指示となります。この様な指示をObjective-Cではコンパイラディレクティブ(Compiler directive)と呼びます。 詳細説明 setterやgetterはメンバ変数を直接扱わずにメソッド経由で代入やデータの取得をする為に定義するメソッドです。setterがデータを代入する時のメソッド、getterがデータを取得する時のメソッドとなります。 メンバ変数をメソッド経由にすることにより代入前にチェックを行って有効な値のときのみメンバ変数
Xcode4でデバッグ設定 - 日々是笑心
あらら、EXEC_BAD_ACCESS が出たよ。retain チョンボか dealloc での解放チョンボってとこかな。:-( デバッグするときのお約束は３つの環境変数をYESで設定すること。 NSZombieEnabled MallocStackLogging NSDebugEnabled Xcode4 になって設定場所が大きく変わっちゃって戸惑っちゃったんだけど、こちらさんのページが参考になりました。:-) Xcode4での環境変数設定方法 よく使う話なので、自分も画像入りでメモっとこ。:-) メニュー「Product > Edit Scheme...」を実行する 左ペインで「Run ○○.app」を選択後、右ペインの Arguments タブを選択する。 Environment Variables 項目に上の３つを追加し、Values を YES にする。
gcc+gdbによるプログラムのデバッグ 第1回 ステップ実行、変数の操作、ブレークポイント
しかし、ブレークポイントという機能はデバッガの手助けなしでは実現できません。 ブレークポイントとはプログラムの強制一時停止を行うポイントで、実行中のプログラムがブレークポイントに遭遇するとプログラムは一時停止され、デバッガによるプログラムへの介入を行えるようになります。 ブレークポイントは次のような場所に設定できます。 指定した行番号のプログラムを実行しようとする瞬間 関数を呼び出した瞬間 その他、C++などでは「例外が発生した瞬間」などにもブレークポイントを設定することができます。 行番号ブレーク ブレークポイントとしてよく使用されるのは、「プログラムの特定の位置」です。 例として、bubblesort.cプログラムのsort関数内で、隣り合う二つの要素を比較している箇所にブレークポイントを設定してみます。 25|/* bubble sort */ 26|void sort(int *a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptのコードフローを視覚化するTraceGL
404 Error - File Not Found