こんにちは、@yuskuboです。 本記事は ビビッドガーデン Advent Calendar 2021 の13日目の記事です。 概要 RubyKaigi 2021でRubyの新しいdebuggerであるdebug.gemが紹介されましたね!Ruby 3.1からは標準ライブラリになる予定とのことです。 ビビッドガーデンでは、これまでbyebug gemとpry gemを利用していましたが、今後のバージョンアップ対応のことも考慮してdebug.gemへ移行し、日々の業務で使っています。 本記事では、私がよく使っているdebug.gemの機能をいくつかピックアップして紹介していきます。「それ知らなかった!」や「そんなこともできたんだ!」ということを1つでもお届けできれば嬉しいです。 対象読者 debug.gemをまだ使ったことないから基本的な使用方法を知りたいという方 debug.gemは既に
新しいデバッガに乗り換えてデバッグプロセスを変更するのがつい億劫になることもあるでしょう。本記事によって、皆さんがruby/debugに親しんでスムーズに移行する助けになることを願っています。 以下、debugはruby/debugを指します。 免責事項 著者はdebugと比べてbyebugの経験があまりありません。不正確な情報や古い情報がありましたらぜひお知らせください。 本記事の目的は高度なレベルで比較を行うことです。debugの特定の利用方法については公式ドキュメントを参照してください。 本記事はすべての機能を網羅しているわけではありませんが、ほとんどの機能をカバーしているはずです。 🔗 debugを使うメリット 個別の機能を解説する前に、debugを使うメリットについて簡単に触れておきたいと思います。 1. 出力がカラー化されている 2. メソッドやブロックの引数をバックトレース
morimorihogeです。涼しくなってようやく生きていける感じになって何よりです。 今回はruby/debugに新しく導入されたChrome Devtools連携リモートデバッグ機能を動かしてみたので、そちらを紹介してみようと思います。 ことの起こり 新しいRuby標準デバッガとして開発が進んでいるruby/debugですが、先日こんなTweetがありました。 debug.gem and Chrome browser integration. Thanks Ono-san! pic.twitter.com/3aUdH2zbEo — _ko1 (@_ko1) October 14, 2021 なにこれすごくない!?と思い、今回の記事を書くに至りました。 動きとしては、デバッガのコンソールで open chrome コマンドを実行するとURLが表示され、そのURLにChromeでアクセスす
ざっくりと書いたので、何かの参考にどうぞ Rails の問題かどうか、ログを調べる あなたのRails アプリが、例えばブラウザからのリクエストに対して何か応答する場合、リクエスト情報はRails のアプリケーションプログラムに到達する前にHTTP サーバのプログラムを通ります。 ですので、HTTP サーバがRails にリクエスト情報を渡さなかった場合、もしくはリクエストがHTTP サーバにすら到達しなかった場合は、当然Rails プログラムは動きません。 ということでまずは、リクエストがRails に到達しているかをログから調べましょう。 ログ デフォルトでは、development 環境の Rails のログは log/development.log に出ます。 ログ見るときの基本的なことですが、tail コマンドの f オプションで、追加行が随時流れてくるようにしてみましょう ここ
初めに 今までbinding.pryでデバックしていたのですが、下記の手順を踏むのでデバックに時間がかかる。 処理を止めたい所にbinding.pryを打ち込む 処理を止める。 確認後binding.pryを消す。 次の処理を見たい時はこれを繰り返す。 VScodeでデバックすると 止めたい処理の所にブレイクポイントを貼る(複数貼る事が出来る。) デバックの開始ボタンを押す。 3.処理を止める。 となり、binding.pryを書かない事、複数箇所ブレイクポイントを貼る事が出来るので、効率化を測れる。 インストール 下記を記述してインストール - ruby-debug-ide - debase
ruby/debug と連携してデバッグを行える VSCode extension が出てるので試す。 marketplace.visualstudio.com github.com 前提 $code -v 1.57.0 b4c1bd0a9b03c749ea011b06c6d2676c8091a70c x64 $ruby -v ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin19] 準備 debug はプレリリース版をインストールしてねと README にあるので従う。 gem install debug --pre ためしに以下のようなコードを書いてブレークポイントを貼ってみる class A attr_accessor :x end def main a = A.new a.x = 2 puts a.x end
環境:rails 4.2.0 Rails でリクエストの HTTP ヘッダはrequest.headersから取得できる。 すべてログに出力するなら # すべてログに出力する request.headers.sort.map { |k, v| logger.info "#{k}:#{v}" } 個別に取得するなら # ユーザーエージェントを取得する request.headers[:HTTP_USER_AGENT] request.envからでも取得できる。 # ユーザーエージェントを取得する request.env['HTTP_USER_AGENT'] 今回やりたいことはクライアント側から HTTP ヘッダに API のバージョンを埋め込んでリクエストしてくるので、すべてのリクエストの API バージョンを取り出してログに出力したい。 リクエストのパラメータを curl で再現すると以下
掲題の願望を満たすために、調べていましたら、学びがありましたので、「結論」と、 その「過程からの学んだ4つのTIPS」をお届けしたいと思います。 結論 explain 使う。なので、もう興味を失った方はもう以下お読み頂く必要はないかと思います。。 SQLをスッキリみたいというささやかな願望 rais c 使います。Active Record 使います。発行されるSQLを見たいです。 irb(main):001:0> User.first User Load (0.1ms) SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT 1 => #<User id: 1, name: "name1", created_at: "2016-10-08 11:20:08", updated_at: "2016-10-08 11:20:
が書かれているので、ソースコード中のどこでもbyebugと書けばそこで停止してデバッグができる。 単体スクリプトの場合は3つのやり方がある。 自分は最近は1-2「ソースコードの中にbyebugを書く方法」を使っている。 1.byebug単体で使う 1-1.シェルからbyebug ファイル名で起動する 1-2.require 'byebug'し、ソースコードの中にbyebugと書くとそこがブレークポイントになる 2.pry-byebugを使う require 'pry'し、ソースコードの中にbinding.pryと書くとそこがブレークポイントになる byebug単体で使う場合と比べて利用できるコマンドが少ない カラー表示がうれしい listコマンドがない(pry自身の@コマンドで代用可) backtraceコマンドがない(pry自身のpry-backtraceコマンドで代用可) displa
Rails本の写経をdocker-composeで行なったときのTips。 TL;DR docker-composeで作ったRubyOnRailsコンテナでbinding.pryによるデバッグを行えるようにする。 前提 docker-composeでRails、Spring用のコンテナなど、複数コンテナを起動する形のRails環境を構築した。基本構成は以下の記事に習っている。 高速に開発できる Docker + Rails開発環境のテンプレートを作った 事前準備 Railsをデバッグ実行するために必要な設定ファイルの準備をする。 コンテナの標準入出力にアタッチするために、Dockerの設定をしておく。 docker-compose.yml ブレークポイントを貼るためのbinding.pryをするためのGemを追加する。 Gemfileはpry-railsの他にpry-byebugも追加して
概要 先日 dockerでrails5環境構築で開発環境を作りました。 で、やはり開発する上ではguiでstep実行できると楽だなと思い、 Visual Studio Codeを使ってRailsをデバッグ実行してみよう の記事を見つけたのでdocker-machine上で実行されているrailsに対して試してみようとしたところ、先日に引き続きハマり倒したのでその作業メモです。 目標のデバッグ環境 構築した dockerでrails5環境構築の環境は下記のような構成で動いています。 この環境でホストOS(osx)で実行しているVisual Studio Codeのデバッガでステップ実行したいわけです。 以下先日の「dockerでrails5環境構築」の状態からの変更点を記載していきます。 railsコンテナの設定 基本的には「Visual Studio Codeを使ってRailsをデバッグ実
Railsを書き始めた人が知っておくと役立つような、RubyとRailsの知識をまとめてみました。 環境はUbuntu 17.10で、Ruby 2.4.1のRails 5.1.3ですが、Macでもほとんど同じく操作ができるかと思います。 Rubyとの戦い方 この項目では、Railsとは関係のないRuby言語としての挙動やデバッグについて話していきたいと思います。Railsから勉強し始めた方だと、どこまでがRubyの挙動で、どこからがRailsの拡張なのか分からないという人も多いと思うので、とりあえず純粋なRubyのお話から初めます。 irbの使い方 まず初めにRubyのデバッガ(正しくはREPL)についてですが、Rubyをインストールしたら同時にirbというコマンドが入っていると思います。このirbを使用すると、Rubyのコードがパッと実行できて、ちょっとした疑問をすぐに解決できるようにな
Pryとは Rubyには、標準で付属されているirb(Interactive Ruby)というツールがあります。 consoleで、irbと入力するとirbが実行されます。 そこで、対話的にRubyの式を入力・実行することができます。 $ irb irb(main):001:0> 1 + 2 => 3 そして、Pryはirbの代替となるパワフルな対話ツールです。 なにがパワフルかというと次のようなことができます。 ドキュメントが見れる シンタックスハイライト デバッグができる(binding.pryをソース二記載するとブレイクポイントになる) $ pry [1] pry(main)> ls # 現在のスコープの変数とメソッドを表示 self.methods: inspect to_s locals: _ __ _dir_ _ex_ _file_ _in_ _out_ _pry_ 動作確認
皆さん、Railsの開発でデバッガ使ってますか? 私は最近ようやく使うようになりました。 それまでは、Rubyistなら誰もがやっているであろう、ppデバッグ(ppで変数を表示)のみでデバッグを行なっていました。 C#でプログラムを開発していた頃は、 「デバッガ無しで開発とかありえない!大きなプロジェクトでppデバッグとか、そんな手法使えるわけないだろ」 と思っていましたが、Rubyだとデバッガ無しでも案外なんとかなってしまいます。 ppを埋め込んで変数を表示、などもお手軽にできるのが、軽量言語の素晴らしい所でもあると思います。 しかし、流石にプロジェクトの規模が大きくなるに連れて、ppデバッグだけではプログラムの流れを追いにくい、という問題に直面していました。 エラーがどこで発生したのかを確認するために、ppを至る所に埋め込んでデバッグ。そんな手法に限界を感じていた、ある日、同じプロジェ
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く