もう puts/p をデバッグに使わない！ デバッグライブラリ IceCream の Ruby 版 - Qiita
先日、Python 向けのデバッグライブラリ IceCream が話題になっていました。 Python 以外にもいくつかの言語版があるようですが、残念ながら Ruby 版が無い。というわけで作ってしまいました。 Ricecream (icecream-ruby) はじめに まず、このライブラリはいわゆる「print デバッグ」1の代替となるものです。 そもそも本格的にデバッグを行う場合、print デバッグではなく Byebug 等のデバッガを用いるべきです。 参考：printデバッグにさようなら！Ruby初心者のためのByebugチュートリアル とはいえ print デバッグが非常に手軽なものであることは間違いなく、ちょっとしたデバッグにはいちいちデバッガを使うより print デバッグで済ませてしまうという方も多いでしょう。 しかし print デバッグは手軽な分そのままでは困ることも
Stackdriver で Ruby アプリのモニタリング、デバッグ、ロギングが可能に | Google Cloud 公式ブログ
Google Cloud Platform（GCP）で動く Ruby アプリケーションのサポート拡充を進めている Google Cloud Ruby チームに合わせる形で、私たちは Stackdriver に対応した gem（Ruby ライブラリ）のベータ版をリリースしました。 Stackdriver は、モニタリング、ロギング、および診断機能を提供する管理ツール スイートです。今回の gem により、GCP だけでなく AWS やお客様のデータセンターでも、Ruby プロジェクトで Stackdriver を利用できるようになりました。Stackdriver gem の詳細は GitHub でご覧になれます。 他の Ruby ライブラリと同様に、私たちは Stackdriver ライブラリが Ruby ユーザーにとって理にかない、作業をより簡単に行えるよう手助けすることに重点を置いていま
SEGV探偵が往く - なるせにっき
人は誰しも108つの夢を持つと言いますが、読者の皆さんにも探偵を夢見た人は多いことでしょう。実際問題として探偵業をやろうと思ったら地道な聞き込み＆張り込みの日々でしょうし、逆に派手な探偵業は陰謀＆殺人で恐ろしい。わたしも自分の命は大事ですからどうするか。そう、探偵ごっこをするわけですね。 というわけでSEGV探偵です。死ぬのはプロセスなので安心。Rubyを使っていればSEGVなんて見慣れたものですが、いざ捜査しようと思うと意外とその辺には転がっていないもの。（むかしはつかみ取り出来るくらいいたそうですよ）とはいえ今でもいわゆる「バグ鉱脈」みたいなものはありまして、その一つが「最新のコンパイラでビルドしてみる」です。 今日はGCCの開発版であるGCC8を試してみましょう。FreeBSDだとsudo pkg install lang/gcc8-develで簡単に入れられるのですが、他の環境だと
VSCodeでRubyコードのデバッグができる環境を構築する（２０１７年２月現在） - 土屋つかさの技術ブログは今か無しか
ツイッターのTLを眺めていたら、mirichiさんがVSCodeでrubyを動かしているのを見て「俺もやりたい！」となって試しにデバッグ出来るところまでやってみました。結構大変だったので試行錯誤の過程を記録しておきます。 Visual Studio Code、通称VSCodeはオープンソースで開発されているソースコードエディタです。 Visual Studio Code（via wikipedia） https://ja.wikipedia.org/wiki/Visual_Studio_Code 【注意！】下記記事を読んでいる事が前提です インストールに辺りこちらのサイトの2016年04月19日の記事を主に参考にさせて頂きました。ありがとうございます。 Visual Studio CodeによるRubyのデバッグ（via Developers.IO） http://dev.classmet
printデバッグにさようなら！Ruby初心者のためのByebugチュートリアル - Qiita
はじめに この記事はByebug（バイバグ）というgemを使ったデバッグ方法を説明するチュートリアル記事です。 JavaやC#のようなコンパイル型の言語ではEclipseやVisual StudioのようなIDEを使って開発することが主流です。 なので、自然とIDEに標準装備されているデバッガを使ってステップ実行したりすることが多いと思います。 一方、RubyではRubyMineのような有料IDEもあるものの、IDEではなくテキストエディタを使って開発している人の方がまだまだ多いと思います。 そうすると、初心者の方はなんとなく「Rubyでデバッガを使ってデバッグするのは無理なのでは？」と考えてしまう人も多いかもしれません。（僕は初心者の頃そう思ってました・・・。） ですが、そんなことはありません！ RubyでもIDEを使わずにターミナル上でデバッガを使ってデバッグすることは可能です。 とい
Deleting code
Created 22 December 2002, last updated 6 November 2012 This document is also available in Russian. There’s plenty of information out there about how to write code. Here’s some advice on how to delete code. The best way to delete codeThis may seem obvious, but I guess it isn’t, because of the variety of other ways developers have of deleting code. Here’s how to delete code: Select a section of code
GitHub - seattlerb/debride: Analyze code for potentially uncalled / dead methods, now with auto-removal.
% debride lib These methods MIGHT not be called: MyClass good_method lib/some/file.rb:16 bad_method lib/some/file.rb:20 ... But you know that good_method is called (perhaps because it is public API), then you can whitelist it: % echo good_method > whitelist.txt % debride --whitelist whitelist.txt lib These methods MIGHT not be called: MyClass bad_method lib/some/file.rb:20 ... Usage example for a
How to spy on a Ruby program
June 12, 2016 I love debugging tools. One of the most frustrating things to me is – when I run a Ruby or Python program, I can’t find out what that program is doing RIGHT NOW. You might eagerly interrupt me – julia, you say, you can use pdb! or pry! or rbtrace!. So, let me explain. If I’m running a program on the JVM with PID 4242, I can run jstack -p 4242, and it will print the current stack trac
YARV命令ごとの実行コストを知るには - なるせにっき
プログラムのボトルネックを探すには大きく分けて二つの方法があります。心眼を研ぎ澄ましていきなり最適化してみてから考えるのと、何かしらのツールでサイクル数やCPU時間を計測して地道に探す方法ですね。皆さん普通は前者だと思うんですが、それが行き詰まってしまうこともあります。 後者のようにprofileを取っていく場合、手軽にCレベルでのprofileがとれて今わたしの中で一大ブームを巻き起こしているのがperf(3)なわけですが、Rubyのprofileを取ると往々にして以下のような結果になるわけです。（よい子のみんなはCレベルでのprofileではなく、stackprofを使ってRubyレベルでのprofileをとろうな！） sudo perf report --stdio --no-children -g none -d miniruby # To display the perf.dat
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
今更聞けないpryの使い方と便利プラグイン集 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Rubyのソースコードを読むとき、grepやctagsだけで読んでるとどこにどういう値が入るのか頭で考える必要があり大変。 そういう時、実際に動かしながらpryを使って中身を確認すると、どういう動きをしているのか楽に把握できる。 普通のエディタを使ってRubyを書いている人にとって、IDE的な機能を提供してくれるのがpryといえる。 本稿では、この記事を書く前の私のように、この次の「最低限の使い方」くらいしかpryを使いこなせていない人向けに、便利な機能をひと通り説明する。 最低限の使い方 まだpryを使ったことがない人はこれだけ知って
小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜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メンテナ」と称し、これまでの仕事の内容を紹介しました。
クライアントからやってくる本物のHTTPリクエストをダンプする - Qiita
Rack限定ならむかし rack-spyup というものを書いた。自分で使ってみたけどJSON APIのデバッグとかだと革命的に便利だと思う。 ただ、Rackに到達する前にリクエストがお亡くなりになったりとか、そもそもサーバルビーじゃないしとかあると思うので、もっと汎用的な感じでダンプする手順をメモしてみる。 リクエストが来たら内容を全部ダンプするHTTPサーバを作る Rubyに標準添付されている、WEBrickの基本的な機能で割と簡単に作れる。 # -*- coding: utf-8 -*- require 'optparse' require 'webrick' require 'json' options = ARGV.getopts("p:", "port:") # The :monkey: raises # cf. http://d.hatena.ne.jp/vividcode/
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=
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はデバッグシンボル付きのものをご用意ください。 生きているプロセスにア
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
QA＠IT サービス終了のお知らせ - ＠IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Using StackTracy within a small Sinatra application
Verify to continue To continue, please confirm that you're a human (and not a spambot).
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby本体でSEGVおこした時の gdb での追い方、またはデバグ手法 : sonots:blog
メソッド定義場所を探してソースコードを読んでみよう - Qiita
