Transcript

CHRIS: Hey, everybody. Thanks for listening to Shop Talk Show. We have two perfect sponsors this week: Lynda.com and then go to /shoptalk, which will get you seven free days for the largest learning resource for tech stuff on the Internet for sure. I have a course there you can check out.

And Environments for Humans, who are promoting Artifact Conf, the Artifact Conference, which is coming up pretty quick here in Austin, Texas, May 5th through 7th. They have a coupon code: SHOPTALKSHOW. We'll tell you more about those later in the show. But for now, let's kick things off.

[Music]

DAVE: Hey there, shopaholics. You're listening to the Shop Talk Show, a podcast all about the Web design world. I'm Dave Rupert, and with me is Chris Coyier. Chris, how are you doing?

CHRIS: Oh, I'm doing just super perfectly. How are you, Dave?

DAVE: I'm good. It's pretty quiet in the study today, isn't it? It's pretty quiet. Why is that?

CHRIS: Well, there's just -- there's no -- you know, there's no guests this week. This is kind of what we like to call around here a Rapid Fire. Uh-huh.

DAVE: Oh, yeah.

CHRIS: Uh-huh, uh-huh.

DAVE: I apologize, I think people are --

CHRIS: We're pushing our gun agenda, I think, is what's going on here.

DAVE: Yeah, just totally pro guns in podcasts. So yeah, man. So this is good. For those who aren't catching this live, we are beta testing another Google Hangout with Rapid Fire. But if you downloaded this, it doesn't matter to you. But it's kind of exciting. Chris and I are now, again, face-to-face. This rarely ever happens. Very exciting. I'd like to see where things go. First question.

CHRIS: No guests, no drama, just, we're getting right into the questions. The first question, you take it, Dave.

DAVE: The first question comes from Confucius Chow: "Is that C-3PO in the background?"

CHRIS: Oh, shoot.

DAVE: Yes, it is.

CHRIS: So there you go.

DAVE: Thank you. See how quick this live feedback is happening right now? So anyway, all right. Let's get into the question and answer action.

[Music]

DAVE: Okay. Here we go. Adam Overstreet writes in: "I know the picture tag you guys have, you have the ability to add various image sizes based on screen size. Will there be something similar for the figure tag?" Chris?

CHRIS: So what Adam is talking about is literally the picture, the HTML tag, which is kind of -- I don't know if you've been following the responsive images drama much at all, but the latest in it is that people are starting to agree that it has a place in the world. There was source set, and that has a place in the world, and then there's going to be picture too. There's going to be two things that are going to help us with responsive images.

And picture is just a special markup that's a little bit like the video tag in that there's an opening picture tag, a closing picture tag, and then, within it, a bunch of more tags, source tags that are going to take a picture source, but then also have what's a media attribute, right, or whatever the attribute is that defines what the media query is.

DAVE: Yeah.

CHRIS: Was that a yayQuery moment for you?

DAVE: Yeah. No, I'm going to be like fake ajpiano here.

CHRIS: Okay. So that's how that works, and for one of those media query matches, that's the source of the image that it's going to display. This is going to be great for us for image or for pictures in markup, for content pictures that depend on which one do you want to serve in which situation, which media query match.

DAVE: Like small, medium, big, right?

CHRIS: So Chrome is onboard, and they're like, "Hey, we're going to do this." And Joav Weiss, I think is his name, right?

DAVE: Mm-hmm.

CHRIS: Is saying, "I'm a programmer, and I write code for browsers. And I'll do this. It's just, it's a little bit of a, you know, maybe not thankless at this point, but at least not well paid job." He's going to like open source contribute it. He's going to spend his own time writing the code to do this, unpaid by anybody. So they started up one of those campaigns. No Kickstarter, but the other one, you know. I can't remember what it's called, IndieGoGo or something.

Sort of like, hey, I'm going to spend a whole bunch of time doing this, and it's really going to help lots of developers in the world.  And it had like a $10,000 goal or something, which is, you know, if that seems like a lot to you, it's probably not a lot compared to what a developer's salary for someone is who writes browser code for a living does because it's going to take them so many months or whatever.  And that hit its goal, so that's pretty cool.  

So we are going to get picture.  Even Chrome contributed to that campaign, which is pretty neat as well.  So did FireFox.  They're onboard too.  Yeah, that should be pretty cool.

DAVE: So is that going to be something similar for the figure tag?

CHRIS: That's the question. I'm sorry that took so long to get through the thing, but figure is just a semantic element like a div or a section or article or whatever. And that just wraps it to say, hey, this is a figure. And if you want to put a caption in it, you can put fig caption. It's just a semantic element. I don't think it's planning to have the same -- any kind of actual functionality. You know, it doesn't actually do anything. It just is a thing.

DAVE: Yeah. Yeah, I think you're a little confused. Figure kind of does nothing by itself. It's just a div. You can put a picture in your figure.

CHRIS: Yeah, and you will. I think we'll see that a lot. You'll see a figure with a picture inside of it with a fig caption and stuff.

DAVE: Mm-hmm.

CHRIS: Yeah.

DAVE: Mm-hmm. There we go. Let's call it --

[Sound effects]

DAVE: We've got some questions in the chat room. Do you want to handle some of these? Should we?

CHRIS: Yeah.

DAVE: Here we go. Robert DeLuca writes in. This is crazy. We've never done these live questions.

CHRIS: No.

DAVE: Robert DeLuca writes in: "Ember.js versus Angular.js, which would you use?"

CHRIS: I don't know. I would make Tom Dale very mad if I picked Angular.js, so just for community credit, I'd have to pick Ember.

DAVE: Yeah, you don't want to go against Tom Dale, right? You can't. I think, if you're doing a Rails app, Ember makes a lot of sense. It's built by a lot of the same communities like a lot of crossover there. There's a lot of parity there. That would be good to do. If you just have all of this JSON from your Java app or something, I don't know, choose Angular. I mean, you've got to think about who's building it, you know, like Google is building Angular to power all their big apps on Google scale. So that's good too. I would actually just say don't worry about it. Just get into it and do it.

CHRIS: Yeah, you're more qualified in answering that than I am.

DAVE: What do we say here?

VOICES: JUST BUILD WEBSITES!

CHRIS: Uh, nailed it! I think we did the C-3PO on. Yes, yes, that is. Okay, let's do one from -- let's wait for a few more to trickle into the chat room here and do one by Eric Serven, Edin, who writes in: "Dear, Shop Talk: Styling scrollbars using CSS has been a discussion since it was introduced by IE5.5 way back in 2001. For a long time this was considered faux pas. But over the past three years, with support from WebKit and a prevalent use on Web apps like Gmail, Facebook, CodePen, et cetera," yeah, we're right in that group, "the topic is again gaining traction. As far as I know, Gecko is the only engine that doesn't support styling scrollbars in CSS, forcing developers to style scrollbars using JavaScript and/or plugins. I would like to know what your opinion is on the issue."

I think it's an opposite -- well, you almost have it right.  I think WebKit/Blink is the only browser that is supporting it now, and they do it through WebKit prefixed properties like ::/webkit-scrollbar and then a whole bunch of other ones.  There's literally like 15 or 20 different, you know, I guess we think of them as kind of Shadow DOM even though it's not quite Shadow DOM.  I guess it is, but I don't know.  Little parts of it you can….

DAVE: Proto Shadow DOM.

CHRIS: Sure. That's what we're calling it. They're the only ones that can. And I think, if I was a different person or worked on different projects, I would be like, uh, why are we even going here? This is the kind of thing that browsers should just do. There's a user affordance to scrollbars that should be maintained. I can imagine myself having that opinion, but I also can, now that I work on CodePen, and we decided that the editors were going with generally a dark theme over the entire site, I've decided to style the scrollbars dark in the editor because I think they're just less obtrusive in the particular style that we have going on there. And I like the look of them.

And it's always a bit jarring to me when I hop over to FireFox, and I'm like, oh, yeah, there's big, white chunks right in the middle of the page because there's just no way to change that style. Honestly, it kind of bugs me, and now I do wish there was a standardized way to handle it. What I work on has affected my opinion there, which is no surprise, right?

DAVE: Yeah. My advice here is just don't. Like, let it go. I know they probably bother you, but just don't. For me, it's like a system level thing. It's like a user is used to their scrollbars. They love them. If they use them, they actually use them, and they want them to be familiar. We kind of went through this Web where like with IE5 and stuff like that. You'd show up and there'd be like blue scrollbars with like pink lines and it was just like, what the crap is going on. So I'm kind of a fan of --

CHRIS: Yeah, just let it be.

DAVE: Either like what you're doing, just like trying to switch the contrast or something, that's maybe fine, but.

CHRIS: Yeah, that's all I want, I guess. Maybe it doesn't have to be so complicated, but maybe there could be some opacity setting to it, or maybe there could be like only show when scrolling setting. Maybe there's some middle ground that could make it acceptable on sites where they look very jarring, but without giving developers a ton of, ton of control over.

DAVE: Yeah. Yeah, it's really interesting. Like Windows has scrollbars, right? But they have these very awesome, very minimal scrollbars. But then if you have a mouse plugged in or it detects a mouse or whatever, it will give you the big, fatty scrollbars.

CHRIS: Well, that's neat. That's the kind of thing that's so hard to spec out, right? Like how do you, as a spec author, decide how operating systems should handle something like this, because it's an operating system level thing?

DAVE: Yeah, overflowing.

CHRIS: So I think it's just too hard for spec authors to do fairly, I guess. When it comes to UI, they tend to back off. Think of the input type equals date. They really don't specify how that should look and work and what the controls in there should be, as far as I know. I think it's just kind of like make it be like a calendar.

DAVE: Yeah, just let it be it.

CHRIS: All right. Let's do one from the chat room because there's a couple of ones in here that are getting lots of up votes. This is cool. This is unprecedented territory here.

DAVE: Yeah. It's like psychodelic.

CHRIS: Josh. I'm going to select it. I don't know what happens when I hit select, but it kind of moves it up to the top.

DAVE: It says, "Currently answering."

CHRIS: "Do you still use Grunt JS? I saw you post you were trying Gulp JS. Do you notice any real differences in performance or features? They say it's faster, but Grunt compiles out essentially instantly for me on my Retina Mac Book Pro."

So this is -- a lot of people are very interested in this.  We have a number of questions that came in.  I don't know.  It has all the right overtones of a good tech drama, right?  Grunt v. Gulp!  Oh, my God!  Came out of left field.  What should I do?  I just got used to Grunt, and now everybody is saying use Gulp.  What's going on here?  People want answers, Dave.

DAVE: I call it FOUTWT, which is: fear of using the wrong tool - FOUTWT.

CHRIS: Oh, that should be your next event or List Apart book, Book Apart book.

DAVE: That's my list apart. Yeah, fear of using the wrong tool. I like Gulp. I'm trying to pull everything over to Gulp because I enjoy it. Gulp and Grunt are the same thing, basically, except Grunt you just write a big, like configuration JSON. It's like miles of JSON.

Gulp, you write like little functions that just execute over and over and over or whatever.  It's kind of like you're writing a node app in Gulp, which is, if you're not comfortable with that, you'd rather just write JSON, then Grunt is your thing.  But if you're like, yeah, I know how to write functions and do that sort of thing, then Gulp is kind of the -- maybe -- it's going to make more sense to you.  It's going to be easier.  It's like a Sinatra app, if you've ever used Sinatra or Express or something.

CHRIS: Yeah. They say writing your Gulp file is just like straight up writing node, right, where your Grunt file is configuration, which it's one of those things that makes me like CoffeeScript because when you look at miles of JSON, like you said, it's nice to skip all those curly brackets and stuff.

DAVE: Yeah.

CHRIS: CoffeeScript is sweet for that. But, yeah, that was a kind of moment I had with Gulp because I did do it on one site, and it was kind of like, in my mind I have a plan for this file. I have a plan for this .scss file. And what I expected to happen in my mind is that at first it compiles to CSS. Then it gets linted or something. Then it gets compressed. Then it gets auto-prefixed. There's all these little things that I know needs to happen to this file after it's done, and that does kind of make a little more intuitive sense in Gulp, I think. Like, here's the file. Pipe it to all these different things, and then put it where I want it to put it.

Whereas in Grunt there's kind of like, take this file, run this one thing, and put it here. Then after that, grab it again, run this one thing, and put it back here. Then grab another thing. So it's just less pipey, but I don't know. Maybe that can be improved in Grunt.

DAVE: The piping is a big deal. For me, it triggers how easy jQuery is, like training functions. You're just like, A then B then C. In Grunt, you have to manage where you temporarily stash an option or a file or whatever, and then you have to go get that from the thing, and then put it in the thing. Gulp is just like an assembly line. It's just like script, choo-choo-choo-choo-choo, output, done. And I like that.

CHRIS: Yeah. The last time I mentioned that, somebody on the Gulp team was like, "No, it's more than that." And I was like: I bet it is. I just done write node.

DAVE: Pretty much jQuery.

CHRIS: I get it that if you are a node person that that could be appealing to you to be able to have essentially your Gulp configuration file be open to whatever kind of code you want to write. But that doesn't mean anything to me. Speaking of that, maybe we'll do this Roger Vandawalker question that just says -- because it's similar in spirit, I think -- that says, "If I'm only interested in straight up compiling and minimizing SAS and JavaScript in a project, why would I go with Grunt or Gulp when there's GUI tools for this?" What do you think about that?

DAVE: My big thing about -- so all these tools are really awesome, right, like Prepros or CodeKit or anything like that. The problem is: A) It's paid, right, or it's maybe only on one platform or something like that. So then you have to buy licenses and do all that stuff. Maybe your team doesn't want to do that, especially when the stuff is free, and then you just have to kind of like do some, just a little bit of work to get it kind of going.

You've got camera two going, Chris.

CHRIS: It's a two-camera shoot.

DAVE: For me, the money thing is a thing for a lot of people. B) The tools that are bundled up into GUI only -- they cannot go as fast as the command line. You could have spent months building a GUI for Grunt, right, and then Gulp comes out, and then it's just like, oh, man, we just wasted all that time and energy. We should have, you know, now we have to redo that all over again. So tools kind of happen faster than apps, like Prepros or CodeKit or whatever can update.

I know CodeKit is making some strides to like make it so you can execute commands yourself, which is kind of cool, so you could kind of like stay ahead of the curve, like you could compile your Jekyll or something like that with CodeKit.  But again, it's just kind of like that works until a point.  I think we should all kind of -- I feel like it's coming to like if you build websites, you should have some familiarity with the command line.  I'm not saying you have to be a pro.  I'm just saying it should not be this dark place to you.  That's my personal IMHO there. 

CHRIS: Yeah. I like it. I think a lot of the GUI tools are for the lone soldiers too, generally. Not everybody, not in every case, especially, you know, CodeKit has a CodeKit.config file now that you could be version controlled, and you could get everybody happily on that. But I generally find the larger the team, even if the team gets to more than a handful of people, I think that's one of the big advantages of Gulp and Grunt is that it's all kind of configured in your repository, and people just pull it down and run commands, and it's easier to kind of keep everybody on the same page with things like that.

Good luck, Roger.  

Maybe we'll do one from our list in here. Actually, we should do a sponsor, probably.

DAVE: Yeah.

CHRIS: We've got Lynda.com, like I told you at the top of the show. Lynda.com and then go to /shoptalk. If you go to /shoptalk, that's how you can -- if you sign up through that URL, you get your seven-day free trial. So if you've never done it, I encourage you to do it because straight up you get seven free days of their entire resource library, which is enormous, right?

There's just more video training on that site than anywhere out there. So it's the kind of stuff that we talk about. I mentioned CoffeeScript just a minute ago. They have a course called Up and Running with CoffeeScript. They have a course called Creating icon fonts for the Web, in which I'll do a follow-up course on -- probably not, but we're going to debate that using SVG for icon fonts or for icons is better. But anyway, if you're interested in that, Creating icon fonts for the Web. There's Responsive CSS with SAS. You know, all these courses, all this type of stuff we talk about, there are learning courses that you can dig in a little more in-depth with them on there.

But then they have all this other stuff too, right? Like just super recently they put out a class called Excel 2013: Working with dates and times, you know, like do you want to get better at accounting tools because that type of stuff is there. Do you want to get better at Lightroom? There's a class all about its new features in 5. Do you want to get better at knowing about the lawyerly legal side of the Web? There's a class called Intellectual Property Fundamentals. Brand new stuff that's just coming out, so it's a huge library, and the breadth of what they teach about is huge. Go to Lynda.com/shoptalk.

All right. We've got one here from --

DAVE: I'm going to write them a jingle right now. L-Y-N-D-Y DOT COM!

CHRIS: You just went right up the scale. Just straight up.

DAVE: Yeah.

CHRIS: Mm-hmm.

DAVE: There you go. All right. Here we go. Let's do Theo Lant. Does that sound good?

CHRIS: Yeah, yeah, yeah, yeah.

DAVE: Is that where you were headed?

CHRIS: That is.

DAVE: Okay. All right. "How do you deal with ads? More specifically, AdSense when it comes to responsive design. I read about AdSense's responsive ad units … your URL goes here, but it seems that the ads served are still the standard sizes, not fluid. So a better name for them would be adaptive ad units."

CHRIS: Fair.

DAVE: I like that. "So if, say, I have a fluid main content area and, on some devices, its width turns out to be 513 pix, is there a way to make my ad be 513 pix as well, or do I have to serve a standard size ad unit and have it centered on or one side? This issue is why, so far, I am choosing adaptive design instead of responsive."

CHRIS: Just to define those things --

[Sound effects]

CHRIS: -- I think adaptive design has come to mean fairly firmly, like imagine the classic shrinking browser window, and it hits a certain breakpoint, and it just shifts entirely what it does. Then you squish it a little further. Maybe the browser engine, Windows, it's getting a little close to the edges, and it goes oh, and it shifts, and everything is in a different places as well. So they're like fixed layouts, but they just hit and break at certain points. That's what adaptive design is.

I think Theo is right that if that's what AdSense is offering, which is like, here's an ad that happens to work at these X different sizes. They're not totally fluid. They have just different versions of themselves that adaptive design might be appropriate for that. And nobody says that adaptive design is just straight up a bad way to do it, for the most part. And responsive design being the one that's totally fluid, right, it just works at any different size. So I don't know. I think that sounds reasonable. Yeah, I mean, if AdSense is very important to you, and you can pull off adaptive design, go for it, right?

DAVE: Yeah. I mean, for me, I just did a site. I had to add units and stuff like that. It was tough, you know, but I think kind of what you're looking at is you do you need this fixed area because you don't know if that ad is going to be a standard image or a Flash ad or something like that, not an iframed video or something like that. So they can't go smaller than certain dimensions. I mean, you can do adaptive.

What we just did is we just did breakpoints. If we knew it was 728 pixels wide, it's basically on the component level like that ad unit level. At 728 pixels, boom, that's when our leader board pops in because we know we can support it. We have the width, so we're going to just pop it in.

A lot of the units are 300 pixels wide, which means you kind of have to get a fixed column that goes down. That's actually really not too hard to do. You can do it with display table even, or whatever you want, or float and then do that margin hack where you do margin and absolutely positioning and all that.

I mean, there are really only four widths that you have to worry about. There's 150, 300, and then, I don't know, 728. That's basically it. You can do a 600 pixel wide thing, but you just need to kind of plan for that. You just need to kind of map out what ad units you have and then just build….

CHRIS: That's an interesting thought, right? It's like you can think of these ads as being a fixed pixel size. But then the rest of your design can be responsive, but you only just put them in there when you know that you have room for it and remove them when you don't. If it's a sidebar ad, for example, just make the sidebar a fixed size that supports that image, but everything else is fluid. Those are possibilities too.

DAVE: Mm-hmm. And Flexbox will really help with this too. You could just do that -- boom. It'd be pretty easy, but yeah, I think it's pretty easy. I don't think you have to limit yourself to adaptive design, but I understand why you would. If that makes sense to you, do that. Yeah, I'd just prefer the fluid nature myself, and I'm fine with a little extra white space.

CHRIS: Indeed. Logan --

DAVE: All right.

CHRIS: Logan Pennington.

[Sound effects]

DAVE: Man, dropping the ball on the gun. Okay, here we go.

CHRIS: I always forget literally every time. Logan Pennington asks, "SAS doesn't support importing CSS files. I'm trying to use CodeKit 2.0 and important Bower's normalize.css or the used Bower to get a copy of normalize.css. But it doesn't work. Could you tell me why and what you do to get around this? I would like to call just one CSS file on my HTML page."

So Logan is trying to concatenate his files together. He's using SAS's ability to do that. And I think me and Dave just talked about, on a show recently, that it's possibly the most important feature in SAS, which I concur with, is its ability to import other files and squish them together, which uses no SAS syntax barely at all. It's just concatenation. It just allows for intelligent kind of organization of files. But apparently SAS doesn't allow you to important .css. I guess I didn't even know that, but.

DAVE: Well, so if you use import from a remote directory, it doesn't. It's like, oh, you mean like import it with an important statement. Oh, okay.

CHRIS: Yeah, like the classic CSS one, which all it does is just make an extra HTTP request. It doesn't actually squish them together.

DAVE: Which is weird. I would have -- I kind of always thought it knew what to do, but maybe that changed or something.

CHRIS: Well, the world's quickest way to do this is just to change the file extension of Normalize.css to Normalize.scss, and then it will work because the syntaxes are cross compatible. So that's the world's easiest way to do it, although I guess you're in a weird spot then, right, because one of the reasons to use Bower is the fact that if Normalize were to update, which it does sometimes, that you can just update that thing and now it's weird. You'll have to make that change again. It's not just a straight up dependency like a Gem would be, right?

DAVE: Yeah. So -- yeah, I mean, I feel like in Normalize, which is kind of one of these things -- Normalize is actually designed to be kind of integrated into your project. It's kind of designed to be the --

CHRIS: Right.

DAVE: -- the HTML 5 bootstrap or whatever we call it. Is that it: bootstrap?

CHRIS: I agree.

DAVE: For your CSS, right?

CHRIS: You should be editing it anyway.

DAVE: Yeah.

CHRIS: So part of that editing process is renaming it. That's a great point.

DAVE: Yeah. Yeah, so that would be my thing. But I see what you're trying to do. Yeah, I would do Chris' hack or whatever, and that would be your easiest way to get started.

CHRIS: Indeed.

DAVE: All right.

[Sound effect]

DAVE: Boom.

CHRIS: I'm going to do one more conference for one more sponsor here just so we get them out of the way. There's Artifact Conf coming. That's the URL for it is ArtifactConf.com. It's a two-day single track conference, and it's all about -- here's what it says: Artifact is an intimate, two-day, single track conference that helps Web designers and developers adapt their tools and processes to the challenges of designing for a multi-device world.

Man, have we talked about anything else the last couple of years?  If so, scarcely, right?  It's all about designing in a multi-device world these days.  

It's coming up May 5th through 7th in Austin, Texas.  Mr. Dave will be there.  

DAVE: Hey!

CHRIS: Yup! Are the tickets -- are the people the same at both two events? Is that how they tried to go it, or are the people listed on the website right now just for the Austin one, and then it will change?

DAVE: I think it's just Austin right now, but I think they try to kind of bring --

CHRIS: Yeah.

DAVE: It's almost like a road show that they try to take across America and the world.

CHRIS: So if you can't make it to Austin, it is coming to Providence, Rhode Island, in September, September 29th and October 1st, so that should be pretty cool. You can use SHOPTALKSHOW for a $100 off it, which is a good deal.

DAVE: You should go!

CHRIS: It's on Cinco de Mayo. That's pretty cool.

DAVE: It's getting close! Oh, yeah, Cinco de Mayo. That's great.

CHRIS: Mm-hmm, mm-hmm. Jeremy Keith is going to be there.

DAVE: Oh!

CHRIS: He's like my spirit animal.

DAVE: When you apparate or whatever? Jeremy Keith is your patronus.

CHRIS: That's some anime stuff, Dave. Major….

DAVE: Hey. Hey, hey. Well, all right, your spirit form. All right. There we go. Shall we go --

CHRIS: Yeah.

DAVE: There's a big question over in the questions bar.

CHRIS: Okay.

DAVE: Here in the Google Hangout, live in the Google Hangout. Here we go. It's from Adisa Collis, and we get this question every once in a while, but here we go. "If you wanted to find a dev mentor, how would you go about doing that? Also, if you are interested in being a dev mentor, how would you go about letting other people know that you are available?"

So how do you get mentored --

CHRIS: Yep.

DAVE: And how do you say I can mention? How does that work?

CHRIS: That's interesting. My first thought is, like, I don't know. Maybe there should be a website for that or something, although I worry about that too because it feels a little like what if -- like, don't feel sad if it doesn't take off.

DAVE: Mm-hmm.

CHRIS: Anyway, I can imagine the problem with that website being that there's not a line around the block of people being like, I'm interested in giving away my time for free. That seems to be the biggest problem with our world is that people have so little time because, man, we're just doing it all. We're doing all kinds of stuff. But I like the mentor model. Didn't you attempt this at one point?

DAVE: Yeah. This guy, Charles, a really awesome guy, emailed me. He was like, hey, I'm looking for a mentor. I thought it would be cool. I thought I'd ask you what to do. We have tried it. We have not been super successful at it, to be quite honest. I mean, he's busy, I'm busy, and stuff like that.

CHRIS: Yeah.

DAVE: But kind of the idea there is like I'm just going to try it and see what happens, see what being a mentor is like. But he straight up cold called me, and it was awesome.

CHRIS: Yeah, so that's a possibility for you.

DAVE: That's a possibility. I would say there's other times I've been in that mentor role like we have Girl Develop It here in Austin that's really awesome. It's like a small community of women learning how to develop and pick up coding schools.

CHRIS: It's like mentorship in mass a little bit, right? This is a large class.

DAVE: Yeah. Kind of like a group, like a small cabal of teaching each other how to do stuff. The kind of thing about mentoring is you literally only have to be like one step ahead of the person who just signed up, so anyone can really do it.

But if you want, you know, if I wanted Rebecca Murphy or something to teach me JavaScript, it's tough. I'm sure she's busy. I'm sure she is like, yeah, I'm busy. I have a kid. I'm not going to do it.

How do you do it? I think it's really just like you make yourself know. You go to meet ups, and you find somebody. Ideally, there's somebody at your company who can help you or is interested. Companies should provide structures for junior and senior devs to kind of train each other. Meet-ups.

CHRIS: Yeah. In Tracy's episode, we talked about that a little bit. I like that idea that you hire, you know -- part of being mentored is being a junior position at your job.

DAVE: Mm-hmm, mm-hmm. Yeah.

CHRIS: Then there's the traditional GitHub model too, right, like maybe you're working on a project, an open source project with multiple other people online that there'll be people that are better than you and people that are worse from you. Maybe that's a mentorship-like scenario.

DAVE: Yeah, yeah. And there's times where --

CHRIS: I just think because they're incentivized then to help you because you're helping them too.

DAVE: Yeah. Yeah, and that's just like there's been times where, yeah, people will hire consultants, bring those people into their company to teach them a skill or something like that. That stuff happens, so if you feel like you're not being mentored and you work somewhere. It's weird if you work for yourself, but if you work at a company, just ask them: hey, I could use some more skill training. What can we do about that?

CHRIS: Yeah, you would think that would be appreciated.

DAVE: Duh -- and I'm all like -- duh.

CHRIS: Good luck though. I know that's a hard question. I'm sure that now you're not 100% empowered to go find a mentor today. I mean, I think that's just kind of a hard question. There's not a -- there's certainly not just a pile of mentors sitting out there that you can just pick one off of and vice-versa, so good luck.

DAVE: I mean, I think cold call, ask some people, start advertising like, hey, I'm looking for somebody on Twitter, you know.

CHRIS: Yeah.

DAVE: And then somebody will be like: I could maybe do that. We need to -- yeah, that'll be in my next A Book Apart book: How to Mentor. No -- All right -- Hey! Next question.

CHRIS: All right.

[Sound effect]

DAVE: Should we do another one from the chat here? Dennis Gable, a long-time listener. It says, "Is Require JS something worthy to dive into or is it on its way out and may be replaced by something shiny and new?"

CHRIS: Module loader, kind of, right? Like how we just talked about the most valuable thing that SAS does, perhaps, is the importing and proper organization of CSS files. You might, call Require JS of that level of importance, right? I need some way to break apart JavaScript files into different concerns and knowing that it's a sucky option to have a production website be loading 30 different JavaScript files, so Require JS is thing to load and combine those together in a way.

DAVE: Mm-hmm.

CHRIS: Right.

DAVE: Yeah. Yeah, so Require JS basically says you define these modules. You say this jQuery plugin requires jQuery, and Require will say, okay, well, you need to include jQuery in this plugin, which is pretty simple. You can do that in your brain. You could write that out in Bower or whatever.

CHRIS: Mm-hmm.

DAVE: In your script, whatever, compiler or whatever. But where it gets confusing is what if one page only uses this weird jQuery plugin that also requires two other jQuery plugins? Masonry is a good example of this. It kind of requires these other plugins to kind of totally run if you're not using the packaged version. So you kind of have to go build up this dependency tree, so it's basically like an in-browser dependency tree.

CHRIS: There you go. Now that we've defined it, is it sticking around or--?

DAVE: I would say -- I mean, I think it is. I think, on big kind of projects, it's really kind of useful. I know this company I'm working with is using Flight JS from Twitter, which is very similar in terms of how it kind of uses the define pattern, the module pattern, which is like coming to JavaScript eventually, an early subversion of that. Yeah, I mean, they like Flight because you can also kind of like lazy load some features and stuff like that, so I would say --

CHRIS: Require JS is also sometimes called AMD, asynchronous module definition, and is it -- I don't get it. Is AMD like the philosophy and Require JS adheres to that philosophy and theoretically something else .js could also adhere to the AMD philosophy?

DAVE: Yes.

CHRIS: Okay.

DAVE: Yes.

CHRIS: And then there's --

DAVE: AMD --

CHRIS: Go ahead.

DAVE: AMD is like the philosophy that is trying to get into ECMAScript 6 or whatever. I could be totally wrong; I'm not a super pro on this. But then there's also Common JS, which is another thing, and that's kind of what all you node packages run on.

CHRIS: Blah!

DAVE: That's super successful, so maybe that --

CHRIS: And then there's Browser AVI too, right? While we're confusing all this, where does that fit into this world?

DAVE: Browser AVI, to my knowledge, allows you to suck up these node modules that were built for the server and use them in the browser. So your whatever, your file accesser --

CHRIS: Yeah.

DAVE: -- or something like that. So that's where it gets confusing.

CHRIS: Uh!

DAVE: Uh! Anyway, I think Require JS is pretty awesome. There is like a build step, but you could do it yourself. I would not probably implement it on a client site or in a WordPress theme until you have -- until, like with Grunt or Gulp or something, you've hit the point where you're like, I can't do this anymore. This sucks. I need a better system. That's where this next step is.

CHRIS: That's good advice, I think. Just do it with your brain until it's just until you know that you can't anymore and you need help.

DAVE: Yeah, and I know a lot of people use Require. I know a lot of people are into it. Flight, again, is kind of an up and comer, so I think that would be a good choice.

CHRIS: Okay.

[Sound effect]

CHRIS: Probably sticking around though. This idea is sticking around. Let's see. Maybe we'll do this audio one from Luke. Is it piped in to do that?

DAVE: Totally unprepared here.

CHRIS: We'll skip it, and you can get it ready, and I'll do a different one for now. How about that?

DAVE: Yeah, sounds good.

CHRIS: Kim Dusting wrote in for Dave. "Dave, you mentioned you're A Book Apart generator." Dave's -- this is a thing. This was a while back when Dave released this thing or whatever. You can find that old show. "One thing I noticed that I hadn't seen before was the use of a paragraph tag to wrap a label and field pair." You know how you do that. Kim says, "I usually use a div, but I never really liked the extra markup. Do you use P just to save a few characters or is it semantically correct? Are there accessibility implications? Also, you used--"

Yeah, let's skip part two of the question just for now. But so there's this idea of, you have a label and a pair, a label and an input, and they are literally paired together because often the ID of the input will be referenced by the for attribute of the label that literally connects them semantically together and functionally together too because it means that then you can click on that label, and the input will be active. But it's long been a part of the valid HTML that you're not allowed to put those two things just in a form tag totally raw. You've got to wrap them together in some kind of other element, which a div is the classic way to do that. It has to be block level, so you've go to pick one of those.

But Dave, in this example, apparently picked P. What's up with that?

DAVE: I probably did it because I had a margin, and that was fine.

CHRIS: Right, like the default margin for a paragraph. Divs don't have any default styling, whereas P has a little margin below it. So, hey, what the heck, use that.

DAVE: Yeah. It was cheap. It was easy. I don't think -- I mean, I've seen it done both ways. I personally like div class input because that sort of says like, hey, this is an input field, and that's kind of how Rails does it and some PHP frameworks and stuff. But, I mean, your options are a div or a P, and basically they're the same thing. I mean, a screen reader and stuff isn't going to be reading and go: paragraph, label, oops, that's wrong. That's not how screen readers work.

CHRIS: Yeah.

DAVE: They're pretty tolerant of terrible markup, so I wouldn't worry about it from an accessibility standpoint.

CHRIS: They do tell you how long the list is, though, so would there be advantages to using OL or UL?

DAVE: I've heard mixed reviews on that because a form is a form, right? And so if you get into a form, and then it's like: form, list, nine items, list item number one, form element label, you know, input, type, text, email. You're kind of like you're adding verbiage that the screen reader is going to read out.

CHRIS: Right.

DAVE: So that's not necessarily helpful to somebody who just wants to hear, if you think of it, just wants to read what the page says. You're basically putting widgets and BS that they don't want to even hear in the form. I kind of lean away from the OL/UL sort of sector.

CHRIS: Even DL --

DAVE: What's that?

CHRIS: Even DL probably is the same deal.

DAVE: Yeah, and DL. Yeah, because you want to kind of be aware of what the screen reader is going to announce in lists, headings, links, stuff like that. Kind of skip over that if possible. That's my personal opinion.

CHRIS: Maybe we'll go with div as being kind of the generally, possibly best way to do it for now.

DAVE: Div is good. If you want cheap padding: P. That's my final answer.

[Sound effects]

DAVE: There we go. I have an audio question here in my email from Luke Whitehouse. Is that right?

CHRIS: Mm-hmm.

DAVE: That is awesome. That's like a -- sorry. Is that a hamburger restaurant? No, that's White Castle. Here we go.

CHRIS: That's where the president lives.

LUKE: Hey, guys. My name is Luke Whitehouse. I'm a student and front-end dev from the U.K., and I've just got a quick question for you both regarding task runners and tools in general. Over the past few weeks, I've been getting into groups with Grunt thanks to your blog post, Chris, over on 24Ways. However, I've come across a new blog post, which basically tells me to stop using Grunt and jump over to Gulp, which apparently does the same thing, but better. So my question is, do you two personally change the tools often that you use, or do you tend to stay with the same one for a long time? In this instance, will you switch to Gulp? It seems these days that there's a new tool coming out every day, and surely this can't keep going on. Anyway, thanks for your time. Keep up the good work and…. See ya."

DAVE: All right, thanks, Luke.

CHRIS: So weird timing because we just talked about this exact thing, right?

DAVE: Yeah, more or less.

CHRIS: So back up if you're just joining us now. But I like the sentiment of how long do you stick with a tool because you already know it. I think that's maybe what we could use out of this question.

DAVE: Ew, that's a good question. In our industry, something new comes out every three weeks, I would say, on average, some revolutionary new tool. Macaw just came out, right, very recently.

CHRIS: Mm-hmm.

DAVE: Yeah, I mean, I'm going to say the same thing. Just use something and don't worry about what you're using. Don't have FOUTWT, which is fear of using the wrong tool. We all know that, right?

But how often do you tend to change? I find that if I realize I've been with something a year and a half, like probably not doing it the best way possible. A year and a half in Web time is a long time for something to change and update. I try to kind of like at least experiment, like do a hello world with all the new tools as soon as I hear about them, just not to say I have a mastery. I don't pretend to do that. There are dudes who do that. But I'm more just like just to know, do I like that or do I hate that.

ajpiano, FOUTWT -- fear of using the wrong tool -- FOUTWT. That is good. Thanks. Thank…. I'm going to pull up the yayQuery soundboard--how does that sound--while we're waiting. Go ahead. So what are your thoughts? What are your thoughts?

CHRIS: Oh, yeah. I don't know that I have any.

DAVE: How often do you change it up?

CHRIS: I don't know. Everybody has some -- what is that scientific term where it's like harder to push a block that's already standing there than it is to push one that's already moving? There's a word for it.

DAVE: Sisyphean Complex.

CHRIS: Definitely. Definitely.

DAVE: Is that what it is?

CHRIS: Like stagnant, you know, but this is a different word. It's like the opposite of momentum. Dimitri Lutz … it just means everybody has got some of that, right, that it's easier to stick with things that you already know. And if there are no huge promises, if you're not having a big problem, then why switch at all? And some of that is, yeah, I agree with that. Forget all this learning something new all the time just for the sake of it. But sometimes that also prevents you from learning something that would level you up.

I think we've talked about, in the past, where sometimes it's nice just to have level up weekend or whatever where there's nothing at risk.  You've decided to explore this new territory.  Maybe you'll use it; maybe you won't, but you've set aside this block of time to attempt to level up just for the sake of it.  I kind of like that idea too, so that if you're feeling stuck with tools that maybe you don't have to.  Maybe you can choose that as a level up weekend activity. 

New question:  Dimitre Genov writes in, "I have recently dipped my toe in the waters of Node JS.  I keep hearing about this amazing tool called Socket IO, but I haven't been able to try it out and the concept still escapes me.  Have you guys used this, and could you explain what the purpose or use of it is?"

DAVE: Socket IO is a Web worker framework; I guess you'd call it. No, not Web worker, but like post message framework. So I can post a message to your browser indirectly if you are subscribing. Basically, I type something. It shows up on your browser.

CHRIS: Yeah.

DAVE: I mean, this is like ancient chat room tech.

CHRIS: Which is new technology. It seems like it should be easy, but it really isn't, right, because it uses HTTP, and the way that it works is just kind of like I am a browser; I'm going to go ask for something. And the server is like, here you go, and then it displays it. And if you want to kind of do that again, the browser is like, well, sure, do it again. I'll just refresh the entire Web page. It wasn't meant for these stable connections of, like, just keep sending me more data whenever you feel like it, and I'll grab that data and do something with it. This idea of Web Sockets is that, like more of a persistent connection or at least saying I'm open to new requests. So if you have some for me, send them, and I'll do something with them. That's maybe what Web Sockets is kind of like, right? Well, Web Sockets is HMTL 5.

DAVE: Yeah, yeah.

CHRIS: New, fancy, right? And Node just happens to be good at this real time server stuff. It happens to be a good middleman between doing those types of situations. You know, Node plus Web Sockets plus browsers is pretty cool. The problem is, you can't always count on that. Web Sockets is fairly new, so what Socket IO is like this -- I don't know -- it's like a way to have all the fallbacks for it because there are other ways you can do this.

A way in the past that they've built chat rooms way back when was something, a long polling, right? It would ask the server for something, and the serve would be like -- it would just hang on that request, essentially. Just would return nothing, and the browser would just spin and spin and spin, you know, waiting for the request. Then as soon as something happened on the server, whether it was a new message, then it would complete that request, and it would come back. Then the browser would immediately ask again. They called it long polling because it would just wait and wait and wait for another request.

You don't have to do that anymore, but Web Sockets falls back the chain of different technologies for this all the way back to that, I think. Socket IO can make this work in IE6. Is that right?

DAVE: Uh!

CHRIS: I could have screwed it up.

DAVE: Yeah, yeah, Socket IO has like a Flash kind of polyfill. If it's not supported, it can inject that sort of Flash polyfill.

CHRIS: Yeah, maybe that's the final gross one at the way bottom. I'm not sure what it is, but there's a bunch of things. Anyway, that's what it does.

DAVE: If you want an example of this, I started a thing over on the Accessibility Project GitHub. It's called WordCast. It was kind of this experiment where you talk into a microphone, and it'll automatically subtitle. And that's awesome for if you're talking to yourself, right? But if you want to broadcast that, you need to kind of broadcast. So we set up this thing. You can try it out in your browser. It's kind of in a weird state right now, but download it, set it up in Node and everything, and then run the server. Open it in Chrome. Do the microphone thing. Start talking, and you'll see subtitles. And then open FireFox and go to the same URL or the visiting URL, and you'll start seeing the subtitles in your FireFox browser. Basically, you're simulating two users sharing an experience across the Web.

CHRIS: Yep.

DAVE: Pretty cool technology.

CHRIS: Yeah.

DAVE: And that's kind of what's enabling all this.

CHRIS: The classic one is a chat.

DAVE: Real time chat.

CHRIS: Yeah, right. I mean, I'm sure there's some --

DAVE: Yeah, or even just like --

CHRIS: -- there's some Web Sockets happening right now in this window you're looking at if you're watching live in this Google Hangouts thing. There are Web Sockets happening.

DAVE: Yeah, or if you're in GitHub, and you're hanging out there, and then all of a sudden it just shows up, like the issue closed. You're like what -- who did that? That's the same thing. It's just kind of like GitHub is not just sitting there hitting their own servers every five seconds asking for updates because that would just melt their servers, so they're just like, hey, when you get an update, you tell me about it. And it's like, yeah, I can do that. It's a little contract.

CHRIS: Hmm, indeed.

DAVE: Hopefully that helps there. Hold on. Hold on. I got maybe some audio here. Oh, come on! Don't fail me. Uh! Sorry. I was doing so good, Chris, and then it just totally bombed on me.

CHRIS: Oh, that's okay. Was it a funny sound effect? Oh, it was going to be some yayQuery?

[Music - singing]

DAVE: Hey, there we go. That's all I got.

CHRIS: Awe. Let's do one from the old chat bar.

DAVE: Next question.

CHRIS: Yeah. Evan Huntley in the chat bar.

DAVE: All right, here we go. Evan Huntley: "What's your favorite open source CMS for large-scale sites? I work in higher ed and, given the size of sites I work on, WordPress often just isn't an option."

CHRIS: I think that's a weird sentiment because --

DAVE: Well, I'll tell you the first thing -- higher --

CHRIS: Go. Go.

DAVE: Well, yeah, so I know some higher ed that does do WordPress, but, man, lots of higher ed do Drupal, so that's probably the big -- higher ed loves Drupal. There's like whole higher ed Drupal conferences and stuff like that.

CHRIS: Yeah, and there may be some benefits to that.

DAVE: I would consider that, and it's zero dollars, and you're not putting your university in a place where they are in a 20-year contract for millions of dollars --

CHRIS: Good point!

DAVE: -- to some enterprise CMS dude.

CHRIS: There's something to be said about picking a CMS that just --

DAVE: Save on tuition.

CHRIS: -- other people in the world use, other people in your industry use, you know, because that way you can -- I don't know. You could go to that conference and have something to talk about or whatever, or have something in common with other people that are often doing what you're going to do. Of course, I'm required to say that it's weird to think that WordPress can't handle large-scale sites. I mean, you're aware that WordPress.com is one, single install of WordPress Multisite, right? Like it's one of the biggest websites in the world. WordPress can handle your stuff. And if it can't, there's something wrong. I don't know. It's a weird sentiment to have that WordPress just can't handle large-scale. I'd say that's incorrect. But, you know, I get it.

DAVE: WordPress is good. Let's not worry about that. But, yeah, like -- yeah.

CHRIS: Drupal, that's the answer you're looking for.

DAVE: That's all I'd say.

CHRIS: Okay.

DAVE: I'm going to pause my camera just for a bit.

CHRIS: Are you losing a little Internet?

DAVE: Drupal is the right way to go.

CHRIS: Okay. Let's just do one more anyway. We're coming up on an hour, so --

DAVE: Oh, yeah, let's do one more.

CHRIS: You pick it.

DAVE: This chat room thing has been so much fun, man. It's wild. It's like mind melting, but it's a lot of fun to get some real time questions.

CHRIS: True.

DAVE: Do you want to go to the sidebar to the other?

CHRIS: You pick.

DAVE: Okay. Here we go, sidebar question. Let's do the top question. Oh, man. Hold on. Let's see. Last minute votes here. All right. Let's do this one from Kyle Lambert. "How do you guys handle scaling CSS on large applications? I work for a startup, and sometimes there is just so much that there isn't time to think about writing CSS I am writing will affect the application in the long-term. Any tips would be great."

So in a startup, moving fast and loose, writing code, slopping it together, large-scale, it might come back and bite him….

CHRIS: This is great. I mean, this is a classic conversation. Not everybody has this because there are plenty of lone soldiers out there working on individual websites, and they have different needs and stuff. But I do enjoy thinking about scaleable CSS. What is it like working on ginormous sites like the university thing we just talked about, and maybe that's the sites and subsites and there are ten levels deep of navigation you can go. How do you write CSS that's practical for that without making it a big mess? How do you write CSS for Twitter or something that has just loads of CSS, I'm sure?

What are those techniques?  I would say number one is a style guide of some kind, and possibly a style guide like Plus, Plus like Pattern Library.  Maybe those are the same kind of thing, but think of it as like this is a type of chunk that we use that's common on our site.  I'm going to define it here so that it's that you can reuse it a bunch of times, and it's pretty easy.  

There was just an article in A List Apart about that by Susan something.  I don't know if you saw that one, Dave, but it was pretty good.  It was kind of like this will help you; do it.  

DAVE: Susan Robertson?

CHRIS: Yeah. And there's, you know, read stuff by Harry Roberts. He writes good stuff about -- you know, there's like generally the SMACSS and the OOCSS thing and that. There's a good Nicolas Gallagher article on kind of being pragmatic about your front end. Read all that type of stuff. I know that was like a major link dump without the links.

DAVE: Yeah. The best book I read last year was SMACSS by Jonathan Snook. It's all based on his experience coding up Yahoo Mail, which turns out is a kind of big Web application. So I would definitely check that out. It sort informs the discussion, so when you read Harry Roberts or even Susan's article on A List Apart, you're kind of like, oh, okay, now I'm kind of getting how modules and build up and stitched together and get bigger. That was the best book I've read, in a long time, on CSS and stuff like that, so I highly recommend that.

Then, yeah, there's BEM.  That's another strategy, but it's the same thing, basically, just a little different.  Yeah, I would start there.

CHRIS: Yeah.

DAVE: You need to figure out how to manage complexity and then scale those little fix --

CHRIS: Right.

DAVE: -- fixes and junk you add on. Otherwise --

CHRIS: There are lots of little tips, I think, that can help you get there. Like this idea of never ever style anything with an ID. It's like, just don't do it. Just don't. Let's not have a big fight about it. This is the idea. We're keeping specificity at the baseline level that we possibly can.

There's the idea of how do you name things.  Try to not name things way, way too specifically.  Come up with a naming system.  Try to think about am I naming this, am I naming this like bottom footer warning for homepage or something.  Is that the class name that you're using?  That's a little specific.  Try to be less specific about stuff or more -- have it match your brain however that happens to work rather than listening to what I'm telling you is the best way to name things.  

Name things how you name things; how you think of them. Try to match your own kind of brainwaves when you name something so that -- and I know that's just you and, on a large-scale site, that might be counterintuitive because it's a whole team. But maybe you can delegate somebody as the namer. There's only one brain doing the naming, and that will be more consistent.

DAVE: I got hung up on a name the other week. I was just like, should it be called card or module or -- and I was just stuck and so, yeah.

CHRIS: And remember that those names are for you, not the site. They have no -- they should describe how you and your team think and talk about the content that's inside of it or not even the content, but the styles that are going to come from that. That's how you should name it.

DAVE: Mm-hmm.

CHRIS: Naming it, you know -- right, like card may be more how describing what it looks like or -- I don't know.

DAVE: Yeah.

CHRIS: That's tough because it depends on what you were talking about there, but calling it like main news article because it happens to be a main news article on the site is probably not a great name just because that has to do with the content inside of it, which doesn't matter really. I'd lean more towards a class name that had more meaning to your team as far as how it looks.

DAVE: Yeah. I mean, you could just be like news article and then have a modifier class. Again, this is kind of the -- SMACSS stuff. That's like "news article--major feature" or something like that.

CHRIS: Yeah, and not like "major blue feature" too because those type of rules still hold true. Don't be so specific with your class names that they'll never have any other meaning if you decide the blue is not blue anymore, that kind of thing. That's still important, but not going so far down the path of semantic class names that you're only naming it based on intelligible content or if somebody were to view source that they could understand why you might have named it that thing.

You don't care why anybody else thinks you should have named something.  It needs to matter to you.

DAVE: And I would also recommend SAS, if you can get on it, because then you can write all your modules nested. So like when you start a module, it's on the left edge, and then you just write all the code going down.

CHRIS: Yeah.

DAVE: Hopefully not super deep, but that's kind of….

CHRIS: I like that too. It like mentally groups it together for you. There's some code advantages to nesting, but there's code disadvantages to nesting too, but I like how it -- like even if you're just writing regular CSS, like indenting stuff over so that you can look at your file and see what's related to what, which visually is pretty cool.

DAVE: Mm-hmm.

CHRIS: This is an eternal question, Kyle. Hopefully that there's a few tips in there….

DAVE: Yeah, hopefully that helps you. Well, Chris, I'm sad to say we have hit the end of another --

CHRIS: Yeah.

[Sound effects]

DAVE: -- Rapid Fire episode. Apologies if we did not get to your question in the sidebar. I think we'll maybe be doing this again sometime soon, so hopefully we can pick up some questions here.

CHRIS: Yeah, that was fun.

DAVE: It was a lot of fun. And, yeah, thank you, guys, for coming out live, tuning in. This will be later. If you're downloading this on the podcast, awesome. You can also watch the YouTube video of this.

Oh, there was a question from Ignat Robert. "What was that sound?" It's a soundboard with guns. So there you go.

And then we'll wrap it up there. Be sure to follow us @ShopTalkShow on Twitter. Subscribe to us in your podcatcher of choice. And, Chris, is there anything else you've got to say there?

CHRIS: ShopTalkShow.com.