Why Pry?

It’s an interesting coincidence that I recently launched my journey as a Flatiron Software Engineering student in the midst of a viral pandemic. Just as the world’s presence online has significantly increased (to adhere to quarantine and shelter in place guidelines) I’m beginning to study coding, the very thing that built and sustains the internet. The intention of my blog is to:

- share my journey into code

- learn from and improve on my coding experiences

How did I come to be a Flatiron student?

In the summer of 2019, my daughter expressed interest in coding. To be supportive, I started dabbling in HTML and CSS using free resources like freecodecamp, Lynda.com, and watching a few YouTube coding vlogs. I purchased Head First JavaScript Programming, then in December, I started seriously studying. I started the Flatiron application process the following January, took and passed the technical interview and was accepted for the Software Engineering course. I completed the mandatory Pre-Work shortly before starting the program.

Pry who?

Despite all the coding practice I had prior to beginning my course, I’d never heard of “pry” until the last few labs of the Pre-Work. Flatiron has a free “Ask a Question” service and one of the coaches asked me if I knew how to pry when I called in for help. I knew nothing about it and when I did attempt to use it, I found it confusing so I avoided using it. Now, in my third week of coding bootcamp, I’ve not only made peace with it, I’m beginning to rely on it.

What is pry?

It’s a code debugger; a tool programmers use to locate mistakes in their code and test out coding solutions. Pry is a REPL (Read, Evaluate, Print, Loop) with the ability to freeze code in mid-run and allow you to ask it questions. You can ask whereami and it will tell you which file you’re in and what line of code you’re on. You can ask what class a data type is by using .class on it. Knowing what kind of data type you’re working with is significant because of the different rules that govern data types. If you write code that adds a string (text) to an integer (a whole number), you’ll get an error and your code won’t work because a string and an integer are two different data types and can’t be added together. While still in pry, you can use ls to ask a data type to list all the methods you can run on it. In the list of methods for an integer, you’ll discover .to_s, a method that converts an integer into a string. Use the .to_s method on the integer when adding it to the string so that now, you’re adding two strings and your code works.

I’m still learning about pry. For instance, just today, I learned how to use pry when working with more than one file and I was able to target which of my files had an error. Place require ‘pry’ at the top of your run file and any other coding files. To test your run page, place binding.pry right above the code you want to peer into. Then run your code in the terminal by typing ruby run.rb (the name of your run file). Move your binding.pry around to test different parts of your code.

To test your other files, leave binding pry at the bottom of your run file and then place another binding.pry in the file you want to pry into. Run your code again with ruby run.rb. If the pry is in your run file, then do a method call from the file you want to pry into and pry will jump to that file. Move your binding.pry around in this file to test different parts of your code.

Pry may seem confusing in the beginning, but stick with it because it’s a significant and powerful tool to have as a programmer.