Debugging Ruby vs Debugging in PHP

One of the best things about PHP is just how approachable it is. For someone like me who knew they wanted to make web applications, it has a very straight forward path to debugging when you’re first starting out - the echo statement.

If you’re curious what a $variable looks like just echo $variable; die; and you can see what’s going out and halt execution before anything else goes off.

What if $variable is an Array? Woof. Tough luck.

Eventually you hear about this other fancy function called var_dump. It doesn’t matter what you feed this function, it will print it out in a pretty way:

  die(var_dump($anything));

For the longest time, this was my way of debugging PHP applications. And I know for a fact many others do the same thing.

There’s a better way to debug PHP, with an actual debugger tool that lets you do all kinds of fun stuff. Things like view all of the variables at any particular point in time, or jump from breakpoint to breakpoint to inspect what’s going on in your application.

That tool is called XDebug. However it get it working properly you need to integrate it with your IDE of choice. I won’t be covering that in this book, but if you’re curious you can find guides on how to use it with PHPStorm or Visual Studio Code easily.

Get xdebug Functionality in Ruby in less than 5 minutes

When you’re writing Ruby web applications, you’re most likely going to be using Sinatra or Ruby on Rails. Unlike PHP which is a language built for the web; there is no echo equivalent in Ruby which just takes a string and spits it into rendered HTML.

While we were doing exceries on the different concepts of Ruby, our interface was the Command Line. The fancy computer science term for this kind of interaction is called CLI, which is short for Command Line Interface.

In a way, this is more of a blessing than a curse. You get introduced to the world of debugging with a legitimate debugger far sooner because you essentially have to.

In PHP, we have a defacto standard debugger and it’s name is xdebug. In Ruby, there are multiple debuggers. One if not the most popular debugger is the aptly named byebug.

Let’s install byebug globally so we can just use it in any Ruby script we create:


  gem install byebug

Now let’s open our favorite Ruby class of all time that we created back in the introduction to OOP section: cat.rb. And let’s load the byebug gem by requiring it in the file.

Then let’s plop a byebug debugger right inside of our meow method:

# cat.rb
require 'byebug'

class Cat
  def meow
    byebug
    puts 'meow'
  end
end

Now run the file with ruby cat.rb and you’ll see something like this:

ruby cat.rb

pierce@my-computa:~/projects/php_to_ruby/examples% ruby cat.rb

[3, 12] in /home/pierce/projects/php_to_ruby/examples/cat.rb
    3: require 'byebug'
    4:
    5: class Cat
    6:   def meow
    7:     byebug
=>  8:     puts 'meow'
    9:   end
   10: end
   11:
   12: cat = Cat.new
(byebug)

Crazy right? Essentially what you did was halt execution, but didn’t exit out of the program. You can now inspect what’s going on in your program at the present moment.

While this Terminal window is open, let’s see what self looks like at inside of this meow method:

(byebug) self
#<Cat:0x007f8c690088e8>

So self is an instance of a Cat object. So we basically just proved that self in Ruby objects are the same as $this in PHP objects.

You can know exit byebug by simply keying CTRL + D on your keyboard or entering exit into the prompt.

There are a plethora of other goodies baked into byebug, but you’ve learned enough to use it proficently. I’ll leave the discovery details of byebug up to you.

PHP to Ruby

Get xdebug Functionality in Ruby in less than 5 minutes