Latest News

 

Here's a tip on deploying Node app builds to Heroku - use the grunt-shell task to make things simple.

Let's say you have this scenario - an Angular JS app, served by a Connect or Express server. Your web app needs a build (Coffeescript, SASS, concat, uglify etc). I use Grunt for running tasks, and Yeoman's Angular Generator to get started.

When you have a Node app, the only option for doing Heroku deployments is via Git. So your build needs to be part of the repo. Say you type grunt build, and you end up with a build in dist/. You now have to add the dist/ directory tree to the index (because stuff under it might have been cleaned up), and make a commit. Here's how to automate it:

// Gruntfile.js
module.exports = function (grunt) {
  ...
  grunt.initConfig({
    ...
    shell: {
      'git-add-dist': {
        command: 'git add '
      },
      'git-commit-build': {
        command: 'git commit -am"build"'
      }
    }
  });
  
  // load the grunt-shell task:
  grunt.loadNpmTasks('grunt-shell');
  ...

  // add these tasks to the build task:
  grunt.registerTask('build', [
    'clean:dist',
    'jshint',
    'test',
    'coffee',
    'compass:dist',
    'useminPrepare',
    'concat',
    'imagemin',
    'cssmin',
    'htmlmin',
    'copy',
    'cdnify',
    'ngmin',
    'uglify',
    'rev',
    'usemin',
    'shell:git-add-dist',
    'shell:git-commit-build'
  ]);
  ...
};

Now type grunt build, and it's ready for deployment:

Alex:tested-form alex$ grunt build
Running "clean:dist" (clean) task
...
Running "shell:git-add-dist" (shell) task

Running "shell:git-commit-build" (shell) task

Done, without errors.
Alex:tested-form alex$ git log -1
commit ad9d9595a2b7d1dae385f63376480c765e27f166
Author: Alex Urdea
Date:   Fri Jun 28 16:52:15 2013 +0300

    build

So now it's in the repo, waiting for a deploy. You can create a heroku task that chains this with a push to your dynos:

// Add these to Gruntfile.js
grunt.initConfig({
  ...
  shell: {
    ...
    'heroku': {
      command: 'git push heroku master'
    }
  }
});
...
grunt.registerTask('heroku', ['build', 'shell:heroku']);

And you're good to go: grunt heroku

Gotchas for Node JS apps on Heroku

Posted on: June 27th, 2013 6 Comments

 

Heroku is amazing, and everything is pretty much straight forward, but a bunch of things made me go through their docs and through StackOverflow. I've used Heroku with Ruby before, but never with Node. This time it was a Node JS app served with Express, with a web app, using Angular JS and scaffolded with yeoman/generator-angular.

Force Heroku to aknowledge a Node app

I like to use the Cucumber BDD framework for integration and sometimes for smoke testing, and I like to implement the steps using Ruby. My app had a Gemfile added to the repo, that would only be used in development, as Cucumber was the only use of Ruby in this project. When I deployed my app, Heroku saw the Gemfile before Node's signature package.json file, so it decided it was a Ruby app. So no NPM packages were installed etc.

192-168-0-102:tested-form alex$ git push heroku master
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 921 bytes, done.
Total 9 (delta 4), reused 0 (delta 0)

-----> Ruby app detected
-----> Using Ruby version: ruby-1.9.3
-----> Installing dependencies using Bundler version 1.3.2
Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin --deployment
Using bundler (1.3.2)
Your bundle is complete! It was installed into ./vendor/bundle
Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Discovering process types
Procfile declares types -> web
Default types for Ruby -> console, rake

-----> Compiled slug size: 10.9MB
-----> Launching... done, v10
http://tested-form.herokuapp.com deployed to Heroku

The fix, as described in this Stackoverflow discusion, is to force te right buildpack, either by a heroku config:add, or when you create the new app. After the right adjustments, it works:

192-168-0-102:tested-form alex$ git push --force heroku master
Total 0 (delta 0), reused 0 (delta 0)

-----> Fetching custom git buildpack... done
-----> Node.js app detected
-----> Resolving engine versions
 Using Node.js version: 0.10.12
 Using npm version: 1.2.30
-----> Fetching Node.js binaries
-----> Vendoring node into slug
-----> Installing dependencies with npm
 npm WARN package.json tested-form@0.0.0 No repository field.
 npm http GET https://registry.npmjs.org/config
 npm http GET https://registry.npmjs.org/coffee-script
 npm http GET https://registry.npmjs.org/yaml
 npm http GET https://registry.npmjs.org/lodash

Bind to the right port

Never had encountered this before, and I guess this must be the first time I overlook the snippet in their docs that states it quite clearly. Heroku decides the port that you MUST use, and it exposes it as the PORT environment variable. I was trying to bind my Express server to 8080 for this staging environment hosted on Heroku. This is what I was getting in the logs:

Alex:tested-form alex$ heroku logs -t

2013-06-27T22:27:57.410360+00:00 heroku[web.1]: State changed from down to starting
2013-06-27T22:28:01.640729+00:00 heroku[web.1]: Starting process with command `node server/start.js`
2013-06-27T22:28:03.099087+00:00 app[web.1]: HTTP server listening on port 46111

2013-06-27T22:29:03.256352+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2013-06-27T22:29:03.256508+00:00 heroku[web.1]: Stopping process with SIGKILL
2013-06-27T22:29:04.374059+00:00 heroku[web.1]: Process exited with status 137
2013-06-27T22:29:04.380692+00:00 heroku[web.1]: State changed from starting to crashed
2013-06-27T22:29:04.382151+00:00 heroku[web.1]: State changed from crashed to starting

You cannot use any other port, so you'd better do this:

// when on Heroku, port will be exported to an environment variable
// and available as process.env.PORT
var port = process.env.PORT || CONFIG.port;
app.listen(port);

Make sure you deploy the build

Because I've used the Yeoman Angular seed, the built app was placed under the build/ directory (after Coffeescript compilation, SASS and all the rest). I preferred to keep the build out of my repo, and when I deployed I got back 404s.

There are currently only two ways to deploy - WAR and Git deployments for Java apps, and Git for all other types of apps. So I had to add dist/ to the repo. Any client side changes for me required a build (grunt build), then a commit and a git push heroku master.

EDIT: There's a better way to do this, as suggested by Johann: use the npm postinstall hook to do a build, install bower packages etc:

...
  "scripts": {
    "postinstall": "./node_modules/.bin/grunt build"
  }
...

For this, you will need to have the grunt-cli package installed locally, so have it listed as a dependency in your package.json.

 

Light up your dynos

Also, since this is about gotchas - I remember something that caught me by surprise a while back, when I first used Heroku: just deploying with Git, does not start up any dynos, although it says "Launching... done, v20" So you must scale up manually:

heroku ps:scale web=1

Then check it:

heroku ps

Sandboxing jQuery selection

Posted on: November 26th, 2012

 

Recently, I had to come up with an architecture that would allow multiple teams within Sky to write modules for a single page application. They were supposed to host their own JS scripts and CSS, and we'd load them into the app dynamically, when users would visit certain sections of the app.

You can imagine how without proper sandboxing, this would cause chaos, as a naive approach would allow a team's scripts and CSS to clash with other teams'. The proposed solution I came up with included enforcing modules, dependency management and dynamic loading via Require JS, using an MVC framework, hooks in the software versioning system that would trigger integration tests to run, and last, but very important: currying jQuery, so that when a selector was used, it would only select elements under a certain view's root element.

A selector that is too broad can have unforeseen effects, and is more dangerous when it affects parts of the DOM that you don't own. The solution is pretty simple: within a module you declare a local variable "$", or "jQuery", which will actually be a curried version of jQuery.

The jQuery function has multiple signatures: http://api.jquery.com/jQuery/. When the first argument is a string, and no context is provided, we want to make sure that it can only grab elements that are owned by us. So, based on the parameters passed into our wrapper around jQuery, we decide whether to add our root element as context:

    getSandboxedJQuery: function($root){
        var selector = null;
    
        return function(){
            var args = Array.prototype.slice.call(arguments);
    
            if (args.length == 1 && (typeof (selector = args[0]) == 'string')){
                return $.apply(this, args.concat($root));
            }
            
            return $.apply(this, arguments);
        };
    }

Here is some more code in a demo (http://jsfiddle.net/LwFsy/22/: you have a simple module that is run when the DOM has finished loading, and that receives an Api as a parameter. This is similar to a real life RequireJS module. Then, with the curried version of jQuery, we use a broad selector to find a div. If we'd select it the original jQuery, we'd also get another div outside our restricted tree.

 

After reading some articles on the Decorator design pattern, I started searching for Javascript implementations that make it possible to remove the dynamically added behaviour. What if we want to use multiple decorators on an object, but want to keep the option to take some of them off later, while keeping others on?

I dug deeper on the Web, and found some discutions on this topic (example #1, example #2 etc), but no Javascript implementations. I decided to experiment with this on my own, on the Decorator and Chain of Responsibility design patterns.

First, the Decorator. Here is its most common form in Javascript (see Wikipedia example):

var target,
    DemoDecorator1, DemoDecorator2;

// the object to be decorated
target = {
    someNumber: 0,
    getNumberString: function(){
        return "" + this.someNumber;
    }
};

// decorators
DemoDecorator1 = function(objToDecorate){
    var newNumber = objToDecorate.getNumberString() + " 1";

    objToDecorate.getNumberString = function(){
        return newNumber;
    };

    return objToDecorate;
};

DemoDecorator2 = function(objToDecorate){
    var newNumber = objToDecorate.getNumberString() + " 2";

    objToDecorate.getNumberString = function(){
        return newNumber;
    };

    return objToDecorate;
};

// The client code, that uses these decorator functions:
console.log(target.getNumberString());  // => "0"

target = new DemoDecorator2(new DemoDecorator1(target));
console.log(target.getNumberString());  // => "0 1 2";

Please notice that the decorator functions are used in a new statement, but the decorator instance is not returned from the constructor. Instead, the initial target object is augmented and returned. To return something from a function that is to be used as a constructor is generally an anti-pattern in Javascript, but this is in fact the only kind of good usage that I know of.

Further, you can see that the target has been augmented, and you can imagine a more complicated scenario, where you have a bunch of decorators, and you want to take them off and put them back on. In that scenario, this solution would not work.

Before picking a path towards a solution, I’ve assumed that we might find ourselves in scenarios with swarms of objects that need to be decorated multiple times (perhaps in a Javascript game), so we don’t want to store lots clones of the intermediary states we get by decorating. Therefore, it seems cheaper to override the methods on the original objects, and just store the overridden methods.

Here’s my take on this - since the decorator is a constructor, and therefore creates an instance that this points to inside of it, we can store data on that instance - to be more precise, we will store the backed up methods. Again: there’s the decorator constructor, which creates the decorator instance, which is used to store the backed up methods.

I will stick to the functionality seen in the first code example to demo this - methods that concatenate strings to the string returned by the overridden method. So if the original demo method returns "0", the demo method that’s defined on the decorator will wrap it, and return "0 1" etc.

The newly decorated object must somehow access the properties available on the target object in it’s previous state. This means that it should have a utility method attached to the target during the decoration - let’s call it overriddenMethod. So if before the wrap the demo method returned "0", then on the decorator, we can define the new demo method:

demo: function(){
    var oldDemoFn = this.overriddenMethod('demo');
    return (oldDemoFn ? oldDemoFn() : '') + ' 1';
}

Here’s the way we retrieve the overridden methods:

Decorator.prototype = {
    ...
    overriddenMethod: function(methodName){
        return this.methodsBackup[methodName];
    },
    ...
};

I want the methods that are brought from a previous state to access other methods from that same state, not the current one. So here’s the trick to achieve this - binding.

If I have an initial object named target, that is not wrapped by any decorator yet, and I want to decorate it with D1, then when I archive the overridden methods, I will bind them to the object itself. If I want to add another decorator D2 on top of that, then I will bind the backed up methods to the D1 instance before archiving them:

Decorator = function(decoratedObject){
    ...
    for (decMethod in this.newMethods){
        ...
        // If the object has already been decorated before (        // methods to the top-most decorator context. Else, bind it to the decorated object.
        if (typeof decoratedObject.decoratorScope == "function"){
            this.methodsBackup[decMethod] = _.bind(decoratedObject[decMethod], decoratedObject.decoratorScope());
        } else {
            this.methodsBackup[decMethod] = _.bind(decoratedObject[decMethod], decoratedObject);
        }
        decoratedObject[decMethod] = this.newMethods[decMethod];
        ...
    }

    return decoratedObject;
};

The bind function that I’ve used is from the Underscore JS library. The third utility method, removeDecorator, will just return the current context (decorator instance).

There are a couple of other methods that are needed to make it all work - decoratorScope, which will return the decorator instance, and of course - demoveDecorator:

Decorator = function(decoratedObject){
    ...
    return decoratedObject;
};
Decorator.extend = Extend.extendMethod;
Decorator.prototype = {
    removeDecorator: function(decoratedObject, decoratorConstructor){
        ...
    },

    overriddenMethod: function(methodName){
        ...
    },

    decoratorScope: function(){
        ...
    }
    ...
};

This all starts too look complicated. In fact, it’s too complicated to be called a design pattern. It’s a Decorator library, because one critical aspect of a design pattern candidate is to be simple enough to be easily explained. Well, as long as the client code is simple enough, it’s still useful. Here’s a possible usage:

var target,
    DemoDecorator, DemoDecorator2;

target = {
    demo: function(){
        return "not decorated";
    }
};

/* Client code: */
DemoDecorator = Decorator.extend({
    constructor: function(decoratedObject){
        decoratedObject = Decorator.apply(this, arguments);
        return decoratedObject;
    },
    newMethods: {
        demo: function(){
            var oldDemoFn = this.overriddenMethod('demo');
            return (oldDemoFn ? oldDemoFn() : '') + ' : decorated (DemoDecorator)';
        }
    }
});

DemoDecorator2 = Decorator.extend({
    constructor: function(decoratedObject){
        decoratedObject = Decorator.apply(this, arguments);
        return decoratedObject;
    },
    newMethods: {
        demo: function(){
            var oldDemoFn = this.overriddenMethod('demo');
            return (oldDemoFn ? oldDemoFn() : '') + ' : decorated (DemoDecorator II)';
        }
    }
});

I’ve used the Backbone JS inheritance mechanism (extracted to a utility script), so the constructor attribute of the object that’s passed in will contain the constructor function that will be used. The newMethods contains the methods that will be added or that will override the existing ones when the target is decorated.

I don’t really like the fact that I’m sticking utility methods on the decorated object. It’s a bad idea to modify objects that you don’t own. They might interact in an unexpected way with the client code logic that does not expect them to be there, and their names might clash with names for existing methods.

The removeDecorator utility method can get passed a decorator constructor as a parameter, and will search the whole chain, from outermost to innermost decorator, and remove the first occurrence. If no decorator is passed in, it will just assume you want the outermost one removed. Basically, it “visits” one decorator instance at a time, and checks whether the next decorator instance down the line is to be removed (is an instance of the Decorator that was passed in). If so, it grabs it’s methodsBackup property and stores on the current decorator instance. This is enough to ensure that the correct decorator instance is now next in chain.

The code is on github (code above is for this commit), including unit testing. In an article that will follow, I will explore removing dynamically added functionality with the Chain of Responsibility design pattern.

This is the new blog

Posted on: August 27th, 2012

 

I haven't posted anything on my blog for a looong time, and I scrapped out all the old stuff. This is my new blog, with a new theme (that should respond to all screen resolutions), and hopefully there will be some new content here very soon. I'm not contracting at the moment, so I should easily find the time.