The Rogues talk about web programming and updating frameworks with Yehuda Katz.

Special Guest: Yehuda Katz.

 JOSH:

By the way, a little trivia 5 by 5 means loud and clear.

Yes.

Really? I didn’t know that.

Yes, it's on a scale of one to five for loudness and clarity.

Ahh.

I would search for that on Wikipedia, but it's down.

[Chuckles] My father was an air force jet fighter pilot, he told me. So there.

There you go, you got it from an expert.

Yeah. [Chuckles]

Our listeners only care about one thing: What's the better language Ruby or JavaScript?

I think I might have to keep my feelings to myself since I'm going to be on a JavaScript podcast.

I should just say as a caveat, almost everything that I have to say on this is basically like my opinion, based on projects that I am on. So I'm happy to talk about it, but I'm not super excited about saying like, “You should definitely do this.”

I think we are basically all noobs. So I'm willing to speak as a noob who’s maybe a little bit ahead, and that’s about it.

No worries. Everything you say will stick with you pretty much forever.

Hey everybody and welcome to episode 38 of the Ruby Rogues podcast. This week on our panel, we have special guest rogue, Yehuda Katz.

Hey, nice to be here.

You haven’t been on the show before; do you wanna introduce yourself briefly?

Sure. I'm Yehuda, I've been programming for a bit… I'm basically a noobs compared to everyone else in the Ruby community. I've been programming since like Smalltalk or when Lisp was created or whatever. And I worked on Merb for a while. That was sort of my first big public project, got merged into Rails, worked hard on Rails 3. Rails 3 is now in very capable hands with Aaron, I still participate in Rails development, but these days, I'm much more involved in JavaScript stuff -specifically Ember.JS.

And in my work on EmberJS, I've been doing a lot of work lately on making the Ruby side of things work well with JavaScript-heavy apps, so I've been working on projects like active model serializers, and stuff like that. So I would say sort of my history is I started working on JavaScript projects first, realize that I was going to need some back end, got into Ruby, got into Rails, then sort of circle back around, and now got heavily back again with JavaScript. So that was great.

All right. Also on our panel, we have David Brady.

Hey, this is David Brady, and I know how to mute my microphone -- accidently. So, yeah like Yehuda, I have spent a large number of years circling back to the beginning of my career, and here I am.

[Chuckles] Also on our panel, we have Avdi Grimm.

Hey, this is Avdi, and today in protest of SOPA, I will be wearing a birka, instead of a gold bikini.

Woohoo!

[Chuckles] Yikes.

It's a good thing we can't see you. Also on our panel, we have James Edward Gray.

Hey everybody, good morning.

And finally, we have Josh Susser.

Hey, good morning everyone. I just wanna point out that Lisp is actually older than I am.

Wow.

Citation needed. [Laughter]

I can do that. It's in Land of Lisp.

I Think we need two citations. We need his birth certificate too.

Oh yeah.

Will you accept a birth certificate from Hawaii? [Laughter]

So what are we up to today?

We couldn’t read Wikipedia today, so we decided to go together and record a show.

Oh, it's going to be awesome. We are not going to sound nearly as much as we usually do.

[Laughs] Exactly! “Hey, what do you think about this technology?” “Uh….”

[Chuckles] My brain is boycotting because of SOPA.

Last night I was up until like 2 AM with insomnia, and having insomnia with a big portion of the internet blocked out sucks! Screw the SOPA protest. Man, I hope they get their way, and go away. Wow.

All right, well, in danger of being on topic, I thought I’d lob some questions Yehuda’s way. So you talked a little bit about how you done a lot of work in JavaScript, and a lot of work in Ruby. I was wondering if you'll talk maybe more about the specific projects. Like I believe you began in jQuery, is that right?

Yeah. So part of reason why… so, a minor reason why I got involved with Merb early on was that I was actually pretty upset with how Rails is handling jQuery stuff or JavaScript stuff with rjs, and also frustrated by the prototype dependency, which makes sense from the beginning, but lasted far too long. And so I was involved in jQuery pretty early.

Wait Yehuda, are you saying Prototypes are good for starting out?

No. So Prototype the library was a good library, and I think it got people on the right track, but I

think John was obviously on to something, and everyone knew it right away. And it didn’t take very long before jQuery had more users than Prototype. And I think the amount of… so eventually, Rails has become a little bit better about changing defaults, but essentially for the longest time, rails was basically whatever DHH came up with when he first made the first version of Rails. We're stuck with Rails forever, and that was definitely something that when we did Merb, we said, “We are going to take the opportunity to actually think about right defaults here.” And I'm okay with test units still being the default, by jQuery was clearly wrong.

But I got involved in jQuery very early, primarily because I basically got a job as a web designer, because I was a print designer in college and I was looking for a job. And I said, “Web design. I know print design. That’s basically the same thing, right?” And then I learned very rapidly that they were not remotely the same thing, and I need to learn to program. So I programmed as a kid, but I didn’t really do any hard core programing until that point. So I went to a talk about JavaScript, that I paid some money for, my company paid some money for, which was by Thomas Fuchs, who did Scriptaculous, and was learning “ajax” at the time.

And essentially, Thomas Fuchs at the end was like, “By the way, all these is cool, you should check out Rails.” So I checked out Rails. Ironically, couldn't care less about the built in ajax stuff, but obviously gotten to Rails. And my involvement with jQuery basically early on mostly documentation based, so I built this tool called Visual jQuery, which was for the longest time, like the main documentation for basically categorize all jQuery stuff. I was involved in getting jQuery to get these documentation into XML format to begin with, because initially it was just a wiki page and I was scraping, and I was like, “This really sucks. It would be great if there was XML that I can pull in.” So that was sort of my initial involvement.

And then, I got involved in Rails, worked on a pretty crazy project involving Microsoft project, and storing Microsoft project data in PostgreSQL schemas and other crazy stuff. And that caused me to be like, “Well, Rails is cool but sometimes when you are doing stuff that Rails didn’t intend or think about, it's really not cool.” Which is basically how I got into Merb. And then eventually, like basically, I essentially got Rails with very good people to 3.0, and I was meeting Carl and thinking like, “Okay, what’s next?” It seems like Rails is on a good track now. Obviously we wanna still be involved, but doesn’t seem my full time is still needed. What else is happening?”

And we both got felt like mobile and the growing JavaScript world was important. So Carl and I started working on some stuff. We ran into Charles Jolley, who I had known because the original version of SproutCore on Merb. And he was like, “Oh, you should join me. SproutCore is cool. You don’t need to build your own thing.” We joined him, said, “Hey, SproutCore is cool but it's like pretty huge, monolithic, not very good for web style apps.” We think we should take them different direction, so we essentially forked off while I was working at Strobe. I started working on SproutCore 2. Eventually realized that it was sufficiently different from what SproutCore 1 was that should be renamed, and that’s sort of the story.

And so that project became EmberJS, right?

Yeah, correct. So basically, SproutCore 1 is a Cocoa inspired framework. And the main thing that SproutCore 2 that now became Ember got from SproutCore one is the object model. So the object model were inspired by Cocoa, and has bindings and observers baked on its core, but that’s in contrast with like Backbone, which has a mixin that you could use for events, but it didn’t really have an object model, per se. So it has like a patchwork object model, so views are swamping. And basically, that part of what SproutCore was, is actually relatively small compared to the view layer, so we rewrote that. Actually Charles rewrote it. He was planning on rewriting for a long time, and that became the foundation of SproutCore 2, and then everything from the view up, essentially was reconceived, rethought in terms of HTML, CSS templates, stuff like that.

So Yehuda, just by way of immediately disillusioning all the Smalltalk lovers out there, just to clarify, you're talking about EmberJS, not AmberJS, right?

Yeah. So we actually started back when we started SproutCore 2, we marketed SproutCore 2 as Amber. SproutCore has a history of having beer names, and I happen to have Amber beer in front of me, so amber seems good. I gave bunch of talk in which I used the name Amber. We talked about it in blog posts, it was relatively public, but we never actually shipped as amber. And at some point we were like, “Okay, that was a code name we don’t really use that anymore. We'll start talking about SproutCore 2.”

And then eventually, we were like, “Okay, we are not going to call ourselves SproutCore 2 anymore.” Well, we’ll call ourselves Amber, we'll just use that. And at the time we started, it was not used. So we didn’t do the appropriate thing which have been to take a second pass. And then we’re like, “Hey, Ember everybody.” And everyone was like, “Oh my god. There's another project called Ember.” So we sort took a day and say, “Well, on the one hand, we kind of used this name for one time.” It would be like if someone was like, “We have a new Linux distro, it's called long horn..” Like everyone will probably be like, “No. That’s weird.” But we didn’t feel like the Smalltalk guys were doing anything in bad faith and it was easy enough to change, although it felt really silly at the time. So yeah, EmberJS.

I love Smalltalk, but I have to wonder if they picked the name amber because they found this dinosaur programing language DNA trapped in amber.

[Laughs] nice.

Yeah.

Our analogy was basically putting the dinosaur SproutCore in Amber.

I think Ember is a better name.

[Chuckles] Yeah. I think Amber gets used a lot. It was a code name for open doc once upon a time, because Amber, you find stuff embedded in it.

So this week, you can take all the hate mail that you are going to send to Josh… Josh.. I can't speak today. All my punch lines are blocked due to SOPA. Anyway, my point is, send all the hate mail to me. That’s what I'm saying. Send it to me.

He needs someone to talk to. [Laughter]

Probably since Wikipedia is down.

Because I'm so lonely.

“Hate mail is the only mail I get.”

It's the only form of validation I get. [Laughs]

Oh geez.

So Yehuda, I have kind of a broad question for you. You’ve been involved in two pretty major project. I don’t think it's even fair to call them ‘refactoring's’ at this scale. It's almost refurbishment or rearchicting something like the massive of updates where you modularize a project and rewrite large chunks of it -- at least two, by my account.

We used to call that ‘quantum leap’.

I would consider Merb as similar case. So I got involved in Merb around when Merb was 04 or 05. And by the time… Merb 09 started literally with an empty repo and try to maintain some semblance of backwards compatibility.

I think a lot of people in software are probably familiar with the systems syndrome where you have a first system, and you get a lot of bright ideas about how the first system sucks and we are going to totally do everything better; we are going to rewrite it and do it better. And that rarely works out. In practice, the second system tends to just drag on and drag on, and never get anything out the door. But you have actually managed to get some of these second systems out the door. I'm just curious if you have some observations on how to make that work.

So it's worth noting that Ruby is also a second system that got out the door. Ruby 1.9 is essentially a rewrite of the VM. I think the general impression that second systems tend to fail is probably… I don’t know what the opposite of survivor bias is, but failure… so people know about things Perl 6

because they drag on for a long time, right? It's like the big dig; people think that infrastructure projects tend to fail because the big dig took a long time, right? You hear about it. It's on the news so, people think that second systems tend to fail because the ones that tend to fail are really big deals. They are like kind of like the poster child for systems that tended to fail.

I can only hypothesize. I have not had a second system that like epically failed, but I can hypothesize that like some things that I've seen while working on these projects, that would have been warning signs that we did not do, that probably would are a failure. So obviously, when you are doing the second system, you cannot actually redo everything. You should not say like, “We are going to make everything perfect.” Because obviously if you do that, you will never finish. And I think Perl 6 has this problem. It's basically going to drag on forever because they are never going to ship. Actually so I work on Strobe, which never really shipped, and that was sort of our problem. It is not really second system, but we desire perfection. So if you desire perfection, you'll never ship.

Textmate has this problem. Desire perfection, desire perfection you'll never ship. And a lot of times, people who build the first system, they are not trying, they say they are trying to ship a second system to fix certain targeted issues. Like in Rails, probably the biggest thing I wanted to fix that we got done was the plugin system was basically a giant model with railstie gems that connected all Rails into one, as glue. And basically what that meant was that if you were not Rails, there was literally no way to hook into the Rails initialization process and to do anything that Rails was doing. So in order to improve the overall ecosystem, we were like, “We would like to change how Rails works.” So instead of active record being magically glued in to everything else by hardcoding everywhere, we would like to figure out the APIs are. We talked about that a bunch.

And that was like a big idea, and so we make sure to get that right. But there were other things like the testing in Rails is actually pretty crazy; like much of the testing is path harded, bad mocks that hook in to internal stuff, and so there were periods of times where we spend a lot of time saying like, “Okay we would really like to have tests that are less insane. We are going to start rewriting or porting all the actions for the test. And make them using a better structure.” And then eventually, it's like, you know, we just spent two weeks modifying the test, it would probably be easier at this point if we just in the testing environment, wrote whatever hack we need to write, to make the new code that we're writing work against the old testing infrastructure. And we basically just say, “We can't do everything. We are just going to do that.”

As example for Ember, we basically said, “We are not going to revisit right now every single quirk of the object model.” There's going to be some quirks. Like the example of this is whether or not computer properties should be casual by default. There's like a very long thread about this. And we could have probably spent a long time revisiting it which would have require really rethinking the object model , how property validation works. I mean, we are just like, “For now, we'll just assume that the current object model implementation is basically correct, and we will wait to release before we revisit.”

And I think that’s basically… you have to, when you refurbish an existing library or tool, it's important to actually pick your battles and think about what things are actually important, what things are going to have high value. So like, rewriting action controller to be modular, instead of being a ton of alias chain hacks, was high value. Active record actually, we didn’t touch at all. Me and carl didn’t really rewrite active record. A bunch of people added arrow stuff, and actually, that stuff ended up being really slow. It’s taken a few releases to make it fast again. And so I think if you look at any of the products that I've been involved in, that are high profile, you'll see that there's a bunch of stuff that was not perfect, that the Perl guys will probably be like, “Oh you should probably wait till release, until that’s all good.” But that will never happen.

So is the big part of that like a dialog where somebody would say, “Oh and this part is really nasty. We need to redo this as well.” And somebody else would say, “No, don’t go down that road.”

Yeah, I think that needs to happen. And I think Ruby and Python 3 is a good example of this. So Python 3 was like, there was a lot of ugliness. And, you know, I can't really say. Maybe Python 2 was sufficiently ugly, that breaking changes will require to make Python 3 good. For example, Python 2, there are two class systems. It depends on whether you inherit from object or not; whether or not you are getting a new style or an old style class. Python 3 only has new style classes.

What?

It's true. There should be one and only one way to it. But there are two types of classes. So basically, at one point they decided that like being able to call super…

[Laughs] I'm sorry.

At one point, they decided that being able to call super was a good idea, and they could not add it in a backwards compatible way to old style classes. Super and other features that exists in modern class syntaxes. So they basically said, “Every old thing is basically an old style class, which is like a type. And if you want to opt in to new style class, you have to inherit from object exclusively, and then you get all these new features.” So this is how python works.

Probably someone decided that was sufficiently ugly, that they would have to break this in Python 3. Also strings in Python 2, the string literal is byte string and I have to use a u to make it a Unicode string. In python 3, string literal is a Unicode string, you have you have to use a b to make it a byte string. Right? So probably someone decided -- in sort of the same way Ruby did -- strings should be encoded by default, and they just did that. So basically the end result of that is that python 3, the adoption was probably going to drag on forever, because there are so many backwards incompatible changes that are not possible to address, merely at run time.

So in Ruby, if a method on enumerable changes, Rails can just be like, “We’re not going to use that method; we'll use a different method which will check and will do the right thing.” Or like every… all the instance variables reflection uses symbols instead of strings, so we'll just do a layer on top of that. Those are one-time hacks. But in python, there are sufficient number of things that you can't, at run time decide, “Oh, this thing was an old-style class, we should now make it a new style class or whatever.” You can't fix that way in a way that is reliable. So actually that’s not a good example, because you could just in python 2, always inherit from an object. But there are cases like the string case, where it's not easy to write a python 2 script that you could then at runtime mutate. So basically, I think python 3 has more second system syndrome because they decided to break too many things.

This is the second, second system?

Yeah. So like Django is still struggling to be compatible. Python 3 and Ruby 1.9.1 came out around the same time, but we're like basically all the way over the adaption curve because we didn’t break anything. And there are like sort of… there’s someone who’s written like an experimental patch that will allow Django to work on Python 3. And I think Ruby 1.9 and Rails 3 both were like we’re not… backwards compatibility is extremely important. So like in Rails 3, the router… if a block takes a parameter, we’re like, “We are going to go into old style router mode.” In the Action Mailer, we are like, “We are going to support all the old style syntax,” right? Because we were like actually upgrading, it's going to be hard enough with all the changes. We are going to try really hard to not break backwards compatibility to kill everything. I think Rails 3 did a better job than like Structs 2. Structs 2 is a total rewrite. No structs 1 user has upgraded to Structs 2 because it's like way too different. And Rails 3, I think got around that problem by actually caring about backwards compatibility.

Yeah. I think the transition from Rails 2.3 to Rails 3 was actually a hell a lot of easier than transition of Rails 1.8 whatever to 2.0.

I couldn’t disagree more.

Really?

Yeah, upgrading from 1.2.6 to 2.0 took me ten minutes and two lines of code change.

I’ll say you probably weren’t doing very much interesting in your app then. [Laughter]

So I will rephrase what Josh said. I think you probably weren’t using a lot of plugins.

I'm not using any plugins. I'm using one plugin and I wrote it myself.

So in the general case, if you are writing a relatively small to medium size app and don’t have plugins, upgrading versions of Rails, you will usually get a lot of deprecation warnings, but not… things will probably mostly work. But the plugin ecosystem, I was just tweeting about this… the plugin ecosystem in Rails 2 is basically hack whatever you need to hack. And like, I'm surprised that… basically the only reason why anything ended up working was that most of the popular plugins get a lot of work to make their own backwards compatibility versions… backwards compatible versions of Rails 3.

Yeah.

Sorry for that slam, Dave.

That’s alright. I have callouses on my crotch from all the punching. It's good.

So I personally am not surprised that upgrading to Rails 3 is not trivial, but I think it's easy because of the fact that people experience pain, which is expected. It's easy to miss the fact that the router syntax works, that all the old active record syntax works.

Oh, I love it. It's absolutely beautiful. I love what you guys have done with Rails 3. So unfortunately, that seduced me into like changing my routes file, instead of just leaving the old Rails 2, I should have just left the Rails 2 routes in, and I would have been fine.

So eventually, maybe for Rails 4, we will deprecate the old route syntax. I mean, the fact that we basically left around a copy of the old router in Rails just so that people wouldn’t have to upgrade it. I think it took us a year and a half to do Rails 3, easily six months of that time was just like, “How do we make sure that existing apps will actually boot… I mean, we changed the entire initialization process, right?

Yeah, that's interesting.

This is something similar to what we are going to talk about on the JavaScript jabber show later today, but what direction do you see the web going? Because it seems like a lot of the projects you’ve worked on with jQuery, Merb, Rails, EmberJS, they are all kind of web-oriented frameworks. So what direction do you think things are going to take within the next year or two, as far as web development goes. Is it going to start heading more toward these JavaScript frameworks? Is the role of Rails going to change a lot? Where do you see these all kind of heading?

So I'm going to stick to my parting line of this, which I've been saying for a long time. Although I feel like the world is shifting more towards my parting line but, I think that Rails is an incredibly good API server. I think people miss that aspect of Rails. So I have now worked on the last 3, maybe 4 Rails projects that I've worked on, have not had a view layer at all, and I have not, for one second consider using something like Sinatra or Node, because Rails itself has like... I know about it, so for me, I'm like, “I don’t wanna use all that security support. I don’t wanna lose all these http support that’s like figuring out what' the actual IP address is.” I know basically all the stuff that gets done that’s not in action view. Action view, was a relatively small part of Rails. So I like being to reload.

I think a lot of people look at… they say, Oh you know what, in my mind, the API surface area of Rails is actually very view-centric. It's like model and view centric. So for a lot of people, if the view is ripped out, it's like, “Well, there's active record, but like why couldn’t I have just a bunch of active record files in a Sinatra app?” And then it's like, “Well, actually you don’t have a development mode. You don’t have migrations without doing some kind of hacks, like figuring out how to do migrations on your own.” It's like all these infrastructure that’s built up. You have to figure out your own security stuff, and then they’ll say, “Well, I could use like Rack IP spoofing middleware.” Well then you have to not think about all things that Rails are doing for you for security. Find the appropriate middleware, hope that they are up to date. So my sort of my perspective from having been in the guts of Rails is that even though the surface area of Rails is an API that’s very view centric, the actual code is doing I'll a lot of things that are not view centric.

Oh wow, it's the corollary to Laver’s law. Laver’s law says, “Everything the system does for you, the system also does to you.” And what you are claiming is that, everything that Rails does to you, Rails also does for you.

Yes.

So to strip up the view layer then, is it just an MC framework? Like MC framework?

MC Rails [beat boxes]

I think it would be fair to consider the JSON generating part of Rails the view layer in the apps that I built. So me and José wrote a library Active Model Serializers, that we originally hoped to be part of Rails. But essentially what happens when you stop… when the JSON stops being afterthought, and starts being the center part of an app that is being consumed by JavaScript client, is that there's a lot more thought that goes into that JSON. So Carl and I, talk about this last year, so we've been saying for a long time that it's actually very important that the JSON that you generate from the server is relatively consistent.

So if you are in the client and you… so for most people, you are getting started, you have some jQuery, you wanna get some customers, you … customers and you do something with the JSON response. But if you are building a rich client-side app, you probably have a lot of models, and you probably be doing that a lot. So having some consistency around which one JSON actually looks like, such that you only have to write one method that says, “Given a JSON string. Here’s how I can extract something useful of it, is very important. And it's sort of my philosophy on this, is sort of the opposite of the jbuilder philosophy that DHH have. So DHH’s idea , “We should have a DSL, that lets you customize your JSON as perfectly as possible. You should have full control over it. And my philosophy is actually, “Isn’t Rails about convention over configuration?” Shouldn’t we have an easy way to just say like, “Here's how I want my JSON to look.” The important question is like should an object be an association be embedded as objects or as ids? Do I want to include the associations in the in the initial payload or…

So those are some question you need to answer, but those questions are like essentially conventional. There should be an easy way to change it. And then when you make JSON, you should basically be saying, “I want these attributes, these associations, please make JSON for me.” I don’t want full control. It's like, I basically look at some of the jbuilder, like how DHH looked at XML; I don’t want to spend a lot of time hand tuning how my JSON looks. I want to express the entity that I want to put into JSON, and I want to have it be emitted in a way that’s conventional, so that in my client, I can also do something conventional, and then forget about having to constantly care.

Shouldn’t you do both though? I mean, if it's convention over configuration, but Rails lets you go back and do configuration. If I hand an object off to the controller, it should and say to JSON, it should render as JSON by a reasonable set of defaults like you are saying. But if my set of defaults are unreasonable, I should very easily be able to change them. And maybe that’s where the builder comes in. If the builder is big and heavy weight, then I agree with you that that’s wrong.

So what you are saying is true. I should clarify a bit, which is I think that to_JSON is a problem. So basically, not to_JSON the method in Ruby, I think that we have JSON in Ruby 1.9. but basically, you have the to JSON is implemented on the model. And there are non-trivial controller level, usually authorization level concerns that are part of the process of generating JSON, and it does not make sense to put that logic in the model, even if you somehow give the model access to the current user.

That’s fair.

And not only doesn’t make sense, I mean, it doesn’t even make… I don’t know…

It doesn’t even make stupid.

Thank you David, I knew that. [Laughter]

But that does lead into a question. And this is something that I've actually been doing with one of the projects I'm working on for my client, I'm using backbone.js on the front end, so I have to give it JSON, in order to make it work. And you know, I need to know for example, because it's kind of a social network thing. I need to know if this user is blocked by that user, and you know, things like that. And so I constantly passing current user into the to_json, and I've actually customized that so that it gets a series of default parameters that I wante to generate a JSON from, and then I pass in the current user when I convert it to JSON. So how do you work around that?

So the serializer gem is sort of my beach head to an answer here, it's still pretty early, and we may evolve it or it may turn out to not be the answer. But sort of the theory is that, to_json is not a

method, it's a class. To_json is doing many things. It's very complicated logic, and trying to have a method that does everything procedurally is not the answer. So what you wanna do is you wanna have a class that has access to the original object that you care about. And also has access probably to the current user and some authorization context.

And in the simple case, you want to be able to have some simple helpers like, “Here are the attributes I would like to include from the class. Here are the associations I would like to include,” possibly customize with like what keys you would like to use and whether or not things are embedded, although embedding should probably be defaults that happens for everything, in which you can opt out of. And then by default, you just get this JSON. I think even just that is still better than trying to customize through JSON, because it belongs in an object, not in some procedural code somewhere. But then in addition to that, if you are like so let’s say you have a post which has comments, and let’s imagine a simple care where comments are allowed to be blocked or removed, but admins are allowed to see the comments. So you would say in your serializers, you would say has many comments, which would basically say, I would like to… whatever my embedding policy is, I would like to embed associated comments, and then you can override the comments method and use the authorization information, that is now available in that object, to customize comments array looks like.

And then basically, what happens is that the serializer will say, “Okay, now you are trying to make this serialized array of comments, I'm going to go instantiate a comment serializer,” and again, you can decide a different one for particular serializer. I'm going to instantiate a comment serializers, and do the same process for... So basically, instead of now having to go build a hash manually, do hash driven development, do some procedural crazy code, try to make sure that you have the right information, the right context. So the controller is kind of the wrong place for it, because it really doesn’t have a sense of what it is. And the model is kind of the wrong place, because it didn’t have the sense of their current user. Basically, you have an object that’s in charge of it, and then have that object, sort of give it some breathing room. Now that there's an object, you can add some helpers, you can feel nice, because now, you can have has many be in there, and have it do something useful for you.

You are kind of talking about something that people are either calling presenters, or view models for generating that kind of…

I am okay with calling it a specialized presenter for serialization.

Why not just call it a ‘view’?

So in Rails, people consider views templates. They think of views as… even if you look at something like Markaby or Erector, those things are so conceptually templates. They are about generating HTML. And like I said earlier, I think it is a view. I wouldn’t put it in the views directory, I think it's weird to have classes in the view directory.

Not if you are using Erector.

Yeah. So we have a couple of serializers directory that we use. I don’t really care.

Is that dirty? Did I miss a dirty thing?

Could be.

[Chuckles] You are losing your touch.

Okay, that was dirty.

Like I'm back on the Tilde offices. [Laughter]

I wanna completely derail the conversation for a second, and shift it away from technical stuff. And we talk about open source software and politics of a bit on this show. And in addition to like being involved in all the technical aspects of these refurbishing, and maintaining open source software, you probably get exposed to a lot of the politics of it. And sitting on the outside of a couple of core teams, it's easy to point fingers and criticize, or be really impressed with amazing efforts, but…

You don’t like their versioning for example.

Yeah, or release processes. [Chuckles] But being on a few different teams, I think you probably have a rather uncommon perspective of the politics of open source or the process. And it's interesting what you could say constructive about how to improve that world.

So I'll start with the tl;dr, which is I sort of have a grand unified theory of things. That’s actually too grand of a name, but I have a theory of things. It comes from both writing software and being involved in large projects, which is for most people in the world, your job is to present an abstraction layer for somebody else that hides most of what you do. And that’s what libraries do, what frameworks do, and what people do. That's what your secretary does. That’s what the united airlines does for you; they present an abstraction layer to you, that hides most of what you do.And leaky abstractions suck. They are painful.

So the people who do the best job in the world at their jobs are the people who do the best job at hiding the abstraction. And the end result of that is there are many things that people do, that libraries do, that open source projects do, that are extremely important that are crucial to getting the job done, but which basically the better the project, the person, the library is the less people actually know about these things, by definition. The more you are doing your job, the easier it is to you. If you are doing a crappy job, if you are Java, it's hard to … you, because so much of your guts are on a table, right? But if you are doing a good job of hiding complexity, people don’t have to think about the complexity.

And open source is sort of this same way; there's this process of even releasing a Rails where people bike shed Rails versioning a lot, but the process of actually shipping a Rails version is very complicated. There's a lot going on. We thankfully hide that from the rest of the world, because it would suck if everybody have to see all the machinations involved. But the bottom line is that there's a lot going on building consensus around people on the court scene, trying to understand what people’s interests are. I think the best things he does for Rails is make sure that when people wants features, there are actually valid use cases behind them. They are not just like some ideas someone came up with somewhere.

And this stuff is very, very unexposed. And it's sort of, I think one of the things I was saying, one of the things that is negative, I think about GitHub, and it's the positive… it doesn’t really matter, but if there’s a cost, is that a lot of people are doing open source, and they imagine that a huge open source project is a scaled up version of their small gist or simple project that they put up on GitHub. And they are really not the same thing. So if you release a project, and you put it up there and you use it in your company, and maybe like two or three people use it -- which I think is a lot of people -- or even like a thousand people use it, or 100 people use it, that project has a process that is you could leave for two months, and probably, you come back maybe have a few pull requests.

If everybody left Rails for a week, basically Rails will take on the life on its own. It would be like things would happen that would be crazy. But EmberJS is still new. It's even worse, like basically, there are request for features that are basically wrong, that are not plausible, given the direction of the project. But you leave for a week, you can't avoid those features getting in. So I think in general, people have a lack of appreciation. They have a lack of appreciation, for instance for the security process in Rails. The fact that… I think Rails is probably the most secure open source web framework. Part of that is that we have security list people actually send email to that all the time. Takes us a good amount of time for every single security thing to identify if it's real. Is it fake, is it a documentation problem? Does it require patches, is that an upstream problem. These are things that we deal with that we cannot actually expose, even if we wanted to.

So I guess that’s a long tl;dr, but the abstraction that big open source project provide to you, is if we're doing a good job, hiding a lot of complexity. And there are a lot of days where I'm very frustrated by Rails and the politics of Rails, but I don’t know how to make it. I don’t know how to make it better. It's just there's a world in which there's a lot of smart people working on projects, and therefore there is complexity involved. And like I said, I think Rails does a very good job of both hiding the internal political complexity. And I don’t mean like hiding the fact that there are disagreements. I think everyone knows there are disagreements, but hiding the process, like not making everyone have to deal with that. And also hiding the complexity of code, and I think it's part of what makes Rails good.

I do think it's improved overtime, especially in Rails camp, you talked a lot about how you used to be how to do Prototype, and now it's Prototype swap in jQuery if you want, whatever. And I think that's filtered down through Rails and other pieces like forever, it was MySQL was the one true database and if it can't be framed in those terms, then Rails won’t think about it, whereas nowadays, we see Aaron committing things that are better for PostgreSQL and stuff like that, which I think is more the way it should be, you know?

And obviously, these things are also political disagreements, right? So jQuery is now the default. There was a large argument about that in the Rails 3.0 era. And obviously, you can't win them all, but eventually got to the point where nobody could -- with a straight face -- argue that jQuery was not, by far, more popular than Prototype. Basically, my argument in 3.0 era, was almost everybody who start a new Rails project is going to immediately replace with Rails. Maybe we should take the time to make it integrate well.

But I guess… so I think Josh’s question about politics was a stoop, because it's essentially a process, and I'm definitely often frustrated by things like prototype is still in Rails 3 as a default. I really wish that wasn’t true, but it's definitely a good thing that… basically, DHH pulls the DHH card extremely rarely. And I think mostly his participation is like as a facilitator, to try to make sure that all the people who are… basically everyone has their own opinions, and if there's a way to make the final outcome reflect everyone’s concerns, that is a win.

And nobody is perfect, and DHH is definitely not perfect in this regard, but I think a lot of his Rails participation is in detecting that there are disagreements among the core team, and try to figure out what the concerns are. And essentially saying, “Okay, we are not going to argue now, what we are going to do is everyone’s going to say what the thing is they are upset about, and would like to see result. And then we are going to see what a good starting point is, and how we can evolve the starting point towards to resolve the concerns.” So usually what ends up happening is that if there's an argument with these two parties, one of the two parties is going to end up with their thing as the starting point, to make the other side upset. But the goal is to say, Okay, so that starting point you say problematic, because you don’t like these things. How can we make that starting point evolve to deal with those concerns.

So an example, I don’t like the asset pipeline, I have an … that I've implemented. There's a lot of concern about the asset pipeline for a while because it was very common that people will boot Rails app in production, and it would require a JavaScript runtime. This is like by far, basically it was like a blocker for 3.1 shipping for many of us. We’ve found an answer which is basically to have a manifest while get emitted. And the reason why that was happening was because Rails would have to regenerate all the files to know in memory what the text [unintelligible].

So, the conclusion was that we should, when we generate the apps, we should dump the manifest file that has all that [unintelligible] so that Rails in production mode, does not need to boot up Sprockets. So that was like an example of everyone hates the asset pipeline. Okay, what is actually the problem? And so like DHH was like, “What is actually the problem?” Well, you'll want JavaScript runtime. What is causing that? What in Sprockets was actually making that happen? How do we actually get to the bottom of that. I think that is very useful. I think that style of leadership is helpful.

Yeah. I think that the big fumble around there was that, it preceded so far, and it really required a large amount of community feedback.

I should be clear. I don’t like it and I wish it was not on Rails 3.1. But I think that the things that were most problematic, like you could not push a Rails 3.1 app at heroku at all. Like basically, it would have been easy for us to get in trenched into, “We hate the asset pipeline. We love the asset pipeline. Okay, sorry, it's going in.” Cool story. Like that’s like sort of the normal, when people get in trenched it's easy to end up there.

And again, I am actually very unhappy with the fact that the asset pipeline’s in. I think it's not baked. I think it needs more effort, and I think conceptually there are things that are not correct about it, but I think the fact that we took a step back and said, “Okay, what are the biggest problems? What are the things that are actually causing the most pain right now, and how do we make sure that even though we don’t like the asset pipeline , we get them resolved.”

José, me, Aaron all wrote patches to fix the asset pipeline to resolve the biggest issues. And I think that that’s [unintelligible] do project, even when I'm open about that. There's a lot of disagreement here, basically, what we should not have done, but sometimes happens with open source, and say, we don’t like the asset pipeline and we'll let it suck. But let it suck so much that everyone is like, oh my god this is horrible. And then we'll win, right? So Ruby gems did this, right? Ruby gems did this with warnings. So Ruby gems admitted tons of warnings. What Ruby gems is essentially doing is weaponizing users against gem authors, right? You should not be doing this, so…

Handing out pitch forks and torches, right?

And I think the right thing is to say, “we are the Rails core team. We have users. We should try to make sure that the users do not unnecessarily have pain, just so we could prove a point,” right?

I think we should just choose champions, dress them in armor, give them swords; whoever comes out alive, is the winner.

Agreed.

That worked for thousands of years.

It did. It's a proven system. Alright, well I have to cut this off, but we probably ought to get to the picks especially since we have some people with time constraints.

However, you can continue this conversation on another podcast.

That’s right. We are going to be doing the JavaScript Jabber podcast later this afternoon.

You know, that Yehuda guy sounds like he really knows what he’s talking about.

Yeah.

I should say I'm really excited about this podcast. I've never really done... So I did a radio show on college which was fun. I think we had like three users. It was about local student government politics, which was probably the lamest possible thing. But I think there's the general environment around JavaScript is direly in need of people actually talking out loud, not in blog post but to each other about what’s going on, and I think it will help a lot with some of the debates that are ongoing, so I encourage people to listen.

I'm excited about it for the same reason I got excited about this one, and that is that I get to spend an hour or maybe a little longer talking to people who know way more about this stuff than I do.

So Yehuda, I have a quick question for you about JavaScript. And this is a tl;dr, because it's Ruby Rogues and what not. So, 30 second answer, you can give the longer answer on the JavaScript Jabber’s. CoffeeScript, good idea or awesome idea? [Laughter]

That question is not at all biased. [Laughter]

On a scale from ten to fifteen…

CoffeeScript is addressing real pain points. I use it in a very large project. There are things about how… it basically ends up being hodgepodge features that…re Ruby has a bunch of features that are well thought out in terms of how they interact with each other, CoffeeScript often does not. And there are problems with CoffeeScript that results in bugs that I don’t mean debugging bugs, I mean, bugs where you typed the wrong thing by mistake, because the syntax is not sensible.

Yeah, surprisingly enough, there's no ternary operator.

Yeah it's just… the most common for me is I've forget to put parentheses around functions that have no…

You figured to put the parentheses at the end of your function pointer?

Yeah, exactly and that’s the biggest one, but there's a number of things like that, how functions call hashes and what not.

Cool, thanks.

So, into the picks. Avdi, go ahead and go first.

Alright, let’s see. I've been doing a fair amount of JavaScript the past week or two, so two books have been helping me out a lot. The jQuery Cookbook from O'Reilly and also, I started digging into the JavaScript cookbook. And for the stuff I've been doing, the cookbook format has been really nice, because I can pretty much just look at the specific common operation that I never learned, because I don’t regularly do tons of JavaScript and see a succinct little blur about how to do it right. So jQuery and JavaScript Cookbooks from O'Reilly.

And for a less programmer-oriented pick. As I kid, I never really read comic books, so you can all take away my nerd card right now. And later on, as I started like acquiescing to my friends who said Watchmen is awesome and Sandman is awesome and stuff like that, I started trying to read those, I realize that I have some kind of mental bug which prevents me from reading comic books, because I basically get visually overwhelmed by everything that's on the page, as a sort of reaction to that, I sort of wind up just tracking from text bubble to text bubble automatically, without actually seeing the pictures.

And the other day, I downloaded an app called Comixology onto my phone and my tablet, and tried reading a comic book that way. And they have this technology that was really invented for viewing comics on a phone, which basically just automatically retracts from frame to frame, so it's sort of moves the view over and zooms in or out as appropriate, to give you what you need for just one frame. And I discovered that that actually works well with my little mental flaw, and enables me to enjoy it a lot better than I can enjoy the printed page comics. So Comixology.

Wow. That makes me cry.

It's such a sad story.

[Laughs] We should start a foundation for my affliction.

[Chuckles] Geez. One of these days, I'm going to sit you down with my compilation of watchmen, and show you how the layouts across two facing pages in the correspondents of the panels and all that really adds a lot of reading.

Trust me, I understand… I mean like, I did read through the paper version of Watchmen and I really enjoyed it. And I understand how some of those layouts are brilliant. I've realized that if I'm not paying attention, just the way my mind works, because there are so much going on the page, I'll lose the page completely and just look the text.

Okay, fair enough.

Alright, David?

I just have one pick today. This is tangentially related to JavaScript, very much related to CSS and styling. There is a project out on GitHub called msie2vboxby Max Manders. And I will paste that on our show notes. And what this is there's a couple… I need to write a blog post about how to set this up, because it's not entirely just straight out of the box. The instructions are really good on the page, however. But what this does is it uses virtual box, which is free, to download Microsoft virtual testing client, which gives you a version of xp that’s authorizable and usable for testing. And it gives you a copy of Internet Explorer version 6, 7 or 8 and I think there's also a version coming out for IE9. And it lets you test how your site is going to look in the various Internet Explorer. And I found it very, very useful as I'm doing development right now in Chrome and Safari, that 80% of the web traffic out there is still an Internet Explorer or 40% or whatever. I can't remember. It's some number. 87.2% of all percentages are just wild guesses anyway, right?

So if you wanna see what your site looks like in internet explorer but you’re on Linux and you’re on a Mac and you really don’t wanna go touch a windows machine. This is a thing that gives you… it's a one line command. You can type msie2vbox -b which does it boot the virtual machine, and windows boots up in a little window on your Mac, and you can get into internet explorer, and go to the site and see where it looks like it's really awesome.

That actually sounds like something I could use, because I actually went and bought windows, so that I can test window stuff, but then I have to use parallels or what not.

Yeah.

James, what are your picks?

So I've got a couple of Ruby community picks today. First of all, the Rails Conf call for proposals is up. So Rails Conf is going to be on Austin this year, which is a great little town if you haven’t gone down to Austin in a while. I loved going down there. Actually, one of my favorite things about going to Austin is I try to eat outside, like the entire time I'm there. And that’s because they usually have great weather, and it has the largest urban bat population in the world, so the bat eats all the bugs. So it's great, you should go to Austin, you should eat outside and check it out. Anyways, I think the Rogues are planning to make a trip down the Rails conf this year, so you can come down and hang out with us, see us. And if you are inclined, you should make a proposal for what you’d like to talk about at Rails Conf.

Road trip!

Road trip, that’s right. So anyways, I wanted to put that out. Also, it's not an O'Reilly event this year. It's back to bring just Ruby central. So, I find that kind of cool that we’re taking care of it ourselves and stuff. So I am looking forward to Rails conf this year, and I think others should do the same.

The other community pick I wanted to bring up is Ruby Heroes is up, it's time for yearly elections and that’s where we nominate all the people that are not… so you can't nominate DHH, because DHH gets plenty of recognition for being DHH. Instead, we nominate the people who don’t receive as much recognition as they should in our community. And talk about why they are great. And there's no fame or fortune involved here. They get an award, that’s given to them, but it's still nice for the community to say, “Hey, we recognize that you are very helpful and stuff.” And this is the time to bring it up because Yehuda Katz won Ruby Hero award in the very first year that it was available. And so, and other people on this podcast are probably pretty deserving, so I recommend that you go and nominate them.

Is there an API I can go to find out how many people have voted that I be permanently banned?

[Chuckles] I don’t know. That’s a good question.

I'm working on that.

We've decided that David Brady probably isn’t eligible until they change the name to ‘Ruby Jokers’. Anyways, go nominate your favorite people in the community, and tell why they are cool and get them listed.

Somebody should probably point out that James is a Ruby Hero as well, are you not?

I won the same year Yehuda did, yes.

But did you win more?

[Chuckles] No. No, definitely not. It's like in that year, it's me, Ryan Bates, Yehuda Katz. I'm like the Waldo guy. The one that doesn't fit, you know. [Laughter]

We are laughing because that’s not entirely true. [Chuckles]

So anyways, go nominate. Those are my picks.

Alright. Josh, what are your picks?

I've been using this cool little application on my iPhone recently, it's called Voxer. And they call it a walkie talkie for your phone. I explained that to a friend, and he’s like, “Oh my god, is it like that Nextel push to talk thing?” And it has a very small piece of that to it, but really, what I think of it is as texting using voice. And so it's like a phone chat, but it's asynchronous, so you just record a few seconds of speech, and then it gets sent off to your friend, and they can respond to it on their schedule, rather than having to respond instantly because you are on the phone synchronously. And it's really cool. I've been liking it. I don’t really know if I trust the way they handle their information and privacy things like that, so I'm going to put a caveat on this. I'm not fully endorsing it, I just think it's a pretty cool concept, and I'm finding it useful. So that’s a mixed review, I guess. I think it's worth checking out.

The other thing that I will endorse whole heartedly is Ryan Fait’s StickyFooter. So I was just pointing this out to couple of people recently, so I figured it's worth pointing everybody to. This has been around for a while. If you go to a website where the footer has like a lot of good stuff in it and maybe it's not too big. Like the GitHub footer is really tall; it takes up half the browser window if you scroll all the way to the bottom. And that’s not a good thing to make. Stick to the bottom of the window all the time, but there's some pages where you just have 50 or 60 pixels at the bottom of the screen that are useful to have around all the time. You want that to stick to the bottom the window, so that if you have short content on the page, your footer isn’t up near the top of the window. So this is just a cool little bit of markup in CSS to make that happen. It's at ryanfait.com. And we'll put that in the show notes. I've been using this on a bunch of different projects for years, and it has slightly more markup requirements. You have to put like an extra div in the markup to get it to work, but I find the CSS rules are much simpler than the competing alternatives, so this is the one that I prefer.

And then I've one little thing for the podcast world. It's called audioname.com. And Chuck, you’ll love this. This is a thing for you can just go to this website and speak your name into your microphone and upload it. Upload you, saying your own name and then the next time you go on like… they refer to you on Ruby five or something like that. Then you’ll have a correct pronunciation of your name somewhere they can easily find it and pronounce your name correctly.

Yay! Maybe that means I get to be James Edward Gray II, instead of James Edward Gray lll, or lV

I thought it was James Edward Gray i-i

So I'm going to go in there right now and make sure that it's pronounced correctly, your worship.

Your worship.

So that’s it for me, guys.

A-v-d-i spells ‘your excellency.’ Alright, Yehuda.

So I have three things. First of all, maybe this is not true about the people listens to this podcast, but I noticed lately that a lot of people don’t actually really know how to use the chrome debugger, so the Chrome debugger has stack traces and you can like get a debug on exception. And you can see the trace, you can go in, you can use the console from any point in the trace, you can see the local variables blah, blah, blah. Again, I thought I through everyone knew this, but I recently discovered that many people do not, and so my workflow is heavy use of this and if you have exceptions in your JavaScript, you'll find this useful.

So two books, Lean Startup; a lot of people have definitely talked about this. Definitely read it. And actually if you are an entrepreneur, if you are trying to start company, where you are responsible for shipping things and actually have control over the process of doing that. And the 22 Immutable Laws of Branding is a good book for… it's the marketing book by the guys who came up with the concept of positioning. I found it… I sort of found religion in it in terms of marketing.

And then finally, I lost my iPhone at the airport, and ironically [unintelligible] had shipped me a windows 7…. I'm not going to pick windows 7, but I want to say something about it. So [unintelligible] has shipped me this windows 7, because I signed up for that. Aside from the fact that it requires me to use internet explorer and Bing, does not have an exchange support, which is a blocker for Google. I actually found it to be a... It is clearly… the UI is as good as the iPhone. And obviously very different, but I can't… it's not the android where I'm constantly complaining about the UI. And the overall… the amount of thought that’s gone into it is good. Like I said though, the needing to use internet explorer for all web browsing and the lack of exchange support, which is shocking, probably will mean that I will not use it forever, but I've been using it for since I got back from Cabo, and I've been pleasantly surprised; I'm able to use it without feeling the need to run to the apple store to replace my iPhone.

Cool. Of course you have to put that in there, right? “I just got back from Cabo.” Poor guy.

Just to be clear, disclaimer, I received the phone for free. I am essentially playing right into their hands.

Alright. Well, it looks like left to do picks.

Dave wants a second round.

I forgot to mention that Gary Bernhardt just posted a lightning talk from Code Mash 2012.

Yes. This is great.

It's titled ‘Wat’, and it is falling down hilarious. You need to go watch if you haven't seen it.

Go watch it. You will be laughing out loud.

Yes, absolutely worth it.

You know, my roommate actually had to check up on me to make sure I wasn’t having a seizure when I was watching it. [Laughter]

Yes!

Alright, so I have a couple of picks. The first one is one that one of the local guys here… He works for the company that puts this together, but I thought it was pretty cool. So it's a QR code generator, and what it does is it put in all your information, your email address, your websites, all that stuff. And then you can pick three social networks, and then it’ll wrap all that up into really small QR code, and it will make that all work really well. I think it's pretty cool. So anyway, I had a little QR code made up, but I'm probably going to put it on my business card and stuff, just so people can scan it right to their phone or what have you. So you can get that at scan.me. And like I said, I'll put a link up because it's their QR code generator URL.

Another thing that I've been doing just to get ready for the JavaScript Jabber podcast. I don’t feel like I have as much expertise in JavaScript as I do in Ruby. And so, I felt like I needed to maybe get a little bit better with it, and so I've been reading the JavaScript The Good Parts. And that’s by Douglas Crockford. And it's just been really enlightening. A lot of the stuff that he goes over, I

already knew, but there have been a couple of things that I wasn’t quite clear on. I had a general understanding of prototypal inheritance, but he explained it in a little different way than I've seen it before. And anyway, it was really good. So, it kind of, “Oh, okay I can think about it that way too, and it makes some sense.” So anyway, those are my two picks.

And finally, I'll put a link in and my third pick will be for JavaScript Jabber. Real simple JavaScriptJabber.com and hopefully you can pick that up as soon we it into iTunes. And I hope you enjoy it.

Real quick, just to wrap things up. We are going to be reading Land of Lisp for our Book Club that will be in about a month in February 22nd. Also this podcast is sponsored by New Relic, and so I just like to thank and acknowledge them. Their tool is awesome for figuring out what's going on in your app. And so, go check them out. We are going to have a link up on the website. And if you click that link, then it says it came from us, but if you don’t wanna go to the website, just go to newrelic.com. And other than that, leave us a review in iTunes and we will see you next week!