AJ:
You sound like you're down a 600-foot hallway. And whispering.
[This episode is sponsored by Frontend Masters. They have a terrific line up of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on JavaScript developers, providing them with salary and equity upfront. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they give you a $2,000 bonus as a thank you for using them. But if you use the JavaScript Jabber link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up at Hired.com/JavaScriptJabber.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development in that Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter, and more mobile Wijmo 5.]
[This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent and their VPS’s are backed on Solid State Drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code JavaScriptJabber, you’ll get a $10 credit.]
[This episode is brought to you by Braintree. If you're a developer or a manager of a mobile app and searching for the right payments API, check out Braintree. Braintree's new v.zero SDK makes it easy to support multiple mobile payment types with one simple integration. To learn more and to try out their sandbox, go to BraintreePayments.com/JavaScriptJabber.]
CHUCK:
Hey everybody and welcome to episode 173 of the JavaScript Jabber Show. This week on our panel, we have Aimee Knight.
AIMEE:
Hello.
CHUCK:
AJ O'Neal. [Pause] Okay, I guess AJ's mute button is working oh too well. I'm Charles Max Wood from DevChat.TV. I got a quick reminder or announcement and that is that we are doing Angular Remote Conf. So, if you are looking for an online conference about AngularJS, go to AngularRemoteConf.com and you can sign up. We have early bird tickets through August 25th. So, make sure you get those because after the early bird, the price goes up.
We also have a special guest this week. And before I tell you who it is, this is the person who I went to when I started podcasting. And he encouraged me to start podcasting. So, that's why you listen to me every week. It's Gregg Pollack.
GREGG:
What's up?
CHUCK:
Do you want to introduce yourself?
GREGG:
[Laughs] I thought you just did. [Laughs] Do you want me to introduce myself?
CHUCK:
Well, I can give you all kinds of background. I remember listening to Rails Envy way back in the day. And the videos that you and Jason did, what were they, EnvyCasts? Where you had…
GREGG:
Oh, yeah.
CHUCK:
“Hi. I'm Rails.”
GREGG:
That was the first time we created paid videos. But yeah, so yeah. It started with Rails Envy doing Ruby on Rails development, did the Rails Envy podcast.
AIMEE:
I'm excited to talk to Gregg because I guess Code School or Envy Labs is where I was like, one of the very first places I went to do Rails Girls two years ago when I started to program.
CHUCK:
Oh, cool.
AIMEE:
Or RailsBridge. It was RailsBridge, not Rails Girls.
CHUCK:
So, actually in Envy Labs offices?
AIMEE:
Yeah. It was in Orlando. I don't know if they're still there. But I drove the four hours from Savannah over to there just because I was desperate for something. [Chuckles] But everybody was so nice.
So, it was cool.
GREGG:
No way.
AIMEE:
Yeah.
GREGG:
That's awesome.
AIMEE:
It was so cool. I think probably two and a half-ish years ago now, I drove down there from Savannah because they didn't have anything like that in Savannah and I was brand new. I had just heard of Rails and barely programmed anything in my life and just thought it would be an awesome opportunity. And everybody there was so nice.
GREGG:
Oh, that's awesome. That's great to hear. Thanks.
AIMEE:
Yeah.
CHUCK:
Yeah. So, most people are probably more familiar with you from Code School.
GREGG:
Yeah, probably. These days I do three things. I help advise Envy Labs, still the consultancy, still going strong. And I'm the CEO of Code School, which was acquired by Pluralsight a few months ago. And then I also run something called Starter Studio which is a three-month technical accelerator down here in Orlando that I started about two and a half years ago to help entrepreneurs. So, I do a lot of startup advising these days, less programming. But I try to get my hands dirty where I can.
CHUCK:
So, did Code School start with Rails for Zombies?
GREGG:
Yeah. I like to say that Code School was me figuring out how to monetize the kind of content that I really enjoyed creating. So, the way I always got consulting work was creating educational content. Started with a blog, went on from there to a podcast. Then I'd go and speak at conferences. Then I
would do online videos.
asked:
What would happen if I combine the kind of videos that I enjoyed producing with the interactivity of Try Ruby? What would Try Rails look like?
And so, what we ended up creating was Rails for Zombies, which was just a free thing for the community. Another one of those free things that I knew would lead to more consulting work. But Rails for Zombies just got so much positive feedback, so many people loved it that we realized, “Okay, we're going to have to do this again. And maybe this time we'll charge for it.” And so, that's where Code School evolved from.
CHUCK:
Very cool. And now you have courses in JavaScript and databases.
GREGG:
IOS and HTML, CSS, yeah, databases, a ton of different topics.
CHUCK:
Very nice.
AIMEE:
So, for those courses, how do you guys decide on what courses to put out and the content for them? Because there are so many other things similar to that, and as I was learning, I did prefer you guys over some of the other options.
GREGG:
Yeah. That's a good question. We mostly just listen to our paying customers. [Chuckles] It's like what you're supposed to do, figure out what topics to teach. So, every year around October, November, we send out a huge survey to all of our customers, paid and unpaid, to really get a gauge for what people want us to teach. And we need to look at that so that we're teaching some of the most wanted topics. And it's certainly been interesting since we're on JavaScript Jabber here, over the last three years, to see how much JavaScript has grown. It's been ridiculous because obviously we started in the Ruby and Rails community. But as we've added new JavaScript courses, that's become our most popular path, is JavaScript. So, we're always working on new JavaScript courses because of that.
CHUCK:
So, what are the topics that people are requesting these days? I know you just released an Angular course not too long ago.
GREGG:
Yeah, we released our second Angular course. We've got a free Angular course and then we're doing a, we've got a paid Angular course. Last month [chuckles] we had a really fun course, regular expressions. We did a regex course, which is a lot of fun if you can think about how we teach stuff in a very interactive and fun way. So, you start typing a regular expression and we interactively help you learn about it. Coming up later this month, we have a web animations course. So, allowing you to figure out how to use CSS to make web pages that are more usable and more animated. So, that's going to be a lot of fun.
What else? Right now I'm actually working with a UX designer so that we can actually do a product design/web design course, which is really going to be teaching you the best practices of how you do design. We've got one other design course which we did a few years ago called the fundamentals of design, which goes into things like color, choosing the right fonts, layout, grid design, all the stuff that even as a programmer that even if you are mostly in the backend or mostly frontend, it's really good to know some good layout. Because inevitably, you're going to need to do a little bit of it here or there. So, I'm excited about those two courses that are coming out.
What else do we have going on? We've got kind of a future of JavaScript course where we're going into, what is it called these days? ECMAScript 2015 or something like that? I don't remember.
CHUCK:
[Laughs]
GREGG:
So, yeah.
CHUCK:
That's a running joke on this show, what it's called.
GREGG:
Oh yeah, oh yeah? Okay. Well yeah, so we're actually creating a course that's going into all of the new cool features of JavaScript which I'm sure your audience would be interested in. That's coming out in the next few months.
CHUCK:
Now, a lot of these have a storyline behind them or at least some interest behind them. Rails for Zombies is a real example of that where you progress through things and it's all interactive. So, how do you come up with the plot or the story that people are going to follow through the course?
GREGG:
It's a lot of fun brainstorming, really. We get together and some of it's informed by topics that designers are just really interested in designing for. And some of it just fits in with the theme. For example, we were just trying to figure out… we recently hired a Python teacher. So, we're asking ourselves which theme should the Python courses be? Then it came to me and I was like, wait a second. This is Python. It has to be Monty Python, right? It has to be Monty Python. So, we're doing a Monty Python theme to two courses there.
For the web animations course, we took a, we call it Sweet Lands. It's almost like an Adventure Time theme. It's kind of fun. For the web design course that's coming up, we decided to take a page out of the Breaking Bad handbook, if you're a fan of the TV show. And it's going to be themed around Chemistry and the elements, because the title of the course is 'The Elements of Web Design'.
And you know, our goal for Code School when you come and check us out, we want you to feel like you're opening the door and walking into a GameStop. We want you to feel like you're walking into a GameStop, not a boring library where you have to pick a book off the shelf. We want you to feel like you're playing. And we take that so far as we use gamification terms. Because I know that if somebody told me that I had to take a chapter and then take a quiz at the end, I'm not going to be as interested than if you tell me I can play through a level and then take challenges. So, even the words that we use along with the themes and the animation, it's all around keeping you entertained as much as we can while keeping it extremely educational.
AIMEE:
Speaking of that, do you think that you try to focus on a different audience or target different people as opposed to a site like Pluralsight? I guess even if you're trying to think of a subscription that a company would pay for, do you ever have issues where the company might be more willing to pay for something like Pluralsight and they maybe are a little hesitant because of Code School having this entertainment aspect, too?
GREGG:
That's a really good question. I honestly haven't heard a lot of people talk about the entertainment aspect of it being a detractor. But if you're looking at those two products, Pluralsight and Code School are two very, very different products. Pluralsight, those guys release several courses a day. Historically, we release one course a month. [Chuckles] So, the way developers use it is very different.
Developers primarily use Pluralsight as a reference library, right? It's more like Stack Overflow. Like when you run into a problem or you need to learn this new tool that's a part of this other framework and you need to reference some big library then you go to Pluralsight. You type in, you search for it, you find the topic, you watch the video, or at least just the part of the video you need to learn, and then you move on. Like you would be searching for a Stack Overflow answer.
Whereas with Code School, we only have just over, around 50 courses. And it's our goal to become the place where you start learning. It's my hope that the next time you need to learn a new JavaScript framework you go, “Well, I could pick up the book. I could read tutorials online. But I know if I go into CodeSchool.com, if they've got a course on this, it's going to be the most effective use of my time. I'm going to be able to get up to speed quickest. And my odds of failure are low.”
I tend to find that if you're picking up something new, especially technology, if you're going to fail, if you're going to get frustrated, odds are it's going to happen in the first 15 minutes when you can't install it right, can't configure it right, and you're missing a dumb semicolon somewhere. [Chuckles] So, at Code School we try to take out that frustration of getting started so that by the end of one of our four-hour courses, you feel like you have a confidence. You feel like, “Oh. Oh wow, I guess I can do this. It wasn't as hard as I thought.” And then you might have the patience to go and watch a few more hours on Pluralsight because you know you have the fluency and it is possible for you to learn.
AIMEE:
[Inaudible] cool, yeah. That's the way that I've used it in the past. I was curious and that was the goal in mind.
GREGG:
Mmhmm, yeah.
CHUCK:
So, how do you structure your courses so that they reach that endpoint where people are, “Okay, now I get this enough to go take the next level”?
GREGG:
Yeah, because certainly when you take a topic like JavaScript for example or even Angular or even Backbone, and you want to do it justice on a course, there's a certain urge as a developer who likes to be explicit to think, “Okay, well in order to do this piece justice I need to tell everything that people need to know.” [Laughs] I need to write a book. But the way I look at it is Code School, our courses, I like to think of our courses as the first four or five chapters of a book.
So, when you get into a course, we split it up into quick 5 to 10-minute videos. So, you might have anywhere between 8 to 12 of these 5 to 10-minute videos which teach you one or two topics, not too complex, because you only can hold too many thoughts in your mind at the same time. And then after you take a, if you watch a video, we immediately get you coding right there in the browser, like Codecademy or Code.org. We have you program right there in the browser to demonstrate that you understood the skills that we just taught you. And you know, gamify it, give it points, give you badges when you get to the end of a level.
But it's really in that format that we can deliver the most effective learning, I think. And what's really interesting is if you take multiple courses of ours, you'll notice that the interface is often different between courses. Because we try to find the most efficient way to teach any given programming language or framework, and often those different things need different interfaces for learning.
For example, if you're learning Git, you need a command line. You need to be learning on the command line. If you're learning Angular, you want to be able to type in some JavaScript code and see what happens. If you're learning HTML and CSS you need something far more visual. So, when you're typing CSS or HTML you actually see live what your code is doing. So, we have all these different interfaces for all these different languages so we can produce the best way to get started learning any given technology.
CHUCK:
I can see how that would work for say JavaScript on the frontend. What about if you have a course for Node.js or Ruby or something that doesn't run natively in the browser?
GREGG:
Oh yeah, we do have two Node courses. They're phenomenal. We also have, yeah one of them is
an Express course. So, we teach Node and then Express. It's a great way to get started with that technology if you're interested. And it's the same format. You learn and you code right there in the browser. You code JavaScript and we validate all your code.
And that's the other thing that us programmers like to geek out about, is if you're on our website and you submit some code, what happens? Well, if it's a JavaScript course, it could be getting executed on the client side right there in the browser. If you type, it'll write. But when it comes to anything server-side, we've got all sorts of sandboxes on our site. So, we take your code when you type it in. We run unit tests against it. We test the behavior and if you get it right. And you see that in the browser and you move on to the next challenge.
CHUCK:
Yeah, but isn't it, I guess you said you have sandboxes. I was going to say, “But isn't it dangerous to execute somebody's code randomly on your backend server?”
GREGG:
Oh, sure. It can be dangerous if you're not secure in the right ways. And certainly that's been a fun challenge over the years to make sure whether it's Ruby or JavaScript or something else, that we're properly sandboxing things so you can't get in and hack the system. And there are all sorts of creative ways that we do that.
I was just looking up, in case your listeners are interested, we actually have open sourced our client-side JavaScript runner. So, if you google for, or you can put in the show notes, it's called, I don't know how to pronounce it. Now, I should have asked somebody. It's pronounced Abecedary, I
think is how it's pronounced.
CHUCK:
Yeah.
GREGG:
Check it out in the show notes. But it basically is what we've used to execute client-side code, client-side JavaScript code and write tests using Mocha to really find out if you are answering the questions right. And that's also what's running on JavaScript.com.
CHUCK:
Yeah, so I wanted to segue into that. I guess you did that for me. When we were first contacted about having you on the show, they were saying, “Yeah, have the creator of JavaScript.com on the show.”
GREGG:
[Chuckles]
CHUCK:
And I went and looked at it and it's kind of the same thing. It's a progression through the basic things that you're going to want to know to do JavaScript. First of all, how did you get the domain JavaScript.com?
GREGG:
You know honestly, it was just a domain broker just showed up. He showed up one day and said, “Hey, I've got this domain, JavaScript.com. Are you interested?” And I said, “How much do you want?” And he said, “Six figures.” And I said, “No way.”
[Laughter]
GREGG:
But I went back and said, “That's a great domain. JavaScript's a great language. Any chance I could convince you to go back to your client and tell them what we might do with it?” And so, I detailed that we would use the website for good. We wouldn't be selling things on JavaScript.com. We would use it as a starting point to try to do our best to represent the language. And I said, “Given that, do you think your clients would be willing to go down in price?” And luckily, they said, “Yeah.” They said, “Sure. That sounds actually good and we'll be able to go lower than that.”
And there's a good reason why we're able to spend a good amount of money on these types of domains. And that's because historically if you look at… because Rails for Zombies was the first free course that we put out there. And it generated enough traffic. And it's still free, but people sign up for Code School accounts and some of those end up going onto becoming Code School subscribers. And because of that, we can attribute that free property to generating enough revenue. And we've done that over and over and over again with websites like Try jQuery where we've got people learning stuff for free.
And yeah, so it's only because we've done that over and over again that we can attribute a big monetary value to a free property. Because we know if we buy JavaScript.com and we put free stuff on there, some of those people will go on to convert to be Code School subscribers. So, eventually we can get our money back. And we know that we can spend a good amount of money on that property. So, it's cool that we can have that confidence to know that we can invest in this, do something for the community, and still in the long term get our money back.
AIMEE:
So, is any of that open source? If I wanted to contribute different learning materials or something like that, what's the process for doing that on JavaScript.com?
GREGG:
That's a good question. We have a team of volunteers. So, some of the people that work on JavaScript.com are trying to run it for the community. So, if you go on there, I think there might be a link to contact us. Right, okay. So, if you go to JavaScript.com and you click on About and you click on Let Us Know, you can go on there and you can talk to the guys about contributing or if you want to add something. And I think they're going to be really liberal about, they have been really liberal about getting feedback. I don't think they've open sourced it yet. They may decide to do that in the future. I don't really see any reason why they wouldn't want to do that. So, they might. And you can encourage them to do that. I encourage you to encourage them to do that. [Laughter]
GREGG:
So, because that was our purpose of the website, was to create something for the community. And we definitely want to make it better. So, if it's something you want to help with, definitely get in touch with them. You'll notice on there, there's a couple of things you'll notice when you go to JavaScript.com. You'll notice that we've got a fun tutorial on there that gets you started in the same way that we c1reated Try Git. It's Try JavaScript. We push people over to our new section where if you have your own JavaScript news whether it's a library you're working on and you want to spread the word, you can post that for free onto JavaScript.com and let other people know about it.
Then we also plug on there our free podcast where you can listen to the latest news in the JavaScript community or subscribe to our mailing list. There's also that on there. And then lastly, we realized we wanted to plug a couple of the best resources for getting started with JavaScript. Now, not the best free resources. So on there we got a bunch of different ones that you can give it a try.
AIMEE:
I tried to get my husband to try out the exercises on there. It didn't go as well as I'd hoped. [Laughter]
GREGG:
Oh no, what happened?
AIMEE:
No, it was good. Just for some reason, he just can't seem to be bitten by the bug like I was. [Chuckles]
GREGG:
Interesting.
AIMEE:
Trying to force it on him doesn't work. [Chuckles]
GREGG:
Ha, that's funny.
CHUCK:
So, I have to wonder a little bit, because I definitely have some courses that I've been thinking about putting together. And I like the format of being able to actually type the code in the browser and then just have it run and have people get the feedback that they need. How do you design the exercises? How do you decide, “Okay, these are the things that they need to use or do and then these are the exercises that we're going to put them through”?
GREGG:
Oh, yeah. There's a whole process these days. We've gotten really good at it, to the point now that we can replicate the process pretty well. And even just the way that we create courses, I could talk about that for days. But you were asking about the challenges. So, what we try to do with the challenges is break down the core concepts that we're teaching in each video. And then we go through and try to create a storyline, right? So, if you had a bunch of different challenges that were all different examples, it'd be kind of rough if you had to learn a new example, a new web application you're building.
So, first of all, we try to make them follow a step-by-step storyline where you're building a web app and you go through, “Okay, first step is do this. Second step, do that.” And we've got different kinds of challenge types, even. If you've taken one of our more recent courses you might notice that prior to the last year when you went in to take a coding challenge, it would just have one description of what to get done and it would say, “Ready, go.” Now, we break down those into different tasks. So, you might do a challenge that has four tasks involved. And you're shown the first task and you type one line of code. And that shows the first task complete. Then you go to the second task. And you type a little code, and then the second task complete. So, we break things down into that so that you can make sure that you're doing things step-by-step rather than having to write five lines of code in order to get it right. There's five tasks and it's one line per task and you're a lot less likely to get stuck and not figure out where to go.
Was there any more? When you say how we put together challenges, can you be a little more specific?
CHUCK:
So, I've done some workshops in the past. And I've actually, I show up and I walk people through it. And I really like that aspect of things. I think people learn better when I explain something to them and then make them do it, which is the process that you go through with Code School. The thing that I'm really interested in is, okay, so now that I've got this example that I want them to put together or you're calling it a challenge, the same idea. How do I put that on my website so that people can do that kind of work on my courses?
GREGG:
Right. Okay, well the first thing that you should know is that you don't necessarily have to do the inbrowser thing. I think that there's just as much value in providing people things they download and they run on their own computers. And there are certainly ways of doing that. We've done that before with some of our… even before Rails for Zombies. I think when we did Rails 3 videos, we put together incomplete applications. And we would make people download the application, go into this directory, and apply what we just taught them in the video.
So, there are some really good ways that you can actually have the same 'learn by doing' and just requiring people to download the project and run the project and improve the project, and tell them, “Go look at the comments on this line and follow the instructions there.” So, you can do that same 'learn by doing' thing without having anything in the browser. And I think some people don't realize that. But if you do want to do things in the browser, well, it's going to take a lot of work. [Laughter]
GREGG:
But if you're doing JavaScript, I think the best place to start is that library I mentioned earlier, Abecedary. Because that shows you how we use iframes to really validate people's code. So, you would be able to do that. You'd have to combine that with getting a good editor in there and whatever the design you would like. But I think that would be a good starting point if you wanted to do it on your own and you're using JavaScript. There's other libraries that we… even some ones that we've open sourced for, I think there's a Ruby one that we open sourced that allows you to run your Ruby code out there. And I also think that Codecademy has open sourced some of their inbrowser executors as well.
AJ:
So, I'm actually really interested in that technical aspect of running code in the browser. Can you talk about any of the technical details of how that's done? You said you throw stuff in an iframe.
What else do you do?
GREGG:
Let's see if I can figure the answer to that, because this is not something that I worked on. This is other people. So, I think the proper answer would be: I'm not qualified to answer that question.
CHUCK:
[Laughs]
GREGG:
But Abecedary uses Mocha for running all tests. And you can extend it with CommonJS style modules. It has a custom Mocha reporter to get feedback because obviously you want to take the error results you might get from running the test and give people more understandable feedback. It also uses something called Chai. Are you familiar with that?
CHUCK:
Yeah.
AIMEE:
Yep.
GREEG:
Yeah. That's the behavior-driven development, test-driven development assertion framework for Node.js. Yeah, so we use that with Mocha. But yeah, I can't really be too technical with that. But check out Abecedary.
AJ:
Alright. Thanks.
CHUCK:
So then, as far as… because you said that your courses are basically starter courses. And so, you have 8 to 12 what, 8-minute courses or 12-minute courses. Or maybe I got the numbers mixed up.
But then how do you decide…?
GREGG:
Each course is around about three to four hours long, based on how you get through it.
CHUCK:
So, how do you decide what to put in and what not to put in?
GREGG:
It's difficult, because obviously there's a lot to all these different technical topics. So, we try to think about what is going to be the most effective use of our time in there? What are the most important components to learn when you're just getting started? And also, what can we teach people so they can immediately start building things and get that feeling of success so they can move on? They can get excited so they can pick up that next book.
I think so many technical tutorials run into the problem of teaching syntax, syntax, syntax, right? So, it's like level one, here's the syntax for doing this. Level two, here's the syntax for doing that. Oh, and you just want to kill yourself. So, we always try to make it so that by the end of the course we're building something together so by the end of the course you have all the tools you need to actually construct something.
And unfortunately what that might mean is that there might be six different topics you need to learn in order to build it. So, what we'll have to do is we'll have to skim through those six topics to get to that point, not really focusing on any one in very good detail. But that's not important. We need you to get to the point where you can start building as quick as possible. Because that's how we're going to get you feeling successful about building in that particular technology.
CHUCK:
I really like the approach. And it does make it okay then to hand-wave over something and say, “Look, you'll understand this maybe a little later. But right now we just want to get you to the point where you can get results.”
GREGG:
Oh yeah, totally. We have that battle. It's a constant battle when you're building a course, what you leave in and what you leave out. And we have this whole process around how we create content from the outline to something we call course book, into slides. We're really hardcore about even teaching with slides. So, the way that we look at it is you should be able to watch a Code School video, turn off the volume, and still get everything. Everything needs to be represented visually. So, that's why we're hardcore with slides, because we can arrange things and teach visually so that you don't really have to even listen. Some people are more auditory learners. They want to hear. Some people are more visual. But there's been research done, and I believe it, that the most effective learning combines the two effectively. And that's really what we strive for.
CHUCK:
So, it seems like there are a lot of companies out there doing online learning for programmers and programming. I'd like to know, where do you see things going from here? Because there's Codecademy and Khan Academy and Code School and Pluralsight and Lynda.com has a whole bunch of stuff.
GREEG:
Yeah, definitely. I still really think online learning in general is still at its infancy. There are still best practices that are getting established. And the greatest evidence there is looking at, if you look at all of the different in-person teaching techniques and you think about how they've gone online, there are some that are still blatantly missing. [Chuckles] Like there are some techniques that are missing. And they're just starting to come along right now, like the mentorship model. Even that, it's only recently that that's starting to come online.
I think there are only two companies I feel like in the programming space that have some really interesting hybrids. So, you've got developer bootcamps and you've got Code School, Lynda, Pluralsight, all that stuff. But what's in between the two? What is halfway in between? And in my mind, there are two companies that are halfway in between right now and doing it successfully. The first one is Thinkful.com. And the second one is Bock.io. Those companies have mentorship programs. So, instead of a bootcamp where you're paying probably three or four thousand dollars a month, with these websites you pay a couple of hundred dollars a month. And they have a curriculum that you go through. And you have a mentor that you meet up with on a weekly basis that helps you through it. And you have a whole support group, right? So, it's sort of a hybrid model between a bootcamp and a code school.
And I feel like there is so much opportunity to figure that out and figure out how you create the optimal learning environment online, because there are so many principles that are missing from Code School. It's ridiculous. We just focus on one thing and we try to do that really well. But it's like at the end of a Code School course, shouldn't you try to build something with what you learned? And if you wanted to create a good learning experience, that's similar to the work environment, you should probably be building something with other people. And meeting other people and building something using that technology and learning from each other and it's like, “Oh. Nobody's really doing that effectively.” There's one idea.
There's also peer review, right? So, when you create something, when you write some code, how do you get effectively peer reviewed? And why isn't there a service for that? And how do you do that correctly? So, there are also things like AirPair. So, that's again, that's trying to address the mentorship model online to make it easier for you to find the experts that you need in the nick of time, when you need it. Ah, it's so interesting, right? And then Hackends is another example of that. And Hackends actually got acquired by Pluralsight just like we did.
And then there's also evaluation. How do you figure out if people are qualified to be programming? How do you figure out to be qualified in a certain language? And how do you figure that out quickly? And there was another company that figured that out called Smarterer, if you've heard of them. And Smarterer also got brought into the Pluralsight team. So, as you can quite imagine, with these sorts of acquisitions, Pluralsight's trying to figure out, what does that feature of online learning look like and how can we make a dramatic impact? And how can we innovate? And there are lots of companies that are doing that. And I feel like there's a lot of room left in the space and a lot of innovation that I'm looking forward to.
AJ:
I've noticed with a lot of these tutorials, they seem to gloss over or not just not touch on at all best practices and security. And this is something that frustrates me. I see jQuery tutorials where they're still teaching to select on the element and do .click instead of selecting on body and then doing .onClick element. Or they show concatenating a string and putting that into HTML rather than showing using an HTML escape. And to me these things seem like if you don't know anything and you're taught the right way, the best practice way, the way that works 100% of the time, that that would be a better model. Yet I don't see tutorials picking up best practices. What are your thoughts on that and where do you guys stand in that ground?
GREGG:
Well, certainly if you find things like that in our courses, please let us know because we always are going back and updating things and improving the courses. So, if you see something let us know, because we go through and improve courses occasionally and want to create the best way to start learning. So certainly, I totally agree though. You want to make sure you teach people the right way the first time and not teach them the wrong way the first time. And certainly, that's a principle that we use when we're creating slides, even. [Chuckles]
So, you don't want… when you're learning it for the first way, especially if you're a developer, it gets really frustrating if someone is teaching you a concept and they go, “So, to do this, here's how you do it. Oh, but really that's the wrong way. So, you need to add this, too.” Oh, I just want to kill myself. And that's the worst way because you just feel like, “Okay I've been focusing on this code to learn it. I've been trying to memorize it. And now you're telling me it's the wrong way? That's so annoying.” But at the same time as well, when it comes to more complicated best practices, there certainly has to have a balance.
So, if I could teach you… the best example of that I could think of is, I don't know if your audience will be able to associate, but it's like scaffolding for Rails. So, in Ruby on Rails everybody, all of the advanced developers just hem and haw about the fact that you could write one line of code to get all this code written for you and it would just magically appear. And then you would realize as you got more into it that it's probably not a best practice to go there. [Chuckles] But you have to balance that with accessibility, right?
So, if the best practice way to do it is going to be 20 lines of complex code, the simple and more insecure way of doing it is only two lines of code, and your goal is to get people learning and up and running and developing good enough, then well you might have to skip the best practice and leave that for later. Because you're going to lose people if you have to teach them 20 lines of code.
No one's going to use it. They're all going to go away.
CHUCK:
Yeah, I like the example of the scaffold mainly because, well for one, if somebody's using scaffold what it does is it just generates basic CRUD operations on a data object or a model in Rails, if you're not familiar. And the thing is it's not broken. It's not wrong. It's just not always what you want. And so, it's not always the best starting point for the code that you're going to write that's going to go into production. But that said, yeah if you want a quick example so that people could start fussing with views or fiddling with an existing set of code that you can just hand them that Rails generates for them, then it's a really convenient way to teach people. I think if you're coming down to security or something else it's going to come around and kick somebody in the head, because they're doing something that is legitimately wrong and shouldn't be done that way ever at all, then that's a different argument.
AJ:
I would think that with the security stuff, if you introduce how to make something vulnerable, it seems like you could introduce how to secure it at the same time. If you introduce how to concatenate strings, at that same moment you could introduce, “This is how you escape a string.”
GREGG:
Yeah, I agree.
AIMEE:
I think too at some point, it's a little bit on the person learning to take responsibility. [Laughs] as long as the person putting out the material is not putting it out in a false sense, like “This is material to get started and we're thinking it's going to take you this percentage of the way and it's on you to finish.” So, I love all these resources as long as they're not trying to make themselves out to be something that they aren't.
CHUCK:
So, is there anything else that we should dig into or talk about?
GREGG:
What is the JavaScript Jabber audience interested in?
CHUCK:
Well, I think we've talked about most of those issues. I think the security was probably one. And then just JavaScript.com and Code School. A lot of people have learned to code through those.
GREGG:
That's awesome. That's great to hear, yeah. Please do give us your feedback, if you have any questions about Code School or you see any of those security bugs, [chuckles] or if you want us to create a course. You can go on there and vote for which courses you want us to do next. Definitely keep an eye out for that. Oh, and if you need to learn regular expressions you've got to check out our latest course on regex. It is awesome.
AJ:
I want to check it out and find out how much I don't know.
CHUCK:
[Laughs]
GREGG:
Yeah, you're bound to take something away from it. I know I did.
AJ:
I use regexes like they're going out of style. But I still… regexes are like vim. You can spend 10 years using them and still only know 10%.
GREGG:
[Laughs] Yeah, totally. Yeah, I remember back in the day, I had an earlier job at a company called MP3.com back in the day. They were a big Perl shop. And I remember that's where I really got exposed to regex because I had to do all of these file parsing on the command line. It's also where I earned my Unix command line chops, throwing around commands like [rep] and sed. I think I used sed a lot with regular expressions to parse through these massive tab-delimited files of email addresses to inject them into the database.
CHUCK:
Does it teach people like AJ that it's 'reg-ex' instead of 'rej-ex'?
GREGG:
[Laughs] Yes. I was tempted to say something about that. I only recently learned about that as well, where it's like 'gex' not 'rej-ex'.
AJ:
Look, I don't care what you say. It's a 'gif'. It's 'rej-ex'. It's OSX.
CHUCK:
That's right.
AJ:
And it's not my fault if the people that created it did it wrong.
GREGG:
[Laughs]
CHUCK:
Yeah, we love our 'rejular' expressions.
GREGG:
[Laughs] 'Rejular'
AJ:
We don't call it 'vair'. We call it 'var'.
GREGG:
[Laughs]
CHUCK:
Alright AJ, whatever you say. Alright, well should we go ahead and do some picks?
[Once again this episode was sponsored by BrainTree, so go check them out at
BrainTreePayments.com/javascriptjabber. If you need any kind of credit card processing or payment processing in general, they are a great way to go and we appreciate them sponsoring the show.]
[This episode is sponsored by TrackJS. Let's face it. Errors cost you money. You lose customers, server resources and time to them. Wouldn't it be nice if someone told you when and how they happen so you could fix them before they cost you big time? You may have this on your backend application code, but what about your frontend JavaScript? It's time to check out TrackJS. It tracks errors and usage and helps you find bugs before your customers even report them. Go check them out at TrackJS.com.]
[This episode is sponsored by Code School. Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. They provide immersive video lessons with inbrowser challenges, which means that each course has a unique theme and storyline and feels much more like a game. Whether you've been programming for a long time or have only just begun, Code School has something for everyone. You can master Ruby on Rails or JavaScript as well as Git, HTML, CSS, and iOS. And more than a million people around the world use Code School to improve their development skills by learning or doing. You can sign up at CodeSchool.com/JavaScriptJabber.]
GREGG:
I totally have it. Can I go first?
CHUCK:
Sure.
GREGG:
Mr. Robot. Anyone else watching Mr. Robot?
CHUCK:
No?
GREGG:
Oh my god. If you are a programmer and you liked Fight Club maybe a little bit, Mr. Robot is a show on USA I believe. And it is, oh it is so amazing what they did. They paid tribute to programmers in a huge way. And it's very Fight Club-esque, very anti-establishment. And anybody who's a programmer is going to absolutely love it. Check it out.
CHUCK:
Alright. Aimee, do you want to give us some picks?
AIMEE:
So, this would probably be maybe old news by the time this comes out. But I've had a ton of fun over the past week looking at the hashtag floating around on Twitter, the #ILookLikeAnEngineer. I don't know. It's just been a ton of fun to filter by that and look through all these pictures. So, if you haven't looked at that, you should. It's kind of cool.
And then in our emails going back and forth we contemplated talking a little bit about WebAssembly. So, I started looking into that a little bit. And I was going to pick a Medium article that's an interview with Brendan Eich that I thought was a pretty good starting point. And that's it.
CHUCK:
Yeah, we should get him back on to talk about WebAssembly. AJ, what are your picks?
AJ:
So, I have had a Raspberry Pi 2 for probably a month or two now. And it's just been sitting around because I've been using my regular Raspberry Pi for doing the stuff I'm doing. But I started actually doing development on the Raspberry Pi 2 and switching over a bunch of stuff to use Node Cluster. By the way, don't ever store a variable in memory. Always use something like Redis [chuckles]. Because when you go to use Node in multiple processes, it's no bueno. But anyway, and the Raspberry Pi 2 is, it's faster than I thought it would be. I think part of it's because it's got a lot more memory. Instead of 256 megs it's got a gig. And then it's got the four cores. So, when Node starts up, whatever else it's doing, Node has one core to start up on. So, I'm enjoying development on the Raspberry Pi 2. And it's a little less frustrating because it's a little less slow.
CHUCK:
Awesome. I'm going to go ahead and pick Periscope, which is the… I don't know exactly what to call it. It's kind of a broadcasting but Twitter bot. You basically get on the app. You fire up a video and then you just talk to your phone. And people can get on. It posts a link to Twitter and then people can get on and they can talk back to you, chat back to you. And that all shows up on the screen. And then they can also send you hearts by tapping the screen. And so, if they really like what you're talking about or they like your idea or you can ask them to give you hearts if there's something that you want them do, you want that kind of immediate feedback on something. Anyway, I really enjoy it. And I plan on doing some more Periscopes. So, if you want to hear a little bit more about what I've got going on, I don't know that I'm necessarily going to save the videos. They disappear off of Periscope after 24 hours. Anyway, I'll be doing that over the next few weeks. So, go ahead and follow me on Periscope. You can get the app on Android and iOS. You can watch the videos online, but you can't interact with them the same way.
So anyway, those are my picks. And thanks again, Gregg, for coming.
GREGG:
Yeah. Thanks for having me. It's good talking to you, all you guys. Thanks.
CHUCK:
If people want to find out what you're up to these days or follow you, what are the best ways to do that?
GREGG:
Yeah, you can just follow me on Twitter. I'm just @greggpollack on Twitter. That'd be the best way to do it.
CHUCK:
That's Gregg with an extra G on the end.
GREGG:
Yeah.
CHUCK:
Alright. Well, thanks again. We'll wrap up the show and we'll catch you all next week.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at
JavaScriptJabber.com/Jabber and there you can join discussions with the regular panelists and our guests.]