Mastering Ruby Debugging: From puts to Professional Tools

Dmitry Pogrebnoy

Hello, Ruby developers!

Debugging is an essential skill in software development, and in this post, we’ll be looking at how to investigate the behavior of Ruby code. As the RubyMine team, we’ve accumulated considerable expertise in creating tools for Ruby developers, and we’re excited to share our experience and knowledge with you.

Recently, at the EuRuKo 2024 conference, our team member Dmitry Pogrebnoy presented the Demystifying Debuggers talk. This blog post is the first in a series based on that presentation, aiming to provide you with valuable insights into debugging Ruby applications.

Every Ruby programmer inevitably encounters situations where their code doesn’t behave as expected. In these moments, we all wish we had an efficient way to pinpoint the problem and fix it quickly. That’s where debugging tools come into play.

In this post, we’ll explore various tools and approaches available to Ruby developers for investigating bugs. We’ll cover several classes of tools, each with its own strengths and weaknesses. Understanding the specifics of each tool will help you choose the most effective one for your particular debugging scenario.

To make our discussion more concrete, we’ll start with a real-world example of a bug we encountered in one of our internal Ruby projects. This case study will illustrate the importance of proper debugging techniques and set the stage for our exploration of debugging tools.

Whether you’re a seasoned Ruby developer or just starting out, this guide will help you sharpen your debugging skills and tackle bugs more efficiently. Let’s get started!

A real bug case from the RubyMine team

In the RubyMine team, our development efforts extend beyond the IDE itself. We’ve created several proprietary gems that enhance the IDE’s functionality. To share some insights, we’ll explore a real-world bug we encountered in one of these gems about a year ago. We’ve isolated and simplified the code sample to focus on the core issue.

Consider the following Ruby code:

def process(thing)
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)               # -> Element is Printable
process(BasicObject.new) # -> Element is Printable

At first glance, this process method seems straightforward. It aims to check whether the given argument has either a to_s or an inspect method. If either method exists, process should print “Element is Printable”; otherwise, it prints “Element is Not Printable”.

At the bottom, you can see two calls of this method with their outputs. The first call process(5) produces the message “Element is Printable”. This is correct. But the second call process(BasicObject.new) looks suspicious. It takes BasicObject as an argument, but prints “Element is Printable”. This is incorrect because the BasicObject instance does not respond to either of the methods we are looking for. So apparently this code contains a bug.

Let’s take a moment to examine the process method. Can you spot the bug?

defined?(thing.to_s || defined?(thing.inspect))

def process(thing)
 if defined?(thing.to_s) || defined?(thing.inspect)
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)               # -> Element is Printable
process(BasicObject.new) # -> Element is Not Printable

By sharing this real-world example, we hope to demonstrate that debugging is a crucial skill for all developers, regardless of experience level. It’s not just about fixing errors; it’s about understanding the intricacies of the language and writing more reliable code.

In more complex, production-level applications, such issues can be far more challenging to identify and resolve. This underscores the importance of robust debugging tools and techniques, which we’ll explore in the following sections.

Choosing the right tool

When it comes to debugging Ruby code, developers have several tools and approaches at their disposal. Let’s explore these options, starting with the basics and then moving on to more advanced techniques.

puts statements

The most basic debugging technique, requiring no setup or additional gems, is using puts statements. This method involves inserting print statements directly into your code to output variable values or execution flow information. While simple, it can be surprisingly effective for quick investigations.

Let’s apply this technique to our earlier example:

def process(thing)
 puts "defined? thing.to_s: #{defined? thing.to_s}"
 puts "defined? thing.inspect: #{defined? thing.inspect}"
 puts "defined? thing.to_s || defined? thing.inspect: #{
   defined? thing.to_s || defined? thing.inspect
 }"
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)
process(BasicObject.new)

This yields the following output:

defined? thing.to_s: method
defined? thing.inspect: method
defined? thing.to_s || defined? thing.inspect: expression
Element is Printable
defined? thing.to_s: 
defined? thing.inspect: 
defined? thing.to_s || defined? thing.inspect: expression
Element is Printable

The inconsistent output from these two methods calls with different arguments hints at where the problem might lie. We can see that, for BasicObject.new, both thing.to_s and thing.inspect are undefined, yet the condition still evaluates to true.

While basic puts statements are useful, several gems can make them more informative:

1. puts_debuggerer gem enhances puts output with the file name, line number, and content of this line.

For example:

require 'puts_debuggerer'
pd "defined? thing.to_s: #{defined? thing.to_s}"

Output:

[PD] example_puts_debuggerer.rb:5 in Object.process
   > pd "defined? thing.to_s: #{defined? thing.to_s}"
  => "Debug print 1: method"

2. awesome_print and similar gems provide more structured and readable output, especially useful for complex objects.

Generally puts statements are useful and might effectively help you with simple cases or when other tools don’t work for some reason. However, puts statements are really basic. They require modifying your source code every time you need to adjust an existing message or add a new one. They are usually not convenient to use because you need to restart the program whenever you modify what you are printing. 

Pros and cons of debugging using puts

Pros:

• Simple and quick to implement.
• Works in any Ruby environment.
• No additional tools or setup are required.

Cons:

• Requires modifying source code.
• Can clutter the code if overused.
• Forces you to restart the program if you want to change what you print.
• Limited information compared to more advanced tools.

While puts statements are invaluable for quick checks, they become less efficient for complex scenarios or when frequent changes are needed. In such cases, more advanced tools like interactive consoles or full-fledged debuggers offer greater flexibility and power.

Interactive consoles

Interactive consoles represent the next level in bug investigation tools for Ruby developers. The two primary options are IRB and Pry, both offering powerful introspection capabilities.

To utilize interactive consoles for debugging, you typically need to insert binding.irb or binding.pry calls into your source code. When the binding command is executed, an interactive console launches, providing access to the current context and the ability to execute arbitrary expressions in this context.

Let’s use IRB in our earlier example:

def process(thing)
 binding.irb
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5) # -> Element is Printable
process(BasicObject.new) # -> Element is Printable

When the code hits the binding.irb line, we’ll enter an interactive session:

From: 5_example_define_irb.rb @ line 2 :

    1: def process(thing)
 => 2:   binding.irb
    3:   if defined? thing.to_s || defined? thing.inspect
    4:     puts "Element is Printable"
    5:   else
    6:     puts "Element is Not Printable"
    7:   end

irb(main):001> defined? thing.to_s
=> nil
irb(main):002> defined? thing.inspect
=> nil
irb(main):003> defined? thing.to_s || defined? thing.inspect
=> "expression"
irb(main):004> exit
Element is Printable

This interaction allows us to examine the behavior of the condition’s individual parts, helping to pinpoint the issue.

Pros and cons of debugging using interactive consoles

Pros:

• More complex and flexible than puts statements.
• Partially allows for on-the-fly investigation.
• No need to predetermine all debugging output.

Cons:

• Still requires source code modification.
• Requires you to set predefined introspection points that cannot be changed at runtime.
• Forces you to restart the program if you want to change introspection points.

While interactive consoles offer more power than simple puts statements, they still have limitations. For complex debugging scenarios or when fine-grained control over execution is needed, full-featured debuggers provide even more capabilities.

Debuggers

Debuggers represent the pinnacle of tools available for investigating bugs in Ruby code. They offer capabilities far beyond simple puts statements and interactive consoles, providing full control over program execution. This powerful feature set allows developers to:

• Pause execution at a specified point using breakpoints.
• Inspect and modify variables in real time.
• Examine the call stack at every breakpoint.
• Step through code line by line.
• Evaluate expressions in the current context.

Let’s explore the three main debuggers for Ruby:

1. byebug gem

• Default debugger for Ruby 2.5.X, Ruby 2.6.X, Rails 5, and Rails 6.
• Comes with all the essential features you’d expect from a debugger like breakpoints, stepping, context, and stack introspection.
• For Rails applications, it requires modification of the application source code. You usually need to place a special call in your code to start the debugger at a certain place.
• Has noticeable performance overheads that make it less usable for complicated applications.

2. debug gem

• Supports only Ruby versions starting from 2.7.
• Has no visible performance overheads on supported Ruby versions.
• For Rails applications, debug, similar to byebug, requires modification of the application source code.
• Bundled with Ruby starting from version 3.1.

3. RubyMine debugger

• Supports Ruby versions 2.3 and later – so almost all possible versions of Ruby your application could use.
• Has no visible performance overheads on any of the supported versions of Ruby.
• No need to modify the code to use the debugger.
• Provides a user-friendly UI out of the box that streamlines debugging.

Despite its extensive feature set, debuggers might be difficult to use in some specific configurations. While debuggers are powerful, they’re most effective when combined with other debugging techniques. The choice of debugger often depends on your specific project and configuration requirements, Ruby version, and personal preferences.

Conclusion

Debugging in Ruby is both an art and a science, presenting challenges that can be overcome with the right tools. As we’ve explored in this post, Ruby developers have a rich toolkit at their disposal, ranging from simple puts statements to sophisticated debuggers.

Each debugging approach we’ve discussed has its strengths:

• puts statements offer quick, straightforward insights, ideal for simple issues or when other tools are unavailable.
• Interactive consoles like IRB and Pry provide a more dynamic environment, allowing for deep context introspection and complex expression evaluation.
• Full-fledged debuggers, such as the byebug and debug gems, as well as the RubyMine debugger, offer comprehensive control over program execution, enabling developers to dissect even the most intricate bugs.

The journey from encountering an unexpected bug to pinpointing its exact cause often requires a combination of these tools, along with methodical investigation and sometimes a bit of creative problem-solving. By understanding the strengths and limitations of each debugging tool, you can select the most appropriate approach for each unique situation.

As the RubyMine team, we’re particularly interested in how our debugging tools serve the Ruby community. We encourage you to explore the RubyMine debugger and share your experiences in the comments below or create an issue in the issue tracker. Your fellow developers will surely appreciate your insight.

Looking ahead, our next post will delve deeper into the inner workings of debuggers. We’ll explore their internal mechanisms and even tackle an exciting challenge: creating a basic debugger from scratch. This exploration will enhance your understanding of debugging tools and provide deeper insights into Ruby’s internals.

Meanwhile, take advantage of the advanced debugger in RubyMine. Download the latest RubyMine version from our website or via the free Toolbox App.

Remember, effective debugging is more than just finding and fixing errors – it’s about understanding your code at a fundamental level. Each debugging session is an opportunity to learn, improve, and write more robust Ruby code.

Stay curious, keep exploring, and happy debugging!

The RubyMine team

Subscribe to RubyMine Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!

Ruby デバッグ完全ガイド | puts から高度なツールまで徹底解説

Ryuji Owan

Ruby 開発者の皆さん、こんにちは！

デバッグはソフトウェア開発に欠かせないスキルです。この記事では Ruby コードの動作を調べる方法について取り上げます。 RubyMine チームには Ruby 開発者向けツールの開発に関する膨大なノウハウが蓄積されているため、その経験と知識を皆さんと共有したいと思います。

先日の EuRuKo 2024 カンファレンスでは、当チームのメンバーである Dmitry Pogrebnoy が「Demystifying Debuggers（デバッガーを解明する）」という講演を行いました。 このブログ記事は、そのプレゼンテーションに基づいて Ruby アプリケーションのデバッグに役立つインサイトを提供することを目的とした連載の最初の記事です。

あらゆる Ruby プログラマーにとって、コードが期待どおりに動作しない状況は避けられません。 そのような状況では、誰もが問題を素早く正確に特定して修正できる効率的な方法を望むものです。 そこで活用できるのが、デバッグツールです。

この記事では Ruby 開発者がバグの調査に使用できるさまざまなツールと手法を詳しく取り上げ、 いくつかの種類のツールについて、その強みと弱みと共に説明します。 各ツールの特徴を理解することで、特定のデバッグシナリオに最も効果的なツールを選択することができます。

JetBrains 社内のある Ruby プロジェクトで遭遇した実際のバグを例に挙げて具体的に説明したいと思います。 このケーススタディによって適切なデバッグ手法の重要性を説明し、デバッグツールを考察するための準備を整えます。

経験豊富な Ruby 開発者であれ初心者であれ、このガイドを活用してデバッグスキルを磨き、より効率よくバグに取り組むことができます。 では始めましょう！

RubyMine チームが体験した実際のバグ

RubyMine チームが取り組んでいるのは IDE 自体の開発だけにとどまりません。 IDE の機能を拡張する独自の gem をいくつも作成しています。 インサイトを共有するため、1 年ほど前にこのような gem の 1 つで見つかった実際のバグを詳しく取り上げます。 核心的な問題に注目できるようにするため、コードサンプルを切り離して単純化しました。

次の Ruby コードを見てみましょう。

def process(thing)
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)               # -> Element is Printable
process(BasicObject.new) # -> Element is Printable

この process メソッドは一見すると単純です。 特定の引数に to_s または inspect メソッドがあるかをチェックするのが目的です。 process はどちらかのメソッドが存在する場合に「Element is Printable」を出力し、どちらも存在しない場合に「Element is Not Printable」を出力するようになっています。

このメソッドの 2 つの呼び出しとその出力が一番下に書かれています。 最初の呼び出しである process(5) は「Element is Printable」メッセージを生成します。 これは正しい動作です。 しかし、2 つ目の process(BasicObject.new) という呼び出しは疑わしく思えます。 この呼び出しは BasicObject を引数に取っていますが、「Element is Printable」を出力しています。 BasicObject インスタンスは探しているどちらのメソッドにも対応していないため、この動作は誤っています。 つまり、このコードには明らかにバグがあります。

では、process メソッドを詳しく見てみましょう。 バグを見つけられますか？

defined?(thing.to_s || defined?(thing.inspect))

def process(thing)
 if defined?(thing.to_s) || defined?(thing.inspect)
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)               # -> Element is Printable
process(BasicObject.new) # -> Element is Not Printable

このような実例を紹介することで、デバッグが経験レベルを問わずあらゆる開発者に不可欠なスキルであること示したいと考えています。 これはエラーを修正するだけのスキルではなく、言語の複雑さを理解してより信頼性の高いコードを書くスキルです。

より複雑な本番環境レベルのアプリケーションでは、このような問題を特定して解決するのははるかに困難になります。 このことは、次のセクションで取り上げる堅牢なデバッグツールと手法の重要性を明確に示しています。

最適なツールを選ぶ

Ruby コードのデバッグに関しては、開発者がすぐに使用できるツールと手法がいくつかあります。 まずは基本的な選択肢を確認した後、より高度な手法を詳しく見ていきましょう。

puts ステートメントの使い方とその限界

最も基本的でセットアップや追加の gem を必要としないのは、puts ステートメントを使用するデバッグ手法です。 この手法では変数値や実行フローの情報を出力するため、コード内に直接 print ステートメントを挿入する必要があります。 単純な手法ではありますが、素早く調査するには驚くほど効果的です。

この手法を前の例に適用してみましょう。

def process(thing)
 puts "defined? thing.to_s: #{defined? thing.to_s}"
 puts "defined? thing.inspect: #{defined? thing.inspect}"
 puts "defined? thing.to_s || defined? thing.inspect: #{
   defined? thing.to_s || defined? thing.inspect
 }"
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5)
process(BasicObject.new)

これにより、以下の出力が得られます。

defined? thing.to_s: method
defined? thing.inspect: method
defined? thing.to_s || defined? thing.inspect: expression
Element is Printable
defined? thing.to_s: 
defined? thing.inspect: 
defined? thing.to_s || defined? thing.inspect: expression
Element is Printable

引数が異なる 2 つのメソッドからの出力に矛盾があり、問題がありそうな箇所が示されています。 BasicObject.new の場合、thing.to_s と thing.inspect のどちらも未定義であるにもかかわらず、条件が true に評価されているのが分かります。

基本的な puts ステートメントは便利ですが、いくつかの gem を使ってより多くの情報を得ることができます。

1. puts_debuggerer gem は、ファイル名、行番号、およびその行の内容を puts の出力に追加します。

例:

require 'puts_debuggerer'
pd "defined? thing.to_s: #{defined? thing.to_s}"

出力:

[PD] example_puts_debuggerer.rb:5 in Object.process
   > pd "defined? thing.to_s: #{defined? thing.to_s}"
  => "Debug print 1: method"

2. awesome_print とそれに類似する gem は、より構造化された読み取りやすい出力を提供します。複雑なオブジェクトには特に便利です。

puts ステートメントは概して便利であり、単純なケースや何らかの理由で他のツールでは対応できない場合には効果的ではありますが、 puts ステートメントは非常に基本的です。 既存のメッセージを調整したり、新しいメッセージを追加したりするたびにソースコードを変更しなければなりません。 出力内容を変更するたびにプログラムを再起動する必要もあるため、通常は利便性に欠けています。

puts を使用したデバッグの長所と短所

長所:

• 単純ですぐに実装できる。
• あらゆる Ruby 環境で機能する。
• 追加のツールやセットアップが不要である。

短所:

• ソースコードの変更が必要である。
• 使いすぎるとコードが乱雑になる。
• 出力内容を変更する際にはプログラムの再起動が必要になる。
• より高度なツールに比べて情報量が限定的である。

puts ステートメントは素早く確認する場合には非常に有益ですが、複雑なシナリオの場合や頻繫な変更が必要な場合にはあまり効率的ではありません。 そのような場合には、対話型コンソールやフル機能のデバッガーなどのより高度なツールを使用することで、さらに優れた柔軟性と性能を得られます。

対話型コンソールを使ったデバッグ

Ruby 開発者にとって、対話型コンソールは次のレベルのバグ調査ツールと言えます。 主な選択肢としては IRB と Pry の 2 つがあり、どちらも強力なイントロスペクション機能を備えています。

対話型コンソールをデバッグに使用する場合、一般的にはソースコードに binding.irb または binding.pry 呼び出しを挿入する必要があります。 バインディングのコマンドが実行されると対話型コンソールが起動し、現在のコンテキストにアクセスし、そのコンテキスト内で任意の式を実行できるようになります。

前の例で IRB を使用してみましょう。

def process(thing)
 binding.irb
 if defined? thing.to_s || defined? thing.inspect
   puts "Element is Printable"
 else
   puts "Element is Not Printable"
 end
end

process(5) # -> Element is Printable
process(BasicObject.new) # -> Element is Printable

コードが binding.irb の行に到達すると、対話型セッションが始まります。

From: 5_example_define_irb.rb @ line 2 :

    1: def process(thing)
 => 2:   binding.irb
    3:   if defined? thing.to_s || defined? thing.inspect
    4:     puts "Element is Printable"
    5:   else
    6:     puts "Element is Not Printable"
    7:   end

irb(main):001> defined? thing.to_s
=> nil
irb(main):002> defined? thing.inspect
=> nil
irb(main):003> defined? thing.to_s || defined? thing.inspect
=> "expression"
irb(main):004> exit
Element is Printable

この対話を通して条件の各部分の動作を調べ、問題を特定することができます。

対話型コンソールを使用したデバッグの長所と短所

長所:

• puts ステートメントよりも複雑で柔軟である。
• その場での調査が部分的に可能である。
• すべてのデバッグ出力を事前に決める必要がない。

短所:

• ソースコードの変更が必要であることには変わりない。
• イントロスペクション箇所を事前に定義しておく必要があり、実行時に変更できない。
• イントロスペクション箇所を変更する際にはプログラムの再起動が必要になる。

対話型コンソールの場合は単純な puts ステートメントよりも高い性能を得られますが、制限がなくなるわけではありません。 たとえば、複雑なデバッグシナリオの場合や実行を細かく制御する必要がある場合、フル機能搭載のデバッガーであればさらに多くの機能を使用できます。

RubyMine デバッガーで効率的にバグ修正

デバッガーは、Ruby コードのバグ調査に使用できるツールの中では最高峰のものです。 単純な puts ステートメントと対話型コンソールをはるかに超える機能を備えており、プログラムの実行を完全に制御できます。 開発者はこの強力な機能セットを使用して以下の操作を行えます。

• ブレークポイントを使用して特定箇所で実行を停止する。
• 変数をリアルタイムに検査して変更する。
• 各ブレークポイントでコールスタックを調べる。
• コード行単位でステップ実行する。
• 現在のコンテキストの式を評価する。

Ruby 用の主な 3 つのデバッガーを詳しく見てみましょう。

1. byebug gem

• Ruby 2.5.X、Ruby 2.6.X、Rails 5、および Rails 6 用のデフォルトのデバッガー。
• ブレークポイント、ステップ実行、コンテキスト、スタックイントロスペクションなど、デバッガーに求められる基本機能がすべて備わっている。
• Rails アプリケーションの場合、アプリケーションのソースコードを変更する必要がある。 通常はコード内の決まった箇所にデバッガーを起動する特殊な呼び出しを書く必要がある。
• 複雑なアプリケーションでは利便性が低下するほどの顕著なパフォーマンスオーバーヘッドがある。

2. debug gem

• Ruby バージョン 2.7 以降のみをサポートしている。
• サポート対象の Ruby バージョンではパフォーマンスオーバーヘッドがない。
• Rails アプリケーションの場合、byebug と同様に debug ではアプリケーションのソースコードを変更する必要がある。
• Ruby バージョン 3.1 以降にバンドルされている。

3. RubyMine デバッガー

• Ruby バージョン 2.3 以降をサポートしている。アプリケーションが使用する可能性のあるほぼすべての Ruby バージョンをサポートしている。
• サポート対象のすべての Ruby バージョンでパフォーマンスオーバーヘッドがない。
• コードを変更せずにデバッガーを使用できる。
• デバッグを合理化する使いやすい UI が初期状態で備わっている。

デバッガーには広範な機能セットが備わっていますが、一部の特定の構成では使いにくい場合があります。 デバッガーは強力ですが、他のデバッグ手法と併用すると最大限の効果を得られます。 多くの場合、デバッガーの選択は特定のプロジェクトと構成要件、Ruby のバージョン、および個人の好みによって決まります。

まとめ

Ruby でのデバッグはスキルと科学であり、適切なツールで克服できる課題があります。 この記事で取り上げたように、単純な puts ステートメントから高性能なデバッガーまで、Ruby 開発者には使用可能なツールキットが豊富に提供されています。

ここで説明したデバッグ手法にはそれぞれに長所があります。

• puts ステートメントは明確なインサイトを素早く提供するため、単純な問題や他のツールを使用できない場合に最適です。
• IRB や Pry などの対話型コンソールではより動的な環境を得られるため、深いコンテキストのイントロスペクションや複雑な式の評価が可能です。
• byebug gem や debug gem、RubyMine デバッガーなどのフル機能搭載のデバッガーではプログラムの実行を包括的に制御できるため、開発者はどんなに複雑なバグでも解析できます。

予期しないバグを発見して正確な原因を特定するまでは、このようなツールを組み合わせて使用して体系的な調査を行うのが一般的で、時には創造力を駆使して問題を解決する必要があります。 各デバッグツールの長所と制限を理解することで、それぞれの固有の状況に最適な手法を選ぶことができます。

RubyMine チームは、弊社のデバッグツールが Ruby コミュニティでどのように活用されているかに特に関心を持っています。 ぜひ RubyMine デバッガーを詳しくお試しになり、下のコメント欄で体験を共有していただくか、課題トラッカーに課題を作成してください。 あなたのインサイトは他の開発者の役に立つはずです。

次回の記事では、デバッガーの内部の処理についてさらに詳しく説明します。 内部の仕組みを詳しく見ながら、基本的なデバッガーをゼロから作成するという刺激的なチャレンジにも取り組みます。 その説明を通じてデバッグツールの理解を強化し、Ruby の内部処理に関するより深いインサイトを得られるでしょう。

それまでは、RubyMine の高度なデバッガーを活用してください。 最新の RubyMine バージョンは弊社ウェブサイトか無料の Toolbox App からダウンロードできます。

単にエラーを見つけて修正するだけでは効果的なデバッグは行えません。基礎レベルのコードを理解することが重要です。 各デバッグセッションは、学習、改善、およびより堅牢な Ruby コードを書くための機会です。

好奇心を保ち、探究し続け、デバッグを楽しみましょう！

RubyMine チーム一同より

オリジナル（英語）ブログ投稿記事の作者：

Dmitry Pogrebnoy

Subscribe to RubyMine Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!