In this book club episode, the Rogues talk about The Rails View with John Athayde and Bruce Williams.

Special Guests: Bruce Williams and John Athayde .

 

Keep...it...goin'!

Hey everybody, and welcome to Episode 104 of the Ruby Rogues podcast. This week on our panel, we have Katrina Owen.

Hello.

Josh Susser.

Good morning from San Francisco.

James Edward Gray.

Good morning from Oklahoma where it is now over 80 degrees.

I’m Charles Max Wood from DevChat.tv. And this week, we have two special guests. Our first guest is Bruce Williams.

Hello from Portland, Oregon where it’s finally sunny.

And our other guest is John Athayde.

Hello from outside of DC where we’re waiting for the Cicada invasion.

Awesome. So, I'm wondering if you guys can briefly introduce your selves. We’ll have John go first.

I work at LivingSocial. I run the small team that does all of the UX and frontend code for our internal applications. I come from an architecture background of building variety and I've got a lot of UX and Rails stuff over the last almost -- Rails since 2006-ish. And I've been doing design and print stuff since ’95 or so. And I've been working with Bruce since the InfoEther days and then we both got acquired into LivingSocial.

Nice. And Bruce, you want to introduce your self?

Sure. As John said, we used to work together at InfoEther. I've been using Ruby since 2001, back when I met Chad and Dave and a few others in an IRC chat room that had very few people in it. And since then, I've been having a blast. Like John said, I work at LivingSocial with him now as a Technical Director on the merchant side which means I write code, but not all the time. And I've been doing view stuff in the last few years with Rails. I've been using Rails since it came out. And in a past life, I was a language translator for the government which is a completely different field.

But for some reasons, somewhat informs how I approach software development.

Cool. Alright. So, the reason we have you here is because for our Book Club Book, we read ‘The

Rails View’. To start us off, I'm a little bit curious as to why you chose to write a book about the Rails View. I mean, most of the technologies involved such as the CSS and HTML are pretty well understood. So, how did you come up with the idea of kind of attacking this angle?

Speak for yourself, I don’t understand them.

I was about to say the same thing.

I would love to say that I've seen evidence that it’s true. I think that people understand them individually. I certainly think that there's a large community of people that care lot about HTML and CSS together. We mix it in with Rails and you mix it with software developers that think of drying up the Ruby code. But once they start to get into the view layer, they start to get a little bit messy, start to drop things in various places and let other people clean it up a lot of the time. I start to forget about things like patterns in a good way. It felt like that it was needed. I mean, both John and I have talked about the subject for the last few years and those talks have been full every time of people with questions. So, it seemed like it made sense for us.

It did actually start as I originally pitched a book about HTML and CSS to PragProg. And it turned out that Brian Hogan had already started writing one. And so, I've made up a talk for Rails Conf in Baltimore which was basically the genesis of the book. And it was Standing Room Only. I'm like, “Okay. I think people might be interested in this.”

It’s funny you bring up Brian Hogan. I'm actually going to be talking to him in about two hours on JavaScript Jabber.

Oh, nice.

And we’re talking about building accessible websites.

Brian was our editor.

Oh, really? [Chuckles]

It worked out quite well actually, yeah.

I think one of the things that kind of hit me heavy and hard when I started reading ‘The Rails View’ was how little thought I had put into how complex it is and how like there are so many technologies that meet in that one place. You have the HTML and the CSS and the JavaScript. I mean, those are the basic ones. But then in ‘The Rails View’, you also have the ERb and the Haml. And you might end up with the XML builder and the JSON builders of various flavors. And then, you have the Sass and Compass and the asset pipeline and all of the various templating languages ERb, Haml, I probably mentioned all of that already. It’s an overwhelming amount of technologies in one space and it hadn’t really occurred to me how complex it is.

It’s kind of funny. It’s like we talk about the presentation layer, but the presentation layer is actually a ton of little layers within itself.

The whole time I was sitting here, listening to Katrina talk, nodding my head and thinking, “How the heck did I get myself into this?” [Laughter]

When I read the book, I thought, “Why is this called ‘The Rails View’? It should have been called like, ‘How to Do Awesome Frontend Web Development when You're Writing a Rails Application’.”

That’s an interesting point.

[Inaudible] about renaming that.

Yeah. It’s interesting because I saw the title and I thought, “Oh, this is all about tricks you can do when programming the view system in Rails.” And I thought, “Oh, we’ll get some custom form builders and maybe some form objects.” But no, you started with like CSS and HTML and HTML5 and it was such a broad range of topics that you went through in the book. It was not at all what I was expecting but it was definitely a nice surprise.

Yes. It’s interesting that starting out the beginning part is hard especially when you’ve given talks in the past. We’ve had some pushback from people that this starts too slow. We’ve got too much HTML, too much CSS. But I think people forget how often people are missing significant chunks of that knowledge and how important it is to have a firm foundation before you start to play with the rest of it. It’s really easy to get too deep too fast.

Yeah. I actually read this book quite a while ago. I think I was maybe the first one that read it in our group. And I ended up talking about it in a talk I gave, ‘Ten Things You Didn’t Know Rails Can Do’. Several of the examples in that talk were actually pulled from this book. In fact, the cover slide on Confreaks, I just basically picked a random slide. And if you look at the lower left hand corner, it says, ‘From The Rails View’. So, that shows you how often it popped up. But when I read this book, it was before I looked into HTML5 at all seriously and you have kind of a light intro to HTML5 and some of the concepts. So, this was like my first exposure to that even though I’d do this kind of stuff kind of a lot.

And the thing I've noticed working just in so many different apps, I see so many people that from the Github, these tables has turned into the, “Well, I’ll just put div and spam in it because I don’t know what to use and I'm afraid that I’ll use the wrong things.” So, I know what I did is the least offensive of all these items I can choose. And every talk I give, I go up and there's a great HTML5 which element to use flowchart from HTML5.dir and I put that up and there's also I think the HTML5 Periodic Table of Elements which has links to all the documentation. And I've been doing this for a long time and there's ones that I don’t even know how to use. There's easily 100 different tags to start with.

Yes.

So, I'm curious how you're doing a discussion of HTML and HTML5 in the context of Rails, change the way that you approach that because there's been a bunch of discussions on HTML5 that I've read in the last couple of years. But this was -- maybe you should talk about it rather than me talking about it, your approach to like things that you talked about within HTML5 and like the path through it.

Yeah. It was difficult. I think our starting point was probably forms more than anything else because there's been a lot added around there. And we’ve got a pretty large chapter in the book that focuses on forms. So, that kind of came at the forefront. Back when we wrote the book, there was very little support for the new HTML5 tags in Rails. Let alone, some of the other parts of the book that had to be kind of rewritten as new things came out possibly as you do. I mean, we struggled with it a lot early on talking about it too much, talking about it too little. So, we tried to focus on the tags that we were planning on using direct the rest of the book with a focus on forms and kind of an array of elements. And it certainly did change -- I mean, there's a definite semantic taste to the book. We try to push the semantics side of the argument as much as could because I think that it appeals a lot to software developers like ourselves who care about names in a Ruby code, so why don’t we care about names in a writing markup and that was something that really affected us.

Yeah. I’d say that came through. I actually have a note about how I liked the focus on good design especially semantic tags and stuff. And we should probably say that with your HTML5 kind of heavy intro, you do this show how do these things like Modernizr and stuff so that you can just kind of count on this modern approach.

Modernizr is such a powerful tool. We didn’t really go into too much depth in it but the real power to me lies when you start doing stuff in where you don’t know who the end user is but you want to use something even cool. Let’s say, the geo-location in HTML5. You can actually sit there and detect if it has it, do-axe. It’s the yepnope.js library is kind of the core of Modernizr. So, it’s something that’s really powerful to let you have great fallbacks for things that don’t work. Sure, the polyfills and stuff are fine. I’ve got great HTML5 elements in IE now but getting into that, how do I handle things that I don’t expect or that people don’t have if they’ve turned it off or it’s broken or something like that.

That, to me, is really where Modernizr can save your bacon or make your app really great.

I think one of the things that the book covered really well was that these are technologies that, okay they are in many ways young, but people have been struggling with a lot of this for a very long time. There are a lot of really good solutions that help you, sort of give you a clean slate, a solid foundation that you can build on. So, don’t try to reinvent it, really don’t.

There were actually a lot of different technologies or software libraries or whatever you want to call them, discussed in the book. You started with ERb, and you talked about Haml, Sass, CSS, Capybara, Vanity, Cucumber….

Selenium…

Yeah, Selenium, there was just like this ridiculous set of -- it’s like if we just named all of them, I don’t know how many it would be. It would be over two dozens easily. You’ve got jQuery, jQuery Mobile. It’s like everything. In some sense, it’s overwhelming, but it was also I think really interesting to see how it didn’t have to become -- just because you’re using factory_girl in one part of your application, it wasn’t like, “Oh, here we have to convert everything in our application to use this new technology.” I thought it was nice how you just sort of dropped stuff in and showed how you could ease into taking advantage of that piece of technology without having to make ridiculous changes to what you were already doing in the application.

And I know for me that comes from having to do that in real life. I work on a really big legacy app most of the time and I think there is no such thing as the great rewrite, it will not happen. It’s just not a possible solution. So, how can I use these new tools without having to throw the baby out with the bath water? So, that’s definitely something that influenced us moving in is our day to day work.

I have to ask though with adding new technologies in and then just moving ahead and using them, are you afraid that some of your older code will be inconsistent with the new code?

Oh, there’s definitely issues where we’ve got whole swats of the app that are kind of older code and newer code in the view, at least with the stuff I’m working on today. And we’ve kind of been pushing, it’s kind of just like refactoring passes is something we’ve been doing a lot lately. So, instead of saying, “I’m going to make this one whole section the most incredible thing ever and everything else is still horrible,” I’m just going to go through and I’m going to just do a little bit of readability refactoring. So, I’m going to spend my Friday clean up, I’m just going to do readability refactoring, and get one whole pass through the app and bring everything up and float all those boats. Then I’m going to say, “Okay, here’s the next pass I’m going to do.” This may take a little longer to see especially when we’re doing UI changes, that’s the kind of stuff where you have to worry about, “Okay, I’m going to break some tests here because I’m changing a div to this, or I’m renaming ID’s,” or things of that nature that were just poorly named in the first place. That’s where things get kind of corrupting. But I found it’s really nice to be able to go in and just break things into partials, where you’ve got a 2,000 line ERb file that just needs to be broken up and cleaned up.

Please tell me that you’ve never had a 2,000 line ERb file.

I’ve had numerous 2,000 line ERb files. They are no more, but I have had numerous ones that I’ve worked through.

Yeah, they exist, they’re pretty gross.

They’re not gross. They started off as something simple. And then as something grows very quickly, all these things just get tacked on and somebody’s like, “We’ll get to that later.” And nobody gets to that later because…

Honestly a 2,000 line anything is pretty gross.

Exactly.

Here, you’re talking languages so that makes it even worse.

Yes. So speaking of the big rewrite, the book has been out for a year or something like that?

It’s 18 months now.

Okay. So, this kind of technological landscape is a bit of a moving target. And I’m curious, like if you were going to do a revision now, what are the things that you would most want to change about it?

Yeah. I mean, things have definitely changed. I mean, we’re talking about Rails 4.rc being out now as well, just recently. I think there’s a whole slew of new technologies that we’d probably want to focus on. I know that’s scary speaking that we already talked about a whole slew of them, but things have changed somewhat. There’s things like Turbo Links, there’s caching, changes in Rails specifically. There are certain libraries that we wouldn’t want to focus on as much. For instance, Vanity, we might not want to focus on as much. And there are some other pieces that we think, based on feedback, we’d want to tackle, based on the way that people are constantly evolving in this space. I think the focus on markup will always be there, I think there’s more things that we can take for granted though because when we first wrote this book, at first, the asset pipeline wasn’t even there. We actually had to rewrite a good chunk of the book because the asset pipeline arrived. And suddenly, we had to explain that and what that meant. Then also, pumped up things like CoffeeScript. And guess what? Now, we’re going to talk about CoffeeScript in more detail because it’s important. Some of those things are more of a given now, so we would have to focus on them less in certain ways. But yeah, it’s definitely something that we’re looking at.

So, there is going to be a new version of the book coming out someday, soon-ish?

We hope. John and I are thinking about that a lot right now and we’ll see what happens. We certainly think that with Rails 4, there’s some interesting things. The book, that’s not to say of course, that people should not run out immediately and purchase the book because (a) that would be great for my coffee budget but also because there’s a lot of good stuff in it. But there’s some things here that we think people should know about and would be very helpful.

Also, Pragmatic Programmers have a pretty good upgrade policy for new editions of books, right?

That’s correct, yes.

So, if you buy it now, you can get the new edition either for free, or for cheap.

Yeah.

Bruce, you mentioned CoffeeScript. One of the questions I had reading the book, you had a really, I think almost ideal intro for SCSS in the book, it was just the right amount to get you into it without going too overboard and stuff. And I was kind of surprised not to see a similar intro level for CoffeeScript. Why that decision?

Yeah. So, I think there’s a big difference between the two. One of which is just kind of the [inaudible] complete nature of CoffeeScript and how daunting that can be. I know a lot of Rails developers especially that are great at Ruby but not great at JavaScript and not even slightly great at JavaScript, just enough to be able to kind of wire in some jQuery plug-ins which I think is kind of par for the course in some ways. I think it was a less complete introduction for the simple reason that it was a much larger topic. There’s already been books on the subject, there’s plenty of JavaScript books out there. We didn’t want to break that in too deeply. There’s so many questions around that space and there’s so much persuasion that you have to do around, you should use CoffeeScript. We talk about some controversial topics, that’s one of them. But yeah, it was just a decision we had to make. Like Josh said, there’s a lot of material in the book, so we didn’t want to focus too heavily on that.

So, there’s a little bit of, you do some testing discussion using Selenium, and Capybara, and Cucumber to drive some of the stuff that you’re talking about in the JavaScript chapter. But you don’t have any discussion of sort of JavaScript unit testing, as in like using Jasmine. How did you decide what level you wanted to do that testing at? I can see how like a big discussion of CoffeeScript might not be appropriate for the book because it’s not really a View related technology as much as something else. Was that the same point about Jasmine that it just wasn’t as good a fit for the problem domain?

Yeah. I think that was part of it. I think Jasmine tests tend to be very, very focused on that piece of the layer, the layer of the layer. Capybara’s got a little bit more crossover. And it’s easier, I think, to talk to Rails developers because they have immediate knowledge of it because it’s basically been around for a bit. Jasmine is much more focused obviously on the [inaudible] line of sight. But yeah, it was just a call we had to make for the length of the book really. I’m really very interested in that space. I’m interested in being able to run that from Rake with the rest of your tests doing CI with it.

It was just a call we had to make as we were putting the book together.

Okay.

Coming from how we were going to build the book, the book ended up being more of kind of a survey book and then your intro class you would take in College or something and then you would drill into each of these. And I know that’s probably a big goal that does exist for any aspiring writers out there is a Rails JavaScript book. Steve Klabnik did a great job writing up some documentation in the repo now. So, there’s actually good JavaScript documentation but that’s still a big question. And there’s so many things that changed there. I mean, since we wrote the book, Ember’s gone 1.0, Angular came out, and it’s one of those things like how far do we drill down into any of those? And what do you give up in order to do that?

Right. And then, there’s the big question of, how client side do you want to go in a Rails book? Being that there’s a lot, there’s several camps there. I mean, we like to talk about controversy in certain places in the book, and that’s certainly another one we could talk about is how rich do you want the client layer to be?

I do, just so we don’t ping at that you don’t have any JavaScript coverage in the book, that’s certainly not true. I thought the coverage of jQuery’s UJS for Rails was actually really good. It was nice to hear. I think we all kind of just use that and take it for granted but you actually laid out what it is and that was great.

There were some technologies I thought that, like you said, it’s sort of a survey of technologies. And I liked, you showed how simple it was to use some of these technologies, you know from Capybara to SCSS to factory_girl. What I felt was just maybe a little weak was there was very little discussion about the tradeoffs for making the choice to use one of those technologies. For instance, factory_girl was presented as, “Oh, here’s a nice way to be able to generate your test fixtures programmatically.” And that was it. There was no discussion about what the potential costs of using something like factory_girl was and what it was good for and where maybe it falls over and you shouldn’t be using it. I understand that’s a whole big mess to deal with on its own and that’s potentially a whole chapter of a book talking about those tradeoffs. But it seemed like there was just, in some cases, there wasn’t really any of that discussion.

Well, I think part of -- so, factory_girl as an example. The book is called ‘The Rails View’. So, there’s a challenge in general with writing a book about a layer of a framework because you have to build an app in it. And when you build an app, you’re out of necessity going to have to use pieces that are not focused on that layer. So, when we do go into discussions of tradeoffs, I think we focused on those in portions of the application that were wholly View related. So we talk, for instance, more in forums about things like that, about why you might want to use this. We actually, in a few places, we build the solution ourselves in kind of a vanilla way. Forums is a good example. And then, pull in something else later to show, “Yes, see? That’s how that works.” Now, we can use these things here to make that easier. So, I think some of the tradeoffs here are already selfevident because we’ve just worked through the problem. But yeah, things like factory_girl, I agree there definitely are tradeoffs even though I generally use factory_girl myself. But it was just an issue of, how many inches are we going to give this particular pro and con in a book that’s about Views.

Yeah. I think that in general, it didn’t seem like there was a whole lot missing there. I think probably the one place where it got my hackles up was using Cucumber for doing the JavaScript testing with Capybara. I think it was like a nice little survey of, “Here’s an example of using Cucumber.” But there’s one of those controversial topics is Cucumber versus just like Capybara in RSpec.

Right.

So, how did you decide, “Oh, this is a good place to use Cucumber,” even though we could be using one fewer technology to do so.

I think part of it is where our heads are at, at any given time. I think we’ve all kind of evolved in the View layer. I know that I have. I’ve made decisions that are different, actually probably now than they would have 18 months ago to some degree. That may be one of them actually. Also, you have to keep in mind I’m a language nerd so there was an example there where I could use more language. And so obviously, I’m going to throw that at people. [Laughter]

I think it was great to have an example of what it looked like. So, for people who are making those choices about, “Oh, should I be using Cucumber,” they can see a great example of what it looks like. So, that was valuable on its own.

And I think it does depend on who you’re talking to as well. It’s, once again, it’s difficult in the book to target multiple types of people and there are definitely multiple types of people looking at the book. You’ve got people that are developers, you have people who are designers, and you’ve got people that are just new in general to software development. And Cucumber is -- there’s a lot of discussion about whether Gherkin is a good fit, within a business or within a software development team or a software development team plus product managers. And you know, that’s a fair point. It’s something as a survey book that we felt we should probably hit. I think using Capybara directly from RSpec or something else is completely reasonable and it’s something I do as a software developer when I don’t have things that I want to necessarily copy and paste for someone else for them to look at.

You did mention there about the audience of the book, how did you decide who you were targeting? I mean, were you targeting the developer who does a little bit of frontend integration?

Were you targeting primarily the frontend developer? Which audience were you appealing to most?

Well, John can speak to this a little bit. Like really early on when we were looking at it, we were trying to focus it more on both the designers and then the developers. But you start to lose -- it was very difficult to go deep at all on the Ruby side when you’re talking to people. So, I think we were probably mixing it quite a bit between frontend developers who maybe wanted to go a little bit deeper in terms of code because maybe they came at it from -- like we know several people for instance that came at software development from the design world and they were kind of moving over, but they were already writing code in Rails. And I think for me personally, the group of people that I most wanted to speak to was the software developer who spent some small amount of time in the View, but just enough time to really screw things up when they’re in there.

[Chuckles] That’s me. And yeah, I definitely felt like the book spoke to me. I mean, you have things in there like a side on how to select good CSS selectors and stuff like that and I thought you were talking straight to me.

One of the things that I talk with people as an example, what I think is a good practice for people that maybe don’t know what they’re doing. When I worked with Chad years ago, Chad Fowler and I used to work together just as a two-man software development team. Chad used to do really funny things like leave me. He would check in code and leave me blinking red, 24pt font texts on Views as a, “Go clean this up because I know that this needs help.” Which I actually thought was a very helpful practice for me.

I love that. [Laughter]

It would be everything horrible he could find, that he could make it obvious that this, “Yes, Bruce. I

know this is not right. Go fix this thing.” But there’s a bunch of people that don’t do that, they’re not even that helpful. What they do is they just go in there and it just kind of becomes a dumping ground. And we wanted to make them kind of morally aware that that’s not a good idea.

So, I have a question regarding HTML5 as some people may or may not be aware, the HTML5 specification is still a work in progress. Were you worried at all that things might shift or change as you wrote the book as far as the HTML5 spec goes?

I mean, things did shift and change across the board as we wrote the book. I remember sitting there with Bruce when David introduced the asset pipeline and he and I were like, “Yes!” And then, we realized that was half the book had to be rewritten. And it was like, “No!” But with HTML5, it is a constant moving target and I think the official date is something, you know, ten years from now to be officially done and accepted. And okay, we’re not going to not touch that. And with a lot of the things, I’ve actually seen more things have problems in the CSS side of things, for example with Flex Box, and Flexible Layout, and Grid Layout, that’s been a far more, sandy soil moving under your feet kind of thing as opposed to the HTML5 elements seem to be pretty solid. The other confusion is the HTML5 is now kind of the wrapper around seven or eight different technologies, including the HTML markup spec. So, we didn’t really get into anything like the web sockets or things like that at all become other options because there was not enough time to get into it. But it was definitely a concern. And I mean, that’s one of the things we’ve probably not been that great about is continuing to write articles on the blog. We’ve just both been slammed from employment perspective. But there’s a lot of little stuff that comes up. And I try and link to it on Twitter and things like that when it happens. There’s not too much has changed on the HTML side but the CSS for sure. Flex Box is actually -- if you wrote Flex Box a year ago, you’d have to rewrite it now, it’s changed entirely.

I thought it was really nice to see that you didn’t shy away from complicated topics. A couple of examples like the discussion of IE versions and how to detect those and fonts, and how to handle those versus including our hosted solutions or things like that. I thought you went into those fairly well and me again, maybe it’s because I am a backend developer who’s trying to get better at the other side. It was very helpful to me to understand the complexities of those issues.

I have a couple of specific questions about content in the book. So, I thought the SCSS examples of CSS, I liked the approach. I thought everything was pretty good. The one thing I thought could have used dimension was in structuring your CSS, you did a lot of deep nesting. And when you generate the actual CSS from that, you get some pretty deep selectors and that can cause performance problems if you go overboard with that. And so, you nest, nest, nest and suddenly you have a selector that’s five or six levels deep when you really only need one selector. You only need the class tag on, or the class on it.

Yeah. I don’t think we get to the level of five or six in the book, but you know, it’s definitely true. I think one of the reasons we focused on -- I don’t know if ‘focus’ is the right word. But we definitely talked through nesting is the fact that it’s not something that CSS supports itself. So, it was kind of important to highlight it. It’s definitely true. John can speak more to this because we’ve had long discussions about whether or not I, for instance, should use IDs or classes. Let alone whether or not how deep you want to make your selectors. People do definitely go overboard with SCCS selectors. That’s definitely true.

And it also depends where you’re deploying. For example, we work on a lot of internal stuff and we’re deploying to the newest Chrome and it’s over a WAN. They’re on a 50Megabit line. So, for people using those apps, there’s not as much of a performance issue. I could kind of abuse SCSS and really side towards developer happiness and clarity of what’s going on as opposed to having to go nuts on the optimization. Optimization is a huge important thing though, and it is worth looking at especially with things we didn’t get into too much with Extends. We mention it. And now, silent extends have come out too. There’s a lot of power there that really helps you optimize your SCSS. Also, I know Hampton showed off in Austin, the beginnings of libsass which basically is Sass in the C language as opposed to Ruby. So, it’s actually a library that’s running because they have somewhere, they have more than 50,000 lines of SCSS in some of the apps that he writes. And that’s something that really, really sped up their compile times and also, is going to make things a little better from just interacting with SCSS in your app. But with any app, you can write crappy CSS by hand too. You can go seven/eight levels deep. And it’s just a matter of not only thinking how does this look but what does this actually generate?

That was maybe one thing that the book felt maybe a little light on was the overall performance concerns of getting in there and minimizing the amount of assets and stuff. There were places where you went into it and they were really good. There was actually a really good discussion on Sprites, and what they are, why use them and stuff like that. But maybe overall, some of that performance concern which is really key these days. I mean, we’re all trying to get the request time down under a certain level and a lot of that has to do with cleaning up the frontend and making it as efficient as possible.

There’s actually a great talk from Ruby Australia, Keith Pitt and Mario Visic did. I don’t know if you guys saw that but it’s ‘Guide to Fast Websites’. It’s them walking through the actual optimization of one of their applications, one of their web apps. And they go how to get something from ten second load down to a second and a half load. It’s a really great talk. You actually walk through the steps with them and see. It’s a really complex topic too. And again, these tools are changing just as fast as everything else in the view is changing. So, we kind of talked about some of the stuff about looking at dead weight or some of those kind of options as things to look into and follow up on, but each one of these things could be a chapter. It’s very difficult to kind of say, “Where are we going to put the effort and the focus and keep it under 700 pages?” [Chuckles]

Yeah.

One of the things that I think is on the verge of becoming an important technique in Rails applications is using form objects. And you had a very nice discussion of how to build presenters and a couple takes on that, that worked pretty well. Have you guys done much with form objects? What do you think about that as an approach for handling some of the problems with dealing with forms and views?

Are you talking about form builders specifically?

Okay. So, the term ‘form object’ is so generic.

Right. The word ‘object’ tacked onto anything is generic.

[Chuckles] Yeah. It’s an object, object. I’ve used this technique a couple of times. I haven’t really flushed it out as much as I’d like to but I know several people who’ve done this where, it’s sort of like doing a presenter, but it’s sort of a plain old Ruby object that can act like an ActiveRecord model enough that you can interact with it with your form. But it’s not database backed and it might actually be an aggregate of a couple of different ActiveRecord models, or no models at all behind it.

I do that often with Active Model.

Yeah. There’s Active Model, there’s Active ATTR, there’s my own informal gem which I’m probably end-of-lifing right now. And I found that this is a really great way to take some stuff that you might put in a presenter and put it in some place that’s a little closer to the data layer. And also, it’s so much better than using the nested attributes and mass assignments.

Agree. I completely agree with you, Josh. That kind of approach, especially at the aggregate level because you end up with things like batches, for instance, let’s say it’s a batch upload form or some kind of batch aggregation result or something like that. Anytime that I think it can make sense for you to treat something like a resource and to model it, like to actually do the data modeling, you should do that. It certainly makes building the view much, much easier because otherwise, what you end up with is either a presenter that is really heavily view focused and really, what you’re talking about is the data. Or you end up with a wild slew of helpers that are trying to display something. Or you end up with just long chains of method calls inside of your form which specifically are already complex enough to be able to display something to create a form field. I totally agree. I think that’s important. I think form builders and form objects are something that people should focus on more when they’re building views.

Do you have a better name for form objects? You’re a book author. Do you have a good name for this?

I just generally refer to them as models. I think it’s just that there’s models that are database backed and there’s ones that are not. So, I don’t know if it’s important that we name them differently. I sometimes just refer to them as a resource object. But yeah, it’s tricky because even in a world of presenters, then you can talk about decorators, there’s no real firm opinion on what exactly that word means depending on who you ask. So yeah, it’s tricky. I get what you mean by form object though, target of the form.

Josh has a neat example there because it’s a data change that does actually end up being quite significant to the view layer as a whole.

I think that’s maybe the most important thing that somebody can do inside of a view is to model their data correctly. So, if you don’t model your data correctly, a lot of the time actually I discover that I haven’t modeled my data correctly when I start to build the view. And I’m like, “Actually, this is just not right. The composition is just not correct for this object or I’m using too many objects or too few objects here.” And sometimes, that change trickles all the way down to persistence, all the way down to the database and sometimes, it’s just something that you can handle at the Active Model of whatever gem that you want to us to be able to model the data.

What are the things, what are the signals that you see that tell you that, “Oh, I’ve done it wrong here.”

In the view?

Yeah.

[Chuckles] Well, there’s a lot of signals. But I think probably the context that it’s most obvious is within a form just because you see people use helpers to be able to pull data out of objects, if they even do that. Often times, it’s foo.bar.baz. But anytime you actually see what ends up being a query directly in the view, that really makes me wonder whether or not you’re screwing up. In the very least, that should be in some object, in some presenter or in some other object. So, that’s probably the clearest distinction is the number of periods that you have on a line really. If you take a look and see whether or not people are going deep to pull something out, then that makes sense. Or if they’re using a lot of very closely named helpers, so if they’re using a lot of helpers that all have the same prefix because they’re all about kind of the same thing but they haven’t modeled that as an object, or they’ve kind of grouped them as kind of a method category, then yeah, that’s a sign that somebody needs to break out and grow a real object. You just pick an object. The overhead is very, very small. That’s what Ruby does really, really well. So, take advantage of that.

Josh had another good example right of dealing with the nested form parameters, that’s usually a hand trade but the data layer doesn’t really fit how you’re trying to put in there.

Yeah. The other thing I think that these objects are good for is, in addition to the nested attributes, they’re also good for replacing the mass assignment protection in a way that I think that is more model-focused than the -- what’s it called in Rails 4?

Strong Parameters?

Yeah, the parameters, the Strong Parameters. I haven’t played with them enough to really see how they really work though in practice.

They’re much more focused on the actual individual application of the parameters instead of saying, “At a model layer, this is what the model handles.” I think that’s another important thing that I think people should really learn about Rails 4 is Strong Parameters because that has a lot of effects and you can use that from Rails 3 as well.

The book talked about formtastic and I was a big fan of formtastic for a little while and I’ve shifted over to using simple form primarily now.

I’ve done the same thing. I think that anything is better than nothing. So, it just depends on -- I think in a lot of different categories within this book, we realize a lot of this stuff just comes down to taste. As long as they’re doing something over just tossing stuff into the view, it’s a good idea. Formtastic is definitely more opinionated and it makes decisions that sometimes make designer -- I know working with John and with others, it’s trickier for them to fit into other designs, it just takes more work. Yeah, we talked about formtastic. I think it was at the time of writing, it was certainly the most complete. I think simple form has come along and it’s something that I probably use more frequently now because it’s less opinionated.

From a styling perspective, simple form, I love that I can actually go in there and change the pieces that generate the code. When I do an f.input, I can actually go in and say, “Okay. Now, I want f.input to generate this,” which allows me to really get detailed on how I’m going to style things. And then, you can pass in wrapper HTMLs. To me, it’s just a lot cleaner than how I had to do things with formtastic.

Right. From a use perspective, it’s not wildly different. So, I think the material we present, it’s still useful. It’s just that under the covers, there’s a lot of differences in output especially and how you can change those things.

Okay, cool.

So, I want to ask your opinion on something just to see where you go with it. I know you covered some topics that are very relevant to this. But I got a design from a designer that I paid for, for one of my websites. And they gave me back a couple of really massive HTML files, several hundred or more lines of code. How do you approach something like that and break it into a kind of sane way of managing the view when you pull it into your Rails app?

So, I have a question for you actually. Are you going to get more designs from him? Is it going to be an ongoing relationship or is this a, ‘Here’s your code’?

This one was a ‘Here’s your code’. Most of the time, that’s what I wind up with. Sometimes, it’s ongoing but most of the time, it’s…

John, do you want to tackle this since you actually do this a lot?

Sure. Usually, what I’ll do is I just kind of start and I strip out everything that’s not absolutely mission critical. What is the barebones that becomes the page frame? If there’s multiple variations like there’s a different home page and a different inside page, then I’ll strip those down to the barebones and those become my application.HTML.ERb, or landing.HTML.ERb in my layout files. Then I start taking those pieces and working down. So, if I’ve got global things like a header, especially when I have multiple things like multiple pages with shared elements. So, same footer on the home page and the inside page with different headers for example, that might be one example where then I pull the footer out to a layouts shared footer partial and I kind of break it down that way. For me, it’s all about understanding what that block is. And I usually associate visual blocks on the page with partials when I’m doing this kind of work. So, I’ll break those out like that. The navigation, it depends on how crazy we get. If it’s just static, I’ll just usually put it in the file. Sometimes, I even leave it in the layout file if it’s not too complex. Sometimes, we do more complex navigation with, for example, the goose gem that Bruce made and that’s when you start to kind of push things into different places. The biggest thing I find is actually my SCSS organization has gotten a heck of a lot more complex, I will break things down into very minute things. And instead of controller based, I talk about areas of the site so it may be a parody to controllers but it often is a little broader. And so, we’ll have various setups. And I’m actually working -- we built one of these at LivingSocial called Wild which I’ve shown a lot of pieces of in the talk I’ve been giving, and a lot of examples from it. But with Lynn Wallenstein who helped write it, leaving and going to GitHub, we’re having some difficulty finishing it to get it out. It works through internal but we’re trying to open source it. So, we’re kind of rebuilding that now as something for a project that Bruce and Lynn and I are working on. Hopefully, we’ll be able to kind of open source that. And that gives a lot of insight into how we build things. Because a lot of people are like, “Oh, bootstrapping, forget it.” And I think that’s the wrong approach, that’s kind of the cargo culting. And it’s really about using those tools to say, “Here’s some best practices, and here’s how I can re-implement that for something that I understand and I’ve built that solves my specific problem, as opposed to having building 50% of this extra code engraft in a library that you didn’t need. I mean, when you approach, so that’s deciding if you’re going to be using one of those libraries is definitely part of that process, but I tend to prefer to kind of just go from scratch and pull the pieces in that I need.

Yeah. Well, the thing I would say is one goal for me when I’m doing something like this is try to mentally extract a style guide from it and maybe even rip those pieces out. This is even separate of where to put them and if they should be in partials. Or if they should be in the layout but actually try to identify, “That’s what this means, this is the type of markup that I should be using for this piece. This is the design style for this type of data for my tables,” or whatever. Once you get to that point, you can start to break it down into SCSS modules or however you want to lay that out data wise, so that you can use it. But the most important thing is that you internalize what the designer has laid out for you and how that can be reused. It kind of depends on what your use case is, whether or not that’s in a partial, whether that’s in help, or whether or not that ends up in SCSS.

Yeah. And I would say to make sure also that a lot of times, we’ll approach things with a sledgehammer because we know how. So, I see a lot of people who say, “Oh, this is great I’ll just start building a presenter from day one.” And I usually encourage people to really start simple and don’t extract it to there until it’s a pain point that’s worth extracting because otherwise, you end up with a lot of meta programming or a lot of weird stuff that’s buried away. And I’ve seen some really ugly presenter code because somebody just wanted to write a presenter. As opposed to, and it would have been easier done as just helpers through the ERb.

Yeah, that makes a lot of sense. Alright, do we have any other questions before we get into the picks because we need to start looking at winding down?

Okay. I guess I’ll just say one more thing, not so much a question but we haven’t mentioned at all that the book actually does have some pretty good coverage on mail and designing email and stuff like that.

Yeah. I think that the chapter on doing HTML style, HTML in Email, I’ve never seen a good write up of it like this before. It’s just amazing.

It’s another example of one of those, “Yeah, this sucks. And here’s what you got to do if you really got to do it.” But it also takes a really practical approach like there was an emphasis on designing the text Email which I thought was really great. And then, showing some great tools like Letter Opener and Litmus and stuff like that. Anyway, I just thought it was a good section and we haven’t mentioned it at all.

There’s a new gem that we found after the book came out called Roadie which actually lets you extract your CSS out and it does all the nastiness of putting your CSS in line and making all your URLS absolute which is, it’s really nice on the developer happiness side and it lets you serve the problem.

Awesome.

Let me just say too I was very happy that John wrote that chapter or most of it. [Laughter]

Because as a topic, that is a topic that really, really was painful for me and I actually learned a lot from just reading what John put together. He has to do that kind of thing. I don’t as often and it was really, really good to learn from someone that has a focus on it.

Awesome. Alright. Well, thanks for writing the book, guys. It really is a terrific way of exploring this layer of Ruby on Rails.

Yeah.

It’s very humbling. I think it puts people back in their place a little bit. There are a lot of developers, I think, who are very kind of condescending about the whole view layer, “It's not real programming.” And this just brings back how incredibly difficult it is to do well and do it right. It kind of frames it as a challenge as well which I think a lot of developers react well to.

You mean, it’s not just HTML? [Laughter]

Just make it Haml, all the problems will just go away.

Oh, that’s right. I forgot.

Ouch.

Alright, let’s go ahead and do the picks.

Do we want to talk about the next book before we do picks? Or does that come after picks?

Nah, go ahead.

Okay. So, our next Book Club Book is going to be ‘Explore It’. What’s the full title of this book?

I have it here, it’s ‘Reduce Risk and Increase Confidence with Exploratory Testing.’

Yes. And it’s by Elisabeth Hendrickson, and it’s a new book out. So, I don’t think many people have read it by this point. And we haven’t scheduled the episode when Elisabeth’s going to come on yet but it will probably be in the next month or two.

Yeah. In fact, if we don’t talk to her soon, she might learn about it on this episode. [Laughter]

No, no, no. We’ve already tweeted about it, she knows. She’s totally up for coming on the show, just got to find the time.

We’ll probably aim to do this one around the end of June. Just because a couple of us are away for pretty much all of May.

Yes.

Yeah, there's a lot going on.

Anyway, it’s an interesting book. It’s not Ruby focused specifically but it’s definitely applicable to the development work we do in Ruby.

Awesome. Alright. Now, let’s get to the picks. Katrina, do you want to start us off?

I do. Lately, I’ve been thinking a lot about becoming a smarter person because I desperately want to be a smarter person. One of the things I came across quite recently is a website called Lumosity. So, it’s a bunch of games that you can play every single day or at least three to five times a week that are designed to help you think more quickly, to increase your attention span, to allow you to practice focusing, increase special awareness, that sort of thing. It’s all based on neuroscientists, or the work of neuroscientists, those people who know stuff about how your brain works. Lumosity, I saw some of the people who are programming the website yesterday in the Expo Hall at Rails Conf, they are one of the sponsors this year. And it just reminded me that I needed to pick it because it’s pretty awesome.

Awesome.

That is awesome.

I’m going to go get smarter too. James, what are your picks?

I have a couple technical this time. First of all, just a plug-in I’ve been using at work that’s kind of helpful. In ActiveRecord, sometimes you have several fields that are like attributes of a model kind of thing, several properties and you want to just cram them all down into one field. This will do it as binary bits on an integer. And then, it can generate the SQL queries for that so you can find the entries that match, and stuff like that. Anyway, the plug-in is called ‘flag shih tzu’. And I’ve been using it work and found it pretty helpful. Then the other thing I have is Ernie Miller, I guess, gave his talk at Rails Conf yesterday and I did not see it. I didn’t catch it on the stream but I did go through the slide deck this morning and it is unbelievable. The talk is called, ‘An Intervention for ActiveRecord’. And if you basically want to see the ActiveRecord Ruby showdown, this is the talk for you. He goes through and looks at, “Look, this is this really complicated thing ActiveRecord does to give you before filters, after filters, around filters. This is how you do them with one or two lines of Ruby.” It was really, really great. I mean, seriously, every slide is just plastered with code out of ActiveRecords internals and comparisons, the complexity of ActiveRecord and stuff like that. And Ed makes some really good arguments. Definitely browse the slide deck, it’s a fun ride. That’s it.

Alright. Josh, what are your picks?

Okay. There’s a tool I’ve been using for, I don’t know how many years, a lot of years. It’s called Transmit and it’s my favorite Macintosh desktop tool for doing FTP. It just works really great. You can do drag and drop. It has a nice little finder pane in addition to your FTP pane so it’s easy to drag stuff back and forth and navigate around. It works great with SSH. It’s my favorite, it’s wonderful.

And it supports S3 which I always use it for too.

Oh, yeah.

I was going to say one of my favorite features is it will actually mount your S3 as it drive in Finder.

Yup.

Yes. If you do any moving files back and forth to servers, it’s really worth it. So, that’s my pick on that. And then, just recently I saw that one of my favorite reading resource, Omni Magazine, ‘70’s, ‘80’s was just great. So, a little kid nerd, I would read Omni all the time and the Internet archive just published the complete archive of every Omni Magazine. And that’s just -- I’m kind of looking forward to having a nice read through some of those things. There was some great stuff. We always thought of Omni Magazine as sort of Playboy without the pictures. [Laughter]

It was sort of like that same sort of speculative, work-your-brain kind of thing but it was about geekery. And, I don’t know. Maybe that says more about the time than anything. But it’s great. There are some really good science fiction, short stories in it, some speculation about the future. It was a lot of fun. So, I recommend that. That’s it for me this week.

Cool. Alright, I’ll go next. I’ve been kind of hooked on a couple of games on my iPhone lately. And so, I’m going to pick those. The first one is actually a board game that I really enjoy. It’s called Ticket to Ride. The app is really fun. I’ve just been playing a lot against the bots so I’m going to go ahead and pick that. Besides that, I know I’ve picked them before I just want to, I can’t say enough good things about them. I’m really happy with Hover. They’re the domain registrar and you can find them at Hover.com, just really, really cool stuff. Finally, my last pick is also our newest sponsor. I didn’t realize that Heroku offered Postgres hosting software as a service. And it looks like just really, really cool stuff. So, I’m going to pick Heroku Postgres as well. John, what are your picks?

Some stuff I’ve been seeing. I don’t know if you guys have seen this but Chris McCord put out this thing out about a week ago called ‘Sync’ which is basically real time Rails partials. And it uses JavaScript but it’s more heavy on the ERb side. It’s something I wanted to start playing with in the View. It’s a really early release right now but it’s definitely something worth pursuing. Some other stuff I’ve been playing, we’ve been using Screenhero at work. Screenhero used to be called PowWow, I think. And it’s a great tool for kind of remote pairing and screen sharing and working on code together. It doesn’t do sound or anything. It just focuses on getting two people’s computers in sync with their mice and their keyboards. So, we’ve been using that for doing some pairing remotely and then we’ll have a Google Hangouts going in the background and that helps a lot. The final thing is I found this article, I used to do a lot of visual effects kind of film stuff but this is around game design in Skyrim. And it’s this whole thing basically did a modular approach to level design and they talk through how they can reuse these assets and these pieces of assets. To me, it applies a lot to also just other design stuff in general. It’s really in-depth and it’s a really long read but it’s a really interesting article about that kind of stuff I found pretty fascinating.

Nice. Alright. Bruce, what are your picks?

So, I’ve got a few things here. The first thing I should mention is that Rails 4.0RC1 is out and people should be looking at that definitely. They should be looking at things like Strong Parameters which we talked about today, and Turbo Links, and Personal Caching. And you should get into Ruby 2.0 as well which I think is really cool. One thing that I’ve been playing around with lately has been Ruby Motion but specifically using CSS to lay things out in Ruby Motion using Pixate. That’s something that’s really, really cool. It’s neat and it’s just kind of neat to be able to develop IOS apps with Rake, for instance. And the last thing that I should mention is that everybody should get outside because it’s Spring. And I know that we all want to sit around and we all want to work on cool things. And there's been a lot of stuff we talked about today but don’t forget there’s a sun outside and there’s -- grow a garden. Do something outside and time is precious so make sure that you don’t use it all up on the computer. And that’s it.

Yeah. You say sun. It was snowing when we started the show here.

Well, there’s sun in Portland. And if there’s sun in Portland, then it is a precious thing. [Laughter]

Fair enough. Alright. So, our next Book Club Book is ‘Explore It!’ as we said before. We’ll put a link in the show notes to that. And thanks guys for coming on the show. Really, really appreciate your expertise and the time that you put into this book.

Thanks so much for having us.

Thank you.

Alright. With that, we will wrap this up. We’ll catch you all next week.