The Rogues talk about templating languages for HTML, CSS, and JavaScript.

 
CHUCK:

Hey everybody and welcome back to another Ruby Rogues. This week’s panel, we have James Edward Gray from Northern Oklahoma. We have Peter Cooper from Great Britain. I forget where exactly. And we have special guest Wynn Netherland from Texas. I’ll introduce them real quick; James is a long time member of the Ruby community. He’s contributed a lot of things. I think the two things that he is best known for are Ruby Quiz, FasterCSV. He’s also written a few books like the one on Textmate. Peter runs Ruby Inside, Rails Inside, Coder.io, Ruby Flow and probably a few other things that I'm missing the newsletters -- Ruby Weekly. And Wynn is new to the show. He is one of the host of the Changelog podcast. He’s also writing a book on SASS, and so we are excited to have his input on the topic at hand today. Today, we are going to be talking about templating languages. Things like ERB, HAML, and Mustache. We are probably going to dig in to SASS and SCSS. We might even get into CoffeeScript, who knows. So I´ll go ahead and stop the music and we'll jump in. How’s it going everybody?

Awesome.

Going well.

All right. Good to hear. Let’s go around real quick and see what you guys are using as far as templating languages. I'm interested in not just HTML, but let’s hear about CSS and if you are using anything like CoffeeScript for your JavaScript or anything. We'll go ahead and start with James.

Okay, so I used ERB for my HTML for two reasons; one that when I first got into Ruby, I got in by documenting standard libraries and one of the very first libraries I've ever documented was ERB. So I know it very, very well and use it pretty much all the time, just because I'm very used to it. So, I typically use ERB. I’ve played around with some things like Mustache and stuff. And I can see some advantages to them, but also some things I don’t like about them as well. And the second reason that I mainly use ERB all the time is I freakin hate HAML.

So, those are my two reasons. Then, as far as like CSS and stuff, I'm not generally the guy that writes the CSS for a project, so I'm probably not the right person to ask on that. When I do write, I usually just edit CSS. I've definitely looked at SASS a little bit and I think it’s great actually because of avoiding the repetitive nature of CSS and just introducing some nesting and variables. I think that’s very worth it. I haven’t really played with CoffeeScript. I get by okay with JavaScript, so I

guess I haven’t really felt the need for it. But I haven’t played with it, so I can't say too much about it.

All right. Sounds good. So you’re too smart for the front end stuff and use ERB for your HTML.

I use ERB for HTML and I think I'm too dumb for the front end stuff.

[Chuckles] What do you think Wynn? Is he too smart or too dumb?

I think he’s too smart, for sure. I only used HAML for my HTML stuff just because I like dealing with CSS selectors and found that… I think Geoffrey Grosenbach said something that I think a lot of us had been thinking for a while. HTML and SASS, allow you to kind of remove the distance between content and the styling, so that your markup in HAML, closely resembles your CSS and SASS usually syntax indents its syntax for SASS as well. And I picked up CoffeeScript lately; using that in a lot of Titanium projects, specially. Haven’t done it for much web stuff yet, just because debugging JavaScript still has a little bit of overhead in that development process, but in the mobile area in Titanium specially, I think CoffeeScript has been a huge productivity boost. I'm using Mustache as well; mostly in web stuff with Ruby projects when I need to turn templating over to end users because it’s a nice safe way to do that, plus it resembles the tumbler syntax that people are familiar with.

All right. Peter, go ahead. What are you using?

In the real world, I'm pretty freaking dumb if we are comparing to James, because I'm kind of like often all over the front end stuff, because I'm kind of really just ‘nail that and get it right,’ kind of guys, I guess. But I'm pretty much using ERB for everything as of now. This is stuff I´ll get to later, but some of the research for this podcast is actually making me actually wanna try some of these other things a bit more than perhaps I have in the past, where I’ve kind of written them off. So that might be a bit contentious. But yeah, I am also using SASS, which I've pretty much… we'll, actually, I say SASS, but like the SCSS version, the other version looks more like CSS rather than the HAML style one. I've been using that a really long time. And I really love that just because I'm love working with CSS. I'm one of those people that if anyone has sort of a problem with CSS, they often sort of ask me, I´ll say whatever like I´ll have these sort of weird bug or whatever. I don’t know, there's a lot about CSS that I really like. It’s like people tinker with all cars or whatever and kind of know the little things and I just kind of like really love playing that. But I just love the way that SCSS just kind of allows me to kind of just do the stuff that I was doing before, but then just kind of clean up some more parts of it. It’s not a radical change and the formatting it’s just adding a few extra things in. So I'm using that. Not using Compass or if you like that I just found that I tried it and I just found it to be a bit complicated. I like the full control of the CSS. Other than that, I'm not using CoffeeScript yet. I've been playing with it kind of a separate thing, but not using it in actually in any apps. I guess the only other thing I'm only using would be Markdown on top of all of the above, sometimes for doing blog post and things like that. I've played with Textile as well. I wasn’t too keen on it. Markdown seems to work for me. So yeah, pretty basic so far. Although I do have opinions on the other things because have to research them, nonetheless.

All right.

Just five thousand on Markdown. Yay, Markdown! [Chuckles]

That sounds super. What I actually use on my stack is I've been using HAML. I actually started using HAML like a month ago. And I just tried it out and I was like, “I'm never going back.” And then I switched over to using SASS. I tried out Compass and it was the same thing. It was just, “Oh, this is so nice.” I can hook my… what is it, where you have the columns. [Chuckles] The grid system. “I can hook my grid system into it, then I don’t even have to think about it.”

Which grid system are you using?

I’ve been using the 960 grid system. I'm thinking about switching over to blueprint.

[Whispers] Oh, blasphemy!

[Chuckles] But I was introduced to the 960 grid system when I was working for a lead gen company a couple of years ago, and I’ve just kind of been using it because that’s what I'm used to. And honestly, the only reason that I would switch is so that I don’t have to go through the… it’s a minor headache now because I know what I'm doing, but I don’t have to go through the minor headache of setting it up every time I start a new project. But I have been playing with CoffeeScript and I haven’t actually used it on any of my existing projects. I´ll probably use it on the next one that I start, but I've played with it in Rails 3.1 and Rails 3.1 kind of makes it dumb simple to use, and it’s totally worth it -- in my opinion. With Compass, I actually SASS; I don’t use SCSS. So that might be something to discuss but anyway, so yeah, I'm in love with my HAML.

Since I'm horribly outnumbered here, I'm going to treat this as an episode or Ruby survivor, where my goal is to get voted off the island. And I just wanted you guys to know I just did a Google fight between ERB and HAML, it’s like about 720,000 results for ‘ERB’; well under 40,000 for ‘HAML’. So I just got to throw that out there.

Yeah, but there's like a million for ‘Britney Spears’ and there's only about 500,000 for you, so who’s winning now? [Chuckles]

Awesome.

The fight begins.

[Chuckles] That’s right.

[Chuckles] Oh, man.

That’s awesome. So Peter, you said that you don’t like Textile and I totally agree and I love Markdown. So how come you don’t like Textile?

I can't remember why now. I mean, the thing is I made this decision. It must have been two years ago now. I kind of avoided it. As I said, I love HTML and love CSS, so I've always been doing everything on HTML and I thought, I better try one of these languages because a lot of people seem to be submitting blog post to me and Textile and Markdown and whatever for Ruby Inside and stuff like that, so I thought I better play with them. I ended up kind of liking the idea, try Textile, and yeah, I just didn’t get on with it, but I can't remember why now. So you might elaborate on that kind of thing, because it sounds like you harbor more of a direct opinion on it.

I’ve tried Textile a couple of times and I guess I find that if I need a simple, easy to translate to HTML language, that Markdown is awesome because it’s just like how I write an email or whatever, which is actually how it was designed, of course. Whereas if I need something more complicated, then I don’t want to go to Textile, I just wanna go to HTML, and handle it that way. Whereas with Textile, I'm always like, “Okay, how would I do a paragraph with a class or to give it the right idea and all that, or it’s like I could have been using just using HTML and I would have known.

That sounds about right. It sounds like we kind of think HTML in a bit more than perhaps the other guys do.

I'm so glad you said that, because that’s actually the reason that I don’t like HAML at all, is I don’t understand the problem it’s trying to solve.

Not having to search for closing div tag ever again.

Yes! [Chuckles]

That’s a failing with your editor.

No, because it might not be that you wrote the div tag, that’s what convinced me we can jump to HAML years ago was someone leaving me div tag out of a partial that I'm consuming that I didn’t write, and then my whole layout is jacked.

Yeah and the other thing is it’s not just leaving the div tag out, it won't tell you which one you didn’t close, so it’s really a headache. It’s like when you get 8 ‘ends’ at the end of your Ruby class, that’s a headache too; you should be using whitespace and things to separate them, so that it’s easier to tell which one is which. And if you have like more than three of four in a row and yeah, so for me, it’s not just which div tag did I close, but where the heck is it and I don’t have to worry about it. And it’s the same with ‘ends’ in your views is if blah, blah, blah and then you just put whatever in there, and it encloses it for you.

You know, it’s also I think telling of what technologies would you give up first. I would give up HAML way before you would SASS out of my fingers.

Agreed.

Yeah. Definitely.

So I feel like you guys kind of answered some of your own questions there, in that as far as a missing div, there are tools that handle things like that like indention and stuff by making sure it’s there. And then also, Wynn mentioned collaboration but how many people know HAML versus how many people know HTML?

That’s true. In very project, I think it’s different. And even the tool chain that I use for project to project based on who’s participating, I think I designer developer more than most, so a lot of times I'm working on both sides of the fence, and if I have a project where I’ve got a heavy designer input, then I have no problems doing something in HTML or ERB or one of those things. But if I'm controlling it, HAML works for me because it’s not only just the closing div tags and the CSS structure; the other thing I don’t like about it is far less escaping between Ruby and Markup, I mean just one equal sign and now in Ruby mode without having to constantly be reaching for that percent key. The other thing is just by nature, HAML encourages short --- outputs, so it fosters this architecture of putting more into helpers or more into other partials, and not having these big --you use in the first place.

Yeah. One other thing that I really like, it’s something that you can do in HTML, but HAML it formats; it does all of the indenting for you. I mean, it’s dependent on indenting, but when you get the overall HTML out of it, it’s all properly indented too. And so, when you include a partial, that just gets nested with everything else. And that’s another thing that I really like because when I'm digging into the actual HTML source, it cleans a lot of that up. And the other nice thing is that I found that the percent or the dot or the hash in front, that tells me that it’s a tag, a class or an ID, that’s a whole lot easier for me to parse than to try and figure out what’s inside the braces and try and go, okay what attributes does it have. Oh, it has this id and it has this class and blah, blah, blah. I can just glance at it and get a real good idea. I guess it’s just faster for my brain to parse that way.

I also use the inline filters quite a lot. Chris Eppstein, the guy that created Compass had a blog post maybe a couple of years ago now talking about HAML sucks for content. And I would agree. If I'm doing a lot of text generation, I'm going to Markdown or something else. But the beauty of HAML is there's another format that I wanna use, I just put a colon in the format name and then indent after that now I'm running a Markdown.

Hmm. I didn’t know that. I'm going to have to check that out.

So when you mentioned that you have used Mustache in a couple of scenarios, I think I pretty much agree dead on with your usage of it is, I like it when I need a safe templating system. But if I don’t need that, I do prefer to stick with the ERB, because I prefer that Ruby behavior of being treated like a grown up, would you agree?

I would agree with that. Mustache is kind of like safety scissors; it’s almost like Liquid that doesn’t suck. If you guys remember Liquid that came out of Shopify. Liquid was one of those formatting languages that my brain did not grok.

I have to totally agree with that. Isn’t that what Jekyll uses under the hood? And I can't stand that. I

just ended up debugging a static site with jekyll the other day and it turned out to be because when I was signing these dates into Liquid variables and then comparing them. They were not comparing it as I expected, and I ended up having to use this… it’s got like this capture syntax, where it can render something out and put the contents of that in a variable. And once I changed to do that even though it was basically the same thing, it started working and it was like a thousand times uglier. So I totally agree that Liquid does not do it for me.

When I'm using Mustache with the client, a lot of times, I switch over to using Handlebars from Yehuda. So Handlebars is basically Mustache++ or Mustache.JS++, where it allows deep traversal of objects. One of the things that kind of cumbersome about Mustache -- at least in the JavaScript work -- is you have to build partials at every level that you wanna consume an object, but Handlebars allows you to traverse an object and pick keys off as you walk down a really deep object graph.

That’s another kind of cool advantage of those types of systems, is that you can use some library in Ruby and then some library in JavaScript and then basically have similar templating in both places.

For sure.

That sounds nice. It would also be nice to be treated like a grownup.

[Chuckles] Right, exactly. So Peter, you said you are interested in trying out a bunch of new stuff you looked at. What are some examples?

Well, I must admit; I did try HAML like when it kind of first started becoming popular. I think that was a good couple of years ago now. And yeah, I just get on with it because of some of the problems you already mentioned already and I just didn’t couldn’t grok it. I couldn’t get my head into it. So yeah, as times gone by, it’s been kind of like arguments on Twitter and like people are like, all these kind of like HAML proponents and its sort of been like, okay see why some people like this stuff and this is kind of like where I don’t, but okay, everyone can use what I like. But then things have happened overtime and there's been things like that, like we’ve just mentioned like you can embed other formatting languages into HAML. I don’t think that was around from the start, when I was trying it for the first time, that’s kind of cool. But then there is Slim, which I believe we are going to kind of sort of briefly cover as well. Andrew Stone, I think it’s by, he’s basically like I think taken the idea of HAML and almost ripped it off. But yeah, he’s been influenced by it heavily, but he claimed to have made a version that’s similar to HAML, but it’s a lot faster -- supposedly -I've heard arguments against that as well -- but with a slightly nicer formatting to it. And that’s also encouraged me to go back and look at HAML and think, “Hang on, how is HAML different to it?” And it’s not that massive of difference; it’s just really like tiny things like certain bits of sort of extra syntactic sugar or whatever you wanna call it to like collapse the whitespace and things like little characters you have to write in to get that kind of features. You know, really small things. So I think just the fact that there's this discussion going on has kind of encouraged me to go back and look into these things and re-assess my opinions two years on and with a lot more development and a lot more maturity of the technology sort of under its belt. It’s time to look again as it were.

That’s a good point. I haven’t used Slim at all. Chuck or Wayne, have you guys used it?

I have not.

I haven’t either. I've heard about it. I've heard some people saying that it’s superior to HAML, I doubt it.

I'm a HAML fan boy.

[Chuckles] That’s awesome.

You don’t have to use the percent signs. I mean that’s one big thing that they mentioned. So literally, like if you just type anything, by default, it’s a tag. And so then you have to kind of like nest things in a certain way so like if you don’t wanna have a tag. But everything is treated as a tag because I mean HTML, you know everything is within a tag at some level or another. So I think he’s kind of assumed, “Okay, the default should be that anything that you type in is a tag and then things have to be formatted especially if they are not.” So an example, I think if you go to Slimlang.com, it’s sort of has a bit of a HAML site, it has like a basic demonstration on the front page. And I've got to admit, I think they do pick their examples carefully in these kind of sites. They’re like, “Lets pick something that looks really appealing. This is going to make you fall in love with it straight away.” And this site is no exception. If you go to that Slim-lang.com, the example on the Front page is quite attractive; even to someone who is into HTML, like I am. I can kind of see where it’s going, but it’s not until you started using some of these things and you have like complex bits of like you might wanna get a certain type of iterator involved or something like that, then you can start slamming into the learning curve. So looking is nice, but it’s the using that is proof of the pudding.

One of the things I'm struggling with is just all these templating languages that I love HAML and addicted to SASS and then CoffeeScript, they’re all whitespace aware, yet I'm still not in love with Python.

Yeah, I agree. And I'm not sure what the difference is, to be honest.

I'm very glad I didn’t have to point that out. [Laughter]

I mean, I don’t have a lot of experience with Python, but still, yeah I mean SASS and HAML at least are whitespace aware. CoffeeScript is, but… yeah.

So, I've never run into problems with Python’s white spacing just because I am one of those very meticulous persons. And like whenever I stopped to think everyone has their nervous ticks. And whenever I stopped to think mine is too obsessively clean code, so I just sit there and mind things up and put them beautify and stuff. And so, I've never actually made Python mad or gotten into where its indention didn’t work, but I could see how that could happen.

Yeah, it just seems like that’s one of the arguments that people throw out against HAML and some of the others is that, they are like, “Well, it has the whitespace, the required whitespace.” And then they get all upset about that. And to me, it’s really not the discussion; it’s the other aspects of the tool that make it what you want or don’t want.

The whitespace is the least of Python’s problems.

Right, it’s the passing --- everywhere.

Yeah.

Functional method.

So it’s harder to make, I guess a convert of a non-believer in HAML just because it really doesn’t add anything to HTML, that it produces. But in the case of CoffeeScript and SASS, you are adding language features that just don’t exist otherwise. And CoffeeScript spits out just plain JavaScript, but it’s not a one to one correlation. If you’ve ever dealt with CoffeeScript’s comprehensions and just the way that you can initialize object literals without having to mind braces or semicolons, it’s just amazing.

But isn’t that kind of part of the problem with CoffeeScript -- and I admit I've got horribly low experience here -- isn’t the problem that because it does compile down, doesn’t it kind of add pretty hefty debugging pane layer there?

It depends how you architect it. In my Titanium projects, I've yet to find an issue where I've found an error in my JavaScript and not knew instantly where that was coming from in the CoffeeScript. What might be coming in the future, talking to Jeremy and those guys, is kind of like what they’ve done in SASS to include the commented version in development mode where every line says it comes from this line of the source. So the debugging tools, can then kick in kind of like a FireSass for example kicks in for firebug so that you can see what SASS files your CSS came from. This same tools I think will evolve for CoffeeScript.

One of the other concerns I've had with CoffeeScript -- and again, I'm speaking from low experience here, so this could be ignorance on my part -- is the need to always have a JavaScript runtime -- pretty much -- in the environment.

Unfortunately, that’s a dependency but I was thinking about that the other day just what a cool language it is, right? And it would be nice if it compile down to other languages, regardless of where you want it to run. It’s kind of like the inverse of the .NET framework, where you get C# and VB.NET compiling down to runtime. It would be nice to get one language to get multiple runtimes.

Yeah, that’s true. And I think we hit the arguments that I've heard about against CoffeeScript and that being mainly that people are concerned about adding that layer of complexity. And yeah, in my experience, you can generally tell what came from what part.

There's an interesting thing I saw in a Rails Conf stuff has been coming up; the new implementation in Rails uses tilt under the hood, which Rails doesn’t use I don’t think, but will soon. And that’s kind of a cool gem that supports a whole bunch of just different templating languages. And it looks like Rails is going to move over to that. If does, then that’s kind of a neat move to make it easier for people to use whatever they want in templating.

I love tilt.

Tilt. T-i-l-t?

Right, correct.

Just taking notes for the show notes. [Chuckles]

That’s how Sinatra handles it’s views.

Right. And that’s another thing that I'm kind of curious about. I've heard that Peter does a bit with Sinatra as well, and I'm sure you guys have used it, have you seen much difference as far as using a templating language in Sinatra versus Rails or Padrino or some of these others? Are they pretty much the same?

No. I know some people do templating in Sinatra, some people try and like cram it into the actual file when they are doing like a small single file script, but I never kind of bought into that. There's something about that that I just don’t like. So yeah, never used that. So other than that, no, I've actually found it very similar to Rails other than the fact that Rails takes care of a lot of some of the defaults and things like that, But yeah, if I just wanna say ERB and you know, call on whatever, it’s going to render it and I just work in a very similar way. I guess I've kind of almost recreate a Railsesque kind of feel if I'm going to make a bit bigger in Sinatra, which I've done. Yeah, I just kind of steal ideas from Rails. And that’s really sad to admit that, but there you go.

You know, when Heroku came out with the read only file system, I think it was when I made the jump to decouple my assets from the actual framework. And the Rails 3.1 might change that, but there's so much pain trying to get SASS built on Heroku, because it was trying to build the CSS files out to the public folder. And that’s not allowed in the Heroku file system that you had to jump through hoops to config that out of there, that I went to a workflow where would crank up a watcher guard and it just watches my assets folder; anytime anything changes, it runs it through the appropriate preprocessor and it’s just a static asset I deploy.

So that’s kind of a great point. So what you are saying Wayne is you edit in the languages you want to, but in the mean time they are being built as these final files and that’s what you end up pushing, basically.

That’s right and that way, first person to hit the site after it goes to sleep, isn’t having to pay for the asset generation that hasn’t changed since I've done a build.

But the only downside to something like that is collaboration, right? Because they don’t have the files that you have.

Just part of the deploy process, it would compile those one more time.

Yeah. And that’s one thing I wasted about half hour of my life trying to get a Rails 3.1 app to run in on Heroku and I was using CoffeeScript and yeah, it didn’t fly. So yeah, I think it’s an interesting thing that they're going to either have to handle one way or the other on Heroku. I would assume that you can also put in some git hooks to build those.

For sure. And another aspect of CoffeeScript that I absolutely love for Titanium is with Titanium, there's something called a context of something analogous to a window and the browser, where it’s basically a JavaScript scope and any context, you have to include all of your JavaScript source. So if you have ten files, that’s ten JavaScript includes to include that in that context. One of the things I absolutely love about CoffeeScript is it has a join argument that you can pass to the coffee compiler. So I've got literally dozens of Coffee source file, and essentially every view in Titanium is its own factory view. Its essentially one method and a name space that I've defined that returns a view. But during the compile process, all of that gets compiled exactly to one JavaScript file. In that way, all of my contexts only include one file and I'm done.

Oh, nice. Yeah, the Rails 3.1 does the same kind of thing when it compiles. It compiles all of your CoffeeScript files into one file and then you get application.js that has everything in it -- including jQuery.

That’s awesome.

Yeah, this really nice.

Very cool. So I used Builder. Do you guys ever used that -- from Jim Weirich -- to use xml? CHUCK: Oh, all the time.

Me too. I really like that gem, actually. I don’t know. It’s like a perfect Ruby to xml translation, in my opinion.

I don’t always use xml, but when I do… [Chuckles]

I don’t use it very much either, that’s true.

I used to and I switched away from it, actually. I switched to actually using ERB for generating xml, which I know is a little bit sacrilege, but it just feels nice. Again, it’s almost like taking that HTMLHAML argument just to like bring it further extreme, like I just want to write xml. So yeah, that’s what I do. I forget that format.

I´ll tell you what ERB is great for and that’s if you are building Ruby gems that include assets that have to be dynamic, based on input in the generator, ERBs are fantastic way to do that where you can have class files that --- themselves based on user input.

That’s cool.

And I have to point out that our ERB champion here uses Builder on his xml.

I do. I was just thinking that when Peter said that that was me on the other side, but I don’t know why. Whenever I mess with Builder, it feels right to me. And I guess the way the Ruby blocks nest and stuff mirrors the structure of the HTML and it fits my brain well for some reason. PETER: Just like HAML does.

Just like HAML. Yeah, you’re right. You guys have converted me. I'm going to go right on and switch.

Yeah, why don’t you stick with your Builder and leave my HAML alone, dude.

[Chuckles] You'll have to. I can't read it.

But you can make HTML with builder, can you?

You could.

I would assume so, yeah.

That could be interesting.

Yeah. For some reason, I don’t ever do that. I don’t know. That’s interesting.

There was Markaby as well, which was similar-ish.

Right. There were a few libraries kind of along that. You mention Markaby era. T. Howard had one called Tagz I believe. And it was kind of similar along that, but I never got in to any of those. I think those maybe their intended use case was kind of, if you were doing the short Sinatra like Peter was talking about earlier, so you could just kind of throw it a bit of Ruby syntax at the bottom of the method and generate some workable HTML. But I just never find myself…

So have you guys seen Zappa?

Uh-uh.

So Zappa is essentially a Node framework built on top of express and NodeJS, but also includes CoffeeCup, which is Markaby for CoffeeScript.

Huh, Markaby. That might be interesting. So in JavaScript, to make it… seen JavaScript, I think I would like a nicer way to generate HTML.

I just checked out actually Ruby Toolbox and Erector is one of the top ones we haven’t mentioned at all but I've never used that. But apparently it’s inspired by Markaby, but overcome some of its flaws.

Well, the biggest flaw for Erector was probably the name and I'm not meaning that… [Laughter]

I think that’s a plus.

I was involved in that project mailing list early on in the project and it was quite the dust up around the name. Some folks takes offense to that name and I think it may have even dampen a lot of enthusiasm for Erector when it came out.

What? Are they five years old?

I've never used it.

I haven’t either.

I never use my Erector. [Laughter] Hey, they are going to complain about this podcast at least.

That’s right. All right, so is that our final word on templates?

I think so. We usually take about twenty minutes on the picks and we have about 20 minutes left.

So yeah, I was about to call it and wrap it up. So let’s go ahead and jump in to the picks this week and we are going to go ahead and let Peter go first.

Yeah, I pretty much got one. Nice, simple quick one. I was watching the DHH keynote the other day live. I don’t know if you guys have at all, but so that was quite fun.

I watched your live stream of it, Peter.

All right, cool. [Chuckles] I think there was broken about that where the caching on WordPress I was like, hang on this isn’t updating, but yeah, I guess it worked out in the end because everyone seemed to have liked it. So yeah, I was watching that live and live blogging about that and then eventually, like literally after a couple of day… it was literally out yesterday, I guess. They released several videos onto YouTube on the O’Reilly channel on YouTube, and there's a few different presentation; there's like Greg doing the Ruby Heroes, which I think Michael won and yeah, a few other people for like documentation work and stuff like that. --- I think for some RVM work. So that was kind of cool. But I guess the thing that I just wanna mention is our kind of our friend here on the podcast, Aaron, “tenderlove” Patterson, his talk is on there and it’s kind of crazy; it just kind of go all over the place but he dig in to so many interesting things. It’s well worth watching. And if you start thinking, “Oh, this is kind of long it’s like a 50-minute talk.” And he kind of laughs all the time even at things that are not funny, which is kind of funny to watch in itself. But at about 42 minutes in... -- I only know this because I've linked so many people to it in the last day -- it goes absolutely insane. Basically, like loads of people come on stage and there's like a big kind of like dance that’s like lead by Aaron, it’s just really weird, but really fun to watch. It seems like one of his best moments of Rails Conf ever kind of moments. But you need to watch the whole presentation. Don’t just jump to that part; watch the whole thing. It’s just really fun. Helps you feel like you are there, a bit. So that’s the only thing I wanted to mention this week. It’s the only thing that I've watched and gone, “Wow this is a little bit crazy.” So yeah, definitely watch that. The O’Reilly videos on YouTube on RailsConf 2011.

All right, cool.

The Aaron video is the best one so far, I think. It’s really good.

Nice. And you mentioned the Ruby Hero’s one and I actually got a mention on there from Greg and that made me feel good.

That’s right. You did.

Anyway, James, your picks.

My picks. So I'm going with two this time because I wanna recommend a non-code thing and you always feel guilty for recommending a non-code thing. So first non-code thing; if you guys don’t know the cool thing about having kids is then you get to play with a child’s toys again, and so I've been playing with Legos a bunch a lately and my kids were way too young for Legos, so it’s only an excuse. But if you guys haven’t done that in a while it’s actually kind of cool. Some of the Lego sets that are out are really pretty nifty. Like for example, my wife and I just got done putting together a 1600-piece set of the space shuttle, which you know since about be a thing of the past, was kind of cool for us. And it’s really detailed with opening doors, got a satellite in it on an arm that comes out and landing gear that come down and fuselage and the booster rocket separate and stuff. So Legos are pretty cool. My wife has this carousel that actually goes round and round, and horses go up and down and plays music -- all built out of Legos. That’s pretty cool stuff. And then since I need to recommend something code related to make myself…

ERB.

ERB, exactly. Right.

We’ve talked a lot about screencasts and stuff, and yet I think we have never mentioned Peepcode, which is like horrible, because Peepcode is awesome. They have some really great screencast on there. Some of my favorite lately, the PostgreSQL one on there is awesome. That’s very clever in that they totally skip all the easy stuff and go straight to the really sexy stuff, so you’re super hooked -- like 15 minutes into it. And you'll go figure out everything out because they’ve just soaked you so good. So that’s a really great video. It would be an awesome warm up for next week’s episode. And then other ones I've been watching on Peepcode, are they have this play by play series where Jeff just sits down with some expert and gives them a little task and they sit there and code it. And actually, the coding part isn’t usually what’s interesting; it’s the comments and stuff they make along the way that is the very interesting part. So I like watching those. And Peepcode is just overflowing with useful screencasts, so I definitely got to recommend Peepcode.

And there's a CoffeeScript one just coming out as well.

That’s right.

All right, well I'm going to go ahead and go next. I'm going to do a non-code related one and then I´ll go ahead and do a code related one. My non code related one, I really like epic fantasy and fantasy stuff, and there is a podcast that I've been listening to that I've really been just enjoying, and it’s called The Secrets of the Hobbit. And it is done by a catholic priest and another guy in California. And the catholic priest is actually in the Netherlands. Anyway, they talk about kind of an interesting mix between news about the hobbit movies that are coming out in the next couple of years, and the book. And so they discuss, “Okay, we found out this about the movie and in book, it’s this way and we have these things going on…” It’s really, really been fascinating to see how that all works. And you hear news and you hear names of actors and stuff. And it’s been kind of fun, so you find out that Orlando Bloom is actually going to be in The Hobbit and you find out that… I haven’t read the books in quite a while, so they talk about some things from the books and it’s interesting to hear how Bilbo found the ring in the first place and stuff. And then my other pick is I've actually, like I said two weeks ago, I switched off of Cucumber and started running just regular Capybara in my integration tests and there's a gem out there called Steak that sets all that up for you and it provides some context for Rspec and stuff. The only problem I really have with it is that I

want to try out Minitest a little bit more, and Steak from what I can tell is Rspec only, but it looks like it’s really convenient way to set up your acceptance test to skip all the garbage that you get with Cucumber, and actually just get right in to writing your tests in Ruby. So anyway, those are my picks. Wynn, what do you have for us?

Got a couple of code picks and I got a non-code pick for you. So I mentioned Guard earlier. guard/guard on the GitHub. This is like watcher, except pure Ruby. Got back into this one a few weeks ago and was excited about it and thought about running a blog post and then when I was googling, I realized I already had written a blog post on this one. What’s old is new again. So Guard is exciting way for me to compile a lot of these precompiled languages. The other one is TI, it’s a new gem from Robert Evans over at the code wrangles. They are putting together some of the patterns we are using on some Titanium projects and extracting those out into TI, that allows you to generate a lot of these views, complete with Jasmin specs and some of that. And gives you more Ruby workflow to dealing with Titanium that supports CoffeeScript out of the box. Since you guys are doing non-code picks as well, put in one. Have you guys seen the cricket?

Uh-uh.

It like a printer, except it cuts paper.

I got one of those for my wife, for Christmas.

Yeah, she’s doing all sorts of cutting with this thing. It’s kind of like the razor blade model, where the cricket is really inexpensive, but then they charge you like $90 per cartridge, that has fonts and symbols and things. I found this piece of software -- and it’s got the lamest name ever but it’s really, really cool -- it’s called “Sure Cuts a Lot”. It allows you to hookup via USB to your Mac and anything that you can save in SVG and illustrator and other app can now be cut on this device, which is really cool. So it’s a nice way to make some irregular-shaped stickers and other things. It’s nice to do something that is not pixel driven

That is cool.

That sounds really nice. I might yet be able to convince my wife that she likes Macs.

Keep working at her.

Yeah, I will.

Just don’t show her HAML, that --- people off.

[Chuckles] Like I said, stick to your CSVs and leave my HAML alone.

Hey, Chuck.

Yes?

I've got to say something. I'm going to be that annoying guy now at this point. You know, you mentioned Steak?

Yes.

About a month ago, slightly blatantly, they added into Capybara pretty much the same stuff that Steak does -- directly into Capybara. So it’s not been like… no one is trying to make a fuss over it, I'm just sort of commit, it was kind of like --- a whole DSL for doing the acceptance testing and then just started doing it. So I should have done a blog post about this, I guess. But yeah, there's some stuff in there to do that, very similar to Steak, so I've actually moved all of my stuff across Steak straight into Capybara now. So that may help you if you wanna try move over to Minitest. I guess I need to blog about this.

Yeah. One thing that I've… because most of my tests that I've been doing with just Rspec and Capybara, you know, I just include Capybara/Rails; I just require that in my spec helper and that’s about all it takes. I think were maybe one or two other little steps; you had to install database cleaner or something. But you know, I don’t know if Steak takes care of some of that for you, but I've done it both ways. And Steak has a convenient little installer. So anyway, that’s something that’s interesting to know about. All right. Well, I think were done. I'm going to go and queue the music and just thank you guys for coming out again. We have James Edward Gray from Gray Productions. What’s your blog again? It’s blog.grayproductions.net. I can never if it’s .com or .net. We have Peter Cooper from Ruby Inside, Rails Inside, Ruby Flow, Coder.io, Ruby Weekly, JavaScript Weekly -- and probably a dozen other things that I have forgotten.

I rule the world!

[Chuckle] And we have Wynn Netherland from the Changelog podcast. And a whole bunch of other cool stuff. In fact, if you go and look at his projects page at WynnNetherland.com, it reads literally like Ruby wrapper, Ruby wrapper, Ruby wrapper, something else, Ruby wrapper, Ruby wrapper.

[Chuckles] Look at his GitHub page -- it’s scary.

Oh yeah, I bet that’s worth looking at too. But anyway, thank you Wynn for coming on the show.

My pleasure.

You can get the show notes by going to rubyrogues.com. And there's a link on the right, we're in iTunes, if you click on that link, it will pull it up on iTunes. Please leave us a review and let us know what you think. You can also email or tweet any of the panelists and give us your feedback. And we are happy to have that and to take it into account. Thanks everybody for coming on and we will catch you next week!