In a way, that's kind of an amazing testament to how flexible JavaScript is, and how user-friendly many of today's popular libraries are. I can't think of many other object-oriented languages where an engineer can be reasonably productive without being at least vaguely aware of classes.

But here's the thing: if you write JavaScript even semi-regularly, you really should understand how prototypal inheritance works. And that's why I'm writing this post.

Disclaimer

There will be some things in this article that I over-simplify a little bit.

My goal here is to help someone who's never used prototypal inheritance to become comfortable with it. In order to do that, I'll cut a few small corners here and there if I think it helps eliminate a bit of confusion.

Objects Inherit from Objects

If you've ever read anything about inheritance in JS, then you've almost certainly heard that objects inherit from other objects.

This is true, and once you already understand it, it's a good way to think about things. But my experience has been that this explanation alone isn't really sufficient.

So I'm going to break from tradition here and not actually try to explain how inheritance works right up front. Instead, we'll start with some simpler stuff that will hopefully provide a bit of context later on.

Function prototypes

Here's a fun fact: In JavaScript, all functions are also objects, which means that they can have properties. And as it so happens, they all have a property called prototype, which is also an object.

function foo() {

}

typeof foo.prototype // 'object'  

That's pretty simple, right? Any time you create a function, it will automatically have a property called prototype, which will be initialized to an empty object.

Constructors

In JavaScript, there's really no difference between a "regular" function and a constructor function. They're actually all the same. But as a convention, functions that are meant to be used as constructors are generally capitalized.

By the way, if you don't know what I mean when I say "constructor", that's totally okay. We'll get there.

So let's say that we want to make a constructor function called Dog, because explaining inheritance using animals is a time-honored tradition and I'm kind of a nostalgic dude.

function Dog() {

}

If I want to make an instance of Dog, I use the new keyword. That's really what I mean when I talk about constructors – I'm using the function to construct a new object. Any time you see the new keyword, it means that the following function is being used as a constructor.

var fido = new Dog();  

So now we have fido, who's a Dog. But he doesn't really do anything.

He's kind of like my dog, actually.

Methods

It's time to make our Dog a little more dog-like. Bear with me here, because I'm going to explain this in just a minute.

function Dog() {

}

Dog.prototype.bark = function() {  
  console.log('woof!');
};

You should remember from earlier that all functions automatically get initialized with a prototype object. In the example above, we tacked a function onto it called bark.

Now let's make ourselves a new fido.

function Dog() {

}

Dog.prototype.bark = function() {  
  console.log('woof!');
};

var fido = new Dog();

fido.bark(); // 'woof!'  

I'm going to explain this in more detail a little later on. But the important thing to take away right now is that by placing bark on Dog.prototype, we made it available to all instances of Dog.

Don't worry yet about how this works. Just keep in mind that it works.

Differential Inheritance

JavaScript uses an inheritance model called "differential inheritance". What that means is that methods aren't copied from parent to child. Instead, children have an "invisible link" back to their parent object.

For example, fido doesn't actually have its own method called bark() (in other words, fido.hasOwnProperty('bark') === false).

What actually happens when I write fido.bark() is this:

1. The JS engine looks for a property called bark on our fido object.
2. It doesn't find one, so it looks "up the prototype chain" to fido's parent, which is Dog.prototype.
3. It finds Dog.prototype.bark, and calls it with this bound to fido.

That part is really important, so I'm going to repeat it:

There's really no such property as fido.bark. It doesn't exist. Instead, fido has access to the bark() method on Dog.prototype because it's an instance of Dog. This is the "invisible link" I mentioned. More commonly, it's referred to as the "prototype chain".

Object.create()

Okay. We talked a little bit about differential inheritance and the prototype chain. Now it's time to put that into action.

Since ES5, JavaScript has had a cool little function called Object.create().

Here's how it works.

var parent = {  
  foo: function() {
    console.log('bar');
  }
};

var child = Object.create( parent );

child.hasOwnProperty('foo'); // false  
child.foo(); // 'bar'  

So what is it doing?

Essentially, it creates a new, empty object that has parent in its prototype chain. That means that even though child doesn't have its own foo() method, it has access to the foo() method from parent.

Try It

We've covered a lot of ground so far, and we still have a bit more to go. To make sure everything we learned so far sinks in, I'd encourage you to open up your dev tools and try a quick little example.

Create a constructor function called Car. Add a drive() method to its prototype that just logs to the console. Now create an instance of Car and call drive().

I really mean it. You should take 30 seconds and go do it. I'll wait here. And no cheating...

Good, you're back. Hopefully you wrote something that looks like this.

function Car() {

}

Car.prototype.drive = function() {  
  console.log('vroom');
};

var benz = new Car();

benz.drive(); // vroom  

If not, consider re-reading some of the earlier sections. It's important that you're somewhat comfortable with that stuff before you move on.

Putting It All Together

It's time to look at a (slightly) more real-world example that takes everything in this post and puts it all together.

Let's start by creating a Rectangle constructor.

function Rectangle( width, height ) {  
  this.width = width;
  this.height = height;
}

At this point, we'll take a tiny detour to talk about this.

When a function is used as a constructor, this refers to the new object that you're creating. So in our Rectangle constructor, we're taking width and height as arguments, and assigning those values to the width and height properties of our new Rectangle instance.

var rect = new Rectangle( 3, 4 );

rect.width;  // 3  
rect.height; // 4  

Now it's time to give our Rectangle a method. Let's call it area.

Rectangle.prototype.area = function() {  
  return this.width * this.height;
};

There's that this keyword again. Just like in the constructor, this inside of a method refers to the instance.

var rect = new Rectangle( 3, 4 );

rect.area(); // 12  

Subclassing

What if we want to make a new class of object that inherits from Rectangle?

Let's say we need a class called Square. Hopefully you remember from elementary school that a square is just a specific type of rectangle.

We'll start by creating its constructor.

function Square( length ) {  
  this.width = this.height = length;
}

So, that's all well and good, but how do we make Square inherit from Rectangle? It's all about setting up the prototype chain.

If you remember from earlier, we can use Object.create() to create an empty object that inherits from another object. In the case of Square, that means all we need to do is this:

Square.prototype = Object.create( Rectangle.prototype );  

All instances of Square will automatically have Square.prototype in their prototype chain, and because Square.prototype has Rectangle.prototype in its prototype chain, every Square will have access to the methods of Rectangle.

In other words, we can do this:

var square = new Square( 4 );

square.area(); // 16  

We can also add new methods that are specific to Square. Remember, Square.prototype is just an empty object right now (albeit with a link back to Rectangle.prototype).

Square.prototype.diagonal = function() {  
  return Math.sqrt( this.area() * 2 );
};

Time travel

One of the really cool (and potentially dangerous) things about inheritance in JavaScript is that you can modify or extend the capabilities of a class after you've defined it.

Because JavaScript will look up the prototype when trying to access properties on an object, to you can alter your classes at runtime.

Here's an example (for illustrative purposes only. Don't ever do this):

var arr = [ 1, 2, 3, 4, 5 ];

Array.prototype.shuffle = function() {  
  return this.sort(function() {
    return Math.round( Math.random() * 2 ) - 1;
  });
};

arr.shuffle(); // [ 3, 1, 4, 5, 2 ]  

The important thing to notice in this example is that arr was created before Array.prototype.shuffle existed. But because property lookups are done at runtime, our array got access to the new method anyway. It's like we went back in time and gave Array a (stupid) new method.

To get a sense of how powerful (and potentially dangerous) this is, go open the JS console on a page like Facebook, paste in the following code, and watch the log as you click around:

Array.prototype.push = function() {  
  throw new Error('lolnope');
};

If you live in the Boston area, love JavaScript, and want to work on some really exciting problems at Starry, shoot me an email. I'm hiring.

Their apps were unmaintainable. Code quality was poor. Build processes were slow and messy. Nothing was really standardized.

They knew they had a problem, and were looking for a senior engineer to come on board and help get things pointed in the right direction – but they also had a few ideas of their own on how to fix things:

“We’re gonna switch from [Framework X] to [Framework Y]”

I immediately knew that I wouldn’t be able to help, because as an organization, they fundamentally misunderstood the root cause of their problem.

Blaming the Tools

There’s a line of reasoning I see all the time, and it goes something like this:

“The app is bad and we built it with [Framework X], so [Framework X] is bad”.

This kind of logic seems to be pervasive among front-end developers right now, and I think it’s really, really dangerous. Rather than thinking critically about application design, we instead look to frameworks to solve all of our problems.

I’ve actually seen a company switch from Backbone to Ember. Then from Ember to Angular. In all likelihood, they’ve switched from Angular to React and Flux by now.

Don’t get me wrong, there’s nothing wrong with changing tools. Each have their strengths and weaknesses, and they need to be evaluated on a case-by-case basis against the objectives of your project. But you need to be clear on why you want to switch, and which pain points you’re trying to alleviate.

I’d submit that if your app is still a disaster after the third switch, then maybe the problem isn’t the framework.

Making Decisions is Hard

My personal take on all of this is that many developers are either unwilling or unable to make difficult choices about application design. So instead, they look for a framework to make all the choices for them.

But the kind of choices baked in to even the most opinionated frameworks aren’t the ones that will make or break your app.

I have yet to discover any library or framework so opinionated, so complete, so fundamentally correct in its core ideology that it can’t be used to make shitty apps.

In other words, they can’t save us from ourselves.

Engineers and Technicians

Okay, back to that interview.

There’s an important piece of information that I left out earlier: this was a rapidly-growing company, and they’d adopted a strategy of hiring very junior devs with [Framework X] experience in droves.

What they’d created was a team of technicians. Employees who knew how to operate the machinery of [Framework X] — but had no context. They lacked a fundamental understanding of the underlying concepts. And as a result, they often weren’t able to make informed decisions when confronted with a problem that their chosen framework offered no clear opinion on.

Anyway, my point here isn’t that junior devs are stupid, or that frameworks are bad.

My point is that by exaggerating the importance of frameworks, we’re ending up with an army of technicians and no engineers. By pretending that Ember or Angular can solve all of our problems, we give the false impression that simply learning the “right” framework is all you need in order to be effective. But it’s not.

What’s the Solution?

I’m not sure that I know, really.

But I think it starts with a much more honest discussion around what these frameworks can and cannot do for us.

More importantly, we need to place a much stronger emphasis on learning fundamental JavaScript concepts and principles of good application design. Unlike memorizing the API of some trendy new framework, that knowledge never becomes obsolete.

— —

Follow me on Twitter or Medium for more posts. I’m trying to write once a day for the next 30 days.

And if you’re in the Boston area and want to come work on crazy, top-secret things with me at Project Decibel, shoot me an email. I’m hiring.

There are a lot of really easy ways to rationalize not testing your code, and I’m probably guilty of saying each of them at one point or another.

• “It takes too much time”
• “That’s what QA is for”
• “A passing test suite doesn’t guarantee that you don’t have bugs”
• “I tested it myself before I committed to master”
• “[some feature I’m working on] isn’t really testable”

For some engineers, I think the reluctance to embrace unit testing is basically just FUD. Like so many other things, testing seems scary if you haven’t done it before.

But it’s also really difficult to fully understand the benefits of testing unless you’ve worked on a project that has good tests. So it’s easy to see why — without fully understanding the upside — many developers regard unit testing as an unnecessary step.

It takes too much time

This argument is actually pretty rational if you don’t understand the long-term benefits of testing.

For a lot of the projects I work on, testing a new feature takes longer than actually implementing it. At first glance, that seems like a crazy way to invest my time.

But there’s an important piece of information missing here:

Over the long-term, having good tests will save you a huge amount of time.

The first time I ever refactored a piece of code with good test coverage, I actually felt a little bit guilty. It was almost too easy. Since I knew there was a safety net, I was free to try whatever I wanted. I didn’t have to remember all of the weird edge cases, because if I forgot them, the tests would fail.

Having good test coverage gives you a crazy amount of confidence going into a large refactor. It helps to ensure that you’re not introducing new bugs, which can ultimately save you a whole lot of time in the long run.

That’s what QA is for

Nope.

Nope nope nope nope nope.

QA does not exist so that we can be lazy and inattentive to detail. They’re a final line of defense against bugs. And they work at a much, much higher level of abstraction than engineers do.

Imagine an app with an off-by-one error. Maybe you’re rendering a list of users, but accidentally omitting the last one.

For QA to catch this, they need to know what the list should look like, and then notice that there’s an entry missing. Essentially, they need to be looking for this exact bug.

Then they need to reproduce it. They need to document it and file an issue. In all likelihood, they need to show their screen to some engineer who doesn’t believe that they could possibly have written code that breaks the app.

And all of that time is wasted, because a simple unit test would have caught the bug. Not just this time, but every time. Instantly and automatically.

A passing test suite doesn’t guarantee that you don’t have bugs

Wearing a seatbelt doesn’t guarantee you won’t be horribly injured in a car accident. Should we abandon any safety measure that isn’t 100% effective?

I tested it myself before I committed to master

Of all these terrible excuses, this is the one I’m probably most guilty of having believed in.

Of course it works. Why would I push code that doesn’t work?

This argument is compelling because there’s a tiny grain of truth to it.

If you’re attentive to detail and thoroughly test your new feature in the browser (or via HTTP or whatever the interface is), that can be functionally equivalent to unit testing.

But it’s hard to be sure that your new code didn’t break some other, unrelated part of the app. And more importantly, nobody else gets the benefit of the manual testing you did. That process happened once, and now it’s essentially lost.

Unit tests, on the other hand, are forever. They don’t just guard against bugs right now, they guard against bugs in the future.

[some feature I’m working on] isn’t really testable

For the past two years, every single application or library I’ve worked on has had 100% coverage.

If you’ve never used a code coverage tool (I like Istanbul for JS), it’s essentially a process that instruments your code and then reports back on whether or not each line was executed while your test suite ran. If a line or expression was never run, it means you didn’t test it.

Anyway, in all of that time, I’ve only encountered one or two functions that couldn’t be written in a way that made them testable. Looking back, I’m not actually convinced that I couldn’t deal with those now by using dependency injection.

Sometimes you have to rethink the problem. Occasionally you even need to settle on an interface that’s less than ideal. But at the end of the day, it’s extremely unlikely that you’re working on a new feature that is literally impossible to test.

Getting Started

If you’ve been convinced that testing is important but don’t know where to start, I’d recommend looking at some open-source projects. Most high-profile OS repos have excellent coverage, and they can give you an idea of how to effectively test your code.

If you’re worried about getting buy-in from the rest of your team, here’s my recommendation:

Start writing tests for your own contributions. Don’t even ask permission. Just do it*.

I’d be willing to bet that the rest of your team will start to see the benefits before long.

*I did this at my last job, and it worked brilliantly. Within about a week, people were actually excited about it.

— -

Follow me on Twitter or Medium for more posts. I’m trying to write once a day for the next 30 days.

And if you’re in the Boston area and want to come work on crazy, top-secret, fully unit-tested things with me at Project Decibel, shoot me an email. I’m hiring.

Consider this post as a series of learning exercises. These examples are designed to make you think — and, if I’m doing it right, maybe expand your understanding of functional programming a little bit.

Hey, dawg. I heard you like recursion, so I put a “Hey, dawg. I heard you like recursion, so I put a “Hey, dawg…

Loosely defined, recursion is the process of taking a big problem and sub-dividing it into multiple, smaller instances of the same problem.

Put into practice, that generally means writing a function that calls itself. Probably the most classic example of this concept is the factorial function.

You may remember from math class that the factorial of a number n is the product of all positive integers less than or equal to n. In other words, the factorial of 5 is 5 x 4 x 3 x 2 x 1. The mathematical notation for this is 5!.

Something interesting you might have noticed about that pattern: 5! is actually just 5 x 4!. And 4! is just 4 x 3!. So on and so forth until you get down to 1.

Here’s how we’d write that in JavaScript:

If this seems confusing, I’d encourage you to mentally walk through the code using the example of factorial( 3 ).

Here’s a bit of help, in case you need it:

1. factorial( 3 ) is 3 x factorial( 2 ).
2. factorial( 2 ) is 2 x factorial( 1 ).
3. factorial( 1 ) meets our if condition, so it’s just 1.

So what’s really happening here is that you’re winding up the call stack, getting down to 1, and then unwinding the stack. As you unwind the call stack, you multiply each result. 1 x 2 x 3 is 6, and that’s your return value.

Reversing A String

One of my co-workers recently told me about a whiteboard question that he’d been asked in an interview, and I thought it was kind of a fun problem.

Write a function that accepts a string a reverses it. Recursively.

If you’re the ambitious type, I’d encourage you to take a few minutes and try to solve this one on your own. Keep in mind the core principle of recursion, which is to take a big problem and break it down into smaller instances of itself.

If you got stuck (or you’re the decidedly unambitious type), here’s my solution:

Again, I’ll give a quick walk-through example in case you got stuck. We’ll use reverse('bar') as a starting point.

1. reverse('bar') is reverse('ar') + 'b'
2. reverse('ar') is reverse('r') + 'a'
3. reverse('r') meets our if condition, so it’s just 'r'

When the call stack unwinds, we end up with 'r' + 'a' + 'b'.

Writing a Recursive Map Function

For our final example, we’re going to write a map() function. We want to be able to use it like this:

Again, I’d strongly encourage you to take a few minutes and try this one on your own. Here are a few hints and reminders:

1. map() should always return a new array.
2. Break the problem down into smaller chunks.
3. Remember the reverse() example.

Oh, good. You’re back. How did it go?

j/k, this is a blog and I can’t hear you. lol.

Anyway, here’s how I did it:

So let’s go through this using the example I gave earlier:

1. Call map() using the array [ 'a', 'b', 'c' ]
2. Create a new array that holds the result of calling fn('a')
3. Return [ 'A' ].concat( map([ 'b', 'c' ]) )
4. Repeat steps 1 through 3 with [ 'b', 'c' ]
5. Repeat steps 1 through 3 for [ 'c' ]
6. Eventually, we call map() with an empty array, which ends the recursion.

NOTE:

You should never, ever, ever do this in a real application. You’ll blow out the stack on large arrays, and more importantly, you create a huge amount of garbage by instantiating so many new objects. Use Array#map in production code.

Wrap Up

Hopefully I did a decent job in explaining this stuff. If you’re still struggling a bit to wrap your head around recursion, the best advice I can give is to start with small examples and mentally trace the call stack. Try something like reverse('abc') and walk through it, step-by-step. Eventually it’ll click.

— -

Follow me on Twitter or Medium for more posts. I’m trying to write once a day for the next 30 days.

And if you’re in the Boston area and want to come work on crazy, top-secret things with me at Project Decibel, shoot me an email. I’m hiring.

If you didn’t read part 1, you really should go back and do that, because this post references a lot of stuff from it.

The Sequence Class

In TinyMusic, Note instances are strung together and have their playback controlled by a Sequence. Each Sequence has a tempo, volume control, and some basic EQ.

There are a couple different ways to instantiate a Sequence:

// create a Web Audio API context
var ac = new AudioContext();  
// beats per minute
var tempo = 110;  
var sequence = new Sequence( ac, tempo, [  
  new Note('G3 q'),
  new Note('E4 q'),
  new Note('C4 h')
]);

For convenience, you can also pass an array of strings, and they’ll automatically get turned into Note instances.

// create a Web Audio API context
var ac = new AudioContext();  
// beats per minute
var tempo = 110;  
var sequence = new Sequence( ac, tempo, [  
  'G3 q',
  'E4 q',
  'C4 h'
]);

So now we’ve got a Sequence with an AudioContext, a tempo, and a bunch of Notes. What’s next?

Playing A Sequence

Playing a Sequence consists of a few steps. I’ll explain each one in a bit more detail later on, but I want to start with a higher-level overview.

First, I create a new oscillator.

Next, I loop through each Note in the sequence and schedule changes to the oscillator’s frequency.

Finally, I schedule a stop() on the oscillator and, when applicable, enable looping.

Here’s the play() method in its entirety:

// run through all notes in the sequence and schedule them
Sequence.prototype.play = function( when ) {  
  when = typeof when === ‘number’ ? when : this.ac.currentTime;
  this.createOscillator(); 
  this.osc.start( when );
  this.notes.forEach(function( note, i ) { 
    when = this.scheduleNote( i, when ); 
  }.bind( this )); this.osc.stop( when );
  this.osc.onended = this.loop ? 
    this.play.bind( this, when ) : null; 
  return this;
};

The when parameter is a Web Audio timestamp, which is essentially a high-precision value (in seconds) that can be used for accurate scheduling.

Everything else will be explained below.

Creating an oscillator

This part is pretty straight-forward.

There’s a bit of extra code to support custom wave types (a bit beyond the scope of this post, and probably not of much interest to most readers) — but essentially, all we really need to do is this:

this.osc = this.ac.createOscillator();  
this.osc.type = this.waveType || ‘square’;  

Possible values for waveType are sine, square, triangle, and saw.

Scheduling Frequency Changes

The entire Sequence is actually played back using a single oscillator.

All I do is loop through each note and schedule changes to the oscillator’s frequency at the appropriate time.

In other words, when you call Sequence#play, I do all of the scheduling immediately, and the Web Audio API kind of takes over from there. All of my work is done up front.

Each note is passed to Sequence#scheduleNote with its index and a timestamp for when it should begin.

Here’s the scheduleNote method:

// schedules this.notes[ index ] to play at the given time
// returns an AudioContext timestamp of when the note will *end*
Sequence.prototype.scheduleNote = function( index, when ) {  
  var duration = 60 / this.tempo * this.notes[ index ].duration,
    cutoff = duration * ( 1 - ( this.staccato || 0 ) );

  this.setFrequency( this.notes[ index ].frequency, when );

  if ( this.smoothing && this.notes[ index ].frequency ) {
    this.slide( index, when, cutoff );
  }

  this.setFrequency( 0, when + cutoff );
  return when + duration;
};

I think this might be hard to explain by going line-by-line, so I’m going to give sort of a conceptual overview instead.

When we loop through all of the Notes in the play() method, we have a starting time value called when.

Starting with the first note, we call scheduleNote(), passing when as well as the note’s index within the sequence (for the first Note, this would be 0).

From there, scheduleNote tells the oscillator “change to x frequency at y time”, and then it returns a new value for when (the previous value plus the duration of the latest Note).

Then play() moves on to the next note, and calls scheduleNote() using the new when value. Rinse and repeat for each additional Note in the sequence.

The actual oscillator scheduling happens in a method called setFrequency(), which looks like this:

// set frequency at time
Sequence.prototype.setFrequency = function( freq, when ) {  
  this.osc.frequency.setValueAtTime( freq, when );
  return this;
};

Pretty simple, right? We just use the oscillator’s setValueAtTime method, which does exactly what it looks like.

Staccato and Smoothing

TinyMusic supports two settings called staccato and smoothing.

Staccato refers to “choppiness”, or how long/short each note will be compared to its intended duration. Lots of staccato means the note is harshly truncated, and no staccato means it will play in its entirety.

Smoothing is for portamento, which is sliding from one note to the next. Higher smoothing values result in a slower slide, and no smoothing means that notes don’t slide at all.

These settings aren’t really integral to the basic functioning of TinyMusic, and I think they’re pretty easy to understand from looking at the source, so I’m going to skip over them in this post.

If you have questions about either, just leave a comment and I’ll answer to the best of my ability.

EQ and Volume

EQ and volume nodes are created as soon as a Sequence is initialized with a method called createFXNodes().

There are three nodes for EQ: bass, mid, and treble. Each is a Web Audio BiQuadFilterNode. This allows for some basic 3-band equalization.

Setting EQ values looks like this:

var sequence = new Sequence( ac, tempo, noteArray );  
// 80 Hz
sequence.bass.frequency.value = 80;  
// +4dB
sequence.bass.gain.value = 4;  

Stopping Playback

Stopping playback is pretty simple, but there are a few important things that need to happen:

if ( this.osc ) {  
    this.osc.onended = null;
    this.osc.stop( 0 );
    this.osc.frequency.cancelScheduledValues( 0 );
    this.osc = null;
  }
  return this;
};

First, we just do a quick safety check to make sure we actually have an active oscillator.

Next, we null out the oscillator’s onended callback, which effectively cancels looping.

Then, we actually stop the oscillator and cancel any frequency automation that may have been scheduled.

Finally, we null out the oscillator.

Wrapping Up

There are a few things in TinyMusic that I decided not to cover here.

Some of them are “advanced” features that likely wouldn’t be of interest to most readers, and others are trivial little helper functions that you can pick up by reading the source.

Nevertheless, I hope you learned a little bit about working with music in code — and maybe got a small taste for what it’s like to build apps with the Web Audio API.

Like I said earlier, please don’t hesitate to ask questions in the comments. If I left something out, it was likely an oversight.

— -

Follow me on Twitter or Medium for more posts. I’m trying to write once a day for the next 30 days.

And if you’re in the Boston area and want to come work on crazy, top-secret things with me at Project Decibel, shoot me an email. I’m hiring.

Being a musician, it felt important that my game would have music. After looking around a bit, I wasn't able to find any libraries that really did what I wanted without totally blowing the 13 KB budget. So I decided to make my own.

This post is the first of two parts. In it, I'll explain the Note class in TinyMusic. We'll dig in to a little bit of light music theory and math.

In part two, I'll cover the Sequence class, and talk about the Web Audio API.

TinyMusic

Before I start digging in, here's a link to the final product: TinyMusic. You can also check out a small demo here.

Keep in mind that this is a fairly bare-bones library. It was really purpose-built for something like js13k, so the idea was to deliver the minimum useful feature set for basic music synthesis.

Notes

The first thing I started work on was a Note class.

var note = new Note('A4 q');  

This was the API that I wanted. Basically, it accepts a string containing a note name and a time value (q = quarter, h = half, etc.), separated by a space.

In order to translate the note name into a frequency, you need two things:

1. A known frequency for a given note.
2. A formula for moving between your known frequency and the target note.

Choosing a starting frequency

Most musicians probably know that A4 = 440Hz, so that seems like a good choice for our target frequency. But since numbered octaves actually begin at C, we really want to use middle C (C4) as our target.

Knowing that C4 is 9 half-steps below A4, we can get its frequency like this:

var middleC = 440 * Math.pow( Math.pow( 2, 1 / 12 ), -9 );  

I won't dig too far into the math here, but hopefully you recognize the 12 (number of semitones in an octave) and the -9 (the distance between A4 and C4).

We'll be using the same formula later on to derive all of our other frequencies.

Converting note names to frequencies

Now that we have our target frequency for middle C, we need a way to translate other note names into frequencies.

The first thing I did was create a string of every note and then use that to populate an offsets hash.

var enharmonics = 'B#-C|C#-Db|D|D#-Eb|E-Fb|E#-F|F#-Gb|G|G#-Ab|A|A#-Bb|B-Cb';  
var offsets = {};

enharmonics.split('|').forEach(function( val, i ) {  
  val.split('-').forEach(function( note ) {
    offsets[ note ] = i;
  });
});

The groupings in that string are kind of important to understand. The basic idea is that in music theory, sometimes there are actually multiple names for the same note. So B# and C are equivalent. Fb and E are equivalent. You get the idea...

Anyway, what we end up with at the end of that process is an object where each key is a note name (A, F#, Db, etc.), and the value is the distance between that note and C (in half-steps).

From there, we just need a little bit of math.

var num = /(\d+)/;  
// the octave number of our known frequency, middle C
var octaveOffset = 4;

Note.getFrequency = function( name ) {  
  var couple = name.split( num ),
    distance = offsets[ couple[ 0 ] ],
    octaveDiff = ( couple[ 1 ] || octaveOffset ) - octaveOffset,
    freq = middleC * Math.pow( Math.pow( 2, 1 / 12 ), distance );
  return freq * Math.pow( 2, octaveDiff );
};

// usage:
Note.getFrequency('F3'); // 174.61  

So we're doing a few things here. The first line just creates an array that looks like [ 'F', '3' ].

From there, we get the note's distance from C by looking it up in the offsets object. In this case, it's 5.

octaveDiff ends up being -1, which means that our target frequency is in the octave below our known frequency.

Next, we calculate a frequency as if our target note was in the same octave as middle C. This is the same basic formula you saw earlier.

Finally, we shift our frequency to the correct octave.

Durations

In addition to frequency, each Note also needs a duration.

In this case, duration isn't actually measured in seconds or milliseconds. It's really just going to be a ratio of the note's time value to one beat length.

In other words, for a quarter note, duration would be 1 (because it's exactly one beat long). For a half note, it would be 2. An eighth note is 0.5, etc.

Dotted notes

If you read music, you're probably familiar with "dotted" notes.

If not, it basically means that when a note is dotted, you add 50% to its duration. So a dotted eighth note is really like an eighth note plus a sixteenth note.

It was pretty important to support this in TinyMusic, so this is how I did it:

var note = new Note('A4 es');  

Here, the e stands for "eighth" and the s for "sixteenth". When I parse that string, I simply add the two durations together.

Numeric values

There are so many possible values for note duration that I couldn't realistically support all of them with short-hand strings (e.g. "q" = quarter, "e" = eighth, etc).

So the Note constructor also accepts numeric values, like this.

var note = new Note('A4 0.75');  

Putting it all together

This is the actual function I ended up with.

var numeric = /^[0-9.]+$/;

Note.getDuration = function( symbol ) {  
  return numeric.test( symbol ) ? parseFloat( symbol ) :
    symbol.toLowerCase().split('').reduce(function( prev, curr ) {
      return prev + ( curr === 'w' ? 4 : curr === 'h' ? 2 :
        curr === 'q' ? 1 : curr === 'e' ? 0.5 :
        curr === 's' ? 0.25 : 0 );
    }, 0 );
};

I know, the nested ternary thing is gross. But in my defense, I wrote this a while ago and I was trying to save bytes. So whatever.

Anyway, here's how this thing works:

1. If we got a string that looks like a number, just call parseFloat and return the number.
2. Otherwise, loop through each character in the string and try to get a time value for it – then add them up.

The second step is accomplished with Array#reduce. This is what gives us the ability to support strings like 'es'. We just get the value for e and add it to the value for s.

Wrapping up

Now that we've got our Note class, we need a way to group them together and play them. I accomplish this with a class called Sequence, which I'll be covering in part 2 tomorrow.

Follow me on Twitter or Medium for more posts. I’m trying to write once a day for the next 30 days.

And if you’re in the Boston area and want to come work on crazy, top-secret things with me at Project Decibel, shoot me an email. I’m hiring.

I start yawning a lot. My heart rate becomes elevated. I'm pretty sure my face turns red. It's gotten a lot better with age – but still, it's not great.

Anyway.

About two years ago, while I was working at Aereo, I had the enlightened idea that we should start doing a Lunch & Learn once a week. I sent out an email to see if anyone was interested, and the response was overwhelmingly positive.

I'm sure you can see where this is going.

Since I was the one who made the suggestion, it was decided that I should present first.

Now, this was going to be a relatively small group of my peers. Maybe 20 people or so, most of whom I had know for about 2 or 3 years. To call this "public speaking" would be a stretch, but still, I was kind of nervous about it.

A little bit of context

I had recently participated in AngelHack Boston with some people I "met" on Twitter, and it was my first real exposure to using pull requests on a project. The other guys on my team were all at the same company, and they used PRs for everything at work – so we adopted them on the hackathon team as well.

The process really struck a chord with me, and I was curious how it might work for my team at Aereo. So I decided to pretend like I had some sort of authority on the matter, and I chose pull requests as my Lunch & Learn topic.

Nope. Nope nope nope nope nope.

The day of my little presentation arrived, and I remember sneaking into the kitchen to grab a beer from the fridge about 30 minutes before we were supposed to get started to calm my nerves. It didn't really work.

Eventually, everyone packed into the conference room, pizza in hand. Waiting.

I took a deep breath, tried not to make eye contact with anyone, and got started. At the time, I has almost zero actual experience with pull requests. So everything I said over the next 40 minutes was, shall we say, "speculative".

#aintsobad

About 5 minutes into my talk, I started feeling more comfortable. People seemed genuinely interested. A couple of them laughed at my bad jokes. Questions were asked and answered. The conference room was filled with the smell of slightly above-average pizza.

I was gaining confidence.

Pull Requests are a way to start a discussion about new code

That was my thesis. I repeated it several times, with a level of conviction that I think is unique to people who are completely and utterly full of shit.

BUT HERE'S THE THING.

It's now two years later, and I think I was actually right.

Why I wasted your time with that dumb story

I'm about to list a few of the reasons why I think your team should use pull requests. These are the exact same things that I wrote in my slide deck two years ago. When I had pretty much never used pull requests before.

My point is: most of these reasons are actually kind of obvious if you take a minute to think about them. They just make sense. You can imagine a scenario where your team begins using pull requests, and intuitively, you know these things are likely to happen.

But still, here you are. Reading this article. Not using pull requests.

So I'll leave you with the same points I made in my bullshit presentation two years ago. Except now, I know they're true.

Discussion

At their core, I think pull requests are just a way to start a discussion about code. Or at least that's how I'd encourage you to think about them.

But why is talking about code a good thing?

ALLOW ME TO TELL YOU...

Learning

Pull requests give the engineers on your team an opportunity to receive constructive feedback – which is a really, really efficient way to learn. I noticed pretty dramatic changes in the overall quality of code being submitted within about a week from when we started using PRs at Aereo. And things just kept getting better and better.

Ownership

At Aereo, we had a rule that any member of the team could merge a PR except for the person who submitted it. This meant that everyone was responsible for reviewing new code, not just leads.

This greatly increased the sense of collective ownership over the codebase. It set an expectation that all new code needed to meet a certain standard, and my experience was that people actually took that pretty seriously. In a way, the codebase almost became a thing to be defended. It was something we were all proud of, and we wanted to preserve the level of quality we'd been working toward.

Shared Knowledge

I think this one is really important.

As engineers, we have a tendency sometimes to carve out little niches for ourselves. We put our headphones on, tune everything out, and we work on "our part" of the code.

And a lot of the time, we end up with an app that's basically 3 or 4 different apps all mashed together. Nobody knows how the "other parts" work.

When you embrace pull requests, you force people to review code that they may not have otherwise been exposed to. As a result, you end up with a lot of overlapping knowledge.

Wrap-up

If you're interested in using pull requests on your team, here are some basic "rules" to try out. Keep what you like, and drop the stuff you don't.

1. All new code must be submitted via pull request.
2. Every PR must contain tests and documentation (when applicable).
3. A pull request can be merged by any member of the team except for the person who submitted it.
4. Each pull request must include a meaningful description.
5. Large PRs or PRs with breaking changes should be approved by multiple team members or a lead. We use checkboxes in the description for this.

The important thing is to just try it. Call a quick meeting with the whole team, explain what you want to do, and do it.

I guarantee you'll be super glad that you did.

Follow me on Twitter or Medium for more posts. I'm trying to write once a day for the next 30 days.

And if you're in the Boston area and want to come submit pull requests and work on crazy, top-secret things with me at Project Decibel, shoot me an email. I'm hiring.

Right, then.

So, what is Object#valueOf and why should you care?

More or less, it's a method that JavaScript calls automatically any time it sees an object in a situation where a primitive value is expected.

Let's look at a quick example.

var obj = {};

console.log( 7 + obj ); // "7[object Object]"  

Plenty has been written about the insanity of implicit type conversion in JavaScript, so I'm really not interested in going down that road. Hopefully, your takeaway from the example is that we used the addition operator with a number on one side and an object on the other, and we got back a value that doesn't really make a ton of sense.

You can hardly blame JavaScript here, though. It has no way to know how to convert our object into a number.

But as luck would have it, we can actually define that behavior.

var obj = {  
  valueOf: function() {
    return 42;
  }
};

console.log( 7 + obj ); // 49  

See? I wasn't lying earlier. The EcmaScript specification dictates that whenever an object is encountered in a situation where a primitive is expected, that object's valueOf method will be called*.

* Actually, sometimes toString() will be called instead – but I'm not gonna get into it here. You can assume that any time a Number is expected, valueOf will be called. If you're super interested in this stuff, look up the ToPrimitive abstract operation in the ES spec.

Who cares?

Look, I’m not gonna lie to you here (I feel like we’re becoming friends, and I have a pathological need to be trusted). Knowing about valueOf is not going to materially change the way you write code on a day-to-day basis. This post is really about surfacing an interesting little JS feature that a lot of people don’t know about. But that being said, there are some practical applications.

Let's write a little Integer class. I won't go into much detail here, since I will assume that you, esteemed reader, are already intimately familiar with the concept of integers.

You can actually just skip this part if you want...

function Int( val ) {  
  if ( !( this instanceof Int ) ) {
    return new Int( val );
  }
  if ( isNaN( val ) ) {
    throw new TypeError(‘Int value must be a number’);
  }
  if ( val % 1 !== 0 ) {
    throw new TypeError(‘Int value must be an integer’);
  }
  if ( val instanceof Int ) {
    return Int( val._value );
  }
  this._value = Math.floor( val );
}

Int.prototype.add = function( n ) {  
  return Int( this._value + Int( n )._value );
};

Int.prototype.subtract = function( n ) {  
  return Int( this._value — Int( n )._value );
};

Int.prototype.multiply = function( n ) {  
  return Int( this._value * Int( n )._value );
};

Int.prototype.divide = function( n ) {  
  try {
    return Int( this._value / Int( n )._value );
  } catch ( e ) {
    throw new Error(‘Division resulted in non-integer quotient’);
  }
};

Okay. Now we've got an Int class.

It does some type checking. It makes sure you don't pass it a float. And it has some basic arithmetic methods.

Here are a couple quick examples, just to give you a better idea of what this thing looks like:

Int( 6 ).multiply( 2 );        // { _value: 12 }  
Int( 4 ).divide( 2 ).add( 3 ); // { _value: 5 }  

Simple enough. But what if I need to do something like this?

var a = Int( 6 );  
var b = Int( 11 );

Math.min( a, b ); // NaN  

It basically blows up. I mean, it doesn't throw an exception, but it gives me NaN, which is almost as useless.

I trust at this point that you see where we're headed.

Int.prototype.valueOf = function() {  
  return this._value;
};

Easy as that. Now, we'll try that same example – but this time, our Int class has a valueOf method on its prototype.

var a = Int( 6 );  
var b = Int( 11 );

Math.min( a, b ); // 6  

Not bad, right? We can also use instances of Int in other places where a primitive value is expected:

Math.pow( Int( 9 ), 0.5 ); // 3  

The More You Know™

If you liked this post, follow me on Medium or Twitter for more. I'm challenging myself to write every day for the next month.

And if you live in the Boston area and want to work on crazy, top-secret things with me at Project Decibel, shoot me an email. I'm hiring.

For the uninitiated, currying refers to the process of taking a function with n arguments and transforming it into n functions that each take a single argument. It essentially creates a chain of partially applied functions that eventually resolves with a value.

Here's a basic example of how you'd use it:

function volume( l, w, h ) {  
  return l * w * h;
}

var curried = curry( volume );

curried( 1 )( 2 )( 3 ); // 6  

Disclaimer

This post assumes basic familiarity with closures and higher-order functions, as well as stuff like Function#apply(). If you're not comfortable with those concepts, you might want to brush up before reading further.

Writing our curry function

The first thing you'll notice is that curry expects a function as its argument, so we'll start there.

function curry( fn ) {

}

Next, we need to know how many arguments our function expects (called its "arity"). Otherwise, we won't know when to stop returning new functions and give back a value instead.

We can tell how many arguments a function expects by accessing its length property.

function curry( fn ) {  
  var arity = fn.length;
}

From there, things get a little bit trickier.

Essentially, every time a curried function is called, we add any new arguments to an array that's saved in a closure. If the number of arguments in that array is equal to the number of arguments that our original function expects, then we call it. Otherwise, we return a new function.

To do that, we need (1) a closure that can retain that list of arguments and (2) a function that can check the total number of arguments and either return another partially applied function or the return value of the original function with all of the arguments applied.

I usually do this with an immediately invoked function called resolver.

function curry( fn ) {  
  var arity = fn.length;

  return (function resolver() {

  }());
}

Now, the first thing we need to do in resolver is make a copy of any arguments it received. We'll do that by creating a variable called memory that uses Array#slice to make a copy of the arguments object.

function curry( fn ) {  
  var arity = fn.length;

  return (function resolver() {
    var memory = Array.prototype.slice.call( arguments );
  }());
}

Next, resolver needs to return a function. This is what the outside world sees when it calls a curried function.

function curry( fn ) {  
  var arity = fn.length;

  return (function resolver() {
    var memory = Array.prototype.slice.call( arguments );
    return function() {

    };
  }());
}

Since this internal function is the one that ends up actually being called, it needs to accept arguments. But it also needs to add those to any arguments that might be stored in memory. So first, we'll make a copy of memory by calling slice() on it.

function curry( fn ) {  
  var arity = fn.length;

  return (function resolver() {
    var memory = Array.prototype.slice.call( arguments );
    return function() {
      var local = memory.slice();
    };
  }());
}

Now, lets add our new arguments by using Array#push.

function curry( fn ) {  
  var arity = fn.length;

  return (function resolver() {
    var memory = Array.prototype.slice.call( arguments );
    return function() {
      var local = memory.slice();
      Array.prototype.push.apply( local, arguments );
    };
  }());
}

Good. Now we have a new array containing all the arguments we've received so far in this chain of partially applied functions.

The last thing to do is to compare the length of arguments we've received with the arity of our curried function. If the lengths match, we'll call the original function. If not, we'll use resolver to return yet another function that has all of our current arguments stored in memory.

function curry( fn ) {  
  var arity = fn.length;

  return (function resolver() {
    var memory = Array.prototype.slice.call( arguments );
    return function() {
      var local = memory.slice(), next;
      Array.prototype.push.apply( local, arguments );
      next = local.length >= arity ? fn : resolver;
      return next.apply( null, local );
    };
  }());
}

This can be a little bit difficult to wrap your head around, so let's take it step by step in an example.

function volume( l, w, h ) {  
  return l * w * h;
}

var curried = curry( volume );  

Okay, so curried is the result of passing volume into our curry function.

If you look back, what's happening here is:

1. We store the arity of volume, which is 3.
2. We immediately invoke resolver with no arguments, which means that for now, its memory array is empty.
3. resolver returns an anonymous function.

Still with me? Now let's call our curried function and pass in a length.

function volume( l, w, h ) {  
  return l * w * h;
}

var curried = curry( volume );  
var length = curried( 2 );  

Again, here are the steps:

1. What we actually called here was the anonymous function being returned by resolver.
2. We made a copy of memory (which was empty) and called it local.
3. We added our argument (2) to the local array.
4. Since the length of local is less than the arity of volume, we call resolver again with the list of arguments we have so far. That creates a new closure with a new memory array, which contains our first argument of 2.
5. Finally, resolver returns a new function that has access to an outer closure with our new memory array.

So what we get back is that inner anonymous function again. But this time, it has access to a memory array that isn't empty. It has our first argument (a 2) inside of it.

If we call our length function, the process repeats.

function volume( l, w, h ) {  
  return l * w * h;
}

var curried = curry( volume );  
var length = curried( 2 );  
var lengthAndWidth = length( 3 );  

1. Again, what we actually called was the anonymous function being returned by resolver.
2. This time, resolver had been primed with some previous arguments. So we make a copy of that array [ 2 ].
3. We add our new argument, 3, to the local array.
4. Since the length of local is still less than the arity of volume, we call resolver again with the list of arguments we have so far – and that returns a new function.

Now it's time to call our lengthAndWidth function and get back a value.

function volume( l, w, h ) {  
  return l * w * h;
}

var curried = curry( volume );  
var length = curried( 2 );  
var lengthAndWidth = length( 3 );

console.log( lengthAndWidth( 4 ) ); // 24  

This time, the steps are a little bit different at the end:

1. Once again, what we actually called was the anonymous function being returned by resolver.
2. This time, resolver had been primed with two previous arguments. So we make a copy of that array [ 2, 3 ].
3. We add our new argument, 4, to the local array.
4. Now the length of local is 3, which is the arity of volume. So instead of returning a new function, we return the result of calling volume with all of the arguments we've been saving up, and that gives us a value of 24.

Wrapping up

Admittedly, I have yet to find a super compelling use-case for currying in my day-to-day work. But I still think that going through the process of writing functions like this is a great way to improve your understanding of functional programming, and it helps reinforce concepts like closures and first-class functions.

By the way, if you like nerdy JavaScript things and live in the Boston area, I'm hiring at Project Decibel. Shoot me an email.

First and foremost, this post is about what to expect if you're interviewing with me. But it's also about how to conduct a technical interview of JS candidates, and which areas offer the best signal-to-noise ratios.

This is Not a Test

The most important thing that I try to stress in any technical interview is that I'm not administering a test. What I'm really interested in is using questions as a tool for facilitating a conversation about code.

So if I ask you to write a memoize() function, what I really want is to give us a starting point to talk about higher-order functions and closures. I don't really care if you can write that function off the top of your head. Instead, what I'm really looking for is whether or not you can arrive at a solution with a little bit of guidance, and if you understand the underlying concepts.

If you get stuck along the way, ask for some help. And if you flat out don't know an answer, that's okay too. I'll do my best to explain it, and we'll work on another example together.

One of the most impressive things you can do in an interview is learn something new and then apply it. It lets me see how you think about problems and assimilate new information.

Anyway, the point is: not knowing things is totally okay.

Whiteboards

There seems to be a lot of anxiety these days about whiteboarding during interviews. Every couple weeks, I see an article on Hacker News about what a terrible, outmoded practice this is.

And for the most part, I agree.

That said, if you interview with me, you should expect to walk in to a room with a whiteboard on the wall. And you should expect that we'll use it.

Whiteboards are great for quick examples. If I ask you what an IIFE is, or how to write a ternary expression, I expect you to be able to jot that down on a whiteboard. Or maybe I'll write a function on the board and ask you what its return value is given a certain set of arguments.

What I won't ever do – and what I think is the primary cause of apprehension about whiteboarding – is ask you to write some big, 20-line function on a whiteboard. It's unnatural, it's slow, and frankly, it's pretty hard for me to read your code that way anyway.

Frameworks & Libraries

Don't care.

As JavaScript engineers, we use third-party code all day, every day. On the front-end, there's jQuery, Underscore, Backbone, Ember, Angular, React, Moment, D3, Bluebird, THREE, and a million others. With Node, there are currently something like 166,000 packages on npm.

We're all learning new APIs constantly, and it's totally unreasonable to expect that you happen to know the same ones that I do. I will almost never ask specific questions about libraries or frameworks.

If you've got a strong understanding of fundamental JS concepts, you'll learn the libraries we're using pretty quickly.

I'm just not that worried about it.

Closures and First-Class Functions

Super important. I expect everyone I interview to be very comfortable with these concepts.

Here's a typical example that I might present to a candidate:

// write a function called `partial` that makes 
// the following snippet work

function add( a, b ) {  
  return a + b;
}

var add5 = partial( add, 5 );

add5( 4 ); // 9  

If that elicits a deer-in-the-headlights look, I might steer the discussion like this:

"Okay, so it looks like partial accepts two arguments. One is a function, and the other is a number."

That'll usually get us at least to this point:

function partial( fn, num ) {

}

"Great. And partial must return a function, because we're assigning its return value to add5 and then calling add5()".

partial( fn, num ) {  
  return function() {

  };
}

"Cool. That's the basic idea. So, if add5 is the function that partial returns and it expects a number as an argument, where does that go?"

Usually, this is the point where a light bulb turns on.

partial( fn, a ) {  
  return function( b ) {
    return fn( a, b );
  };
}

Again, the point here is not necessarily that you can do this without any help (although that's great, and it's what I'd expect from a more senior candidate). What I'm really hoping is that you can get there with a little bit of direction.

Prototypal Inheritance

This is definitely an area that tends to separate junior devs from more senior ones, although in my mind, it's something everyone applying for a JS role should know.

Here's a problem that I might give to a candidate:

// make a class called `Square` that inherits from 
// `Rectangle` and satisfies the following snippet

function Rectangle( width, height ) {  
  this.width = width;
  this.height = height;
}

Rectangle.prototype.area = function() {  
  return this.width * this.height;
};

// your code here

var square = new Square( 4 );

square.area(); // 16  
Square.prototype.area === Rectangle.prototype.area; // true  

If this looks foreign to you, I would strongly recommend brushing up on prototypal inheritance. It's really not very hard once you get the hang of it, and it's an extremely powerful and important feature of JavaScript.

Oh, and here's the answer:

function Square( length ) {  
  Rectangle.call( this, length, length );
}

Square.prototype = Object.create( Rectangle.prototype );  

What's this?

There's probably no other feature in JS with a worse simplicity-to-confusion ratio than the this keyword. You can basically learn everything about it in an hour, but so many JS developers never do.

You should know how Function#call() and Function#apply() work. They are absolutely essential to writing JS at a high level, and they're super easy to wrap your head around.

This is low-hanging fruit.

Async

Another big one, especially if you're applying for a job where you'll be using Node.

Here's a question I might ask:

// write a function called `shout` that accepts
// a string and a callback function, and uses
// `exclaim` and `yell` to transform its input

function exclaim( value, fn ) {  
  setTimeout(function() {
    fn( value + '!' );
  }, 100 );
}

function yell( value, fn ) {  
  setTimeout(function() {
    fn( value.toUpperCase() );
  }, 100 );
}

shout( 'hello', function( shouted ) {  
  console.log( shouted ); // 'HELLO!'
});

Again, this is really something that I expect every JS candidate to be comfortable with. If you're about to interview for a JS gig and you're not familiar with this stuff, drop what you're doing and spend some time practicing. It's that important.

Oh, and the solution to that problem:

function shout( value, fn ) {  
  exclaim( value, function( exclaimed ) {
    yell( exclaimed, fn );
  }); 
}

Trick Questions

Personally, not a fan.

In the rare occasion that I do ask a trick question, I'll call it out beforehand, and I won't really care if you miss the "trick". What I'm really trying to accomplish in cases like this is to start a conversation.

"Not quite. Remember, variables get hoisted in JavaScript..."

"That's actually a ReferenceError. Can you see why?"

Questions like this can be really useful, but I use them pretty sparingly because nobody likes to feel like they've been set up for failure.

Advanced Stuff

Okay, so you were able to breeze through closures, prototypal inheritance, and async functions. Now what?

At this point in an interview, I'm usually pretty confident that a candidate has an intermediate to advanced understanding of the language, and my goals for the interview start to shift a little.

What I really want to know now is how much you know. I'm trying to get a sense of the shape and depth of your JavaScript knowledge.

This is where we start to move away from core concepts and I might start asking about specific language features or more advanced functional programming.

I might ask you to use Object.defineProperty or to write a curry function. Maybe we'll talk about promises or recursion.

These are things that you don't really have to know, per se, but since you've got the basic stuff down, I need to ask these types of questions to get a better sense of how advanced you are.

Think of this as extra credit. It's an opportunity to impress me. Anything we talk about at this point is essentially just bonus material.

Memorization

This is sort of a tricky area, and I'm a little bit conflicted.

I expect a senior level JS person to know the argument signatures for Array#splice() or Function#bind().

At the same time, I have never worked in an office without an Internet connection – and looking something up on MDN takes about 20 seconds.

I never explicitly quiz candidates on stuff like this, because it just doesn't strike me as being particularly important. That said, if I realize during the course of our interview that you don't know how to use a common method like Array#push(), that's a pretty good indicator that you haven't been writing JS for very long.

In short: Learn the most commonly used stuff, but don't feel like you need to memorize the entire EcmaScript spec.

Ask Questions

If you only take one thing away from this post, let it be this:

If you don't know something, or you aren't sure, ask me.

Not knowing something is a problem with a very simple solution. Lacking intellectual curiosity is much harder to fix.

I love hiring candidates who need a bit of mentoring. It's fun for me, and it's great for the team. One of the best ways to crystalize your own understanding of a concept is to explain it to someone else, and fostering a team environment where we're all teachers and students is the best way I know to continually raise the bar for everyone.

We all have plenty more to learn, myself included. My goal has always been to hire people who embrace that fact, and who are genuinely excited about learning new things and becoming stronger engineers.

I'm Hiring

Is this hypothetical interview sounding pretty fun to you? Are you in the Boston area?

Shoot me an email, and come work on crazy, top-secret things at Project Decibel.

I tried to copy the markdown from the Gist I wrote, but it looked like garbage with my site's stylesheet, so here's a link instead.

Enjoy.

These examples are by no means an exhaustive overview of what's new in ES6, and since
the spec isn't complete, a lot of these are subject to change. Nonetheless, it's still
kind of fun to get an idea of what the future of JavaScript looks like.

Disclaimer: I'm not saying that the following examples are necessarily The Right Way™ to refactor in ES6. They're really just meant to be a vehicle for demonstrating some cool new stuff.

_.range

The first example comes from Underscore's _.range method. Here's the original:

_.range = function(start, stop, step) {
  if (arguments.length <= 1) {
    stop = start || 0;
    start = 0;
  }
  step = arguments[2] || 1;

  var len = Math.max(Math.ceil((stop - start) / step), 0);
  var idx = 0;
  var range = new Array(len);

  while(idx < len) {
    range[idx++] = start;
    start += step;
  }

  return range;
};

The thing I love about this example is that the problem is so straight-forward. It's hard to imagine
anyone taking a drastically different approach here. Sure, some people might not initialize that
range array with a length, and would instead rely on pushing values. But ultimately, the basic mechanism is going to be the same.

What does stand out though, at least to me, is all that boilerplate in the first few lines of the function
body. This is a pretty common sight in JavaScript for polymorphic methods. There's really never been
a particularly elegant way to deal with a variable number of arguments.

Fortunately, this is one area where ES6 really comes through. Here's the same method, refactored
to take advantage of some of ECMAScript's forthcoming features:

_.range = function(start = 0, stop = start, step = 1) {
    var len = Math.max(Math.ceil((stop - start) / step), 0),
        range = new Array(len);
    for (let idx = 0; idx < len; ++idx) {
      [range[idx], start] = [start, start += step];
    }
    return range;
};

The first thing you'll notice is that we've got default parameters. Because I can define
defaults, I was able to remove 5 lines of code right off the bat. Not only that, but I think
this syntax is also significantly more explicit, especially once you get used to it.

Second change is the use of the let statement in the loop. let is similar to var, except it has
block scope rather than function scope. In this case, there's honestly not much of a difference, but it
seemed worth demonstrating - especially since let is already implemented in Firefox, Chrome, and IE11.
In this case, the main advantage is basically cosmetic. Since idx is only important to me inside that loop,
I can scope it accordingly to reflect that.

The third change is the destructiring assignment inside the loop. I'm not going to dive into that, because
my explanation wouldn't be nearly as good as what you'll get by reading This post
by Nick Fitzgerald. And you should definitely read that. Immediately.

Really. Go ahead, I'll wait.

Backbone.Model

Oh good, you're back.

Next example comes from Backbone's Backbone.Model:

var Model = Backbone.Model = function(attributes, options) {
    var defaults;
    var attrs = attributes || {};
    options || (options = {});
    this.cid = _.uniqueId('c');
    this.attributes = {};
    _.extend(this, _.pick(options, modelOptions));
    if (options.parse) attrs = this.parse(attrs, options) || {};
    if (defaults = _.result(this, 'defaults')) {
        attrs = _.defaults({}, attrs, defaults);
    }
    this.set(attrs, options);
    this.changed = {};
    this.initialize.apply(this, arguments);
};

This is a simple example, but also a pretty important one. Defining "classes" in JavaScript
has always been a little bit awkward. First, you write a function (and probably capitalize the first
letter to indicate that it's a constructor, though this is just a convention). Then, completely outside
of that function definition, you start adding methods to its prototype object. It just looks sort of messy,
and fails to really convey what your intention is.

This is where ES6 classes come in:

var Model = Backbone.Model = class Model {
    constructor (attrs = {}, options = {}) {
        this.cid = _.unique('c');
        this.attributes = {};
        _.extend(this, _.pick(options, modelOptions));
        if (options.parse) attrs = this.parse(attrs, options) || {};
        if (defaults = _.result(this, 'defaults')) {
            attrs = _.defaults({}, attrs, defaults);
        }
        this.set(attrs, options);
        this.changed = {};
        this.initialize.apply(this, arguments);
    }
};

Not too much has really changed here, except for the fact that we're substituting that anonymous
constructor function with a class definition. Then we just move the original function body inside
of the constructor definition and pretty much call it a day, aside from swapping out some boilerplate
for default params.

The beauty here is that (a) this is a lot more explicit, and (b) we can also put our methods
inside the class definition, like this:

var Model = Backbone.Model = class Model {
    constructor (attrs = {}, options = {}) {
        ...
    }
    sync() {
        return Backbone.sync.apply(this, arguments);
    }
    get(attr) {
        return this.attributes[attr];
    }
};

So now we're being a lot clearer about the intent of the code. The constructor and method definitions
are all living in the same place. It's easier to read and understand what's going on.

Backbone.Collection#toJSON

This final example is a really small one, but it lets me demonstrate one of my favorite ES6 features.

Here's the original code for Backbone.Collection#toJSON:

toJSON: function(options) {
    return this.map(function(model){ return model.toJSON(options); });
}

That inner line, where we pass an anonymous one-line function to map is something that happens
all the time in JavaScript.

Soon, we'll have an easier way:

toJSON2: function(options) {
    return this.map(model => model.toJSON(options));
}

If you've ever used CoffeeScript, this should look pretty familiar. If not, that's called a fat-arrow function.

Basically, it's shorthand syntax for an anonymous function that returns a value. It doesn't need a function keyword,
the parens are optional when there's a single parameter, the value of this is bound to the containing scope,
and automatically return the value of the expression following the fat arrow.

Wrapping up

The point here wasn't really to give a comprehensive or in-depth overview of everything in ES6. It's really
just to highlight a few interesting changes in the context of how they might be used in the real world. I highly
recommend reading the proposals and trying this
stuff out for yourself.

If that sounds fun, check out Google's Traceur Compiler, which lets
you write ES6 and compile it into valid ES5. They even have an online version
that's great for quick experiments, or if (like me) you're just too lazy to download the code.

Did you know you can set display:block; on things like <title/> elements? Kind of cool, right? If you're super concerned about crazy small request sizes, you could probably save a couple bytes by displaying your <title> instead of an <h1>. Overkill, for sure -- but still sort of interesting.

But another, slightly cooler trick is adding a display:block; white-space: pre; rule for select <script> elements.

This is kind of awesome for times when you want to include a code sample in your page, but you also want that code to actually execute. Sure, you don't get syntax highlighting -- but you do get a couple extra nerd points. And you reduce the weight of your page a bit by not duplicating that code.

The More You Know™