小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 | gihyo.jp
RubyKaigi 2015レポート 小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 12月11日～13日、ベルサール汐留にて「RubyKaigi 2015」が開催されました。今年も基調講演が毎日一つずつ行われました。その模様をレポートします。 RubyKaigi 2015 2日目の基調講演は、世界で唯一の、LinuxのコミッタでありRubyのコミッタでもある小崎資広さんです。今回、小崎さんは「Linux loves Ruby. Ruby Loves Linux - How to debug your linux box」と題して、発表しました。 Linux portメンテナのお仕事 小崎さんは、Ruby Core Teamでの自分の役割を「Linux Portメンテナ」と称し、これまでの仕事の内容を紹介しました。
gdbを使ったrubyのデバッグ - クックパッド開発者ブログ
技術部の国分 (@k0kubun) です。 先日byebugの高速化を行っていた最中、変更を加えたbyebugを使っていると一定の確率でrubyがSEGVするバグを発見しました。 私はC言語のコードのデバッグの経験はなかったのですが、デバッガの使い方を調べながらSEGVの原因調査を行いパッチを送ったところ無事取り込まれ、最新の高速なbyebugが安全に使えるようになりました。 その際、ruby自体をデバッグするために必要な情報が分散していて大変だったので、まだrubyのデバッグをしたことがないけれどやってみたいという人を対象に、gdbというデバッガを使ったrubyのデバッグの方法を紹介します。 デバッグ用にrubyをビルドする デバッグ時に変数名やソースコードなどの情報を見るためには、最適化オプションをオフにしてデバッグ用にrubyをビルドしておく必要があります。 rubyのデバッグ用ビル
gems: pry とデバッグ周辺 | DriftwoodJP
なんとなく整理できてきたのでソースをまとめます。 [markdown] 今回も引用先サイトで勉強させて頂きました。 ありがとうございます。 ## インストール pry と関連する gem を確認。 > * [debug – Rails4 今のところ最強なデバッグツール達 – Qiita](http://qiita.com/yusabana/items/8ce54577d959bb085b37) “`ruby:Gemfile group :development, :test do gem ‘pry-doc’ gem ‘pry-rails’ gem ‘pry-stack_explorer’ if RUBY_VERSION >= ‘2.0.0’ gem ‘pry-byebug’ else gem ‘pry-debugger’ gem ‘pry-remote’ end end “` > * [R
pry-debuggerを使ってみた - ソースコードから理解する技術－ＵｎｄｅｒＳｏｕｒｃｅＣｏｄｅ
railsのデバッグ時に、シンタックスハイライトされるのが羨ましくて pry-debuggerを使ってみました。 単にインストールするだけでなく、ショートカットキーも自分の好みに 設定したので、以下にそのときの手順をメモとして載せておきます。 ◆インストール 1.gemに以下を追加。(developmentのところ) group :development,:test do gem 'pry-debugger' end 2.以下のコマンドを実行し、インストールする。 bundle install ◆ショートカットキーの設定 1.「.pryrc」ファイルをルート直下に作成する。 2.以下の定義を記述する。 Pry.commands.alias_command 'c', 'continue' Pry.commands.alias_command 's', 'step' Pry.commands.
pryを使ってRubyのスクリプトをデバッグする - ソースコードから理解する技術－ＵｎｄｅｒＳｏｕｒｃｅＣｏｄｅ
ちょっとしたスクリプトをRubyで書くときに、.rbファイルに保存することが あるかと思います。 今回は、.rbファイルとして保存したスクリプトを、pryでデバッグする手順です。 pryがインストール済みであることを前提条件とします。 1.ブレークポイントの設定 Ruby on Railsで行うのと同様、スクリプト内のデバッグ時に止めたい箇所に、以下を記述します。 binding.pry 2.スクリプトの実行 以下のコマンドをコンソールに記述し、Rubyのスクリプトをpryでデバッグ実行します。 $ ruby -r pry 対象のスクリプト名.rb 3.ショートカットキーの設定 上の手順だけでデバッグやステップ実行はできますが、よく使うコマンドについては ショートカットキーで呼び出したいところです。 ショートカットについては、実行するRubyのスクリプトファイルと同じフォルダ内に 「.pr
about-byebug-for-debug-with-pry - Philippos Blue Book
byebug 導入 ruby2.0環境下では、pry-nav ならびに pry-debugger のデバッグ機能に不具合があり、また例外補足のためのツール pry-exception_explorer にも不具合があるため、デバッグ用のツールとして同様の機能を持つ byebug および pry-rescue への切り替えを行った。 また今回のタイミングで、コールスタック（バックトレース）を参照するためのツールである pry-stack_explorer の導入も行った。 byebug は pry と同じインタフェイスを持っているとのことで使用法は pry と同じである。 まず、以下の gem は Gemfile から削除した。 1 2 gem 'pry-debugger' # あるいは pry-nav gem 'pry-exception_explorer' そして次の gem を導入する
something new and exciting
記事の引越しから漏れていたのでサルベージ。 [secondlifeさんの記事](http://d.hatena.ne.jp/secondlife/20061010/1160453355) に反応して後で書こうかなあと思っていたら、大分時間がたってしまいましたが、めげずに書いてみます。 1. p/pp こちらはRailsに限らず良く使われている方法ですが、RailsではWebサーバをフォアグラウンドプロセスとして立ち上げた状態で使う感じになります。 pre>> $ ./script/server <2. logger.debug さて、続いてlogger.debugを使う方法です。 pre>> logger.debug "something interesting information" <> $ tail -f log/development.log <3. script/console
ステップ実行可能なRailsリモートデバッグ環境 - clock-up-blog
概要 IntelliJ IDEA 13 (または RubyMine) と rdebug-ide の組み合わせで Ruby on Rails のIDEデバッグ環境を構築する。 大事なこと ブレークポイントを張れること ステップ実行できること コールスタックが参照できること 変数内容が参照できること 作業環境の前提 コーディング・デバッグは Windows7 上の IntelliJ IDEA から行う。 ブラウジングは Windows7 上の Chrome から行う。 サーバは Windows7 上の VirtualBox 内 CentOS にて立ち上げる。 IntelliJ IDEA 13.0.1 Ruby 2.0.0p353 Ruby on Rails 3.2.13 ※ Windows7 を MacOS なんかと置き換えても同じ手法が使えると思う。 リモート？ VirtualBox だしリ
Ruby の http ライブラリの通信を表示する http-dump を作った - 2nd life (移転しました)
Ruby 上で http を叩いた通信見たい時に、毎回同じ事をやってるので抽象化して http-dump というライブラリを作った。 https://github.com/hotchpotch/http-dump $ gem install http-dump require 'net/http' require 'uri' require 'http-dump' HTTPDump.dump { Net::HTTP.get(URI('http://example.com')) } と http でやりとりしてるコードを block で囲むと、以下のように出力される。 > GET http://example.com/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=
Railsのデバッグが捗るエラー画面Better Errors使ってみた！
Railsのエラー画面をわかりやすく表示してくれるBetter Errors(better_errors)、GitHubのRuby系プロジェクトの中で一ヶ月で１番Starがついてたみたいです。ということでさっそく使ってみました！ charliesome/better_errors - GitHub 🏀 Better Errorsとは？Better ErrorsはRack(RailsとかSinatraとか)のエラー画面をデバッグしやすい形に整形してくれるGemです。 このGemの特徴は次の3つです。 * 綺麗なUI * わかりやすいエラーメッセージ * ブラウザからのirb(PERL)によるdebugが可能 インストールは、Gemfileに次の行を追加してbundle installするだけです。 group :development do # エラー画面をわかりやすく整形してくれる ge
Rails4 今のところ最強なデバッグツール達 - Qiita
Gemfile の 「group :test, :development do」ブロックに書いている 個人的に最強な設定 を晒したいと思います。(2013/10/24 現在) 作業環境 Ruby 2.0.0p247 Rails 4.0.0 Gemfileに設定している内容 ※ コメントに随時変更したものを追記しますー group :test, :development do gem 'pry-rails' gem 'pry-doc' gem 'pry-stack_explorer' if RUBY_VERSION >= '2.0.0' gem 'pry-byebug' else # 以下はRuby1.9の時のみ使う(pry-byebugの代わりに) # debuggerは1.9以下でしか動作しない, remote は byebug で使えないようになった gem 'pry-debugger
CoreからRubyのバックトレースを表示するgdbruby.rbを作った
gdbperl.plというスクリプトがあります。そんｋする樋口証さん作の、gdbを操作してPerlのプロセスのバックトレースを取るツールです。生きているプロセスだけではなく、coreを取っておけばそのcoreからバックトレースが取れるのが特徴です。 gcoreというコマンドが/usr/binあたりにあって、これを使えば走っているプロセスのcoreを取得することができます。よって、本番環境で気軽にcoreを取ってgdbperl.plにかけることによって、刺さっているポイントを見つけたりすることができます。超便利。 くわしくは、Perlスクリプトをgdbでデバッグを参照ください。 んで、その便利なgdbperl.plをRubyに移植してみました。その名もgdbruby.rb。単純。 gdbruby.rb 使い方とか Rubyはデバッグシンボル付きのものをご用意ください。 生きているプロセスにア
Rubyのデバッグに役立つ便利なPryの拡張まとめ | ましましブログ
Rubyistのみなさん，Pryはご存知でしょうか． Pryとは，最近話題のirb上位互換の高機能インタプリタです． 簡単な解説は以前に自分でも書きましたが， こちらの記事がよくまとまっていると思います． Rubyistよ、irbを捨ててPryを使おう - TIM Labs 実際に使ってるところをscreencastで見てみると，より凄さが分かると思います． Pry Screencast on Vimeo さて，Pryには，pry-railsの用にインストールすることでpry自身が便利になったり， 他の環境でもpryが利用できるようになったりするような様々なpluginのgemがGithubで公開されています． 今回は，Githubのリポジトリを検索してpry-xxxって名前がついている， Pry関連のgemを調べて，自分が便利だなーと思ったものをまとめてみました． 基本編 まずは，デフォ
Railsならbetter_errorsを入れるとデバッグがはかどるなぁ - (ﾟ∀ﾟ)o彡 sasata299's blog
2013年09月02日18:22 Ruby Railsならbetter_errorsを入れるとデバッグがはかどるなぁ 今までなんで入れてなかったんだろ、、って思いました。 better_errors はRailsのエラー画面を素敵にしてくれるgemです。これだけでRailsのエラー画面がすごく便利になるんです。こんな感じ。 注目すべきは右上のエリア！なんとその場でデバッグすることが可能です…！有難いっ！ ででーん（クリックして拡大できます）。 インストールも簡単でGemfileに追加してbundle installするだけっ！！と簡単ですが セキュリティ のところは一度ちゃんと読んでくださいね。 group :development do gem 'better_errors' gem 'binding_of_caller' # その場でデバッグするには必要 end ツイート 「Ruby」
CRubyでオブジェクトが生成された位置を突き止める - GC Advent Calendar - I am Cruby!
Garbage Collection Advent Calendarの1日目の記事です。 おそらく一人でけっこう長い日数を書くと思うので、軽いものからボチボチと…。 しかもGCとはあまり関係ないですが…。 とあるオブジェクトの生成位置を調べたいとき、どうするのか。 object_idを1bit左シフトするとだいたいそのオブジェクトのRVALUEのアドレスになるので p (hoge.object_id 1).to_s(16) # => fa83a4 上記のようにobject_idを出力するコードを混ぜておきましょう。 その後にgdbでrubyを動かしてみます。 この時、GC_DEBUG付きでビルドしたrubyなら実はソースコードとラインがわかります。 デバッグ用にGC_DEBUG付きのrubyがビルドできるようならそうしてみましょう。 rvmだったら.rvmrcに以下の設定するとできるんじゃ
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
Rubyのnet/http でHTTPリクエスト/レスポンスをdumpする方法 - ( ꒪⌓꒪) ゆるよろ日記
俺得メモ。もう3回くらい同じこと調べたんでいい加減メモ残しておく。 Net::HTTP にset_debug_outputってメソッドがあってコイツに出力先を渡せばいい。残念ながらこのset_debug_outputはドキュメントには載ってないのでnet/httpのソース見てね。 require 'net/http' Net::HTTP.version_1_2 http = Net::HTTP.new("d.hatena.ne.jp", 80) http.set_debug_output $stderr http.start{|http| req = Net::HTTP::Get.new('/yuroyoro') res = http.request(req) print res.body } irbでやると irb(main):001:0> require 'net/http' => t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby プロセスを追いかけるツール(プロファイラとか)10選 - sonots:blog
http://blog.kiftwi.net/2012/03/20/summary-of-pry-plugins/
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ