← Back to Code School


Continually learning and improving your craft can be tough, but it’s necessary for becoming a better developer and expanding your skills. So here at Code School, we’ve made an easy-to-follow learning roadmap to help usher you back to school.

Level Up Essential Skills

Even if you use a technology every day, there are small improvements you can learn that will lead to big payoffs in productivity and performance. Improve performance quality and safety with our Best Practices courses, then take on version control in Git Real, and Discover DevTools to optimize your dev process and speed up your workflow.

JS Best Practices

Rails Best Practices

Git Real

Discover DevTools

Explore Front-end Frameworks

Figuring out which JavaScript framework works best for your project is important, so we’ve given a comparison on our blog. Each has its own strengths and weaknesses, so try them out for yourself to find what works for your build. Play through our Angular.js, Ember.js, and Backbone.js courses for a full introduction to the benefits of each framework and a chance to use each syntax in the browser.

Shaping Up with Angular.js

Warming Up with Ember.js

Anatomy of Backbone.js

Speed Up Your Workflow

As a developer, you’re always looking for ways to get the job done faster – coffee can only take you so far. Opt to learn CoffeeScript and Sass instead, and get more done with less code.

A sip of CoffeeScript

Assembling Sass

Build Some Apps

Creating something tangible with all the new knowledge you’ve gained can really help your learning stick. Watch our Soup to Bits screencasts to build a reading list app with Ruby on Rails, Ember.js and Angular.js — you’ll end up with the same result, but will cement your skills as you take different roads to get there.

Soup to Bits: Rails for Zombies 2

Soup to Bits: Warming up with Ember.js

Soup to Bits: Shaping up with Angular.js

Try Something New

Now it’s time to push your boundaries and try out a new technology. Learn about building iOS apps with Try iOS, become a data master with Try R, or give Ruby a shot with Try Ruby.

Try iOS

Try R

Try Ruby

To help you get back to school and start learning, we’re dropping the cost of our annual subscription by more than 30% until Friday, August 22. Enroll now to get an entire year of courses, challenges and screencasts for just $199 — welcome back to school!


Learning to code shouldn’t be complicated, especially for those just starting out. That’s why Code School offers courses that start with the basics and progressively get more advanced. We organize courses into Paths to make it easier to find the course and technology you want to learn. With Paths in Ruby, JavaScript, HTML/CSS, iOS and additional Electives, there’s something for students at any level. And because each course features a unique theme and narrative, it feels more like you’re playing a game than sitting in a classroom.

So say you’re a beginner — you’ll want to start at the top of a Path (hint: look for Try, Free and Orientation courses) and move your way down. If you’ve already mastered front-end development, try back-end to round out your skills. If you’re just not sure where to start, the first level of most courses is free so you can test drive a course before making a commitment.  As you beat courses along a Path, you’ll rack up points and earn badges to show off your progress and secure bragging rights.

Most courses start off with a quick video before sending you straight to coding challenges in the browser. We think the best way to retain information is by using it, so you’ll always be learning by doing. If you choose to start out with a more advanced course, make sure you check for course prerequisites — you can find them on the right-hand side of the course page, next to the Course Overview.

Need help finding a starting point? Here’s a handy list of the recommended courses for beginning each Path:


Try Ruby

Rails for Zombies Redux


JavaScript Road Trip Part 1

Try jQuery


Front-end Formations

CSS Cross-Country


Try Objective-C

Try iOS

If you ever get stuck along the way, you can buy hints throughout the challenges, use the community forum to start discussions with other users, or contact us.

If you don’t have time to play a full course, we also offer screencasts that complement and build upon course learning. Check out our Code TV, Soup to Bits, or Feature Focus shows for a variety of screencast content. Between our courses, screencasts, podcasts, and blog posts, we’re always releasing new content to quench your programming thirst. So, what are you waiting for — get started!


As a designer at Code School, I love getting to share my design process. Mastering any skill is about the personal journey of learning, and creating visuals for the Mastering GitHub course was a challenge I welcomed. I’ve never really attempted character illustration and I’m not well-versed on the ways of the samurai — mostly because I’m not a samurai. Even when it comes to pop culture, I am but a novice. So here’s how I went about preparing for the design of our upcoming Mastering GitHub course:

Visual Research

I did as much of this as I could. I had lots of help from Google images, browsing endless amounts of imagery, taking screenshots like there was no tomorrow, and watching various movies, anime shows and whatever else offered clues for this theme. Part of my process required spending a fair amount of time letting these things soak into my mind and getting the feel for the overall picture. I browsed my folder of screenshots over and over and what stood out were things like the bonsai and cherry blossom tree, lanterns, patterns, and of course, the sword. 

Defining the Character

The next big thing I needed to do was develop a character for the course. When I was little and watched cartoons, I always wondered why the characters never changed clothes or hair styles from day to day. Now I understand it was for character consistency and I suppose branding. To create a character that would be recognizable from multiple angles, I defined the head/face with a series of shapes.   


Drawing by Hand

I created all the final files for this course in Illustrator (no Photoshop on this one). Before I even began in Illustrator, I made quick sketches of whatever I thought I may use in a scene. After scanning in the hand-drawn poses, I recreated them in Illustrator with a basic color pallette. Here are a few sketches and a final rendering of one set.




Putting a Scene Together

To put together a scene, I selected a pose and built elements around it — working in one-point perspective. Most comic books and other Manga-esque illustrations use drastic angles and really dynamic lighting in their scenes, but I didn’t end up taking that route here. It wasn’t a deliberate decision I made, but really just the way my work developed. 

Let’s take a look at the seated pose. I used this in combination with a quick sketch based on various movie scenes.


In the next step, I layered in different elements like the ground plane and the sky in the background.


I added in rocks and cherry blossoms for more visual interest. This also helps to establish the mat as something that sits on the ground rather than hovering slightly above it.



Lastly, I added the people in the background. I could generalize them to some extent, but each person in the background required a fair amount of attention. I didn’t want them to look like they were just stamped in over and over.



After finishing up the main course designs for Mastering GitHub, I designed the set of badges to be earned throughout the course. I really wanted to make these badges feel like a progression of skill and provide a sense of reward for the user. Unlike the course scenes, I didn’t sketch these out beforehand but worked entirely in Illustrator — primarily because I had established the overall course look and had a general idea about what I wanted to include. Here are a few of my favorites.


Designing this course was a rewarding personal journey for me, and I hope you’ve enjoyed the design preview. There’s much more to see in the Mastering GitHub course, so get ready to play it this month and earn all the badges on your way to becoming a GitHub master!


Yesterday we announced Code School’s new Feature Focus screencast series.

In this series, we pick a popular web-based product and explore a few of its key features. We do this by building our own version of these features in their most simple form. 


As a viewer, if you ever need to implement a similar feature in your own projects, you can watch the Feature Focus series to find reference code and feature suggestions. But wait, THERE’S MORE!


Each 20-minute episode is split into two parts that cover a single feature. First, we go over our version of the feature by briefly looking at the code and discussing our design decisions. In the second part, we meet with a developer from the original product team and show them our code.

While meeting with the product team, they give feedback as we contrast our simple version with their fully developed version. This leads to interesting conversation about how each team arrived at their current product version and what technical challenges were faced along the way.


The first product we focus on is Basecamp, one of the leading project management apps. In our feature review of Basecamp, we chose to implement search, message notification, timeline, and infinite scrolling. We then flew to Chicago to meet with David Heinemeier Hansson, founder and CTO at Basecamp, and the creator of Ruby on Rails, to get his feedback on our version of code.


The first Feature Focus screencast is available for free, and the source code is up on GitHub.

Be sure to join our discussion in the Code School Forum and let us know what you think. We hope you enjoy watching this series as much as we’ve enjoyed producing it!


The Code School team is made up of many innovators, so things never stay the same for long. We spend a ton of time creating courses and updating the technology behind courses. Our newest update is a course player engine that is changing the way we create courses and the way you play them. 

In the olden days, all Code School courses were created as self-contained Rails apps that communicate with the main codeschool.com site to track things like progress and points. This worked great for awhile, since it allowed us to add features and innovate on each course. Fast forward to 2014, and we were feeling the pain of maintaining and updating thirty or so slightly different apps. This mounting pressure prompted us to start developing a new course engine that would tackle these issues.


Our new course engine is a single app that is capable of playing course content stored in version controlled text files (they look a little like markdown). This engine was built from the ground up and designed to share templates and features across all courses. Now, if we need to retrofit a new video player we don’t have to change and deploy thirty apps, we can change it once and it’s done.

The templating system uses AngularJS directives to simplify our complex interfaces. For example, when a designer wants to change the position of the instructions in a challenge, they can simply move an <instructions></instructions> tag instead of needing a dev to change more complex code. The same can be said for <code-editor></code-editor> and the ever-popular <challenge-tasks></challenge-tasks> UI element that’s used in the Shaping up with Angular.js course.

We’re also using this new course engine to create new tools for course production. These tools will help make the production process faster and more efficient, so we can get more content out each year. This also allows our designers and front-end team to work on other cool things, such as improving the user experience on our site and designing/building the next generation of challenge interfaces. We’ve also begun working on a course builder so our instructors can build courses as they write content, which should decrease the amount of edits and tweaks that slow down that process.

You might be wondering, if all new courses share the same interface elements, what happens to that innovation Code School loves? This new course engine gives our developers more time to innovate as we wait for content to be finalized. That being said, we’ve got some really awesome things in the pipeline for new courses that we can’t wait for you to see!

To play our courses that are already using the new course engine, check out Shaping up with Angular.js, Discover Drive, and JavaScript Best Practices. If you have suggestions for new Code School features, you can submit your ideas here. We’re always looking for new ways to improve your educational experience.



The design teams from Code School and Envy Labs all recently attended the Front-End Design Conference in St. Petersburg, Florida. Our very own Drew Barontini was one of the speakers, explaining how to think through writing modular CSS. Never one to do only what is required, Drew built his own HTML slide app with AngularJS. Of course he open-sourced it, along with a way to do a version of slides with transcripts.


If you are interested in Thinking Modular CSS, check out his actual slides and slides with transcripts.


Having recently split our design teams to increase focus for each company, it was great to have all of the Envy and Code School team members hanging out together. This conference has some history amongst the teams, as it is how I met many of them. A few team members have attended since 2010, Jason VanLue spoke in 2012, Justin Mezzell spoke in 2013, and Drew Barontini teamed up with Nick Walsh to share their MVCSS approach to front-end development last year as well.

In addition to the fun and snacks, there were some fantastic presentations. While they’re still available from Twitter, you can see the tweets shared, or check out the list of wrap-up posts and notes from attendees.

Like-minded people

The best part of conferences is the people who attend. It is such a wonderful feeling to hear people share their knowledge and then talk shop with peers. In the video below, Daniel Ryan shares some thoughts on what inspires him. Part of his message is that “being able to do something where you can go to bed at night knowing that you didn’t just write code, but that you impacted someone’s life.” This is near and dear to our hearts at Code School, as we work to help others grow their skills.

Meet the team in Portland


After running this conference for six years, this year was the last Front-End Design Conference in St. Pete, with our finale coming up in Portland on August 22 and 23. The Envy design team and some of the Code School design team will be there, enjoying the beautiful city and local community.

Keep an eye out for new things

We love any opportunity to share knowledge and spend some time with people in our community. There won’t be any more of this specific conference after Portland, but keep an eye out for exciting things to come in the future.


When we write applications that heavily depend on network requests and access to file systems, we should always keep an eye on how data is being transferred. This is one of the areas where NodeJS can really shine.

For ultimate efficiency, especially when dealing with large data sent across the wire, we need to be able to get that data piece by piece, or chunk by chunk. If that happens, we can start manipulating the data as soon as it arrives and keep it from being held in memory all at once. We do that in Node using streams.



Streams in Node are like channels where data can flow through. They can be different types, but we are going to look at the two most common: readable and writeable.

Consider the following code:

var http = require('http');

http.createServer(function (request, response) {

  response.write("<p>Hey! Ho!<\p>");

  setTimeout(function () {
    response.write("<p>Let's Go!<\p>");
  }, 5000);


We run this code and visit http://localhost:8080 from our browser. The program first responds with “Hey! Ho!”, which the browser receives right away.

Then, five seconds later, “Let’s Go!” is sent and our program finishes the response with a call to response.end().

Turns out, the response and request objects in the previous code are Writable and Readable streams, respectively. They also inherit from EventEmitter. This is a great combination because it allows our code to interface with these objects by listening to events.


Two events from request that we’ll be looking at are readable and end:

  • readable is emitted when there’s data ready to be consumed.
  • end is emitted when the data transfer is complete.

Let’s write some code that listens to those two events.

The following code reads data from a user request and sends that same data back to the user in the response. In other words, it reads data from a Readable stream and writes to a Writeable stream.

var http = require('http');

http.createServer(function(request, response) {

  request.on('readable', function() {
    var chunk = null;
    while (null !== (chunk = request.read())) {

  request.on('end', function() {


The event listener for the readable event is going to loop through each piece of data sent by the client by calling request.read(). This function returns chunks of data in the form of Buffers as soon as they arrive on the server. The response.write function takes care of converting those Buffers to strings, and sends them back to the client.


When all we do is write data to a Writeable stream as soon as it becomes available on the Readable stream, as in the previous example, then there’s a helper function we can use to pipe these two operations together called…pipe!

The pipe() function handles all of the event listening and chunk reading behind the scenes for us.

var http = require('http');

http.createServer(function(request, response) {



pipe() also manages the data flow so that we don’t have to worry about backpressure issues that fill up the Buffer and cause our programs to freeze or crash.

I always prefer using the pipe() function over listening to the events and manually reading from the stream.

Streams in the Wild

Node streams are so powerful and so simple to use (thanks to the pipe() function) that there’s third party libraries which heavily rely on them. One example is the Gulp build system.


Gulp exposes the pipe() function as part of its own public API, so we can use it for all sorts of asset manipulation with very few lines of code.

The following code is an example of a Gulp task for image optimization:

gulp.task('images', function() {
  var optimized = gulp.src(paths.images).
    pipe(imagemin({optimizationLevel: 5})).

  return optimized;

The gulp project is a great example of using streams in a real world scenario.

The stream-handbook is another great resource for reading more about streams. Last but not least, check out the official NodeJS documentation on streams.

Have you been using Node streams successfully in your own projects? We’d love to hear about your work on our Forum!


Last week we held a Code School Live Q&A on JavaScript, which coincided with our course release of JavaScript Best Practices

If you missed this hour-long event, you can watch it below or on our YouTube Channel.

We received great questions from our community that kept us on our toes and brought a number of resources to mind. Here is the full list of resources mentioned during the JavaScript Q&A:

Thanks for your questions and for following along with our talk, whether you watched live or just now! We hope the number of questions we’re able to answer will only increase at Q&A events in the future. If you submitted a question that wasn’t answered, feel free to visit our Code School Forum and post your question for us to answer.

To get more acquainted with our JavaScript hosts, follow Carlos Souza, Adam Rensel and Jason Millhouse on Twitter.

For additional questions or comments on Code School Live, you can email me at krupinski@codeschool.com.


Two weeks ago, we held our third Code School Live Q&A event focused on all things Rails.

If you missed it, you can watch the hour-long event below, or on our YouTube Channel

During the event, Carlos mentioned a presentation he did titled Books Every Ruby on Rails Developer Should Read. You can access his presentation deck here.

Thanks to everyone who submitted a question during the event, we hope the number of questions we’re able to answer will only increase as we put on more events in the future. If you submitted a question that wasn’t answered, feel free to visit our Code School Forum and post your question for us to answer.

To get more acquainted with our Rails hosts, follow Gregg Pollack, and Carlos Souza on Twitter.

For additional questions or comments on Code School Live, you can email me at krupinski@codeschool.com.

With the launch of our new JavaScript Best Practices course, you may be wondering how we decided on each featured topic. This course was a huge undertaking due to the significant amount of material we could have covered, some of which was left on the shelf for another day. The end result is still our longest course to date, and is filled to the brim with broad applications and juicy tidbits we think every JavaScript developer should know. 


Given that there are many opinions about what makes the absolute best JavaScript code, we thought we’d illustrate just a couple debated topics to show why we think these are the top practices for performance, safety, and legibility. 

Bracketing Blocks of Code

Many folks love their unbracketed, one-line block statements. They really enjoy that they can leave off the curly brackets that conventionally close a block of code, like so: 
if(thisValueIsTrue) thisThing = done;
else thisOtherThing = doneInstead;
or the following, which can be more misleading because of its visual impression:
thisThing = done;
thisOtherThing = doneInstead; 
The above examples also apply to loops, which don’t require brackets in JavaScript if the loop executes only one statement. The arguments for the one-line block statement are usually that it tightens up code into a more legible style, and that JavaScript doesn’t even scope to blocks. The first example above does indeed save two lines of code (two!) versus the second, and does approach a more natural left-to-right reading style that some find very intuitive and useful. 

We’ve taught in JSBP that curly brackets are instead a two-character sacrifice that can be very important to make at all times, especially in team-maintained code. Check out what happens in the second example above, if code is added (ostensibly by someone else) without analyzing the existing block or bracket structure:
thisThing = done;
thisNewThing = doneToo;
probsThisTooYouGuys = boom;
thisotherThing = doneInstead;
This code will quickly produce an error because that else keyword has no immediately preceding if-block to associate with, although the editing developer probably got some visual cues that it did. And understandably so; the code appears like two “blocks.” Many developers might avoid you on the playground if they were forced to analyze your code for lack of brackets, in order to not make errors with minor, but necessary, additions.
We view the following as a better style for these reasons of safety and kindness. Although the second example is one line longer, it still retains legibility:
if(thisValueIsTrue) { thisThing = done; }
if(thisValueIsTrue) {
thisThing = done
} else {
thisOtherThing = doneInstead;
Comma-Delimited Variable Statements
Another example of personal style and prevention versus performance is the debate over separating variable declarations, and potentially assignments, with commas. Check out the following setup:
var dudeOne = "cool";
var dudeTwo = "smart";
var dudeThree;
JavaScript, like other languages, offers a way to group multiple variable declarations using only one var keyword and commas:
var dudeOne = "cool",
dudeTwo = "smart",
In the first example, the JavaScript parser—which figures out whether some code is even valid in the grammar of the language—will need to look up that var keyword three times, two more than is absolutely necessary. Some devs like saving the minor performance hit that those extra lookups provide, especially if a great deal of variables are declared in the context of the code. Enough of us at Code School liked this performance pick-up, and so we teach it as a best practice in the new course.
On the other hand, some find the presence of the var keyword to be particularly helpful! They prefer to recognize what’s going on in a line of code immediately. Losing that var keyword, especially later in a file, makes it appear that the new variable might have been declared elsewhere—even though the comma might signal otherwise. Context always applies.
Additionally, the comma-delimted variable declaration can get dense if crowded onto one line like so:
var dudeOne = "cool", dudeTwo = "smart", dudeThree;
There’s a great legibility argument for NOT using a single line when employing commas. If the assignments present here were lengthier, maybe from using compound logical assignment or function calls with namespace headers or both, those three “dudes” could get really dense to read in one line. Bad news, bro.
Another valid reason that some developers may choose to place var keywords on every declaration is to prevent the effects of missing commas. Automatic Semicolon Insertion in JavaScript can produce unintended results. Check out what happens to the “dudes” in this case:
var dudeOne = "cool";
dudeTwo = "smart"   //Forgot a comma here, oops!
dudeThree;    //Now dudeThree is a reference, not a declaration.
//An undefined reference, too.
Definitely bad news if you can’t remember to put your commas in. We view the better performance impact associated with a single var, albeit minor, as something to strive for—and with striving comes a responsibility to ensure your code has no missing syntax, in similar fashion to the first topic about brackets. Nevertheless, comma-delimited variables are just one best practice idea of many in which personal style, preference, and precision can indeed play a role.
This is by no means a comprehensive sample of all the controversial best practices out there in the development wilds. These do, however, demonstrate the idea that your approach to building your best code should take into account not only your preference of personal style, but also the best performance, maintenance, and safety considerations within the context of your particular application. 

We’re sure there may be differing views, and we appreciate those who value the art of development so intensely as to have a passionate opinion! We hope you’ll join in on a discussion and share the best practices you recommend so that the whole Code School community can continue learning together.

We hope you enjoy our JavaScript Best Practices course, and wish you luck as you continue your journey in development!