01:15  - Announcements

• Katrina Owen/Angela Harms Episode
• Declaring Learning Bankruptcy
• Ruby Newbies Contest 06:53  - A Good Starter Project / First Ruby Projects
• PROM Image Preprocessor 14:11 - The Ruby Quiz
• Mini CMS
• Airport Mystery Shopping Rails Site
• Sequel
• Frat Girl - Email Management System for Support 23:27  - Authoring OSS 26:05  - PDI: Please Do Investigate 26:40 - Take Care to Properly Estimate the Size of the Change You Seek to Make
• Simpler Projects are Better 29:25  - ToDo Apps/Blogs
• Boilerplate
• Command Line App, maybe not Rails
• Heroku
• Simple Command Line Apps 39:05  - What should I work on?
• Do something you find interesting.
• ERB
• DRb
• MUD (Multi-user Dungeon)
• Chat Server w/ Combat 45:50  - Ideal Starter Project
• Overlaps Your Skill Area & Goes a Little Beyond 46:19  - Application for Streeteasy.com
• Ruby Sort
• Call sort_by – It Does a Schwartzian Transform
• Don’t Be Too Emotionally Connected to Your Starter Project

Transcript

JOSH: [babbles] JAMES: Oh, your Wookie impression. AVDI: [laughs][Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net]**[This episode is sponsored by JetBrains - makers of RubyMine. If you like having an IDE that provides great inline debugging tools, built in version control, and intelligent code insight and refactorings, check out RubyMine by going to jetbrains.com/ruby]****[This podcast is sponsored by New Relic. To track and optimize your application performance, go to rubyrogues.com/newrelic]****CHUCK: Hey everybody and welcome to episode 70 of the Ruby Rogues Podcast! This week on our panel, we have James Edward Gray. JAMES: Hello everyone. CHUCK: Josh Susser. JOSH: Hey, good morning world! CHUCK: Avdi Grimm. AVDI: Hello from sleep deprivation. CHUCK: David Brady. DAVID: Hey everybody. I am pair podcasting with Chuck Wood today. We have swapped cities. CHUCK:**That's right. I'm Charles Max Wood from devchat.tv. I'm actually in Chattanooga, Tennessee today  and yeah, that’s how we swapped. Hopefully I can swap back to home pretty soon. [laughs]JAMES: Is that why you sound like an 80-year old smoker? DAVID: Yes. JOSH:[laughs]**CHUCK: All right well, we have a few announcements. I'm going to let some other folks take care of that this week. David, do you wanna start us off? DAVID: Yeah. So, introducing our new segment, which is “T_he totally awesome thing that happened on Ruby Parley List”. This week, the thing that just blew me away from the list because a post from Katrina Owen, who was talking about the Angela Harm’s episode, specifically the un-schooling bit. And she was talking about _just in time learning versus just in case learning. The thing that blew me away; the phrase, the concept I guess -- the sopheme if you will. If phoneme is the fundamental unit of sound, a sopheme then is the fundamental unit of thought. And the sopheme that caught my eye of a totally new concept to me was, she said she declared learning bankruptcy. She has this huge back log of articles to read, she had all these things saved and she’s dumped it and basically said, “I'm going to learn the things I need to learn, when I need to learn them.” And all of a sudden, she was free to learn things she was interested in instead of all these things that she had to learn. That was freaking awesome. And that's going in my mental bag of tricks. And that's my bit. AVDI:**I was declared “learning too big to fail”. [laughter]JAMES: And how’d that work out for you? JOSH: --- bailout. JAMES: Oh. DAVID: He's continuing his learning Ponzi scheme. AVDI:[laughs] Other people --- the learning for me.**JAMES: That's awesome. CHUCK: All right. Well, we have another announcement. We are going to leave that up with Josh. JOSH:**Right. So given the smashing success of our last user engagement contest that we did, we decided to do a new one before the first one was even done. [laughs]**DAVID:**This is not a continuation of the bankruptcy theme. [laughter]**JOSH:So, we tend to do a lot of content focusing on people learning Ruby. And so we figured we would do something specifically about Ruby newbies, and see who is out there in the community who is new to the community and what that’s like for you. Because many of us had been around the community for a long time and we are a little disconnected from the experience of the newbies. So we figured, we will give you guys the stage for a bit and see what’s up, see what we can learn. So we are going to do a month long contest. Well, less of a contest, more of a -- I don’t know. Just call it a contest. What we wanna do is we wanna find some excellent newbies to come on the show and talk about being new to the Ruby language and the Ruby community. And the way we are going to find those people is if you are a newbie or you know a newbie, you get them to make a 5-minute video and it up on YouTube, and answer a couple of questions for us. You know, things like, “What are you using Ruby for?” “What do you like about the community?” We are going to put up a page on the website, you know, rubyrogues.com. I don’t know. It will be probably just be a post in the page but we’ll put a link in the show notes for that one that goes up. And come read the thing, figure out what's up, make your video and we will put you through some very demanding evaluations. [chuckles] And when we are done, we’ll have a couple of you come on the show and talk about being in the community and learning Ruby.JAMES:“Hazing” is not the wrong term. [laughter]**JOSH:**We are going to drop ship you a Ruby beer bong… [laughter] …for the second video. All right. But you have to drink Kool-Aid from it. [chuckles] And the actual date of the deadline for the contest, we will be announcing that in later shows. It really depends on when we get the first announcement out there—because not always, get the episode is out in the same week that we record them and we are sorry for that [chuckles].JAMES: What? What? JOSH: OK. Enough of my intro rambling. We want newbies come do a video for us and come in the show and be cool with us. DAVID: And the really cool thing about this contest is it has made us realize that we have to finish up the previous contest. So, we are getting in our votes right now on the Rogues Golf. CHUCK: Yeah. DAVID: Guys what do you think? Can we announce winners next week? JOSH: Yes. CHUCK: Yeah. I think we can. DAVID: OK. You heard it here first. We are all committing to have our votes in on our winners pick next week, on next week’s show. JAMES: It’s really not that much of a commitment because we usually lag about 3 or 4 weeks behind in releasing episodes. So, yeah. JOSH:[laughs] OK. By the way, the reason we do all these stuff at the beginning of the show is we learned reading in Twitter that nobody listens to the end of the show.JAMES: So you brought this on yourselves, OK? JOSH: If you would just listen to the ad, you wouldn’t have to listen to us. AVDI: And we only have 6 more intro items to get through. JAMES: Yeah. We are almost done. CHUCK:[laughs]**JOSH: Moving right along. DAVID:**So, getting down to the picks. [laughter]JOSH: OK. Do we have a topic today? JAMES: Oh yeah. Chuck, what are we discussing? I think you did this one. CHUCK: Yeah, it’s “What is a Good Starter Project?” JOSH: What does that mean? Can we have a definition? What a starter project? CHUCK:[laughs] That's your department. Not mine.**DAVID:**You take about 6 ounces of Ruby, stick it in a mayonnaise jar in the fridge and let it culture. [laughter]CHUCK: Oh man. JAMES: That's not right. So how about -- why don’t we go around the horn and do what our starter project in Ruby was? How about that? CHUCK: Yeah that’d be interesting. JOSH: So who started with Ruby first? We should go in terms of seniority. JAMES: I think Avdi is actually the old man. AVDI:[old man voice] Yes, back in my day…JAMES: I think you actually have me beat by like 6 months. AVDI: [laughs]DAVID:[old man voice] And Steampunk wasn’t retro, it was cutting edge. [laughter]**JOSH:**What are with drinking today? [chuckles]CHUCK: [laughs]**JAMES:**I'm not but I'm thinking of starting. [laughter]JOSH: For the people listening in, I just wanna explain that this is what happens when we don’t spend a half hour in the pre call getting it all out of our systems. JAMES: Yeah we spend a half hour with Chuck’s Wi-Fi instead. JOSH:[chuckles] Yeah.CHUCK: It was not my Wi-Fi.  Blame my client. DAVID: Yeah. JOSH: So Avdi, tell us about your Ruby starter project. AVDI:[old man voice] Well way back in 2001... Honestly, I don’t remember like the first program that I wrote you know, like play program that I wrote in Ruby. The first project that I did in Ruby, really the first program that I recall doing was a rewrite of a “PROM Image Preprocessor”, which back before hardware had flash memory on it, I was on a project that had some really--JAMES:[unintelligible]AVDI:[laughs] I was on a project that dealt with some decades old hardware. And the boards for it, you know, these things had like 6800 -- I think they actually had 68000s on them but really old. Anyway, really old hardware. It had PROMs on it which are you know, you would actually seek the – you’d have this chip that you would put in to a big old PROM burner and burn the program image in to it. And then you would seat the chip in to the board by putting it in, pressing it down really hard.  And that was how you reprogram the board and if you have a bug in the program, you had to pull the PROM chip, take it back to the PROM burner, you know, spend like half an hour burning a new image on to it and then reseat it on the board and hope you got it right this time.JOSH: So were these EEPROMs if you were re-burning them? AVDI: What's that? JOSH: If you were re-burning them? Were they-- AVDI: Yeah. Probably. Obviously it’s been ten years now. Or at least close to ten years for that project anyway. JOSH: Did you have one of those cool tools for pulling the chips out of the socket? AVDI: Yeah. I had a little grabber thing. And you know, of course the PROM burner was like also this ancient piece of hardware that you had to like put a floppy disk into and-- JOSH: It had one of those big nice switches next to it? AVDI:[laughs]JOSH: Like in the Frankenstein castle? AVDI: Yeah and it also had little bubbling vats and its pretty great. JOSH: But what was the project? AVDI: What? JOSH: But what was the project? AVDI: Oh. OK. So the thing was this hardware was so weird that it had to have this custom program to sort of pre-process the image before it went on to the PROM. And by “pre-process”, I mean it sort of have to rearrange things in the memory image. The memory had to be laid out just so -- so you took the output of the compiler, which normally you will be done at that point but now you have to take the output at the compiler and move stuff around in memory until it was just right. JOSH: Yay! World alignment. AVDI: Yeah. And you know, because it had to match the memory architecture of this board. And the thing is, we were working on replacement board and so, they kept changing the memory layout of the board. And there was this horrible C program that parts of it were just like old bits of assembly that nobody had the source for anymore. You just had to link then with the C program or actually able to compile-- So long story short, I decided instead of updating this old C program, that I would just rewrite the pre-processor in Ruby. And I had -- I actually had a YAML file, which declaratively laid out the different RAM sections or the different ROM sections. And you know, you basically – so the idea was that other people who didn’t know Ruby in the project could just go into this YAML file and change the way the memory was going to be laid out by switching stuff around in the YAML file. And it worked out really well because I was able to make changes to it very fast, which I wouldn’t have been this nasty old C program. So that was my first project. Not sure I would recommend that as a great starter project, but there you go. CHUCK: Wow. Every time you said “PROM”, I was thinking of the high school dance so-- JAMES:[laughs] Yeah, Avdi's first project was getting a date. Right yeah. [laughter]**DAVID:**So, I don't remember my first project but I remember getting in trouble for the first word I ever said after looking at Ruby. [laughter]**JOSH: Is blasphemy syntax compatible? DAVID:**It’s not actually blasphemy, but there was a little bit of profanity. I’d seen Ruby off and on and then somebody said, “You need to check out and see what's going on in Ruby.”  And RSpec was out. And so I typed “3.should” and it worked. And thinking back, it wasn’t RSpec. It was the fact that you can call the method on an integer. It was like “3.times” (RSpec wasn’t out yet). So I did like “3.times” and it ran a loop. And I'm in a room at a company in Provo -- all Mormon, a little bit uptight and I typed “3.times” and it works. And just out of nowhere, in the bull pen and very quiet, I said “Batshit!” and I got in trouble for that. All these poor little Mormon kids going, “What?”CHUCK:[laughs] nice.**JAMES: My first project in Ruby was the Ruby Quiz. That was the first thing I did. And I did it because I was by Mark Jason Dominus -- that was called “Perl’s Quiz of the Week”. And he did it a little differently than I did. He had a beginners quiz and an expert quiz each week and you can choose which one or do both or whatever. And I missed having that so much and being able to work in each week, that I made the Ruby Quiz to make my own. And I ran it for over three years I think or three years – right around three. And that was absolutely the easiest way to learn a ridiculous amount of language. In that, every single week I read every one solutions and I had to figure how they work so I could talk about them. And actually to this day, some of my favorite tricks in programming, I actually have associated with specific Ruby quizzes. And I'm like, “Oh, yeah that's the trick from the genealogy Ruby Quiz” or whatever. And that's how they are in my head. So people are sometimes surprised like how much depth I actually know of Ruby and stuff. It seems like I almost have the whole language memorized or something but-- DAVID: Yes it does. JAMES: It’s actually that—it’s that spent three years reading everybody’s code and of course everybody who submitted used every trick in the book. You know, so-- DAVID: Because they could. JAMES: Right. So I've really seen it all. You know. CHUCK: Nice. That's awesome. JOSH:**OK. I’ll jump in. So my first Ruby project of any significance more than just like fiddling around. I had friend who was an author and he had a book coming out that he wanted to build a website for. And he wanted to be able to like add press reviews and links to things on the web about it and also, things about where he was appearing for going on his book tour and doing signing events and things like that. And I was like, “Oh. Well I have been reading about this Ruby on Rails thing and I’ll just build you a website using that”. So I ended up building him a little mini CMS that was specifically just he can put up his website and then he could edit the press mentions and the appearances. And I actually even used Markdown and all that. It was terrible. [chuckles] Some of the worst code I have ever written.JAMES: Next week’s episode will be a dramatic reading of Josh’s code. CHUCK:[laughs]JOSH:[laughs] I'm pretty sure that code exist nowhere on the planet. So yeah it was a terrible Rails project. It was I think just before 1.0. So I learned a lot about how all bad things you can do in Ruby on Rails in that project.CHUCK: Right. JAMES: Awesome. DAVID: I'm loving the fact that we are four stories down and we just got to our first Rails project. JOSH:[chuckles] Well I'm one of those people who came to Ruby because of Rails. I'm not ashamed of that.CHUCK: Yeah. So David, was that your only story? Is that what you are going to share? DAVID: Well, yeah. OK so the first paying Ruby project that I did was Rails site. And kind of like Josh, I basically made every mistake in the book. And this was back when I was writing C++ and Ruby. James can attest to my skills there. And, it was Rails 1.1 project and I just turned over maintenance on that project about two months ago. So I mean, I shepherd at that thing through 1.2 and then 2.0, and then the Rails 3 upgrade. And yeah, old legacy code will haunt you to your dying day if you let it. That’s my story there. It was mystery shopping for airports. People would go in and pretend to buy something and then I would go out and basically tattle on the staff of the store and talk about customer service that they got. And so, it was basically like a quiz site on steroids; a lot of reporting, a lot of dependent nested models and that sort of things. In retrospect, it would have been a slam dunk for a NoSQL project, but boy, howdy, we did it in SQL because that's how you did things back then. CHUCK:[laughs] Awesome. You can go through the body scanner *and* use this free shopping on the same day.DAVID: That's right. That client had one customer denied him a badge to get through TSA. And so, literally one month in order to fulfil their contract, he had to drive to the neighbouring city and then fly into the airport that they were scoring, so that they could be inside the terminals and then they shopped everything and then they flew back. CHUCK: Wow. That's nuts. DAVID: Mh-hmm. CHUCK: My first Ruby project -- you guys are going to laugh -- the code name for my first project was “Frat Girl”. JAMES:[chuckles]**DAVID: Awesome. CHUCK:**And the reason is, is because my monitoring system on the company I was working for was called “Frat Boy” and it was kind of making fun of a CEO. But anyway, so I was working for the company in tech support and we had just been in the wall street journal, and so we have gotten a whole bunch of traffic -- people was signing up. And so we needed a system – we need an email support and up to that point, we have been using Thunderbird. But it turned out that we actually needed to have a system that would just speed up the email and let us reply you know, basically in line. So that's what we are doing is we are using the TMail Ruby interface to connect to the email server, pull all of the emails into MySQL, [unintelligible]. We were really just trying to save time. And eventually that grew into a whole support system with a knowledge base and all of these other stuff built into it and information on how to handle calls and stuff like that. And that's when I made the transition from tech support to Ruby programming, was with that job where I figured out that I --- in management and I really did love programing. But that was it. And that was in 2005.**JAMES: TMail. He just mentioned the TMail library. Remember that one? AVDI: Oh, yeah. JAMES: That was awesome. CHUCK: Yeah. We don’t miss that one. Do we? JAMES: That got replaced by Mail, which is now what Rails uses. CHUCK: Remember when the Mail gem came out, I couldn’t believe that there hadn’t already been a gem called “Mail”. JAMES:**Yeah, it was surprising. Tmail I heard was a good at spam detection. You fed it an email and if it crashed, it was probably spam. [laughter] So, it’s worth noting -- like maybe I don’t know about if Avdi will agree with this -- but for me, I was just playing around in Ruby because it was fun. And learning the language on the side and recreationally (so to speak) before Rails hit. And then Rails hit and all of a sudden they wanted all these people that knew this obscure language that nobody knew. So suddenly, it was valuable -- this bizarre edge knowledge I had. It was interesting.**AVDI:**So go learn the most obscure programming language you can find and I promise it will make you rich. [laughter]**JAMES:**Maybe you too will hit the language lottery. [laughter]**JOSH: OK. So, did we get everyone? JAMES: Yes. JOSH: So, in preparation for this episode today, I sent out a tweet yesterday asking people about their starter projects. And I asked two questions: “What was your first Ruby project?” and “What was the most educational Ruby project?” Or the best education for learning Ruby. And I got a ton of responses. It was actually super cool. There were couple of themes that came out of this. And one was, that a lot of people said that working on open source software was the most educational thing they could do. And specifically authoring their own open source software and putting it up as a gem or something like that, so that other people can look at your code and give you feedback. That was probably the number one thing that people said. James, you were looking at some of these tweets too. Chime in a few. JAMES: I wanted talk a little bit about what you just said on open source. Like, I don’t think I appreciated it till a little past my starter project times. Like, there was one point I remember with the open source project where I wanted to make change to it and I made a very detailed change. And I’ll totally confess, I did a bad job. And I did put way too much in there so it’s difficult to review on the other side and stuff like that. And-- DAVID: We’ll talk about this later. JAMES: Right. So they just rejected it of course -- which they should have. And that was a little demoralizing to me like in the beginning when I was working with open source. It was like, “I did all these work and they didn’t want it.” And that it was more an understanding problem on my end of not understanding why they didn’t want it. And that particular project was good about you know, it would have been great if they said, “Look, there's some good ideas in here but you really did a bad job of putting this together. Could you break it up?” So that would have been helpful. So open source can be good, but it can also be able to be a bit problematic in that, you have to conform to those rules, right? Which is kind of tough when you are getting started and you don’t really understand the rules. JOSH: OK. So if you already have experience doing open source software, it’s probably a heck of a lot easier to go that route. But if you are learning both Ruby and the open source world at the same time, that might be a double challenge. JAMES: Yeah or just ask somebody. A lot of projects are really good too, like if you go talk to them before you wanna do something. Like, “Hey, I'm thinking about doing this idea.” And they would usually say, “Yeah, we would love that” or “No, we wouldn’t like that,” and give the reason why. And then you can ask them, “So if I did this—“. A lot of the times if you engage them before hand, they are more willing to shepherd you through the process. DAVID: What was the magic acronym? We had somebody on a while back that talked about – was it PDI? Please Do Implement? JAMES: Please Do Investigate. Yeah. DAVID: Please Do Investigate. JAMES: That's from the Rails core team. They say that a lot, yeah. AVDI: The one thing that I see a lot is, when newbies go to participate in open source project, they usually bite off some like huge, huge change that they wanna make. And a lot of times, it may just be that they have no idea. As a newbie, you don’t know, you have a hard time estimating the size of something. And it can be very surprising just how big a given change do you think a good idea can be and sometimes it’s better to look  for like a tiny bug or something. JAMES:**Yeah, you know that's a mistake I keep making, like all away till today like, I always think, “Oh, yeah. I should do this complex thing.” Even in my speeches, I’ve learn this over time like when I am giving a presentation, almost like, “Oh, I got to show some significant example” or something like that. And I keep having to relearn this lesson but I found that if I do simpler example, then that leaves me time to show off, twist it around, you know make it deeper, show it from different angles. And those end up being the better ones. [chuckles] So yeah, always when I bite too big, it comes back to haunt me in those things.**AVDI:**In my pairing with novices, I usually ask, “What's a simple change to this program or what's the simple feature that you would like to implement?” And they pick like the simplest thing they can think of and then we get about 10% of that done. [laughter]JAMES: Exactly. Yeah. CHUCK: Well, in contributing to open source, I think we said in the past episode too that it’s much easier to accept smaller a patch than have to go and grock a larger patch so that you know that there’s nothing in there that’s going to blow things up. DAVID: That can be like counter instinctual too because, like, I was reading a project yesterday that had a method in it that was ‘d=array’ and then it had some collection.h d gets some conversion of that element. And then it returned the d collection. And I'm like, “That's the map. I can get rid of—I can reduce this whole—this 5-line method to one line of code”, which is returning a map. And I thought, “You know, it’s not really worth making a pool request to put this. It was a big hassle to five line code.” But do send those in because that is a tiny little defect. It is also something that the maintainer -- if they are actively maintaining the project -- it’s something they can look at and go, “Yeah that's cool.” And merge it and you are done. JAMES: So Josh, tell us some other cool stories you saw off Twitter. JOSH: OK bro. CHUCK: “bro”? AVDI:[laughs]**DAVID:**Yeah. Cool story bro. [laughter]**JOSH:**Somebody got it. [laughs] OK. So there were a couple of other things that emerged. A lot of people said ‘ToDo App’ was a good starter project and they learned a lot doing that.JAMES: I thought I saw  a couple of people that said blog as well. JOSH: That too. That was the next thing I was going to say. CHUCK: The ToDo App is the JavaScriptMVC. JOSH:[chuckles] These days, yes. But you know, I took the pragprog Rails Studio way back when. And they had a ToDo App as one of their early exercises in the app and I think that’s what we spent the first day doing. So, it’s not just for JavaScript. So, ToDo Apps and blogs. And someone has written his own blog engine, I got to say it’s a pretty good project.JAMES: Yeah. Actually I really liked that one. I think eventually, if you go and read Avdi’s current post he’ll tell you about why when you get so far, it’s kind of annoying because when you get to a certain level, you really just wanna sit down and write a blog post and not think about what’s underlying it. Which I think is true at a more expert level. But for a beginner project, building your own blog and then posting some stuff to it is awesome. JOSH: It’s really great. And I got to say, when I built my blog engine, I set myself up a constraint. And I think that – I’ll editorialize here for a bit – that starter projects, you want them to be constrained. You don’t wanna have infinite runway and you don’t wanna have infinite features. So what I did with my blog was I said, “I'm going to impose a maximum limit of 500 lines of code.” JAMES: That's awesome. DAVID: Mh-hmm. JOSH: And I threw out a bunch of features that I thought I wanted. And in fact, I have too many features; there's a couple feature I just never use -- that I wasted some lines of codes on them. That's I think a very effective technique is to set yourself a couple of limits on how far you can go in your project. DAVID: That's great. JOSH: Otherwise, it’s too easy to cheat and you do crappy things. JAMES: I've had someone do their own blog and I kind of walked him through it. And the limitation – the kind of artificial limitation I constrained on them was, basically a good object-oriented design. So, I forced them to say, you can’t have any code that wasn’t an object except for the Sinatra call inside the block and the only thing that can do is like instantiate an object that it handed down to the view or whatever. So basically, I used it to show people how you would make the objects and get them to talk to each other. AVDI: Speaking of constraints, I work with a lot of novices now in my pairing practice. And something that I have been noticing is that, for somebody that is specifically interested in learning more about Ruby and maybe about like OO design, a Rails project isn’t always the best place to start. JOSH: And that was next theme from the tweet. So a lot of people said that doing a command line tool. AVDI: Yes. JAMES: Yes. AVDI: Because I've spent a lot of pairing sessions where people have been surprised that you know, we spent a lot of the session doing kind of boiler platey things. I mean, we learned a lot because they learned all about different layers of Rails and different aspects of the request cycle. But there's a lot of just sort of getting the scaffolds in place, getting the views up and running. There are a lot of bits and pieces. And a lot of times, if you are particularly interested in learning the language and how to think about a problem, doing some kind of command line app can really focus you. And it can get rid of a whole lot of kind of extraneous stuff which is not really – it’s important, but it’s not really part of that core learning. JAMES: Yeah. I think that’s really important. Like there seems to be two groups of people; some that come up through Ruby and then get to Rails. And then there's the others that come in through Rails and hopefully eventually go down and really learn Ruby. And even when like Josh says something like he came to Ruby through Rails, he doesn’t mean the same thing that most people mean when they say that. For example, Josh came with, you know, a mountain of Smalltalk experience so he already knew how to program in a very detailed, object-oriented way and wasn’t missing those pieces. Eventually he learned how all that applies to Ruby. But believe it or not, the coming up through the language is far easier. I think people don’t think that, but it actually is. I learned Rails long after I learned Ruby. And I used to joke that I was the worst Rails programmer on the planet, which is pretty much true because I knew so little of Rails, but it didn't matter because I understood Ruby and I can make Ruby do anything I want. So people would laugh at me because I’d write this little chunk of code and they will be like, “You know there's a helper for that.” AVDI:[laughs] For a noob--DAVID: --- the compiler. I'm good to go. AVDI: For a noob, I mean there are things that we don’t think about anymore probably as like regular Rails programmers. Like a command line program, it has a single entry point. You can look at the file and know that the Ruby interpreter is going to start at the top of this file and go down. DAVID: Yeah. AVDI: But when you are working on a Rails project, you have to understand routing before you even understand the entry points. And it’s not a single entry point; it depends on the route it comes in on. JOSH: So you don’t put signal handling in your command line script? AVDI:[laughs] Well that's kind of intermediate level stuff.JOSH:[laughs] OK. Just pulling your leg.AVDI:[laughs]JOSH: I think the command line stuff is pretty interesting. And it can get really complicated if you wanna go that way. JAMES:[laughs] Josh has been interrupted.**AVDI: I'm just testing your interrupt---. That's all. JAMES: He’ll be back next week. JOSH:**I didn’t have a specific handler, so I just crashed. [laughter]**DAVID:**I was just going to hop in and get him to reload his configuration files. [laughter]**JAMES: You know, that command line thing too, it has more legs than you think. JOSH:**Look at Rake. Jim Weirich built a whole career around that. [laughter]**JAMES: Exactly right? And we are at OKRB last week -- our local Ruby group. And one of the Heroku guys came in and showed us what they have been working on. And basically, they are trying to work on some better monitoring structure and what they found is also monitoring tools out there they don’t really like how those are working. And what they have done is they’ve started rebuilding monitoring the way they want it and what they are doing is they are building a bunch of very Unixy command line apps. That just basically do one very simple thing, very tiny thing and they can be combined with other tools. So the example that the guy showed was like a check HTTP command and just hit it and gave you if it was up, how long did it take to respond, stuff like that. He wrote all its output on one line, but was very careful to do it in key value pairs. So like in ‘name=some value’, so it was super trivial to parse out. And then he started talking about how they were combining all these like then eventually, these lines were being sent to like a sys log server and stuff like that. And people were doing searching through them for a particular data they were interested in. So I'm just saying that here's Heroku, a company that's very far down the life cycle of building this platform and here they are, trying to build simple command line apps because it’s a very powerful thing to do. It’s one of those things that -- and I’ll talk about this in my picks a little bit today too -- but the more I learn the shell and the command line and stuff, it still pays me back massive dividence to this day. CHUCK: Well it’s a lot similar when we are talking about SOA, service-oriented architecture and service oriented design. You know, you have some worker that you delegate work to or some system. And it’s the same kind of thing where it’s not necessarily a web interface; it’s not necessarily this Rails or Sinatra app. And sometimes it’s just the simple script that it has that single entry point that Josh was talking about where, it just pull something off of the queue, goes and retrieves the next job and then it just does this little job and then moves on. JOSH:**By the way that was Avdi [chuckles] who said that. OK. So I think in terms of starter projects and how to get people going, one of the things I always tell people when they were like, “What should I be learning with?” I always say, work on a project or on a problem that you are really interested in solving.**DAVID: Yeah. JAMES: Absolutely. Yeah. CHUCK: I worked in a company for coaching and then they are like, “So what are we going to work on?” and that's what I always tell them too. I always tell them, “You got to pick a project that you are interested in being a part of.” JOSH:**Yeah. I remember when I was learning about relational databases, I built a dumb little tool to keep track of my DVD collection. And I used it for about two weeks and then realized I can buy a better one [laughs]. But it was great. It got me really engaged and I cared about solving the problem. And so the thing that is really amazing about Ruby there is I mean, how many gems are out there now? There is a gazillion gems out there. There's amazing number of cool pieces to the standard library and the software ecosystem that gives you all of the super powers to solve problem in interesting ways. And like ERB (embedded Ruby), does templating. So there is a lot of problems that you can solve by putting in little snippets of Ruby into your HTML file or not even HTML, you can do templating for any number of – you know you can build form letters for sending out your holiday card list or something like that. So what are some other good like – so I think of these things, sometimes they really good for doing production code, but a lot of them are kind of science experiment kind of things. I look in DRb and things like that, which are fun tools for doing distributed systems, but I would never really use them in a production system because they just can’t handle large scale.**DAVID: That is sad and funny for a thing that is built to be distributed. JOSH:**Oh shut up. [laughter]DAVID: No. You know, because I agree with you right? The whole point of DRb is distribute the load and the problem  with it is it doesn’t scale for crap. JOSH:  That's the problem with distributed computing. [laughter]**DAVID:**That's the problem with scalability. It doesn’t scale. [laughter]**JOSH: It’s a really hard problem. Nobody has ever built a really good general-purpose distributed computing platform. Everything is always specialized towards one thing or another. That's why we have MapReduce or what have you. JAMES: And just to be clear, Josh is not recommending this as a starter project. JOSH:**Well, no. Actually if there is somebody who -- oh, you mean the general purpose thing? No, not at all [chuckles]. But I am recommending playing around with DRb as a starter project.JAMES: Oh absolutely. That's a blast. JOSH: Yeah. DAVID: ---- that's using DRb and that gets to be a nightmare fast. JAMES: I found it to be kind of fun. I played around a lot with MUD’s. I was really interested in MUD’s and used to play on them a lot. JOSH: Oh yeah. JAMES: I built MUD clients and MUD servers and stuff like that. And so I actually have a very deep knowledge of networking, that I almost never use anymore because I don’t really do anything in that area. But I actually know how to write like non-blocking evented servers and stuff like that because I had to figure all that out in order to write a MUD. JOSH: Can you explain ‘MUD’ to people? JAMES: Oh yeah. Multi-user--- CHUCK: Dirt and water. JAMES:[chuckles] Dirt and water, right. MUD is Multi-user Dungeon I think it’s what it stands for. It’s an old time text adventure game, where you connect to some server. And usually, they have a very D&D-ish feel theme and you choose maybe a race in a class, you have certain amount of hit points and you go around and fight monsters and explore the world and gets stuff and items, equipment -- that kind of thing. It’s like a chat server with combat almost. Am I right? [laughter]**JOSH: In other words, Campfire? JAMES:**Yeah. Right. [laughs]CHUCK: Kind of like an IRC channel? JAMES: Yeah it’s kind of like an IRC channel, sort of. Yeah. They are a lot of fun to play around with and they are pretty neat in that, from a computer point of view, they have a lot of very fun problems. Like the networking is the killer part -- the hard part to get past. But if you use something like event machine, you can simplify that a lot. But the fun part, modelling the world so you have these areas that connect to each other. So when you type ‘north’, so you go to whatever is north; and just modelling out that much can be fun. If you want the non-networked version like interactive fiction, which is very similar games like Zork and stuff like that that you play which is a command line interface, walking around, looking at that items, using this item on that item and modelling that kind of program can actually teach you quite a bit about -- especially it’s a good object-oriented project because you will have the different objects and stuff that represents the elements in the game. You can learn a lot that way. What I was going to say that was good for me is your starter project, I agree with what the other say, don’t take something too big. But do take something that overlaps your skill area and goes a little beyond it. Like it’s great if it’s mostly right in your skill area, except for that one part that's going to go a little bit outside your skill area, that to me is the ideal starter project. Because you want something that you can get into, you can work on, but it’s also going to  raise you up a little bit and you are going to have to interact with others to get past that part, or get some help or read or all those things that programmers do as a daily part of the routine. DAVID: And we already said this but I want to reiterate – centered right in the middle of your interest area -- because that's the thing that you go to bed at night and just wonder, “OK. How am I going to make this work? I just need that one more thing but I got to find it, I got to find it.” CHUCK: I think that is a good rule of thumb for any project you work on -- both on what you said. Kind of push you a little beyond what you where you currently at and something that you are interested or passionate about. JAMES: Yeah. That's a good point. And in a way, starter project are almost the silly thing in programming in that, like when I started a new project and it usually does have some component I'm not familiar with, so to me that's still a starter project. I'm still learning, still figuring it out. JOSH: So, I got to say, one of the replies I got on Twitter from somebody about what's their first Ruby project was, Sebastian Delmont said it was the application for streeteasy.com. JAMES: Wow. JOSH:[laughs] So how many years since he’s been running that business? It’s like he started that like in 2006 or 2007 or something. I don’t know, 2005? And it’s still his business.**DAVID: Is he that good or did he just get lucky? Or both? JAMES: I would imagine that he evolved it over time. And there's probably some things he did well, some things he didn’t so as well and hopefully, he is upgraded parts of it and things like that. That's a good question though. DAVID:**I was just thinking, we should have him and maybe a couple of people down the road that have presided over the evolution of large projects and just say, “Hey, walk us through start of the early days.” You know when we talked with the Square guys, and we talked about how they started out and now they got the whole office is a tanning booth because they are monitoring everything. [laughter]**JOSH: Right. Yeah that is a good idea for future episode. We have the newbie episode and we can have the old fart episode. DAVID:**Yeah exactly. Go crusties! The neckbeard episode! [laughter][old man voice] Back in my day, symbols weren’t sortable. [laughter]**JOSH:**They still aren’t. But no. [laughs]**DAVID: Yeah they are. In 1.9 they are sortable. JAMES: Yeah they you can sort them now. AVDI: They do all kinds of crazy things in 1.9. I don’t know. JAMES: Yeah. You can run like regexs on them. AVDI: Capitalize. I don’t know. JOSH: You know, for putting on my Smalltalk old timer hat,  that's not terrible for me. JAMES: That's awesome. JOSH: Symbols where sub classes of strings in Smalltalk. JAMES: Oh, interesting. DAVID: So speaking of interesting and fun and weird little challenges, I was playing with gaming stuff and I discovered last night that Ruby sort -- array sort is woefully underpowered. It takes a block and you can do anything with it, but there is no convenient shorthand. I had this array, I built this population of a thousand monsters and they had strength, dexterity and constitution. And I wanted to find the ---. I wanted to find very high strength, low dexterity. And sorting on two fields, you have to write spaceship operator twice. JAMES: No you don’t. No you don’t. You call, ‘sort by’ which does-- DAVID: ‘Sort by’! Okay. JAMES: ‘Sort by’ does a Schwartzian Transform right? So it does a map to some set of criteria and then sorts and then maps back to the original content, right? And it has-- DAVID: Can you get criteria? Can you sort it by negative dexterity? JAMES: Yes. And ‘sort by’ just does some transform, when you are dealing with multiple criteria, use an array because an array implements the spaceship operator. And it will do the spaceship operator on its contents. So you do an array of your two criteria in sort by it will map in to that, do the sort and then map it back to the objects you had instead of the arrays. JOSH: And that's great unless you are sorting a really big collection, in which case allocating another array for every object in there can be a bit of a hassle. DAVID: Yeah that is the trade-off of the Schwartzian Transform. Can we get a definition on that? So we know what short Schwartzian Transform is? JAMES: It comes from Perl because I think it was Randal Schwartz. DAVID: Randall Schwartz invented it. Yeah. JAMES: Who made it big and basically, if you think in Ruby code, it’s almost equivalent to .map, where you map into to something else. Then .sort, you sort on you mapped it to; and then the last step is the .map back to the original thing. So, if you had to do it manually, you would map it to an array where the first thing is the thing you wanna sort on and the second thing is the original object. And then the second map would just be a map to the last element to the array, so you put it back to the original object. DAVID: So an example that Randal used is he had a bunch of people that he wanted to sort by last name first name and so he built up this string that was like 50 characters long. And he put the last name in first up to the first like, 25 characters and then padded out 25 characters he put in the first name. So that no matter how long the last name was, as long as they are within 25 characters, you will end up with a single string that represented your index in the sort. And now you can sort these elements out very, very quickly. JOSH: Yeah that's pretty standard and all. It was clever for him. DAVID:**Well, it was clever for him because he did it like in 1988. So yeah. [laughs]**JOSH: People have been doing that kind of thing for a lot longer than that, but it’s cool that-- DAVID:**Oh we got to have Schwartz on the show now. You’re going to throw down with him. [laughs]**JOSH:**Yeah. [laughs] OK. So, getting back to what we were talking about.**DAVID:**So the whole point of that discussion is a good starter project is if you don’t know how to do something in Ruby, go on Ruby Rogues and tell James it can’t be done. [laughter] I didn’t intend to go there, but here we are.JOSH: Well, that's how you've asked questions on the Internet. JAMES: Right. DAVID: Yeah. JOSH: Your asking a question never gets you an answer, but declaring something cannot be done-- DAVID:It will be stupid! It can’t even do X! [laughter]**JOSH: Yeah, people -- we’ll bring you on the Ruby Rogues and tell you how it’s done. JAMES: I have a search filter for that tweet, you know. DAVID: I first learned that from like unofficial fact to the gen2 channel on IRC, was if you wanna get help on gen2, you go on and say, “Gen2 sucks! It can’t even drive an Epson 218 printer!” And you will get 15 replies within 30 seconds. JOSH: Yeah. That was what people told me when I started using that back in the 80s. DAVID: Uh-huh. AVDI: Unfortunately, 14 of the replies would be, “Only stupid people would use that printer.” JAMES:**That's right. [laughter]JAMES: Sometimes I feel that way about the Emacs IRC channel. Geez. DAVID: Actually, we did still get that sometimes in the Ruby community. And this goes back to like open source contributions, you'll say, “I wanna be able to do this.” And the first response you'll get back is, “Don’t want that. Stop wanting that.” AVDI: Yeah. JAMES: Yeah, “Don't do that.” “It hurts when I do this.” “Don’t do this.” AVDI: Yeah don’t do that. CHUCK: We need to get in to the picks pretty soon here. Are there any aspects of this that we haven’t talked about? JOSH:[sighs] What's a good starter project? OK. So, we've talked about constraints of it, but I think you have to be – you know, Dave and I both talked about you wanna work on something that interests you -- something that you would care about. But I think you also have to be willing to kill your darlings. Yeah, that you don’t wanna be too -- even though you are sort of emotionally invested in it, because you are learning something and you are working on something you care about etc. its hold on loosely to this thing. You don’t wanna be too emotionally invested in having your little starter project grow up in to being the foundation of your company for ten years.**DAVID: Yeah. Be willing to walk away. JOSH: Yeah. AVDI: Yeah. DAVID: I’ve been playing with Darts generator for ten years -- well, 20 years. I mean since I've been to programing. And one of the first things I did in Ruby was write a dice class and a dice bag that you can roll. Give me 3d6 +  2d4 + 1d10 * 8. And it could roll all those dice. And I mentioned that because I revisited—I started writing a new dice class last night and it’s just fun. But the reason you come back to it is because you are willing to just kill it and walk away and realize, “This is not in my career”. JAMES: It’s fun too because you can put d method on an integer. Right? DAVID: That's exactly what I did! It’s a little bit ugly, but yeah ‘3.d6’ the other problem is that the side that d6 is now embedded in the method. So, guess what's coming; method missing baby. CHUCK: Awesome. Well, let’s get to the picks. Let’s make David go first. DAVID:**OK. I'm actually pretty quick today. Jim Weirich has written an extension to RSpec called ‘RSpec-given’. And I've been playing around with it and I really like it. It lays *almost* perfectly on top of RSpec 2. You can basically say ‘given’ and that's like a ‘let this equal this’ and then you say, ‘when’ and then some block that something happens. And then you say, ‘then’ and then you have some blocks where you put your assertion. And in each describe or context, you can only have one ‘when’ block, but you can have an arbitrary number givens and they are lazily evaluated. You can have an arbitrary number of ‘thens’. Each ‘then’ will trigger a new run throughout the ‘when’ and the thing. And it can really make for some readable RSpec. I think RSpec is pretty readable to begin with. And actually on project that Chuck and I are working on together now, we really did trade places. He is at Chattanooga in the same room that I was in three weeks ago. But for the project that we are working on, we switched to RSpec-given for about a week and then we ended up switching back (sorry Jim) mostly because we found that we were writing given, given, give, then, then, then, then. We didn’t have any ‘when’ blocks. And so we just realized, “Wait a minute, let’s just use ‘let’ and ‘it’ and then just be done with it.” The nice thing about RSpec-given -- and I say ‘nice’ -- this is a change that will make some of your eyeballs itch, is that you lose the ability to say ‘it’ and then ‘string’. ‘It’ should do this or ‘it’ does this or do and then some block. You say then you say ‘then’ and it’s just like writing it do and then your block. And it forces you to write code that tells the reader what it’s doing, not just how it’s done. I actually confronted Jim about this on Twitter and he said, “No, that was by design”. He considers that the text in ‘it block’ to be a code smell, just like the code smell as a comment as the code smell. And I thought that was just really, really fascinating. So I played with it. Now, RSpec-given does have one thing that will just absolutely hamstring you and that is that, we have this very temporarily fixed. You have ‘givens’ that happen before the ‘when’. And then you have the ‘when’ and then all your ‘thens’ happen after the ‘when’, which means that it’s impossible to put in a mock before like should receive and expectation. You can’t put that in a ‘then’, it has to happen before the ‘when’, which means that you need to use spies more than you use mocks. So that you can basically say, given, I got the spy set up on this method then when I do this thing, then my spy should have executed. And I pushed back on Jim about this and so he went out and he updated his flexmock library, which now supports spies. And so now you can build out your stuff with less mocking and stubbing and a little more spying. And they work really, really nicely together. If you find yourself not using the ‘when’ a lot, you probably wanna roll back to just pure RSpec 2. But if you do have something that is very staple that needs these mocks and spies  where you can basically say, you know, ‘given this’ ‘when this’ ‘then this’. It’s a very elegant library and I really like it.**JOSH:**Hey David, here is a pro tip: next time you have a pick that’s that extensive, write a blog post about it and then pick your blog post. [laughter]**DAVID:**I’ll skip my second pick. [laughter]**CHUCK: Nah, go ahead. JAMES: That technique is really good. I heard someone recently say, “When somebody ask you an interesting question in an email, write a blog post and then send them the link.” DAVID: That's a really good idea. JAMES: Yeah. DAVID:**Actually before the episode today, I thought about writing down my pick and reading it, so that it wouldn’t go 20 minutes long. And I like your version better; write it down and then don’t read it! [laughter]**JOSH: Just link to it. DAVID: Yeah. No, that's actually really good because I wanna explore some of the new ones RSpec-given. I think it’s a fantastic library and I think people should play with it. And I'm going to stop talking about it because we need other people to finish their picks. CHUCK: Yup. So you are done with your picks then? DAVID: I'm done. I’ve got another pick but I'm going to save it for next week. CHUCK: OK. Avdi, what are your picks? AVDI:**All right. Well I have been doing some research for the stuff that I have been putting into the Confident Ruby book. And as readers of my blog know I'm a big fan of the ‘Null Object Pattern’ that I decided to hit the books and get a little more background on it before I wrote about it in the book. And so I've been reading some papers and they’ve been really enjoyable read, so I thought I’d share those. The first one I guess is the original Null Object Pattern paper by Bobby Woolf. And you know, it lays down a pattern and it explains why you might wanna use it. And then there's a newer article ‘Null Object – Something for Nothing’ by Kevlin Henney. That's from 2003. And both of those also led me to a paper from 1995 by Ward Cunningham called ‘The CHECKS Pattern Language of Information Integrity’ and it details an interesting approach to dealing with user input that may include invalid input. And that's in the Pattern Languages of Program Design book, but I think it’s also available on Ward’s website. So, just some interesting old reads and the fun thing about reading these old pattern papers is that, the farther back you go, the more modern they are. Because the more recent ones, all the code samples are like cluttered up with like Java or C# or heavens forbid C++, but when you go back to the earlier patterns papers from the 90s, they do their examples in Smalltalk. And then they are really, really easy to translate to Ruby. [chuckles] So it’s kind of a weird timing version principle there. Anyway, those are my picks.**JOSH: We’ll call that “the dark ages” AVDI:**Yeah. [laughter]**JOSH: The period between Smalltalk and Ruby. CHUCK: Right. Josh what are your picks? JOSH:**OK. I've been working through this list of picks for a couple of weeks now and I'm now down to a couple of non-programming picks. So my first pick today is ‘fridayhug.com’. We hadn’t actually picked this yet, which is awesome. So some people who are perhaps new to Ruby may not be aware of this. So fridayhug.com is a website of Aaron Patterson hugging the Internet and then a whole bunch of other people joining him. [chuckles] And this was built as a RailsRumble project, so tenderlove would post a photo hugging the Internet every Friday. And somebody wrote a website to capture those things that get posted off of Twitter and put them on the website, so we can keep them around for all time.**JAMES: I mine that site for pictures for my Rails Conf talk. JOSH:**Oh, nice! [chuckles] That's great. So that's worth checking out. And come Friday you can give the world a hug -- online. And then my other pick is also non-programming but its programming relevant because many of us build websites and this is relevant to that. It’s called  ‘TOS;DR’ or ‘Terms of Service; Didn’t Read’.DAVID:[laughs]JOSH: Yeah, yeah this is kind of cool. ‘tos-dr.info’ and the point of this is that they translate the point of service for various websites into understandable English and they bullet point it and then they classify everything. So they give websites a great -- and this is project is in its infancy. It’s just getting started.  Reading their timeline, it looks like September is the month they are going to try and get funding to grow it out into a sustainable project. So keep your eye on it and go check out the site. I'm sure we’ll have an announcement about that as that kicks in. But it’s pretty cool where you can look at a site like GitHub which got a B grade. And it’s great because they do things, they break it down like, “Oh, hey. You don’t have to give any copyright away.” but also things like they can suspend your account and delete your data for any reason. So they don’t have enough good user protection to be a class A TOS. So, it’s pretty cool. There's a lot of stuff up there that needs to be filled in. And it’s an open project. I'm hoping that it takes off and it gets a lot of attention and eventually becomes a big player on the Internet and then what do they say? Like, ‘sunshine is the best disinfectant’. JAMES:[chuckles] Nice.**CHUCK: Never heard that before. I like it. JOSH: They usually say that about politics, but I think it works well for Terms of Services too. OK. That's it for me this week. CHUCK: All right James, what are your picks? JAMES: OK. I've got a couple about we talked today about how scripting the command line can definitely be a cool way to get starter with things. I saw this cool video this week about running Shell scripts inside Alfred. And Alfred is one of those awesome things -- I know we’ve picked it in the past -- that pretty much every Mac user I think needs it or something like it. And what is cool for me is it’s kind of grown up over time. It got more and more awesome features. So sometimes I learn about things I didn't know because they were added later and I haven’t thought to look about them. But anyways in this video, the is guy showing how he triggers a shell script through Alfred that creates his project directory the way he likes it and stuff like that. It’s a Backbone project that he is setting it up for, but that won’t matter even if it’s that's not interesting to you, it’s what he is doing that is very interesting -- running a shell script through Alfred silently so you don’t see the terminal pop up and sending it parameters when he types in the command and stuff. It’s pretty neat stuff. So check that out if you are an Alfred user. DAVID: You are not going to stop being shiny about Alfred until I quit using Quicksilver are you? JAMES: Yeah there is like one person left that's still using Quicksilver. DAVID: It’s me! JAMES: Anyways, Alfred -- It’s amazing. And the other thing I learned about, I've been reading the Tmux book, which I know I picked in the past and it’s awesome. But it mentions some command line utility that I was somehow unaware of. I had no idea how, but there's a SCRIPT command which I feel like a total idiot because I just spent all weekend running a bunch of shell commands and then copy and pasting them somewhere to get the content into something I needed to produce. And it turns out there is a shell command where you can just say ‘script’ and give it a file name and now everything you are doing is being written to that file. And then you just have it in the file. So it’s great if you need to report a shell session. And it actually keeps like the escapes and stuff in there. So, the color coding and stuff like that will actually be in there. You can strip them out if you want, but they will be in there. So if you open it up afterward, it may not be quite a normal textfile. A good way around that is just open it in so ‘<-R’ so, ‘less but raw’ will how you the binary so basically it will put the syntax going back the way it was and stuff. So anyway, that's another cool trick. Those are two programming ones. And then for a non-programming one, I got to confess that I actually saw the movie ‘Hunger Games’ recently and I was quite skeptical and you know, things like Twilight have made me pretty gun-shy but it turns out that The Hunger Games actually has a pretty cool story and I found the movie very enjoyable. It was pretty good stuff. I don’t think it’s out on Netflix streaming yet, but you can get it on DVD. And it was pretty good stuff, so I’d recommend it. CHUCK: Awesome. All right. So I guess I'm last. My first pick is RadioShack. And I just have to point out I had to run down there because our washer—one of the buttons on the washer basically failed and was shorting out. So was shorting the connection across like the button was being held in and at first it would beep like somebody kept pressing it and then eventually, it just shorted. And then if you push any button, then it would change the temperature on the washer. And the start button is one of those buttons that was kind of affected by that. You couldn’t actually start and run the washer, so I ran down to RadioShack and I picked up a new soldering iron because I couldn’t find mine and a little switch. And it cost me probably $20 to fix my washer as opposed to having some repairman come out and do it. JOSH: Chuck, you do realize that in the near future, you are going to be picking a 3D printer that allowed you to print a repair part for a replacement part for your washing machine? CHUCK:**Oh, dude don’t tempt me. [laughs]JOSH: No. Hey 5-10 years, that is future. People aren’t go to the store and buy replacement parts anymore. They’ll just print them. CHUCK: Yeah, that's true. Of course we had a thunderstorm that we lost power to our house and when it surged back on, it friend something in our TV. So, yeah I'm getting to solder again when I get home. JOSH:[laughs] nice.**DAVID: Actually I love the future because you used to tell people don’t ever open a TV, but they are all LEDs now so, we don’t have that 30,000 Volt capacitor in there anymore. CHUCK: Yeah. Well the other thing is that, in a lot of TV, you pretty much can get away with ordering the right circuit board and get away with doing things or you can pull it out if you see a capacitor that got fried, then you just deal with it that way. So, yeah, kind of cool. But anyway, so yeah I just ran down to RadioShack and I they had the right parts for me. So I thought that was pretty awesome. Now the machine is soldered so the contacts were teeny tiny but you know, a little bit of persistence you can make ---. My other pick is the ‘LG Tone’ it’s a Bluetooth headset and it has a microphone on it. That's actually what I'm talking on right now. It’s not the highest quality for recording, but it was nice because last night I was listening on an audiobook on my iPad and I'm pretty used to having just the wired ear bud and so, you know, I just left the iPad on the bed when I went and brushed my teeth and you know, did what I needed to do to get ready for bed. And I didn’t have to be tethered to my iPad. So, that's my other pick. It’s the LG Tone and I’ll put a link to the one that I got. I actually picked it up at Best Buy, but that was only because I realized I wanted it and I would probably need it today, yesterday and so I couldn’t get it shipped with Amazon Prime directly to me. Anyway those are my picks. Is there anything we want to go over or reiterate before we wrap up the show? DAVID: Just use your powers for good -- or for awesome. CHUCK: Yup. JOSH: Sign up on Ruby Parley. DAVID: Yes. JAMES:**They’ve already quit listening, people! [laughter]**DAVID: Yeah, why do we bother recording this section of the show? There's like 5 people listening and it’s us. CHUCK: All right well, thanks for listening, we’ll catch you all next week! JAMES: Bye! DAVID: See ya! AVDI:** Bye!