The Rogues talk with Mike Clark about teaching Ruby.

Special Guest: Mike Clark.

 

My voice is going through a $400-microphone into my mixer, and then being sweeten up by the mixer before you guys even hear it, so.

And who said money can't buy you happiness? Right, Chuck?

That’s right [Chuckles] .

Hey everybody, and welcome to episode 27 of the Ruby Rogues podcast. This week on our panel, we have a special guest Rogue, Mike Clark.

Hey, thanks for having me.

Do you wanna introduce yourself, Mike?

Sure. I'm Mike Clark. I run the Pragmatic Studio. We do Ruby and Rails training, and I'm also a Ruby Rails developer, and I've done some iOS stuff as well. So that’s what I'm up to these days.

All right, good deal. Also on our panel, we have Avdi Grimm.

Hello, hello.

We also have James Edward Gray.

Hey everybody, it's James. I'm sitting over here, stroking my fluffy white cat, thinking about how to take over the world.

[Chuckles] We also have Josh Susser.

Hey, good morning everyone.

And I'm Charles Max Wood. And let’s go ahead and get started. This week, we are going to be talking about Teaching Ruby, and that’s why we have the expert, Mike Clark on here. So Mike, why don’t you go ahead and get us started with just some of your thoughts on teaching? Maybe some of the challenges that we face, and things like that.

Oh, I knew you were going to do that, Chuck. “Go ahead and get us started, Mike.” No problem at all.

[Chuckles] Okay, let’s be a little nicer to our guest.

All right, Josh, why don’t you get us started.

Okay, I´ll get us started then. So I think this was my idea -- this topic. My first Rails training was from Mike Clark -- way back when. So I think many of us have experienced like classroom setting teaching of Ruby -- which is a big part of the topic -- but I think that it's also a lot of teaching in Ruby that goes on in our day to day stuff, especially if you are pair programming with somebody or mentoring new people, or working on open source projects. So when I envisioned the topic, it was a little bit bigger than just classroom settings. But I think that there's a lot that we can learn from classroom settings, that could be helpful to how we teach Ruby to people, in our day to day interactions. Or how we even learn it ourselves.

I think you’ve brought up a really keep point, that I’d like to sort of start with in that, everybody learns in a different way, and some of those ways can overlap; it can be classroom and pair programming, but our experience has been, you know, we do classroom training primarily, because we are not on site with people on their project. But having someone to mentor them or pair program with, back on the project in the context in their actual domain is really, really key. Because what you wanna do after you get sort of like formal training, is to actually build something; that’s how you learn how to apply those things.

So a lot of people think, “What one thing can I do to learn Ruby?” And it's actually multiple things; it's sort of like a progression or stage to go through. So we very much advocate learn it the way that works best for you, but also try different ways; put yourself in different situations to do that learning, because that’s going to be the thing that really helps you grow as a Ruby programmer. So I think it's great to talk about all those different ways, not just classroom.

So, do you have a favorite project that you kind of turn people lose on after you teach them?

No, we don’t. We actually turn them loose back on their project. I mean, most of our students are coming from an existing project in some company doing Ruby -- primarily Rails, but some companies are still doing pure Ruby. And what they are looking to do is get skilled up enough from us, that then they can go back and be productive on their project.

So we generally tell people when they leave, “The best thing you can do when you leave here, is to go build something. Now, that might be something you've got to do for your company, obviously. But if you don’t have one of those, it could be something you've always wanted to build. It might be a Rails app or it might be a Ruby game or you might play with some gaming library.”

But basically, whatever excites you, and it's going to get you motivated, is probably the best thing to start with. So we don’t sort of like assign the work on this project when they are done. We give people pointers, but you want people to be engaged in what they are doing, and they are going to be engaged in what they are excited about.

That makes a lot of sense. And that’s something that it saw with my online course, because I taught an online course that just ended last week, and I kind of assigned them stuff , and I think it would have gone a little bit better if I’d let them work on something that they were building themselves. And I do get questions from one guy that’s still working on something of his own. But yeah, I really like that idea and that approach.

So it's kind of interesting that Ruby conferences seems to be picking up on this training vibe, and really starting to put training days in before the conferences and sometimes, they are run by professional companies like Pragmatic Studio and stuff like that. A lot of times, people volunteer to teach a class on something for half a day or whatever, and I've done several of those myself. And I

was just thinking, Mike, what are your thoughts about those kind of informal trainings around the conferences?

I think it's a great idea. I mean, we did some stuff years ago before Rails Conf. We did something called the Rails Guide Book. And basically, the intent was, think of it sort of like a tutor book or a tutor guide, where you want to like go to some foreign land, and visit some foreign land and see what’s going on, but you don’t want somebody to just like… you show up in the airport and you are like, “Okay, what do I do now? How do I get the most out of this trip?”

And so the intent was, in this day before the conference, we'll show you all the sort of major attractions, introduce you to the language that you are going to hear sort of spoken around the conference, and just get people basically comfortable; feeling like, “Oh, okay. I know where I wanna go explore. I feel like I know enough about the language that I can communicate with people, and not be embarrassed to do so.”

So I think it's a great way basically bootstrap people in the conferences. And more than that, help them get more value out of it, overall. Because to the extent that they feel a part of that, because they are sort of knowledgeable, it just makes the entire community a lot better. And they are more productive during the conference too, so I think it's a great thing.

I think it can be tricky to pull off. I mean, I know people have approached us about doing some of those around different conferences. And it can be tricky because if it's a long conference already, it means people away from home for one more day, which can sometimes be a stretch for people. And they've already committed a certain amount of dollars to the conference.

So you know, we did ours basically as a charity, where there was a small payment that you made and then it went towards a number of charities. So I think you got to be a little bit careful about how much you charge for something like that, although it's valuable, people are already, sort of like the main thing is the conference. But it can be done; and it can be done really well, and effectively.

Yeah, what I've noticed about doing them and stuff, is it is a pretty wide range, and I personally enjoy that. Like, you get some people who are just kind of showing little ideas or things they’ve done in their own projects and stuff like that. And that can be good and interesting and stuff, depending on what you're after. And then, even with other people, it was kind of surprising that they are not typically in a training scenario, and they turn out to be real well. And so the content can be well-varied and stuff, but I kind of like that; getting into some of the stuff I don’t normally see.

So I'm kind of curious, because we've been talking about kind of the formal training aspect of teaching Ruby, or teaching Rails. How did you guys learn? Did you guys have mentors? Did you pick things up just on your own or off of blogs? What ways did you have for learning Ruby or Rails?

I had been doing Smalltalk for many years, and I had a little bit of background in functional programming, although I never really used it much. Picking up Ruby was pretty straight forward for me, in terms of all the concepts, because it's a really good implementation of Smalltalk in a lot of ways.

So I went out and got the Pickaxe book and started reading that, and I just started downloading Rails and started playing around with that, building little apps, kind of stuff. And I was working at EarthLink at the time, and right when Mike and Dave started doing their Pragrammatic Studio Trainings for Rails and brought them in, and set up a two-day training course. And I participated in it and, I guess the rest is history.

I did it sort of of like Josh. I came mostly from the Perl world, and I grab a few books and taught myself a lot of it. Also, back then, I came in at the end of the era, where the Ruby talk mailing list was an absolutely phenomenal resource. So I spent a lot of time on that mailing list, and interacted with a lot of first generation Ruby folks. And so they were very kind and answered by questions, and really got me over the hump. And that’s how I picked it up.

I started reading the Pickaxe. I guess it was probably… just when it came out. I was sort of tracking what Dave and Andy were doing, and I knew Dave and Andy before that, and I started reading it. And I guess I was sort of typical in the sense that I read it, and I really like the language and I said, “What am I going to do with this?”

But I sort of kept playing around with it. Not, to the degree that Dave Thomas did, but I sort of just fiddled around with it. And I knew Dave. And I have to say, I really owe Dave all the credit for me getting in to Ruby on Rails, because I knew him at the time, and I was able to ask him questions about Ruby. And I mean, he’s just been an incredible mentor for me, since then.

:Unit, that weren’t to test that Ruby was actually doing the right thing, because I knew that was the case. But it was a way for me to have a repeatable suite of tests, that I could poke and prod on Ruby, and see what it actually return to me.

So the story was, I read the Pickaxe, and the Pickaxe basically said, “Type this and then hit return, and you should see this result.” And I did that for enough pages and I finally said, “You know what, I actually wanna type that in once, and I wanna capture the results. And I wanna be able to go back and look at what it was.” And so I wrote this blog post called, “Ruby Learning Test,” which was just basically how I learned Ruby -- by writing little tests against things like strings and arrays and hash and figuring out how they worked -- and I just kind of snowballed from there, and continue to get into it.

And then when Rails came out, I was like, “Oh, I know what I can do with this now, because people want web apps,” and I was fortunate enough to know some people who saw me playing around with Rails and when we started doing teaching, hired me to build a Rails app for them. So my first Rails project was literally a production app, back in the day.

So Avdi, how did you pick up Ruby? Because I know you've been in the community longer than I

have, even.

I read the Pickaxe. I was a general language geek for a long time, and I was doing a lot of Perl for like data mining and stuff like that. I was [inaudible] and this Ruby language started getting mentioned more and more in those communities. [inaudible]

So it's interesting that basically, none of us seem to really picked it up via training, and yet, now a lot of us have been involved in doing trainings for other people.

Yeah, I kind of came from a different angle because, before doing Ruby, I was actually a systems administrator; I didn’t come in from another language. And really, what it did it for me was I was working with Rails developers while running a tech support department. And anyway, we needed a tool, and I've done programming as part of my degree -- I have a computer engineering degree -so, I could code I just really didn’t. And so I got into it and really started to enjoy it. And so my first language and my first framework were Ruby and Rails. So just kind of an interesting thing there.

And most of what I picked up was really from working with other people. It was more mentorship. I never have read the Pickaxe book. I have every intention of doing so when I have it on my shelf. Ultimately, it wasn’t from the books; it was from the other guys that I was working with and the things that I have learned from them.

So let’s go back to the training scenario, when we end up in a room full of people interested in learning more about Ruby; where do we go from there? Mike, I know you had some interesting things to say about this before the show, so.

You mean, where do you go from there after the training?

No, how do you start a training for Ruby folks? What's a good place to start?

Yeah, well so you said you end up in the room, and I´ll start there because we tried to not make it, so that you end up in a room. And we do that by… before you come to the class, actually giving you something to do; getting you into Ruby. And that includes installing Ruby, so we’ve got online instructions for how to do that. And it also includes like some recommended ways to get started. Because when you show up in the room, you wanna hit the ground running.

So we try to actually bootstrap you into the training, so that when you are there, you are getting the most out of it. But also that, in a way, it sort of lets people get motivated about the language a little bit. And lets them play around with it some, and it lets them form questions that they are going to have during the class. And we do that just by saying, “Here’s what we want you to do before class,” “Here’s how to install Ruby. We want you to do a little bit of reading online. We want you to type in some code and see what it does. You may not understand how it works.” So it's not completely foreign and fresh when they get to the class.

And I don’t know, that’s just the way that we do that. And so from there… in the early days, it was mostly people who had really strong programming backgrounds – mostly Java. A lot of Java programmers. And as I said when we were talking before, I think the easiest way to teach somebody something is to try to understand what they already know, and then try to figure out what they don’t know and give them some motivation for what they want to do. And then basically do the dif.

So if you are a java programmer and you really understand OO, then if I show you what a class is like in Ruby, you say, “Oh, that’s sort of like a class in java, except I don’t have any like types.” So then we can figure out, “Okay, the difference is it's a dynamic language. Let’s talk about that.” But it's always wrong to assume that java programmers know anything about a little. They might know java syntax, but they don’t necessarily know object-oriented. Right? They are orthogonal concepts, really. So then you have to step back and you say, “Okay, the dif is in Ruby, we’ve got these objects and we need to understand what they are, because they are really powerful and classes are objects and all that stuff.” So do that sort of diff.

But these days, I think – and this is totally anecdotal – but we're seeing more and more people coming to Ruby and Rails in particular, that have no programming background, right? They are just like, “I wanna learn to program.” So figuring out what they know about programming is pretty easy, unless they self-started, they don’t know much at all – which is good in one way. They don’t have a lot of baggage. They don’t care about types. They don’t know what a type is. But it's bad in other ways, in that you have to start from the basics, which is before… I need to teach you about iterators, and what a loop is. Why would you wanna loop over something? What is a variable? Sort of thing.

And that gets really hard because that’s a huge curve. If you think about what's going on in Rails today, and everything that goes into getting Rails installed in your first Rails app running, if you don’t have that background, I mean it's a pretty steep mountain. Especially in our public classes, it's tricky because you got to figure out, “Okay, who in this class has a strong programming background?” And the diff is pretty small versus who the people in the class, where the diff is huge, right?

And so you just kind of got to start with what you know, and what do you wanna learn, and really motivate them towards that. Because I hate taking classes where it's like, “Here’s the syntax.” What I wanna know is why would I want to do that? And so you figure out, “Well, what do you wanna be able to do?” “Oh, I wanna be able to method that does this.” “Okay, let’s talk about methods.” And motivate them that way.

So mike, what are the strengths of Ruby that you used to motivate people to learn it?

Well, the strength there in terms of motivation is there's very little friction, right? If somebody says, “Hey, I wanna be able to print out my name” It's like, “Okay, puts your name. Let’s start there.” Now, we don’t do that in Rails. I mean, I would do that in a Ruby course. We can't start everyone on a Rails course at that level. Which is why we try to prepare them beforehand, to get to the course necessarily.

But the fact that it stays out of your way, means that people can get where they wanna go a lot sooner, and you don’t have to explain a lot of those stuff. If you were having to show somebody how to print their name in the console in java, you'd have to tell them about, public and what static means and void and string and all these stuff, which they don’t care about. It's like, “Okay, whatever, I just wanna print my name.” So I think the biggest strength of Ruby is that it's like principle of least surprise. You wanna print your name? Type puts “you name” or type print “your name” if you want. And it just works. And that’s huge; I can't overstate how big that is for people.

So Mike, you touched on a bunch of things there that I found interesting. One was that people coming to our language now that don’t have any experience and wanna learn to program. I've seen some of that too. And the interesting thing I find is I think Ruby is a little bit hostile to that crowd -not in a language and stuff like that-- more in community. And I think that's because we kind of grew up as a community of language geeks and stuff and kind for found it early. I'm not sure we've done the best job in the world of preparing the beginner materials. Do you agree with that?

I don’t know. That’s a good observation. I don’t know that that’s true. And reason I say that is because there's actually quite a bit of good stuff for beginners out there. I've heard from a number of beginning programmer sorts, who would tell me that Why's Poignant Guide was a way for them to start. And for me, Why's Poignant Guide was confusing. It just wasn’t the way I sort of wanted to learn. To me, it was sort of like -- I know this is going to be like heretical to say -- but it's sort of like weird way to explain what's going on. I want it sort of more straight forward, but I had this programming background.

So there was stuff like Why's Poignant Guide, there's the learn to program book. So, there's quite a bit of material for beginners. But I agree with you in a sense that, these days, the ecosystem is pretty big. And I was thinking like Ruby was a lot easier back in 2005. You know? It was just like there was Ruby, there was some gems out there, and you can get started pretty easily. And I guess the thing would be you didn’t feel like you were an outsider, because there weren’t very many insiders. There wasn’t a really big sort of community.

And I think if I were a Ruby programmer today, or trying to learn Ruby, and I went to a conference, it's not that people would make me feel an outsider, but I would feel like, “Wow, I have to figure out how to work my way into this community if I'm going to get the most out of this.”

But I don’t feel like Ruby or Rails has done anything overtly to like discourage people from doing that. I don’t think we've made it hard for people to install Ruby. I think we've made it easier for people to do things in Ruby and Rails -- given that they already know what's going on. But in some ways, that makes that harder for beginners.

Yeah. Well I have to say that the materials that are around now for people to be able to learn Ruby are so much better. I actually first heard of Ruby in 2002, and tried to pick it up, but there wasn’t much for me to look at and read, and I gave up pretty quickly. So now, it's a completely different world for people coming in to Ruby. You mention there is Try Ruby, Kids Ruby, tons of blogs out there and some really good training courses. So, different kind of world.

Yeah, it would be interesting to know, like what it would be like coming in today. I mean, that's hard to do, to sort of put yourself on their shoes, because all of us on this call has been in this for so long, that you really have to step back when you are trying to teach somebody Ruby. And say, okay, well sort of forget all of that a little bit and just boil it down to, “Let’s talk about what you wanna do, what you understand, what you don’t,” and go from there.

In that respect, it can also be really fun for them, because there are certainly people who want an experience where they are going to learn something, and it's going to take them into more ears, right? They learn Ruby and they are going to become part of this community. And there are people out there that very much want that sort of social aspect, really. And it also shows them where they can go. They say, “I wanna learn Ruby, because I wanna write a Rails application, because I wanna go to Rails Conf and give a lightning talk, because I wanna be the next IPO.” So there is an actual progression that they can see, which is kind of cool. I wouldn’t recommend that progression, but….

But it works for so many people.

[Laughs] Yeah, it's interesting the points you were making. I had a client, she basically tried to write… I mean, it was a simple app, but she tried to write this app in Rails, and I just don’t have the time or inclination to figure this out right now, so she hired me to build it for her. So when I gave it back to her, so she could do the design work and stuff on it, we went through all kinds of stuff with setting up RVM, and setting up Rails, and doing all these other stuff, and then she tied Rails admin on to the backend and I customized some things on that for her, so she has her own custom fork.

I mean, we went through all of that too and she’s just like, there's so much to know! And I didn’t even think about it. You know, it was for me, it was like, “Well I thought for me, it was real easy.” When I learned Rails probably 5 or 6 years ago, and I was like, “Yeah, it was easy when I learned it,” but yeah it's changed so, so much. And just to have to understand all these stuff that’s out there with RVM and bundler and Ruby gems and everything else, it was really kind of eye opening for that. But then, you get these other guys that come in, and they just kind of seem to gravitate to it -not every necessarily for the language sometimes for a community like you were talking about.

Yeah, but we see people that excel the most, are who have a real goal -- they want to do something -- as opposed to people… and there are certainly nothing wrong with this, but I know people and I've talked to people, who will go to a class and they will ready five books and then ten books, and then they'll be out reading all these blogs all day long about Ruby, and they are learning stuff, but because they are not really applying it, it doesn't really stick.

And I always encourage people, “Find a way that works for you to get started; whether that’s in a classroom, whether it's somebody, a company that can mentor you over lunch, whether it's reading a book.” And then set a real goal; like, “I wanna write a program that’s going to like record my favorite football scores,” right?

Because then that's going to motivate you to learn the next thing, because you are going to get to a point where you are going to say, “Oh, I wanna store these in the database.” Or even simpler, “Oh, I want to store these in comma separated values.” You know, “Okay, go learn the CSV library,” or “Go learn Active Record.” And then you have a real reason to go learn those things. And then when you are actually applying them, it sticks, because you remember that time where you wanted to save something in the database, and you learned active record, for example.

Because when you are just sort of wandering around, picking up every bit of knowledge you can, there's no in to it. You don’t know when to stop. It just sort of like, “I'm reading it, but I don’t know what this is really good for.” So I think people excel when they have a real goal.

And all of those rabbit holes are so deep, right? [Chuckles] “Oh, I´ll just learn a little Rails.” Yeah, you can keep doing that for years.

Yeah, I think that’s a really good point. Something I've seen, I don’t do it, but I have some basically two ring engagement that I do, and that’s something that I've seen is… as a result of the fact the Ruby community is largely moved on from talking about language itself so much, into sort of talking more about the universe of technology that’s in the language [inaudible] And somebody can… and I've seen people can do like… they need to have an opinion over like whether they prefer Redis to CouchDB. When really, all they have to be working on right now is figure out how to use [inaudible]. And so it can be there is this feeling like you have to understand this huge ecosystem of technologies. And I think it would be helpful if there are sort of guide to [inaudible] perspective. Here is the sort of progression of things that you need to understand. And there are a lot of things that people need to worry about first.

Yeah, but at the same time, I think there is something to be said too for tackling some of the hard problems. I mean, there are things that I have learned about different technologies and things like that, because I went out and tried to figure out MongoDB, I tried to figure out Cassandra or this or that. I think initially, you are correct. Yeah, don’t worry about these other details if you use Couch or Mongo, but I think as you move ahead, and you are trying to get in to some of the more advanced or intermediate topics, eventually, I think you do need to figure out, “Okay, I'm going to dig in to this and challenge my thinking in this way,” or “I'm going to open up this because this is different from what I've dealt with before,” and see what's new to learn there.

So I'm going to try and hijack the conversation here, because Mike hit on something interesting earlier that I wanna talk about. That is he kind of dismissed learning syntax -- with an offhand comment. And talks more about learning how to think about programming and that’s always been a very big deal in any teaching I've done. I always feel like programming teaching is so syntax focused. “So, you wanna learn Ruby? Here's how you find methods in Ruby.” And stuff like that.

And it’s like, you know that is the dumbest, easiest thing to learn that has nothing to do with programming. That it's thinking about programming; learning to think about how machines work and stuff like that. How they have to have the steps spelled out for them, and why do we have to, when we wanna change one in the middle of the file, why do we have to make a copy of it and rewrite the first part and then rewrite that one line, rewrite the last part, and then move it back over the first one. It's things like that; learning to understand how those process work that I think are so tricky. So Mike, why don’t you talk about like in your teachings, how do you handle the thinking about programming?

In terms of the syntax thing. Again, if you are coming from another language, it just seems pretty easy, right? You say, “Okay, here's how you write a method in this language. And here's the syntax in Ruby.” And if you got that background, you just say, “Oh, okay. I know that a method is going to have a name, and it's going to possibly take some parameters.” And then you just sort of do the diff there. That’s not real tricky to do.

But there are times when people know how to write a method, but they don’t really know what a method is for. And I don’t say that to sort of like belittle what people know about Ruby, but when you step back and think about conceptually, you are talking about… a real question is, “When would you write a method?” And what should a method do? How big should the method be? How small should the method be? What should it know about? When you pass in things into a method, what is good and bad coupling? You know, if you pass in too much, is that bad? If you pass in too little, does it have to ask other objects what to do?

So, the syntax is certainly one thing; you can't side step it is when you are teaching a beginner to write a method, if you were to stat with the concept – which is good --- and motivate them, “Here’s why you want a method.” “Here’s how you create a method right now.” But if you gloss over the syntax, they kind of won't come along with you, because what they are looking at and they type that in, just feel so foreign to them, that they can't really get it conceptually until at least they feel comfortable enough about the syntax.

But my experience has been you wanna show them the least amount of syntax possible to get them to the concept. So if I was teaching you methods, I will show you the simplest possible method. And then if we had to pass a parameter to that method, I will show you how to do that. But I would certainly not at that point, say, “By the way, here's other bunch of stuff we could do. We could pass in a method that has a default argument, we could pass a method that has a default argument that’s based on the values of the previous arguments. If the last argument is a hash, we don’t have to put the curly braces on.” That’s where you lose people , because they are like, “Wait, I don’t care. I don’t need that stuff right now.”

But that gets tricky too, because if you just create the simplest possible Ruby class, create some like person class within an attribute, like an initializer and a method. And if you sit back and look at it, if you try to explain that whole thing at once, it's difficult. There’s a whole bunch of stuff going on there that’s really easy to us. If you get beyond just the class level syntax, if you had like an adder reader in there, you may have to explain that it's not a keyword and the class is active, so when the class is being defined and code is actually being run.

So there's a whole bunch going on in there, that you want to get them comfortable with that at some point. But if you overwhelm them with the syntax upfront, they just get lost. And so it's a delicate balance -- it really is -- in terms of how people pick up the syntax. I'm not necessarily a language wonk. I couldn’t compare Ruby syntax to four other languages. In fact, I sort of forget all java syntax I used to remember.

So I'm not good at remembering syntax myself. Other people are much better than me, at like remembering the sort of corner cases. I still look up corner cases and I used them, so sparingly that it's okay for me to just sort of forget about those things. So it’s encouraging beginners that they don’t need to know all these syntax to get something done. But when they do need to get something done, it's important for them to understand what they are doing, and what it means.

So I've a lot of success in training using kind of similar techniques. One thing I've done that really worked out well when I wanted to teach regular expression and Ruby’s integration, like you said, the syntax can really get in your way. And Ruby’s regex system is kind of one examples of that, because if you do like string, and then the match operator and some regex in IRB, if you are trying to show examples or something, Ruby just returns that cryptic index there, where that regex matched. And you have to explain, “Okay, this part is the match operator. This is what it does,” and I hate that.

So actually, one way I did it one time, is I started an IRB session, and we've already had a little bit of strings where so we’d have indexing in the strings, with like indexes, to get letters or substrings at some point. So I just, you can index into a string with regular expression, and it will return the part of the string that matches that regular expression. And it turns out that it's so much easier to teach and work with, because you put in this pattern that describes something and it spits out that part of the string that matched that pattern. And so the syntax basically just goes away at that point.

And then when I'm teaching regex, the way I do it, is I don’t even tell you what the operators or regular expressions are, I just show you examples. So I´ll show a bunch of examples in the class of things, and I´ll start introducing like a period and I´ll show several examples of what it's doing. And the students will figure out what that does overtime, and then I´ll have them write it down up in these whiteboards, front when they basically what some operator is in regular expression. And kind of puzzle it out that way, so that they are focusing in how things interact with each other. And I'm listening to them talk, and so if they get stuck on certain things, I´ll try to show them new example that looks at it in a different way.

Well, something that makes teaching a lot more fun and easier for people is IRB, which now that we've used it for years, were just used to having IRB at our fingertips, but the real key to IRB, I think, is that when students go into IRB, for some reason, there’s this sort of switch in their brain that says, “I'm doing something real. I don’t want to screw up anything.” It goes off. So they feel like they can actually experiment. Like when you open up a text file, and you start writing a “real program,” people are sort of afraid to do something. Like, “Well, if I type in the wrong thing, is it going to blow up?”

In IRB, for some reason, it just feels like, “Go ahead, experiment. And see what happens. Take an array, do something with it.” And that is really cool. And it's super easy to discount, but I think there are two different personalities happening. When you are in IRB, you are experimenting and you can actually learn. And for some reason, when you are on programming file, you feel like you've got to do the right thing all the time.

So we've been talking a lot about like teaching beginners, and not really much about teaching more advanced people. But one of the techniques I like -- either for beginners or getting more advanced people level up -- is blowing their mind, where you just show them something that is going to make them think, “Wow, what is that about? How does that work?” “Wow, that would really change how I'm doing something day to day.”

The Rails 15 minute blog video was one of those blow their mind kind of things. But there's a lot of little ones that you can do when teaching. And I'm curious if people like doing that or what they fall back on. I like things like the enumeration protocol, just join some partition usually blows their mind enough, that they are willing to learn anything about all the collection methods and all that. So there’s just a lot of little go to things that I like dropping in on people and saying, “Oh, look you can do this.” And they are like, “What?” And then they'll pay attention to a few minutes, so you can teach them something to learn.

That’s the key. I mean, I actually like the name “blow your mind” pattern, if you wanna coin it that.

Because when you are learning something, you want little winds along the way. So you kind of wanna stage, where it's like, “I´ll give you a little wind and then you rule. And then you get another little wind and you can do it.” And you do a series of this, and at some point, you go, “I really rule. I can do this.” But you sort of get a little lackadaisical too, like “Oh, I'm getting all these.” So after a series of those sort of, “I win” moments, it's okay, I think to do a, Okay, now I'm going to blow your mind moment. Because that’s going to get you to the next series of “I rule” moments, because you are going to say, “Wow, I wanna learn how to do that now.” Okay, let’s step back and look at what it actually is, so that at the end of that next series, you know what’s going on. But then you want another like, “What do you wanna do? Let’s blow your mind.” So I think that’s okay to do for beginners at a certain stage, not like the first day. But I think it's definitely something very effective for advanced people, because people love to sort of like continue to level up. And that’s one way to do it is to figure out, Josh something really cool and just showed me. And I wanna do that too.

Yeah, I think that kind of gets back to IRB a little bit. Mike was talking about how when you are in a

program, you feel like it's a different scale and scope and stuff. One of the things I worry about once I've opened the text file is where do I stop? Like how much do I have to write before I can run this thing and see what it does? And the great thing about IRB is where do you know the answer to that question? It's at the end of the line; when you write that whole line it stops and you get immediate feedback and those little successes and just like mike was just saying. You get those little victories along the way.

But I definitely agree with the ‘blow your mind’ strategy. I can still remember one of the coolest things I saw in Ruby back in my early days, and I can't remember who showed it to me unfortunately, but we were working with REXML stream parser, so you pass it some object and then it reads an XML document and it calls methods on that object as things happen; like tag start, tag end, that kind of thing.

And documentation was terrible or unfortunately famous for. And so we had no idea what to do, and someone showed me that just define the class, and just put method missing on there to just print out what was being called. And they passed that object in to XML and fired it off. And we basically just got this print of tag start with blah, blah, blah and it taught us the interface because of this one little trick he did, and I thought that was a great ‘blow your mind’ moment.

Yeah, you got to love those. And sometimes it's real simple if you are pairing with somebody and you just got something really, really simple, but you use it over and over and over again, and it makes a huge difference. All right, well let’s get into the picks. I hate cutting us off. Maybe we’ll have to do another episode on this and have Mike comeback, because I really feel like I'm cutting us short, but we need to keep this to an hour.

So why don’t we do picks, and we'll start with Avdi.

All right, I just wanna pick Ruby 1.9.3 which is now released. And there’s lots of good stuff in it [unintelligible] I've been using been using file.read for years, it just feels natural. Actually, I have another pick too; Plantronics 995 wireless headphones, which I've been [inaudible] for a while based on a bunch of recommendations, and it seemed like a great headset for remote pairing and stuff like that. [inaudible] Well, I just bought it a today, while I was getting ready for this is broadcast, and it's like one month out of warranty, so I don’t think I'm going to be recommending the Plantronics 995 wireless headphones anymore.

So that’s an anti-pick, I guess. [Chuckles]

[Chuckles] We feel for you, Avdi.

“Don’t buy that. It's bad.” All right, Josh?

Okay, on to me. My first pick is testfirst.org. that’s all about test first teaching of Ruby. Sarah Allen and Alex Chaffee did a talk about this at GoGaRuCo in 2010, and the video for that is up there on Confreaks, I guess. But testfirst.org has good resources for how to do teaching based on testdriven development. We didn’t get a chance to talk about that during the episode today, but I figured I’d throw that in there as a pick, so feel free to go check it out and look at the videos on the site, etc.

My next pick is MagLev. This has been a long time coming, but MagLev is now 1.0 for people who aren’t not familiar with it, MagLev is a Ruby implementation built on top of the gemstone, Smalltalk virtual machine. And gemstone has some pretty cool, persistent object technology, so it's essentially Ruby running on top of a distributed, NoSQL database. And it's pretty high performance. We haven’t seen benchmark published since the release yesterday. A year ago, it was faster than everything, except JRuby, so see how that goes. I think it's worth checking out. I'm going to be playing around with it sometime next week to see how it's all grown up in 1.0.

And then I have a quick fun one, which is the ancient inventions documentary series. And this came out a while ago, I think it was the late 90s, but Terry Jones from Monty Python is the narrator and host of this. And it's like 2.5 hours of stuff in three episodes. It's BBC documentary all about the brilliant things that inventors did thousands of years ago, and how a lot of how our modern convenience is compared to those things. I think it's worth checking out. I’ve been watching it on Netflix streaming, but it's out on DVD, and other formats as well. So that’s it.

All right, James?

Okay, so I've been working on some new apps and in that, I've had to do some interactions with email and trying different services. And I've had quite a bit success lately with Send Grid, so I wanted to recommend Send Grid to people, if you need to send out email. Really, if your Rails app sending email and stuff, you should absolutely never be using a local sending it to a… send mail. I'm sending it to local queue and sending it out. What's great is that it can be it's just, you eventually run into email deliverability errors or issues and it's so much work to work around those, that it's just not something you ever wanna do. So pay somebody else to solve all those problems for you.

And Send Grid is my current weapon of choice in that area, for getting it done. And they have a new newsletter API on SendGrid, which I've been making in one of my apps and I like it; it's not perfect. There are things that I would add to it. There’s a couple little issues. But, it's a good start and so you can, using this newsletter API, you can create newsletters and send them out to a bunch of people at once, instead of having to iterate and fire off 40 emails or something.

So I really like that, and if you do wanna play around with that newsletter API, my local Ruby user’s group has OK.rb is the group, we have a gem called the Gatling gun, which will fire out those emails for you. And it's really new gem, we just got it together, so it's not robust or anything. It still needs a lot of work, but I'm using it in production, and it's affective and working, so you might wanna check out those without things.

Yeah, those guys are pretty okay, and they were pretty okay gem. So, OK.Rb. Mike?

My first pick would be the redcar Ruby editor. It's an editor written in Ruby. It's free. It does great Ruby syntax highlighting. We started using it during training, because we found people would bring editors they are not really comfortable with. We were using Textmate, and Vim, and then other people unfortunately will try to use things like WordPad and text edit. And redcar runs on Mac, Windows and Linux. And it's really well done; and the guys who put it together are really friendly. And they put a lot of work into it. So I just want to give them a little bit more press. I like it so much, I put together a little 12 minute screencast on how to use it. It's also free. So we’ve been getting a lot of mileage out of redcar, and I just wanna get for putting it together.

My second pick would be -- just to be a little bit different -- is an iPhone app, that I got turned on to called, Instacast. And I don’t listen to a ton of podcast, but when I do, trying to transfer them from iTunes over to my phone is a real hassle. But with Instacast, you just subscribe to a podcast like the Ruby Rogues, and then it just downloads it to your phone and then when a new podcast come up, it will automatically download those. So get your Ruby Rogues podcast through Instacast. I don’t know who built that, but it's a slick little app.

That's great. I've been looking for something like that.

Yeah, I've used it off and on. The problem that I've had with it is that I like to be able to queue up my podcast in a playlist and play them, and then I couldn’t figure out how to do that with Instacast.

Why did I never have that idea? Chuck, I could kiss you.

[Chuckles] Okay. I'm a little disturbed now.

[Chuckles] Awkward.

Anyway, a couple of picks here. The first one is… a little bit ago, I picked balloon tower defense 4, and the guys over at ninja kiwi have actually put it out as an iPhone app, and so I've been playing it on my iPad lately, and it's just been a whole lot of fun. Just really interesting little game. Another pick that I have, that I wanna put out there -- and this has been around for a while -- but I've been listening to the Ruby show, and that’s done by Jason Seifer and Peter Cooper. And some of the stuff they mentioned, just like whatever but every once in a while, they really have just some solid news that I didn't hear, and it's nice to kind of keep your finger on the what's going on in the community with that podcast in the Ruby 5 podcast. So I just wanted to mention them, just because I think they are funny guys. And anyway, so that's kind of a good podcast.

And those are my picks, so if you wanna get the Ruby Rogues podcast, you can. You can find them at iTunes. Like Mike said, you can get us on Instacast. There are few other ones out there that I haven’t submitted to, that I have to submit to, and some of them were like Instacast where you just put in the podcast name and it will find it. We also have a lot of people on Android listening through Listen, so if that’s your thing, then you can get us there as well.

I really appreciate the reviews. We actually had, last time I looked, fifty one reviews, and forty eight of them were five star, which were really cool and I really appreciate all of the people who have taken the time give me feedbacks.

Yeah, and that’s not costing us that much money, so I think it's very worth it.

Yeah, absolutely. Anyway, that’s about all we've got this week. Next week is going to be a live recording from Ruby Midwest, and James is going to be that up, so we are all looking forward to that, and then we'll catch you in a few weeks!