289 RR Head First Ruby and Treehouse with JayMcGavren
- Published on:
- December 7, 2016
00:25 – Introducing Jay McGavren
1:20 – Teaching style and joining Treehouse
4:35 – Head First Ruby’s ideal audience
8:00 – Challenges with teaching
11:30 – Writing Head First Ruby
12:50 – Doing research
15:20 – Reader feedback
16:05 – Hangups when learning Ruby
20:45 – Searching for error messages
23:20 – Early days of programming
24:20 – Jay’s switch from Pearl to Ruby
30:50 – Building a thorough education with Ruby
39:05 – The rate of Ruby change
48:30 – Different languages and coding standards
The Ace Editor github (Jerome)
Evans Mill (Charles)
Selfie Sticks (Charles)
The Humane Interface by Jef Raskin (Jay)
Charles: Hey everybody and welcome to Episode 289 of The Ruby Rogues podcast. This week on our panel we have Jason Swett.
Charles: Jerome Hardaway.
Jerome: What’s up everybody?
Charles: I’m Charles Maxwood from Devchat.tv. This week we have a special guest and that’s Jay McGavren.
Jay: Hi folks.
Charles: Do you want to introduce yourself real quick Jay?
Jay: Yeah, sure. I’m Jay McGavren. I’m the author of Head First Ruby, published in 2015 by O’Reilly, late 2015. I’m also Treehouse’s new Ruby teacher so I do video tutorials. I think it’s pretty cool.
Jay: Andrew Chalkley maybe? Or we got a whole lot of folks?
Charles: Yeah, James Churchill, that’s who he was.
Jay: Oh nice, cool. Yeah, he’s a cool guy.
Jay: All the teachers are cool folks.
Charles: Isn’t that a job requirement?
Jay: Sure, absolutely. I made it in somehow too.
Charles: Nice. I’m curious, it seems like Head First Ruby and Treehouse, you get to teach people. You get to teach people some of the basics of Ruby. Did you write the book and join Treehouse for some of the same reasons?
Jay: Yes, very much so.
Charles: Okay. Do you want to just explain what your approaches then to helping people pick up Ruby?
Jay: Yeah, sure. My approach in the book at least is very much the general Head First approach, which is try to explain everything as clearly as possible, break it down as much as you possibly can. I find especially a lot of the reference programming books, they just throw so much at you at one time. That’s fine if you’ve got a bit of programming experience under your belt already but if you’re new or if a language really follows a different paradigm than you’ve been using so far, it can just be overwhelming.
Over the years, I’ve just developed the snack for breaking complex topics down into more manageable chunks. That’s what I do in the book and that’s what I’m trying to bring to my Treehouse teaching as well.
Jason: I think that makes a ton of sense. I was listening to Reuven Lerner I think on one of his podcast. He said something to the effective of when he’s teaching because he does training. When he’s teaching, more isn’t necessarily better. Some people go in and they want to teach everything they know in a week, not realizing that it’s not necessarily better to try to teach people a ton of stuff. It’s probably better to cover a small number of things but make sure they really stick. It sounds like that’s kind of the approach that you take.
Jay: Absolutely. I actually got to consult with Bert Bates, one of the series founders and co-author of Head First Java when we were starting this up. That was one of the things he tried to drill into me was to put your topics on trial. Is this really necessary right now? Is it relevant to the one topic that you’re trying to currently teach? And are they going to need to know it right when they’re starting out? If it’s not, you should just exclude it from the book all together.
Jason: Yeah. I saw one of your notes about Did You Know side bars, which I really appreciate because those are pretty much invariably just distracting, no matter if it’s a programming book, or a business book, or whatever. Like you said, if it’s not necessary and super relevant to the thing that’s being taught right now just leave that out.
Jay: Yup, absolutely. You can’t teach the whole language at once and expect the current topic to really stick.
Charles: The Did You Knows are always just gee-whiz stuff. It’s not actually relevant, anything you’re learning is just, “Oh, here’s some trivia so I can sound smart.”
Jay: Right. I won’t claim that there are no side bars in the book, there were few things that were relevant to the current topic that elaborated on a little bit. There’s a side bar too but it’s not totally random facts.
Jason: Here’s a question, who exactly is Head First Ruby good for? Is it only good for somebody who’s completely unfamiliar with Ruby, or for someone who has been using it for a while, or has been using Rails so far for a little while? Is that something that is good for me to go learn something new from?
Jay: I would say that even if you’ve been using Rails for a while, if you’re not really comfortable with your grasp of the core Ruby language, say, you’re wondering why this bit of syntax is like it is, Head First Ruby is still a really good resource for you. If you don’t understand why keyword arguments work the way they do. For example, the chapter on hashes is going to be fantastic for you.
We tried to expand it out to the broadest audience we could but the original target is definitely somebody who has used a programming language before, maybe not completely mastered it but they know what a variable is, what a conditional is, that is if statements and things like that, and then they’re trying to move to Ruby. We try and really expand on the topics that will seem unusual to somebody who’s only programmed in say, Java or something like that.
We put a few hooks in there for complete beginners, we do briefly explain what a variable is but that’s the key target, is somebody who has done a little programming and wants to really master programming through Ruby.
Jerome: That’s actually what I rated the book. That is a great book for what I call an advanced novice. A novice is someone that has experience in program, an object in Ruby. At least a finish another beginner Ruby book and use in this as a skill reinforcement tool. I was like, it’s a great book, just written like learn Ruby the hard way but may not be like few of you mastered finishing it, if you finish programming in Ruby. Actually, I recommended it to several persons as well as one of my friends who’s going to college for CS because I feel like that would be a great book for people in those community, couple bootcamp grads as well.
Jay: Yeah. Bootcampers were our core audience I had in mind while writing the book. I don’t know how thoroughly it’s reached that market but definitely we were trying to target them.
Jerome: That’s a good market for it. I like it when I read it. I read the exercises, it’s a great reinforcement tool because one of the things that I always hear from bootcampers is that the programs, they go by and they put in so much information and sometimes they want to slow down and get a little more in depth. The book is more in depth with some of the basics, some of the core Ruby, beginning Ruby syntax and structures, which I really enjoyed.
Charles: One thing that I’ve noticed though is because I’ve tried writing books, and inevitably everything connects everything else. I start talking about one topic and then it’s, “Oh, but it would be really helpful if you understood this other topic.” So you’re getting into numbers, and then you get into arrays, and then you get into some of the functional programming stuff that the collection methods like inject, collect, map, and all that stuff. Pretty soon I’m like, “Oh, will it be really handy to know this?” But then I realized I haven’t given you enough information to really understand it when I teach it. How do you deal with some of these things? When I’m teaching Rails it’s like, “It will be really handy for you to know Rake but at the same time in order for you to understand Rake you have to understand how to pull some of these other stuff in.”
Jay: I have a magic secret for determining how you’re going to teach this kind of stuff, it’s to rewrite everything you’re doing from scratch over and over. It’s quick, it’s simple, it only takes a couple of years.
Charles: Oh, is that all?
Jay: Yeah. It really is a balancing act. I definitely have found that if you want to achieve quality work that maximizes the ease of learning for the reader, you have to be willing to do rewrites and there’s just no work around for it.
Charles: In other words I have to work to work?
Jay: Afraid so. It’s definitely a balancing act. I can tell you my general strategy for coming up with any particular chapter or anything like that, is I try to come up with a really good concrete example. It’s basically a project that people are going to be working on. For example, the Number Guessing Game that we start Chapter One with. The program says, “I’ve picked a random number between 1 and 100, you have 10 chances to guess it.” That drove teaching of conditionals because you had to compare the user’s guess to the random number that the program picked. It drove loops because they get to try 10 times and several other topics that I needed to teach for that chapter. For hashes, we needed to pick lines from a text file that contained candidate’s name. Count the number of votes that at the curve while the ideal solution for that problem is a hash because you can use a candidate’s name as hash to key, and then keep a tally of the number of times you’ve seen that vote as a hash value. You walk them through that example.
What I was doing in a lot of the chapters was I would show inefficient ways to solve the problem and then I’d show, for example, why a hash works so much better. There was an example where you were creating a class that created a list with comments and it’s one, two, and three. We showed why unit testing was important because that prevented it from breaking.
Basically you just choose an example that you are sure is going to walk through the features of the programming language that you need to show and that helps keep your learner oriented while you’re going through the topic.
Charles: Yeah, that makes sense.
Jason: I have a question for you Jay. How long did it take you to write this book? It’s a pretty big book and I’m just curious, how long does that kind of thing take?
Jay: We set out for 450 pages as a final target. I think we wind up going a little over 500. The project actually grew as we were working on it. It also took a little longer than originally planned. I was keeping track of time spent on it while working on the book. It’s over 2,000 hours, probably in the area of 2,500 hours worth the work that’s go into this.
Jason: That just like spending nights and weekends on it or is that like similar to a full time occupation doing that. How did you structure when you work on that book?
Jay: I’ve heard different Head First Software tackling it in different ways. Some folks try to take a sabbatical and work exclusively on the book. I wish I could have done that but for me it was nights and weekends because I still have a day job.
Jason: Yeah. I think that’s a way a lot of people probably do it.
Jerome: Jay, one of my questions is where did you do the research for the first chapter that came along of the best practices and talking to learning advice you gave. Some of the things I realized they were really great ideas and really great advice. I’m already in my habits so I can do all of them. I try to literally do everything that your book said. I can’t do the like learn at night because I wake up super early and by the time I sit down at the end of the day I’m like type like really draining, I only want to read like Facebook post, much less a book. I’m early morning guy but I want to know where did you get that? That was nice ball, about make it the last thing you learn, how to learn even the things that you also even recommend some things [00:13:45] die, make sure you’re hydrated and things to that nature. I just want to know where are the reference points so my piece would really help you learn and using all the pictures and things to that nature. What are those data or that advice pulled from?
Jay: You’re talking about the intro, the how to get the best learning out of this book. That actually is not mine. That intro appears in most books in the Head First Series. I am pretty sure that that all got started with Kathy Sierra and Bert Bates back when they wrote Head First Java. I don’t know all the sources that they got that learning advice from. I know one book that Bert strongly encouraged me to pick up was Efficiency in Learning by Ruth Clark and several other authors. That had some general tips on how to structure learning materials to maximize how much sticks with the learner. Aside from that I couldn’t tell you all the sources they pulled everything from. I wish I could claim credit for that but that’s definitely the series’ founders at work there.
Charles: Darn it. This is too much humility. You should have just said, “I’m just a freaking genius.”
Jay: I’m faking it the best I can.
Jerome: Alright, cool, thank you.
Charles: I’m a little curious, what kind of feedback have you gotten about on the book is? Do you get people that say, “Oh, I totally got hang up but displace,” or “The way you explain this was really great,” or this just kind of go often to a black hole and you hear from people occasionally when you’re at conference and they go, “Oh you’re that guy.”
Jay: There has been a whole lot of, “You’re that guy.” I definitely am obsessively pouring over the reviews I get at Amazon. I’m sitting at an average of like 4.5 or 4.8 stars there right now.
Jay: Yeah. High score, achieved and unlocked.
Jerome: I’m going to go and start it right now.
Jay: Oh, thanks.
Jerome: It’s a good book.
Charles: I’m also curious as you’re teaching at Treehouse, where do people get hung up when they’re learning Ruby?
Jay: The core Ruby content was mostly taught by Jason Seifer, teacher emeritus at Treehouse. Right now I’m mostly focusing on a rebooted the Rails content. I’m just about to release course on Snatch or two because that’s good segue way from core Ruby into Rails. As far as where folks get hung up, installation of the programming environment. I hate to say but right at in their beginning steps is one of the most difficult aspects of getting started with programming. There’s just so much that can go wrong and we’ve taken pains to try to provide guides that make it as easy as possible but you still get DLL on some operating systems, there’s all kinds of dependencies that can be missing so very often people wind up going to our forums to seek out help when they get stuck. We strive to answer them there if they have problems. Of course if somebody doesn’t think to go to the forums, then we never know about it. I don’t actually know how many students are getting lost that way. I wish it was easier.
Charles: Yeah. But didn’t you have Rails installer and stuff around to make that easier or does that not actually solve the problem?
Jay: I forget the particular reasons that I didn’t recommend Rails installer for my recent Rails courses, maybe just a fact that it wasn’t setup to work with Rails 5 at that point. I seem to recall there were a couple others as well. There’s a post on the Treehouse blog which has my particular recommendations for getting setup with the Rails and Berm and on Windows, and we also have separate post for OS 10 and Linux. Basically that was a result of researching all the available options and figuring out which was a path of least resistance.
Jason: I’ve found the same exact thing. I’ve gone some Ruby meetups where this meetup is specifically for newbies, so come and we’ll teach you some stuff. Everybody is just like, “Hey, how do I get anything working on my computer?” It’s like, “Oh yeah, I forgot about that whole setup process.” I think it took me like a matter of days as opposed to like a matter of minutes or hours, it took me days to get setup the first time.
Jay: Yup. Sometimes you’re lucky and everything just falls into place but when you’re beginner and you don’t know what any of these strange debug messages that are popping up in your terminal mean, it can be a show stopper.
Charles: That’s it, I’m supposed to note.
Jerome We cheat at our non-populate. Just to get setup we use Cloud Nine, they have a pretty set Rails and Berm workspace. If you pick a Rails workspace and it already pre-sets so there’s no Gem sets. We’re teaching now how to do Ruby on Rails, you can actually move over to other type. As they get proficient they get more comfort then we can teach them how to set it up locally on their machines.
Jay: Yeah. Treehouse integrate panes that create an environment called workspaces for that same reason. For our Core Ruby classes, we actually rely on workspaces so that folks don’t have to set the Ruby environment up from scratch. We don’t have it working with Rails at this point unfortunately. Folks still have to set that up from scratch on their own machines. We’re going to try and fix that in the future but we’re not there yet.
Jerome: I’ll work on the similar project, I will definitely share you the GitHub I found with regards in doing that. Handles Rails 3, I’m sure some other fact we need to handle like four or five as well. The current one focuses on Rails and how that make workspace that actually can use it.
Jay: I would be super curious to see that, yeah.
Jerome: How’s that?
Jason: I just wanted to make a quick a comment to Ruby relative to getting setup. If anybody listening to this at the point where they’re just about to get started or they’re in the process of getting started with Ruby and Rails and just getting stuff working, one of the problems I’ve seen with people getting started is that like you said Jay, they get error messages and they don’t know what those error messages mean. The biggest problem I see is that people read these error messages and they try to figure out what it means, they try to read it and understand it. When what they really should do is don’t even try to understand the error message, this is my opinion, don’t even try to understand it, just copy and paste it directly in the Google and see what you find on Stack Overflow because chances are somebody else has encountered that issue before you. Rather than trying to figure out the solution, just find somebody else’s solution to that problem. It’s surprising how many people don’t do that.
Jay: Absolutely. Googling skills are absolutely vital. In fact we actually demonstrate using a full search engine in the documentation chapter. Just to get people use to the idea of searching for error messages and searching for documentation on how to use particular Ruby classes and libraries.
Jayson: Yeah. I’m just remembering as we’re talking about this, isn’t crazy there is a time when there is no Stack Overflow. Before that, I was even programming and I think you guys were too probably before there was even a Google. How did we get anything done?
Charles: Reference books, and you’d look in the index. If you found an error, good freaking luck.
Jerome: I was millennial. Google is around when I started programming. Don’t put me in the same space on other old guys.
Charles: All the other old guys.
Jayson: I’m more of an atavistic kind of person.
Jay: I used to work in one of those cubicle farms and I was lucky enough to have some senior developers who are ready to mentor me. I would just stop to the cube next door and ask my question. They were okay with being interrupted, thank goodness. Nowadays I work from home so I don’t have the cubicle next door, thank goodness I have Google.
Jayson: Actually Jay, I was reading your little about blurb in the book. It said that before you’re doing Ruby, you were doing Perl stuff, is that right?
Jay: That is right.
Jayson: And then you switched from Perl to Ruby. I’m just kind of curious about that transition. First, how did you get end up Perl, and how long did you do it, and then like what prompted that switch?
Jay: I have an unusual path up through my career. I was basically working on a data entry job for something that totally should have been automated the way by then expect that it was small enough job that it wasn’t worth investing, the development hours for a tool that small. It was basically just copying descriptions from one database to another. I was like, “These should totally be automated but I don’t have any tools for these, what can I do?” I search around, these were Windows desktops, and all I had available was Visual Basic for applications. The macro language that might come with Microsoft Word, I was actually using that for manipulating text for a while.
Co-worker in another department saw this and it caused him pain as it probably should have. So he lent me his copy of a programming Perl and said, “Oh yeah, you can totally install it on one of these desktops,” because there was an easy installer available at the time. I checked it out and I had hello world up in running in absolutely no time.
After a while, the programming Perl book had an excellent reference, all the libraries that Perl comes with, so there were network communication libraries and that had me talking from one database to another in very short order. Perl is a very concise language. It’s very expressive, much like Ruby. I wound up automating myself out of a job basically. They promoted me to I think they called it Automation Analyst. I wound up building and building on this Perl program to copy stuff from one database to another.
Jason: What year and time was this?
Jay: This was taking place between 2000 and 2003.
Jay: This company I was with, Java was their main language, it wasn’t Perl. Eventually that enough people were relying on this program of mine that they said, “Okay, we need to bring you into the actual development department and you need to learn Java because we are not going to maintain this addable program all the time. We can’t get rid of it because we need it. You need to start working with the official company tools.” My official day job was Java for quite a while but of course Perl was still my preference on the side.
There was that whole debacle with the transition from Perl 5 to Perl 6, where it just kept getting pushed out and pushed out. Of course Pear 6 is available now but that was about a decade too late for me. I made the jump to Ruby instead, which I really consider Ruby to be very much keen dread spirit to Perl. It has its roots in the UNIX command line, others are surprising number of syntactic structures that are the same between the two languages.
Jason: Can you think of any examples of those?
Jay: I believe argv for example, array for getting command line arguments. I want to say that originally came from Perl. A lot of the usage for Ruby on the command line where you can type Ruby-E to evaluate a stepped of a code right there on the command line, that came from Perl, just many, many little details that still exist in Ruby today that got barred from the Perl language.
Jason: Nice. Yeah I remember that. When I got into Ruby the way that I came to it was that I’ve been doing PHP for a number of years. I didn’t necessarily hate it but then on the side I started doing Lisp and I thought Lisp was really interesting. In the more Lisp stuff I did the less I liked PHP. Backed then nobody was really doing web applications with Lisp and so I wanted a more practical tool, that’s what led me to Ruby. I think when I was reading about Ruby’s origin, I read that it had roots in Lisp and Perl also.
Jay: Yup, absolutely. I haven’t gotten to do whole lot of Lisp coding. I want to say blocks or a structure similar to it originally came from Lisp.
Jason: I thought the map function was really handy too. When I first found that, it made so much sense. It’s like why this does not exist in PHP? I believe it does now but at that time it did not.
Jay: Yup. Map is awesome, most of the methods coming from a new Perl and then more abler awesome. I have to tell you though, when I was first picking up Ruby, I was learning from programming Ruby, the Pickaxe book, I encountered blocks and I was like, “Okay, I’m just going to flip to another chapter here because I don’t get that at all.” That is why I spent a whole lot of time to chapters on teaching blocks in Head First Ruby. Just break it down into really small bites because I know blocks were very intimidating for me when I first came to the language. I’d never seen anything like them and I figured they might be for other folks too.
Jason: That may be an interesting thing to talk about. It brings up something else that I wanted to ask about which is, when I first started learning Rails, I kind of learn Rails first and then learn Ruby. Obviously Rails uses Ruby so you have to know some Ruby in order to use Rails. I just got started with Rails without worrying about teaching myself a ton of Ruby in depth first, and then I went back and learn more Ruby. I still don’t have that depth of knowledge that I think I should. What I wondered that you probably know a lot better than me is for somebody who started Rails and has never used anything that’s Ruby without Rails, is there anything that they might be neglecting or have missed somehow that they could or should be taking advantage of in Ruby that you wouldn’t be exposed too just by using Ruby within Rails? Hopefully that question makes sense.
Jay: Yeah, it definitely does. I’m not the ideal person to ask about this because I came out at the other way. I definitely worked very hard on the core Ruby language before messing with Rails very much. Basically if had to guess, a lot of folks are going to be missing out on a lot of the capabilities of the core Ruby classes. For example, everything that array and hash, those classes inherit from the enumerable module, methods like map, and find, and all that good stuff. Not the version of find that’s ActiveRecord provides but the ability to actually search within an array.
Basically anything relating to the core classes, I find it really gets glossed over during Rails tutorial. There’s so much power available there that I really think folks could benefit from learning to harness it.
Charles: Yup. I’ll chime in on this too because I came into learning Rails and then I learned Ruby. Once I figured out how Ruby worked then my Rails got a whole lot easier because it wasn’t just do it this way but I started to understand why it’s that way. I think you alluded to that a bit there Jay, when you are talking about for example the enumerable module. I just took it for granted than anything that was a collection had, each, map, reduce, and all that stuff on it. I didn’t really understand that until I got into mixing in modules or the class system and how that works, how inheritance works, how we use multiple inheritance with the mixing in of modules, how we structure our classes and how we pull together just other things to compose as opposed to inherit different functions and features. Then just seeing, as you said, some of the core classes and how they’re really designed in Ruby as opposed to just taking for granted that they do specific things.
For me, it was much less, like what the core classes of Ruby are capable of, is much as just, why they’re put together the way that they are and why that helps Rails be what it is, and then how everything can hang together so that I can organize my code and take advantage of the ways that Ruby functions in putting my functionality in place with the functionality of Rails and other systems that I pull in.
Jay: Yup, absolutely. Rails and the default Rails project structure are very much a product of the Ruby environment that their built on top of. When you understand that Ruby environments, Rails becomes a lot less magical and I mean that in a good way. You actually understand what’s going in a lot better.
Jason: I think one think that people could understand a lot better that is Ruby but not Rails is just using plain old Ruby objects in your Rails projects. I remember reading the Steve Klabnik blog post, where he mentioned that it take him a long time and it took me a long time too to realize that not everything in your apps/models folder has the inherit from ActiveRecord, it can just be a plain old Ruby class. If you understand that then you can make your code a lot more organized if you do it that way. It can benefit your testing a lot because if you have classes that are just plain old Ruby objects, those can be a lot faster to test than ones that do a lot of database interaction. But that’s not something that I see in a lot of Rails apps that I come across.
Jay: Absolutely because the tutorials don’t cover it.
Jerome: Yes. That is actually something we ran to in our experience. Actually, two things that we wanted to is what you’re referring to the how is a lot of things are just very [00:36:06]. People don’t tend to learn and you’re dealing with just Rails. As one of my favorite books that I picked that was like the Ruby cookbook. It just has a bunch of stuff in it that really think that Ruby will do one as all. When it comes to work back to Jason was saying, like Jay say, they don’t teach a lot of that, they don’t teach that in the tutorials, they just leaves them out and you’re supposed to figure it out on your own. I definitely want it to do that more, I guess. I keep a lot more [00:36:49] more based tutorials out there that could actually focused on nuances of Ruby code. I was just wondering, what can we do as a community to do that? Because focusing more on the core language, not just learn enough Ruby so you can do Rails effectively? Oh my frame is currently out there.
Jay: That’s a good question. You know how I talked about how it was important to keep a laser focus on the topic at hand. That’s what I was trying to do in Head First Ruby. I really don’t blame the Rails tutorials for not talking about core Ruby too much because they need to be laser focused on the Rails content.
As a community, what can we do? I would say to steer people towards to a Ruby tutorials that teach the Ruby standard library, just more than the absolute basics. To give people a really solid foundation before they move on into Rails. Or if you’re doing a tutorial that same that teaching people Rails first and it by saying, “Hey, it would be valuable to you as a Rails developer to go back and learn core Ruby classes. Pick up the Pickaxe book. Pick up Head First Ruby because we really didn’t have room to teach you here, everything that you need to know about core Ruby. There is still more to learn and it can still make your code better.”
Charles: One of the things I see in this and I totally agree on the laser focus part of things. We’re trying to get people to results so they get the payoffs than stick around. That’s hard if we’re teaching them core Ruby concepts in the middle of Rails tutorial. I also agree as we put solutions up on Stack Overflow and things like that. Not just to give people a solution, create a plain old Ruby object that does XYZ in your Rails app but also explain why. This doesn’t need any of the ActiveRecord stuff and so we’re just creating a plain old Ruby object, we’re inserting these couple of modules, this is why it works, and here’s a brief explanation of the classes in Ruby.
Jay: Absolutely. I hate cargo culting, which is the old term for that, borrowing a snippet of code without really understanding it. It’s an obvious pattern for beginners to fall into so not really their fault but they definitely need to be taught the importance of understanding that code that they’re adding to their application.
Jason: Okay, another question for you Jay, just about the process of writing the book. Now that you’ve written it, and I realized it came out relatively recently, but do you expect to have to periodically go back, refresh it, update it, and stuff like that as the technology moves forward, or is it kind of evergreen stuff that you feel most part won’t have to touch?
Jay: That was the reason I wanted to write a book about core Ruby specifically, is that I’m expecting it to be fairly evergreen. This is one of the things I love about the language, changes nice and slowly. There’s not a new framework coming out every couple of weeks that you have to learn, there aren’t Python 2 to Python 3, the transition there, the statement to print align to the terminal change that didn’t work anymore. Suddenly a whole bunch of Stack Overflow answers that didn’t work properly anymore. That kind of frustration is something that the Ruby core team works very carefully to avoid.
Literature out there about Ruby definitely last a long time. I didn’t want to write a book that I was going to have to be updating every six months or whatever. I’m hoping that this will be a useful resource exactly as it is for a long time to come.
Jason: That’s great.
Jay: Yup. I’m glad we have Bundler, I’m glad that we have Ruby Gems, I’m glad that we have so much functionality ready to go out of the box. There’s no need to debate over which solution will use.
Jerome: I was about to say that. First question is going to be like, “Okay, tab or spaces, which one?” Go.
Jay: Actually it’s interesting. Looking into the Go language lately, they have quite firmly decided tabs. They’ve got this Go format tool that’s included with every Go distribution. If you feeded the file it’ll reformat it for you according to the community standards. Basically however, Go format reformats your code that is the standard. It’ll replace all your spaces with tabs. There is no discussion.
Jason: I think that’s great. I like it when somebody else makes those decisions for us because the alternative is to have an internal debate with your development team.
Jay: I like them as long as they’re the right decisions.
Jason: Right. If you have a development team, I’ve always been of the opinion that you use somebody else’s coding standards rather than come up with you own, because some of that stuff is going to have be arbitrary decisions and you can burn so much time just debating that stuff. It’s better to take somebody else’s. You might not agree with every choice they made but at least, since it’s somebody else’s it’s not just open for debate.
Jay: Absolutely. My general philosophy is smarter people than me have looked at this and come to this decision. I’m just going to go with it.
Jerome: Yeah. We used Airbnb style guide. They’re doing pretty good so we’ll just go ahead and hop on and use their style guide.
Charles: Ultimately for me it’s, “Okay, do I really need to take the time to make this decision?” It’s not even down to have smarter people than me actually looked at this. I don’t have time to make this decision so I’ll gloss over it, yeah, this looks close to what I want so I will implement it and then I will pick up the pieces and say, “This piece isn’t what I want.” then I’ll switch it out once it becomes painful enough for me to actually want to spend time.
All right. Before we get to picks, Jay, do you want to quickly tell people where they can follow you, buy your book, and check out other stuff that you’re doing?
Jay: Absolutely. You can follow me on Twitter, my handle is @jaymcgavren. It’s a little bit funny spelling so hopefully we can link that from the episode notes as well. If you want to check out Head First Ruby for yourself, they’re on Amazon, just go search for it.
Charles: Awesome. All right, let’s go ahead and do picks. Jerome, do you want to start us off with picks?
Jerome: Yes, roger that. My first pick is Effective Ruby: 48 Specific Ways to Write Better Ruby. I just picked this book while I was in San Francisco for better in stay week. From one of that reading is just really going to makes it a lot clearer. One of my things down is trying to read every Ruby book out there to mostly to set a life but to actually get better at language too.
Another pick, I would say the Ace Editor GitHub. For those of you who are looking into doing lot of cool project, like how to make a Rails app that actually has an inline text editor, then you can actually implement code and then run it. I would definitely recommend you guys looking up the Ace Editor of project tutorials. Those are my two picks.
Charles: Nice. Jason, what are your picks?
Jason: Okay. My two picks are books as usual and non-programming related as usual. The first one is this book called Titan, which is the biography of John D. Rockefeller. What I found was even more interesting was actually John D. Rockefeller’s dad was a really interesting character. That was an awesome book. I was into it on audio and it’s super great.
My other pick is I guess kind of a classic novel, Something Wicked This Way Comes by Ray Bradbury. Thought that was a really awesome book. I don’t read a lot of fiction but that one was really, really great.
Charles: Very cool. I’ve got a few picks here. The last week or two I was in Nashville and then I was in New York City. I wasn’t actually in Nashville, I was staying at a resort called Evins Mill, which is out by Smithville. I was out there for three days. It was just gorgeous out there, beautiful, beautiful area. I was out there for retreat with my Mastermind group. I’m going to pick Evins Mill just because it was amazing.
Jerome: I’m judging you, just to let you know.
Jason: You might fit in with those teenage girls better though.
Charles: I know. I need to cock my head to one side and put one foot up on my calf and strike a nice little pose.
Charles: Yup. Anyway, those are my picks. Jay, what are your picks?
Jay: Okay. I love video games. In honor of appearing on the Ruby Rogues’ show, I picked a Roguelike game. One that imitates the old dungeon exploration game Rouge, this is the Shiren the Wanderer Series. Rogue was just you had to look at squiggles and a terminal and deciphers, what the heck they meant. Shiren is way more approachable than that, it’s got cool graphics but more importantly it’s got really deep game play. It’s chess like and that it’s term based, you have to carefully position all your characters and combat or you’re going to risk losing the battle, just very deep game play. Many of the instalments are little bit older but that means they’re pretty cheap on Amazon. There are versions available on the Nintendo DS which can be compatible with your 3DS systems if you have to borrow from your kids or whatever. There’s a version out there for the Wii, which also runs on the Wii U of course. There’s a version that just came out for the PlayStation Vita. I love those games, super deep, definitely worth look.
Second pick is a book, it’s an older one, it’s called The Humane Interface. It’s by Jef Raskin, who was a core member of the original Macintosh project. Basically it’s all about making software interfaces that are possible for beginners to learn and second nature for experience users. That is totally automatic. You don’t have to think while you’re using the software designs that are in this book. You’ll learn about user interface sins that are way too common in modern software. This book will teach you things like why search that wraps around to the start of a document, like in many web browsers is evil for example. Just a great book, it’ll change the way you look at computers, it’ll make you very frustrated with a lot of their aspects unfortunately but it’s a really good read especially if you design user interfaces. That’s what I got.
Charles: All right. Thanks for coming Jay. It was fun to talk and interesting to just dig into some of the stuff.
Jay: My pleasure. It was great talking to everybody today.
Charles: All right. We’ll go ahead and wrap this one up and we’ll catch you all next week.
Jason: Bye guys.
Jay: Thanks folks.
Jerome: Bye everyone.