DEV Community: Stan Lo

From byebug to ruby/debug

Stan Lo — Wed, 10 Aug 2022 15:38:25 +0000

Switching to a new debugger and potentially changing your debugging process could be scary. So I hope this post can help you get familiar with ruby/debug and determine whether to switch to it.

(In the rest of the article, I'll use debug to refer to ruby/debug)

Disclaimers:

I'm not as experienced with byebug as with debug. So please let me know if I listed incorrect/outdated information.
Its purpose is to give a higher-level comparison. To learn more about debug's specific usages, please check its official documentation.
It doesn't contain all the features but should already cover most of them.

Advantages of `debug`

Before we get into individual features, I want to quickly mention some advantages of debug:

Colorized output
Backtrace with method/block arguments
Immune from the compatibility issue with Zeitwerk
Powerful breakpoints and tracers
Convenient remote debugging and VSCode integration
- Setting it up with VSCode

Disadvantages of `debug`

Less flexible on thread control
Doesn't work well with Fiber yet
Doesn't have pry integration like pry-byebug
No per-project configuration

`byebug` vs `debug`

Installation

(Although Ruby 3.1 comes with debug v1.4, I recommend always using its latest release)

	byebug	debug
Supported Ruby version	2.5+	2.6+
Gem install	`gem install byebug`	`gem install debug`
Bundler	`gem "byebug"`	`gem "debug"`
Dependencies	No	`irb`, `reline`
Has C extension	Yes	Yes

Start Debugging

	byebug	debug
Via executable	`byebug foo.rb`	`rdbg foo.rb`
Via debugger statement	`byebug`	`binding.break`, `binding.b`, `debugger` (the same)
Via requiring	No	`require "debug/start"`

User Experience Features

	byebug	debug
Colorizing	No	Yes
Command history	Yes	Yes
Help command	`h[elp]`	`h[elp]`
Edit source file	`edit`	`edit`

Evaluation

Code evaluation in REPL is more or less the same between byebug and debug, that is:

If the expression doesn't match a console command, like my_method(arg), it'll be evaluated as Ruby code
If the expression matches a console command, like n, you can use console commands to evaluate it

	byebug	debug
Execute debugger commands	`<cmd>`	`<cmd>`
Avoid expression/command conflicts	`eval <expr>`	`pp <expr>`, `p <expr>`, or `eval <expr>`

Flow Control & Frame Navigation

debug provides the same stepping commands as byebug does. So byebug users can switch to debug without learning new behaviors.

	byebug	debug
Step in	`s[tep]`	`s[tep]`
Step over	`n[ext]`	`n[ext]`
Finish	`fin[ish]`	`fin[ish]`
Move to `<id>` frame	`f[rame] <id>`	`f[rame] <id>`
Move up a frame	`up`	`up`
Move down a frame	`down`	`down`
Move up n frames	`up <n>`	No
Move down n frames	`down <n>`	No
Continue the program	`c[ontinue]`	`c[ontinue]`
Quit the debugger	`q[uit]`	`q[uit]`
Kill the program	`kill`	`kill`

Thread Control

As previously mentioned, debug stops all threads when suspended and doesn't allow per-thread management at the moment. So it has simpler thread-related commands.

	byebug	debug
Thread suspension	Only the current thread	All threads
List all threads	`th[read] l`	`th[read]`
Switch to thread	`th[read] switch <id>`	`th[read] <id>`
Stop a thread	`th[read] stop <id>`	No
Resume a thread	`th[read] resume <id>`	No

Breakpoint

Although byebug already has decent breakpoints support, debug takes it to another level by:

Allowing breakpoints to execute commands with pre: and do: options
Supporting call-location-based triggering condition with the path: option
Supporting specialized catch and watch breakpoints

Setting Breakpoints

	byebug	debug
On line	`b[reak] <line>`	`b[reak] <line>`
On file:line	`b[reak] <file>:<line>`	`b[reak] <file>:<line>`
On a method	`b[reak] <class>#<method>`	`b[reak] <class>#<method>`
With a condition	`b[reak] ... if <expr>`	`b[reak] ... if: <expr>`
With a path condition	No	`b[reak] ... path: /path/`
To run a command and continue	No	`b[reak] ... do: <cmd>`
To run a command before stopping	No	`b[reak] ... pre: <cmd>`
Exception breakpoint	No	`catch <ExceptionClass>`
Instance variable watch breakpoint	No	`watch <@ivar>`

Managing Breakpoints

	byebug	debug
List all breakpoints	`info breakpoints`	`b[reak]`
Set a breakpoint	`b[reak] ...`	`b[reak] ...`
Delete a breakpoint	`del[ete] <id>`	`del[ete] <id>`
Delete all breakpoints	`del[ete]`	`del[ete]`

Information

Backtrace

Backtrace in debug contains values of method call or block arguments. This small improvement can save you from inspecting them manually between frames.

The filtering support can help you focus on relevant frames and ignore the ones from frameworks or libraries.

	byebug	debug
Show backtrace	`where`, `backtrace`, `bt`	`backtrace`, `bt`
Displaying method/block arguments in backtrace	No	Yes
Filter backtrace	No	`bt /regexp/`
Limit the number of backtraces	No	`bt <n>`

Varibles/Constants

	byebug	debug
Show local varibales	`var local`	`info l`
Show instance variables	`var instance`	`info i`
Show global varibales	`var global`	`info g`
Show constants	`var const`	`info c`
Show only arguments	`var args`	No (included in `info l`)
Filter variables/constants by names	No	`info ... /regexp/`

Methods

While debug doesn't have a dedicated command to list an object's methods, it has a ls command that's similar to
irb or pry's.

	byebug	debug
`obj.methods`	`method instance obj`	No
`obj.methods(false)`	`method obj.class`	`ls obj`

Tracing

I will write another dedicated article to introduce debug's tracing functionalities, but I encourage you to already give them a try from time to time, especially:

trace exception - to monitor exceptions raised in your code. You may be surprised by the exceptions raised and rescued in your application under the surface.
trace object <expr> - to observe an object's activities: receiving a method call or being passed to a method call.

	byebug	debug
Line tracer	`set linetrace`	`trace line`
Global variable tracer	`tarcevar`	No
Allow multiple tracers	No	Yes
Method call tracer	No	`trace call`
Exceptions tracer	No	`trace exception`
Ruby object tracer	No	`trace object <expr>`
Filter tracing output	No	`trace ... /regexp/`
Disable tracer	`set linetrace false`	`trace off [tracer type]`
Disable the specific tracer	No	`trace off <id>`

Configuration

debug supports a wide range of configurations to make it fit your needs. But it doesn't support per-project RC files due to security concerns.

	byebug	debug
List all configs	No	`config`
Show a config	`show <name>`	`config show <name>`
Set a config	`set <name> <value>`	`config set <name> <value>`
RC file name	`.byebugrc`	`.rdbgrc` (or `.rdbgrc.rb` for Ruby script)
RC file locations	`$HOME` and project root	`$HOME`

Remote Debugging

Remote debugging functionality is becoming crucial as we start containerizing our development environment and don't always have direct standard IO access.
It's also crucial for connecting to different debugger clients like VSCode or Chrome.

So if you have needs in this area, migrating to debug is your best option.

	byebug	debug
Connect via TCP/IP	Yes	Yes
Connect via Unix Domain Socket	No	Yes
VSCode integration through Debug Adapter Protocol (DAP)	No	Yes
Chrome integration through Chrome DevTools Protocol (CDP)	No	Yes

Wrapping Up

To most users, switching from byebug to debug should take little effort. But the potential productivity gain from debug's features could be significant.

byebug is a great debugger and has served the community well for many years.
But as its development slows down (last release was 2 years ago) and debug receives constant updates from the Ruby core, the gap between them will only widen.

So adding debug to your toolbelt and exploring its powerful features will be a great productivity investment for the long term.

References

Setup ruby/debug with VSCode

Stan Lo — Sat, 09 Jul 2022 11:32:10 +0000

Do you know Ruby's official debugger ruby/debug provides out-of-box integration with VSCode? If you haven't tried it yet or having difficulty making it work, I hope this short post will help you set it up.

Basic Setup

Install the VSCode rdbg extension in VSCode
Create the launch.json file
1. Click Run and Debug button on the left side
2. Click create a launch.json file - this is quite small and under To customize Run and Debug
3. Save the created launch.json
Put gem "debug", require: false in your Gemfile and run bundle install

Debug Simple Ruby Script

If you want to debug a simple Ruby script, you can follow these steps.

Debug Rails/Web Applications

If you want to debug a Rails/web application, do these instead:

Open the files in VSCode and add some breakpoints.
Start your program with the rdbg executable - bundle exec rdbg --open -n -c -- bundle exec rails s
- --open or -O means starting the debugger in server mode
- -n means don't stop at the beginning of the program, which is usually somewhere at rubygems, not helpful
- -c means you'll be running a Ruby-based command
Go back to VSCode's Run and Debug panel, you should see a grean play button
Click the dropdown besides the button and select Attach with rdbg
Click the play button
It should now connect the VSCode to the debugger
- If it stops at somewhere in your web server (like puma). Hit continue or F5. This will be resolved in the next 1.6.0 release.
Send some requests and it should stop at your breakpoints

Video

I also have built this repl.it to let you try out ruby/debug's console commands in your browser (it'll only take you 5 minutes).

If you want to see more articles/tips about the powerful features ruby/debug has, you can follow me on Twitter 🙂

A Sneak Peek of Ruby's New Debugger!

Stan Lo — Thu, 29 Jul 2021 15:22:16 +0000

ruby / debug

Debugging functionality for Ruby

debug is Ruby's new debugger and will be included in Ruby 3.1. Since I've been both contributing to and using it for a while, I feel it's time to give you guys a sneak peek before its 1.0 release 🙂

(Since it's not officially released yet, any feature mentioned in this article could still be modified/removed in the released version)

(Update: The project's lead developer @ko1 has started a blog series about the debugger. Please also check it 😉)

debug.gem blog: initial commit

Koichi Sasada ・ Jul 31 '21

#ruby #debugger

Introduction

As I have mentioned, it's planned to be a standard library of Ruby 3.1. And currently, you can install it as a gem, like:

$ gem install debug --pre

# Gemfile
# it's under active development, so I suggest using GitHub as source when possible
gem "debug", github: "ruby/debug"

Functionality-wise, debug is similar to the famous GDB debugger and Ruby's byebug gem. It provides a rich set of debug commands and has some unique features.

Quoted from its README:

New debug.rb has several advantages:

-   Fast: No performance penalty on non-stepping mode and non-breakpoints.
-   Remote debugging: Support remote debugging natively.
    -   UNIX domain socket
    -   TCP/IP
    -   VSCode/DAP integration (VSCode rdbg Ruby Debugger - Visual Studio Marketplace)
-   Extensible: application can introduce debugging support with several ways:
    -   By `rdbg` command
    -   By loading libraries with `-r` command line option
    -   By calling Ruby's method explicitly
-   Misc
    -   Support threads (almost done) and ractors (TODO).
    -   Support suspending and entering to the console debugging with `Ctrl-C` at most of timing.
    -   Show parameters on backtrace command.

And these are my favorite features:

It's colorized.

When showing backtrace with the backtrace command, it also shows method arguments, block arguments, and the return value.

=>#0    Foo#forth_call(num1=20, num2=10) at target.rb:20 #=> 30
  #1    block {|ten=10|} in second_call at target.rb:8

It's possible to script your debug commands with binding.break and reduce manual operations. (See the combinations section for examples)
There are several commands to set breakpoints that trigger under different conditions, like break, catch, and watch.

`binding.break` (alias: `binding.b`)

If you're a heavy pry user like me, you can use a familiar binding.break (or just binding.b) to kick off the debug session as usual.

But binding.break is actually more powerful than binding.pry, because it can take commands!

For example:

binding.b(do: "catch CustomException") - debugger will execute the command (catch customExeption) and continue the program.
binding.b(pre: "catch CustomException") - debugger will execute the command (catch customExeption) and stop at the line.

(To execute multiple commands, use ;; as the separator: "cmd1 ;; cmd2 ;; cmd3")

Fequently Used Commands

The new debugger has many powerful commands. And here are the ones I use the most:

`break` (alias: `b`)

class A
  def foo; end
  def self.bar; end
end

class B < A; end
class C < A; end

B.bar
C.bar

b1 = B.new
b2 = B.new
c = C.new

b1.foo
b2.foo
c.foo

Basic Usages

b A#foo - stops when b1.foo, b2.foo, and c.foo is called
b A.bar - stops when B.bar and C.bar is called
b B#foo - stops when b1.foo and b2.foo is called
b B.bar - stops when B.bar is called
b b1.foo - stops when b1.foo is called

Commands

b b1.foo do: cmd - executes cmd when b1.foo is called but doesn't stop
b b1.foo pre: cmd - executes cmd when b1.foo is called and stops

`catch`


class FooException < StandardError; end
class BarException < StandardError; end

def raise_foo
  raise FooException
end

def raise_bar
  raise BarException
end


raise_foo
raise_bar

catch StandardError - stops when any instance of StandardError is raised, including FooException and BarException
catch FooException - stops when FooException is raised

`backtrace` (alias `bt`)

Example Output:

=>#0    Foo#forth_call(num1=20, num2=10) at target.rb:20 #=> 30
  #1    block {|ten=10|} in second_call at target.rb:8
  #2    Foo#third_call_with_block(block=#<Proc:0x00007f9283101568 target.rb:7>) at target.rb:15
  #3    Foo#second_call(num=20) at target.rb:7
  #4    Foo#first_call at target.rb:3
  #5    <main> at target.rb:23

bt - shows all frames on the stack
bt 10 - only shows the first 10 frames
bt /my_lib/ - only shows the frames with path that matches my_lib

`outline` (alias `ls`)

Similar to the ls command in irb or pry.

`binding.b` + Command Combinations

`binding.b(do: "b Foo#bar do: bt")`

It allows you to inspect a method call's backtrace without touching the method definition or typing commands manually.

Script:

binding.b(do: "b Foo#bar do: bt")

class Foo
  def bar
  end
end

def some_method
  Foo.new.bar
end

some_method

Output:

DEBUGGER: Session start (pid: 75555)
[1, 10] in target.rb
=>    1| binding.b(do: "b Foo#bar do: bt")
      2|
      3| class Foo
      4|   def bar
      5|   end
      6| end
      7|
      8| def some_method
      9|   Foo.new.bar
     10| end
=>#0    <main> at target.rb:1
(rdbg:binding.break) b Foo#bar do: bt
uninitialized constant Foo
#0  BP - Method (pending)  Foo#bar do: bt
DEBUGGER:  BP - Method  Foo#bar at target.rb:4 do: bt is activated.
[1, 10] in target.rb
      1| binding.b(do: "b Foo#bar do: bt")
      2|
      3| class Foo
=>    4|   def bar
      5|   end
      6| end
      7|
      8| def some_method
      9|   Foo.new.bar
     10| end
=>#0    Foo#bar at target.rb:4
  #1    Object#some_method at target.rb:9
  # and 1 frames (use `bt' command for all frames)

Stop by #0  BP - Method  Foo#bar at target.rb:4 do: bt
(rdbg:break) bt
=>#0    Foo#bar at target.rb:4
  #1    Object#some_method at target.rb:9
  #2    <main> at target.rb:12

`binding.b(do: "b Foo#bar do: info")`

It allows you to inspect a method's environment (e.g. argument) when called:

Script:

binding.b(do: "b Foo#bar do: info")

class Foo
  def bar(a)
    a 
  end
end

def some_method
  Foo.new.bar(10)
end

some_method

Output:

DEBUGGER: Session start (pid: 75924)
[1, 10] in target.rb
=>    1| binding.b(do: "b Foo#bar do: info")
      2|
      3| class Foo
      4|   def bar(a)
      5|     a
      6|   end
      7| end
      8|
      9| def some_method
     10|   Foo.new.bar(10)
=>#0    <main> at target.rb:1
(rdbg:binding.break) b Foo#bar do: info
uninitialized constant Foo
#0  BP - Method (pending)  Foo#bar do: info
DEBUGGER:  BP - Method  Foo#bar at target.rb:4 do: info is activated.
[1, 10] in target.rb
      1| binding.b(do: "b Foo#bar do: info")
      2|
      3| class Foo
      4|   def bar(a)
=>    5|     a
      6|   end
      7| end
      8|
      9| def some_method
     10|   Foo.new.bar(10)
=>#0    Foo#bar(a=10) at target.rb:5
  #1    Object#some_method at target.rb:10
  # and 1 frames (use `bt' command for all frames)

Stop by #0  BP - Method  Foo#bar at target.rb:4 do: info
(rdbg:break) info
%self = #<Foo:0x00007fdac491c200>
a = 10

I'm a Rails developer, so I usually put the combination code at the beginning of a controller action, like:

class SomeController < ApplicationController
  def index
    binding.b(pre: "b User#buggy_method do: info")
    # other code
  end
end

And then the debugger would execute the command and/or stops at the method I expected.
I don't need to jump between multiple files for adding binding.pry or puts anymore 😎

A Small Drawback

However, the new debugger isn't all perfect (yet). Unlike in byebug or pry, you can't directly evaluate a Ruby expression in the debug session:

(rdbg) 1 + 1
unknown command: 1 + 1

To evaluate an expression, you need to use p or pp command:

(rdbg) p 1 + 1
=> 2

But according to the project's maintainer @ko1's 'comment, expression evaluation may be supported before the official 1.0 release.

Update

With https://github.com/ruby/debug/pull/227 being merged, this problem doesn't exist anymore 😉

Final Thoughts

Although it's not officially released yet, I've started using it at work daily. And I believe it'll soon become an must-have tool in every Rubyists' toolbox. So if you're curious about its capability, I encourage to give it a try 😉

Fixing issues in OSS is easier than you think

Stan Lo — Thu, 12 Nov 2020 07:17:28 +0000

Issue fixing is the most common way to contribute to open source projects. And I believe many of you want to contribute to OSS projects in this way. But the idea of solving an issue on your own can also be intimidating. For example, when you open up an issue report and try to work on it, you may find it difficult to start because

You don't have sufficient information about the bug
You don't know how to reproduce it
You are not sure if that's really a bug of the project or just an unsupported use case

I don't know if the above scenarios have happened to you before, but I surely experienced it a lot in my earlier days as a contributor. At that time, it prevented me from committing to an issue because I was afraid that I couldn't finish on my own.

But who said that we need to fix an issue alone? Although solving an issue on your own is surely a great thing. However, it's also often to see people solving issues collaboratively. So in this post, I want to show you how to break down an issue and make your contribution in different ways.

So you want to fix an issue?

Regardless of the issue's subject, here are the first few things you should do in most of the projects:

Clone the project
Follow the contributing guideline to set up the project (install dependencies, required services...etc.)
Run the test suite and make sure they pass locally. If some of them failed, it could mean:
- You haven't completed the setup or didn't do it correctly
- There's a compatibility issue between your environment and the project, which could be another contributing opportunity

Then depending on the issue, you might be able to start working on it right away. But it's also possible that you meet some obstacles and don't know how to proceed, as I mentioned earlier:

You don't have sufficient information about the issue
You don't know how to reproduce it
You are not sure if that's really a bug of the project or just an unsupported use case

Those obstacles, however, are actually the thing you can and should contribute to. Just answering any of the questions will make the issue one step further to be solved, either by you or others.

But what if I don't get any credits from it

I know most people contribute to open source projects with the hope of helping their career growth with some nice showcases to put on the CV. I'm no exception. So I understand that spending dozens of hours to help others landing a bug fix PR doesn't feel like a good investment.

But here's how I look at this: Many companies still use whiteboard interviews or homework assignments to test their candidates' problem-solving skills. However, since most of the companies aren't so great or have enough resources at hiring, those processes designed by them don't necessarily demonstrate your real capability.

So why not using the issues you helped solving as evidence? Any issue you help solving can be a great proof of your conversation and coordination skills, whether it's a reproductions script you wrote or a comment to express your opinion on the solution. Sometimes, those non-coding contributions are as valuable as your PRs. Like this comment

If you agree with my point above, let me show you how to contribute to an issue under different scenarios.

Not having sufficient information about the issue

Sometimes, the issue description may not provide sufficient information about the issue itself or the requirements to reproduce it. And if the project maintainer(s) don't have time to go after them one by one, the issue could remain unhandled for a while.

Usually, a ready-to-solve issue should contain the following information:

The user's environment when encountering the issue, including
1. Project version (e.g., sentry-raven 3.1)
2. Language version (e.g., Ruby 2.6)
3. Operating system (e.g., MacOS 10.15.6)
4. The version of other important libraries (e.g., Rails 6.0)
The expected behavior
The actual behavior
Reproduction steps

So if you found any issue that lacks the above information, you can kindly ask the issue author to provide more info to let you start working on it. For example:

Hello @st0012, I'm interested in investigating this issue further, but I need more information to do so. Can you also tell me what Ruby version did you use when seeing the error? Thanks 😄

Usually, the author will reply rather quickly to move the issue forward. And once he/she has provided more information, you or other people can start working on it.

Not sure how to reproduce the issue

If an issue can't be reproduced, it can't be solved with confidence. So if you find the reproduction steps are missing from the issue, you can be the one that provides one by

Creating a minimal app that can reproduce the issue with the given (or fewer) reproduction steps so other people can have an actual app to see the bug happens.
Or writing a reproduction script that can demonstrate the problem just by executing it. A great example of this is Rails' bug report templates.
Best scenario: writing a new test case for it
- If you're certain the cause of the issue locates inside the project, this will be the most helpful thing to do.
- This could be hard because you'll also need to set up the project locally and make it runnable. But if you managed to do it, to you, the issue is more than halfway through!

Even if the author already provided reproduction steps, you can still try to reproduce the issue with a different setup, such as using a newer version of a library or Ruby to see if it still happens. This can help you and others find out the potential cause of the issue.

Validate the issue's cause

Even if the issue can be constantly reproduced, it doesn't necessarily mean it needs to be "fixed" for reasons like:

Not the expected usage of the project
Caused by something else:
- a conflict with other projects
- a bug in the dependencies

So you need to validate the issue by understanding the project's scope, its dependencies, and the user's use case. Sometimes this also requires having a discussion with the project maintainer and other users of the project.

You might feel like doing broad research in the step. But if you do it thoroughly, this will be the step you'll learn the most from. Here're the things you can do:

Dive into the codebase and locate the root cause and report what you've found in the comments
If the issue is caused by the project's bug, find the commit/PR that introduced it and share it in the comments. This will help tremendously. If it's a complicated issue, I also suggest you write down the paths you've visited during the investigation.
If you're already familiar with the project (e.g., you're a heavy user), provides your opinion about the issue. This will help the maintainer decide whether to fix it or not or how to fix it.

Fix It!

If the issue you're looking at already has a detailed description, a reproduction script, and has been verified as the bug of the project, why not be the one that fixes the issue? Especially when you're the one that completed the previous steps, you can now call yourself the expert on the issue should be the best candidate to fix it!

This part is pretty straightforward, as most of us fix bugs for a living 🙂. But I still want to provide some tips for you:

Since it's a bug fix, you should add test case(s) that will fail without the fix (unless there's a reason not to so). I suggest you write the test cases before making any code changes. TDD works pretty well when fixing bugs for open source projects.
Don't mix refactoring with bug fixes in the same commit. I know some refactorings might be inevitable for fixing the issue properly. So make sure you give the refactoring a standalone commit, which makes the code review a lot easier.
Be patient. Every maintainer will be grateful to see you help them fix a bug and will try to merge the fix as soon as possible. But most of the maintainers maintain the project in their free time (which is very limited), and they could be busy reviewing other PRs or fixing other issues. So you may not get a quick response to the PR you just opened. I know how frustrating it could be, but it doesn't mean they don't cherish the hard work you just made.
Make sure the maintainers can review your PR as easily as possible. This can be done by:
1. Making sure your PR pass the CI
2. Making sure your code follows the coding style guide of the project
3. Explaining the cause of the issue in detail. Like:
  - because method_a called method_b at file.rb:120 with the string "foo" under certain circumstances, it caused the baz method in Bar class to return the incorrect "xyz" result and caused this issue.
4. Depending on the nature of that issue, there could be multiple ways to fix it. So you may want to explain the approach you chose and why you think it's the best approach
  - since the method_b is a private method that is only called by method_a, I figure adding an argument check in method_a will be sufficient to prevent this from happening again.

The key concept is: make your PR's purpose clear, so even a busy maintainer can easily review the content.

Final Note

I'm not sure if you have noticed them, but the steps above actually make a full process of solving an issue. Each one of them helps understanding the project better from a different aspect. This means that even if you only make a partial contribution at a time, sooner or later, you'll be capable of solving an issue by yourself.

So I hope after reading this post, you're now more confident about making your first or next contribution to open source projects. It's really not that hard to do. And as a community, we really need your contribution to keep the projects moving forward!

Completely Remove Ruby 2.7's Default Bundler

Stan Lo — Sun, 09 Aug 2020 06:26:34 +0000

Ruby 2.7 comes with the default bundler gem, which always has 2.0+ version. This is a great default in general, especially to the beginners. But in some cases, like when using Rails 4, we want to keep the bundler version under 2.0 to avoid conflicts.

Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    rails (~> 4.2) was resolved to 4.2.11.3, which depends on
      bundler (< 2.0, >= 1.3.0)
  Current Bundler version:
    bundler (2.1.4)

However, it's not easy to rollback to a older version of bundler. Since the 2.0+ version will be installed as a default gem, simply uninstall it won't work:

$ gem uninstall bundler
=> Gem bundler-2.1.4 cannot be uninstalled because it is a default gem

And these tricks won't work either (at least they didn't work for me):

$ bundle -v
Bundler version 2.1.4

$ gem install bundler:1.17.3 --default
Successfully installed bundler-1.17.3 as a default gem
Done installing documentation for bundler after 0 seconds
1 gem installed

$ bundle -v
Bundler version 2.1.4

$ bundle config default 1.17.3
$ bundle -v
Bundler version 2.1.4

From all the references I can find, the only way to remove it is to delete the bundler-2.1.4.gemspec file from the gem path. The following commands did the trick for me:

$ gem env gempath
/Users/st0012/.gem/ruby/2.7.0:/Users/st0012/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0
$ ls /Users/st0012/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/specifications/**/bundler-*.gemspec
/Users/st0012/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/specifications/default/bundler-2.1.4.gemspec
$ rm /Users/st0012/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/specifications/**/bundler-2.1.4.gemspec
$ gem install bundler:1.17.3 --default
$ bundle -v
Bundler version 1.17.3

But what if we want to perform the same cleanup on CI (like travis-ci) too? Well, I wrote a script for you:

#!/usr/bin/env ruby

gempaths = `gem env gempath`.split(":")
gempaths.each do |gempath|
  # lookup bundler-*.gemspec files and delete them
  # this is the only way to completely cleanup default bundler
  # Note: the bundler gemspecs' paths are different for CRuby and JRuby
  Dir.glob(gempath.strip + "/specifications/**/bundler-*.gemspec").each { |p| File.delete(p) }
end

# Remember to make this file executable

Then you can add this to your CI config file (.travis.yml for example):

before_install:
  - ./cleanup_bundler
  - gem install bundler -v '1.17'

And that's it! I hope this short post can save you from pulling your hair for a few hours 😉

If you're a Rubyist and you like this post, please also check the debugging tools I wrote:

st0012 / object_tracer

ObjectTracer tracks objects and records their activities

st0012 / power_trace

Buff exception backtrace with local variables, passed in arguments and instance variables!

Replace A Rails Initializer

Stan Lo — Sun, 31 May 2020 05:59:38 +0000

Rails uses a series of initializers to initialize your application. While some of them might come from the gems you use, most of them are the Rails' built-in ones. And in some rare cases, you might need to customize some of them for special usages.

For example, I had to replace my app's set_routes_reloader_hook initializer (the one that generates routes for your application) to benchmark our route generation logic. And it took a while to figure out how to do it the right way.

So if you don't need to do this, that's totally normal. But if you do, this post is for you.

The Steps

In this post, I'll use the set_routes_reloader_hook initializer as our example. And the replacement will be done in 3 steps:

Identify the Initializer's Source
Register the New Initializer
Drop the Old Initializer

And finally, I'll show you how to reuse the original initializer's body instead of copy&paste the code.

Identify the Initializer's Source

When talking about replacing a Rails initializer, your first thought might be modifying the Rails::Application#initializers directly. But that won't work.

In Rails, Rails::Application#initializers actually consists of 3 initializer sources:

def initializers #:nodoc:
  Bootstrap.initializers_for(self) +
  railties_initializers(super) +
  Finisher.initializers_for(self)
end

So every time you call Rails::Application#initializers, it returns a new array of initializers, and the change made on it won't be applied to the rest of the app.

What we need to do instead, is to identify which source that our target initializer belongs to:

Rails::Application::Bootstrap.initializers_for(Rails.application).map(&:name).include?(:set_routes_reloader_hook) #=> false
Rails::Application.initializers_for(Rails.application).map(&:name).include?(:set_routes_reloader_hook) #=> false
Rails::Application::Finisher.initializers_for(Rails.application).map(&:name).include?(:set_routes_reloader_hook) #=> true

Now we can see that the set_routes_reloader_hook is defined in Rails::Application::Finisher.

Register the New Initializer

Because Rails executes initializers in the order they are defined, we need to make sure the new initializer is placed in the right place. So we need to use the target initializer as our index before dropping it. To do this, we can use the before or after argument when registering the new initializer:

# config/application.rb

require 'rails/all'

Rails::Application::Finisher.initializer :set_routes_reloader_hook_with_benchmark, after: :set_routes_reloader_hook do |app|
  # ....
end

Drop the Old Initializer

And then the last step: drop the target initializer

# config/application.rb

require 'rails/all'

Rails::Application::Finisher.initializer :set_routes_reloader_hook_with_benchmark, after: :set_routes_reloader_hook do |app|
  # ....
end

Rails::Application::Finisher.initializers.reject! { |i| i.name == :set_routes_reloader_hook }

Additional Tip: Reuse the Old Initializer

Since we're "replacing" the initializer instead of just dropping it or adding a new one, it means the new initializer may be very similar to the old one or just an extension of it. But because initializers aren't methods, we can't use super like

def set_routes_reloader_hook
  super
  # other stuff you want to do
end

If this is bothering you, here's a trick: We can extract the old initializer's block, and use instance_eval to evaluate it inside the new initializer


original_initializer_block = Rails::Application::Finisher.initializers.detect { |i| i.name == target_initializer }.block

Rails::Application::Finisher.initializer :new_initializer, after: target_initializer do |app|
  instance_eval(&original_initializer_block)
  # other stuff you want to do
end

Rails::Application::Finisher.initializers.reject! { |i| i.name == target_initializer }

Thank you for reading this post. If you like it, I also wrote some articles about debugging Rails applications/Ruby programs

Changing the Approach to Debugging in Ruby with TracePoint

Stan Lo for AppSignal ・ Apr 9 '20

#ruby #rails #webdev #beginners

Optimize Your Debugging Process With Object-Oriented Tracing and tapping_device

Stan Lo ・ Jan 21 '20

#showdev #rails #ruby #tutorial

I'm also working on a gem called tapping_device. It can help you debug Ruby programs more easily by making objects tell you what they do.
Not sure what it means? There are examples in the readme 👇

st0012 / object_tracer

ObjectTracer tracks objects and records their activities

Changing the Approach to Debugging in Ruby with TracePoint

Stan Lo — Thu, 09 Apr 2020 14:54:28 +0000

Ruby has always been known for the productivity it brings to its developers. Alongside features such as elegant syntax, rich meta-programming support, etc. that make you productive when writing code, it also has another secret weapon called TracePoint that can help you "debug" faster.

In this post, I'll use a simple example to show you 2 interesting facts I found out about debugging:

Most of the time, finding the bug itself isn't hard, but understanding how your program works in detail is. Once you have a deep understanding of this, you can usually spot the bug right away.
Observing your program down to the method call level is time-consuming, and is the major bottleneck of our debugging process.

Then, I'll show you how TracePoint could change the way we approach debugging by making the program "tell us" what it's doing.

Debugging Is about Understanding Your Program and Its Design

Let's assume we have a Ruby program called plus_1 and it's not functioning correctly. How do we debug this?

# plus_1.rb
def plus_1(n)
  n + 2
end

input = ARGV[0].to_i
puts(plus_1(input))

$ ruby plus_1.rb 1
3

Ideally, we should be able to address the bug in 3 steps:

Learn the expectations from the design
Understand the current implementation
Trace the bug

Learning the Expectations from the Design

What's the expected behavior here? plus_1 should add 1 to its argument, which is our input from the command line. But how do we "know" this?

In a real-world case, we can understand the expectations by reading test cases, documents, mockups, asking other people for feedback, etc. Our understanding depends on how the program is "designed".

This step is the most crucial part of our debugging process. If you don't understand how the program should work, you'll never be able to debug it.

However, there are many factors that can be part of this step, such as team coordination, development workflow, etc. TracePoint won't be able to help you with those, so we won't dwell on these problems today.

Understanding the Current Implementation

Once we've understood the expected behavior of the program, we need to learn how it functions at the moment.

In most cases, we need the following information to fully understand how a program works:

The methods called during the program's execution
The call and return order of the method calls
Arguments passed to each method call
Values returned from each method call
Any side effects that happened during each method call, e.g. data mutation or database requests

Let's describe our example with the above information:

# plus_1.rb
def plus_1(n)
  n + 2
end

input = ARGV[0].to_i
puts(plus_1(input))

$ ruby plus_1.rb 1
3

Defines a method called plus_1
Retrieves the input ("1") from ARGV
Calls to_i on "1", which returns 1
Assigns 1 to local variable input
Calls plus_1 method with input(1) as its argument. The parameter n now carries a value of 1
Calls + method on 1 with an argument 2, and returns the result 3
Returns 3 for step 5
Calls puts
Calls to_s on 3, which returns "3"
Passes "3" to the puts call from step 8, which triggers a side effect that prints the string to Stdout. Then it returns nil.

The description isn't 100% accurate, but it's enough for a simple explanation.

Addressing the Bug

Now that we've learned how our program should work and how it actually works, we can start looking for the bug. With the information we have, we can search for the bug by following the method calls upward (start from step 10) or downward (start from step 1). In this case, we can do it by tracing back to the method that returned 3 in the first place⁠—which is the 1 + 2 in step 6.

This Is Far from Reality!

Of course, we all know that real debugging isn't as simple as the example makes it out to be. The critical difference between real-life programs and our example is the size. We used 10 steps to explain a 5-line program. How many steps would we need for a small Rails app? It's basically impossible to break down a real program as detailed as we did for the example.
Without a detailed understanding of your program, you won't be able to track down the bug through an obvious path, so you'll need to make assumptions or guesses.

Information Is Expensive

As you probably already noticed, the key factor in debugging is how much information you have. But what does it take to retrieve that much information? Let's see:

# plus_1_with_tracing.rb
def plus_1(n)
  puts("n = #{n}")
  n + 2
end

raw_input = ARGV[0]
puts("raw_input: #{raw_input}")
input = raw_input.to_i
puts("input: #{input}")

result = plus_1(input)
puts("result of plus_1 #{result}")

puts(result)

$ ruby plus_1_with_tracing.rb 1
raw_input: 1
input: 1
n = 1
result of plus_1: 3
3

As you can see, we only get 2 types of information here: values of some variables and the evaluation order of our puts (which implies the program's execution order).

How much does this information cost us?

 def plus_1(n)
+  puts("n = #{n}")
   n + 2
 end

-input = ARGV[0].to_i
-puts(plus_1(input))
+raw_input = ARGV[0]
+puts("raw_input: #{raw_input}")
+input = raw_input.to_i
+puts("input: #{input}")
+
+result = plus_1(input)
+puts("result of plus_1: #{result}")
+
+puts(result)

Not only do we need to add 4 puts into the code, but, in order to print values separately, we also need to split our logic in order to access the intermediate states of some values. In this case, we got 4 additional outputs for the internal states with 8 lines of changes. That's 2 lines of changes for 1 line of output, on average! And since the number of changes grows linearly with the size of the program, we can compare it to an O(n) operation.

Why Is Debugging Expensive?

Our programs can be written with many goals in mind: maintainability, performance, simplicity, etc. but usually not for "Traceability", meaning, getting the values for inspection, which usually requires a modification of the code, e.g. splitting chained method calls.

The more the information you get, the more additions/changes you need to make to the code.

However, once the amount of information you get reaches a certain point, you won't be able to process it efficiently. So we either need to filter the information out or label it to help us understand it.

The more precise the information, the more additions/changes you need to make to the code.

Finally, because the work involves touching the codebase⁠—which can be very different between bugs (e.g. controller vs. model logic)⁠—it's hard to automate it. Even if your codebase is tracing-friendly (e.g. it follows "Law of Demeter" strictly), most of the time, you'll need to type different variable/method names manually.

(Actually, in Ruby, there are some tricks to avoid this⁠—like __method__. But let's not complicate things here.)

TracePoint: The Savior

However, Ruby provides us an exceptional tool that can largely reduce the cost: TracePoint. I bet most of you have already heard of it or used it before. But in my experience, not many people use this powerful tool in daily debugging practices.

Let me show you how to use it to collect information quickly. This time, we don't need to touch any of our existing logic, we just need some code before it:

TracePoint.trace(:call, :return, :c_call, :c_return) do |tp|
  event = tp.event.to_s.sub(/(.+(call|return))/, '\2').rjust(6, " ")
  message = "#{event} of #{tp.defined_class}##{tp.callee_id} on #{tp.self.inspect}"
  # if you call `return` on any non-return events, it'll raise error
  message += " => #{tp.return_value.inspect}" if tp.event == :return || tp.event == :c_return
  puts(message)
end

def plus_1(n)
  n + 2
end

input = ARGV[0].to_i
puts(plus_1(input))

If you run the code, you'll see:

return of #<Class:TracePoint>#trace on TracePoint => #<TracePoint:c_return `trace'@plus_1_with_trace_point.rb:1>
  call of Module#method_added on Object
return of Module#method_added on Object => nil
  call of String#to_i on "1"
return of String#to_i on "1" => 1
  call of Object#plus_1 on main
return of Object#plus_1 on main => 3
  call of Kernel#puts on main
  call of IO#puts on #<IO:<STDOUT>>
  call of Integer#to_s on 3
return of Integer#to_s on 3 => "3"
  call of IO#write on #<IO:<STDOUT>>
3
return of IO#write on #<IO:<STDOUT>> => 2
return of IO#puts on #<IO:<STDOUT>> => nil
return of Kernel#puts on main => nil

Our code is much more readable now. Isn't it amazing? It prints out most of the program execution with lots of details! We can even map it with my earlier execution breakdown:

Defines a method called plus_1
Retrieves the input ("1") from ARGV
Calls to_i on "1", which returns 1
Assigns 1 to local variable input
Calls plus_1 method with input(1) as its argument. The parameter n now carries a value 1
Calls + method on 1 with an argument 2, and returns the result 3
Returns 3 for step 5
Calls puts
Calls to_s on 3, which returns "3"
Passes "3" to the puts call from step 8, which triggers a side effect that prints the string to Stdout. And then it returns nil.

# ignore this, it's TracePoint tracing itself ;D
return of #<Class:TracePoint>#trace on TracePoint => #<TracePoint:c_return `trace'@plus_1_with_trace_point.rb:1>

  call of Module#method_added on Object         # 1. Defines a method called `plus_1`.
return of Module#method_added on Object => nil
  call of String#to_i on "1"                    # 3-1. Calls `to_i` on `"1"`
return of String#to_i on "1" => 1               # 3-2. which returns `1`
  call of Object#plus_1 on main                 # 5. Calls `plus_1` method with `input`(`1`) as its argument.
return of Object#plus_1 on main => 3            # 7. Returns `3` for step 5
  call of Kernel#puts on main                   # 8. Calls `puts`
  call of IO#puts on #<IO:<STDOUT>>
  call of Integer#to_s on 3                     # 9. Calls `to_s` on `3`, which returns `"3"`
return of Integer#to_s on 3 => "3"
  call of IO#write on #<IO:<STDOUT>>            # 10-1. Passes `"3"` to the `puts` call from step 8
                                                # 10-2. which triggers a side effect that prints the string to Stdout
3 # original output
return of IO#write on #<IO:<STDOUT>> => 2
return of IO#puts on #<IO:<STDOUT>> => nil
return of Kernel#puts on main => nil            # 10-3. And then it returns `nil`.

We can even say it's more detailed than what I said earlier! However, you may notice that steps 2, 4 and 6 are missing from the output. Unfortunately, they are not trackable by TracePoint for the following reasons:

2. Retrieves the input ("1") from ARGV
- ARGV and the following [] aren't considered as call/c_call at the moment
4. Assigns 1 to local variable input
- Currently, there's no event for variable assignments. We can (sort of) track it with line event + regex, but it won't be accurate
6. Calls + method on 1 with an argument 2, and returns the result 3
- Certain method calls like built-in + or attributes accessor methods aren't trackable at the moment

From O(n) to O(log n)

As you can see from the previous example, with proper usage of TracePoint, we can almost make the program "tell us" what it's doing. Now, because of the number of lines we need, TracePoint doesn't grow linearly with the size of our program. I'd say the whole process becomes an O(log(n)) operation.

Next Steps

In this article, I've explained the main difficulty with debugging. Hopefully, I've also convinced you of how TracePoint could be a game-changer. But if you try TracePoint right now, it'll probably frustrate you more than help you.

With the amount of information that comes from TracePoint, you'll soon be swamped by the noise. The new challenge is to filter out the noise, leaving valuable information. For example, in most cases, we only care about specific models or service objects. In these cases, we can filter calls by the receiver's class, like this:

TracePoint.trace(:call) do |tp|
  next unless tp.self.is_a?(Order)
  # tracing logic
end

Another thing to keep in mind is that the block you define for TracePoint could be evaluated tens of thousands of times. At this scale, how you implement the filtering logic can have a great impact on your app's performance. For example, I don't recommend this:

TracePoint.trace(:call) do |tp|
  trace = caller[0]
  next unless trace.match?("app")
  # tracing logic
end

For these 2 problems, I've prepared another article to let you know of some tricks and gotchas I found with some useful boilerplates for typical Ruby/Rails applications.

And if you find this concept interesting, I also created a gem called tapping_device that hides all the implementation hassles.

Conclusion

Debugger and tracing are both great tools for debugging, and we have been using them for many years. But as I've demonstrated in this article, using them requires many manual operations during the debugging process. However, with the help of TracePoint, you can automate many of them and thus boost your debugging performance. I hope you can now add TracePoint to your debugging toolbox and give it a try.

Our guest writer Stan is a Senior Software Engineer @ticketsolve. He loves cats, Ruby on Rails and boxing. He created Goby and works on tapping_device during the weekends.

Optimize Your Debugging Process With Object-Oriented Tracing and tapping_device

Stan Lo — Tue, 21 Jan 2020 13:15:50 +0000

As programmers, debugging is one of our daily tasks. And it’s important to sharpen our debugging skills along with other programming skills. But have you ever noticed that, when we’re getting better and better at refactoring, testing, and other coding skills, our debugging skill doesn’t grow as fast as them? In fact, I found myself still using the same debugging tool and process I used 2, 3 years ago.

In the past few weeks, I tried to find a way to debug more effectively. In this post, I will share the reason why it is so hard to improve our debugging skills and how I come up with another approach to tackle this issue.

(To make it easier to explain, the “Bug” here only refers to a piece of code that breaks a previously working program.)

Table of Content

How Do We Debug Our Program - Path Comparison Debugging
1. Build Execution Paths
2. Compare Execution Paths
3. The Technical Challenge of This Technic
Object-Oriented Tracing
1. What Is It
2. What Problem Does It Solve
3. TappingDevice
Conclusion

How Do We Debug Our Program

The way we usually debug our program is actually very primitive: “Compare”. We do it by comparing how the program should work with how it actually works, and find the places that act differently during the program execution. Most of the time, those places are the keys to finding the bug, if not the bug itself. It’s a 3-steps process:

Build the Expected Execution Path
Build the Actual Execution Path
Compare Both Paths

For example,

Build the Execution Paths

The “Execution Path” of a program can somehow be thought of as its path of method/function calls, or simply call it "call path". But depends on the size of the program, it might perform many method calls. So usually, we only mean “the call path of business logic related methods”. For example, during a request to OrdersController#create, there can be many method calls like, Array#[], Object#inspect…etc. But when we’re building the execution paths, we only care about those related to Order’s creation and ignore others.

Compare Execution Paths

Under most conditions, the bug of the program can be found in the first place that acts differently (returning a different value, calls different methods…etc.). So in the following case, the bug is probably inside the bar method or its dependencies.

The Challenge of This Technique

I believe most people debug like this approach, but not exactly the same. Ideally, we should build the execution paths as detailed as possible, so we can have enough information to make an accurate comparison. However, in reality, for reasons like the limit amount of time, or laziness..etc., we usually just pick some methods that we “guess” are related to the bug, and hope we made the right guess. 🤞

It means that the effectiveness of our debugging practices are determined by the method we pick to build the paths. And that can be affected by

Our experience in the language/framework
How well do we understand the codebase
Luck?

This is why we still debug faster over time, even though we don’t put too much attention on our debugging skills.

In my opinion, the root cause of this phenomenon is that we don’t have an efficient tool to work with our debugging strategy. Whether you’re a puts debugger or a pry-debugger. For most of the time, inspecting the program’s behavior is an overwhelming job, for several reasons:

We need to collect arguments manually

# super annoying
def foo(var1, var2)
  puts("var1: #{var1}")
  puts("var2: #{var2}")
  # …
end

We need to collect return values manually

# eithr
def new_cart(attributes)
  Cart.new(attributes).tap { |c| puts(c) }
end

# or 
cart = new_cart(attributes)
puts(cart)

We need to jump between different methods, or even files to place the puts or breakpoints.

The more manual job it needs to collect information, the more likely we’ll just make a guess and take a chance. Despite being annoying, manually collecting these different kinds of information also creates other problems:

To collect the information we need effectively (e.g., at the right place, call the right method), we need to understand the program well enough. So the less experienced you are, the harder you can understand the program.
Adding breakpoints or tracing methods is a kind of code pollution. For example, if a method changes an object’s state and you call it when tracing the code (to get its return value or something), it’d change the program’s behavior.
In my personal experience, when messing around with the code, it’s easy to forget my original purpose is just to inspect the method call and start digging deeper.

Object-Oriented Tracing

But if we look at our debugging behavior close enough, we can find some patterns that we might take advantage of. For example:

If you’re debugging a web application’s feature, we can start from a specific endpoint’s logic (e.g., particular controller action). Which gives us a perfect position to start the debugging process.
In an object-oriented programming language like Ruby, a feature can usually be linked to 1 or a few classes. For example, you know you should look for something like OrderCreationService when there’s a bug about orders. So you can build the most of the execution paths by observing one or a few object’s method calls.

And the concept “Object-Oriented Tracing” is built upon the above assumptions and Ruby’s powerful TracePoint feature. Let me explain it with examples.

Assume we have an OrdersController#create endpoint for creating orders

class OrdersController < ApplicationController
  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])
    @order = OrderCreationService.new.perform(@cart, promotion)
    ……
  end

And we want to build the execution path of Order’s creation. We can write

class OrdersController < ApplicationController
  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])

    TracePoint.new(:call) do |tp|
      if tp.self.class.name == "OrderCreationService"
        puts("Called :#{tp.callee_id} from #{tp.path}:#{tp.lineno}")
      end
    end.enable do
      @order = OrderCreationService.new.perform(@cart, promotion)
    end

Which would print

Called :initialize from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:2
Called :perform from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:6
Called :validate_cart from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:17
Called :apply_discount from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:23
Called :create_order from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:27

Now we know what the OrderCreationService does to create an Order, we have a pretty clear execution path immediately. But with some of Ruby’s meta-programming tricks, we can get more information, like each method call’s arguments!

class OrdersController < ApplicationController
  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])

    TracePoint.new(:call) do |tp|
      if tp.self.class.name == "OrderCreationService"
        puts("Called :#{tp.callee_id} from #{tp.path}:#{tp.lineno}")
        tp.binding.local_variables.each do |name|
          value = tp.binding.local_variable_get(name)
          puts("  Arg #{name}: #{value.inspect}")
        end
      end
    end.enable do
      @order = OrderCreationService.new.perform(@cart, promotion)
    end

Called :initialize from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:2
  Arg options: {}

Called :perform from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:6
  Arg cart: #<Cart id: 1, total: 10, customer_id: 1, promotion_id: nil, reserved_until: nil, created_at: "2020-01-19 08:41:51", updated_at: "2020-01-19 08:41:51">
  Arg promotion: #<Promotion id: 1, amount: 0.5e1, customer_id: nil, created_at: "2020-01-19 08:41:51", updated_at: "2020-01-19 08:41:51">

Called :validate_cart from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:17
  Arg cart: #<Cart id: 1, total: 10, customer_id: 1, promotion_id: nil, reserved_until: nil, created_at: "2020-01-19 08:41:51", updated_at: "2020-01-19 08:41:51">

Called :apply_discount from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:23
  Arg cart: #<Cart id: 1, total: 10, customer_id: 1, promotion_id: nil, reserved_until: nil, created_at: "2020-01-19 08:41:51", updated_at: "2020-01-19 08:41:51">
  Arg promotion: #<Promotion id: 1, amount: 0.5e1, customer_id: nil, created_at: "2020-01-19 08:41:51", updated_at: "2020-01-19 08:41:51">

Called :create_order from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:27
  Arg cart: #<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-19 08:41:51", updated_at: "2020-01-19 08:41:51">

Isn’t this super cool? Now we know what method got called and what arguments they took. Let’s add the last piece of information: the return value.

class OrdersController < ApplicationController
  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])

    TracePoint.new(:return) do |tp|
      if tp.self.class.name == "OrderCreationService"
        puts("Called :#{tp.callee_id} from #{tp.path}:#{tp.lineno}")
        tp.binding.local_variables.each do |name|
          value = tp.binding.local_variable_get(name)
          puts("  Arg #{name}: #{value.inspect}")
        end
        puts("  => #{tp.return_value}")
      end
    end.enable do
      @order = OrderCreationService.new.perform(@cart, promotion)
    end

Called :initialize from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:4
  Arg options: {}
  => {}

Called :validate_cart from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:21
  Arg cart: #<Cart id: 1, total: 10, customer_id: 1, promotion_id: nil, reserved_until: nil, created_at: "2020-01-19 08:59:13", updated_at: "2020-01-19 08:59:13">
  =>

Called :apply_discount from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:25
  Arg cart: #<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-19 08:59:13", updated_at: "2020-01-19 08:59:13">
  Arg promotion: #<Promotion id: 1, amount: 0.5e1, customer_id: nil, created_at: "2020-01-19 08:59:13", updated_at: "2020-01-19 08:59:13">
  => true

Called :create_order from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:29
  Arg cart: #<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-19 08:59:13", updated_at: "2020-01-19 08:59:13">
  => #<Order:0x00007f91455ebd10>

Called :perform from /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:13
  Arg cart: #<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-19 08:59:13", updated_at: "2020-01-19 08:59:13">
  Arg promotion: #<Promotion id: 1, amount: 0.5e1, customer_id: nil, created_at: "2020-01-19 08:59:13", updated_at: "2020-01-19 08:59:13">
  => #<Order:0x00007f91455ebd10>

If you read the above example carefully, you’ll notice that there are other changes in the code and output, except for the return value:

TracePoint now tracks return event, instead of the call event like other 2 examples.
The output’s order is somewhat different from the previous ones.

This is because we need to wait for a method call to finish (return) before we can retrieve its return value. So the output is ordered by the time the method is returned, instead of called. For example:

def perform
  # …
  create_order
end

# call order: perform -> create_order
# return order: create_order -> perform

Once we understand this small difference, this small change in the output won’t confuse us that much. In fact, I sometimes find it more useful in some instances. e.g., when I want to observe how different methods update and return the same value, ordering them with return value makes more sense.

With Object-Oriented Tracing, now we can know the program’s call path, each call’s arguments, and even their return values in a glance. Other than being super-efficient, object-oriented tracing also avoids some problems I mentioned earlier:

In the past, we need to understand what OrderCreationService would call, in order to get inside those methods and collect the information we need. Now we only need to know where would OrderCreationService#perform be called (which is super easy to find).
Unless we need more detailed information or perform some tests on the logic of OrderCreationService, we don’t need to touch any line of its code. So we can keep it clean even while debugging.

TappingDevice

Although TracePoint is already capable of doing what we want, there still are things we can do to make it easier:

The boilerplate code is quite long (~10 lines). It’s not so easy to remember.
If you’re not familiar with TracePoint, it could take you some time to deal with some edge cases (trust me, I’ve been there before). This means the boilerplate code might end up getting longer to work around those cases.

This is why I created tapping_device to make this easier for you! Do you still remember the code we wrote in the last example? Well, I don’t. And I don’t want to remember it! How about making that piece of code into just one method call? Instead of

  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])
    service = OrderCreationService.new

    TracePoint.new(:return) do |tp|
      if tp.self.class.name == "OrderCreationService"
        puts("Called :#{tp.callee_id} from #{tp.path}:#{tp.lineno}")
        tp.binding.local_variables.each do |name|
          value = tp.binding.local_variable_get(name)
          puts("  Arg #{name}: #{value.inspect}")
        end
        puts("  => #{tp.return_value}")
      end
    end.enable do
      @order = service.perform(@cart, promotion)
    end
    # …
  end

We only need to add 2 lines now:

  include TappingDevice::Trackable # include this

  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])
    service = OrderCreationService.new

    print_calls(service) # <— and you only need this now
    @order = service.perform(@cart, promotion)
    # …
  end

And we can get the same information!

:validate_cart # OrderCreationService
    from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:8
    <= {:cart=>#<Cart id: 1, total: 10, customer_id: 1, promotion_id: nil, reserved_until: nil, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">}
    => nil
:apply_discount # OrderCreationService
    from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:10
    <= {:cart=>#<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">, :promotion=>#<Promotion id: 1, amount: 0.5e1, customer_id: nil, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">}
    => true
:create_order # OrderCreationService
    from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:11
    <= {:cart=>#<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">}
    => #<Order id: 1, number: nil, total: 5, customer_id: 1, promotion_id: 1, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">
:perform # OrderCreationService
    from: /Users/st0012/projects/tapping_device-demo/app/controllers/orders_controller.rb:10
    <= {:cart=>#<Cart id: 1, total: 5, customer_id: 1, promotion_id: 1, reserved_until: nil, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">, :promotion=>#<Promotion id: 1, amount: 0.5e1, customer_id: nil, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">}
    => #<Order id: 1, number: nil, total: 5, customer_id: 1, promotion_id: 1, created_at: "2020-01-20 07:09:22", updated_at: "2020-01-20 07:09:22">

In addition to print_calls, tapping_device also provides different level’s of APIs for different kind of information, like print_traces

Assume we don’t find anything wrong on the OrderCreationService’s method calls. And we suspect it’s something wrong on the @cart object. We can use print_traces to see how it interacts with other parts of the program.

  include TappingDevice::Trackable

  def create
    @cart = Cart.find(order_params[:cart_id])
    promotion = Promotion.find_by(id: order_params[:promotion_id])
    service = OrderCreationService.new

    print_traces(@cart, exclude_by_paths: [/gems/]) # exclude gems so we don’t see ActiveRecord’s internal method calls
    @order = service.perform(@cart, promotion)

Passed as 'cart' in 'OrderCreationService#perform' at /Users/st0012/projects/tapping_device-demo/app/controllers/orders_controller.rb:9
Passed as 'cart' in 'OrderCreationService#validate_cart' at /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:8
Called :reserved_until from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:18
Called :errors from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:9
Passed as 'cart' in 'OrderCreationService#apply_discount' at /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:10
Called :apply_discount from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:24
Called :total from: /Users/st0012/projects/tapping_device-demo/app/models/cart.rb:6
Called :update! from: /Users/st0012/projects/tapping_device-demo/app/models/cart.rb:6
Passed as 'cart' in 'OrderCreationService#create_order' at /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:11
Called :total from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:28
Called :customer from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:28
Called :promotion from: /Users/st0012/projects/tapping_device-demo/app/services/order_creation_service.rb:28

We can not only see what’s been called on @cart, but we can also see what methods took it as its arguments! This can save you some time when debugging. 😉

If you want to know more about how to use tapping_device to optimize your debugging workflow, you can read its readme to explore different types of useful helpers! You can also see how I used it to address the cause of a Rails issue in Debug Rails issues effectively with tapping_device.

Conclusion

Debugging is mostly about collecting information about how our program works (or used to work). And doing this manually is pretty overwhelming. So as humans, it’s tempting to cheat by guessing how it works in our head and ends up spending more time on the issue.

But with the help of Object-Oriented Tracing, we can take advantage of the paradigm of OOP, and Ruby’s super powerful TracePoint to enhance our efficiency on inspecting our programs. I believe this can reduce debugging’s painfulness for junior developers, while allows experienced developers to speed up their debugging process largely.

If you have any opinions on this post or tapping_device, please feel free to leave a comment below, I’d love to discuss them with you! Also, if you have a different or better strategy on debugging, please let me know as well ;-)

Debug Rails issues effectively with tapping_device

Stan Lo — Sun, 22 Dec 2019 11:07:37 +0000

Debug Rails issues effectively with tapping_device

Hello everyone, 👋 I’m the author of the tapping_device gem, a debugging tool I created a while ago. I'm also a Rails contributor that helps people solve their issues from time to time. Today I want to use a real-world example to demonstrate how did the tapping_device gem help me find the cause of a Rails issue in an hour ;-)

Basic Intro of tapping_device

tapping_device is built on top of Ruby’s TracePoint. It has several helpers that provide a high-level point of view of how your program runs. For example:

tap_on!(target) - you can use it to track all method calls performed on the target
tap_sql!(target) - this is a Rails-specific helper. You can use it to track on method calls that generate SQL queries
tap_passed!(target) - you can use it to track what method takes target as its argument

For more info, here’s a post contains some useful examples that you can use in your Rails apps.

The Issue (#38041)

The issue is about a behavioral change on DateTime calculation:

# Rails 5.2.4.1: OK
“2019-12-19 10:00”.to_datetime - BigDecimal(1).hour
=> Thu, 19 Dec 2019 09:00:00 +0000
# OK

# Rails 6.0.2.1: WRONG
“2019-12-19 10:00”.to_datetime - BigDecimal(1).hour
=> Thu, 19 Dec 2019 08:59:59 +0000

It’s clear that something has been changed between version 5.2.4 and 6.0.2. But we don’t know where's the change nor when it’s been made.

How I’d do, in the past

Check if “2019-12-19 10:00”.to_datetime returns the same result in both versions
Check if BigDecimal(1).hour returns the same result in both versions
Digging into what happens when calling DateTime#- in both versions
(Jumping between files and adding breakpoints or puts)

What I did instead, with tapping_device

I wrote a script that prints out how the objects are used by tracking their method calls. The first thing I’d check is that what’s returned in each method call so I can locate what’s been changed. And it’s also important to see where the calls were performed.

require "active_support/all"
require "tapping_device"

puts("Rails: #{ActiveSupport.version}")

time = "2019-12-19 10:00".to_datetime
one_h = BigDecimal(1).hour

device_for_time = TappingDevice.new
device_for_one_h = TappingDevice.new

device_for_time.tap_on!(time)
device_for_one_h.tap_on!(one_h)

time - one_h

puts("Calls on time\n")
device_for_time.calls.each do |payload|
  puts(payload.method_name_and_location + " => #{payload.return_value}")
end

puts("==============================")

puts("Calls on one_h\n")
device_for_one_h.calls.each do |payload|
  puts(payload.method_name_and_location + " => #{payload.return_value}")
end

Then I ran the same script on both versions. Here are the outputs:

Output - Rails 5.2

Rails: 5.2.4
Calls on time
Method: :acts_like?, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activesupport-5.2.4/lib/active_support/duration.rb:404 => true
Method: :+, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activesupport-5.2.4/lib/active_support/core_ext/date_time/calculations.rb:113 => 2019-12-19T09:00:00+00:00
Method: :since, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activesupport-5.2.4/lib/active_support/duration.rb:410 => 2019-12-19T09:00:00+00:00
Method: :plus_with_duration, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activesupport-5.2.4/lib/active_support/core_ext/date/calculations.rb:102 => 2019-12-19T09:00:00+00:00
Method: :-, line: time_test.rb:15 => 2019-12-19T09:00:00+00:00
==============================
Calls on one_h
Method: :is_a?, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activesupport-5.2.4/lib/active_support/duration.rb:145 => true
Method: :-@, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activesupport-5.2.4/lib/active_support/core_ext/date/calculations.rb:102 => -3600.0

Output - Rails 6

Rails: 6.0.2
Calls on time
Method: :acts_like?, line: /Users/st0012/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activesupport-6.0.2/lib/active_support/duration.rb:405 => true
Method: :+, line: /Users/st0012/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activesupport-6.0.2/lib/active_support/core_ext/date_time/calculations.rb:113 => 2019-12-19T08:59:59+00:00
Method: :since, line: /Users/st0012/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activesupport-6.0.2/lib/active_support/duration.rb:411 => 2019-12-19T08:59:59+00:00
Method: :plus_with_duration, line: /Users/st0012/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activesupport-6.0.2/lib/active_support/core_ext/date/calculations.rb:102 => 2019-12-19T08:59:59+00:00
Method: :-, line: time_test.rb:15 => 2019-12-19T08:59:59+00:00
==============================
Calls on one_h
Method: :is_a?, line: /Users/st0012/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activesupport-6.0.2/lib/active_support/duration.rb:144 => true
Method: :-@, line: /Users/st0012/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activesupport-6.0.2/lib/active_support/core_ext/date/calculations.rb:102 => -3600.0

We can see that the + method call’s results were different in the 2 versions. Version 5.2.4 returned 2019-12-19T09:00:00+00:00 while 6.0.2 returned 2019-12-19T08:59:59+00:00. Let’s check what’s defined in active_support/core_ext/date_time/calculations.rb:113.

  def since(seconds)
    self + Rational(seconds, 86400)
  end

Nothing weird. Maybe it has been changed recently?

$ git blame lib/active_support/core_ext/date_time/calculations.rb | grep 113
c85e3f65f34 (Edouard CHIN        2018-10-09 13:36:56 -0400 113)     self + Rational(seconds, 86400)

commit c85e3f65f3409fc329732912908c3601d8e5fac9
Author: Edouard CHIN <edouard.chin@shopify.com>
Date:   Tue Oct 9 13:36:56 2018 -0400

    Fix issue where duration where always rounded up to a second:

    - Adding a Float as a duration to a datetime would result in the Float
      being rounded. Doing something like would have no effect because the
      0.45 seconds would be rounded to 0 second.

      ```

ruby
        time = DateTime.parse("2018-1-1")
        time += 0.45.seconds


      ```

      This behavior was intentionally added a very long time ago, the
      reason was because Ruby 1.8 was using `Integer#gcd` in the
      constructor of Rational which didn't accept a float value.

      That's no longer the case and doing `Rational(0.45, 86400)` would
      now perfectly work fine.

    - Fixes #34008

Bingo! There was a round call in 5.2 but it has been removed 6.0 via this commit.

Isn’t this a super-easy way to debug an issue 😉

What does this mean to me (and you)?

As you can see from the above example, what tapping_device provides is a new way to spot behavioral changes in your program.

Whether you’re a pry/bye bug debugger or a put debugger, you always need to go through files so you can build a rough execution path of the program in your mind before actually adding breakpoints or puts to the right location. The downsides of this are:

If you’re not familiar with the codebase or it’s not written in an easily-understandable way, there could be a lot of trial-and-error before you actually found the right place to inspect your program.
And it’ll be very easy to lose the big picture when you dive into individual method calls.

But if you use tapping_device, you can inspect the program from an object’s point of view. This means you won’t need to know which way it’ll go to intercept it. You just need to know where it’ll start its journey! It can save you hours when debugging a large application/library.

I hope you can give tapping_device a try after reading this post. And if you do try it, please don't be shy to give me any feedback! I’d love to fix any issue or add any feature that can help people debug more happily!

[Ruby Trick] Retrieve an object's private method without calling its `method`

Stan Lo — Fri, 13 Dec 2019 16:34:55 +0000

Goal: Get the bar method

class Foo
  def method; end

  private

  def bar
    "hey!"
  end
end

foo = Foo.new

# foo.method(:bar) will cause error cause it's been overridden
# foo.public_method(:bar) won't work cause :bar is private

method_method = Object.method(:method).unbind
bar_method = method_method.bind(foo).call(:bar)
bar_method.call #=> "hey!"

Want to know more about your Rails app? Tap on your objects!

Stan Lo — Mon, 09 Dec 2019 10:09:37 +0000

Have you ever looked at a controller action like this

def index
  @posts = Post.all
end

And wonder who’ll eventually use the @posts variable? Is there an easy way to do that without going through multiple files and write puts everywhere?

Well, with the help of the tapping_device gem, it’s not just possible, it’s also super easy (with only 3 lines of code!)

Install `tapping_device` and include `TappingDevice::Trackable`

First, add tapping_device into your Gemfile

gem "tapping_device", group: [:development, :test]

And include TappingDevice::Trackable in your controller:

class PostsController < ApplicationController
  include TappingDevice::Trackable
end

The `tap_on!` helper

Now let’s get the most basic information: who’s calling methods on @posts? To do this, you need to use the tap_on! method and define a callback. The block will be executed every time a @posts ’s method is being called.

def index
  @posts = Post.all
  tap_on!(@posts) do |payload|
    puts(payload.method_name_and_location)
  end
end

Then send a request to /posts, you’ll see everything that’s been called on the @posts object:

Method: :eager_load_values, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0/lib/active_record/relation.rb:668
Method: :includes_values, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0/lib/active_record/relation.rb:669
Method: :eager_loading?, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0/lib/active_record/relation/calculations.rb:226
Method: :includes_values, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0/lib/active_record/relation/calculations.rb:226
Method: :has_include?, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0/lib/active_record/relation/calculations.rb:128
Method: :distinct_value, line: /Users/st0012/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/activerecord-6.0.0/lib/active_record/relation/calculations.rb:234
......

Apparently, most of the methods are called by ActiveRecord and it’s not helping us here. Let’s filter them out with the exclude_by_paths option:

def index
  @posts = Post.all
  tap_on!(@posts, exclude_by_paths: [/activerecord/]) do |payload|
    puts(payload.method_name_and_location)
  end
end

Now we can see who’s using the @posts object inside our application:

Method: :count, line: /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:3
Method: :each, line: /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:16
Method: :where, line: /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:31

# index.html.erb

<h1>Posts (<%= @posts.count %>)</h1>
......
  <% @posts.each do |post| %>
    ......
  <% end %>
......
<p>Posts created by you: <%= @posts.where(user: @current_user).count %></p>

Isn’t this super easy?

However, in most cases, we don’t really care about who calls methods on @posts. What we care about is “who calls @posts and generates sql queries?”.

`tap_sql!` to the rescue!

To see what queries @posts generates, we need to use the tap_sql! method instead. It runs the callback every time a sql query is generated from the object.

Let’s change our setup a little bit to:

tap_sql!(@posts, exclude_by_paths: [/activerecord/]) do |payload|
  puts("Method `#{payload.method_name}` generates sql: #{payload.sql}")
  puts("  From #{payload.filepath}:#{payload.line_number}")
end

Now it prints out the method’s name, the sql it generated and the location.

Method `count` generates sql: SELECT COUNT(*) FROM "posts"
  From /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:3
Method `each` generates sql: SELECT "posts".* FROM "posts"
  From /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:16
Method `count` generates sql: SELECT COUNT(*) FROM "posts" WHERE "posts"."user_id" = ?
  From /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:31

If you look at the output very carefully, you may notice something isn’t quite right: The last query SELECT COUNT(*) FROM “posts” WHERE “posts”. “user_id” = ? wasn’t actually generated from @posts.

Well, this is a hidden feature of the tap_sql! method. It also tracks the scopes created from @posts, so if you call scope chaining methods like order or where on @posts, the queries generated from the new scopes will also be recorded!

Bonus: what’s passed into the method?

Sometimes, only knowing which method is called isn’t enough. What’s passed into the method is also very important. For example, assume we want to know which user was passed into the where call, we can do

def index
  @posts = Post.all
  tap_on!(@posts, exclude_by_paths: [/activerecord/]) do |payload|
    if payload.method_name == :where
      puts(payload.method_name_and_location)
      puts("  Arguments: #{payload.arguments}")
    end
  end
end

Method: :where, line: /PROJECT_PATH/rails-6-sample/app/views/posts/index.html.erb:31
  Arguments: {:opts=>{:user=>#<User id: 20, name: "Stan", age: 25, created_at: "2019-12-09 09:06:29", updated_at: "2019-12-09 09:06:29">}, :rest=>[]}

Now we know it’s the “Stan” user, and we don’t even need to leave the controller!

Conclusion

tapping_device is a new project, but I already use it very often on my day job. So I believe it’ll be helpful for others too! If you want to know more about it, please visit the repo and read the readme for more features. And if you have any feature requests, please feel free to open an issue, and we can discuss it! Any other feedback is welcomed as well 😄

tapping_device - a gem for tacking method calls

Stan Lo — Sun, 20 Oct 2019 15:57:21 +0000

tapping_device is a gem built on top of Ruby’s TracePoint class that allows you to tap method calls of specified objects. The purpose of this gem is to make debugging Rails applications easier.

For example, you can use it to see who calls methods on your Post records

class PostsController < ApplicationController
  include TappingDevice::Trackable

  def show
    @post = Post.find(params[:id])
    tap_on!(@post) do |payload|
      puts "Method: #{payload[:method_name]} line: #{payload[:filepath]}:#{payload[:line_number]}"
    end
  end
end

And you can see these in log:

Method: name line: /PROJECT_PATH/sample/app/views/posts/show.html.erb:5
Method: user_id line: /PROJECT_PATH/sample/app/views/posts/show.html.erb:10
Method: to_param line: /RUBY_PATH/gems/2.6.0/gems/actionpack-5.2.0/lib/action_dispatch/routing/route_set.rb:236

Or you can track all association calls with tap_assoc!. This is very useful for tracking potential n+1 query calls, here’s a sample from my work project

tap_assoc!(order) do |payload|
  puts "Assoc: #{payload[:method_name]} line: #{payload[:filepath]}:#{payload[:line_number]}"
end

Assoc: payments line: /RUBY_PATH/gems/2.6.0/gems/jsonapi-resources-0.9.10/lib/jsonapi/resource.rb:124
Assoc: line_items line: /MY_PROJECT/app/models/line_item_container_helpers.rb:44
Assoc: effective_line_items line: /MY_PROJECT/app/models/line_item_container_helpers.rb:110
Assoc: amending_orders line: /MY_PROJECT/app/models/order.rb:385
Assoc: amends_order line: /MY_PROJECT/app/models/order.rb:432

Although I've been using similar ways on my work for a while, my use cases might be quite limited. So I'd love to hear any feedback or suggestions on this tool 😄

DEV Community: Stan Lo

From byebug to ruby/debug

Advantages of debug

Disadvantages of debug

byebug vs debug

Installation

Start Debugging

User Experience Features

Evaluation

Flow Control & Frame Navigation

Thread Control

Breakpoint

Setting Breakpoints

Managing Breakpoints

Information

Backtrace

Varibles/Constants

Methods

Tracing

Configuration

Remote Debugging

Wrapping Up

References

Setup ruby/debug with VSCode

Basic Setup

Debug Simple Ruby Script

Debug Rails/Web Applications

A Sneak Peek of Ruby's New Debugger!

ruby / debug

Debugging functionality for Ruby

debug.gem blog: initial commit

Koichi Sasada ・ Jul 31 '21

Introduction

binding.break (alias: binding.b)

Fequently Used Commands

break (alias: b)

Basic Usages

Commands

catch

backtrace (alias bt)

outline (alias ls)

binding.b + Command Combinations

binding.b(do: "b Foo#bar do: bt")

binding.b(do: "b Foo#bar do: info")

A Small Drawback

Update

Final Thoughts

Fixing issues in OSS is easier than you think

So you want to fix an issue?

But what if I don't get any credits from it

Not having sufficient information about the issue

Not sure how to reproduce the issue

Validate the issue's cause

Fix It!

Final Note

Completely Remove Ruby 2.7's Default Bundler

st0012 / object_tracer

ObjectTracer tracks objects and records their activities

st0012 / power_trace

Buff exception backtrace with local variables, passed in arguments and instance variables!

Replace A Rails Initializer

The Steps

Identify the Initializer's Source

Register the New Initializer

Drop the Old Initializer

Additional Tip: Reuse the Old Initializer

Changing the Approach to Debugging in Ruby with TracePoint

Stan Lo for AppSignal ・ Apr 9 '20

Optimize Your Debugging Process With Object-Oriented Tracing and tapping_device

Stan Lo ・ Jan 21 '20

st0012 / object_tracer

ObjectTracer tracks objects and records their activities

Changing the Approach to Debugging in Ruby with TracePoint

Debugging Is about Understanding Your Program and Its Design

Learning the Expectations from the Design

Understanding the Current Implementation

Addressing the Bug

This Is Far from Reality!

Information Is Expensive

Why Is Debugging Expensive?

Advantages of `debug`

Disadvantages of `debug`

`byebug` vs `debug`

`binding.break` (alias: `binding.b`)

`break` (alias: `b`)

`catch`

`backtrace` (alias `bt`)

`outline` (alias `ls`)

`binding.b` + Command Combinations

`binding.b(do: "b Foo#bar do: bt")`

`binding.b(do: "b Foo#bar do: info")`

Install `tapping_device` and include `TappingDevice::Trackable`

The `tap_on!` helper

`tap_sql!` to the rescue!