What The Internet Never Told You About Building A Login System

The Internet is replete with "how to build a login form" and "which password hashing algorithm to choose" articles but strangely silent on how to build a professional (well, maybe, semi-professional) login system.

Any login system has two sides: the client side and the server side.  The client side is easier so we'll start there.

To login, a user should provide a username or email address and a password.  For your system, well, which should it be: a username or an email address (or maybe a choice)?

Email addresses are more consistent and, chances are, you'll want to verify accounts by requiring a verified email address.  On the other hand, usernames are shorter and have a little more flair though a user is far more likely to forget their username than their email address.

Many clients send the password in the clear to the server.  But, when I researched the issue, I opted for a more sophisticated approach.  It is:

sha256('yoursite.com'+'user@emailaddress.com'+'password')

sha256('yoursite.com'+'user'+'password')

SHA-256 is a rather insecure hashing algorithm.  The point here is not to secure the password so much as invalidate an attacker's database of SHA-256 hashes and force him to generate a new one.  An attacker might already have a huge database of SHA-256 password hashes.  But, by adding the username or email address to the password string and then doing the SHA-256 hash, an attacker will have to have a much, much larger database of SHA-256 username-password hashes.  Adding an arbitrary string, such as the name of your web site, to the username-password will force an attacker to generate a new database of SHA-256 hashes customized for your login.

This hash is sent from the client to the server as the user's "password".  If an attacker steals your database and recovers the client-hashed password, they will be able to login to your site but the password won't work at any other site.  The arbitrary string will ensure that the hashes are different.  The attacker will be forced to recover the plain text password.

Having client-side SHA-256 hashes, even with usernames and arbitrary strings, isn't enough.  You are protecting other sites (a little bit) from being vulnerable to broken into if your password database is stolen.  But you are providing no protection for yourself (or your admin accounts) and SHA-256 is far too weak to be effective all on its own.  Enter server side hashing.

Like I said earlier, the server side of a login system is more complicated than the client side of the login system.  What server side hashing algorithm should you use?

MD5, SHA-256, PBKDF2, bcrypt, scrypt or Argon2?

Well, no.  You shouldn't choose a hashing algorithm at all.

Hashing algorithms and hardware change over time and, since you are building professional system, meant to adapt over the years, your server should support multiple algorithms.  Your login system, at least the server side, has three requirements:

1. Hashing algorithms must be assignable per user, not one for the entire system
2. Each user's hashing algorithm has to be changeable into any other algorithm
3. Adding a new hashing algorithm should only require one function to be changed

No doubt, your database has a "password" column that contains the user's hashed password.  Having a password in a single string is extraordinarily convenient.  Rather than storing hashing algorithms in a separate column, it is best to store the hashing algorithm in the same column as the hashed password, as part of the same string.  Ideally, you'd use a standard password string format.

As far as I'm aware, there is only one such format in wide use: that's the Linux /etc/shadow password format (a.k.a. the shadow password format).  It looks like this:

$algorithm$arguments$saltthenpasswordhash

The algorithm field indicates the algorithm:

1=MD5

2=Blowfish

5=SHA-256

6=SHA-512

2a,2b,2y=bcrypt

pbkdf2=PBKDF2

scrypt=scrypt

argon2d=Argon2d

argon2i=Argon2i

The arguments field might not exist or might contain algorithm arguments.  bcrypt requires a work factor.  Argon2 has 3 different arguments: iterations, memory and threads.

The saltthenpasswordhash is the salt with the hashed password for this user.  Other articles (by other people) describe the reasons why each password should have its own salt and not a global salt.  Nowadays, it is common for libraries to automatically generate a salt when creating new hashes so there is less reason for me to go over those arguments here.  Since salts are generated along with the hash, it is easier to do it the right way and harder to do it the wrong way, with a global salt.

Storing all this information in a single string in the "password" column of your database using the standard /etc/shadow format will satisfy the first requirement that hashing algorithms be assignable per user.

For new users, I use a global variable to indicate the hashing algorithm that a new user should use so, when a new user is created, their password hash and their hashing algorithm (from the global variable at the time the account was created) is stored together.

When a user logs in, they use the hashing algorithm in their password string from the "password" column of the database to hash the SHA-256 client-side hash.  Then, the hash from the login attempt is compared to the hash from the database, preferably using the special hash comparison function from the encryption library (to blunt timing attacks).  If the hashes are not equal, the login attempt fails.

If the hashes are equal, the login attempt succeeds but you're not quite done yet.  The user's current hashing algorithm is compared to the hashing algorithm in the global variable.  If they are not the same, the client-side SHA-256 hash (which has already be validated to contain the correct password) is hashed using the global variable's hashing algorithm.  The result, in shadow password format, is stored into the "password" column: the user has been upgraded on-the-fly to the latest algorithm.

The global variable provides the ability to "turn up" and "turn down" security by specifying different algorithms.  When the global variable is changed into a stronger (slower) algorithm, new users and any user logging in will be upgraded to the new algorithm seamlessly.  If you make a mistake and deploy an algorithm that bogs down your server, you can "turn down" security merely by changing that algorithm global variable.  Existing users will undergo a one-time delay when they login using the too-slow algorithm and are downgraded to a faster algorithm.

Designing your login system such that a single function provides hashing new passwords, hashing a password with a given salt (for login checks) and comparing two hashes will allow you to deploy new hashing algorithms over the years by changing one function.

Rather than just sending passwords in the clear and hardcoding MD5 (oh, Yahoo!, will you never learn?!), a login system with client-side hashes and upgradable server-side hashing algorithms will provide you a basic framework for the future.

I don't claim these practices to be the best or even adequate.  I'm not a security researcher and don't claim to be one.  But SHA-256 client side hashes, the shadow password format and easy deployment of new server side hashing algorithms are important issues that are worth debating and considering.  And, hopefully, will give you a place to start the conversation.

AngularJS to React/Redux and back again

I've found AngularJS to have many analogues (corresponding pieces) to React/Redux.  Let me show you.

A Redux state almost exactly corresponds to an AngularJS $scope variable.

In a Redux reducer file, you have an initial state that looks like this:

const initialState = {
  inited: false,
  loading: true,
  user: {
    first: '',
    last: '',
    email: ''
  },
  error: ''
}

This initial state almost directly corresponds to an AngularJS $scope initial state.  If it doesn't, you can easily move the AngularJS variables that are outside the $scope variable into the $scope variable to match up exactly.

Not every AngularJS controller has an "inited" variable but many do.  In Redux, an "inited" variable is essential to signal that the Redux state has not been populated by data from the backend yet.  An easy way to do this is to check the "inited" prop in the componentDidMount() method in the React component that requires it (or any React component that requires it) and, if it is false, load up the data and set the "inited" value (well, call an action to call a reducer to do it) to true.  Even if you don't have an "inited" variable in your AngularJS $scope variables, it is easy to add one.  The AngularJS controller function might be converted like this:

componentDidMount() {
  if (!this.props.inited) {
    // do this only once
    this.props.model('inited', true)
    // in AngularJS, this is the controller function
    getUser(this.props)
  }
}

Speaking of Redux reducers and so on (and since I brought it up in the code directly above), it is very convenient and useful to make a "model" action along the lines of an AngularJS ng-model.  The "model" action will take a string indicating the value to change, e.g. props.model('user.first', 'John'), and ultimately create something that looks like this:

<input type="text" value={ props.user.first } 
  onChange={e => props.model('user.first', e.target.value)}/>

Often, I've found it easy to copy the HTML from my AngularJS templates (HTML) into the React render() method and fix them up.  There are a three tricks that you have to remember:

1. Do a global search and replace on "class=" to replace with "className=".  Before you make this change, your React component may render but will not apply the CSS classes.
2. Search for each "style=" (e.g. style="background: blue") and convert each instance (e.g. style={ { background: 'blue' } }).  (Don't forget to make it a JavaScript object by having the double curly braces.) . Really, if your AngularJS still contains "style" attributes, it's just better to convert them into CSS classes and "class" attributes rather than go through the hassle of converting them to React.  Before you make this change, your React component will often render a blank screen; this is a big hint that you have unconverted "style" attributes.
3. Change each AngularJS template to have a single root element, not multiple root elements.  Multiple root elements are allowed in AngularJS but there is no reason to use them and it is easy enough to just wrap it all in a div tag so it is easy to convert to React.  React components (specifically, JSX and the render() method) require a single root element.

react-router-redux is a pretty convenient analogue to AngularJS router modules (either the built-in or ui-router).

Factories and services can be stripped of their AngularJS specifics and placed in your React application's modules folder.  Usually, I place them in a subfolder of modules.  Often, factories and services use the AngularJS $http service; you can convert these calls to use fetch (from the isomorphic-fetch npm module) or Axios (or superagent or request or whatever).

AngularJS filters are essentially just functions; I just strip out the code and drop them into the modules folder itself.  A call to a filter is easy to convert.  In AngularJS, a filter looks like this:

{{ 'mytitle' | translate }}

In React, it becomes:

{ translate('mytitle') }

In AngularJS, we have the "ng-if" and "ng-repeat" attributes which are used a lot in almost every AngularJS application to do control flow.

The AngularJS "ng-if" attribute is used like this:

<div ng-if="showing">
  My title
</div>

In React, it becomes a conditional, like this:

{ props.showing? (
<div>
  My title
</div>
) : '' }

An AngularJS "ng-repeat" attribute is a little more complicated.  From this:

<table>
<thead>
<tr>
<th ng-repeat="column in columns">
  {{ column }}
</th>
</tr>
</thead>
</table>

To this in React:

<table>
<thead>
<tr>
{ props.columns.length? props.columns
  .map((column, index) => (
<th key={ index }>
  { column }
</th>)
  ).reduce((p, c) => [p, '', c]) : ''}
</tr>
</thead>
</table>

Admittedly, this post is a little slapdash and not really enough to convert an entire AngularJS to React/Redux. But I think that you will agree that there are a lot of concepts that easily port from AngularJS to Redux with a little tweaks, here and there.

What's wrong with Ember.js?

Once you have React and Angular in your toolkit, should you concern yourself with Ember.js?

Executive summary: No.

React comes from Facebook; Angular comes from Google.  If you live in the Silicon Valley like I do, Facebook and Google cast a long shadow.  Many companies, large and small, "cargo cult" Facebook and Google; that is, they adopt technology blindly based on what Facebook and Google do, hoping that that imitating success will yield real success.  Many startups adopt "hot" technologies to appeal to venture capitalists ("hey, we're just like Google!") and to garner attention from developers and the press.

Right now (9/20/2017), React is in the cat bird seat.  React developers command the extravagant salaries and most of the pursuit by recruiters.  In contrast, AngularJS (1.x) is a workhorse: valued by many companies but also some willing to leave positions open rather than paying a premium and others paying a limited premium in developer salaries.  Angular (2/4) is rarely seen: companies who adopted Angular (2/4) seem oddly out of touch, like they didn't get the memo, and seem to have little interest in paying salary premiums.

Where is Ember.js?

Ember.js is at LinkedIn, a respectable name to be sure, but hardly the influencer that Google and Facebook are.  Ember.js is also seen at the occasional AI or hardware startup.  No salary premium for Ember.js developers: those companies think that being an Ember.js developer shows that you are a free-thinking hippie that cares more about concepts than money.

Ember.js gets an honorable mention by those job postings that read, "must know at least one of React, AngularJS, Ember.js or other JavaScript framework".  Hey, that's something: Vue.js doesn't get this kind of respect.  But we all know that, when a job posting reads like that, it really means, "Hell, we're don't know jack about any of these JavaScript frameworks so, if you've done any of it, it's all the same to us."

Recently, I did a multi-day investigation and technical review on Ember.js and, while Ember.js seems technically competitive with React and Angular in some respects, there was no indication that they were ever going to emerge from their rather distant third place, open source, hippie-dippie "alternative" framework status.  Having recently reviewed Backbone.js, I see a lot of intellectual inheritance from Backbone.js in Ember.js and, believe me, that's not a compliment.  That smell of Backbone.js in Ember.js makes it feel ... old.

I have to give the Ember.js team respect for hanging it there all this time.  But, sorry, I will not be staking my future on Ember.js, either now or anytime soon.  Nor will I be considering any Ember.js positions.  And I'd advise others not to, either.

But, hey, Ember.js, if, someday, you break through, give me a call.  I'm in the book.

What was Backbone.js and why did it die?

As AngularJS (Angular 1.x), Angular (Angular 4) and React rose, Backbone.js declined. What was Backbone.js? Why did it decline?

Let's just dive in and look at some Backbone.js design and features.

Backbone.View.extend(), Backbone.Model.extend(), Backbone.Router.extend(), etc.

Backbone.js is based on a Java-style class structure with classes, objects and inheritance. It makes a conscious choice to embrace this approach, instead of JavaScript prototypical inheritance. The extend() method creates a subclass of the "class" which it is invoked upon. While other frameworks adopt this approach as well (usually by upgrading to TypeScript or ES6) for their view classes, Backbone.js is rather dogmatic about it and, as we will soon see, it requires a lot more classes and a lot more objects whereas other frameworks were more limited and less, well, so darned adamant about creating all those things.

_.bindAll() call in a Backbone.View constructor

When a new Backbone.View class is created, its constructor often contains multiple calls to _.bind() or a single call to _.bindAll(). I have written about the function of _.bind() before so I won't repeat that here. OK, OK, I'll repeat it a little. _.bind() converts a method into a standalone function call. In Backbone.js, this is often required because event handlers only work with functions, not with methods. Backbone.js uses events extensively so the _.bind() calls are necessary. Calls to _.bind() and _.bindAll() confuse many people and cause odd errors when not used so Backbone.js got a reputation as being confusing.

React requires a bind() call in some but not all circumstances but it is not designed around events in the same way that Backbone.js is. The use of _.bind() and _.bindAll() isn't a deal killer but certainly doesn't help Backbone.js' reputation.

render() method of a Backbone.View

Every Backbone.View class has a render() method, similar to React. The render() method in Backbone.js is usually a string concatenator, something like an old-fashioned version of React, before JSX was widely adopted. In Backbone.js, it is additionally encouraged to call the render() methods of child Backbone.View objects, take the returned strings and insert them in the correct position in the parent Backbone.View string. All this string concatenation feels very awkward and old-fashioned.

events property of a Backbone.View

The events property looks something like this:

events: {

 'click button#add': 'addItem'

}

It is a map with magic strings that makes nobody happy.  The “click” refers to the onclick event; the “on” prefix is dropped.  "button#add” is a jQuery selector.  “addItem” is the method to invoke on the current object.

Backbone.js is the one framework that separated event handlers from the HTML. This approach provides no benefit to the developer and is somewhat inconvenient and buggy.

Backbone.Model

Backbone.js separates views and data; Backbone.Model was the base class for data. Instead of working with plain old JSON objects like many other frameworks, Backbone.js expects JSON objects (from the server) to be deserialized into full blown Backbone.Model objects.

Backbone.js data objects support events and event handlers (as do view objects). The idea seems to be that, once JSON data is converted into full-blown Backbone.js objects, the view objects and data objects are stitched together with the right events.

The Backbone.js data objects is an alternative to AngularJS' $scope variable or React's props variable (argument). Backbone.js event mechanisms require the developer to orchestrate how data changes propagate to the view. In contrast, AngularJS' digest cycle and React's virtual DOM and diffing algorithms take care of this orchestration for the developer.

Backbone.Collection

Backbone.Collection is the Backbone.Model version of an array. Instead of using ordinary JavaScript arrays, Backbone.js requires the developer to deserialize arrays into collections so that events and event handlers can be used to monitor data changes.

Backbone.sync()

Backbone.sync is an Backbone.js specific implementation of something like GraphQL but is incompatible with GraphQL. Its API is reminiscent of server side persistence libraries like Hibernate with methods like fetch() and save(). Backbone.sync uses HTTP operations like GET, POST, PUT and DELETE to perform server CRUD operations using pre-determined URLs. A server needs to confirm to Backbone.sync's conventions in order to work with Backbone.sync.

GraphQL has attained some level of popularity due to its support from Facebook; Backbone.sync never has.

Backbone.Router

Backbone.Router supports partial views. It seems OK.

Underscore.js templates

Backbone.js supports HTML templates via Underscore.js.

An Underscore.js HTML template looks like:

<h1><%= title %></h1>
<% if (title === 'first') { %>
This is the first title <% } %>

Backbone.js also supports other libraries like Mustache but these must be downloaded and integrated separately. This presents a problem: you cannot re-use templates that were written in one library with a different library so templates were mostly not reusable.

Backbone.js does not provide any support for dynamic data in the template. In AngularJS, Angular or React, if the data changes, the template (or JSX) is automatically re-rendered whereas, with Backbone.js templates, the developer must detect the change, invoke the template directly and re-render the updated template in the right place.

Also, Backbone.js does not provide any support for (reusable) components. In AngularJS, directives allow the developer to insert a component with HTML and behavior. Similarly, JSX in React allows a developer to insert a component with HTML and behavior.

Backbone's weakness in templates and lack of component functionality is one of its biggest weakness and an important reason why it is not popular.

Overall

Backbone.js is a very awkward framework, requiring much of the developer trying to use it.

It is also a very ineffective framework, lacking popular features while providing other features that were not that useful.

Backbone.js is very imperative, manually connecting everything with events and event listeners, instead of declarative, changing JSX (in React) or changing HTML templates (in AngularJS) to invoke the event handler.

The Eh (Canadian) programming language

I know a guy who is Canadian and, just for fun, I wrote a programming language for him.

The language is the Eh programming language.   The syntax is similar to JavaScript, except that instead of a line ending with a semicolon, it ends with a comma, a space, the word "eh" and a question mark (?).  For example:

var src = 'script', eh?
var s = '', eh?
s += 'Hello', eh?
s += ' ', eh?
s += 'World', eh?
s += ' from ' + src, eh?
console.log(s), eh?

This will print the following to the JavaScript console:

Hello World from script

An Eh script can be included inline using the "text/eh" type:

Or loaded from an external script file:

Here's the source code for the Eh compiler (in JavaScript) named eh.js:

// eh compiler
window.onload = function() {
  // execute eh code
  function executeEh(src) {
    eval(src.replace(/,\seh\?/g, ';'));
  }
  // load eh scripts
  var scripts = document.getElementsByTagName('script');
  for (var s=0; s < scripts.length; s++) {
    if (scripts[s].type === 'text/eh') {
      if (scripts[s].src) {
        // execute external eh scripts
        var extScript = new XMLHttpRequest();
        extScript.open("GET", scripts[s].src, true);
        extScript.send();
        extScript.onreadystatechange = function() {
          if ((extScript.readyState== 4)
              && (extScript.status == 200)) {
            executeEh(extScript.responseText);
          }
        };
      } else {
        // execute inline eh scripts
        executeEh(scripts[s].innerHTML);
      }
    }
  }
}

Eh supports all major JavaScript libraries and APIs.

Here's a Plunker to demonstrate: http://plnkr.co/edit/ASrEWq3uoZgi6TwolGLd

If you make an Eh script, comment below and let me know!

Put your Git branch in your Mac or Linux prompt

There is a lot of examples out there but here's a basic way to show your Git branch in your profile.

First, edit your .bash_profile.

$ vi .bash_profile

Press "i" to put vi in "insert mode".  Then, add the following to your .bash_profile:

ps1_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
export PS1="\w\$(ps1_git_branch)\$ "

After making this change and starting a new Terminal, the prompt will show the following in non-Git folders:

~/Documents $

In Git folders, the prompt will show the following (if you are on the "master" branch):

~/Documents/git/code (master)$

Very convenient.

JavaScript private data using createPrivateThis()

In JavaScript, all object properties are public.

But, coming from Java and a long line of languages before it, I've seen how private properties can enforce better designs.  Is there a convenient way to enforce private properties in JavaScript?

Up to now, there were four proposed solutions:

1. Imaginary privacy: Put an underscore (_) in front of all private properties to indicate that they are private.
2. Everything in the constructor: Use closure and attach all your functions to the this object; don't use Object.prototype.func = anymore.
3. Weakmaps: http://www.nczonline.net/blog/2014/01/21/private-instance-members-with-weakmaps-in-javascript/
4. Everything public: Why care?

I am now proposing a fifth solution: createPrivateThis().

My objectives were simple:

1. Provide Java-style public and private data in JavaScript.
2. Prevent read access to the private data from outside the object.
3. Allow functions to be created on the prototype object as normal.
4. Allow functions on the prototype object to access public and private data using the this pointer.

Here's the code that I came up with:

/**
 * Wrap the prototype functions and put the wrappers on the
 * object itself.  A wrapper merges the object and private
 * properties before the call, makes the call then unmerges
 * the object and private properties.
 *
 * Normally, you create your private data in the constructor
 * function and give distinct names to public and private
 * data.  Then, during function calls, you use the this
 * pointer for BOTH public and private data.  In ambiguous
 * situations, the private data is operated on with the
 * exception that adding/deleting data defaults to the
 * (public) object.
 *
 * It is possible to create private functions and variables
 * with the same name using the transitory getPrivateThis()
 * method but this is NOT recommended and is an advanced use.
 *
 * @param {Object} obj The object that needs private data.
 * @return {Object} The private data pointer (this_p).
 */
function createPrivateThis(obj) {
  // use Underscore.js or our own mini version
  var __ = (typeof _ === 'undefined')? {
    isFunction: function(f) {
        return f 
           & {}.toString.call(f) == '[object Function]';
    },
    has: function(o, k) {
      return o.hasOwnProperty(k);
    },
    keys: function(o) {
      return Object.keys(o);
    },
    clone: function(o) {
      var k, o2 = {};
      for (k in o) {
        if (o.hasOwnProperty(k)) {
          o2[k] = o[k];
        }
      }
      return o2;
    },
    each: function(oa, f) {
      var i, k;
      if (oa.constructor === Array) {
        for (i=0; i < oa.length; ++i) {
          f(oa[i]);
        }
      } else {
        for (k in oa) {
          if (oa.hasOwnProperty(k)) {
            f(oa[k], k);
          }
        }
      }
    },
    extend: function() {
      var a, arg, d = arguments[0];
      for (a=1; a < arguments.length; ++a) {
        arg = arguments[a];
        for (var k in arg) {
          if (arg.hasOwnProperty(k)) {
            d[k] = arg[k];
          }
        }
      }
      return d;
    },
    union: function() {
      var a = Array.prototype.concat.apply({}, arguments)
      var b = [], a1, i;
      while (a.length > 0) {
        a1 = a.pop();
        for (i=0; (i < b.length) && (a1 !== b[i]); ++i) ;
        if (i === b.length) {
          b.push(a1);
        }
      }
      return b;
    }
  }: _;
  var priv = {};
  var getPriv = function() {
    return priv;
  };
  // iterate over each function in the object prototype
  __.each(obj.constructor.prototype, function(value, key) {
    if (__.isFunction(value) && !__.has(obj, key)) {
      // intercept the function on the object itself
      obj[key] = function() {
        var pre = __.clone(priv);
        // combine the object and its private properties
        var full = __.extend({}, obj, priv);
        // add the getPrivateThis() access function
        full.getPrivateThis = getPriv;
        // invoke original function with combined object
        var r = value.apply(full, arguments);
        // remove the getPrivateThis() access function
        delete full.getPrivateThis;
        var objKeysToUpdate = {}, objKeysToDelete = {};
        var privKeysToUpdate = {}, privKeysToDelete = {};
        var allKeys = __.union(__.keys(pre), __.keys(priv),
          __.keys(obj), __.keys(full));
        // decide what to do with every key that we ever saw
        __.each(allKeys, function(key) {
          if (__.has(pre, key) !== __.has(priv, key)) {
            // private property was added or deleted
            // using getPrivateThis()
            if (__.has(full, key)) {
              // add/modify object property with the same name
              objKeysToUpdate[key] = full[key];
            } else if (!__.has(full, key) && __.has(obj, key)) {
              // delete object property with the same name
              objKeysToDelete[key] = 'delete';
            }
          } else if (__.has(full, key) && __.has(priv, key)) {
            // modify private property
            privKeysToUpdate[key] = full[key];
          } else if (!__.has(full, key) && __.has(priv, key)) {
            // delete private property
            privKeysToDelete[key] = 'delete';
          } else if (__.has(full, key) && !__.has(priv, key)) {
            // add/modify object property
            objKeysToUpdate[key] = full[key];
          } else if (!__.has(full, key) && __.has(obj, key)) {
            // delete object property
            objKeysToDelete[key] = 'delete';
          }
        });
        // do what we decided to do with the keys
        __.each(objKeysToUpdate, function(value, key) {
          obj[key] = value;
        });
        __.each(objKeysToDelete, function(value, key) {
          delete obj[key];
        });
        __.each(privKeysToUpdate, function(value, key) {
          priv[key] = value;
        });
        __.each(privKeysToDelete, function(value, key) {
          delete priv[key];
        });
        return r;
      };
    }
  });
  return priv;
}

The core idea is to create wrapper functions on the this object which automatically intercept the calls to the functions defined on the prototype object.  The automatically generated interception functions combine the this and the private data, make a call to the prototype function, then uncombine the data back into the this and the private data.

In practice, createPrivateThis() is used like this:

function Animal() {
  var this_p = createPrivateThis(this);
  this_p.nickname = "NoName";
  this.type = 'animal';
}

Animal.prototype.getPrivateNickname = function() {
  // this.nickname is private but we can access it inside here
  return this.nickname;
};

Animal.prototype.setPrivateNickname = function(nick) {
  // this.nickname is private but we can access it inside here
  this.nickname = nick;
};

Animal.prototype.getPublicType = function() {
  return this.type;
};

Animal.prototype.setPublicType = function(type) {
  this.type = type;
};

The private property, nickname, is not accessible outside the object.  It is accessed via the this pointer but it does not actually reside on the object.  The private property actually exists as a local variable in the createPrivateThis() function that is accessed via closure (only available inside the function).

Make Mac Minecraft work on Oracle Java

My son likes to play Minecraft.  I like to use Oracle Java 8 instead of the decrepit Apple Java (6) that Apple insists on.  Can't Minecraft use Oracle Java 8?

It can but it took me 6 months to figure out how to do it right.  You can modify the Minecraft Mac application so it will work on whatever is installed, either Oracle Java 8 or Apple Java 6.  You can even do it without starting a Terminal (but I'll tell you how to do it in Terminal, too).

On MacOS X Yosemite:

1.  Make a copy of your Minecraft application for backup.

2.  Start Safari and go to this page:

https://raw.githubusercontent.com/tofi86/universalJavaApplicationStub/master/src/universalJavaApplicationStub

This is a bash script from https://github.com/tofi86/universalJavaApplicationStub GitHub project.

3.  Choose the "File" menu, then select the "Save As..." menu item.  Select the "Page Source" item in the "Format" dropdown list.  Now, save it using the default name (i.e. universalJavaApplicationStub) on your Desktop.

4.  Go to the Applications folder, right click on the Minecraft application and select "Show Package Contents".  A Finder window will open.  Double-click on the Contents folder to open it.  Start Finder and choose the "Go" menu, then select the "Go to Folder..." menu item.  Type "/Applications/Minecraft.app/Contents" and press the "Go" button.  A Finder window will open.

5.  Double-click on the MacOS folder.  If it is a Java application, you will probably see a single file named JavaApplicationStub in the MacOS folder.

6.  Drag the universalJavaApplicationStub into the MacOS folder.  Now, there are two files in there.

7.  Right click on universalJavaApplicationStub and select the "Get Info" menu item.  Open the "Name & Extensions" item.

8.  If the "Hide extension" checkbox is enabled and checked, uncheck it.

9.  In the text box, delete the extension (probably ".txt") and close the "Get Info" box.

10.  If you get "Are you sure you want to remove the extension ".txt"?" prompt, press the "Remove" button.  (The icon for universalJavaApplicationStub will change to a green CRT terminal icon with the text, "exec", on it.)  Leave the "MacOS" Finder window open.

11.  Oh, I lied.  You do have to use Terminal.  Open the Applications folder, open the Utilities and run Terminal application.

12.  Paste the following into Terminal and press the "Return" key to execute it:

chmod ugo+x /Applications/Minecraft.app/Contents/MacOS/universalJavaApplicationStub

This command adds eXecute permissions to the file for User, Group and Other.

If you don't get an error, it probably worked.  If you get an error, you can give up on this process and, don't worry, the Minecraft application is undamaged.  In either case, close the Terminal.

13.  Press the back button on the original Finder window to return to the Contents folder.

14.  Right click on the Info.plist file.  Select the "Open With" menu, then choose the "Other..." menu item.  Scroll down and select the "TextEdit" application.  The TextEdit application should start.

15.  Edit and save the file:

A.  Insert "universal" in front of "JavaApplicationStub" so it reads <string>universal JavaApplicationStub</string>.

B.  Insert an "X" at <key>Java</key> to make <key>JavaX</key>.

16.  Go to the Applications folder and run Minecraft.  It should work.  You're done.

If you want to perform this same process entirely in Terminal, start a Terminal and do this:

$ cp -r /Applications/Minecraft.app /Applications/Minecraft\ copy.app
$ cd /Applications/Minecraft.app/Contents
$ curl "https://raw.githubusercontent.com/tofi86/universalJavaApplicationStub/master/src/universalJavaApplicationStub" -o "MacOS/universalJavaApplicationStub"
$ chmod ugo+x MacOS/universalJavaApplicationStub
$ vi Info.plist
Press i to insert text
- <string>JavaApplicationStub</string>
+ <string>universalJavaApplicationStub</string>
- <key>Java</key>
+ <key>JavaX</key>
Press Esc, then type ZZ which will save

This technique should work for any Mac Java application, as long as you go to the correct .app folder.

Don't forget that you have to a backslash (\) before any spaces in the name when using Terminal so Minecraft copy.app becomes Minecraft\ copy.app.

If you need to troubleshoot, try running universalJavaApplicationStub from the Terminal and see if it launches Minecraft or gives you error messages.  If that works, try running the open command so open /Applications/Minecraft.app and see if that launches Minecraft or gives you error messages.  The error messages can be somewhat cryptic but, with Google, perhaps you can figure out what the issue is.

References:
http://apple.stackexchange.com/questions/88110/make-minecraft-or-java-preferences-app-run-on-java-7
http://gaming.stackexchange.com/questions/178178/making-minecraft-run-with-java-8-on-os-x-10-10
http://www.cgwerks.com/make-minecraft-work-mac-osx-yosemite-latest-java-8/
https://gist.github.com/pudquick/7518753
http://www.minecraftforum.net/forums/support/unmodified-minecraft-client/1858141-minecraft-x64-for-mac-with-java-7
https://bugs.mojang.com/browse/MCL-1049
http://mosx.tumblr.com/post/64402950499/os-x-tip-execute-java-apps-like-minecraft-or
http://stackoverflow.com/questions/14806709/application-is-using-java-6-from-apple-instead-of-java-7-from-oracle-on-mac-os-x
http://superuser.com/questions/490425/how-do-i-switch-between-java-7-and-java-6-on-os-x-10-8-2

What does _.bind() do?

The name, "bind", conjures fear.  It's scary.  Binding sounds mysterious and strange.

Underscore.js has the _.bind() function.  What does it do?

Let's say that you using the JavaScript setTimeout() function to set the focus on a jQuery DOM element.

var el = $('#myinput');
setTimeout(function() { el.focus(); }, 50);

The setTimeout() function takes a standalone function as its first argument.

Now, consider this code:

var el = $('#myinput');
setTimeout(el.focus, 50);

This code doesn't work.  Why?  Well, the focus() call is an object method, not a standalone function.  The setTimeout() function expects a standalone function, not an object method.

A standalone function and an object method aren't the same thing.  If you pass an object method as an argument that expects a standalone function, it's not the same thing, it's wrong and it doesn't work.

It's as if you passed a string as an argument to a function that expects a number.  You passed the wrong kind of thing, even if the string contains a number.  If you want it to work, you have to convert the string to the proper type before calling the function.

So, how can you convert an object method call into a standalone function?

One way is to create a standalone function that calls the object method as you did in the original code.

A second way is to call the _.bind() function.

The _.bind() function says, "Create a standalone function that invokes the method in the first argument, using the second argument as the this object."

So, instead of creating your own standalone function, the _.bind() function will create one for you.

var el = $('#myinput');
setTimeout(_.bind(el.focus, el), 50);

The _.bind(el.focus, el) code creates a standalone function that calls the el.focus() method.  You can think of it as converting a method (call) into a standalone function.

The _.bind() implementation is more complex but you can understand it by imagining that it is implemented like this:

function bind(method, self) {
  return function() {
    self.method(); // this doesn't work; it's just for clarity
  };
}

That's what _bind.() does.  It takes a method call and "converts" it into a standalone function.

Once you grasp this, you will discover that _.bind() has additional uses, such as converting a standalone function call with multiple arguments into a standalone function with no arguments.

With this explanation, I hope that _.bind() and binding is no longer mysterious and strange.  And not scary.

AngularJS dependency resolution and child controller creation

Suppose that you have an AngularJS template (HTML with AngularJS tags, same thing) and an AngularJS controller and you want to execute them together:

var elem = angular.element(angularTemplateHtml);
var compileFunc = $compile(elem);
$controller(controllerName, locals);
elem = compileFunc($scope);

This is how ngRoute bootstraps a route.

Suppose that the controller has dependencies.  How are they resolved?

Deep inside angular.js, there is an invoke() function that looks like this:

function invoke(fn, self, locals, serviceName) {

  if (typeof locals === 'string') {

    serviceName = locals;

    locals = null;

  }

  var args = [],

    $inject = createInjector.$$annotate(fn, strictDi, serviceName),

    length, i,

    key;

  for (i = 0, length = $inject.length; i < length; i++) {

    key = $inject[i];

    if (typeof key !== 'string') {

      throw $injectorMinErr('itkn',

        'Incorrect injection token! Expected service name as string, got {0}', key);

    }

    args.push(

      locals && locals.hasOwnProperty(key)

      ? locals[key]

      : getService(key, serviceName)

    );

  }

  if (isArray(fn)) {

    fn = fn[length];

  }

  // http://jsperf.com/angularjs-invoke-apply-vs-switch

  // #5388

  return fn.apply(self, args);

}

AngularJS looks for dependencies in the locals object and getService().  If it doesn't find the dependency in either place, the dependency fails and you get an error.

It's interesting that you can bolt dependencies onto the locals object.  The locals object is passed directly into the $controller() function so, if you are calling $controller() function directly, you can provide dependencies to the controller, even if those dependencies aren't AngularJS services.

The $controller() function itself looks like this:

/**

 * @ngdoc service

 * @name $controller

 * @requires $injector

 *

 * @param {Function|string} constructor If called with a function

 * then it's considered to be the controller constructor function.

 * Otherwise it's considered to be a string which is used to

 * retrieve the controller constructor using the following steps:

 *

 *  * check if a controller with given name is registered via 

 *    `$controllerProvider`

 *  * check if evaluating the string on the current scope returns

 *    a constructor

 *  * if $controllerProvider#allowGlobals, check

 *    `window[constructor]` on the global `window` object (not

 *    recommended)

 *

 * The string can use the `controller as property` syntax, where

 * the controller instance is published as the specified property

 * on the `scope`; the `scope` must be injected into `locals` param

 * for this to work correctly.

 *

 * @param {Object} locals Injection locals for Controller.

 * @return {Object} Instance of given controller.

 *

 * @description

 * `$controller` service is responsible for instantiating

 * controllers.

 *

 * It's just a simple call to {@link auto.$injector $injector}, but

 * extracted into a service, so that one can override this service

 * with [BC version](https://gist.github.com/1649788).

 */

return function(expression, locals, later, ident) {

  // PRIVATE API:

  //   param `later` --- indicates that the controller's constructor

  //     is invoked at a later time. If true, $controller will

  //     allocate the object with the correct prototype chain, but

  //     will not invoke the controller until a returned callback is

  //     invoked.

  //   param `ident` --- An optional label which overrides the label

  //     parsed from the controller expression, if any.

  var instance, match, constructor, identifier;

  later = later === true;

  if (ident && isString(ident)) {

    identifier = ident;

  }

  if (isString(expression)) {

    match = expression.match(CNTRL_REG);

    if (!match) {

      throw $controllerMinErr('ctrlfmt',

        "Badly formed controller string '{0}'. " +

        "Must match `__name__ as __id__` or `__name__`.",

        expression);

    }

    constructor = match[1],

    identifier = identifier || match[3];

    expression = controllers.hasOwnProperty(constructor)

      ? controllers[constructor]

      : getter(locals.$scope, constructor, true) ||

        (globals ? getter($window, constructor, true) : undefined);

        assertArgFn(expression, constructor, true);

  }

  if (later) {

    // Instantiate controller later:

    // This machinery is used to create an instance of the object

    // before calling the controller's constructor itself.

    //

    // This allows properties to be added to the controller before

    // the constructor isinvoked. Primarily, this is used for

    // isolate scope bindings in $compile.

    //

    // This feature is not intended for use by applications, and is

    // thus not documented publicly.

    // Object creation: http://jsperf.com/create-constructor/2

    var controllerPrototype = (isArray(expression) ?

      expression[expression.length - 1] : expression).prototype;

    instance = Object.create(controllerPrototype || null);

    if (identifier) {

      addIdentifier(locals, identifier, instance, constructor

        || expression.name);

    }

    var instantiate;

    return instantiate = extend(function() {

      var result = $injector.invoke(expression, instance, locals,

        constructor); // resolve dependencies

      if (result !== instance && (isObject(result)

        || isFunction(result))) {

        instance = result;

        if (identifier) {

          // If result changed, re-assign controllerAs value to

          // scope.

          addIdentifier(locals, identifier, instance, constructor

            || expression.name);

        }

      }

      return instance;

    }, {

      instance: instance,

      identifier: identifier

    });

  }

  instance = $injector.instantiate(expression, locals, constructor);

The $controller() function's first argument is expression.   This is either a controller object or its a string with the controller's name.  If it's a string with the controller's name, the $controller() function immediately looks up the controller object and sets expression equal to the object.

Then, the $controller() function chooses whether to create the object instance and return the constructor function to be called later (in green text) or to create the object instance and call the constructor immediately.

In our example, the constructor is called immediately.

But what happens if angularTemplateHtml contains additional controllers that are created by using the ng-controller attribute?

When $compile() function is invoked, it crawls through the angularTemplateHtml DOM tree using functions named nodeLinkFn(), childLinkFn() and compositeLinkFn() to find and instantiate AngularJS constructs, like controllers.

The compileFunc() function is created and returned by the $compile() call.

Inside AngularJS, the compileFunc() function looks like this:

return function publicLinkFn(scope, cloneConnectFn, options) {

  assertArg(scope, 'scope');

  options = options || {};

  var parentBoundTranscludeFn = options.parentBoundTranscludeFn,

    transcludeControllers = options.transcludeControllers,

    futureParentElement = options.futureParentElement;

AngularJS crawls the angularTemplateHtml DOM tree during the $compile() function and, when it finds a ng-controller attribute, it invokes the setupControllers() function.

function setupControllers($element, attrs, transcludeFn,

    controllerDirectives, isolateScope, scope) {

  var elementControllers = createMap();

  for (var controllerKey in controllerDirectives) {

    var directive = controllerDirectives[controllerKey];

    var locals = {

      $scope: directive === newIsolateScopeDirective

        || directive.$$isolateScope ? isolateScope : scope,

      $element: $element,

      $attrs: attrs,

      $transclude: transcludeFn

    };

    var controller = directive.controller;

    if (controller == '@') {

      controller = attrs[directive.name];

    }

    var controllerInstance = $controller(controller, locals, true,

      directive.controllerAs);

Notice the bold purple text where the locals object is created by AngularJS when it finds an ng-controller attribute.  While a child controller can access its parent's $scope for various purposes, a child controller's locals object is hardcoded, unavailable and unlinked to the parent controller's locals object!  So, a parent controller cannot resolve dependencies for a child controller created by AngularJS.  Wouldn't it be nice if a parent controller could use its locals object to provide dependency resolution and control over instantiation of its child controllers?  But, it doesn't.  Maybe next version.

Notice the orange highlighted true argument inside the setupControllers() function.  The true argument allocates the controller instance but does not invoke the constructor immediately.  It returns the constructor to be invoked later.

AngularJS allocates controller instances during the $compile() call (in our example) but waits and invokes constructors later during the compileFunc() call (in our example).

During the compileFunc() call, the child controller constructor functions are invoked in this code:

if (elementControllers) {

  // Initialize bindToController bindings for new/isolate scopes

  var scopeDirective = newIsolateScopeDirective

    || newScopeDirective;

  var bindings;

  var controllerForBindings;

  if (scopeDirective && elementControllers[scopeDirective.name]) {

    bindings = scopeDirective.$$bindings.bindToController;

    controller = elementControllers[scopeDirective.name];

    if (controller && controller.identifier && bindings) {

      controllerForBindings = controller;

      thisLinkFn.$$destroyBindings = 

        initializeDirectiveBindings(scope, attrs,

        controller.instance, bindings, scopeDirective);

    }

  }

  for (i in elementControllers) {

    controller = elementControllers[i];

    var controllerResult = controller();

    if (controllerResult !== controller.instance) {

      // If the controller constructor has a return value,

      // overwrite the instance from setupControllers and update

      //the element data

      controller.instance = controllerResult;

      $element.data('$' + i + 'Controller', controllerResult);

      if (controller === controllerForBindings) {

        // Remove and re-install bindToController bindings

        thisLinkFn.$$destroyBindings();

        thisLinkFn.$$destroyBindings =

          initializeDirectiveBindings(scope, attrs,

            controllerResult, bindings, scopeDirective);

      }

    }

  }

}

Notice the bold red text shows where the child controller construction functions are invoked during the compileFunc() call.

This shows the lifecycle of controller objects, both directly created controllers and controllers created by AngularJS itself.