記事の引越しから漏れていたのでサルベージ。 secondlifeさんの記事 に反応して後で書こうかなあと思っていたら、大分時間がたってしまいましたが、めげずに書いてみます。 1. p/pp こちらはRailsに限らず良く使われている方法ですが、RailsではWebサーバをフォアグラウンドプロセスとして立ち上げた状態で使う感じになります。
これは便利だと思います。 no title Wirble: colors irbでシンタックスハイライト。 Wirbleをインストールします。 % sudo gem install wirble ~/.irbrcに下のコードを書きます。 require 'rubygems' require 'wirble' Wirble.init Wirble.colorize 出力がハイライトされます。ハッシュや配列は見やすいかも。 Wirble: history irbは、コマンドの履歴が残ります。[↑]や[↓]、[control] + [p]や[control] + [n]で履歴を見ることができます。しかし、いったんirbを終了すると、履歴がクリアされてしまいます。 Wirbleをインストールしておくと、履歴がクリアされません。再度irbを起動すると、前回の履歴を使うことができます。 Wirble:
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
メモリ解放済みのインスタンスへアクセスする時にこのエラーが発生することが多い。デバッグの方法として NSZombieEnabled が紹介されていた。これを使うと解放済みのインスタンスへアクセスすると EXC_BAD_ACCESS の代わりに例外が発生し、エラー原因が発見しやすくなる。
Firebugでは条件付きブレークポイントが使えるので、 scriptタブにて該当行にブレークポイントを貼り、 条件としてconsoleへの出力を||区切りで、最後に&& falseを入れる。 console.debug('this.lastPosition') || console.dir(this.lastPosition) && false こうするとブレークポイントを通る度にconsoleへの出力は評価され、 consoleに出力され、最後の&& falseのため式全体は必ずfalseとして評価されるため ブレークすることはない。 追記 console出力系関数の戻り値はundefinedなんだから&& falseは不要か 追記 nanto_vi @monjudoh JSでは||より&&の方が優先順位が高いので、a || b && c はaが真ならbもcも評価されずに全体が真として
iPhone デバッグ用のマクロ - Windchase #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_CURRENT_METHOD NSLog(NSStringFromSelector(_cmd)) #else # define LOG(...) ; # define LOG_CURRENT_METHOD ; #endif iPhone デバッグ用のマクロ - Windchase このマクロをちょっと変えて、クラス名を自動的に出力するようにしました。 #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_CURRENT_METHOD NSLog(@"%@/%@", NSStringFromClass([self class]), NSSt
See related links to what you are looking for.
iPachiで起きていた不具合なのですが、 特定の画面を表示中にメモリ不足に陥り didReceiveMemoryWarningを受け取ると アプリがクラッシュするという問題をついに 解消しました。 didReceiveMemoryWarning後にクラッシュするので メモリ管理でどこかがおかしくなっているのだろうとは 予想がつくのですが、いかんせん貧弱なエラーメッセージの ため、まったく発生元がつかめませんでした。 EXC_BAD_ACCESSとか言われてもさっぱりわからんです。 が、すばらしい記事をみつけました。 NSDebugEnabled これでクラッシュをおこしているオブジェクトの生成場所を 特定できるので、格段にデバッグ効率があがります。 というわけで、エミュレータでのメモリ不足時のシミュレートと デバッグのための設定をまとめます。 エミュレータでのメモリ
iPhone アプリをデバッグするときに、ソースに NSLog をそのまま書いてしまうと、リリース時に削除するのが面倒なので、以下のようなマクロを使っています。 #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_METHOD NSLog(@"%s", __func__) #else # define LOG(...) ; # define LOG_METHOD ; #endif 使い方は、まずプロジェクトの設定を開き、「Debug」構成を選択してから、一番下のユーザ定義カテゴリの「GCC_PREPROCESSOR_DEFINITIONS」に「DEBUG」を追加しておきます。 こうすることで、Debug build のときにだけ「DEBUG」が定義されます。 あとは、NSLog の代わりに LOG を使うようにすれば
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
こんにちは、mixi開発部にてアプリケーション開発をしていますyouheiです。 今回は、MySQL-5.0.45のInnoDBで連番を管理するテーブルのパフォーマンス測定をしていたのですが、その際に少し変わったデッドロック問題に遭遇しましたので、そのあたりをネタとして書いてみたいと思います。 まずは、今回使用したデータベースのスキーマは下記のようなものです。 CREATE TABLE num ( id bigint unsigned NOT NULL default '0' ) Engine=InnoDB; AUTO_INCREMENTは使用していません。 そこに1レコードだけ登録します。 INSERT INTO num (id) values (1); そして実際連番を取得する際には、 UPDATE num SET id = LAST_INSERT_ID(id+1); といったクエリを
FirefoxであればFirebugで簡単に問題の場所をみつけられますが、IEでjavascriptのエラーが出ると、素っ気ないうえに意味不明な日本語のエラーメッセージが出てきてお手上げなので、エラーが出ている場所の特定すら困難です。 そんなときでもOfficeについているスクリプトエディタ(前はスクリプトデバッガという名前だった気が....)を使うと、Visual Studioのデバッガとおんなじインターフェイスのデバッガを使ってjavascriptのエラーを出している場所をすぐに見つけることができます。Firebugと比べると極めて重たいですが、関数呼び出しをバックトレースすることもできますし、各スコープでの変数の値を調べることもできるので、これを使わない手はありません。 が、いつもどうやってインストールするのかを忘れてしまうのでメモ代わりに書いておきます。 コントロールバネルのプロ
先日のShibuya.pm #9のLightening Talkで「gdbでXS on mod_perlをデバッグ」という話をしてきました。XSを使い出すと、従来のPerl的デバッグだけでは不十分なのでgdbをうまく使って、効率的にデバッグしましょう、という話です。実は、はてな社内では1年近く前に勉強で話したネタだったのですが、ようやく公開することができました。 Shibuya.pmでは5分という枠があったのでショートver.でしたが、ここでは制限はないので、本来のロングバージョンの資料をアップします。ちょっと公開できない情報が混っていたので、xxxで隠していますが、ご了承ください。 ちなみに、Rubyとかでも似た感じでデバッグできると思うので、そちらの人も参考にしてください。長いよ!という人は、最後の「これは設定しておけ的gdb初期化マクロ」だけでもどうぞ。かなり便利です。 (資料公開が
2007年02月11日13:45 カテゴリLightweight Languages perl - B::Deparse 尻馬乗るべし、ということでB::Deparseの紹介。 いやなブログ - スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl スクリプト言語用の CUIのデバッガの使い方を簡単にまとめました。対象言語は Ruby, Python, Perl です。実は私も、デバッガーはperl -de1ぐらいしか使っていない(perl -de1は非常によく使うので、Terminal.appのウィンドウの一つがそれ専用になっている。スクリプト言語のインタラクティブな利用法に関しては以前「404 Blog Not Found:LL Intaractive」にまとめたのでそちらをご覧頂くとして、ここではなぜスクリプト言語では滅多にデバッガーを使わないかをおさらいした
尾藤正人です。 Ruby で debug する7つの方法 Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 ということなので、僕が PHP でやってること書いてみたいと思います。 preprint_r() print_r() とか var_dump() だと HTML の中に出してブラウザで見るときにすごく見にくくなります。 そこで preprint_r() という関数を定義して、<pre></pre> で囲んで見やすいように出力しています。 function preprint_r(&$var, $title = '') { echo _preprint_r($var, $title); } function &_preprint_r(&$var, $title = '') { if
肥え続けるTomcatと胃を痛めるトラブルハッカー:現場から学ぶWebアプリ開発のトラブルハック(8)(1/3 ページ) 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部) メモリリークと聞いて、良いイメージを思い浮かべる開発者は少ないだろう。経験したことのある人にとっては、思い出したくない過去の記憶がよみがえるかもしれない。もしかしたら、その単語を聞くだけで胃が痛くなる人もいるかもしれない。筆者もかつてはその1人であった。 前々回の記事では、WebサーバとTomcatの間の接続において、スレッド数の不整合により発生したトラブル事例を、前回はTomcatとDBサーバの間のトラブル事例を紹介した。今回もTom
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く