The Rogues discuss Pat Shaughnessy's book, Ruby Under a Microscope.

Special Guest: Pat Shaughnessy.

 

I’m not sure, but I may have accidentally just taken a sleeping pill.

Maybe I’m not sure, but I may have just accidentally eaten a whale. I don’t know. It’s possible. [Laughter]

What?

So, is this the part of the show where you go over the rules of etiquette and good behavior with guests?

No, this is the part of the show where we get it all out of our systems so that we can behave like adults.

Wait, it’s taken you 145 episodes to behave like adults? [Laughter]

It’s going to take a lot more than that, a lot more.

Hello ladies and gentlemen and welcome to episode 146 of the Ruby Rogues Podcast. Chuck is out today, so I’ll be your host. And with me today is Josh Susser.

Hello from San Francisco.

Avdi Grimm.

Hello from Pennsylvania.

Ruby Rogues alum Aaron Patterson.

Hello from the internet.

[Chuckles] And with us today is special guest Pat Shaughnessy.

Hi, it’s Pat. Thanks so much for having me.

Welcome to the show, Pat.

Yeah. Since this is your first time on, you want to go ahead and introduce yourself?

Sure, yeah. I’m Pat Shaughnessy. I’m a Ruby developer. I worked for a long time at McKinsey, which is a management consulting firm. And now I’m doing some freelancing. And I live outside of Boston and Massachusetts.

And we asked Pat on this show today to talk about typos. No, no, no, not typos. [Chuckles]

I don’t know anything about typos.

[Laughs] We asked Pat on to talk about his book, ‘Ruby Under a Microscope’ which we’ve all been reading. It’s very good.

Thanks a lot. I really appreciate again, having me on. Thanks a lot. And also, thanks for reading the book. It’s a lot to take, so I’m sure it wasn’t easy.

I had a lot of fun with the book. So Pat, I used to do Virtual Machine development. I did Smalltalk and Java stuff. So, this was great. This was a lot of information that I’ve suspected was what was going on in Ruby and some of the stuff I’d learned in various places. But this put it all together in one place and fleshed out all the details and a lot of it felt like familiar territory. But a lot of it was also, “Ooh, wow.” I love the explanations. As a VM implementer, I thought this was a really solid book.

Yeah, this was the most fun I’ve had reading a tech book in a long time.

Yes.

Thanks, Avdi. Thank you.

So yeah, we all seem to be in agreement. But let’s actually start with what is this book? It’s very different from a lot of the tech books we read. Why don’t, Pat, you give us the 10,000-foot view.

Yeah, like what the heck is this? Yeah, so there are a lot of great books out there on programming, especially with Ruby. There are a lot of fantastic Ruby books. And most books are Programming 101. How do I learn this language? How do I learn Ruby? And that makes a lot of sense. If you’re a developer and you want to learn a new language, that’s usually why you buy a programming book, right? So, I wanted to do something different. And I’ve always been interested in Ruby internals and how things work on the inside. And I’ll talk a lot more about that later if we have time. But I just figured it would be really fun to write a more advanced book about how Ruby actually works. And I’ve written a few blog articles about that stuff back in 2012 and they seemed to be pretty popular. So, I figured, “Hmm, there’s some appetite for this.” And I just think it’s an amazing story. So, I think whether it’s a blog post or a conference presentation or a book, I think it’s all about storytelling. You want to entertain people. And I think what’s going on inside of Ruby for me is just this really interesting story that I wanted to tell. And the Ruby core team, I’m glad you’re with us today Aaron. Thanks for coming. You guys have done a lot of amazing work. There’s a lot of really amazing things going on inside of the language that we all know and love. And I just wanted to share that with the world, as well as find out for myself. I didn’t know any of this stuff before I tried to write the book. So, it was great for me to learn it, too.

I have to mention. I was the technical reviewer for this book, so if there are any typos, it’s my fault. [Chuckles]

Yeah, I’m blaming you, Aaron. [Laughter]

As usual. So Pat, I got to say, the thing that I love most about this book wasn’t just that you presented all the information, but that the entire book was a guide to how to experiment to discover all of this information for yourself.

Yeah, that’s it.

Yeah, how to learn all of this stuff yourself. So, it was like, reading the book every time I got to a section that said, “Oh, here’s this question that we want to answer,” and then it was, “Well, here’s how we’ll create an experiment and we can run some Ruby code to learn something about what’s going on inside the VM. And then we can go look at some code or something inside the VM to confirm what we were thinking.”

Well yeah, thanks. Yeah, and I think that’s one of the, or maybe the best thing about open source software, is you can do that. It’s all out there. And I think back. I’ve been doing development for 20 years. I think back to the 90’s when I was doing Microsoft, Windows GUI apps. And there was this wall you couldn’t get around. And what’s going on inside of Windows? And what’s going on inside of Visual C++? Who knows? They know at Microsoft, but no one else knows. I think that’s one of the great things about Ruby, or any open source framework, is that you can find out. You can just go look at the code yourself. And whether it’s Linux, Ruby or Rails or anything, you can just go read the code and figure it out. Yeah, that’s really what this is all about, is figuring out how Ruby works. And then I wanted to also, the other big goal was explain it in a way to people that wasn’t intimidating, that made sense, that made sense to Ruby developers and not just to C developers. If you’re not sure if you want to read the book or if you’re afraid it’s a little too advanced or too technical, I really tried to explain things so that if you’re a Ruby developer it’ll make sense. You don’t need to know all the bits and bytes and Assembly language and C programming, all the real technical stuff, at a detail level. So, I hope that came across. I hope most Ruby developers were able to follow along.

It definitely did. I got to agree with Josh. I got sucked into the experiments. At one point, you’re showing the difference between for and each, and you just did it to show that under the hood, for is just a syntactic trick and it’s actually calling each. But what’s actually always bugged me about for and each in Ruby is the way it leaks a variable in the outer scope when you switch to for. And so, I took that example you started and played around with it so that I could see the instructions in [inaudible]. And Ruby actually takes this extra step to assign that variable up to that outer scope. And I’m like, “Oh, why do you do that?” because that’s a variable leak that I always can’t stand about the for loop. So, it was cool to get sucked into that and be able to play with the examples and see what was happening.

Does anyone even use for loops now?

Well, I used to see them all the time in Rails code. They used to be a fashion in Rails code for some reason. Nowadays, I don’t think I’ve seen it [inaudible]. JOSH: [Chuckles] Okay. In Rails back in the 1.0 days, it was use each in the model or in the controller and for in the view. [Laughter]

Yeah.

I remember that.

And why was this a thing exactly?

I have seen it suggested that for somehow looked better in views or that maybe the people that are making the views would be more familiar with the for concept. But, I’ve never found that terribly convincing. I think each works just as well in a view.

Yeah, I agree.

And logic-less views worked even better.

What?

You’re not making any sense. You’re being illogical.

That’s a whole other episode.

I have a question about the book.

Alright, you get one question, Aaron.

How were you able to fit Ruby under a microscope? [Laughter]

That’s a great question. It’s a really good one.

Well, you know Aaron, Rubies come in all shapes and sizes. I just got a smaller one that fit.

I thought you got a prerelease version mruby because it can fit on really small…

Yeah, that’s what I was going to say, mruby because it’s smaller.

[Chuckles] Okay, now we’re going to get even more feedback about how lame our humor is.

Oh no, it’s just me. You bring me on as a guest to make the humor even worse. It’s okay.

It’s awesome.

I knew this was a bad idea. No, and again, thanks for coming, Aaron. I just wanted you to answer all the tough questions today. I wanted you to be humorous. But really, I just wanted to thank you for all the help that you gave me on the book and for fixing all my mistakes. And not only that, you gave me just a lot of great suggestions for maybe what was missing or just what else I could put it. So, I really, really appreciate it and I think…

Oh, no, no problem at all. I’m glad I was able to review the book. I actually enjoyed reading it a lot. The reason I liked it is because it’s very, it discusses Ruby internals but it does it in a really approachable way. I like that a lot because I don’t think we have a lot of advanced books. There aren’t very many and this is and advanced book. But you don’t have to be a C programmer. But if you are a C programmer, you can actually dive into the source and be like, “Oh okay. I can handle that.” So, I really enjoyed reading it.

Thanks. And I think that’s important because I think people should know. One of the reasons I wrote this book is I think Ruby developers should know how their language works. The way I look at it is Ruby is the tool that we use to solve problems. And for me, the best way to know how to use a tool is to know what the tool is doing. How does the tool itself work? What’s going on inside the tool? And the same thing could be said for Rails, or for any software framework, Angular or whatever. If you really want to be good at using ActiveRecord, if you really want to know what to do and what not to do with ActiveRecord, you have to at some point dive in and learn the code inside of Rails. How does ActiveRecord actually work? What is it really doing? And I think that’s the same for Ruby itself. And the problem is of course, it’s written in a different language. It’s really hard to figure out. And so, that’s what I was trying to do, is just give people that information that maybe they couldn’t get anywhere else.

The main problem with that analogy though is that nobody actually knows how ActiveRecord works.

Right.

You do, Aaron. That’s all we need.

No. [Laughs] Nope.

Pat, you said something in the introduction that goes along with what you were just saying there that I really liked. It said that you could read this book to learn how Ruby’s creators intend for you to use it. And that was just a thought I hadn’t had before, that when they’re creating and designing the language, they have in mind, we hope, intentional usage. How would this be used? And by looking into some of this, we run into that. We see how they are intending for us to use the language. It’s an interesting idea.

I think that came to me when I was, because I wrote the introduction at the end, which is kind of a funny thing. But I was imagining, I don’t know. That really hit me when I was writing a chapter about blocks and closures and how the stack works and how it finds variables, where you reference a function or a block. And all that sort of stuff, chapter eight in the book, when I was figuring that out and writing that, it struck me. There’s a lot going on here. And I think Matz and the core team, when he invented the language he wanted us to be doing that sort of thing. He wanted us to be using blocks in a certain way, and using lambdas and procs and other things in a certain way, sort of like the way they work in Lisp. It’s what led me to write that sentence and that’s what I had in mind. But then other things as well. It applies to modules and objects and classes, all that stuff. They were designed in a certain way to work a certain way. And so, understanding how they work helps us I think understand what we should be doing with them.

On that note, something else I found that’s helpful for understanding how it was intended to be used is I’ve been following the Ruby core mailing list for a while now. And it’s just really fascinating to see. Somebody will pop up with an idea for an addition to Ruby and it’s like, “Oh yeah, that seems like a really neat idea.” And then you’ll see the conversation that ensues. And somebody will bring up some unforeseen consequences of that idea and suddenly it’s like, “Oh wow, that would have been a terrible idea.” So yeah, it’s just another perspective on the thought that goes into this.

So Pat, I did find a few things that I thought were missing from the book.

Okay.

So, I’m looking forward to the sequel ‘Ruby Under an Atomic Force Microscope’. [Laughter]

Ruby Under an Electron Microscope?

So in particular, there was no discussion at all about the efficiency of double-quoted strings versus single-quoted strings. [Laughter]

[inaudible], yeah. No, and I think you’re right. I think there’s a lot missing. And I don’t intend this to be an exhaustive explanation of every single thing that goes on inside of Ruby. In fact, to be serious, I think the biggest thing that’s missing, and I just literally ran out of steam, ran out of energy, was a discussion of threading and multithreading and how that works and how it doesn’t work in Ruby and compare that…

Especially with how fibers now play into all of that, right?

Yeah. And part of it was there are other great books on that. I know Jesse Storimer wrote a book on threading and stuff. And I just didn’t know anything about it and I just didn’t have time and the energy to keep going and keep writing. So, that’s one big thing that’s missing. And there is other, I think, less important stuff missing. But what I tried to cover was what I think, or what I thought was really the fundamental core ideas of the language, starting with parsing. How does Ruby understand your code? I think that’s really interesting. And how does it work? What’s really going on there? Going into the VM and how it works and then the object model, closures and blocks, all that stuff. So, I just picked the things that were most interesting to me and also, in my opinion, that were the most important, so the core identity of Ruby as a language.

Well, I think the things you covered are mainly things that’ll… I mean you could talk about threading, but I think 80% of the time, you’re writing stuff that doesn’t have to do with threading. You don’t particularly care. You’re writing stuff in your controllers or whatever, regular Ruby code. And I think that’s what this book covers, is stuff you need to keep in mind on your daily programming tasks. So, it was very good.

Okay. I like where you’re going there, but I’ve got a one-word response.

Yes.

Refinements.

[Laughs] So, I included those. Was that a mistake? Do you think I should have left that out?

I don’t know. That’s a good point. Maybe we can talk about this a little. Having looked under the hood at how refinements work, and I read the book too, which was good for me because I have not been a fan of refinements so I was anxious to see how it influenced my opinion on them at all, how did you feel about having refinements in Ruby?

How I feel about having them in there?

Yes.

I think it sounds like an interesting, cool feature. I don’t have a strong opinion about whether it’s a good idea or not. I think if it were used responsibly, and maybe that’s the key thing here is most people aren’t responsible enough, but if it’s used responsibly, why not? It could be really effective and helpful. But like most things in Ruby, if you misuse it or use it too much or do the wrong things with it, it could clearly be very confusing.

Right.

Well, I guess the big question is do you have any thoughts on what might constitute a responsible use?

Yeah, as it’s intended. I think if you wanted to change the behavior of something in a specific place and not globally across your app, then I think that could be helpful.

The thing I think that’s weird about that is I see where it’s going. Maybe you want a monkeypatched string but you only want to do it in this class. Whenever I see use cases like that I’m like, “Well, why don’t you just make a private method in the class?”

Right.

And just call that method and pass a string in. Then the other half of me is like, “Well, I’m just not a huge fan of monkey-patching anyway.” So, am I just biased? You know what I mean?

Yeah, it’s interesting. So, reading about the implementation of it, you get to see that it’s this special case in Ruby. There has to be a whole separate field in the structure to manage these refinements.

Yeah. There’s a lot of noise in the C code, a lot of noise about implementing that right.

Right. And so, I have to say that I wasn’t really a super big fan going in and reading about the implementation did not make me a bigger fan. [Chuckles] It didn’t seem like it was a super clean thing that just made sense in the existing system. It was more like, “Eh, to make this work we’re going to have to wrap a bunch of things around here.” And I didn’t see that sway me at all. I can definitely understand the point of wanting to be able to safely change a few things in this context. What extremely worries me about refinements, and I think we have yet to see a heavy usage of it in the Ruby world, so I’m holding out judgment to see if it can be done right. But my concern is now that it applies on basically the module level, what’s going to happen is there is some module influenced by some library. And then because you put something in that space, somehow in your usage of it then you have these inherited behaviors. And there’s not a super easy way that I’m aware of for you to see that at the usage level. If you start trying to figure out what method’s being called and you just start calling ancestors or something like that, that’s not going to help you.

Well, I think there are two answers to that. First, the refinements are lexically scoped. They’re supposed to be lexically scoped, so it shouldn’t affect you outside of a particular file.

Okay, hang on. I got to stop you there. That was true in Ruby 2. I do not believe that’s true in Ruby 2.1, is it?

Really?

I thought their scope was expanded in Ruby 2.1. Am I wrong?

I’m not sure. I don’t know. I’m not sure.

Okay. We’re going to try to get a definitive ruling on that, but keep going.

That’s what I heard too.

And then the other thing is if you use the method method, you can look up what you’re going to call and the source location.

Ah, that’s a good point. I did not think of that. So, what you’re saying is get a reference to the method, then call source location?

Yeah. And then you know exactly where you’re calling.

That’s a good point.

That seems like a lot of work. [Chuckles] I can’t imagine writing code, like normal kind of code to do stuff with that amount of meta programming in it just to understand what’s going on.

Honestly, I couldn’t survive in the Rails codebase, working on the Rails codebase, without the method method. I have no idea what’s going on right now. I have to use that. JOSH: So, you mean as a debugging tool?

Yeah, yeah.

Okay, okay. Okay, that’s a different thing.

Does the Rails team, do you guys refinements?

No, no.

And would you use them in the future?

That’s a good question. I don’t know exactly. So, the problem is we can’t offer… So, first off, there’s the first, most fundamental issue which is that we go back. We support 1.9.

Right, right.

So, we can’t use them from that perspective. But even when we drop 1.9, we can’t make applications backwards compatible. So, for example, since refinements were lexically scoped in 2.0, we don’t know about 2.1, since they’re lexically scoped in 2.0, there’s no way that we could turn all of our monkey-patches into refinements and then offer them to you in the same place. Let’s say for example you’re using, I’m trying to think of an ActiveSupport method, camelize or something like that. If you’re using that inside one of your models, since you didn’t explicitly require the refinement, then it’s not going to work. We have to continue to monkey-patch in order to be backwards compatible with existing applications. So, even if we could use refinements, it’s not going to happen for a long time.

A long time, right.

Yeah.

So, I just did a little Googling to double check. I’ll put the link in the show notes. But according to these notes I found, here’s what it says about the changes in 2.1. It says that in Ruby 2.1, refinements are no longer experimental and can also be applied within a module without affecting the top-level scope of a file.

Right, I think that sounds right, yeah. In 2.0 I think the compromise was you could only apply or use the refinements in the top-level scope.

So, that’s the lexically scoped Aaron was talking about, yeah.

And now, you’re able to, inside of other modules or classes, you can turn them on and use them.

Yeah. So, it looks like that restriction has been lifted. I have not personally played with it or tried it. But that’s…

But it’s still, isn’t it still lexical in the sense of it’s active from where the module opens to where the module end is?

Yeah, it’s all lexically scoped.

Yeah, I guess you’re right. [Inaudible]

In 2.0, they limited the impact of the feature by saying you could only apply refinements at the top level.

Right.

Now, you could do it…

You’re right.

But it’s lexical in the sense that the module keyword introduces the lexical scope in Ruby.

Yes, exactly.

So, you’re right. And it’s not like if I reopen that module somewhere else, I won’t get those refinements unless I also include the refinement.

Right, right. And if you include the module somewhere else, you’re not going to get the refinements.

Okay, which is a fair point. So, most of my fears seem unfounded. That’s good.

Yeah. It’s pretty isolated.

Okay. And that was our sidetrack on refinements. Although, to put you back on point, I will point this out. One of the dangers of this highly technical book obviously, is that parts of it will get out of date very fast. And that’s happened in a couple of areas. I noticed two. One was the refinements. It didn’t really talk about the differences between Ruby 2.0 and 2.1. Another is when you talk about method caches.

Oh, right. Yeah, yeah.

Those also took a pretty big change in Ruby 2.1.

It was ironic. As soon as I finished the book, it was literally being printed somewhere, I met James Golick at a conference and he started telling me all about the amazing stuff that he’s done with, and I think he and some others, Charlie Somerville, on method caching and speeding that up. And now it’s, what, scoped by class or subclass. It’s a much more efficient way of doing it. And that just wasn’t in Ruby when I was writing that part of the book. So, I had to tell him, “Dude, I’m sorry I didn’t cover that.” [Chuckles] So, I just touched on the basic way method caching works. But I didn’t get into the really important optimizations that were made just recently. So, I think, correct me if I’m wrong, so the way it used to work is if you ever added a new method or created a new class or module, the method cache was invalidated and…

There were 15 different things you could do to invalidate the method cache.

So now, it’s only invalidated if…

Yeah, and [inaudible] invalidate globally, yeah.

Yeah. Now it’s only invalidated for the class that you’re changing.

Exactly.

Yeah. It’s basically hierarchically scoped now. So, if you do it only that branch of the tree and down needs to rebuild their method cache.

Right. And they made some important changes to the RClass structure to make that possible, I think. But I just didn’t see that and didn’t know about that when I was covering that part of it.

I really like that change because that global invalidation of the method cache was always a big penalty for using Ruby dynamically.

Yes.

Ruby is a very dynamic language and it cries out to be used dynamically. And so, I really like the change that James made because it rewards us for our ability to use it dynamically, or at least doesn’t penalize us as much.

And I like the philosophy behind the change as well. I was asking Matz about this when I got a chance to meet him, talking about the argument that I’ve participated in and seen where it’s like one the one side it’s, “We should use all these abilities of Ruby to the max and our use should put pressure on implementers to optimize it,” and the other side saying, “We should not use, we should constrain what features we use because some of them just aren’t fast.” And I was asking about that specifically with regard to things that blow up the method cache like extend. And basically he said, “You should use the features that Ruby gives you. They’re there to be used. And the implementers are there to make them fast.”

Yeah, totally. And some of these features are creating methods. That’s hard not to use, right?

Yeah. And then he brought up exactly this change that we’re talking about. At that point, it wasn’t released yet but it was already in core, in the trunk. The method caches have been broken up.

Yeah. So, it was great work. And James Golick has some blog posts on that stuff or conference presentations. And we can link to those later.

Also, I guess this is the same strategy that JRuby uses, or actually used for a while. Now, MRI used the same expiry strategy that JRuby uses.

Yeah, James was telling me that. I think Charlie Nutter helped him out a lot on how to do this, what’s the right design.

And I think some of that actually came out of the refinements discussion, because one of the issues with refinements was how expensive it was. And a lot of the examination of the refinements feature led them to some understanding that let them optimize. So anyway [chuckles]. Hey, so more about the book. [Chuckles] There’s some really cool stuff in the book that talks about the format of the RObject structure and the polymorphic nature of it and how it gets used in different ways. And I guess in the C side of things, you would call it a union.

Right, right, yeah.

And it was great, because at the beginning of the book it looked pretty straightforward. And as you went through the book and kept talking about new kinds of objects, you talk about strings, you talk about blocks and all that, we got to see how some of the quirks of Ruby get explained by that. So, there are things like why short strings are so much more efficient to use. And then there’s that, what, 27 characters or something limit. What was it, 27?

Right, yeah. That was my most infamous blog post. I wrote that as a joke. Well, not as a joke, but I wrote the title and it was called the ‘Never create strings longer than 23 characters’.

Oh 23, yeah.

And I thought it would be obviously a tongue-in-cheek sort of sarcastic title. And I think a lot of people took that seriously. [Laughter]

And they started rewriting their apps or something. I don’t know.

I’ve programmed that way ever since.

Exactly. [Laughter]

So, there was that. But there was also the thing about the compact hashes where if there’s…

Right.

Yeah, that was cool.

Yeah. If there are few enough entries in the hash, then it just makes a little array [chuckles], stores all the values and keys right there. And you don’t need to have all of the other objects allocated.

That was really interesting.

Right. The hash chapter in general is on my list as one of the parts I thought was super cool in the whole book.

Yeah, so a lot of things here. One point I want to make is again, the Ruby core team has done a lot of work, a lot of work over many years, to make Ruby faster and better. And these are just some examples of the lengths that they go to. The Ruby C code is very complex and hard to understand, often because of these kinds of optimizations. And they do that to speed things up and to make our apps faster. So, kudos to them and thanks to all the hard work from Matz and Koichi and Aaron and all those guys because they’re really helping us out. The other point I want to make is, back to hashes, you just mentioned that James. I think another thing I want people to get out of this book is some touch on or some taste of computer science, of the computer science behind Ruby and behind the way Ruby works. And we’re standing on the shoulders of giants. And everything that Ruby does was actually, is based on work and research that was done, not in the 1990’s but 1950’s and 60’s and 70’s and 80’s. And hash tables are just one example of that. And the way I think of it is I think most Ruby developers, maybe more so than other language communities, a lot of Ruby developers aren’t computer science majors, didn’t go to college to study computer science. They might have majored in English or they were musicians. I didn’t major in computer science either, but I got into this from some other path. So, you may never have learned the theory behind hash tables or garbage collection or how parsers and compilers work. And so, I think one reason to study how Ruby works and one reason to read this book is just to get a taste of the computer science theory behind everything that we’re doing. And I think it’s important. It’s important, not that you know every single detail in every single C pointer and structure inside of Ruby, but you should know what a hash table is and how it works and the basic idea behind it. And you should know what garbage collection is and what it means, at least at a conceptual level. And I think that’s really my biggest, aside from storytelling and entertainment, my biggest goal of the book is really to, at a high level, at a conceptual level, show people with a lot of diagrams and a lot of words how the computer science inside of Ruby really works.

How much of the computer science stuff did you know before going into this and how much did you learn along the way?

I think I learned almost all of it along the way. I was thinking about that recently. I might have had a vague idea of what a hash table was. You put it in, you get it out with a key, and somehow there’s something called a hash function. But I didn’t really know. And so, I think that’s what was super exciting for me about writing this book and about doing the research behind it, was finding out.

Right.

And again, it’s open source software. Ruby, it’s all out there. You can just go read it and find out for yourself. So, it was super exciting to really walk through. When I save a key and a value in a hash, what actually happens? When I create an object or set an instance variable, what is Ruby really doing? And it was super fun to see just the nuts and bolts of what was going on inside, but also to get a sense of the theory underlying or underpinning that. It was really interesting.

So, the hash table sticks out or the hash chapter sticks out as such a cool example because it’s like you say, you talk about this algorithm, you talk about how it works, how items get sorted into buckets, and why that hash function is so important. And then you’re like, “Wow, so we’ve learned all this. Let’s see if we can break the hash and just [inaudible] a terrible hash value,” and, “What happens to performance?” And you play with it and do the experiment. And it’s like, “Look. Ruby falls off a cliff.” [Chuckles]

Right. That was the fun one. Yeah, I remember that. That’s one of the first experiments I did. And again, it points out how important, this tiny little detail in Ruby. There’s actually this wacky bit of C code that Matz and the team got from, I think it was University of Berkeley or some place that does the hash function. Sorry, the hash table code generally. There’s actually a newer algorithm they’re using for the hash function called the murmur hash or something. So, one little tiny detail like that has just an enormous impact on how hashes work. And hashes are underlying, we use hashes every day in all of our code.

Yeah. So Pat, speaking of hashes, there was actually a part of the book that I found horrifying.

Uh oh.

Uh oh. [Laughter]

No, not because of the book, but because of what it was explaining. And that was the section where you were talking about keyword arguments, section 4.2, or experiment 4.2, keyword arguments. And you showed how you could monkey-patch the hash class and essentially break the entire language. [Laughter]

But how is that new?

So, what’s new?

You can monkey-path plus.

Well, okay. So, from a VM implementer perspective, I’m used to there being a kernel VM and what goes on inside that kernel can only be affected by changes within that kernel. And then you build the rest of the language on top of that. And that’s much the way that Rubinius is built and JRuby. But MRI, apparently you get to go in and you can change methods in the Hash class in Ruby and that changes the functionality of the inner workings of the VM.

Because Ruby is using hashes internally. I too was surprised by that when you showed how just by constructing these keyword arguments it was making this hidden hash and then it was asking it if it had these keys or whatever. It was like, “Wow, that is kind of crazy,” but, me too.

Well, yes.

You can do tons of stuff to break the language though. It’s just that that particular behavior, it’s not required. For example, JRuby doesn’t have to implement keyword arguments that way.

I’m not encouraging people to break the language. [Laughter]

Oh, it’s too late now.

That’s my job.

Except as an experiment.

Yeah, it’s too late now. [Laughter]

It’s an “experiment”.

Everyone, override the .hash function on object.

And see what happens.

[Inaudible] one.

So yeah, the message is read ‘Ruby Under a Microscope’ to learn what you should not do in your application. [Laughter]

Well, you talked about just digging in and actually watching Ruby do its thing and seeing what it actually does under the covers. One of the things that I found most interesting about this book was seeing you use some tools that maybe not everyone is familiar with to dig into Ruby internals. And I’m not just talking about reading the C code, more about the tools that you used to looks at Ruby dynamically. And I’m curious if you could talk a little bit about if somebody wants to get an interesting look at what’s going on under the covers and learn what Ruby can tell you about itself dynamically, what some of the tools they should look at?

That’s an interesting question. I’m actually very old fashioned. I only primarily did two things. One was I used gdb, which is a C debugger, to set breakpoints and to step through the code, and particularly to look at the C stack trace, just to get a sense of where I was in time and what was happening in what order. So yeah, people, if they want to do that sort of thing, they should get the C code in their machine, they should set up the C compiler clang or gcc, and learn how to use gdb a little bit at least. But to be honest, the most mileage I got was by, and the most useful technique I had was very simple and very old school, which was just putting print statements, printf statements in the C code. And that was a way of… it was even more than gdb. It was a way of just giving me a sense of what happened in what order in time. And that’s one of the most confusing things to figure out. Not only is there a lot of code that’s hard to understand, but it’s very hard to figure out what happens first and second and third and what calls what.

Right.

So, I know there’s better, maybe there’s more sophisticated tools out there. I know there’s DTrace and Aaron maybe you can mention that if you want. I know you did some stuff with that last year. But for me, printf was just a great, it was a very simple way. Just adding a print statement here, recompiling Ruby, and running some test Ruby code and seeing what was outputted.

But you also did some interesting things with dumping out disassembled yar of bytecode and also some stuff with object space as well.

I agree, yeah.

Yes, yes. You’re right. I’m sorry. So yes, the thing in the beginning in chapters one and two when I talk about ripper, which helps us understand tokenization and parsing, that was really helpful. Yeah, the disassembly, that was a huge thing. So, I think it’s chapter three I get into that, chapters two and three. And yeah, that was a hugely helpful thing because you really do see that language that Ruby’s compiled into, and for people who didn’t know that. And that was one of the things that really shocked me. I had no idea that Ruby had a compiler. I always thought Ruby’s an interpreted language. What do you mean there’s a compiler? This isn’t Java. What compiler? But yeah, there’s a compiler running in there. It produces bytecode, just sort of like Java does. And it was fascinating to learn that, how all that stuff worked, and to see. Yeah, that was another very useful tool, was just to see the bytecode that was generated for particular Ruby scripts or method calls, whatever.

If I were going to pause this podcast and go play with Ruby disassembly right now, what class and method would I be looking for?

So, it’s called, I think it’s RubyVM.

Yeah, InstructionSequence.

Yeah so, exactly. So, there’s a disassemble or disasm method on that class, which is RubyVM InstructionSequence. We can leave a link to that in the show notes maybe.

Cool.

Yeah, it’s very easy to use. You just take a string which contains some Ruby code, pass it into that disassemble method, and it just prints out all the internal yar of bytecode instructions. And that can help go a long way toward just understanding how things are working under the hood.

Aaron, do you have anything to add about poking around in Ruby’s internals?

So, I like to read the vm_core.c file. That’s awesome. Actually, what you should look at, my favorite file, is let me get you exactly the name here, insns.def. If you go check out the Ruby source, get that file. Look at that file, because it’s a file that contains all of Ruby’s instruction sequences and descriptions of what those instruction sequences are. So, when you go and disassemble some method or whatever, if you go dump the instruction sequences for some method, you won’t necessarily know what they mean. But if you go look at this file, every one of the instructions is listed in there with documentation about what it does. So, you can look at that code and then read this definition file and understand what it’s doing.

Yeah, I remember that was tricky to figure out in the beginning when I was getting started, because it’s not a .c file.

No.

And I was grepping and searching for, “Where is this instruction defined?” like the send instruction or whatever, the getlocal instruction. Where do I find this? And eventually, I found it in this .def file.

So, that’s a great tip.

The def file is actually parsed and turned into a C file.

Yeah. And Pat talks about that in chapter three. That was pretty interesting, using basically meta programming to create the instructions.

So, there’s actually a method, this is not covered in the book, there’s a function that lets you load instruction sequences. But it’s not exposed to the public. If you do a little bit of fiddle code, I could probably give you a snippet. But it’s possible to expose this function and allow you to actually load bytecode. So, theoretically you could get the bytecode per method, manipulate the bytecode, and then load that back up.

Wow. That’s kind of scary.

Yeah, it’s possible.

That’s cool, yeah. And one of the cool things on Rubinius is that it actually allows you as a standard feature to output the bytecode. So, you have a real compiler, right? So, you have a Ruby compiler. And it can save out bytecode that you can then later read in and run. So, I don’t think MRI does that. You can use these tricks to look at it, but you can’t save the bytecode in a separate file and then run it later as if it were Java.

Right. I thought your treatment of Rubinius was one of the best arguments I’ve seen for why Rubinius is valuable, that we can for so much of the stack, we can just go and read in simple Ruby code what this particular method does. And that really turned out to be interesting. You had some really good examples of that.

Yeah, thanks. And I wish I had more time to write more and learn more about Rubinius and JRuby and other versions of Ruby. But it was just, I did want to touch on those and show people that there are other ways of doing things and other versions of Ruby and be able to compare and contrast them. But I only had enough space and time to handle, just to scratch the surface of Rubinius and JRuby. But it was a lot of fun.

Speaking of Rubinius, I know that one of the challenges of working on alternate VMs, JRuby, Rubinius, has to do with the fact that MRI was developed without a formal specification. And it just grew up organically and the implementation was the specification for the language. Oh, if it runs, it runs. This is Ruby. So, there’s some stuff that you covered in the book that looked like the kind of stuff that would drive me a little crazy, trying to implement [chuckles] or to understand why it was that way and if it really mattered, like in chapter six when you were talking about modules and sharing and how all that stuff works. And it was like, “Well, okay. When you include a module, it shared the method table but it doesn’t share everything.” So, there are changes that you can make to the module after it’s been included that will instantly show up in all the classes that have already included that module. But there are other changes you can make that will not show up. [Chuckles]

Right, yeah.

I got asked that question on stage once, by the way.

Oh.

What happens if you include a module again in the class hierarchy? I’m like, “I have no idea.” [Laughter]

Right. I don’t think these are, for me it’s not like I’m recommending that you do these things or that this is an important feature of the language even. For me, it’s important in a scientific way. It’s a way of researching or getting to the question of, or answering the question how does Ruby work? How do modules work? What happens when you include them? And doing these wacky things, the same thing with the hash, right? Breaking the hash, using a poor hash function, not something I’m telling you that you should do. It’s an experimental trick. It’s a way as a “scientist” for me to figure out what’s really going on, on the inside and demonstrate, prove that the theory is correct.

Oh, yeah. Yeah, I’m not knocking our approach in the book at all. But I look at these things and I’m wondering, “Okay, is it that way by accident? Or is it that way intentionally?”

Oh, good question, yeah.

And you didn’t build the Ruby language, so you’re not the person who can answer that question. But I love that the book shows all of these things where I know now. “Oh hey, this is a thing that I would love to ask Matz the next time he sits down next to me on a plane.” [Laughter]

Because that has happened.

Yeah.

I was so lucky to meet Matz and I gave him a copy of the book. But I didn’t think of asking these tough questions. I was just like, “Thanks for creating Ruby. It was super fun to write the book.” I signed a copy for him. But I didn’t. I should have asked him, why do you not share the method table when you include a module?

Right. And I suspect a lot of that stuff is just yeah, what you said, it just grew organically and just is the way it is. Or maybe there are subtle reasons for some of these design decisions.

I think it’s amazing you talk about understanding how all this works. A lot of times, we see people talk about how Ruby leaks memory. And whenever they do that, I just want them, now I’m just going to want them to read your chapter on blocks and closures, because that’s whenever I look into the code, nine times out of ten, it’s they’re keeping a bunch of closure references around.

Right.

And you can see how that works. It copies all this memory into the heap and it has to live for the length of that thing. And that’s your leak.

That part of the book was the most fun for me, chapter eight and the part about how blocks and closures work. And I think it’s one of the most beautiful features of the Ruby language, how you can in this elegant way pass in a function or a lambda to another one. And then when I was learning how Ruby worked, that was the most fun and interesting part of it, learning how blocks are handled internally, how they’re passed around, and then yeah, how when you create a closure how they’re copied out into the heap. That was a big moment. It’s was like, “Oh, I’m getting this. I can see how Ruby works here. When you create a closure, it’s put into the heap and it stays there forever, as long as you’re using it. So, that was one of the big “Aha!” moments for me was when I figured out how closures worked. And I think that’s important for Ruby developers to know that.

That explanation I thought was extremely valuable, in particular for the comparison or the discussion of the optimization that has gone into blocks. When you pass a proc into a method, it has to create the extra context. But if you call it with a block, then it can share the context of the method.

Right, right. And it was also one of the most difficult things to figure out, was how blocks work and how the pointers to the block structure are handled. But yeah, blocks and procs are really the same thing. And a proc is a wrapper around a block so it can be handled like a Ruby object.

Yeah.

But yeah, it’s all very confusing. But I tried to explain that stuff in a way that made sense.

It was good because it helped you understand sometimes why there might be multiple syntaxes for something. Like you have block given in yield or you can give the extra parameter with the ampersand in front of it and get the actual proc object. And there’s even been talk in the past, why do we need both of these? Shouldn’t we just have one way to call a block? But it’s like Josh said, well when you only use yield, then Ruby knows that it’s only going to happen in that method and it can take a few shortcuts, whereas if you pull it up into an object, who knows where you’re going to send that object? And now it’s got to start copying some memory.

Yeah. And I think blocks are definitely a special case inside of the Ruby C code. But I think that was a great decision and it’s one of the things that sets the language apart. For example, this is probably going to get me in trouble to say this, but Ruby and Python are very, very, very similar. They’re almost like the same language. But when I compare the two, I think the fact that you can use blocks the way that you do in Ruby is one of the things that I love about Ruby that I find missing in Python. But I’m not a Python developer, so I’m sure I’m going to get hate mail from those folks about why Python is actually better than Ruby. But that was one. So, my point is only that blocks are one of the most elegant features of the language. And so, it’s really neat to see how they work internally and how they’re handled. And I think for me that was the most fun part of the book to write.

I’m just amazed they were able to finish the language with such an important blocking feature.

Oh, no Josh, no.

I thought Aaron was supposed to give us the puns. [Laughter]

Oh, I haven’t had my coffee today. I can’t do it.

It’s alright, Aaron.

Aaron gives us great emoji instead. [Chuckles]

Too many blockers. [Chuckles]

Oh, there we go.

Alright, well we’ve been talking for about an hour. What else do we need to cover before we move on?

I [don’t] know.

I have one more. I loved the garbage collection chapter. When you took on garbage collection, I thought, “Wow. This is a big topic.” And I was a little worried. You did a great job. You really went pretty deep into it. Simple mark and sweep, “How does that work?” and then, “Okay. So that’s not ideal. Where can we go one step more?” and just showed how Ruby’s algorithm has evolved over time. And I talked about how some other parts of the book hadn’t caught up with some of the most recent advances, but actually this part had when you mentioned the changes in 2.1 and all that. So, it was just really cool. You took on this really hard core concept in a super accessible way. It was great.

Well, thanks a lot. And that was not easy. And a lot of that, I have to thank my editor Bill Pollock from No Starch. So, he’s not a developer or a Rubyist. He didn’t help me with garbage collection. But he helped me pull that together into something that was understandable. And it was a challenge. I was trying to finish this book in a reasonable amount of time last year. And it was just dragging on and on. But I really wanted to get to garbage collection. I just felt it was important enough and I couldn’t leave it out. And I also thought it would be a good way to end the book. It’s like the death of a Ruby object. How do things get cleaned up and reused again. But it was tough pulling that into a format that made sense and that’s where Bill Pollock really helped me out. So, thanks a lot to all the folks at No Starch for helping me improve this. So, I did a version of ‘Ruby Under a Microscope’ in 2012 that was just on my own. And the version I did last year, I think came out to be a lot better with some professional help. That could be a whole other podcast for you guys, self-publishing versus traditional publishing. [Inaudible] Avdi has the [least] to say on that topic. But all I want to say is I got the best of both worlds. I was able to write my own eBook one year and the next year, do it with professionals. Anyway, back to garbage collection. Yeah, that was a tough topic and he helped me really just scope it and shape it in a way that made sense.

Yeah, Pat, I’ve got a question about some of the terminology in that chapter. So you talked about young objects and mature objects and the Eden. You talked about Eden as the place where objects were born. When all this stuff, generational garbage collection, when that was being developed, I guess in the 80’s, 90’s, I guess it was the 80’s, we called those things…

I think it was actually earlier. It was 60’s and 70’s probably.

So, probably the research. I remember it was becoming available in commercial implementations in the 80’s.

Right, right.

And I would go to the OOPSA conferences and people would be doing papers on generational garbage collection. But they would talk about the place where objects were born was called the nursery. And then they would move through several generations and then when they got to the point where you stop doing the copying and you started doing the mark, sweep, the mature objects, they called that tenure.

Right, right.

So, you could tell this stuff came from academics. [Laughter]

Right, yeah.

Yeah, exactly. Exactly.

Oh, that’s maybe a good thing to point out there. It seemed like Pat, and correct me if I’m wrong here, but it seemed like for the most part, Pat tried to use the terminology that you would see if you were digging inside of the Ruby source.

Yes, exactly. Yes. That’s a great point. I should have said that earlier. There were a lot of times, not just with garbage collection but in many other parts of the book where I didn’t really know. So, another example is, is it a meta class, a singleton class, an [inaudible] class? There’s this whole other, not a debate, but different people use different words for that. And I tried not to impose any opinion on that. I tried to use the words that Matz and the core team used in the code, so same thing with garbage collection. Although a lot of that stuff in that chapter is not about MRI. It’s about Rubinius and JRuby. But I would just use the words that I would see in the code. Exactly.

Okay. Yeah, so that makes total sense then. And I had that impression as well.

And again, Aaron, you got some great suggestions on garbage collection. I think you helped me add a whole other piece to one of the experiments. So, you had some great contributions there.

Thanks a lot for that.

Yeah, of course. No problem. It’s my pleasure.

Who wrote the foreword? Couldn’t we get somebody good for the foreword? [Laughter]

That was really awesome, Aaron. Thanks again. I don’t know how to…

Oh, no, no. No problem. No problem. I’m happy to do it.

Yeah, it’s a pro tip. If you’re going to write a book about Ruby, get Aaron Patterson to review it and write a foreword for you.

Alright, let’s do some picks. Josh, you wanted to go first.

[Chuckles] Yes. Yeah, I just… time and all that. Okay, so I’m being lazy about picks right now. [Chuckles] So, you probably all heard of these by now, but just for the record xkcd.com/Now is the best world clock I’ve ever seen, so go check that out.

It is awesome.

And then, the new thing, Atom.io, the Atom editor from GitHub. I’ve played with it for a whole hour now. And it looks pretty cool. I think it has a lot of potential. It’s basically… people have compared it to Sublime Text in its functionality and feel. But it’s build mainly in CoffeeScript and it uses CSS for all the styling and theming. So, it’s meant to be extremely hackable. And the thing that I’ve noticed in that hour or so of playing around with it is that it seems like the kind of thing that I would build. It’s like the people who built it think a lot like I do. So, there haven’t been much surprises. Everything’s made a lot of sense to me. So, I’m looking forward to playing around with that more.

And that’s it for me.

Avdi, do you have some picks?

Well, I’ve got one. So, you know how Google has this thing where they come up with really neat technology and then they just completely fail to market it well? [Laughter]

So, for a long time, they’ve had a feature where if you’ve got an Android phone, I don’t know if you can do this on an iPhone, maybe you can. But if you’ve got an Android phone, if you’ve got Google Plus, you can have the phone automatically sync your photos straight up to the Google Plus private photo gallery. And this is not terribly unusual. I think Facebook has copied them since then, so you can have your stuff synced to Facebook immediately. And it’s a nice little backup in case you dump your phone in the lake. And it’s also convenient because once you go to your computer and you want to post some photos from your trip or something, the photos are just right there in the cloud. So, it does that. It’s very nice. But that’s not super unusual. They’ve also been incorporating some really nice photo editing capabilities into the online web app. And that’s cool too, but again not super unusual, but worth checking out. What’s really interesting is that several months ago, they rolled out something that they call Auto Awesome, which is the worst name ever because it’s meaningless.

But, at a base level what it means is whenever my stuff gets synced to Google Plus Photos, it saves the original copy of the photos but then it also runs some automatic enhancement on them. So, stuff like if a picture is washed out, it’ll punch up the color a bit. If a picture has some blurriness, it’ll sharpen it a little bit. Particularly, if there’s an area that was so bright that it just completely washed out or if there is an area that is super deep in shadow, it’ll touch up just those areas to bring out the detail that you couldn’t see before. A lot of little tweaks that are just barely noticeable unless you’ve flip-flopped between the original and the enhanced version, but it works really well. I can’t think of an instance yet where I prefer the original to the enhanced version. It’s all very subtle and it’s a bajillion times nicer than going in manually and fiddling with stuff in the photo editor to try to punch up a photo a little bit. So, it’s really, really nice. And that just happens automatically. And it’s gotten to the point where I just wait until a photo gets synced up and gets Auto Awesomed before I post it anywhere, because I know that version will be nicer. But then, they’ve gone a step beyond that too where they’ll take some of your photos and just do random awesome stuff to them. And it’s not destructive. You still got the originals. But if you take a sequence of photos right after each other of something that’s in motion, it’ll just automatically make a gif for you, the action happening. Or sometimes, it does little collages. Lately it has taken to noting that a series of photos was from a particular outing or something and just putting the photos and videos all together with some musical backdrop and making it a little 30-second video of that outing. [Chuckles] And it just pops those into your collection. They weren’t there before and they just appear there. It’s like, “Hey, you’ve got some new stuff here.” And often, it’s actually, like they say, kind of awesome. So yeah, it’s like the coolest thing online that nobody’s talking about. And it’s totally worth playing around with Google Plus, just for their photo stuff. And that was really long. So, I’ll just end it at that.

The Auto Awesome feature was clearly programmed by passionate ninja rock stars, I think.

Naming, you can tell by the naming. I also feel compelled to point out that Avdi just said ‘gif’. And last week, I said ‘jif’ which I’ve been taking flak for. \

Do we have to fight now?

I know, right? Just to be clear though, I prefer the way Avdi said it. I only said it the other way because I thought that had been definitively proven correct.

[Laughs] Well, if you’re a freedom fighter, CompuServe defined the word and said it was pronounced ‘jif’ and then they were jerks and exerted IP control and tried to break the internet. So, I’m all for pronouncing it ‘gif’.

Yeah, so stick it to the man.

Yeah. [Chuckles]

So, now we get to change it. Alright, there you go. There’s the Ruby Rogues take. We are saying ‘jif’ in order to fight the power. That’s it.

‘gif’

‘gif’

‘gif’ yeah, geez. [Inaudible]. [Laughter]

Okay Aaron, save me from this conversation. Your picks, please.

Yeah, I’ve got a lot of picks. I usually post them to my Instagram and also Twitter. So, check them out there.

That’s usually my cat. [Laughs] Man, I don’t know. Let’s see. What’s on my desk? I have a ‘Ruby Under a Microscope’ book. That is my pick for the week. [Laughs]

We should do that as a book club some time.

[Laughs] No, man, I don’t know. I guess I choose SparkFun.com because I’m spending a lot of money there lately for some reason. Go to SparkFun.com. You can make robots and stuff, which is what I am doing.

That’s amazing.

[Laughs] Well, I’m working…. okay, I’ll tell you what I’m doing. I am extremely jealous… okay, I’m working on a system to identify my Magic cards and I’m extremely jealous of my friend’s robotic system made out of Legos. But I don’t want to spend the money on Legos. So, now I’m trying to build a robot without them.

[Laughs] Wow.

So, that is what I’m doing.

So many emotions wrapped up in that, envy and…

Yes. [Chuckles]

Joy, envy, trial, tears.

That was great. [Chuckles]

Alright, is that all your picks?

That’s all my picks.

Okay. I’ve got a few. First, I’ve been doing a lot of working with hypermedia lately, which basically means that I’ve made all the mistakes you can make when implementing your own hypermedia API now. And so, I appreciate them. So, there’s this thing I’ve seen on GitHub called DocJSON which is another hypermedia format, like Collection+JSON or HAL. But it talks about some of the flaws with those and why they’re trying to build a new format and stuff. So, that’s of interest to me. If you work with hypermedia formats, it might be of interest to you too. Then I saw a good blog post from Envy Labs about not every object being an ActiveRecord object, not every model being an ActiveRecord model. And I think that’s one of the killer things I have known for a long time and I see people struggle with still once they get in the Rails mindset and they have that app/models folder. They think that everything in there has to be ActiveRecord. And it’s incredibly powerful to just remember that you can be able to insert a class that’s just a normal class. And this blog post talks about that. And then the third thing, just for amazing fun, I was talking with a co-worker, Jared Ning the other day. He was house hunting and got to talking about building our own houses. And he dropped this link on me of 33 amazing ideas for basically inside your house. And they’re absolutely amazing. They made me want to build my own house right now using all 33 of these ideas, and a billion more. It’s super cool. You got to go check it out. Those are my picks. Pat, what do you have for us?

Real quick, before I get to the picks, I just want to do a couple of shout-outs, just thank Peter Cooper for all the support. And he’s just encouraged me for so long and helped me have enough confidence to write this book. And also, Xavier Noria from Barcelona was my technical reviewer in 2012 when I self-published it. And so, thanks so much for your help. And of course, Aaron thanks for all the work you did last year. So, for my picks, I have an article. Actually, I wanted to pick one of my own articles, which sounds really egotistical and selfish. But I know you guys are going to do an episode on gem. But I was really saddened by Weirich’s passing. And I was just looking back happy that I had a chance to interview him. So, I wanted to put in a link to an interview I did with Jim Weirich back in 2012. I read it again today and it was a fun conversation. We talked about the job description of a computer programmer. That was very interesting. And I also called him a technical storyteller, which I think is a great way of describing Jim, at least one side of his personality. And actually, in that interview we talked about an article by Michael Feathers. I’ll give you that link in a moment as well. It’s called 10 Papers Every Programming Should Read, or something like that. And it’s a really fascinating list of articles, academic articles, from a long time ago. And back to the point with my book, which is I wanted to encourage Ruby developers to learn something about computer science and learn about how Ruby works. So, this is a great way of, Michael Feathers has a great list of old academic articles that you can go read that are really fascinating. So, I’ll give you that link. And then on the same topic, a friend of mine, Mike Bernstein from New York works at Code Climate. He’s also famous for reading academic articles and He tweets them quite often, so follow him on Twitter, @mrb_bk. And he also did a fascinating presentation called Distributed Systems Archaeology or something like that. So, check that out, where he goes through the history of academic research and talks about a lot of amazing academic papers that again, you can read. So, I’ll give you guys these links. A lot of great things you can go read up on about computer science. But yeah, that’s it. Thanks. And thanks guys for having me on today. It was a blast, a lot of fun.

Awesome. Thank you very much for writing the book and then coming to talk to us. Our next book club book, we are going to do ‘Object Design’ by Rebecca Wirfs-Brock and Alan McKean. So, we’re going to get in touch with them and see when we can get them on the show. But the full title is ‘Object Design: Roles, Responsibilities, and Collaborations’. So, it sounds awesome. I think we’ve told that it was one of the inspirations for POODR, which we all loved. So, that’s the book we’re working on next. Go ahead and grab a copy and read along with us. And I think that’s it.

Thank you everybody and we will see you next time.