← Back to Code School

As an internal developer for Code School, my job is to implement new features, test the site, and improve our codebase. One of the questions I get asked most often is about how Code School uses GitHub on our team. So, with the launch of our new Mastering GitHub course, there’s no better time to share our process than now.

I think most of us at Code School would admit that our workflow has changed quite a bit since we first started using GitHub. Beyond the Git repository hosting, GitHub has also developed a suite of well-crafted tools. We have all been using these tools — like Issues, Pull Requests and Gists — internally but they’re also useful to discover new open source projects that fit our needs. GitHub also makes it easy to find help from software maintainers so that we don’t have to dig for answers in forums and email lists.

GitHub’s team collaboration workflow give us a boost in velocity and overall it improves communication within the team. This is crucial for our team because it helps us keep our students focused on learning with no disruptions. It was only a few years ago that being able to fork a repository, make quick changes, and submit a pull request would have seem far fetched — or at least tedious. Now, we go through this process sometimes dozens of time a day and we barely even notice. This has made iterative software development at Code School more focused and more  …  fun.

Of GitHub’s many helpful tools, the feature we use most is Issues. On our main repository for codeschool.com, which is made up of 12,220 commits, we’ve amassed over 2,270 Issues and 620 Pull Requests — most of which are thankfully closed. The fact that we can easily link to a specific line of code when creating and reviewing Issues allows us to point out specific problems to whoever authored the code. That, in turn, lends to better conversations about bugs or features because we can clearly establish a context.

I think the purposeful simplicity of Issues makes it an excellent reporting and communication tool for software projects, both public and private. Its simplicity lowers the usage threshold amongst teams. For example, we can easily mention a person or a team within an Issue, which we often do with our support and marketing teams whenever they need to be involved.

Whoever is mentioned will be notified via email (or chat) to help clarify the problem at hand, which saves time for everyone. We then have a single thread to communicate about what changes are needed, who’s working on them, and when the Issue is finally resolved. This leads to better feedback, allowing our team to know about resolved Issues immediately and keeping our customers better informed.

There are also a few features that the Code School team doesn’t really use (yet), like Releases. That’s mostly because we don’t maintain a lot of internally versioned libraries. Usually, I tend to stick to a simple change log. GitHub’s notification center and social aspects are also features I don’t find myself using very often. Stars offer a less noisy way to remember cool projects. However, the social features for teams, like Pulse, give Code School a great overview of our work load — how many things we’ve tackled this week, how many features we’ve deployed, and how many bugs were fixed.

I’ll follow up with a second post related to our specific GitHub practices, but feel free to go give our new Mastering GitHub course a play in the meantime.


Building the Orlando creative community has always been very important to us here at Code School, and one of the events we brought to Orlando 7 years ago is BarCamp Orlando. This year, BarCamp is taking place on September 27th, and if you live near Central Florida I’d love to see you there.

Running community events has been key to the success of Code School, in several ways. Two years after I moved to Orlando I started the Ruby users group, and I met a lot of developers in that group who I later ended up hiring. In 2007, I ran the first BarCamp here in Orlando with the objective of bringing together the creative/tech community to share and learn from each other. For a good laugh, check out this dated promo video for the first BarCamp.

If you’re not connected to the tech community in your area, I highly recommend taking the time to go to an event that interests you. The easiest way to get started is by going to meetup.com and doing a search. If you’re near Florida already, I hope to see you at BarCamp Orlando later this month! Register here for free



With the launch of our new Mastering GitHub course, we wanted to take a little time to sit down with Peter Bell, GitHub trainer and guest instructor for the course. A veteran teacher with a background in Ruby on Rails and ColdFusion, Peter talks about the new Mastering GitHub course, what you can expect, and how it will help you dive deeper into using GitHub to collaborate more effectively with the rest of your team.

CS: What will students learn in Mastering GitHub?

PB: This course is all about improving collaboration by using GitHub. From advanced tips and tricks to proven best practices, you’ll learn the options that Git and GitHub offer to centralize and turbocharge your team collaboration.

CS: How important is GitHub to a developer?

PB: GitHub has become one of the most popular ways to collaborate — both with developers and with the rest of your team. Its powerful features for communication, collaboration and application integration make it a really efficient way to work. Also, because most open source projects are hosted on GitHub, there is a really strong open source community around the site, and working with GitHub is becoming a required skill for developers. It’s becoming the default collaboration tool for many of the best teams around.

CS: Are there any prerequisites for the Mastering GitHub course?

PB: The answer to this really depends on your current skill level with Git. Someone who consistently uses Git and knows their way around it shouldn’t have any trouble going straight into the course. However, there are specific concepts that may be beneficial to know as you go through the course, so we recommend playing through Git Real and Git Real 2 in order to be well prepared.

CS: Should Git beginners steer clear of this course?

PB: This course wouldn’t be the best place to begin your learning, but some of Code School’s other courses can help! If you want to build a solid foundation in Git, I recommend you play through Try Git, Git Real and Git Real 2 before moving on to Mastering GitHub. If you know your way around Git, you can definitely jump straight into this course.

CS: Can you share some GitHub features that our students may not know about?

PB: There are a lot of great things about GitHub, but one great extension that comes to mind is hub. Hub is a command-line wrapper that allows you to work with GitHub directly from the command line. Another thing many people might not realize is the power of Issues, Wikis and GitHub Pages for creating a complete project management solution as part of your GitHub repository.

I’m also really looking forward to diving into simple best practices for using feature branches and release tags to simplify branching strategies while making it easier to work with Git and GitHub effectively. I’ll also let you in on a fun little hack that allows you to make it look like someone famous contributed to your project!

There’s a lot more to learn as you play through our newest Git course, so get started on your journey to becoming a GitHub Master! 



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!