Caffeine-Powered Life

Getting into Docker

2015-04-22T08:00:00-04:00

What is this Docker thing, anyway?

For the best answer, check out What is Docker? on Docker’s web site. Briefly, Docker is a way to deliver applications. A container holds one or more applications. Docker provides a way to deploy, share, and update those containers. Docker containers are similar to virtual machines, in so far as they host an operating system. However, they rely solely on the host’s RAM, CPU, and networking.

Advantages of Docker vs. traditional deployment

You are not shipping code; you are shipping a binary. This binary is an image of the application. It is published to a Docker registry — either the public registry at Docker Hub or an internal registry in your organization. To get the latest version of a container, simply use docker pull.

Except for the Docker engine, you do not have to install anything on your production machines. You do not have to install web servers, databases, cache engines, scripting runtimes (like NodeJS, Python, or Ruby) or any of your production servers.

Every application runs inside its own Docker container. You can have multiple versions of your application’s toolset without version interference issues.

Authoring a Client-Side Web Application

Here is our application directory structure.

my-app/
  src/
    scripts/
      main.js
    index.html

The application itself lives under /my-app/src. In this app, we only have an index.html and a single JavaScript file. Deployment scripts are under /my-app/deploy.

Here is the my-app/src/index.html file.




    </span>Getting into Docker<span class="nt">
    


    Hello World!
    The current time is  id="timestamp">

Here is our my-app/src/scripts/main.js file.

;(function () {

    function updateTimestamp() {
        var timestamp = (new Date()).toLocaleString();
        $('#timestamp').text(timestamp);
    }

    updateTimestamp();

})();

Deploying our application

First, let’s start with the nginx Docker container. It is available in the public Docker registry. This container is configured to forward requests from port 80 to /usr/share/nginx/html. (Port 443 is ready to go for SSL, as well, but we will not be using that in this demo.) To do this, we are going to add three new files to the my-app/ directory.

my-app/
  build.sh
  Dockerfile
  run.sh

Let’s take a look at the Dockerfile.

FROM nginx:1.7.12
COPY ./src /usr/share/nginx/html

There is nothing too difficult here. We are starting with the nginx:1.7.12 image. To that image, we are going to copy the contents from the src directory to the /usr/share/nginx/html folder.

You might be tempted to move the Dockerfile to a build folder. This will not work. The Dockerfile must be in or above the the src/ directory. This is because Docker sets us a context from the location of the Dockerfile, and it cannot access anything outside of that context.

Our build script will take care of this build process for us.

#!/usr/bin/env bash
sudo docker build -t my_app .

Build, using the Dockerfile located in the current directory. Additionally, tag (-t) this container as my-app. We can now see this Docker image on our server.

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
my_app              latest              04caf9e7a04e        6 minutes ago       93.44 MB
nginx               1.7.12              637d3b2f5fb5        7 days ago          93.44 MB

Finally, let’s create a script to run our application.

#!/usr/bin/env bash
sudo docker run --name my_app_run -d -p 8080:80 my_app

Run the application in the background (-d), using the container named my_app. Forward requests on host port 8080 to container port 80. Also, name the running container to let us easily access it by name later (--name my_app_run).

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                           NAMES
9f729419e7ca        my_app:latest       "nginx -g 'daemon of   4 seconds ago       Up 3 seconds        443/tcp, 0.0.0.0:8080->80/tcp   my_app_run

Conclusion

A copy of this source code is available on Github.

Reliable Database Fixtures with CouchDB

2015-02-23T07:35:18-05:00

My latest project has me working with Apache’s CouchDB. We needed to solve the problem of how to create a working application when we have a dozen developers working around the globe. While CouchDB has no schema to worry about, we do require design documents to produce queries.

These design documents are code, and the map-reduce functions are JavaScript. Like anything that is code, they need to be tracked, versioned, and part of the source. We have made each document it’s own file. Each of these documents is stored in a documents folder.

// _design_all.js
module.exports = {
    _id: '_design/all',
    language: 'javascript',
    views: {
        byType: {
            map: function (doc) {
                emit(doc.type, null);
            }
        }
    }
};

// product_1000.js
module.exports = {
    _id: 'product_1000',
    type: 'Product',
    description: 'This is my super-cool product. You should definitely buy it!',
    timestamp: new Date().toISOString()
}

There are a few catches to this setup. The biggest being that we need deterministic identifiers. We do have documents that relate to each other, and this only works well when we know the _id values of those documents.

To insert these documents, we use the Node library Cradle.

var cradle = require('cradle');
var fs = require('fs');
var path = require('path');

var couchFiles = [];
var db = new cradle.Connection({
    host: 'http://localhost',
    port: 5984,
    cache: false
}).database('my_database');
var folder = './documents';


console.log('Inserting CouchDB documents...');
fs.readdir(folder, function (error, files) {
    if (error) {
        console.error(error);
        return process.exit(1);
    }
    couchFiles = couchFiles.concat(mapFiles(files));
    processNextCouchFile();
});


function getNextFile() {
    var nextFile = couchFiles.shift();
    if (!nextFile) {
        console.log('Done inserting CouchDB documents.');
        return process.exit(0);
    }
    return nextFile;
}


function mapFiles(files) {
    return files.filter(function (file) {
        return path.extname(file).toLowerCase() === '.js';
    }).map(function (file) {
        return path.join(__dirname, folder, file);
    });
}


function processNextCouchFile() {
    var nextFile = getNextFile();
    console.log('    Working with file: ', nextFile);
    var doc = require(nextFile);
    db.save(doc, function (error, result) {
        if (error) {
            console.error(error);
            return process.exit(1);
        }
        console.log('        Saved document:', result.id);
        processNextCouchFile();
    });
}

Before we run our integration tests, we wipe out the database, recreate the database, and run this script. Our tests can run against localhost, with hundreds of predefined documents, testing each of our views in a fraction of a second.

It’s CouchDB. Relax!

JavaScript Getters, Setters, and Aliases with Object Prototypes

2015-01-06T14:30:18-05:00

Happy 2015, everyone!

I’m neck deep in a pile of JavaScript, and I am trying to create aliases. As it turns out, this is relatively easy to accomplish.

Let’s look at a sample class.

var MyClass = (function () {

  function MyClass(initialValue) {
    this.value = +initialValue || 0;
  }

})();

Creating an instance and getting/setting value is quite simple. We can create a new instance of MyClass and simply access the value.

var instance = new MyClass();
instance.value = 3;
console.log('value = ' + instance.value); // value = 3

My problem was that I needed to create an alias. It turns out, this is pretty easy to do an object with Object.defineProperty(). I simply give it an object, the name of the getter/setter, and the appropriate functions.

Object.defineProperty(instance, "alias", {
  get: function () {
    return this.value;
  },
  set: function (x) {
    this.value = x;
  }
});

I can now create change value and read alias.

instance.value = 4;
console.log('value = ' + instance.alias); // value = 4

What if we wanted all instances of MyClass to share this alias? That takes just one small trick: instead of using instance, simply use MyClass.prototype. Applying the new property to the prototype means that all instances of that class will be created with the new getter and setter.

var MyClass = (function () {

  function MyClass(initialValue) {
    this.value = +initialValue || 0;
  }

  Object.defineProperty(MyClass.prototype, "alias", {
    get: getAlias,
    set: setAlias
  });

  return MyClass;

  function getAlias() {
    return this.value;
  }

  function setAlias(x) {
    this.value = x;
  }

})();

Now, every new instance of MyClass will have both the value and alias properties.

var instance = new MyClass(5);
console.log(instance.value); // 5
instance.alias += 2;
console.log(instance.value); // 7
instance.value += 3;
console.log(instance.alias); // 10

Setting Up CouchDB on Ubuntu in Azure

2014-12-04T09:28:42-05:00

Create a new Ubuntu 14.04 LTS virtual machine.
Add an endpoint for port 5984.
SSH to your newly created machine.
Update your new machine.
```
 $ sudo apt-get update
```
Install CouchDB.
```
 $ sudo apt-get install couchdb
```

Ensure that CouchDB is working.

 $ curl -X GET http://localhost:5984
 {"couchdb":"Welcome", "uuid":"80543311a1c6ed1de302adfc970a6d37", "version":"1.5.0", "vendor":{"name":"Ubuntu", "version":"14.04"}}

By default CouchDB gets installed and works only on localhost. We will need to edit CouchDB’s configuration file to allow it to work on public ports.
```
 $ sudo vim /etc/couchdb/default.ini
```
Find the line that looks like bind_address = 127.0.0.1. Change that to bind_address = 0.0.0.0.

Restart CouchDB.

 $ sudo service couchdb restart
 couchdb stop/waiting
 couchdb start/running, process 1627

Happy coding!

Zero Inbox

2014-11-06T16:20:16-05:00

I’m not joking when I say “zero inbox.” Note, this screen shot lasted for about 3 minutes before another email came in.

You have to work at it each and every day.

The rules are simple. Every time an email comes in, make the following decision.

This email is junk. Delete it.
This email is informational. You read it once and are done with it. Delete it. This includes useful things like, “The build server will be taken offline for two hours tonight so upgrades can be installed.” That’s nice to know. Next, please.
This email is informational and relevant. Add some helpful tags to your email. Do not use folders. Folders only work when only one thing applies. But what if something is both a Receipt and belongs to Client X? It needs two tags. Archive it.
Handle the stuff you can handle the moment it comes in. When you’re done with it, reply, tag it, and move it to Archive.
Anything that you can’t handle gets put into the Follow Up folder. The Follow Up folder is your main work queue. When you done with an item, move it to the Archive.

We all know that you have to make this decision with every piece of mail that you receive. You can either choose to (a) make these decisions one time or (b) make these decisions every time you open your Inbox and start sifting through your mail. If you delay this decision process, then you are just creating a project for yourself when it comes time to find that one important thing.

But Jarrett, I still have too much email!

If you’re doing the above and still have too much email, then here are few other things you need to look into.

Email is not an instant chat client. At Fusion Alliance, we use HipChat. You can create groups and have one-on-one chatrooms. It’s wonderful.
Email in not a file sharing service. But tools like Dropbox, BTSync, OneDrive, Cloud Drive, SharePoint, and many others are, in fact, file sharing services. Create a folder to share with your clients, project team, or whatever, and put all common documents there. Also, your network administrators will thank you for getting rid of all those giant attachments.
Use those Unsubscribe links. Find yourself deleting the same junk over and over again? Maybe take steps to slow the junk.
Use mail rules to your advantage. This can be especially helpful with automatically adding those tags that we discussed earlier or deleting stuff that you know is garbage.
Quit it! If you are drowning in email, then you are probably one of the most unproductive, unreliable, unprepared employees at your job. If you say, “I have too much email to deal with,” then someone like me hears, “I spend all my time switching context and jumping from one fire to the next.” Seriously, this warrants a discussion with the appropriate parties. No one can be effective under that kind of stress. Sometimes, you’ve got to stand up for you!

I can do it, and so can you!

Angular Part 5: Testing

2014-10-31T08:00:00-04:00

Today is Halloween in the United States. As such, I think we should talk about something scary.

No, not lions and tigers and bears. Something that drives fear into the hearts of developers: unit testing.

Seriously, this is not that difficult. Part of learning any new programming language or framework includes learning how to test that language or framework. This is 2014. If automated unit and integration testing isn’t a first-level design concern by now, you are doing it wrong. (I’m looking at you Microsoft WebAPI.)

Angular makes writing unit tests incredibly easy. JavaScript is fragile enough as-is, so let’s always test all of our *.js files. Quasi-futuristic languages like TypeScript or AtScript might offer us runtime type checking, but that is still runtime checking. That means to thoroughly test your application, you must run through all possible code routes.

The tools

This is the list of tools we will be using for this project.

The application (app.js)

The application is very easy to define and test.

First we declare it.

app/app.js

angular.module("myApp", []);

Then we make sure we can get it.

spec/appSpec.js

describe("module: myApp", function () {

  it("is defined", function () {
    expect(angular.module("myApp")).toBeDefined();
  });

});

The point service (point.js)

The point service is taken from our previous post. It looked like this.

app/services/point.js

app.factory("point", [
  function () {
    return function (options) {

      options = options || {};

      var self = {
        x: options.x || 0,
        y: options.y || 0
      };

      self.distanceTo = function (other) {
        var absXSq = sqError(self.x, other.x);
        var absYSq = sqError(self.y, other.y);
        return Math.sqrt(absXSq + absYSq);
      };

      self.toString = function () {
        return "Point: { " + self.x + ", " + self.y + " }";
      };

      function sqError(a, b) {
        return Math.pow(a - b, 2);
      }

      return self;
    };
  }
]);

The unit test below defines what our point service should be able to do.

spec/services/pointSpec.js

describe("service: point", function () {

  var point;

  beforeEach(module("myApp"));

  beforeEach(inject(function (_point_) {
    point = _point_;
  }));

  it("can create a new point object representing the origin", function () {
    var pt = point()
    expect(pt.x).toEqual(0);
    expect(pt.y).toEqual(0);
  });

  it("can calculate the distance between two points", function () {
    var origin = point();
    var pt = point({ x: 3, y: 4 });
    expect(pt.distanceTo(origin)).toEqual(5);
  });

  it("returns the expected value for toString()", function () {
    expect(point({ x: 1, y: 2 }).toString()).toEqual("Point: { 1, 2 }");
  });

});

The parts to notice are the two beforeEach() functions. The first one loads the module. The second one sets up the service to be tested. The _point_ is used by the injector to create the point instance.

Yes, it’s a bit magical how the injector works. Basically, any inject() argument that starts with $ is an Angular built-in, and any argument that looks like _something_ is something you’ve written. Beyond the injection magic, the tests are rather straightforward. We can create a new point, calculate the distance between two points, and test its string representation.

The controller (PointCtrl.js)

Our PointCtrl is quite small, especially since most of the work is being handled by the point service. That was why we wrote the service in the first place.

app/controllers/PointCtrl.js

app.controller("PointCtrl", [
  "$scope",
  "point",
  function ($scope, point) {

    $scope.point1 = point();
    $scope.point2 = point();

    $scope.getDistance = function() {
      return $scope.point1.distanceTo($scope.point2);
    };

    return $scope;
  }
]);

The test for the controller is similarly simple, once you figure out the test setup steps.

spec/controllers/PointCtrlSpec.js

describe("controller: PointCtrl", function () {

  var ctrl, distance, point, scope;

  beforeEach(module("myApp"));

  beforeEach(inject(function ($controller) {
    createMockPoint();
    createController($controller);
  }));

  it("assigns point1 and point2", function () {
    expect(scope.point1).toBeDefined();
    expect(scope.point2).toBeDefined();
  });

  it("returns the expected value for getDistance()", function () {
    expect(scope.getDistance()).toEqual(distance);
  });

  function createController($controller) {
    scope = {};
    ctrl = $controller("PointCtrl", {
      "$scope": scope,
      "point": point
    });
  }

  function createMockPoint() {
    distance = Math.random() * 100;
    point = function () {
      return {
        distanceTo: function () {
          return distance;
        }
      };
    };
  }

});

Again, the trick to these tests is understanding the beforeEach() functions. The first one loads the module. The second loads the $controller factory.

You will notice that we create a mock point object and a mock $scope object. I have discussed mocking JavaScript objects before, and I follow the same pattern here. Since there is no type system in JavaScript, we only care that the object we create has the same functions and properties as what we use.

How much of a mock do you need? You need as much of the object surface area as the controller has access. For $scope, an object literal ({}) will do, and there is no reason for anything more complicated than this.

The point object is a little more complicated. First, it needs to be a function, so we can call point(). Second, the controller needs access to the distanceTo() function. We will create a stub for this function and return a random value between 0 and 100.

The final result

Running all of tests in the browser, we should see the following.

The complete series

Angular Part 4: Creating a Service

2014-10-30T10:24:06-04:00

Our last project covered dependency injection in an Angular application. Now, let’s show how a service works.

An Angular service is a way to encapsulate business logic so that it can be consumed by controllers and other services. Like any well-written program, functionality that goes together should be put together in small, reusable, testable components. Speaking of testing, that’s going to be the next post, so stay tuned.

Demonstration of application

The application should work similar to the following example.

Our new service

We will encapsulate the point object into an Angular service. This service will be called “point”, and it will have no dependencies. You will notice that this block of code looks almost identical to the point() function from our previous post.

angular.module("myApp").factory("point", [
  function () {
    return function (options) {
      var self = {
        x: options.x,
        y: options.y
      };
      self.distanceTo = function (other) {
        var absXSq = sqError(self.x, other.x);
        var absYSq = sqError(self.y, other.y);
        return Math.sqrt(absXSq + absYSq);
      };
      self.toString = function () {
        return "{ " + self.x + ", " + self.y + " }";
      };
      function sqError(a, b) {
        return Math.pow(a - b, 2);
      }
      return self;
    };
  }
]);

By giving our service a unique name, we can now inject it into our controllers as needed.

angular.module("myApp").controller("PointCtrl", [
  "$scope",
  "point",
  function ($scope, point) {
    $scope.point1 = point({ x: 0, y: 0 });
    $scope.point2 = point({ x: 0, y: 0 });
    $scope.getDistance = function () {
      return $scope.point1.distanceTo($scope.point2);
    };
    return $scope;
  }
]);

Adding a service makes our controller much simpler than the previous post. Additionally, our point is now a focused, reusable block of code that can be used anywhere within our application.

It is important to note that all Angular services are lazy singletons. Specifically, they are only created when asked for, and only one instance of the function will ever be created. This is great for your application’s memory profile.

The complete series

Angular Part 3: Dependency Injection

2014-10-29T12:00:00-04:00

In my previous post, I showed how a controller is built in Angular. The basic syntax for creating a controller looks like the following.

module.controller("MyCtrl", [
  "$scope",
  function ($scope) {
    return $scope;
  }
]);

This syntax for creating a JavaScript module is incredibly powerful. By letting Angular handle all of the dependencies, and by treating the scope as yet another object to be injected, the developer needn’t ever worry about three of the most difficult concepts in JavaScript: specifically, closures, new, and this.

The Traditional JavaScript Object

For a refresher, here’s the traditional way to create an object in JavaScript.

var Point = (function () {

  function Point(options) {
    this.x = options.x;
    this.y = options.y;
  }

  Point.prototype.distanceTo = function (otherPoint) {
    var absXSq = Math.pow(this.x - otherPoint.x, 2);
    var absYSq = Math.pow(this.y - otherPoint.y, 2);
    return Math.sqrt(absXSq + absYSq);
  };

  return Point;

})();

We create a new point in the following manner.

var origin = new Point({ x: 0, y: 0 });

In the above class, this is always the functional enclosure that defines the class. This means that this acts the same as we would expect it in C# or Java. However, it wouldn’t take much, just a simple callback, to change the result. Imagine a more complex function that needs to be non-blocking.

Point.prototype.distanceTo = function (otherPoint) {
  return setTimeout(function () {
    // Here, any reference to this.x or this.y will cause your
    // program to fail. Inside the setTimeout callback, this
    // refers to the global scope.
  }, 0);
};

Yes, there are ways to get around the above, specifically by learning how bind(this) works, but, in my experience, this is a place where many developers tend to not know what they are doing. Unfortunately, too many JavaScript “developers” are frequently C# or Java developers who have been asked to add functionality to a web site. They then write mediocre, fragile JavaScript.

An Alternate JavaScript Object

Instead, let’s examine an alternate way to writing our Point class. In this example, we are creating an object literal and attaching functions to this new object.

function point(options) {

  self = {
    x: options.x,
    y: options.y
  };

  self.distanceTo = function (otherPoint) {
    var absXSq = Math.pow(self.x - otherPoint.x, 2);
    var absYSq = Math.pow(self.y - otherPoint.y, 2);
    return Math.sqrt(absXSq + absYSq);
  };

  return self;
}

No longer do we have to worry about immediate functions, the (function () {})() syntax, this, or even creating a new object. To create a new point in this manner, we simply do the following.

var origin = point({ x: 0, y: 0 });

Angular Objects

Angular gets around of all of this (Ha! Ha! Puns!) by injecting the scope object. Anything you wish to expose gets attached to the scope object. Also, the developer never needs to create new objects. The Angular framework does all of that work for you.

Let’s create a simple form for displaying the distance between two points.

 ng-app="myApp">

   ng-controller="PointCtrl">
    
      x1
       type="number" ng-model="x1"/>
      y1
       type="number" ng-model="y1"/>
    
    
      x2
       type="number" ng-model="x2"/>
      y2
       type="number" ng-model="y2"/>
    
    
      Distance
       ng-bind="getDistance()">

Our controller will look something like the following.

angular.module("myApp").controller("PointCtrl", [
  "$scope",
  function ($scope) {

    $scope.x1 = 0;
    $scope.x2 = 0;
    $scope.y1 = 0;
    $scope.y2 = 0;

    function squareError(a, b) {
      return Math.pow(a - b, 2);
    }

    $scope.getDistance = function () {
      var absXSq = squareError($scope.x1, $scope.x2);
      var absYSq = squareError($scope.y1, $scope.y2);
      return Math.sqrt(absXSq + absYSq);
    };

    return $scope;
  }
]);

Together, the above HTML and JavaScript should give us something like this.

As mentioned previously, anything that gets attached to $scope is publicly accessible. The squareError() function is not available publicly. There is no binding trick that the developer can use to attach the function to any Angular directive.

Finally, let’s look at the format of the controller definition.

module.controller(String, Array);

The String is the name of the controller. The Array is the names of the dependencies with the last element of the array being the definition of the controller. Dependencies that start with a $ are built-ins for Angular — there are several.

Conclusion

I recently watched Douglas Crockford talk about writing JavaScript without using new or this. At first I was quite taken aback. How the hell am I supposed to write JS without objects? As you can see, we can still create plenty of objects, those objects have attributes, attach functions to those objects, and even have private function encapsulation without ever using new or this.

Learn more about scope in Angular.
Learn more about services in Angular.

The complete series

Angular Part 2: Moving to a Controller

2014-10-28T08:00:00-04:00

In Part 1, we showed how easy it is to add functionality to a website with AngularJS, and compared that to how much work would be necessary to do the same thing using jQuery alone.

We did have a little bit of logic in our views, though, and that’s not ideal. That logic was testing for specific values for our form fields.

// Showing the form field
ng-show="favoriteColor === 'Other'"

// Requiring the form field
ng-require="favoriteColor === 'Other'"

In my opinion, even something as simple as a test for equality is view logic, and we should do what we can to move that out of the view. Ideally, we want something that looks more like this.

// Showing the form field
ng-show="showOtherField()"

// Requiring the form field
ng-require="requireOtherField()"

Moving that logic is not difficult. In Angular, this kind of thing is handled by the controller.

Before we can write a controller, we first need a module. Defining a module takes the signature angular.module(String, Array). The string is the name of the module, and the array is the list of dependencies required by the module. Below, we define a module named myApp, followed by an array of dependencies. In this case, we do not have any dependencies, so we just have an empty array.

if (window.app) {
  throw Error("window.app is already defined.");
}
window.app = angular.module("myApp", []);

Now that we’ve defined our module, let’s define our controller. We get our module from the Angular registry and add a controller to it. Defining a controller takes the signature module.controller(String, Array).

The array is the list of dependencies followed by the definition of the controller. Our controller does have a $scope dependencies. $scope is Angular’s way of not having to deal with JavaScript’s this object. Anything that we want to expose, we add to the $scope object.

angular.module("myApp")
.controller("ColorFormCtrl", [
  "$scope",
  function ($scope) {

    /**
     * Return true if the submit button should be disabled.
     */
    $scope.disableSubmit = function () {
      return $scope.form.$pristine || $scope.form.$invalid;
    };

    /**
     * Return true if the "Other" field is required.
     */
    $scope.requireOtherField = function () {
      return $scope.favoriteColor === "Other";
    };

    /**
     * Return true if the "Other" field should be displayed.
     */
    $scope.showOtherField = function () {
      return $scope.favoriteColor === "Other";
    };

    return $scope;
  }
]);

Let’s take look at updated HTML.

 ng-app="myApp">
 lang="en">
   charset="UTF-8">
  </span>Angular Demo<span class="nt">

 ng-controller="ColorFormCtrl">
 method="post" action="#" name="form">
  
    What is your favorite color?
     name="favoriteColor" ng-model="favoriteColor" required="required">
      
      Red
      Blue
      Other
    
  

   ng-show="showOtherField()">
    Favorite color (other)
     type="text" name="favoriteColorOther" ng-model="favoriteColorOther" ng-required="requireOtherField()"/>
  
  
     type="submit" ng-disabled="disableSubmit()">
      Submit
    
  

We added our module’s name to the ng-app="myApp" directive. We added our controller as part of the ng-controller="ColorFormCtrl" directive. We then moved all of our page logic to a controller.

The complete series

Angular Part 1: Show and Hide

2014-10-24T06:35:08-04:00

This week, I have been diving headfirst into AngularJS. I am amazed at how much one can accomplish with very little code. In this example, I want to show and hide various parts of a form based on what selections the user makes elsewhere. That’s a pretty simple thing to do with jQuery. It’s even easier with AngularJS.

First, let’s show our base markup. This is the bare minimum to get our page to work.

  </span>Angular Demo<span class="nt">

   method="post" action="#">
    
      What is your favorite color?
       name="favoriteColor">
        
        Red
        Blue
        Other
      
      Favorite color (other)
       type="text" name="favoriteColorOther"/>
    
       type="submit">
        Submit

The above HTML will render as follows.

If we already know jQuery, we know that we need to add a little more to our markup to make it play nice with jQuery.

Add an ID to our select box.
Add an ID to our wrapper div tag for our “Other” input.
Hide the “Other” form field by default.
Write a little bit of jQuery.

 name="favoriteColor" id="favoriteColor">

 id="form-field-favoriteColorOther" style="display: none;">

That’s really not too bad. Let’s however, add a few more requirements.

The Favorite Color option needs to be required.
The Other field needs to be required if Other is selected.
Don’t let the user submit an invalid form.

HTML 5 gives us some of this, but we still run into walls. We’re going to have to add a disabled attribute to the button. We’re going to have to validate our form with another library (or roll our own). We need to add required to the select box. We need to add required to our text box, but only if “Other” is selected.

The program flow should look like this.

This is the default state of the form.

User selects an option that is not “Other”. Everything is good. Enable the submit button.

User select “Other”. Show a text box and disable the submit button.

User enters a value in the text box. Everything is good again. Enable the submit button.

Again, none of this is particularly difficult, but you can imagine how all of this blows up when a page gets to be of a certain complexity. Let’s see what AngularJS has to offer.

Add ng-model tags to the form fields that we need to expose to angular. That’s both of them.
Add ng-required to any field that is dynamically required.
Add ng-disabled to any field that is dynamically disabled.
Wire it all together.

Let’s look at our AngularJS markup

 lang="en">
   charset="UTF-8">
  </span>Angular Demo<span class="nt">

 ng-app="">
   method="post" action="#" name="form">
    
      What is your favorite color?
       name="favoriteColor" ng-model="favoriteColor" required>
        
        Red
        Blue
        Other
      
     ng-show="favoriteColor === 'Other'">
      Favorite color (other)
       type="text" name="favoriteColorOther" ng-model="favoriteColorOther" ng-required="favoriteColor === 'Other'"/>
    
       type="submit" ng-disabled="form.$invalid">
        Submit

Let’s compare our jQuery markup with our AngularJS markup.

The body tag now has an ng-app="" attribute. This is what tells Angular that it should work.
We have added a name="form" attribute to our form. By giving the form a name, it can be accessed by Angular. This access can be seen on the submit button, with the form.$invalid variable.
We have added ng-model="..." to both of our input fields. This exposes the form fields to Angular.
We have added a required HTML5 attribute to our select.
We have added ng-show="favoriteColor === 'Other'" to our div tag that wraps our text box. This means that the field will only be shown if the expression is truthy.
We added an ng-required attribute to our text box. This means the field will be required if the expression is truthy.
Finally, we added an ng-disabled attribute to our button. This means that the button will be disabled if the expression is truthy.

Now, let’s show the JavaScript we need to write to make all this magic happen.

// Boo!

Yep. We’re done. Zero lines of JavaScript. Yeah, I could get used to this.

The complete series

Oops! How To Permanently Delete a File from Git

2014-08-07T08:00:00-04:00

I accidentally added an uninitialized (appended) SQL Server backup file, a *.bak, to source control and pushed it. Now, no one can fetch a clean copy of the source because of out-of-memory errors. How do I fix this?

git filter-branch --tree-filter 'git rm -r -f --ignore-unmatch *.bak' HEAD

This will take a while to run, as it goes through every commit in your project and deletes the file. When you’re done, you’ll need to push the file to your remote.

git push origin master --force

You’ll need the --force flag because this is not a fast-forward commit.

Getting Started with MathJax

2014-08-06T10:47:19-04:00

I’ve spent the past few days getting myself reacquainted with TeX and familiarizing myself with MathJax. As it turns out, it is quite easy to get MathJax working in Octopress.

Open source/_includes/custom/head.html.
Add the a JavaScript source: //cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-MML-AM_HTMLorMML.
Start typing your TeX.
In your Gemfile, make sure you are using at least RDiscount version 2.1. gem 'rdiscount', '~> 2.1'
In your _config.yml file, disable automatic superscripts by adding - no_superscript to your RDiscount configuration.

The last two are quite important. Without those two steps, it looks like RDiscount will turn x^2 into x². This will get displayed as x². That will break the MathJax processor.

Let’s start by demonstrating a simple inline equation, like $ y = mx + c $. This is simple enough by including the inline text: \$ y = mx + c \$.

To enter full equations, like the one below, use the following syntax.

\begin{equation}
x = \dfrac{ -b \pm \sqrt{ b^2 - 4ac } }{ 2a }
\end{equation}

The above code will render as the following equation.

\begin{equation} x = \dfrac{ -b \pm \sqrt{ b^2 - 4ac } }{ 2a } \end{equation}

Happy mathing!

Mocking a JavaScript Constructor

2014-07-18T07:27:05-04:00

JavaScript, and dynamic languages in general, make it extremely easy to mock out functions. This greatly reduces the need for all the extra programming junk (interfaces, adapters, wrappers, factories, etc.) that gets in the way of us solving our problems. We add tons of extra layers in the name of test isolation and object independence that plainly isn’t necessary in the dynamic languages world.

// lib/Point.js
var Point = (function () {

  function Point(x, y) {
    this.x = x;
    this.y = y;
  }

  Point.prototype.distanceTo = function(point) {
    var dx = this.x - point.x;
    var dy = this.y - point.y;
    return Math.sqrt(dx * dx + dy * dy);
  };

  Point.origin = function () {
    return new Point(0, 0);
  };

  return Point;

}).call(this);

module.exports = Point;

We’ve defined a very simple class, and it has all of the parts that we need to demonstrate how mocking works.

First, let’s define some simple tests. I’m using Jasmine and Node. (See jasmine-node for a command line version of Jasmine.) These tests fully describe the basic functionality of the class.

// spec/PointSpec.js
var Point = require("../lib/Point");

describe("Point", function () {

  var point;

  beforeEach(function () {
    point = new Point(3, 4);
  });

  it("can return the distance to the origin", function () {
    var distance = point.distanceTo(Point.origin());
    expect(distance).toEqual(5);
  });

  it("returns the expected value when constructing an origin", function () {
    var origin = Point.origin();
    expect(origin.x).toEqual(0);
    expect(origin.y).toEqual(0);
  });

  it("returns the expected values for x and y", function () {
    expect(point.x).toEqual(3);
    expect(point.y).toEqual(4);
  });

});

Mocking an instance function.

The distanceTo() function exists on the instance of Point. It’s incredibly easy to mock out. Functions are first-class members in JavaScript, so we can simply redefine the function in the unit test. In this example, we simply redefine the function to return 0.

describe("Point with stubbed distanceTo() function", function () {

  var point;

  beforeEach(function() {
    point = new Point(3, 4);
    point.distanceTo = function (point) {
      return 0;
    };
  });

  it("returns 0 via stub", function () {
    var distance = point.distanceTo(new Point(10, 10));
    expect(distance).toEqual(0);
  });

});

Mocking a class function.

The origin() function is a class function that returns the point {0, 0}. Let’s suppose we need to define a different origin. That’s easy to do!

describe("Point with stubbed origin() function", function () {

  var point, temp;

  beforeEach(function () {
    temp = Point.origin; // Save the definition for later.
    Point.origin = function () {
      return new Point(1, 1);
    };
    point = Point.origin();
  });

  afterEach(function () {
    Point.origin = temp; // Restore the original definition.
  });

  it("has the expected values for x and y", function () {
    expect(point.x).toEqual(1);
    expect(point.y).toEqual(1);
  });

});

In this case, we need to store the original definition of origin() in the temp variable. In beforeEach(), we will override the origin() function. In afterEach(), we will restore it to its former glory.

Mocking the class constructor.

Of the three, mocking the constructor takes a little more insight, but the activity is functionally the same. We are going to create a new class and copy all of the necessary functionality to the new class. We do this by copying over the prototype of the original point. We also need to explicitly copy over the origin() function, since class functions are not part of the prototype.

describe("Point with stubbed constructor", function () {

  var MockPoint = (function () {
    function MockPoint(x, y) {
      this.x = 0;
      this.y = 0;
    }
    return MockPoint;
  }).call(this);

  // Apply all functions from Point to MockPoint. Also copy the
  // origin() function to MockPoint.
  MockPoint.prototype = Point.prototype;
  MockPoint.origin = Point.origin;

  var point, temp;

  beforeEach(function () {
    temp = Point; // Save the definition for later.
    Point = MockPoint;
  });

  afterEach(function () {
    Point = temp; // Restore the original definition.
  });

  it("calculates distance correctly", function () {
    var distance = new Point(3, 4).distanceTo(new Point(6, 7));
    expect(distance).toEqual(0);
  });

  it("can stub out the constructor", function () {
    point = new Point(4, 5);
    expect(point.x).toEqual(0);
    expect(point.y).toEqual(0);
  });

  it("leaves the origin() function unchanged", function () {
    point = Point.origin();
    expect(point.x).toEqual(0);
    expect(point.y).toEqual(0);
  });

});

The pattern is the same. Create a copy. Redefine the function. (The constructor is just another function, just treated a little differently.) Do your tests. Restore the original definition.

I hope this clears up some of the issues around mocking JavaScript objects. This can be done easily with the language and require no additional 3rd party libraries.

A Pox on Static Languages

2014-07-11T08:00:00-04:00

It’s no secret that I am tired of .NET, C#, and static language stupidity.

My curent project went in for a code review, and I’m going to share the before snippet. This is a simple part of the project, containing no business logic — it’s just a way to check the status to make sure that the server is up.

public class Status
{
  public Status()
  {
    ServerTime = Clock.Instance.UtcNow;
    Timestamp = Clock.Instance.UtcNow.ToEpoch();
    Version = GetVersionString();
  }

  public DateTime ServerTime { get; set; }

  public long Timestamp { get; set; }

  public string Version { get; set; }

  private static string GetVersionString()
  {
    var version = Assembly.GetExecutingAssembly().GetName().Version;
    var versionString = string.Format("{0}.{1}", version.Build, version.Revision);
    return versionString;
  }
}

public class StatusController
{
  public Status Get()
  {
    return new Status();
  }
}

That’s all the relevant code in this particular example. Here is the reviewers comment.

Factor all of the work out of the Status class’s constructor. Treat Status as a DTO. Put unit tests around the new factory to ensure it is properly initializing Status.

Damn. The problem with that above review is that (1) it is a lot more code to write for such a simple thing, and (2) I completely agree that’s how it should be done in C# (and probably other static languages, too). From a testing and code design point of view, the above comment represents all of the best practices that good code should follow. It keeps the result object as a plain DTO. It makes sure that the controller is responsible for nothing beyond negotiation. The reviewer’s comment is valid and accepted for work.

If I sound too put off by this, please realize that this is less than 30 minutes of work for me to do. This is much more about my distaste with the current state of static language patterns than my critique of the code reviewer.

So, let’s start by adding a factory, moving the initialization logic to the factory. We are using Ninject, so we’ll also need to be sure to register this with our IoC container.

public interface IStatusFactory
{
  Status Create();
}

public class StatusFactoryImpl : IStatusFactory
{
  public Status Create()
  {
    return new Status
    {
      ServerTime = Clock.Instance.UtcNow,
      Timestamp = Clock.Instance.UtcNow.ToEpoch(),
      Version = GetVersionString()
    }
  }

  private static string GetVersionString()
  {
    var version = Assembly.GetExecutingAssembly().GetName().Version;
    var versionString = string.Format("{0}.{1}", version.Build, version.Revision);
    return versionString;
  }
}

// In our registration...
Kernel.Bind<IStatusFactory>().To<StatusFactoryImpl>().InRequestScope();

We also need to modify our existing StatusController.

public class StatusController
{
  private readonly IStatusFactory statusFactory;

  public StatusController(IStatusFactory statusFactory)
  {
    if (statusFactory == null)
      throw new ArgumentNullException("statusFactory");
    this.statusFactory = statusFactory;
  }

  public Status Get()
  {
    var status = statusFactory.Create();
    return status;
  }
}

Finally, let’s modify the Status object, removing the logic from the constructor.

public class Status
{
  public DateTime ServerTime { get; set; }
  public long Timestamp { get; set; }
  public string Version { get; set; }
}

Finally, we need to modify our StatusControllerTests file to get all of our tests to pass. We will introduce a mock object to the controller’s constructor.

public class StatusControllerTests
{
  private StatusController controller;
  private Mock<IStatusFactory> mockStatusFactory;

  [SetUp]
  public void Before_each_test()
  {
    mockStatusFactory = new Mock<IStatusFactory>();
    mockStatusFactory.Setup(x => x.Create()).Returns(new Status());
    controller = new StatusController(mockStatusFactory.Object);
  }

  /* snip */
}

All of this is easier how? The answer, obviously, is that this isn’t easier. I’m not even convinced that it is cleaner, even if it is more clearly separating concerns.

Total changes?

6 files modified (Status, StatusController, StatusControllerTests, StatusTests, plus two .csproj files)
3 files added (IStatusFactory, StatusFactoryImpl, StatusFactoryImplTests)

Ugh.

Reconciling with Ruby on Rails

How would I write the exact same thing in Ruby on Rails, and have the exact same level of testability (including mocking), etc.?

class Status
  attr_reader :server_time, :timestamp, :version

  def initialize
    @server_time = Time.now
    @timestamp = @server_time.to_i
    @version = Application::VERSION
  end
end

class StatusController < ApplicationController
  def index
    @status = Status.new
    render json: @status, status: :ok
  end
end

Wait. Doesn’t that look like the original code? Yes, it does. Thanks to Ruby’s basic attr_reader, I can quickly create the attributes for a class with very little code. The Ruby version is so much shorter because there is no reason to add extra layers (interfaces, factories) for the sake of object independence and testability in the dynamic objects world. We never require an actual type in dynamic languages, just something that conforms to the contract.

This is just another reason why I love Ruby. I can get more done faster, less typing, more clarity, and the same (or even better testability) than anything C# even comes close to accomplishing.

The Easiest WebAPI Authorization Tutorial Ever

2014-01-15T08:00:00-05:00

So, it took a lot of scouring of the internets, but I was finally able to piece together the bare minimum necessary to create your own authoritization client in WebAPI.

Step 1: Create a DelegatingHandler

The DelegatingHandler is a class that will be attached to all requests coming into your API. This is going to be the easiest authorization handler ever. Here are the rules.

If there is a token, any token at all, the request is valid.

Otherwise, the request is unauthorized.

Yes, this is simple. In reality, you’d want to check the value of the token against something, at the very least a local database. That is left as an exercise for the reader.

public class AuthorizationHeaderHandler : DelegatingHandler
{
  private string authorizationParameter;

  public bool HasAuthorizationParameter
  {
    get { return authorizationParameter != null; }
  }

  protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
  {
    ParseAuthorizationHeader(request);
    if (HasAuthorizationParameter)
    {
      ConfigureClaimsIdentity();
      return base.SendAsync(request, cancellationToken);
    }

    return ConfigureUnauthorizedRequest();
  }

  private void ConfigureClaimsIdentity()
  {
    var claims = new List<Claim>();
    // Ideally, you'd add some claims here.
    var claimsIdentity = new ClaimsIdentity(claims);
    Thread.CurrentPrincipal = new ClaimsPrincipal(claimsIdentity);
  }

  private Task<HttpResponseMessage> ConfigureUnauthorizedRequest()
  {
    var response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
    var taskCompletionSource = new TaskCompletionSource<HttpResponseMessage>();
    taskCompletionSource.SetResult(response);
    return taskCompletionSource.Task;
  }

  private void ParseAuthorizationHeader(HttpRequestMessage request)
  {
    if (request.Headers == null || request.Headers.Authorization == null || request.Headers.Authorization.Parameter == null)
      return;

    authorizationParameter = request.Headers.Authorization.Parameter;
  }
}

Step 2: Wire Your Handler to Your Configuration

Somewhere, you probably have a class that sets up your WebAPI configuration. You need to add this line to your configuration.

private static void ConfigureMessageHandlers(HttpConfiguration config)
{
  config.MessageHandlers.Add(new AuthorizationHeaderHandler());
}

Step 3: Add an Authorization Header to Your Requests

For this to work, you’ll need to add an authorization header to all of your requests. It needs to be in the following format.

Authorization: <scheme> <parameter>

Here’s a sample. (No don’t actually use this token. It’s just the SHA256 hash of Hello, World!.)

Authorization: Token DFFD6021BB2BD5B0AF676290809EC3A53191DD81C7F70A4B28688A362182986F

Step 4: Test With and Without an Authorization Header

Fire up Fiddler. Let’s create a request without an authorization header.

The request.

The reponse. We can see the 401 Unauthorized coming back from the server.

Now, let’s look at the same request with an authorization header.

The response. Now with more 200 OK.

We’re successfully grabbing the token from the request. Everything else is left as an exercise for the reader!

Unit Testing an MVC Authorize Attribute

2014-01-14T08:00:00-05:00

When working with unit tests, I usually consider it a code smell when you have more fixture setup than production code. Today, I ran into just that condition.

This class has been written for a while, but it wasn’t covered by any tests. I decided to change that. First, I’ll show you the class. The class under question is called SessionBasedAuthorizeAttribute. It looks to the ASP.NET session to get the username, instead of relying on a forms token.

public class SessionBasedAuthorizeAttibute : AuthorizeAttribute
{
  protected override bool AuthorizeCore(HttpContextBase httpContext)
  {
    // If the session object has not yet been created, then there is nothing
    // we can do with this authorization.
    if (httpContext.Session == null)
      return false;

    IHttpSessionAdapter httpSessionAdapter = HttpSessionAdapter.Deserialize(httpContext.Session);
    if (httpSessionAdapter.IsAuthenticated)
    {
      SetHttpContextUser(httpContext, httpSessionAdapter);
      return true;
    }
    else
    {
      return false;
    }
  }

  private static void SetHttpContextUser(HttpContextBase httpContext, IHttpSessionAdapter httpSession)
  {
    var mediator = Mediator.Instance;
    var query = new UserByUsernameQuery(httpSession.Username);
    var user = mediator.Request(query);
    httpContext.User = user ?? new Guest();
  }
}

Writing your own AuthorizeAttibute isn’t difficult. It’s just a few lines, really, to pull a value from session, fetch a user from the database, and set the user. But what about unit testing?

Here’s the result.

[TestFixture]
public class SessionBasedAuthorizeAttribute_Tests
{
  private AuthorizeAttribute attribute;
  private AuthorizationContext authorizationContext;

  [SetUp]
  public void Before_each_test()
  {
    attribute = new SessionBasedAuthorizeAttibute();

    var controller = new FakeController();
    MvcTest.SetupControllerContext(controller);

    authorizationContext = new AuthorizationContext();
    authorizationContext.Controller = controller;
    authorizationContext.HttpContext = controller.HttpContext;

    var controllerDescriptor = new ReflectedControllerDescriptor(typeof(FakeController));
    var method = typeof(FakeController).GetMethod("Nothing");
    authorizationContext.ActionDescriptor = new ReflectedActionDescriptor(method, "Nothing", controllerDescriptor);
  }

  [Test]
  public void Fails_when_session_is_not_authenticated()
  {
    SetupSession(false);
    Authorize();
    AssertUnauthorized();
  }

  [Test]
  public void Fails_when_session_is_null()
  {
    Mock.Get(authorizationContext.HttpContext).SetupGet(x => x.Session).Returns((HttpSessionStateBase)null);
    Authorize();
    AssertUnauthorized();
  }

  [Test]
  public void Succeeds_when_session_is_authenticated()
  {
    SetupSession(true);
    SetupServices();
    Authorize();
    AssertSuccess();
  }

  private void AssertSuccess()
  {
    var user = authorizationContext.HttpContext.User;
    user.Should().BeOfType<User>();
    user.Identity.IsAuthenticated.Should().BeTrue();
    user.Identity.Name.Should().Be("tester");
  }

  private void AssertUnauthorized()
  {
    authorizationContext.Result.Should().BeOfType<HttpUnauthorizedResult>();
  }

  private void Authorize()
  {
    attribute.OnAuthorization(authorizationContext);
  }

  private void SetupServices()
  {
    var mediator = new Mock<IMediator>();
    mediator.Setup(x => x.Request(It.IsAny<UserByUsernameQuery>())).Returns(new User { Username = "tester" });
    Mediator.Instance = mediator.Object;
  }

  private void SetupSession(bool isAuthorized = true)
  {
    var mockContext = Mock.Get(authorizationContext.HttpContext);
    var mockSession = new Mock<HttpSessionStateBase>();
    mockSession.SetupGet(x => x["IsAuthenticated"]).Returns(isAuthorized);

    // Return the mock.
    mockContext.SetupGet(x => x.Session).Returns(mockSession.Object);
  }

  internal class FakeController : Controller
  {
    public ActionResult Nothing()
    {
      return new EmptyResult();
    }
  }
}

By the way, there’s even more setup code that happens as a part of the MvcTest.SetupControllerContext() method call, but I had already written that for another purpose.

13 lines of production code. 25 lines of fixture setup.

It turns out, that’s much more difficult, because we are relying on a lot of the inner guts of MVC. I had to pull up the source code for the OnAuthorize method to see what all the NullReferenceExceptions were. When mocking out the HttpContext, you also have to mock out the Session (knew that) and Items (didn’t know that) properties. There are also some ActionDescriptor values that must be set for OnAuthorize to work, and I have never worked with those classes before, either.

I suppose the first conclusion is to praise the powers at Microsoft for open sourcing the MVC framework. Without access to the source, I would have never been able to write these tests. Even with the source, the terrible nature of the NullReferenceException made this much more difficult than it ought to be. Any time you have a chain of w.x.y.z, finding which of those threw the exception becomes a total PITA. Yeah, I know. The Law of Demeter is in play, too.

Check out Code Contracts. It makes this kind of in-code documentation much easier.

The second conclusion is the value of this kind of test. I’ve already had one coworker respond with, “this is where I begin to question the value add of unit testing.” I kinda have to agree with him. This was a hard test to write, even though the production code itself was quite easy. On one extreme, some people say that if it is important enough to write, then it is important enough to test. I think I agree with that sentiment. I believe in the value of testing. I’m just not sure what I could have done to make this testing easier and still remain within the bounds set by the MVC framework.

BCrypt Is Slow

2014-01-13T06:23:23-05:00

For some reason, this just made my day.

See those yellow dots? That’s NCrunch telling me that these tests are slow. It’s BCrypt. It’s supposed to be slow! That’s the whole point of using BCrypt. If you’re storing passwords, it’s the only hashing algorithm you should be using.

JavaScript Objects

2014-01-08T08:00:00-05:00

This is always a good topic to review. There are just too many developers who don’t know what they are doing when it comes to writing good JavaScript. The code for this project has been published to Github.

Understanding Scope

The first thing we must understand is how variables are scoped in JavaScript. When it comes to JS: there’s only one rule.

Variables are scoped to the function that defines them.

There’s no concept of block scope like in C# or Java. This means that we’re going to make use of something called a functional closure.

The Specs

Specs are a wonderful way of defining how a class should work. Don’t tell me this is BDUF or not how TDD is supposed to work. Both of these methodologies would say to only write one test, then write the code. Repeat until you are finished. This is why I refuse to strictly follow a dogma. If you know the specs up front, then write the specs.

The following tests are written with the Jasmine unit testing framework.

describe("Speaker", function () {

  it("can be instantiated");                     // 1.
  it("has a name attribute");                    // 2.
  it("can change the name in the constructor");  // 3.
  it("returns the expected message");            // 4.
  it("adds the message to an output buffer");    // 5.
  it("counts the number of times spoken");       // 6.
  it("counts the number of things said");        // 7.

});

Declaring the Constructor

var Speaker = (function () {

  function Speaker() {
  }

  return Speaker;

})();

Yes, we had to type the name of the class three times and the word function twice. I’m sorry.

The Functional Closure

The above code example is a functional closure. The more you work with good JavaScript, the more you’ll see this pattern. Yes, it’s a lot of character noise. I’m sorry Ruby developers.

(function(){})();

The above line creates an anonymous function that is executed immediately. In this example, we are creating a new Speaker function and then returning that function. The functional closure will let us hide variables that we don’t want exposed outside of class.

This will let us create new instances of our Speaker class.

var speaker = new Speaker(); // Passes #1.

Objects Are Instances of Functions

What syntax makes function Speaker() any different from function speaker()? Nothing at all. The only reason that we are capitalizing Speaker is by convention of those who have come before us.

console.log(typeof Speaker);   // returns "function"
var speaker = new Speaker();
console.log(typeof speaker);   // returns "object"

Adding Properties

We also think our speaker should have a name. I like to know to whom I am speaking.

var Speaker = (function () {

  function Speaker() {
    this.name = "Ann";
  }

  return Speaker;

})();

We can now test that the speaker really does have a name attribute now.

it("has a name attribute", function () {
  var speaker = new Speaker();
  expect(speaker.name).toBe("Ann"); // Passes #2.
});

Constructor Options

We should get used to using an options object in our JavaScript. Instead of having an explicit list of arguments, we instead accept a single options object as a method parameter. Remembering that JavaScript does not have a compiler, this allows us to be very clear about the expected inputs to our methods.

Having an options parameter also lets us set some defaults. Both jQuery and Underscore have an extend method that let us map settings. They both do the exact same thing. For no particular reason, I’m choosing Underscore over jQuery.

var Speaker = (function () {

  var defaults = {
    name: "Ann"
  };

  function Speaker(options) {
    this.options = _.extend({}, defaults, options);
    this.name = this.options.name; // Passes #3.
  }

  return Speaker;

})();

So, by default, our speaker will be named “Ann,” but we can still change it by adding a name attribute to our options argument.

var speaker = new Speaker({ name: "Bonnie" });

Also, notice that the defaults are private to the functional closure. There is no way to access these defaults from outside the Speaker object. While we can access speaker.options.name, we cannot, in any way, access speaker.defaults.

Adding a Functional Prototype

To expose a public function, we need to use the prototype attribute.

var Speaker = (function () {

  var defaults = {
    name: "Ann"
  };

  function Speaker(options) {
    this.options = _.extend({}, defaults, options);
    this.name = this.options.name;
  }

  Speaker.prototype.say = function(toSay) {
    var message = '"' + toSay + '," said ' + this.name + '.';
    return message; // Passes #4.
  };

  return Speaker;

})();

Duck Typing

I’m not going to get into duck typing today. A lot has already been said by developers much smarter than I. Check out Eric Lippert’s post and Phil Haack’s first and second posts. Instead, here’s the short, short version…

I’m going to call something - a method or property - and you had better just “work.”

That’s all we are going to do with the output buffer in this case. I’m going to call a .write() method. I don’t care what you give me, but I’m going to call that method.

We’re going to go back to our constructor here.

AlertBuffer: Writes to window.alert.
ConsoleBuffer: Writes to console.log.
MemoryBuffer: Writes to an internal array.

I wrote all three versions. They are available in the repository linked above. Here’s the code for the MemoryBuffer.

var MemoryBuffer = (function () {
  function MemoryBuffer() {
    this.messages = [];
  }
  MemoryBuffer.prototype.write = function(message) {
    this.messages.push(message);
  };
})();

We’ll set our buffer in the constructor of Speaker. We’ll go ahead and default to the MemoryBuffer. If you want the MemoryBuffer, then leave it alone. If not, then give us a new buffer when you create your Speaker instance.

var Speaker = (function () {

  var defaults = {
    buffer: new MemoryBuffer(),
    name: "Ann"
  };

  function Speaker(options) {
    this.options = _.extend({}, defaults, options);
    this.name = this.options.name;
  }

  Speaker.prototype.say = function(toSay) {
    var message = '"' + toSay + '," said ' + this.name + '.';
    this.options.buffer.write(message); // Passes #5.
    return message;
  };

  return Speaker;

})();

Creating a Private Function

Now we want to create a private function. This function needs to be exposed to the Speaker instance, but not outside of the instance. We can’t use a prototype for this, so how do we accomplish this? Answer: we just create a method inside of the function. This will scope it locally, preventing it from being exposed.

var Speaker = (function () {

  var defaults = {
    buffer: new MemoryBuffer(),
    name: "Ann"
  };

  function Speaker(options) {
    this.options = _.extend({}, defaults, options);
    this.name = this.options.name;
    this.thingsSaid = [];
    this.timesSpoken = 0;
  }

  Speaker.prototype.say = function(toSay) {
    var message = '"' + toSay + '," said ' + this.name + '.';
    this.options.buffer.write(message);
    addToThingsSaid(this, toSay);
    this.timesSpoken += 1; // Passes #7.
    return message;
  };

  function addToThingsSaid(speaker, toSay) {
    if (!_.contains(speaker.thingsSaid, toSay)) {
      speaker.thingsSaid.push(toSay); // Passes #6.
    }
  }

  return Speaker;

})();

With that, we will now pass all of our specs.

Relying on Unreliable IDs

2014-01-03T11:45:32-05:00

Relying on IDs means that we are checking that a value set by the database. This may be an autoincrementing value — a SQL Server identity or an Oracle sequence.

Why This Happens?

This anti-pattern occurs because it is thought to be easier to hard code values into the software than to make changes to the database schema. When the schema is wrong, fix it!

Example: Include/Exclude by Value

In this case, this particular department is a virtual department, not a real department, and we don’t want it displayed in this particular UI screen.

var departments = departmentRepository.Where(d => d.ID != 6).ToList();

However, in this program, the ID column is a SQL Server identity. The value of 6 was assigned to the row in the developer’s environment. However, there are three more environments to consider: QA, Staging, and Production.

There are two anti-patterns to this approach.

It assumes that data will be entered in the exact same order. It also assumes that if there was a mistake before, the mistake would be repeated, since a failed insert will increment the identity.
It assumes there will never be another department that we wish to exclude.

Solution: alter the schema to reflect the intent

The solution is to alter the database to reflect this logic.

ALTER TABLE [departments] ADD [exclude_from_user_management_ui] BIT NOT NULL DEFAULT (0);
UPDATE [departments] SET [exclude_from_user_management_ui] = 1 WHERE [id] = 6;

The application code is now extremely easy to understand, and there is no reliance on “magic” values.

var departments = departmentRepository.Where(d => d.ExcludeFromUserManagementUI == false).ToList();

Example: Setting a Default Value

In this example, we are using a value to reflect that something should have a default setting.

var task = new Task();
task.Description = "Be more awesome!";
task.Status = statuses.First(s => s.ID == "new");
task.CreatedAt = DateTime.UtcNow;

Again, this assumes that the “new” status will always be present. If you, ask the developer have complete control over the environments and deployments, then this does work. Also, you’re luckier than I, since I have never been at a client where I have complete control over deployments.

Solution: alter the schema to reflect the intent

ALTER TABLE [statuses] ADD [is_default] BIT NOT NULL DEFAULT (0);
UPDATE TABLE [statuses] SET [is_default] = 1 WHERE [id] = 'new';

The application code is similarly trivial.

var task = new Task();
task.Description = "Be more awesome!";
task.Status = statuses.First(s => s.IsDefault);
task.CreatedAt = DateTime.UtcNow;

Now, whether the query for .IsDefault should be a call to .First() or .Single() is an argument I don’t really want to get into. Ideally, it is probably correct that only one value can ever be the default value. However, I’ve been places where I don’t have any control over those particular administration screens, and the code quality is rather dubious. In that case, I chose the .First() method because I didn’t want my code to break because of another developer’s poor decisions.

Yes, I realize my code will still break if there are no default statuses. The [status_id] column in the database is not nullable, so .FirstOrDefault() is just prolonging the issue.

Lesson Learned: Don’t rely on magic.

DRYing Up Controller Actions With Responders

2014-01-02T08:00:00-05:00

I read a few books over the long weekend. One of those books was Crafting Rails 4 Applications by José Valim. I’m going to say that this is a pretty advanced book on Rails, since it really digs into the Rails framework internals, especially when it comes to overriding the default functionality.

One of the topics is how to DRY up your controllers by writing custom responders. That got me thinking. Can we do the same thing in .NET?

The “Before”

I have two controllers in my Portfolio application: a TagsController and a TasksController. These controllers contain the following lines.

// In TasksController
[HttpDelete]
public ActionResult Delete(DeleteTaskCommand command)
{
  var task = mediator.Send(command);
  var message = string.Format("Successfully deleted task: {0}", task.Title);
  this.Flash("success", message);
  return Json(new { success = true });
}

// In TagsController
[HttpDelete]
public ActionResult Delete(DeleteTagCommand command)
{
  var tag = mediator.Send(command);
  var message = string.Format("Successfully deleted tag: {0}", tag.Description));
  this.Flash("success", message);
  return Json(new { success = true });
}

That is some pretty similar code. In fact, that’s about as un-DRY as you can get. One might say that’s going to happen if you try to create some sort of standard in what your controllers and actions should look like.

Delete Is Easy

Notice that [HttpDelete] attribute on our Delete() methods? That means that the only way these methods are ever going to be called is via XHR. Currently, no browsers can create a DELETE request without the support of JavaScript. That means that our controller pattern has no reason to be complicated.

The DeleteResponder

It’s pretty obvious what we’re trying to achieve here, so let’s start by creating a branch and stubbing out some tests.

> git checkout -b responder-spike

Writing out your tests first is a good way to define a spec, so let’s do that. We can already tell what happens in our controller action, and we want our responder to mimic this behavior.

public class DeleteResponderTests
{
  private DeleteResponder deleteResponder;

  [SetUp]
  public void Before_each_test()
  {

  }

  [Test]
  public void It_should_send_a_request_to_the_mediator()
  {
    Assert.Fail();
  }

  [Test]
  public void It_should_add_a_successful_flash_message()
  {
    Assert.Fail();
  }

  [Test]
  public void It_should_have_an_expected_JSON_result()
  {
    Assert.Fail();
  }
}

What is our responder going to look like? I have a good idea what I think it should look like up front.

public class DeleteResponder
{
  private readonly ApplicationController controller;

  public DeleteResponder(ApplicationController controller)
  {
    if (controller == null) throw new ArgumentNullException("controller");
    this.controller = controller;
  }

  public ActionResult RespondWith<T>(IMediator mediator, ICommand<T> command)
  {
    throw new NotImplementedException();
  }
}

The easiest part is to send the command to the mediator. We can write that test fairly easily. We’re also going to need a fake controller.

public class DeleteResponderTests
{
  private ICommand<object> command;
  private DeleteResponder deleteResponder;
  private Mock<IMediator> mockMediator;

  [SetUp]
  public void Before_each_test()
  {
    mockMediator = new Mock<IMediator> { DefaultValue = DefaultValue.Mock };
    deleteResponder = new DeleteResponder(new FakeController());
    command = new FakeCommand();
  }

  [Test]
  public void It_should_send_a_command_to_the_mediator()
  {
    deleteResponder.RespondWith(mockMediator.Object, command);
    mockMediator.Verify(x => x.Send(command));
  }

  class FakeCommand : ICommand<object> { }

  class FakeController : Controller { }
}

This command implementation is extremely simple.

public ActionResult RespondWith<T>(IMediator mediator, ICommand<T> command)
{
  mediator.Send(command);
  return null;
}

Next, we want to make sure that the JSON result is returned appropriately.

[Test]
public void It_should_have_an_expected_JSON_result()
{
  var result = deleteResponder.RespondWith(mockMediator.Object, command);
  var jsonResult = MvcTest.HasExpectedActionResult<JsonResult>(result);
  var objectDictionary = jsonResult.Data.ToDictionary();
  Assert.IsTrue(objectDictionary["success"]);
}

This implementation is also fairly simple.

public ActionResult RespondWith<T>(IMediator mediator, ICommand<T> command)
{
  mediator.Send(command);
  var jsonResult = new JsonResult();
  jsonResult.Data = new
  {
    success = true
  };
  return jsonResult;
}

The only remaining piece is how we add the flash message. I’m actually going to leave this piece alone. If you want to see how I did it, then check out my version of the DeleteResponder.

The “After”

Our TagsController and TasksController now look like the following:

// TagsController
[HttpDelete]
public ActionResult Delete(DeleteTagCommand command)
{
  return new DeleteResponder(this)
      .RespondWith(mediator, command);
}

// TasksController
[HttpDelete]
public ActionResult Delete(DeleteTaskCommand command)
{
  return new DeleteResponder(this)
      .RespondWith(mediator, command);
}

Eight total lines of code become two total lines of code, and the common functionality is moved to a utility class.

Also, just because the delete is easy, that doesn’t mean that everything has to be difficult. Your controllers should be rather thin. They invoke a service. They do a query. They return an ActionResult. This responder pattern can be applied to any form post.

Caffeine-Powered Life

Getting into Docker

What is this Docker thing, anyway?

Advantages of Docker vs. traditional deployment

Authoring a Client-Side Web Application

Hello World!

Deploying our application

Conclusion

Reliable Database Fixtures with CouchDB

JavaScript Getters, Setters, and Aliases with Object Prototypes

Setting Up CouchDB on Ubuntu in Azure

Zero Inbox

But Jarrett, I still have too much email!

Angular Part 5: Testing

The tools

The application (app.js)

The point service (point.js)

The controller (PointCtrl.js)

The final result

The complete series

Angular Part 4: Creating a Service

Demonstration of application

Our new service

The complete series

Angular Part 3: Dependency Injection

The Traditional JavaScript Object

An Alternate JavaScript Object

Angular Objects

Conclusion

The complete series

Angular Part 2: Moving to a Controller

The complete series

Angular Part 1: Show and Hide

The complete series

Oops! How To Permanently Delete a File from Git

Getting Started with MathJax

Mocking a JavaScript Constructor

Mocking an instance function.

Mocking a class function.

Mocking the class constructor.

A Pox on Static Languages

Reconciling with Ruby on Rails

The Easiest WebAPI Authorization Tutorial Ever

Step 1: Create a DelegatingHandler

Step 2: Wire Your Handler to Your Configuration

Step 3: Add an Authorization Header to Your Requests

Step 4: Test With and Without an Authorization Header

Unit Testing an MVC Authorize Attribute

13 lines of production code. 25 lines of fixture setup.

BCrypt Is Slow

JavaScript Objects

Understanding Scope

The Specs

Declaring the Constructor

The Functional Closure

Objects Are Instances of Functions

Adding Properties

Constructor Options

Adding a Functional Prototype

Duck Typing

Creating a Private Function

Relying on Unreliable IDs

Why This Happens?

Example: Include/Exclude by Value

Solution: alter the schema to reflect the intent

Example: Setting a Default Value

Solution: alter the schema to reflect the intent

See Also

DRYing Up Controller Actions With Responders

The “Before”

Delete Is Easy

The DeleteResponder

The “After”