RailsConf 2014 – Debugger Driven Developement with Pry by Joel Turnbull

JOEL TURNBULL: Thanks for coming. My name is Joel Turnbull. I’m a developer for Gaslight in Cincinnatti,
Ohio. I also head up and coordinate a blog over
there, in case anybody ever wants to talk about that. But today, I’m here to talk about debugger
driven development with Pry. Most Rubyists I know
don’t use debuggers. Rubyists I know, when faced with
a problem, would prefer to ponder code than pop open
a debugger and poke around. This is crazy to me. I’ve always thought it was, because to me, trying to solve a problem by pondering code is like trying to find your keys in the dark, when you’re holding a flashlight, but you’re consciously deciding not to use
it. So why is this? I, I used to think it might be about egos or culture or something like that, but really it’s pretty simple.
I think we’ve had a lack of really good tools up to this point. But ultimately, my talk isn’t
about using debuggers in a traditional sense to
fix software, but using debuggers as a tool in your workflow to build software. And, so why do I think we can do this right now? I feel like we finally have a tool that we can use to explore this debugger driven, debugger driven workflow.
And that tool is Pry. Can I get a show of hands of who uses Pry? Awesome. Like, everybody. All right.
Cool. So I’m talking about debugger driven development
with Pry. Conrad Erwin gave a talk not even like six months ago called REPL Driven Development with Pry.
I swear to god I had no idea. But, and both are accurate, I think. You know, but I think both terms kind of undersell what the power of Pry is. So here’s my favorite definition. Pry is an IRB alternative and
runtime developer console. So if we take the first part of that and we think about Pry as an IRB alternative, you know, anything that you can
do with, with, both, both are REPLs, right. And, and
a debugger is a REPL, too. Anything you can
do in Ruby, you can do in IRB. Anything you can do in IRB, you can do in Pry. What makes both of them powerful, is they
both leverage this idea of runtime. And, to me,
runtime is all about immersion. It’s about being immersed
in a live system, where you can play with code and you can look at your objects and, and all that kind of thing. You can validate your implementations. Everything you need to do.
And it’s like, looking for your keys with a flashlight. So, given that Pry and IRB are both REPLs and they both have this idea of runtime, why should you use Pry instead of IRB? It’s got a couple vital workflow features right out
of the box. Syntax highlighting and tab completion.
Both super handy. But, what I want to talk about today is some of the bigger, game-changing features
of Pry. The first one is enhanced introspection. Here’s
our friend again. Introspection is the ability to, of, of a
language, where you can ask a language questions about
itself. And it’s built into Ruby, and that’s awesome. If you’ve ever asked a class what method you can call on it, or you’ve asked an instance what class it is, you’re doing introspection. What if you want to go deeper? Like, what if you want to know what the class methods are versus the instance methods? You know,
what if you want to know what methods are inherited,
and from where? What if you want to know what state an instance holds onto during its life
cycle? You can answer all these questions with plain
Ruby and IRB. But the problem is, is that, it’s, the, the amount of effort involved is non-trivial.
I would classify it as daunting. So. Given that. You know. I would, I would classify this as DRTFM. This is what I, this is what I point to. I mean, this is the workflow that I like. I like to take the things out of the box. I like to get a feel for what the pieces are. I like to play around with them. I like to try to put it together without reading the manual, and if I get stuck, then I read the manual, right. The second really game-changing feature of
Pry, to me, is extendability through plugins. And the
best way that I can show this is to just demo some of my favorites for you. So, I’m gonna show you a Rails app. Instead of calling it in a normal way, like rails s, I’m gonna call it like this. Under the umbrella of Pry rescue. And I’ll show you
why in a minute. But here we are. This is an app I’ve been working on late, late nights, you know.
Please don’t steal this. This is a bowling score
count, tracker, right. You can push any number after
you bowl and it will record what you, what, how many pins you knocked down, right. So, the first thing I’m gonna show you about Pry, for those who aren’t necessarily familiar,
is how you invoke a runtime at any point in your application, where you’re running Ruby, right. Here, I’ve inserted a couple binding dot prys.
One into my controller action and one into my
template. On the lower left we have our model. OK, so let’s rerun it with that in mind. Let’s go back to our running server, and we’ll see that we’ve halted our execution here,
and we’ve been dropped into a run time. And we can do things in here like look around. We can play lines of code. Let’s play the line that sets the bowling game. And then we can look again. When we exit from this, we’ve returned from
our controller. We’re starting to render our template,
and we’ve hit our next binding dot pry. You can put binding dot prys inside your erb tags, right. Same drill. We can look at bowling games.
We can, we can step into our next, our, our, our implementations of our methods. Here we’ve
stepped into the frames method of our bowling game model. Same drill. We can look around here. We can look at ourself. We can go to the next, or we can continue. So, you can see how handy that would be if things aren’t necessarily blowing up, but,
you know, something’s not quite right, either. So what
if things do blow up, though? Right. So, here I am. I’m gonna, I’m gonna spark an exception here by bullet, trying to bowl
the next ball of my next frame. I’m gonna bowl a big nine. I’m gonna come back here and we’ve been dropped into a runtime, because
an exception was thrown. That’s what being under the watchful
eye of Pry rescue is gonna do for us within this context here. So, some interesting, interesting things we
can do here. We can call the show-stack command of the
Pry stack explorer plugin. And we’re seeing the
whole stack here. this is like caller, but it’s alive,
right. We can move up the stack. We can move up the stack nine frames. We can move down the stack. We can take a look at the state of any object here at any level of our stack trace. We can look at our stack again just to see where we’re at. We’re on frame ten. But this is a big hairy kind of Rails stack trace, and we’re not getting a whole lot of value out of that right now. So let’s call the cd-cause command of Pry
rescue. And see if it can track down what caused this problem in the first place. There we go. This looks more familiar, right.
Here we are in our template. And I will guess that on line thirteen we have a problem with frame one. And that’s true. So we just need to add a little bit of a guard in here, and say, you know, if we have pins on frame one, let’s render that. Otherwise
let’s just render a dash. And we get feedback that that’s going, that’s
what’s gonna happen, right. We know that this is
a working implementation. So let’s copy our history. This is another
plugin called Pry clipboard. That’s gonna copy that
implementation into my clipboard. I’m gonna edit a file where
the last exception was raised. It drops me right
where I need to be. I’m gonna paste in that implementation, drop back in, and I’m gonna
ask Pry rescue to try it again. And we’re back. And we’ve got our dash. So, and we can continue to bowl, right. That’s
legit, right. A five and a six. OK, cool. So, what do we do here? We used binding dot pry to invoke a runtime anywhere in our app where we’re doing Ruby code. We used the pry-debugger gem to give us our step, next,
and continue functionality that we expect out
of our debugging tools. We used pry-rescue and ran our Rails
app under the umbrella of pry-rescue to drop us
into a runtime when things go wrong, so that we can poke around. We used the pry-stack_explorer
gem to navigate the stack and explore state at any
level. A few commands we saw were cd-cause in pry-rescue that took us to the, the root of our problem. We used play and we used copy-history
to not mess around with, you know, copying things
with our mouse and pasting them into our REPL,
which can be a pain. We used the edit command with the e flag to take us to the file where the exception occurred so that
we could fix it. And then we used pry-rescue, try-again,
which under this, under the context of Rails, just
replayed our request. We didn’t have to reload our,
our page, or do any of that nonsense. Reload the whole environment or anything like that, right.
So it was fast. So, the, that’s, that’s great, and having
demoed Pry in a debugger context, you know, I can show some of those things. But, really, what I
find interesting is this idea of Pry as a runtime developer console, right. So there’s some really awspect- really awesome
aspects of Ruby, right. It’s introspective, which we’ve
talked about a little bit and we’ll talk about more. And
it’s a dynamic and it’s reflective, which means,
you know, we don’t have to compile it and we can change things on the fly in its runtime. And I think we, we take advantage of these things, you know, a lot in the code that we write, whether we’re doing metaprogramming
or monkeypatching or, or anything like that. But we, we haven’t
really taken advantage of, of these things in the
tools and in our workflow yet. So, when I talk about workflow and our problems with our workflow, I see big problems with
the traditional workflow in, in Ruby development
that I, that I see. Right, I mean. By that I mean we write some code in an editor. We save it. We hop over to a terminal or we pop over to a webpage and reload it and run it to see if it worked and, if it worked, we go back and continue on. If it didn’t, we fix it, we save. We go back. We reload it, rerun it. Rinse, repeat,
right? What, what are, what problems do I see with this? First of all, it’s disruptive and it’s
distracting to keep switching back and forth, right. Some
amount of context-switching is always gonna be imminent,
right. But any effort you can make to reduce that is just gonna be a huge win for your flow, you know, and your focus. The second problem I see with that is it’s just guess work. We just write some code.
Oh, yeah, I think it’s gonna work. We save it. We go over. We run it to see if it works. We’re just taking shots in the dark, you know. You can ask this guy. Taking shots with a flashlight is much more
accurate. And recommended, apparently. So do that. And, to me, it just seems backwards, right.
We, we’re like solidifying and codifying our code
into our code base just in an attempt to see if it works. It should be the opposite. Our code base, it should be the, the record of code that we’ve, we’ve already validated, right.
And I, I mean these things are just kind of things
that we accept and, and we, we take for granted, right. But I mean, I think other languages have,
have been more effective and intentional about
integrating this idea of a runtime into the, their workflow, you
know. And blurring this line between static and
running code. Clojure comes to mind, right. But, we’ve talked about the awesome aspects
of Ruby, and there’s really nothing that restricts
or limits us from doing the same, right. I mean, I think the Ruby language is, the Ruby language enables
it, you know. It’s just that up to this point, we really haven’t had the tools to do so. So, we talked about these workflow problems.
How does Pry solve these workflow problems, right?
I see that, you know, the introspection and the documentation
and the source code browsing, which we’ll see in a
minute, that’s, that’s baked into Pry, gives us ninety
percent of the information that we need to write code right now, you know, in most cases. It has a runtime that you can throw your code against and validate it and get feedback
on whether it, whether it works or not, immediately.
And it’s smart about editing. You don’t have to
think about what file you need to open. Pry usually knows what file you want to edit and usually knows exactly where you want to edit it. Which is really nice. So, when I talk about this idea of runtime development, I’m really talking about being
immersed in this, in this environment that, you know, loves
us and can give us feedback, and, and is alive, right. So we want to spend the majority of our development time there, and we want our editor
to just be an after thought. And that’s just
a place where we just push working code when
it’s done, right. So, let me demo to you a little bit about how I see that working, right. So. Our mission is to write an empty class definition, OK. This is just a script. No
Rails involved here or anything. But given a class
like name like BowlingGame, we want to create a
file, bowling_game dot rb, and write a class definition
to it, like class BowlingGame empty space end.
Right, and I’ve created a little skeleton here of, of
how I think that might work, right. We’re gonna, we’re gonna read in a string
from the command line, we’re gonna pass that string
into a method called file_name_for_class and get
a file name. We’re gonna pass that string into a method
called class_definition for class and get a class
definition, and then we’re gonna create that class by writing
that class definition to that file. Right. So let’s step out here and let’s just run that. So, we get an expected error, right.
We haven’t implemented anything called file_name_for_class,
yet. So we could jump into our editor and start coding and
all that, but why don’t we see what this is like. Why don’t we use Pry rescue and leverage that exception to drop us into a runtime and start this runtime development process. So we do
that. We get the same error, but the difference is,
we’re inside of a runtime now, OK. So, the first problem is pretty easy. We know that we need to define file_name_for_class. And we do so,
right. The difference is in here, I’m gonna raise,
in the implementation of this class, and drop
back out. And I’ll show you why. When we ask Pry to try again, we get in here. We’re right where we need to be to define the implementa- working implementation of this class. Although,
I already know that I have forgotten to pass in the BowlingGame string, like I always do. OK. Now we have everything we need. So we have something like BowlingGame, right, and
we’re looking for something like bowling_game dot rb, OK. So
I’m just gonna preview my favorite Pry command of all
time here. ls. When I call ls, and give it the class or the object I’m working with, I immediately
know I’m working with a string and I’m seeing all of the methods that are available to me on that string. And when I say all of the methods, I don’t mean all of them. Notice
that the object methods are not in here. And, you know that if you’ve ever used IRB to get the method, you always do, thing dot method
minus object dot methods blah, blah, blah. The, that’s just noise, right, in most cases.
So the default is just to leave that out. The developers of Pry have thought of that, right.
So we can try to class downcase, which gets us so close, but yet so far away. We don’t really know where to put that underscore. But, as Ruby devs, Rails devs, we know we have things like ActiveSupport that can help
us out with that. So we include that, and now when we ls our class, we’ve got some extra stuff in here, right. Demodulalize, deconstantize, right.
That kind of stuff. And if it, that’s hard to see, we can just ls ActiveSupport::Inflector itself and see
what’s available to us there, right. So we need an und, we needed an underscore. I see a method called underscore there. Tab
completion is nice. All right. So now we’re getting a lot closer. All we need to do is stick on our file exception, and I think we’re done, right. So that, there’s our filename. So let’s copy
that. Let’s drop back into our file. Right here,
exactly where we need to put the implementation, let’s
put it in there. And let’s save it and continue on. OK, I know, I’m not gonna continue through this whole thing, in the interest of time,
but I do want to, to implement this last method inside of the create_class, so I can talk
a little bit more about what I love about introspection, right. Let’s just reflect on what we did there, though, with the workflow, OK. So we used, the, we used pry-rescue to leverage the power, you
know, to leverage that exception, to pop us into a
runtime, and we used the runtime of the debugger not to fix code, but to drive our development
process, right. So. We’re in here. We’ve raised inside of
our create_class method. We try again. We’ve got
our file name, and we’ve got our class definition.
And we have this file class, right. And, and I know about this file class, and I know this is exactly what I need to get the job done. But, I mean, this is exactly what I, what happened to me. I don’t really remember exactly
what I need to do here, OK. So I can pop out to StackOverflow or I can pop out to, to Ruby-docs or something
and take a look. Or I can just ls file, right here. And just take a minute to look at this, and think about all of the low-level Ruby instrospection acrobatics you would have
to go through to get this brain dump of information right
here. We’ve got all of the methods that you can call on instances of file. We’ve got all the methods you can call on the file class. We’ve got all of the methods that file inherits,
and, from its superclass, and we know what that
superclass is. IO. We also know all the constants involved and
if there was state involved in class or instance
variables. We would see that here as well. So, all of a sudden, I’m informed about, about everything
I need to know about this class, and I have a pretty good idea, just from a, from a moment’s notice, of how I can use it, or what I can do to play around with it. So let’s. I see the right method. And I don’t really want to write anything or mess
with anything right now, so I’m just gonna look
at the documentation for it. OK. It opens the
file. It optimally seeks to the given offset. Writes
a string, then returns the length written. Write
ensures that the files close before returning. This sounds
like what I want. I page down. I see some examples there. Great. I’m ready to go. Alternatively, I can do the same and call
show-source, OK. Which isn’t doing a lot for me here, but when I’m in my, my own code base, this is what I lean on more often, right. So, let’s get our bearings again. And let’s give it a try, right. File.write(file_name.class_definition).
OK. Something happened. It seemed to work, right.
How do I know? Really easy to shell out in Pry. You get really nice output. Exactly what you
would expect, which is, I can’t say the same for IRB in that, in that case. I have this thing called bowling_game in there.
Let’s take a look at it. That looks correct to me. So let’s just do that again. I’m gonna copy the history again. And then I’m gonna
remove bowling_game, just to make sure that my script
is doing what it promises, right. Oops. And it’s not there anymore. So let’s go back. Let’s put in that, let’s put in that implementation. And drop back in. Let’s ask Pry to try again. No more exceptions. Do we have our
bowling_game? We do. OK. So, what happened there, right? We used
the debugger and the runtime as, as, as a tool for driving our development process and build
our implementation. Not just to fix software, right. We validated our implementation before codifying
it, and we reversed this traditional workflow that I’ve
got so many problems with. We explored and we informed
ourselves about how to, how to use our classes without context switching. Right, we stayed focused in one
tool. And then we didn’t have to reload our, our libraries and our environment every time we wanted to
run code, so it was fast. So, and, you know. We’re in the testing track here, so I should probably talk about testing
a little bit. And, that might have felt a little bit like TDD to you. I mean, it does to me, right. As, as practitioners of TDD,
you know, I may not, I’m, I’m, I love TDD. I think most, many Rubyists do. But I mean, what I love about it most is it keeps me focused and, and, and, having a test suite allows me to aggressively refactor
my code, you know, and have the confidence to
do that. You know, and I’d rather do that upfront than after the fact, right. But, as practitioners
of TDD, you know, we’ve learned to love failure,
you know. TDD is all about making something fail, then
writing the code to make it pass. When we have bugs, we want to exercise that exact piece
of code that’s giving us the error and get that error, you know, before we then go, cause
we know we’re about to do something cool and
fix it, right. So, we love to see red. And so a, a practice that’s, that’s centered around
failure is naturally suited to a debugging tool, right. I mean,
that’s what a debugging tool does. It’s meant to
handle failures, catch failures, and then give you
the tools you need and enable you to fix them as quickly as you can. And we’ve seen how awesome, you know, a debugger Pry can be. And, so, the promise of this talk is that I’m going to, you know, deliver a, a, a Pry-enabled TDD workflow. But before I do
that, I mean, I mentioned that, you know, I’ve had
a, kind of specific experience that made me a
believer that this workflow even happens. I mean, I’ve
actually done this before. I’m not creating this, right. And, and that specific experience was this.
Does anybody know what this is? Smalltalk. Yeah. This is
a screenshot of a Farrow Smalltalk IDE, right.
And I spent about a year or so in the 2000s writing a web application in the C-side framework
in Smalltalk for a company in New York City with, with a team of guys. And, really delving into object-oriented programming,
and learning so much about it, I really learned to love this, right. But what first, what first struck me
when I saw Pry and I saw the ls command was it reminded me of this, right. Right here, we are looking at a ZnClient class in a Zinc HTTP package. We see the class definition
right there at the bottom, with all of the instance variables that this class makes use of listed
out. On the right hand side, we see all the methods that we can call on this, on a, on an instance of class, and we can click on any of those to see the source code of that method. I mean, that’s all, that’s
all you need, as far as I’m concerned. I mean, that gets you ninety percent of the way there almost every, like, almost every time, right. So, I wanted to, I wanted to demo, like a, a Smalltalk TDD workflow, cause that’s
the other really cool thing about Smalltalk and different
thing about Smalltalk is that it really, like, enables
this awesome TDD workflow. And I don’t think I’m gonna
have the time to do that unfortunately. But the TL;DR is this, basically. OK. So if I write a test, and I try to exercise a class that doesn’t exist, like BowlingGame
here, Smalltalk’s, when I save this, Smalltalk’s gonna say, that
doesn’t exist. Do you wanna, what do you want to do? And the first option there is define new class. You just click it and it does it, right. When I try to call a method on that class that doesn’t exist, Smalltalk asks me
if I want to implement that method, and when I
say yes, it drops me into a debugger, right. A runtime, where I have everything available
I need to create the implementation of that class, and
I can expect all the things I need to do so. Right, I’m not in a static code editor here. This is like, living system, right. So I can do so. Just want to return zero. And when I save, my tests pass. So that’s. That’s,
that’s the idea, right. And, and it, it’s small,
but, you know, small changes in your user interface,
you know, can really turn, like a daunting experience
into a really motivating flow, right. It doesn’t take much. So, when I talk about, you know, this power of Pry and, and we’ve talked about some of the plugins and how powerful they are and
how, you know, Pry is so easy to extend, you know, even I can do it. And, and so, I’ve kind of gotten the ball rolling. I pushed a little code up to GitHub. It defines a new command called define-it in
Pry. Right now, it’s just a PryRC, and you can define Pry commands in your PryRC or you can do gems or whatever, and that’s, that’s where
I want to move it. But, this is my attempt to kind of get this workflow going in, in Ruby, right. So,
all right. So here it is. Here’s my PryRC. I’m creating a command called define-it, and then
I’m implementing – every Pry command implements this method
called process, and that is what is going to happen when you call the command from within the Pry REPL, right. And so I’m kind of using this idea that we demoed in the last demo of, when I hit a name error, I just want to automatically generate an empty class definition and move
on. What it will also do is when I hit a NoMethodError, it’s gonna generate an empty
method definition and put you right in there where you need to be to implement it, right. So let’s take a look. So, once again. Oh, let me just show you this real quick, though. So here is a spec and a set of tests that exercise this BowlingGame class,
right. The first test just verifies that BowlingGame is a thing.
The second test says if I ask a new BowlingGame for its score, it should return zero. The
third test says, if I bowl a four then the game’s score should reflect that. And the last test says, if I bowl twice, you know, the, the score should reflect that,
that sum. So, when I run rSpec under pry-rescue,
pry-rescue, you know, it does different things in different
contexts, right. So just like before, pry-rescue’s gonna
break on unhandled exceptions, just like it always
has done, but in the context of rSpec, it’s also gonna break on assertion failures, all right. So you can
poke around and get those fixed. So, here we are. We. We’ve got our first exception, right. It’s the name error. Uninitialized
constant BowlingGame. So let’s define it. All right. Didn’t see it, but it did it. Next. Believe me. All right. So next. Next, we’ve got our next exception here right. Undefined method ‘score’
for BowlingGame. Our NoMethodError. So let’s define-it. You guys
didn’t believe me, but there it is. All right. There we go. We’re in our empty method. Let’s TDD, right.
We just need to make the test pass so we return zero out of there. Ask pry-rescue to
try again. We got another exception here. NoMethodError:
undefined method ‘bowl’ for BowlingGame. So, let’s define-it. Now I feel like we’re
gonna need to keep track of a little state, so let’s. We want to make that the fixnum. We want to return @score out of here now, instead. And let’s initialize @score to be
zero when you create a new BowlingGame. Let’s save that
and let’s try again. All right. That worked. We’re in our last
test here, and we’ve hit our first assertion error,
right. It expected nine and it got five, cause we’re not doing any of the, the totaling yet. So let’s, this is another way you can call edit. You can just ask it to edit the class, and it’ll know what file to drop into. So I feel like we’re gonna want to keep track of our scores now. So let’s just push those fixnums on a scores array. Let’s get our score by reducing those values. That’s how you keep
score in bowling, right. You just add everything
up. All right. Cool. And let’s, let’s initialize it with an array
with initial value of zero as well. Let’s try again. Something’s wrong there. There it is. All right. Four examples, zero failures. rSpec
thought we didn’t fail at all, you know. It’s pretty
cool. So. So what happened there? All right. I mean, basically, you know, we. We, again, we used
Pry to drive our development process. We used
our own Pry plugin there to kind of make that a little bit easier, and within one runtime,
we fixed all of our assertions, exercised our class
and implemented the whole solution, right. No reloading, no nothing like that. So, in conclusion, embrace your runtime and
all things. Don’t read the effing manual. Use a kickass flashlight. If you’re fixing software, use a debugger.
If you’re building software, use a debugger. And when
you use a debugger, use Pry. Thank you very much.

Tags: , , , , , , , , , , , , , , , , , , ,

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *