I was recently chatting with a friend while we were on a hike, and we started to discuss the differences between var, const, and let in Javascript. We talked about the what, how, and when to use each. And from that discussion, this post was born…

First, a little history. In the dark ages of Javascript (pre-ES6, that is) there was only the var. If you wanted to declare a variable, all you had to do was pound on the keys v-a-r and you were done. There were no other decisions that had to be made. Life was easy… Then came along ES6 with all of its fancy options, meh. Life was never to be simple again (cue sad music).

Okay, enough with the melodrama ;-)

The introduction of const and let to es6 is a very welcome and needed update. Const and let introduced block scope to Javascript (an idea that is prevalent in many other languages, including C and C++). Let’s see how it works.

let status = 'awake';

{ // a new block -- yawn, let's take a little nap

  let status = 'napping';
  console.log(status); // napping

} // time to get back to work -- end nap

console.log(status); // awake -- as expected

So, because let is block-scoped (blocks being defined by the code between the opening and closing curly braces), the status is still ‘awake’ outside of the block. The inner status of ‘napping’ doesn’t leak out of the block into the outer scope. (Const, like let, is also block-scoped.)

Now, let’s look at var. Var is function-scoped.

var status = 'awake';

{ // a new block -- yawn, let's take a little nap

  var status = 'napping';
  console.log(status); // napping

} // time to get back to work -- end nap

console.log(status); // napping -- yikes

As you can see, var doesn’t respect the block. The napping that was declared inside of the block, clobbered the declaration made outside of the block. As mentioned earlier, this happened because var is function-scoped as opposed to block-scoped.

Takeaway — if you don’t want to get caught napping at work, use let or const.

Another example where this might cost you some time debugging is in order…

let count = 5;
// 20 lines of code

for(let count = 0; count < 15; count++) {
  // do stuff
}

// 10 lines of code
console.log(count); // 5 -- as expected

Using let, things are as they should be. Now it’s var’s turn…

var count = 5;
// 20 lines of code

for(var count = 0; count < 15; count++) {
  // do stuff
}

// 10 lines of code
console.log(count); // 15 -- smh

I hope that by this time, if you didn’t understand before, you understand block-scoping vs functional-scoping with regards to let, const, and var. (I know that I haven’t touched on const at all, yet, and that is because it acts exactly like let when it comes to scope.)

Your wait is over… The time has come to talk const. The const keyword creates a declaration that cannot be reassigned.

const reassignMeAtYourOwnPeril = 'Klaatu Barada Nikto';
reassignMeAtYourOwnPeril = 'Klaatu Verada Nec...';
// error -- the world is safe
console.log(reassignMeAtYourOwnPeril); // never runs

In the above example trying to reassign the const declaration creates an error and the console.log code will never be executed. Let’s see what happens when we run the same code using var or let (both var and let have the same behavior with regards to reassignment).

let reassignMeAtYourOwnPeril = 'Klaatu Barada Nikto';
reassignMeAtYourOwnPeril = 'Klaatu Verada Nec...';
console.log(reassignMeAtYourOwnPeril); // Klaatu Verada Nec...
// code executes and the dead rise -- oops...

As you can see, a variable declared with let, similarly to var, can be reassigned. (Possibly having some dire consequences…)

Alright, now I’m about to ask you to look at a code sample and make a decision. Adjust your browser window accordingly so that you don’t accidently see the answer that is going to be just underneath the code sample… I want to go over a point of possible confusion regarding a const declaration. Look at the code sample below and decide whether or not an error will occur.

const booksOfTheDead = ['Vol 0', 'Vol 1', 'Vol 2'];
booksOfTheDead[0] = 'Necronomicon';  // Will this cause an error?

If you’re finding this content helpful in some way, don’t be shy, give me a clap :-) Thanks!

If you decided that an error would not occur, then you decided right! The const declaration has to do with reassignment. When we change an item in an array, reassignment is not occurring. Rather, we are making a change to the underly data structure (an array in this case).

Here is a similar code sample that will result in an error…

const booksOfTheDead = ['Vol 0', 'Vol 1', 'Vol 2'];
booksOfTheDead = []; // Error, can't reassign

See the difference? In this last example, we are trying to reassign booksOfTheDead to an empty array, which is not going to be allowed when using a const declaration.

Lastly, I would like to share the rule that I follow when deciding whether I should use var, const, or let. First, I look at const. If I’m not intending to do any reassignment, then const is a clear winner. (You should use const whenever you can.) Next, I look to let. And I basically use let in every situation where I don’t use const, ie, there will be a reassignment. My last choice is var. If for some reason, neither const nor let will provide me with the needed behavior, then fine, var it is…

A final note on const — using const is beneficial because it is making your intention explicit. When another programmer comes along, perhaps even yourself, weeks — months — years later, and they need to make some change to the codebase, it is very beneficial for them to know the declarations that are being reassigned vs those that should definitely not be reassigned. It can save a lot time lost, and frustration had, by debugging. Do the world a solid, use const if you can.

The difference between var, const, and let in Javascript is… was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, whoever may be reading this from the future, I hope that your journey into the wonderful world of software engineering has been awesome! Mine started a few years back, and I must say, it has definitely been one of the best experiences, to date, of my life :-)

Today, I went to an interview-prep meetup at the way-too-early time, 8:30am. The subject was Binary Trees, and we were given a few problems to solve. (Quick shout-out to Jack Wong for hosting the meetup!) Well, I solved the problems, and I thought, why not write a blog post explaining the problems, and then, the solutions that I came up with.

** Disclaimer — I am not under the impression, nor do I claim, that my solutions are the most efficient. The solutions that I came up with are just that… solutions that I came up with o_O

The Problems:

1. Build a Binary Tree (note — not a Binary Search Tree)

2. Find all paths to leaves (ie, 2–3–9, 2–3–4, 2–8–7, 2–8–1)

3. Find the longest sequential path

4. Invert the Binary Tree from the earlier problem

Give it a go! After you’ve come up with your own solutions, or at a minimum, put some thought into how you would solve these problems, check out my solutions.

The Solutions:

1. Build a Binary Tree (note — not a Binary Search Tree)

const Node = function(value) {
  this.value = value;
  this.right = null;
  this.left = null;
};

Node.prototype.insert = function(value) {
  
  let queue = [this],
      node;
  while(queue.length) {
    node = queue.shift();
    if(node.left && node.right)
      queue.push(node.left, node.right);
    else
      break;
  }

  if(!node.left)
    node.left = new Node(value);
  else
    node.right = new Node(value);
};

let root = new Node(2);
[3,8,9,4,7,1].forEach(value => root.insert(value));

A few notes on the above code…

• I used a queue to populate the tree because a queue allows me to traverse level by level looking for leaves. Using this strategy, the tree will populate level by level from left to right.
• Putting all of the values in an array and iterating over them is a nice way to keep your code looking clean.

2. Find all paths to leaves (ie, 2–3–9, 2–3–4, 2–8–7, 2–8–1)

3. Find the longest sequential path

Decision — because problems 2 and 3 seemed to share a lot in common, I decided to use one function to do both.

const allPaths = function(node) {
  // get all paths to leaves and longest, 
  // increasing by one, sequence

  let maxSequence = 1,
   paths = [];

  const _recurse = function(node, currentSequence, currentPath) {

    if(node.value - currentPath[currentPath.length - 1] === 1)
      currentSequence++;
    else
      currentSequence = 0;

    currentPath.push(node.value);

    if(!node.left && !node.right) {
      // at a leaf, compare currentSequence to maxSequence
      if(currentSequence > maxSequence)
        maxSequence = currentSequence;

      paths.push(currentPath.slice());
      return;
    }

    if(node.left)
      _recurse(node.left, currentSequence, currentPath.slice());

    if(node.right)
     _recurse(node.right, currentSequence, currentPath.slice());
  };

  _recurse(node, 1, []);
  return {paths, maxSequence};
};

A few notes on the above code…

• I’m using the slice method so that each new stack frame will have its own copy of the currentPath. Using this strategy, when the stack frame is popped off the stack, the frame under it will have a currentPath that accurately reflects its state. If currentPath was passed in without using the slice method, the underlying array would be mutated, and the state in each stack frame would be altered.

• {paths, maxSequence} is equivalent to {paths: paths, maxSequence: maxSequence} — keeps the code looking clean.

If you’re finding this content helpful in some way, don’t be shy, give me a clap :-) Thanks!

4. Invert the Binary Tree from the earlier problem

const invertTree = function(node) {

  const queue = [node];
  let currentNode,
    temp;

  while(queue.length) {
    currentNode = queue.shift();
    if(!currentNode) continue;

    temp = currentNode.left;
    currentNode.left = currentNode.right;
    currentNode.right = temp;

    queue.push(currentNode.left, currentNode.right);
  }
};

A few notes on the above code…

• Again, the queue is proving to be useful.
• In order to test this code, I wrote a standard in-order traversal.

const traverse = function(node, arr) { // in order traversal
  if(!node) return;

  traverse(node.left, arr);
  arr.push(node.value);
  traverse(node.right, arr);
};

• Then used the following code to verify that the inversion worked...

let arr = [];
traverse(root, arr);
console.log('Tree before inversion ', arr);

invertTree(root);
arr = [];
traverse(root, arr);
console.log('Tree after inversion ', arr);

And that wraps it up! If you made it this far, I commend you on your focus ;-)

Binary Tree Problems. was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Web Sockets… Why should I use them? What problem do they solve? Those questions, in addition to how to use them, are within the scope of this blog post. So, if you’re interested, please continue to read, if not, no offense taken… click me :-) ← click either way…

You should use web sockets because ‘I say so.’ Phew, that question was easier to answer than I had originally anticipated. I guess the latter question might be the more challenging one to answer ;-)

Time to get serious. What problem does web sockets solve? Web sockets provide a protocol that allows a client to receive information from a server, via a server push, after an initial connection has been established. Typically, using HTTP, a client sends a request to a server, the server sends back a response, and then the connection is terminated. However, leveraging the web socket protocol, a connection can persist as long as it may be needed.

Let’s write a little code illustrating how to use web sockets, and perhaps, the WHY will become clear (if it isn’t transparent, just yet).

Using npm, we can install socket.io-client and socket.io, through terminal, with the following commands.

npm i socket.io socket.io-client

Now that we have a socket server and client, presumably, available in our node_modules directory, we can require and import them, respectively, for use.

First, let’s handle setting up sockets on the server (using the Express Framework).

const app = require('express')();

const server = app.listen(3000, function() {
  console.log('listening on port 3000');
});

const io = require('socket.io')(server);

io.on('connection', (socket) => {
  console.log('socket connection made to socket ', socket.id);
});

At this point, we have successfully set up server-side sockets, but they really aren’t doing anything interesting, just yet… They are simply logging a message each time a unique socket connection is made.

Let’s add something useful. How about, each time a post is made to a message board, we update the message board that is being rendered on each client’s computer.

app.post('/message', function (req, res) {

   const message = req.body;

   //  put message in database
   database.add(message);

   // send message out to all sockets (not the use of io)
   io.sockets.emit('topicCreated', {message});
});

Now we have a server that is ready to receive posts and will update all the client computers with the new message. The next step is to set up a socket connection on the client.

import io from 'socket.io-client';

socket.on('connect_error', function(err) {
  console.log('error connecting to server');
});

socket.on('topicCreated', ({message}) => { 
  console.log(message);
});

If you’re finding this content helpful in some way, don’t be shy, give me a clap :-) Thanks!

And that is it! If you have been following along, congrats, you’ve just implemented web sockets! Sure, right now we are simply logging the message that comes from the server to the console; when really, we should be rendering the message to the message board. But that is out of scope for this blogpost. The important takeaway is that the client doesn’t have to request the new information; rather, the information is sent by the server as it becomes available.

I hope that you feel empowered, if you didn’t already, to give web sockets a try on your next project. They really help us (programmers, that is) in our quest to facilitate an awesome user experience for all those that use our software!

The Wonderful World With Web Sockets was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I initially learned about Javascript Promises, they seemed obscure, and honestly, I failed to grok the value proposition. At the time, I felt comfortable with asynchronous behavior using callbacks and didn’t see any point in stirring what appeared to be a pot at equilibrium. Enter, database queries with node… The aforementioned pot went from stasis, to a rolling boil, to an outright tempest. In the midst of the tumult, I made a promise and was able quell the gale. Now, I am a true believer, a zealot, even.

So, what is a Javascript Promise and when would it be in my best interest to use one? Well, I think that answering the latter will help with an understanding of the former. In the world of asynchronous code, callbacks become requisite, as halting code execution in order to wait for an outside task to complete would make for a really abhorrent user experience. Callbacks are used in order to facilitate synchronous behaviour in an async world. Which leads, inevitably, to code styles as such:

readDataFromFile('path/to/file', (err, data) => {
   sendDataToWebsite(data, (err, response) => {
       writeResponseToFile(response, (err, success) => {
           console.log('Information was written', success);
       });
   });
});

As you can see, the code is already starting to look a bit unwieldly, and this is only three async operations (without even introducing error handling). So, let’s introduce error handling and see what happens :-)

readDataFromFile('path/to/file', (err, data) => {
  if(!err) {
    sendDataToWebsite(data, (err, response) => {
      if(!err) {
        writeResponseToFile(response, (err, success) => {
          if(!err) {
            console.log('Information was written', success);
          } else {
            console.error('error writing response to file', err);
          }
        });
      } else {
        console.error('error sending data to website', err);
      }
    });
  } else {
    console.error('error reading data from the file', err);
  }
});

Wow, that got ugly real quick. As I hope that I have clearly illustrated, callbacks can create a codebase that is difficult to read, write, and generally, just ugly to look at. Fear not, I promise that promises will right this wrong. Let’s refactor the above code and pretend, for now, that each one of the above functions returns a promise.

readDataFromFile('path/to/file')
  .then(data => {
    return sendDataToWebsite(data);
  })
  .then(response => {
    return writeResponseToFile(response);
  })
  .then(success => {
    console.log('Information was written', success);
  })
  .catch(err => {
    console.error('err', err);
  })

I must admit, there is something quite satisfying about transforming that ugly pre-promises codebase to something more… hmmm, palatable. Perhaps, palatable is a bit too tepid. I think that delightfully delicious is more apt :P

If you’re finding this content helpful in some way, don’t be shy, give me a clap :-) Thanks!

I pray that the why of promises has penetrated deep into your bowels. That is has inextricably attached itself to the neurons that fire callbacks. Good. Now, let’s peek into the black box and witness the genesis of a promise.

let readDataFromFile = function(pathToFile) {
  return new Promise((resolve, reject) => {
    readFile(pathToFile, (err, data) => {
      if(err) {
        reject(err);
      } else {
        resolve(data);
      }
    });
  });
}

Here, we have written the readDataFromFile function in a way that utilizes the promise constructor. If you are familiar with the way that error handling with callbacks in node is usually handled, then this code should feel somewhat familiar. Check this out.

readFile(pathToFile, (err, data) => {
   if(err) {
      console.error('error reading from file', err);
   } else {
      // do something with data
   }
});

As you can see, essentially, we are just wrapping a normal async function (readFile) in a promise and calling reject or resolve, depending on if we have an error or success. It is really that simple. If resolve is called, the then method will be invoked, but if we call reject, the catch method will be invoked. And because we are returning a promise from each then method, we can continue to chain them together to make beautifully readable code.

If you haven’t already been using promises, my hope is that you feel empowered to give them a try. And if you have, I hope that you were still able to find something interesting in this blog post. If not, my apologies… When you feel comfortable with the concept of promises, I suggest that you check out bluebird.js. I would love to begin discussing bluebird.js, but I think that is a blog post best left for another day…

Promises. was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Elegant, succinct, academic… When I think of recursion, these are the words that permeate my mind-space. Crafting an elegant recursive solution to a problem may be seen as a rite of passage for many software engineers. Once you have a handle on the recursive paradigm of thought, you can wield it to solve coding puzzles with minimal lines of code. You will have finally arrived at the place where you always knew you wanted to be… Maybe. Is recursion really deserving of all the hype? I’m not sure, but let’s find out.

First, let’s start off with a canonical recursive problem, ie, finding the factorial of a given number, n.

let factorial = function(n) {
  return n === 0 ? 1 : n * factorial(n - 1);
};

Denying the elegance of this solution would be an exercise in futility; however, one might argue that the iterative approach is easier to read.

let factorial = function(n) {
  for (var product = 1; n > 0; n--) {
    product *= n;
  }
  return product;
};

In order to deem whether or not recursion is a worthy recipient of the adoration of so many, I think it best to try and understand the cost and benefits associated with it. Let’s begin with the benefits.

The nature of recursion lends itself to pithy code. As there is a positive correlation between lines of code and maintenance costs, this results in a plus one for recursion.

At times you may find yourself dealing with a data structure that may be variable in length, like a tree. Recursion is a good fit for iterating over something of unknown depth because it naturally wants to continue down the path. Another point for recursion…

Though I might definitely be missing a benefit or two, I feel that the aforementioned benefits of recursion are the most obvious to me. Now, we should attempt to understand the costs that accompany these benefits…

Although recursive code may, at times, be more succinct, it can definitely be more difficult to read and understand the author’s intent. In addition, debugging recursive code can be, at times, an arduous task fraught with frustration. If you are wondering what makes debugging recursive code more daunting than other code, then you are wondering just the thing I am about to address, nice :-). I find that debugging recursive code can prove to be a daunting task because as new execution contexts are created, with each recursive call, it can be challenging to discern which execution context you are currently in, as the variables associated with each execution context share the same names. This difficulty debugging definitely results in a negative point for recursion.

Another cost that is inherent to a recursive solution is the cost associated with function invocation. When a function is invoked, a stack frame is created; when a function finishes, the stack frame is popped off the stack. The invocation of a function is an expensive process because a new execution context has to be created each time, and each execution context has a set of variables that are available to that context. When writing a recursive solution, you end up calling the same function many times... Subtract a point from recursion.

If you’re finding this content helpful in some way, don’t be shy, give me a clap :-) Thanks!

As I mentioned earlier, recursive code is apt for a certain type of problem, ie, ones where the depth that needs traversal is unknown; however, certain problems do not lend themselves to a recursive solution. One such problem that comes to mind is a breadth-first traversal of a binary tree. Sure, it can be solved with recursion (through some creative programming), but in this case, I find that the iterative approach is far more suitable.

Below is code for a breadth-first traversal that pushes nodes into an array if they pass a test based on their value and depth.

Tree.prototype.BFSelect = function(filter) {
  let newArr = [], queue = [], depthQue = [];

  let node, depth;
  queue.push(this);
  depthQue.push(0);

  while(queue.length) {
    depth = depthQue.shift();
    node = queue.shift();

    if(filter(node.value, depth)) {
      newArr.push(node.value);
    }

    depth++;
    node.children.forEach(childNode => {
      queue.push(childNode);
      depthQue.push(depth);
    });
  }

  return newArr;
};

An iterative approach to this kind of problem (BF binary tree traversal) seems like the logical solution because you are wanting the traverse the tree level by level. As mentioned earlier, recursion tends to naturally want to follow a path all the way to the bottom, at which point it begins its journey back through the stack frames (not an ideal paradigm for a problem such as this).

A confession… I started writing this article with a fairly negative view of recursion; however, during the process of writing this article, which naturally required many moments of reflection, I find that I have reached an understanding, and acceptance, of recursion that I had not formerly had. I still think that an iterative approach is probably more suited for most situations, for reasons that I touched on earlier, but I won’t write-off recursion just yet.

Backbone vs React vs Angular: data passing and event listener.

Every interactive application has paths for data to flow. To the uninitiated, these paths may be hard to discern. At first, it may feel as though you are traveling through an unfamiliar wilderness during the eve; however, just as the dawn is sure to come, so too, will understanding illuminate your mind. The paths, that only minutes before were shrouded in darkness, exist, defined in the light.

React, Backbone, and Angular, all have paths of a similar nature. As the state of the application changes, due to actions by a user, data is often fetched, manipulated, and rendered. How are the components, which are isolated by nature, to communicate with one another? The answer is interface. Just as auditory data leaves our body primarily through our mouths and is primarily received through our ears, data is passed through one part of BRA (Backbone, React, Angular) interface, but received by another.

While all three frameworks have syntactical differences, they share many patterns when it comes to moving data. When initializing a backbone view, the view is often linked to a model, or a collection of models, where listeners are set. The event listeners are attached to the model, firing when a particular event happens. This might indicate a change of state in the model, or perhaps, an event triggered by a user.

const VideoPlayerView = Backbone.View.extend({

  initialize: function() {
    this.listenTo(this.collection, 'select', this.selectVideo);
  },

  selectVideo: function(selection) {
    this.model = selection;
    this.render();
  },

  render: function() {

    if (this.model) {
      this.$el.html(this.template(this.model.attributes));
    } else {
      this.$el.html('<div class="loading">Please wait...</div>');
    }
    return this;
  },

  template: templateURL('src/templates/videoPlayer.html')

})

In the above example, an event listener is being placed on the select event of the collection. When a model is selected, the event will bubble up through the collection and trigger the select event, which will in turn, change the model associated with the view, and thereby render the new model.

Let’s explore how React handles a similar situation.

const VideoPlayer = (props) => (
   <iframe
      src={`https://www.youtube.com/embed/
          ${props.video.id.videoId}?autoplay=1`}
      allowFullScreen>
   </iframe>
   <h3>{props.video.snippet.title}</h3>
   <div>{props.video.snippet.description}</div>

  );

Bring your attention to the props argument that is being passed into the anonymous function. The argument that is passed to the anonymous function when VideoPlayer is instantiated, will have any property information that the parent component wishes to impart on its child. Through this mechanism, the parent component can pass down information that the child component can use to render itself. If any property information changes upstream, that is being passed through the props argument, those changes will be reflected in the child component. In addition, the parent component can pass through bound functions as properties on the props argument that can be attached to any event listener along the way. The VideoPlayer component above is stateless; however, if its parent component has state, it will cause VideoPlayer to render anew when relevant changes to the parent’s state occur.

If you’re finding this content helpful in some way, don’t be shy, give me a clap :-) Thanks!

Data flows through Angular components in a similar way to what we have seen with Backbone and React. Typically, data flows from parent to child at the time of the child’s instantiation.

<video-player video="$ctrl.currentVideo">
   <h5>videoPlayer component goes here</h5>
</video-player>

The child binds the data that is coming in through a bindings property that exists on every component.

angular.module('video-player')

.component('videoPlayer', {
  bindings: {
    video: '<'
  },
  templateUrl: 'src/templates/videoPlayer.html',
});

In the above example, the ‘<’ denotes that a one-way binding is occurring. This means that when the property changes in the parent, the child’s view will be re-rendered. This is different from a ‘=’ which denotes a two-way data-binding. A two-way data-binding has the effect of updating the values in both the parent and child whenever the said property is altered, and re-rendering as necessary. Two-way binding is generally frowned upon, as it has some serious performance costs associated with it, and should only be used when absolutely necessary.

Once the data has been passed through to the child component, the child can choose to render the information. The syntax for displaying the information is as follows.

<h3>{{$ctrl.video.snippet.title}}</h3>
<div>{{$ctrl.video.snippet.description}}</div>

Notice the {{ }} and the use of the $ctrl. The mustaches (curly braces ;-) denote string interpolation. The expression inside will be evaluated, and the evaluated string will show up in the html. The $ctrl is not optional; it is referencing the scope of the controller that exists on the component. I realize that I haven’t discussed the controller, but I think it is fair to think about it as the place where the variables and methods associated with a given component live.

In Angular, similar to Backbone and React, data flows from child to parent, via events. A bound function is passed from parent to child during instantiation, and attached to an event of any of the parent’s descendants. When the said event is fired, the function that was passed down, runs. Because the this is bound to the parent’s scope, changes can be made in the parent which might then be reflected in its children.

I hope that this discussion has helped to illuminate the paths in your mind that are associated with data flowing through these frameworks. If you are still reading this…I appreciate you spending your time to do so :-)