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
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.
$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:
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.
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
# 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
(byebug) self #<Cat:0x007f8c690088e8>
self is an instance of a Cat object. So we basically just proved that
self in Ruby objects are the same as
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.