← Back to Code School


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!


We’re fast approaching the launch of a new best practices course for our JavaScript Path. The nature of a best practices course has lent itself well to the exploration of a few cool and diversified course challenge types. Throughout the history of Code School, we’ve always looked to add more diverse methods to our evaluation model, in order to better break down the testing of conceptual material. The goal is to more thoughtfully and thoroughly engage our students with ideas that carry depth and an appropriate complexity.

We’ve found that sequential “baby steps” toward the evaluation of fundamental concepts in our browser format are not always best served by producing large, fully functional blocks of code. Even using single lines of new code to incrementally increase the size of existing code blocks does not always test in detail the front-to-back understanding of what concepts that code may represent.   

A central tenet of our vision is to produce well-rounded, knowledgeable and prepared developers through a combination of formats. We therefore always strive to increase educational rigor while still retaining the fun that has always been Code School’s trademark. By employing useful research into theories of learning, we also want to better cater to the immensely divergent learning styles that likely exist among our many clever subscribers.

The new challenge types are a convergence of these desires to educate better throughout the instructional frame. We’ve added three styles of evaluation to complement our existing code editor style. We’ll be watching closely to investigate their efficacy and usefulness within our browser format. They are:

Free Response - We often want to make sure students know specific names for concepts, or have the ability to trace through difficult code in their future jobs, which may require maintenance of someone else’s code. The free response challenge will require the analytical skills that all developers must use, but allows a student to illustrate a portion of concept mastery without the synthesis of producing code. 


Multiple Choice -  This ain’t old school multiple choice. As many of you know, common multiple choice questions in academia are often easy and obvious—leaving them educationally worthless. We strive to reinvigorate the multiple choice question educationally, so these challenges will attempt to engage analysis and precision with a concept for every possible answer.


Console Entry -  For single lines of code that don’t require full files within the editor, but do demonstrate some unique aspect of a concept or practice, we’ve added the one-line console entry. Sometimes we think of this as a mini-editor, where a student can demonstrate incremental progress in the understanding of a broader concept before trying to unite many concepts together in synthesis.


Our hope is that we can do the very best for our students by providing real, functional, entertaining education in the most useful sense of the term. We hope you enjoy these new, fun ways of thinking and learning about code. We look forward to hearing your responses to the upcoming JavaScript Best Practices course and its new challenge types. Happy coding!


It’s an important day here at Code School. If you’ve been following along with the Google I/O conference in San Francisco, you may have heard we’re teaming up with Google and its Women Techmakers Program to support women and minorities in tech.

Specifically, Google is giving away thousands of accounts for three free months of Code School. Together, our goal is to invest in women and minorities so they can continue developing their technical skill sets. Having access to self-learning programs (such as Code School) is instrumental in that.


It’s no secret that diversity isn’t the tech community’s strong point—and we’re always looking for opportunities to help change that. Today, a quarter of IT roles are held by women, and African Americans only make up about 3 percent of scientists and engineers. These are just a few of the more sobering statistics. The situation is clear: we have a long way to go in order to create a diverse, open and inclusive tech community. And while there is no silver bullet, we’re excited to work with Google on this piece of the educational puzzle.  

We should note: this isn’t exactly a free for all; Google is distributing promo codes strategically at the conference and inside the community. But what this does mean is thousands of people interested in continuing their path with programming will have the ability to do so free of charge.

What also makes this partnership unique is that it supports people along their learning journey. We’ve seen a lot of efforts this year that focus on teaching newbies and kids to code. While this is necessary and tremendously important, there’s also the other end of the equation, which is supporting continuous learning for working and aspiring technology professionals who are pursuing technical careers. To that end, Code School offers a large number of courses that cater to intermediate to experienced developers (in addition to beginner courses). This includes a number of Google-related technology courses such as Shaping Up With Angular.js, Exploring Google Maps for iOSDiscover Drive and Discover DevTools.

If you’re a woman in technology and want to apply for a chance to take part in this initiative, visit the Women Techmakers’ application page and share what inspired you to join the technology industry. If you already have a code, you can redeem it on our website here.


While creating the design for our upcoming JavaScript Best Practices course, our art director, Justin Mezzell, created an awesome 8-bit narrative to guide you through the course. He created an extensive world, pixel by pixel, and introduced us to the heroic characters Dhuun and Aiedra. These characters begged to be animated, so just like any front-end developer would do, I recreated the characters using only CSS—specifically box-shadow.



I’m not the first to attempt this technique. Alex Griendling recently created an 8-bit Rocket Racoon, and Favrice LeJeune recreated the design using this box-shadow technique. Being a curious front-end developer, I had to try it with Justin’s characters.

Flexible Sizing

First, you may notice that I used ems instead of pixels. Fellow Code School front-end developer Dan Denney pointed out that this method would allow the size of the design to be easily adjusted. This is because ems are calculated relative to the current font size, so in this instance, a simple change to the body font size would alter the size of our character. This is the setup for that:


Building with Pixels

Next, I picked a random point (pixel) close to the center of the design, and started building out each line of the character one by one, using comma-delimited box-shadows. To give you an idea of how this looks, here is the first line of Aiedra.

See the Pen Aiedra - First Line by Jordan Wade (@jordanwade) on CodePen.

Note: Proper commenting is helpful to keep track of each line of the design.

Keyframe Animation

After the setup and line-by-line 8-biting, it was time to start the animating. The difficult part of the animation was getting the boxes to flicker without a transition to give a more classic, 8-bit-style animation. I had a feeling the solution was using steps, and, after some guesswork, I discovered that setting steps to “1” fixed the issue. Unfortunately, like a lot of things we do, it works for an unknown reason that was only uncovered by tinkering with numbers to get it right.

Here are the two finished characters:

See the Pen Aiedra by Jordan Wade (@jordanwade) on CodePen.

See the Pen Dhuun by Jordan Wade (@jordanwade) on CodePen.

Note: Feel free to look through the code to see how it’s accomplished.


So why would I go through the trouble of creating each pixel individually, when I could have easily made a sprite or used Justin’s GIF? Well, in this case, for fun. I had some extra time on this course, so why not try something different and challenge myself to keep learning?

I hope you enjoyed this quick look at some of the techniques we’re using at Code School. Don’t forget to follow Dhuun and Aiedra on their journey in our upcoming course, JavaScript Best Practices.


Last week, we held our second Code School Live Q&A event focused on all things Angular.js.

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

Resources recommended during the event:

If you watched live, you may know that we experienced technical difficulties with our video feed. We apologize to everyone who was unable to participate in the event or watch the live feed in its entirety. We’re working hard to fix these issues for next week’s Code School Live, but we appreciate your patience while we test live steaming and work out the kinks.

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 Angular.js hosts, follow Gregg Pollack, Alyssa Nicoll, and Adam Rensel on Twitter.

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


The console sandbox mode is a nice feature of Rails that’s not very well known. This feature allows us to perform database operations which are automatically reverted when we leave the console.

You can start the console in sandbox mode with the sandbox option, like so:

$ rails c ––sandbox

This command loads our Rails application, connects to the database and automatically starts a database transaction. All database operations performed within this console session are rolled back upon leaving the console.


This feature comes in handy any time we need to run methods from the console without permanently changing data. For example, when trying to reproduce reported bugs in production, we can use the sandbox mode to make sure we don’t accidentally change existing user data.

Third Party APIs

The sandbox mode only reverts operations in the database. It does not prevent web service calls from being performed to third party APIs. Any calls to bug reporting services, payment gateways, etc. are still going to be run normally. In order to prevent those from being called, they need to be mocked out separately.