In this Book Club episode, the Rogues talk to Kent Beck about his book, Smalltalk Best Practice Patterns.

Special Guest: Kent Beck.

 

I actually only have really one good solid question for him which is, “Will you marry me?” [Laughter]

Hey everybody and welcome back to Episode 23 of the Ruby Rogues podcast. This week, we have six programmers on our panel. We'll start out with our guest; we have the amazing Kent Beck, who is the author of the book we are reviewing this week -- Smalltalk Best Practice Patterns. Sorry, I had to look at the book. Kent, why don’t you tell us a little bit about yourself, and then we'll introduce the other panelists.

Well, you guys are welcome to just call me ‘amazing’ if you want.

Okay.

Or just V. That’s also fine. So I've been a programmer for… I was thinking about this the other day… almost forty years. And I'm currently employed several places; I'm contracting at Facebook, and no, I can't change the profile back. And I'm also chief scientist at Iterate, which is a small consultancy in Oslo.

Oh, interesting.

I think one of my first introductions to you was also some of the stuff you do with Extreme Programming and things like that. So, not just what Kent is doing, but what he’s done; what he has contributed in the community in a lot of ways, for a lot of years. So we really appreciate him launch this book. Also on our panel, we have David Brady.

Hi, I'm David Brady, I run Shiny Systems Consulting… well, Shiny Systems anyway. I blog at heartmindcode.com. And I'm doing my level best to contain my ‘squee’ being on a call with Kent Beck. Kent, I was a low-level Win32 programmer, C Assembly programmer, and had been for about a decade. And I was headed down the .NET rut at about the time that XP Explained: Embrace Change came out. And that book hit me like a thunderbolt, and then I ran into like two weeks later, Martin Fowler’s Refactoring book.

And those two books, permanently brain damaged me programmer, and I was unable to continue writing procedural static crappy C/C++ code. And ten years, eleven years later, I'm now a Ruby programmer. I still do a bunch of other languages; I picked up Smalltalk at the beginning of this year, and so I actually have read through the Best Practice Pattern book, and I think it’s awesome. And so okay, that's my elegy for mister amazing. Sorry, I don’t feel comfortable calling you on a first name basis, but maybe later I´ll start to call you ‘the’.

And that’s the end of my introduction -- which is mostly me, basically kissing up to Kent. [Laughs]

Induced brain damage. It sounds like a government program.

Yes. Actually, one last thing; and that is that I also do ADDCasts with Pat Maddox. Several people have asked me if we're still doing that, and the answer is yes. We are just really, really swamped with the contract we are working on right now.

All right, also on our panel this week, we have James Edward Gray.

Hey everybody, I'm James Edward Gray II, and I literally learned Smalltalk to read this book.

Awesome. Also on our panel, we have Avdi Grimm.

Hey, Avdi here. I'm Chief Aeronaut at Shiprise, and I blog on programming topics Avdi.org/devblog. And since we are doing odes to Kent, I just wanna say thank you, for unknowingly participating in my Computer Science education. I pretty much learned everything I know by spending hours and hours and hours reading wiki wiki. And I know you’re a big contributor there, so thank you very much for that.

I'm glad you found it helpful.

All right. Also on our panel, we have Josh Susser.

Hey, good morning. Still getting over a sore throat, so I'm a little froggy today. So, I'm a former Smalltalker. I actually… you can blame or credit Kent with a little of my career trajectory, in that he got me to come work at Apple and do Smalltalk there. So, thank you or damn you, Kent.

And really nice to brush up on Smalltalk and look at [inaudible]. So that’s enough about me.

All right, and I'm Charles Max Wood. Two things that I wanna mention: one is that I have a testing

or Ruby or Rails course that will start the beginning next month. And I also wanna point out that when I was reading this book, I've been learning Objective-C to program on the iPhone, and I was struck with how similar some of the syntax and things were between Smalltalk and Objective-C.

Complete coincidence!

[Chuckles] Sorry.

So anyway, I thought I’d point out. Anyway, let’s go ahead and start the show. One thing that I wanted to point out real quick before we get going is just that when I picked up the book, I kind of expected it to be, “Here’s how you program Smalltalk well.” And you know, obviously I expected there to be some lessons I can apply with Ruby. However when I started reading it, it really struck me that what I was reading wasn’t a book about Smalltalk, it was a book how to write good code and good object oriented code. And so some of it is about the expressiveness of your code, and some of it is about how to manage objects and things like that, and how to think about sending messages between objects. And so ultimately, the fact that it’s centered around Smalltalk is kind of just a feature, rather than actually the center of focus of the book. So anyway, anyone else have something to say?

Yeah, kind of along those lines. Kent, we are kind of obsessed with definitions, although it can often turn out kind of comical when we do try to define something. But your book starts the same way. You actually go through and define Best Practice and then Patterns, which I'm particularly interested in the definition of ‘patterns’, because I think in programming, we have so many ideas like design patterns and then idioms and refactorings and stuff. So, I was just wondering if maybe you can talk about what are the patterns in your book.

So are you asking about ‘patterns’ sort of in general, or the patterns on the book? Like the specific patterns.

Yeah, I was asking more about the specific patterns in your book, but maybe it might be interesting of why you chose that term, you know, in light of things like design patterns and stuff.

So my involvement with patterns go back to my undergraduate days, and I encountered the Christopher Alexander’s The Timeless Way of Building, which I couldn’t afford, so I read Standing Up in the University of Oregon bookstore, like 45 minutes at a time. And they kicked me out and I came back a few days later and read a few more chapters.

So I was familiar with that patterny style of describing stuff. And a few years after I started programing, I got this déjà vu sense, “Oh, I programmed this before.” “Oh, isn’t that what patterns is all about?” So I tried and failed to apply the pattern’s style to describing these recurring experiences I had with programming for six or seven years, before anything really came out that was recognizably a pattern.

I remember pretty clearly, it’s like 1988 when you showed maybe Alexander books and started talking about patterns.

Yes, that's the first published stuff. So Ward Cunningham and I were walking at Techtronics , and we were trying to apply these pattern’s ideas. And the basic premise is there are few unique problems, and there are many, many recurring problems -- in any kind of endeavor. And you want to apply creativity and uniqueness to the unique problems, and you want to just… for the problems that happen over and over again, you want to just solve them the way that they usually works, and not waste any time on it. So the patterns are trying to capture those moments where you just go, “Oh, I've written this before. I know how to do this.” And it just rolls up your finger.

That’s a beautiful application of, “Make the hard things possible, without making the simple things hard.”

Yeah. And it’s even… you are trying to make this simple things really easy. So the way I wrote this book is I one day decided I'm not going to type another line of code. I'm not going to type a single character unless is know what pattern I'm following. So I would say, “Okay, what's the name of this class?” And I'm going to call it contract. Well, why? Oh crap, now I have to go and write the pattern about class naming.” And so, I programmed for 15 seconds, and then spend 3 hours trying to tease out whether all the constraints on naming classes, and why do I do it in this particular style.

Okay, so now I have contract. And the first method is going to be some way to create one. Oh well, now I have to go write the… So I program for 15 seconds, I’d write pattern for 4 hours; I’d program for another 12 seconds, and then spend 3 more hours writing a pattern.

You may actually be the origin of the phrase “Typing is not the bottleneck.”

[Chuckles] Yes, I might. I see a lot of stuff.

I mean like you might be the cause. Somebody watching you might have been, “Typing is not the bottleneck. Have you seen Kent?”

It was awful. I was already comfortable with Smalltalk, and I could just rip off applications. And I felt very fluid, so it was torture to like give all that up and try to say, “Okay, is there a rule behind what I'm doing now. And if so, let me write it down first.” But at the end of the first week, I found that I was applying the same patterns that I’d already written down most of the time.

I wanna know what kind of daily meditation practice you had that enabled that level of introspection.

I am in terror in not understanding stuff. I would say that’s my big motivation.

[Chuckles] Okay.

When I'm in a situation and I just don’t understand what's going on, I have a great deal of anxiety. So in a case like this, having the set of patterns… having a book that’s like, “Okay, here's what I

really do.” I found that very, very comforting. So since then, I tried to learn how to feel good about ambiguous situations -- which is a whole different set of skills. And it’s very, very valuable but...

Especially programming in Ruby.

I'm not kidding. [Chuckles]

Something I noticed about the patterns in this book is that they are very low level. They are at a level that I formally really thought of as code construction or as idioms even. And I'm curious of your thoughts on that. Are patterns things that pretty much just turtles all the way down?

They are to me. I mean, I've been thinking in that style for however many years. So it’s very natural for me to see patterns at the level of architecture and patterns in design, and patterns in user interface, and patterns in coding, patterns in how use get, etc., etc.

So before we get into like some of the actual patterns, which I'm sure we'll definitely talk about. I thought I would mention, if I'm reading the copyright correctly, this book is 14 years old.

Yes.

And to put that in context, at one point in the book, Kent references Windows 3.0.1. If that kind of takes you back in time. I´ll tell you that when I was reading it, I found myself worried that you were disappointed in how much we hadn’t learn over that time period.

So I guess I wanted to ask you, how well do you think this book has held up?

Fabulously well. I've been very like… in getting ready for this conversation, I went back and read the book again, and there's very little that I would write differently. Which I think speaks to the universality of what we are doing most of the time. I mean it’s sort of good news/bad news; most of the problems that programmers are dealing with that caused by programmers.

Right. That’s true. And I agree with you that its held up very well overtime. I mean, I never… I'm probably one of the few people on this podcast that never went through the Smalltalk phase, so I didn’t learn objects in Smalltalk; I learned them probably much later in Java. But I was reading it from the point of view of the guy who writes Ruby every day, 14 years later and I was like, “Wow, Kent solved a lot of the problems that we still wrestle with every single day.”

Yeah, that's one thing that I noticed and was thinking about was that, this book like you said is 14 years old; we also have Dave brought up, I think it was two weeks ago, the SICT, where that book came out in 1986. It’s like 25 years ago. And these are things that people still don’t fundamentally use or understand. And it just amazes me that we have these books that are this old, in an industry that’s changing as rapidly as computer science, and yet these fundamental things are things that we still don’t… not all programmers understand and use.

I think the basic problem addressed by Smalltalk Best Practice Patterns is that programming at its best is an act of empathy. You're trying to think and feel for the person who is going to come later, and read this code. And empathy is not something that comes naturally to me, and it’s not something that comes naturally to a lot of people whose brains work well for programming. So it’s something that you have to work on really hard, and sort of rewiring the human brain, I mean… in a sense is what you are doing as you have those moments where you think, “Yeah, I'm done, but somebody is going to come and read this and go, ‘What was he thinking?’ So let me work on this a little bit more.” That moment where you’re out of your own head, and doing something in service of somebody else, that's not going away anytime soon.

That’s another concept is just that you’re writing the code for other programmers that are going to come along, and have to use your code. And it shows in your book that you are thinking about that as opposed to, “Does it work? Does it work? Does it work? Does it do its job?” Well yeah, but it’s ugly as hell.

That was one of my favorite things in the book. That was one of the things I really got out of this book was the concept of code that is a conversation to the future reader. And I found myself just since I read that from you, I found myself applying that almost daily to my own code, and the code I was looking at. I was actually criticizing a piece of code a couple of days ago and I said, “Oh, when this fails, the conversation with the reader test…” And I really think that has given me all of new insight into how I program.

So the empathy thing I think is really important. I think that you can have the thinking.. you can think about having the conversation with the reader of the code, or the user of your API, who will have to read it to understand it at some point, but still miss what it is that they actually care about. I had this conversation with a friend just a day or two ago, and we are talking about some API thing he was building, and he asked my opinion on something. And it was really messed up; it was a crazy, overloaded method. There are three different ways to create one of these classes using the new method.

And he said, “Oh, I just want it to be flexible. I'm thinking of the person who’s using this. I think it’s going to be… I want him to be able to use it however he wants.” And I said, “No, you are giving him three different methods, but you are not giving them three different names. That’s a source of confusion.” So it was actually like a 20 minute conversation about all this. I was able to sway him, but I think that putting yourself in someone else’s shoes to say, the hard part about using an API isn’t using it; it’s about learning how to use it.

Yeah. There's a beautiful thing that happens with programmers when… it starts off with an ugly thing that happens with programmers, especially if they are very smart, where they become very, very focused on making sure that their code is right. And that right has a capital “R” on it, and it’s like provably right. And like it’s a very formal legalistic term; “This code is right and that is the way to do it.” And yet, it fails the reader test. And to get somebody to say, “You know what, this needs to pass the future reader test and it doesn’t that..”

By the way, we are 15 minutes into this phone call, and we haven’t told any rubyists out there if they should give a crap about Smalltalk Best Practice Patterns. And the answer is, “Oh my head, yes!” Because this book is not just about the low level stuff; it’s also about very, very high level stuff. When we start talking about a specific Ruby advice, there's a line that Kent puts in here that I think is all about, “You should go talk to your team about this.” And it’s not about right, it’s about being readable, and that in turn becomes right.

To speak out for a moment, I think there's a phase of learning to program when you just can't get the computer to do anything. You think you are clearing your head…

Yeah, when do you get out of that phase because I think… [Laughter]

Well, it’s kind of cyclical for me; it depends on the time of the day. But while you are in that phase, I

think it’s fine to focus on getting the program to work at all, and sometimes that’s more of a struggle and sometimes it’s less. But at some point, you get some confidence that you can get stuff to work, and then you have this chance to expand your horizons to include more in your sphere of concern than just you in the computer, and you can care about somebody who is going to read this later.

You know, you had something in your introduction to this book. I think it’s kind of weird to geek out over the introduction of a book, but the introduction in this book is actually amazing. The first couple of chapters where you’re defining things and summing things up. But one thing that really stuck with me out of it was where you talk about the cycle of programming; and it was basically you have the one idea of what you want the computer to do. So you sit down, and you try to make the computer to do that. That changes your idea of what you wanted the computer to do. So go back to square one and then try to make it happen again. And just this cycle of you back and forth with the computer, you know. What you want it to do, and how doing that changes what you want it to do.

And I thought that was very great. It reminds me of programming.

A strange thing has happened in the Ruby community lately, and I wanted to get your comment on it. Someone will say, “Let’s use the so and so pattern.” And the other person will say, “So and so pattern? That sounds like a Java thing.” What do you say to that?

It’s not a Java thing; it’s a programming thing.

I don’t think the examples I've seen weren’t factories. I think it might have been delegation. And what people are reacting to, I guess I'm asking a little bit about history here, because I think what people are reacting to is less that it’s so and so pattern and more that it’s the so and so pattern.

And that patterns have gotten an odd association in recent years.

They certainly have. They went through the hype cycle, and people were calling things patterns that weren’t patterns, and putting the word on books to try and sell books, instead of putting the concept inside to try to create value -- just all that usual stuff. So that certainly has happened. So I think that the patterns, once you agree… so sounds to me like there's two levels of discussion going on there: one level of discussion is about what you're programming, and the next level of discussion is about what patterns you're going to use in programming -- and mixing up the two is pretty inefficient.

If you can, in that moment say, “Okay, let’s take a step back and let’s talk about what's generically going on here, and what pattern we are going to use for this.” Then you have that discussion, and then you can go back to the code and decision in the code becomes obvious once you've had that discussion. So I’d say that’s an opportunity for a higher level discussion. But it’s also an opportunity for a rat hole if one of you is talking about the code, and the other is talking about the patterns; you can go spinning around that merry go round for hours and hours and hours. Does that makes sense, Avdi?

Yeah. I think there's also maybe an idea… I can't remember the quote that's quoted, but with the sufficiently powerful language, you “don’t need patterns because it’s just part of the language.” I mean, I'm curious how you respond to that.

One of my early thing was BASIC. And in the first day that I was learning BASIC, I figured out ‘if, then, else’. I just kind of looked at a bunch of examples and I went, “Oh, I see.” It wasn’t if then else in the language, but I could figure out there was this pattern of conditional go-tos and unconditional go-tos and I went, “Oh, I see. So there's that pattern.” Then when I learned Pascal, lo and behold, there’s ‘if then else.’ So I don’t need the pattern that I used in BASIC when I go to Pascal, because Pascal just has a language feature for it. And I think that happens over and over again. That’s the way that programming languages evolve, is the things that you do over and over again and are difficult in language A, when you get to the language A prime, then that’s been automated way.

The concepts are still fundamental and there is some… it’s like iteration or recursion, some languages, those are easy to do, and some languages those are hard. But an expert programmer doesn’t really care about the syntax of the language, when they are really thinking about the problem space, and putting the other in algorithm.

I think that’s kind of part of the problem. I'm just guessing, but when people… like for example, after I've been a Rubyist for a pretty short time, I read a really great book on Java patterns. I think that was Holub on Patterns. And it was a really great book and I enjoyed it. And I went back to write in Ruby, and was trying to incorporate this pattern knowledge, and it really took my Ruby downhill for a while [Chuckles]. That’s because those patterns aren’t quite the same in Ruby, as they are in java. And like a factory is a great example. Whereas in java, you have such a high need for something like that.

And in Ruby, the need is very small because classes are objects, so a lot of times, the factory can just be assigning some class to a variable and calling new on it when you are ready. So it can be that simple. But that is still the factory pattern. It just doesn’t look like the factory pattern from java, you know? You are still doing it for the same reasons, to make object instantiation dynamic. But it just looks a lot different. And so I think that leads some people to say, “Well Ruby doesn’t need a factory pattern.” Sure it does. We have it. We assigned a class to a variable and call new.

Well, Ruby has observer built right in. So if somebody says, “Let’s use the observer pattern.” Like “Okay, observer, we are done.” Avdi, I think the quote you are looking for was from Rich Hickey, the creator of Clojure, who said that, “Patterns are what you get when you run out of language.”

That’s interesting. Can I derail this just a little bit? I’d be interested to talk about some of the patterns that are in the book. I mean, we've been talking for like 25 minutes.

Hell yeah, there's a book involved in there.

So you know, it’s interesting to talk about how patterns apply, but I want to get in to some of the examples because I want people to understand some of what this book offers, so that we can get some of these things into the conversation a lil bit more in the Ruby community. So if somebody just wanna pipe up and maybe talk about pattern that they are using, or pattern that they really were impressed with.

Sure. So I saw that the first pattern in the book was Composed Method. And I was wondering if that was on purpose, because I loved Composed Method, and I would say I used that like every single day. In fact, it’s my favorite way to program and Kent actually mentions why in his book. That I can start from the high level, and just say, “Okay, I'm going to do this thing. And that will involve doing this and then doing this, then I go write all those methods.’ And he actually points out exactly that use case of the book. So that’s one of my favorite patterns and it was the very first one, and I was wondering if that was on purpose.

Yeah, very much on purpose. I think that’s the central… if you got that one, everything else kind of follows from that. This idea of functional decomposition, having small pieces of stuff that can change independently of other pieces of stuff. And there’s more to Compose Method; there’s this idea that everything is occurring at the same level of abstraction.

I have to say that for me, that kind of epitomizes something that we talk about a lot in the Ruby community, and that is outside in programming or top down programming. Or you know, you start at the highest level of abstraction, and then you just put the next level of abstraction into the method.

At every level, you are translating from what you want to have happened, to how it’s going to happen.

Yeah.

But it’s not a linear process, because you make all these discoveries along the way, which is why it’s not as simple as well. I just picked up my copy… my Pascal textbook from n thousand years ago. And they have this functional decomposition style, top down style. And programming really doesn’t work that way. Unless you don’t learn anything, because the boundaries between the layers are kind of messy and you don’t know quite where they should show up. And so, you are constantly playing with where things does this belong? At this level or some other level or “Oh look, I have the same thing in two places. Let me extract it out.” So it’s not as simple as start with the statement. The system works, and then decompose from there because are going to learn a bunch of stuff along the way.

That makes a lot of sense.

Yeah.

One of my favorites that I was reading, and it was light came on for me… and I think it’s a compilation of a couple of different concepts that I keep hearing, and eventually it just kind of clicked for me. But it was demonstrating the double dispatch, where basically, you had the example of integer plus float, float plus integer. It was really interesting, because I went through this process in my head where I was like, “You couldn’t do that in Ruby because they are not strongly tight.” And then I realized, “Yeah, but what you are doing is you are calling across to what you are adding in, and so you already know what the types of the two objects are, so then you can handle things.

And so for me, it really kind of broke things down into, what do I know, because if I'm calling integer plus float, I know that the first object or the thing that is being called on is I know what that is, I know it’s an integer. And then the second thing was, who can I most effectively send the message to to get the job done. And I’d never really thought about that before. I typically just do things more procedurally and just keep everything in that one class. And so for me, it kind of opened things up and it’s like, “No, make the consideration, as far as who can best handle this, what's the best message to send them and what information do I already have that I can provide to them.”

Ruby has a method called Coerce that will let you flip the relationship. Like if you have integer plus float, and then you end up writing float plus integer, and if you have a coercion, it will basically flip it around and make it work. And if you do not understand double dispatch, and the meaning behind this, coerce is enough to shoot yourself in the foot. You will write bad code with it.

Yeah, I thought of Ruby’s coerce too when I was reading that pattern. I have to say like Chuck, i was really… Double Dispatch was an AHA moment for me. If compose method was my old friend, I

was glad to see it in the book, then double dispatch and method object were the ahas, you know. But coerce is a little strange actually, because I actually found double dispatch more straightforward, because the problem with Ruby’s coerce is that the reason it exist is if you are building some object that you want to be able to add to integers, it matters if that object comes on the left side or the right side of the plus sign.

So when you are doing it in Ruby, you have to do it two ways because first, you have to define the plus operator overload that, so that if it comes on the left side, then it can handle the addition. Then you have to define the coerce methods, so that if it comes on the right side, Ruby’s objects can handle that conversion, right? But with double dispatch, you can actually get rid of that problem and that you could… now I guess the downside there is that you'd have to reopen all of Ruby’s classes to add the correct type method to them, so that they will dispatch correctly. But I don’t know, I found it more elegant and easier to follow, the double dispatch example.

That will be interesting to take a real example and code it up both ways, and see which ones are easier to work with overtime. One of the challenges with double dispatch is you have n times m implementations of all those methods. And adding a new one… and then if you add a new one, say so if I've got integer float and I don’t know, a vector and then I add a matrix to that, then I may have to go add three more implementations or four more.

Yeah. So Kent how come you didn’t talk about the Smalltalk numerics generality system?

Because I hated it.

Well it was pretty gross, but…. So I wondered off from Smalltalk in the late 80s, and didn’t do much professionally with it after that, so I don’t know what became the state of the art in Smalltalk for dealing with that soup. Did that ever go away or is that still…

Yeah, it’s all done with double dispatch now. The coercing arithmetic type is all done with double dispatch now. The previous way was each class had a generality associated with it, and if you had a less general number trying to do its arithmetic with a more general number, then you’d coerced the less general one to be more general, so you'd like… floats and fractions, fraction would turn itself into a float before you do the addition.

So that is what you just described as pretty much how numbers work in Ruby.

Yeah, everything old is new again.

Yeah.

So one other thing that I noticed in here that was… I never really thought of it as a pattern, but it made a lot of sense is in the collections chapters, there were a lot of ways you explained, “Hey look, Smalltalk provides you with this convenient way of handling this thing.” So then you talked about select and reject and detect and inject, and you know, all of these different things. I think we have all of those in Ruby. But it’s a really convenient way of accessing and iterating over your collections. And to me, it was kind of a, “You should get to know these features in the language.” It really wasn’t so much of a, “This is how you implement.” This is more of a, “This is here and if you get to know the language, then you can take advantage of it.”

And I thought that was just an interesting approach, because in Ruby, a lot of times I´ll see people doing an array.each do blah, blah, blah. And what they are effectively doing is collect. And they could just go ahead and say, array.collect blah, and they'd get whatever they needed by giving it a block that transforms whatever was in the array. And so, it’s an interesting pattern to me to know what your language does as opposed to set things up in this way.

And the reason I wrote that down very explicitly like that is because I also saw lots of code where somebody was essentially doing a collect, but they were using do to do it. And so I thought, well, there is an underlying problem; why is that method there? Why is collect there? Well there is this underlying problem that you need to transform a collection into something where the elements are derived from the elements of the original collection. So that just happens over and over again; five times a day when you are programming hard. And so call it out and say, “Hey, there is this problem that we all have, and there is this simple solution.”

The equivalent if you’re in java, you also need to write a collect pattern, but the implementation is going to be more than one method, because you have to okay, so you have to allocate the resulting collection and use this variable name to describe that, and then you have to here’s how you format the loop and then now you have the problem solved. If you are in java, you have one kind of solution. If you are in Smalltalk, you have a different solution. If you’re in Ruby, the solution is very similar to the Smalltalk solution. The syntax is a little bit different, but the problem is the same, right? That’s just a thing that happens because we program.

I want to rip off that real quick. I've been translating some of these examples to Ruby, and I'm kind of split mind as I'm doing it because Smalltalk has a very small syntax -- small and elegant. And so one side of my brain, I'm thinking, “This is so simple and elegant in Smalltalk code.” And then I'm also realizing that other side, “For this particular case, there is a specific… really concise syntax just encoded in to the Ruby language.” Because you do it so often, it’s basically like they've taken the pattern and encoded it into the language. So the Ruby version is actually a little bit more concise. And I'm curious how you feel; like at this stage how you feel. Do you naturally gravitate to the language with the really simple syntax and predictable syntax? Or towards the languages that have all these syntax like Ruby?

I naturally gravitate to the languages I can get paid for writing code in.

It is very natural. So you know at Facebook, I write a lot for php code. And my php code doesn’t necessarily look like everybody else’s php code. I'm trying to apply the patterns and in the sense of how can I write this, so that other people can really understand it. But then each language gives you a different set of constraints for what's easy to express, and what’s more difficult to express.

And my goal is to write idiomatic, but very readable code in whatever language I'm using.

So kind of going back to the… you had the example of do versus collect. Glen Vanderburgh and I have kind of played around with that idea a little, and used it to kind of derive a way to teach Ruby’s iterators to people, and we used it in a training we did at one time. And it’s very effective. So if you ever wanna understand Ruby’s iterators, it’s a good trick. We give each, and almost everybody understands each immediately, so it’s a very simple; which will be the equivalent of Smalltalk’s do. And then we write the other iterators in each.

So we say okay, we wanna go over these list of items and transform every item into something else. And that’s collect or map in Ruby. And we write that using each. So make the resulting array, each over each of the items, changing them and putting them into that array and then return the resulting array. And what it does is exactly what Kent was saying. You write the pattern in java, it looks different. But once you've done that with the iterators, then you see, “Oh, whenever I'm doing this, this making an array, transporting items, putting them in there one at a time and returning that array,” and I meant to say, map. And so then if you are reading your code later, and you see that array each return the array, then you are like, “Oh, I meant map.” And you just change it to map. So it turns out to be a great way to learn them, I think.

James, I just wanna say what you actually meant to say was collect, not map. [Laughter]

No, I was sure I meant map, actually.

[Chuckles] Just like when I said ‘detect’, what I really meant was ‘find.’ Anyway, we are getting kind of to the end of our time before we do the picks, and I wanted to ask some of the questions that people had put on the blog regarding this. Most of these questions are for Kent.

Wait, wait, wait, wait, wait, before you do that. So I am the biggest fan boy of Kent, and I have like taken all of my Ritalin in one doze so that I would not completely freak out and fan boy, but I didn’t get the chance to ask my question. Can I ask my question?

[Chuckles] Ask away.

And this is exactly where I'm talking about Ruby programmers, you absolutely need this. And this book is also very, very high level. So I'm really glad that Chuck, you picked something out of the back after the book because I was worried that Kent is going to think that we all read like the first ten pages of the book and said, “Yeah, I got enough.”

Because my question is from the third pattern of the book, which is the short constructor method. And the motivation for this pattern is you are building something so often from other data types, you are cobbling it together that it finally makes sense to instead of writing this big, long, conversion method, I'm just going to go ahead and monkey patch. And Kent doesn’t use the word monkey patch, because that didn’t come in slang for another 15 years, but I'm going not go monkey patch this other class so that I can send it a message and it will generate my other class.

So in Smalltalk, our can send the at message to an integer or to a float, and you give it another integer or a float, and you get back a point object. And there's a great note where he says, “It puts a great burden on the programmer to remember the message because it looks like it can be easily mistaken for existing language syntax.” So he says, “Represent object creation as a message to one of the arguments to the constructor method. Add no more than three of these shortcut constructor methods per system you develop.”

Now, your holiness, if I may, I have taken this and interpreted this scripture to mean, if you monkey patch, you have to elevate the visibility of that monkey patch, so that it is visible to the entire team. And so we've started adapting like a specific idioms, like we have a patches directory in every Rails project that we write. And you are expected as a programmer coming to the project, you are actually expected to sit down and read that patch’s directory because it’s changing everything in the system, right? It’s monkey patching array, it’s monkey patching string to do different things.

And I've found that if you create a patches directory and then all of a sudden there's 15 files in there, I found that I can make a pretty good argument that 12 of those have to go away, because it’s just too freaking complex. It’s just too patched. And so I tried to actually adhere to the ‘no more than 3 of these system that you develop’ because it’s a great team learning. I'm curious to know if you have… if that was the motivation is because this is a surprise gotcha, and has that rule held up in other languages as you move forward.

So most languages… wow, there's a bunch of questions there. I´ll try and keep track of it.

Okay, sorry.

It’s the downside of having programmed for 40 years. So I just pull the number three out of the air. I want to be aware of the cost and benefits of what I am doing. When I have a shortcut constructor like that, I'm really adding to syntax of the language. In a more fundamental way, in a more surprising way than, “Oh, here’s another class,” and “Here’s another method for that class.” Everybody expects that. The shortcuts, they are more fundamental in that. They're a surprise, and you have to get used to them.

I think what I was reacting to, was in the early days of the commercialization Smalltalk, there were people who just would fall in love with something like this. And they would have 100 of these, and you could not read the code. If you just walk in, it didn’t even look like Smalltalk code anymore, because there were all these funny characters and what do they mean, and they are just so condensed.

On the other hand, not having at to create points, when I do graphic programming in java or in JavaScript, where creating a point is so hard, they don’t even do it. They pass around x and y separately even though they go together. How stupid is that? So there's a place for this kind of syntactic optimization. But be aware that it’s special vocabulary, it’s our slang here and if somebody new comes in, they are going to have to learn that before they can even talk to you.

There is a critique of Lisp that I read 20 years ago that basically said, “Every Lisp program becomes a DSL. And as result, Lisp is a very autistic language.” And autism is a disorder where

you cannot communicate your internal state to external observers. And yet, you come down, you sit down and you get this DSL that you can't understand.

And three years ago, I worked on a project that had like 30 or 40 monkey patches on it, and it was just exactly that. There were a couple for programmers there, myself included, I got caught up in the fever, who were in love with monkey patching everything, always, all the time. And eventually, it bit our ass clean off; I mean it didn’t just bite us on the butt -- it killed us. But I've noticed an insurgence lately, and I wonder if you see this distinction as well.

In the past year, I've seen an emergence of Ruby DSLs, that are actually built out of a strict set of idioms which ends up, you can look at the DSL and go, “Oh, that is very, very readable,” and yet it is also made out of Ruby constructs that I recognize. The solar plugin for searching in Rails, you type searchable do and you go, “Oh, that’s a block. I get this. I could probably debug this if I have to.” Have you seen that as well?

That was always our goal with Smalltalk code, is to create a language that somebody could read, but it was built out of Smalltalk constructs. And that’s very, very hard to say in java, because you just don’t have much syntax to play with -- and you have a lots noise. In Smalltalk, because there's little noise, it was easier to make something that look like a DSL; if squint at it with one eye, and if you squint at it at the other eye, you just go, “Oh, that’s just Smalltalk.”

Yeah.

I wanna say one more thing since Dave mentioned that we don’t talk about anything in the back of the book. I have tons of notes, so I can just sit here and talk all day. But two of the later chapters in the book I thought was particularly impressive; one being Classes which is a short chapter admittedly, but this is a chapter entirely about naming. And we all know that naming is one of the famously hard problems in computer. So it turns out there is an entire chapter just about picking the names, so I just totally love that.

And then the chapter immediately following that is actually like how to format your code, which when i was reading the table of contents at the beginning of the book, I was like, “Wow, that’s kind of weird in a book like this,” I thought at the time but then by the time I've gotten through the code, it’s a conversation to the reader aha moment, then I realized that that made perfect sense because you wanna format your code, so that it is readable to the person that comes after you. So those were two chapters I loved later in the book and I was very glad that they were included.

Yeah, very, very nice. I feel bad cutting you guys off, but were going to go way over, and I do wanna ask some of the questions that people posted on the blog. So let me just ask a few of these and then we'll kind of see where things go from here.

One of the first questions that was posted was by Rafael and he says, “I recognize some ideas from SBPP in later works by other authors, e.g. I think “Clean Code” by Robert Martin can be seen as the heir to SBPP. Do you agree?”

So I say yes and no. the yes part, the similarity is that it’s worth caring about your programs. That it’s worth pouring all of yourself into the act of programming. Where I see a difference is who you are doing it for. So I´ll talk about software craftsmanship in general. A lot of software craftsmanship stuff that I hear seems to be more about the craftsman, and Smalltalk Best Practice Patterns is calling for you to take that care with your programs for the sake of other people, not for the sake of your own feelings. Or I´ll feel bad If I don’t do this. I'm kind of OCD about code, but I try to differentiate when I am fuzzing with the formatting, because it will make a difference for somebody reading it or when I'm doing it just because I… the light switches and the using the right spoon or whatever. Does that makes sense?

Yeah, that makes sense. The next two questions have to do more with the future of Smalltalk. One is, “What is your opinion of the future of Smalltalk?” which I think is pretty general. But then he asks, “Do you think the latest Smalltalk’s community efforts such as Pharo, Seaside, Amber (previously known as JTalk), etc. could put Smalltalk again in the limelight?”

Limelight, honesty, I don’t think so. But I think Smalltalk has a vibrant cult following, and I think that’s a great position for a language.

One of the other questions asked by that same guy, that I think kind of relates to what we were just saying there, “Do you think Smalltalk is worth learning by current programmers?”

Yes, absolutely. Because you have no choice but to use objects. And I think this is where I would criticize Ruby; in Smalltalk, the objects are right there and under the glass. You don’t have a text editor that works on a stream characters that’s going to get interpreted, that’s going to eventually turn into objects; you are working with the objects, you point at them, you click on them, you edit them. They are right there. You have no choice but to interact with the objects.

Huh, interesting.

I think that’s a very good point and… but kind of in defense with Ruby, I think that's kind of a strength and a weakness of Ruby, right? That it’s bad and you’re right, I think that’s why rubyists are slower to adopt things that we figured out in Smalltalk 15 years ago, about how to do objects right because it is like a step removed. But at the same time, I love that like Ruby can double as a scripting language and let you do some low level, fill up a hash or array or something, run it through a few transformations and spit something useful out of it; which I think is maybe a little bit more ceremonial language like Smalltalk, right?

Oh, absolutely. That's definitely the tradeoff. In Smalltalk, you have this… the cliché , you have this place and as long as you are inside of Smalltalk, things are much easier. And when you go outside of Smalltalk, things get quite a bit harder. So throwing a script together is not a trivial thing to do in Smalltalk, if you are accessing external systems.

I made a comment on the Rogues a couple of weeks ago that Rails actually encourages some bad programming practices, because although we wanna do everything top down, the very first thing you do in Rails, once you've decided what you wanna write is Rails g migrations, right? Or Rails g model. And you end up building bottom up from the database.

And a little secret is that quote is actually a retooling; that statement I made is a retooling of something I tweeted several months ago about Smalltalk, which is somebody asked me, “Why should I look at Smalltalk?” And I said, “If you are interested in doing arbitrary programming, Smalltalk makes it really freaking hard to write bad object code.” I'm not saying it can't be done, but it actually, the language pushes you towards a top down.

And it is. I love that phrase, Kent, that the objects are there and it’s under the glass, that everything is an object and its always an object. And stop trying to turn them into procedural things because the language will fight you every inch of the way. I love that. And it will make you a better Ruby programmer to go learn Smalltalk, and let Smalltalk have its way with your brain for a few months.

Yeah, people freak out when they realize there's no main.

[Chuckles] Yeah and there's also no case statement, which I think is probably one of the weirdest thing about programming in Smalltalk, but it really forces you to use the double dispatch, and use the method dispatch to the language.

Yeah, we just call it a message.

Yeah.

That's the case statement. And if you like… why would you have a case statement.

Yeah, you have collections and messages; what else do you need?

Yeah, and your main can turn into a [inaudible] main anyway. I've seen it happen. Anyway, another question is by Eric and he said, “I thought I heard a couple of years ago that you were working on a “Ruby Best Practice Patterns” book with one of the ex-Hashrocket guys. Any truth to this? Any plans for making a ruby version of this book?

We had one conversation and it didn’t go any further. But in preparation for this podcast, I listen to all your previous episodes and…

So you are [inaudible]…

[Chuckles] Congratulations.

Do I get my coffee mug now?

You wasted how many hours?

[Chuckles] Oh it was not wasted. I was shoveling manure.

I'm just going to let that one sit. So I heard last week you guys were talking about how you'd like to see patterns in Ruby. So here’s my proposal. I´ll rent a fishing lodge up here, and we'll get us together for three days at the fishing lodge, and we'll go fishing in the morning, and we'll write in the afternoon and the evening, just to kind of kick things off and get things started. You´ll do the writing, I´ll be the editor and we'll end up after a few months with the Ruby and/or Rails Best Practice Patterns out of that process.

I am so in.

Squeee!

I get to go fishing.

As long as I don’t have to clean the fish, I'm totally cool with that. [Chuckles]

I´ll clean your fish too. [Chuckles]

[Chuckles] No, that sounds great. I think that at least some subset of this group can get into a project like that. I would love to see a good tactical patterns book for Ruby.

And just like that, I'm backed out.

Clean your own fish.

I'm definitely for it. I would love to have that book in Ruby, and I would love to do it with these bunch of guys.

Rogues retreat! Rogues retreat! Oh, sorry. [Chuckles]

It would be great if we could get maybe the prags to do something creative with commercializing it. You know, making sure that it has a wide distribution, but there's also enough capital flowing around it to keep everybody’s interest.

That actually answers another one of the questions our listeners had for you, “Would there ever be an electronic version of Smalltalk Best Practice Patterns?”

The Smalltalk one is out of my hands; it’s up to Pearson whether they want to do it or not. And I wrote my editor and he did not write back, so I don’t have any more information about that. Bug Pearson if you want it.

I don’t think some of these publishers really understand the ecosystem for the people who would be buying this book. Because if it will be electronic, you'd selling them like crazy.

Yeah, in [inaudible] dollars or something.

I'm not sure, but I think we single handedly drove up the price of this book briefly on Amazon.

I notice that too, that right when we announced it, the price seemed to get ridiculous.

DAVID: yeah.

CHUCK: that’s kind of funny.

Yeah, they had to print more.

I got mine before the gold rush. [Chuckles]

Yeah. so one other question that I saw from the last one about the eBook version was from Don as well, that I'm interested in is “How does he balance between learning new or current things versus going back to old (say more than 10 yrs old) publications?”

How do you balance? I make sure that I do some of each. So I recently re-read on the criteria for de-composing systems in the modules or something. I don’t remember the exact title, but I recently reread that. The people that came before me were really, really smart and had a lot of these stuff already figured out. And so I try and stay up to date with what people are publishing that's interesting now, but I try and take a part of my day and just read. And some of the stuff that I just read is things that came out a long time ago too.

It always amazes me like monkey patching, you can take something in modern day, we have this idiom and everybody understands it. And then, you go back 25 years, here's Kent Beck saying, “Well, here's this rule of thumb that I kind of feel like I have.” And then you go back 25 more years, and then you'll find that Edsger W. Dijkstra has a proof. He actually mathematically proved the Dunbar number for code or whatever it is. I don’t know. We forget sometimes that going back to Donald Knuth and stuff like that from the 60s and the 70s is sometimes really, really worthwhile because these guys were dealing with first principles and they were very, very rigorous. This was before computer science has gotten really sloppy. And sort of relying on a lot of lore. And yeah, you can go back and find like proofs for why you should do this. I love that.

All right, and with that, I'm going to go ahead and cut things off. We are going to get to the picks. We are right at an hour recording, I believe right now. So were a little over what we try and target. So we'll try and go through these pretty fast. And one thing regarding the picks that I've been considering and I want the panel’s opinion and I'm kind of curious about everyone else’s opinion too, is I thought about putting together a mailing list that would go out every week with the picks in it, and maybe just a few thoughts from week’s episode. Do you think anyone will be interested in that?

I think we should ask the listeners.

Like the show notes, kind of? That's kind of interesting.

Not necessarily the show notes, but maybe a quote or two. But really picks that people have seem to want to have those like right away.

Yeah, maybe.

Maybe we can do an RSS feed of just the picks.

Maybe. That’s a good idea too. I´ll put out a survey for the listeners. All right, well let’s get into the picks. Let’s go ahead and let David go first.

In the interest of time, I'm just going to throw out two titles; SQL Cookbook from the O'Reilly press and Joe Celkos’ Trees and Hierarchies in SQL for Smarties. I've recently had to do heavy duty Rails and Ruby lifting with some really, really, really, smart programmers, and I am staggered to find that a lot of them don’t know much beyond the join syntax in SQL. And so, if you've ever wondered how access nested set works, or if you've ever wondered how any of these membership things work; some of the really tricky containery bits, I realized we just talked about Smalltalk, but SQL is also a really great legacy language to learn. It’s a very, very powerful query language. You can do a lot more with it than you think you can. I wrote an adventure game in PostgreSQL about this six years ago, that you literally pick things up and drop things and move around in the game, just to prove that psql was a turing tarpit. I said I was going to do a quick pick and I'm still talking, so I'm going to stop there.

All right, Jo—aaames.

That was hilarious.

[Chuckles] I did that because Josh said, “Don’t pick me next.”

No Josh, it really is fine if you wanna go now. [Chuckles] Okay, so the one time we run horribly over on time, and I'm usually the guy that does that one pick and all that. Well this time, I have three. I saved my Kent Beck fanboyism for the end here, since I didn’t get it in at the beginning. But he has these set of videos on test driven development. You can get them from the pragmatic programmers. Just four episodes, I can remember how long they are, they are just like a couple of hours if you add them up, I think.

And they are actually really good videos. I still use tricks I learned from those videos back from when I watched them. Like one of my favorite things in them is Kent says, “When you are about to run a test and see if it passes or fails or whatever, guess. Make a guess.” Because if you don’t guess and you just get the an answer then, you don’t learn anything. But if you guest and it surprises you, then you have a better chance to learn something. And I use that all the time when I'm programming.

Is that “Calling your shot?”

Calling your shot, absolutely.

I love that terminology.

Yeah that's a good point. So there's these. And I just wanted to point out that like the Ruby community is currently obsessed with isolated tests. That's been all over the place in discussions, it’s been on Destroy All Software etc. one of the four videos in this is on isolated tests. So you know, as usual, Kent ahead of the curve, and teaching us all that stuff before we knew we wanted to learn it. So I definitely recommend checking out those videos.

And another pick that I saw this week that was absolutely great, people are always asking me what project should I go read code for to learn a lot about. And I know I said publicly in the past, Rest clients are a great read and I stand by that choice, it’s a great read. But there was a new library released this week by some guy I have never before -- Avdi Grimm -- that is just a short little wrapper library. He invented keyword params for Ruby in this library, and he basically just used Ruby’s metaprogramming to make real keyword params.

So like you specify them like a hash, when you are calling the method and they end up as local variables inside the methods themselves. And the reason I say that this one is a great read is the main code of it is like 42 lines, that main file, that does most of those stuff. And it’s an awesome use Ruby’s metaprogramming, where every single line is there for a very important, specific reason. And if you go through and look, and you figure out what each of those lines does, then you will understand the great deal of Ruby metaprogramming. Like try to remove that thread local variable he put in there, to figure out why it’s there or things like that. So it’s great; it’s 42 lines and really will help you understand Ruby’s metaprogramming. So that’s my second pick.

And I have three this week. I was searching around on some Arduino projects a buddy of mine have been working on. I got side tracked from there and I ended up on some steam punk computer science stuff and I found this awesome site where they make like steam punk computer keyboards, and they are now taking pre-orders on this whole steam punk laptop, which I have to say the most gorgeous thing I've ever seen with these gears and stuff on the back. And it’s way more than I can afford, so I'm telling all our Ruby Rogues listeners, you guys can just chip in and buy me this, okay? And that will be great. No, I was telling you this so you could go there and actually drool over all of the pictures, just like I do because I think they are cool. So I´ll post a link in the show notes.

You should go check out the steam punk computers. Okay, that’s it. I'm really done.

All right. So you mentioned the masters of the universe, Avdi and Kent, and we'll move on to another master of the universe, Josh.

[Chuckles] Okay. Master in some other universe, maybe.

[Chuckles] My first pick is… I don’t know, this one has been floating around for a while, but I don’t think we've done it as a pick before. There's a site called coder wall. Coderwall.com which gamifies your existence on GitHub. And so you can get achievements for having projects in various languages, or contributing to someone else’s open source project, things like that. It’s kind of a nice, clever way to get an idea of what someone is up to, and what their open source life is about. If look at myself, I can see that I only have seven achievements, so I need to do more open source work. So that’s Coder Wall. It’s in beta. It’s been in beta for a while. I hope they figure out how they are going to make some money and turn this into a real cool product. It’s pretty cool already.

And then my other pick is also GitHub related, and it’s sort of a product endorsement; there's this pinktocat shirt. GitHub has this lovely cat logo, and for breast cancer awareness month, they're doing a pink version of it, because pink is the breast cancer awareness color. And they’re lovely tshirts, but the thing that I wanted to commend GitHub for is GitHub is a real… they have women who work there, but they have a small percentage of their employees are women.

And Dave and I are having conversations about even online on Twitter about, “Oh gee, we really want more women in our company. What do we do about that?” This I think is a really brilliant move on their part is they jumped in, they support breast cancer awareness month; they put a product up there for it. This seems like a really good way to engage a community that they want to be better represented within their company. And besides that, it’s a good cause. And it’s a cute shirt, so that’s my pick.

All right, Avdi.

I just got back from Ruby Conf, where I stayed at the Marriott for $60/night, which is why my pick is Priceline, which is something that I had been aware of. I mean, everybody is aware of it but I hadn’t actually gotten around to figuring out what the whole Priceline thing is all about. And I finally did and I'm very happy, except that I feel kind of embarrassed that I wasn’t booking hotels using it before now. So ridiculously good deals to be had on there. And there's a screencast by Gregg Pollack, which points out extra tricks for nailing a really good deal. Highly recommended if you travel a lot.

Second pick is one of these really old gems that I always kind of assumed that everybody knows about, and then I talk to people at conferences and then I realize that nobody knows about it. So, there's this piece of code which is actually been coded up in a few different places called eXMP for Ruby. And it’s for formatting examples. Basically, you annotate… you take some Ruby source code, you annotate it with special comments, and you run it through eXMP and eXMP fills in the evaluated value of the lines you annotated.

So if you have 1+1 on a line and you put a special comment, it will fill in two at the end of the line. And so this is really handy for posting little examples of code. So if you install the rcode tools’ gem, among other things, you will get a nice eXMP filter executable, which you can pipe stuff through and it’s got a bunch of options for how it formats the output. Very, very handy for doing examples and other things. And actually, if you take a look at that library that James was mentioning, I did kind of a crazy thing where I actually implemented the tests using eXMP filter. So if you weren’t using it already, check it out.

There's a Textmate bundle, and or Emacs mode that uses eXMP, if I recall correctly.

Yeah, if you get rcode tools, it’s actually… bundled in rcode tools is the Emacs mode for it, which is super handy because you can just say, eXMP, and it fills everything in the buffer that you are working on.

Nice.

Yes. And in Textmate, we do support it in the normal Ruby bundle.

[Chuckles] That sounds awesome. Let’s get some picks from Kent.

So I have three, and I´ll try and describe them briefly. The first one is, Rooibos tea. It tastes good, I find it calming, there's no caffeine, it’s loaded with all good stuff. And it’s a mild diuretic, so I don’t have to worry about sitting there and programming too long. [Laughter]

I have branded that as the P-modoro technique.

Kent, you were my favorite panelist before you said that. Now, I will retire the category. That's great.

I was laughing long before I unmuted. [Laughter]

Okay, my second pick is the D3 project from Michael Bostock, who works at square now, who was in Stanford. It is an awesome visualization library for JavaScript, that lets you make all kinds of amazing graphics with very little work -- if you are willing to twist your head around a fair amount. I'm using it to visualize complicated structures of software, and using this force based layout, and it has a beautiful implementation of that. Anyway, you can do amazing stuff very quickly. And it’s interesting code as well; the API design is not something that I'm used to, so I'm learning a lot from that.

And my last pick is a set of books by a man named Phillip Ball from Oxford Press. And the three books are called Shape, Flow and Branches. They are little books; they are beautifully illustrated, and they talk about kind of the design in nature; what are the natural forces that act on the design. My current crazy quest is to understand the natural forces that are acting on software design. And I think there are really strong forces acting on software design, because we inadvertently come to the same conclusions so frequently, there has to be some kind of natural law at work, and nobody understands what it is. So, that’s something that I'm reading to understand how natural forces in the real world affect physical structures.

All right. I guess I'm last. Couple of picks; the first one is I started playing with trying to get Cassandra to hook into Rails in the way that some of the ORMs do. I have my own little one called Sandra. And so I was working on the Sandra Rails gem, just like you have a DM Rails and SQL Rails for data mapper and SQL. And I was having hardest time getting it to work, so I went and looked at these other plugins, and lo and behold I made this recovery about Rails that is so incredibly useful, if you are writing gems and plugins that you need to hook into Rails, and it’s actually called railties. And I know it’s been around forever, but I didn’t realize just what it did. And so if you wanna check it out, it’s a great way of adding initializers, modifying configuration, setting other things up; just handy, handy stuff if you are trying to extend Rails in specific ways, and you want to add certain a functionality in and initialize certain behaviors in your Rails app. So Railties is definitely a pick there.

One other thing that I've done recently is I've upgraded some of my audio equipment. And so, I was using this Behringer microphone, and I decided to go ahead and finally break down and buy the microphone that I've been drooling over for the last six months; and that is the Heil PR-40. I think it makes my voice sound incredibly good. I don’t know what it is about the e quality of my voice when I talk into it, but I think it sounds so, so nice. And so I'm also going to have to recommend that.

And I was looking for some new headphones and things, but the ones that I had, I had some headphones that were noise canceling, and they were pretty nice, but I kind of wanted something that I can put on over my ears that were maybe a little bit more comfortable, and had some great sound. And so I was looking around and I had several people mentioned to me that I have to check out Dan Benjamin’s podcast recommendations. He puts out a recommendation list over here, and so I actually bought the headphones off of that. But his recommendations are really top notch. And so, if you go and look at in, you can Google Hivelogic Podcasting Recommendations, and you´ll find them. And I´ll put a link in the show notes, but that’s a good place to start if you are looking for what you need to get a top-end podcasting rig.

If you are not interested in top end podcasting rig, then I highly recommend -- and this is my final pick – you go and listen to the latest episode of Podcast Answer Man. You can find it on iTunes, or you can go to podcastanswerman.com. The latest episode, he starts playing with digital audio recorder, then he plugs a mic into it and kind of explains, “This is the bare bone set up I would get, and this is the next thing I would get, and this is the next thing I would get…” And so if you are trying to build your podcasting setup piece by piece, then what he recommends is really a great way to go. So those are my picks. And with that, we will wrap things up.

Before we do, Chuck, can I talk about the Book Club?

Absolutely.

It’s not like we are short on time or anything, right?

Right.

So this was our Book Club episode for this month of course, which is Smalltalk Best Practice Patterns. The next book we are going to be reading is Eloquent Ruby by Russ Olsen. And it’s a book about kind of along similar veins of Smalltalk Best Practice Patterns, but with more of a Ruby focus. It’s different in that it’s a lot more real world Ruby, I would say. And it may raise Josh’ blood pressure a little when he gets to the section about why people just use hashes and arrays instead of making objects.

But anyways, it’s a very well-reviewed book; it receives great marks. And I read Russ Olson’s first book and really enjoyed it. And it’s good stuff. So that’s what we are reading. We are not going to do it in one month for several reasons; some of the Rogues are busy in November, and also it’s a bigger book than we usually do, so we are going to need two months and we will talk about it at the beginning of December. Eloquent Ruby, pick it up, follow along and we'll talk about that in December.

I think that's it. Like I said, we are going to wrap this up. I do wanna mention that you can get this in iTunes. If you just lookup Ruby Rogues, you can find us there. You can also subscribe on the website. If you have any topics, go to rubyrogues.com, and click on “request a topic” and we will definitely take those into consideration. We've just had some awesome opportunities lately, so I think next week, we are talking to Corey Haines. Am I right on that?

Yes.

Okay. Just some great opportunities. And then if you are going to any conferences, look for us because several of us are going to be at different conferences. And Avdi and James are going to be at Ruby Midwest; I'm going to Apache Con. I think some of the other guys are planning on going to some later this year and the next year. So keep an eye out for us; come and let us know what you think and we will catch you next week!