GitHub LinkedIn RSS
Showing posts with label Front End Programming. Show all posts
Showing posts with label Front End Programming. Show all posts
Sunday, November 2, 2014

EcmaScript6 with TypeScript and Grunt.js


ECMAScript 6 is nearly here. In fact I can already taste it and so will you with TypeScript. TypeScript is an open source language and compiler written by Microsoft running on NodeJS. The language is based on the evolving ES6 spec but adds support for types, interfaces that generates JavaScript (ES3 or ES5 dialects based on flag). In fact it's very interesting shift for Microsoft to make something useful for open source community, so before you boo me, have a look at it as it's not so bad.

Introduction


Microsoft has compiled a great video introducing the TypeScript and since one video replaces million words, let's start with it.



Using TypeScript


As TypeScript is built on top of Node.js, installing it will be as easy as breathing.
npm install -g typescript
And compiling the files is done through the tsc command, however this is no way respectable developers work. We'll be using Grunt.js to compile our TypeScript files during the build phase. Let's start with writing something small using the new syntax. As usual all the accompanying code can be found on article's repository. First we'll create Animal class and extend a Lion from it, overriding it's methods.
class Animal {
    constructor(public eats: string) {}

    eat() {
        console.log('Eating ' + this.eats);
    }

    speak() {
        console.log('Animal speaking');
    }
}
///
class Lion extends Animal {
    constructor() {
        super('meat');
    }

    speak() {
        console.log('Lion roars');
        super.speak();
    }
}
Then check our new classes in the HTML file:
<!DOCTYPE html>
<html>
<head>
    <script src="src/Animal.js"></script>
    <script src="src/Lion.js"></script>
    <script>
        var lion = new Lion();
        lion.eat();
        lion.speak();
    </script>
</head>
</html>
Pay attention that we reference the js files and not the ts ones. Now let's move to Grunt.js.

TypeScript and Grunt.js


To make both play together nicely, we'll be needing additional package, called grunt-ts. Since we won't be needing it besides development environment, let's use --save-dev flag to mark our intentions.
npm install grunt-ts --save-dev
Moving on to our gruntfile.js file. I've used as little options as possible to make the example easy to understand. There are a lot of configurations of grunt-ts package, which are thoroughly explained in it's page.
(function () {
    'use strict';
    module.exports = function(grunt) {
        grunt.initConfig({
            ts: {
                dev: {
                    src: ["src/*.ts"]                
                }
            }
        });

        grunt.loadNpmTasks('grunt-ts');
        grunt.registerTask('default', ['ts:dev']);
    };
}());
Once Grunt task is run, four files will be generated including both JavaScript and Map files of our classes. And of course opening our HTML page, will feed the console with following lines:
Eating meat               Animal.ts:5
Lion roars                Lion.ts:8
Animal speaking           Animal.ts:9
Pay attention to where Chrome maps the log calls, which is our original ts files. This will come handy in case of debugging your application, which means you don't really need to open the auto-generated JavaScript files.

Besides support in Visual Studio, TypeScript is also supported in WebStorm and SublimeText. Hope you enjoyed the article and next we'll be talking about CoffeeScript.
Tuesday, October 28, 2014

AngularJS E2E Testing with Protractor


In continuation to AngularJS series, today we'll discuss e2e or end-to-end testing of AngularJS applications. If you've been following the blog for a while, you must have noticed my numerous stressing the importance of unit testing using Jasmine and Karma and automating JavaScript testing with Grunt.js. The only thing left behind was e2e testing, of which we would talk today using Protractor for AngularJS applications.

What is E2E Testing?


End-to-end testing is a methodology used to test, whether the flow of an application is performing as designed from start to finish. The purpose of carrying out end-to-end tests is to identify system dependencies and to ensure that the right information is passed between various system components and systems.

In contrast to unit testing, which verifies the correct behaviour of various components separately, end-to-end testing verifies the entire flow of the application. From front end development perspective, it will be checking, whether JavaScript logic is reflected in the UI components. Good thing about Protractor is that we can write our end-to-end specs using Jasmine, so no knowledge of additional framework is needed.

angular-seed


To demonstrate the methodology, I'll be using angular-seed project, actually the whole article will be based on this repository. This project is an application skeleton for a typical AngularJS web app. You can use it to quickly bootstrap your angular webapp projects and dev environment for these projects. Installing the application is no-brainer, just follow the instructions in the repository - they are quite detailed. The reason I've chosen the seed project, was it had already had preconfigured Jasmine unit tests and e2e protractor tests in place. What is left is to understand the code :)

Unit testing with Karma


End-to-end testing doesn't replace the good old unit testing. It merely completes it to provide a comprehensive testing tookit. Let's take a look at Karma configuration file, karma.conf.js:
module.exports = function(config){
  config.set({

    basePath : './',

    files : [
      'app/bower_components/angular/angular.js',
      'app/bower_components/angular-route/angular-route.js',
      'app/bower_components/angular-mocks/angular-mocks.js',
      'app/components/**/*.js',
      'app/view*/**/*.js'
    ],

    autoWatch : true,

    frameworks: ['jasmine'],

    browsers : ['Chrome'],

    plugins : [
            'karma-chrome-launcher',
            'karma-firefox-launcher',
            'karma-jasmine',
            'karma-junit-reporter'
            ],

    junitReporter : {
      outputFile: 'test_out/unit.xml',
      suite: 'unit'
    }

  });
};
There are two interesting things about it. One is the integration with JUnit reporter, which reports test results in JUnit xml format. It than can be parsed programmatically and used for various DevOps purposes. For it however to work, you'll have to add the following line, indicating the usage of the reporter:
reporters: ['progress', 'junit']
The second thing is including angular-mocks.js file. It contains supporting functions for testing AngularJS application. Let's take a look at spec defined in version_test.js and see them in action.
'use strict';

describe('myApp.version module', function() {
  beforeEach(module('myApp.version'));

  describe('version service', function() {
    it('should return current version', inject(function(version) {
      expect(version).toEqual('0.1');
    }));
  });
});
We can see here the usage of functions module and inject. Both work in pair. The former registers a module configuration code by collecting the configuration information, which will be used when the injector is created by inject function. The latter wraps a function into an injectable function. The inject() creates new instance of $injector per test, which is then used for resolving references. You can read more about these functions in the respective documentation pages. You can also read a great article about Angular and Jamine here. The unit tests are run, as usual, using Karma command:
karma start karma.conf.js

End-to-end testing with Protractor


Protractor is a Node.js program built on top of WebDriverJS, which is Node.js runner, similar to node-jasmine, of which we've talked in Jasmine and Node.js article. Installing the driver is easy using the npm:
npm install -g selenium-webdriver
Then we need to set-up the selenium environment by running the following command:
npm run webdriver-manager
The interesting thing about this command is that it is run through the npm. The executed commands can be found in package.json file under scripts section.
"scripts": {
    "postinstall": "bower install",

    "prestart": "npm install",
    "start": "http-server -a localhost -p 8000 -c-1",

    "pretest": "npm install",
    "test": "karma start karma.conf.js",
    "test-single-run": "karma start karma.conf.js  --single-run",

    "preupdate-webdriver": "npm install",
    "update-webdriver": "webdriver-manager update",

    "preprotractor": "npm run update-webdriver",
    "protractor": "protractor e2e-tests/protractor.conf.js"
  }
So executing the webdriver-manager command, will actually execute webdriver-manager update. However since we have a pre prefix followed by the same name on another section, preupdate-webdriver, this script will be executed first - npm install. As you see configuring scripts through package file, allows us a lot of flexibility ensuring everything is run in the desired order.

Once everything is in place, let's start our e2e testing by typing the following command:
npm run protractor
Anddddd, it doesn't work - of course it won't :) So what is the problem:
....
protractor e2e-tests/protractor.conf.js

Starting selenium standalone server...
Selenium standalone server started at http://10.0.0.5:36333/wd/hub

/home/victor/git/angular-seed/node_modules/protractor/node_modules/selenium-
webdriver/lib/webdriver/promise.js:1640
      var result = fn();
                   ^
Error: Angular could not be found on the page http://localhost:8000/app/index.html :
retries looking for angular exceeded
From looking at the log we see that the webdriver is up and running on port 36333 and Protractor tries to fetch the page from port 8000. Is this the problem? As we can see Protractor runs according to configuration file e2e-tests/protractor.conf.js. Let's have a look at it:
exports.config = {
  allScriptsTimeout: 11000,

  specs: [
    '*.js'
  ],

  capabilities: {
    'browserName': 'chrome'
  },

  baseUrl: 'http://localhost:8000/app/',

  framework: 'jasmine',

  jasmineNodeOpts: {
    defaultTimeoutInterval: 30000
  }
};
Very similar to Karma config, isn't it? Run the specs written in Jasmine using Chrome on localhost:8000. But what is 8000? If we put here the port of our WebDriver, 36333, it won't help either, since WebDriver runs the Protractor tests and not the page itself. So the solution is pretty straight forward - configure web server on port 8000 to serve our app. Any server. Apache, Jetty or IIS God forbid, what ever is close to your heart. Rerunning the previous command will result some flickering on the page and console will report the passed tests. The tests are configured in scenarios.js file. I'll show you just one of them:
describe('view1', function() {

  beforeEach(function() {
    browser.get('index.html#/view1');
  });


  it('should render view1 when user navigates to /view1',
    function() {
    expect(element.all(by.css('[ng-view] p')).first()
      .getText()).toMatch(/partial for view 1/);
  });
})
Pay attention that instead of testing the internal logic of application, it rather tests the end result displayed to the user. That is, take the text of item retrieved by css rule, [ng-view] p, and test if it matches the string partial for view 1. That why it's called e2e testing.

Hope you found this article useful and would try to Protractor in your own projects. Next time we'll discuss Protractor usage with non AngularJS sites and also compare it to additional utility called CasperJS.
Thursday, October 16, 2014

AngularJS Debugging with Batarang


It's been a while from the moment I started to blog about JavaScript topics and despite me being MEAN developer; Heh-heh, actually I'm quite friendly. Anyway, despite the MEAN orientation of the blog, I haven't talked much about the "A", that is AngularJS. Well, today we are going to fix this and since it's the first blog of the month, we'll be talking about Batarang - debugging tool for AngularJS.

Why even bother? I use Chrome


Over the years a lot of developers have shifted to rely entirely on Chrome developer tools in terms of debugging front end applications. While Chrome indeed provides a superb build-in debugging functionality, it doesn't support specific aspects of modern frameworks like AngularJS and Ember. For instance it's not aware AngularJS scopes and models. Being a JavaScript application, one can of course debug AngularJS code as any other web application, however if you're not a stranger to Zen Coding, than productivity should be your top concern. Besides Zen's mumbo jumbo, as for me I would rather spend as much as possible time creating new features instead of being sucked into debugging bog.

Where do I start? 


For starters you should download the Batarang extension from the it's Chrome Market page. The extension's page also provides an eight minutes youtube tutorial, which can be a good starting point for you.


Play with it, even though Batarang doesn't provide many features at first glance, the ones it does, are must have for AngularJS debugging. See you next time...
Tuesday, September 30, 2014

JavaScript Promise


Nothing weights lighter than a promise
This maybe true regarding to human promises, however in the programming domain, promises are always kept. Following this optimistic note, today we'll be talking about JavaScript promises.

Event Handling Problem


Let's see what promises are good for and their basic capabilities starting with a problem they come to solve. Events are great for things of a repetitive nature like keydown, mousemove etc. With those events you don't really care about what have happened before you attached the listener. On contrary calling services and processing their response is a completely different kind of beast. Have a look at the following function, which reads a json file and returns it's content or an error in case of something goes wrong.
function readJSON(filename, callback) {
 fs.readFile(filename, 'utf8', function (err, res) {
     if (err) {
      return callback(err);
     }
     try {
       res = JSON.parse(res);
     } catch (ex) {
       return callback(ex);
     }
     callback(null, res);
 });
}
As you can see there're a lot of checks for errors inside the callback, which if forgotten or written in an incorrect order may cause it's creator quite a headache. This is where promises shine. JavaScript promises are not just about aggregating callbacks, but actually they are mostly about having a few of the biggest benefits of synchronous functions in async code! Namely, function composition of chainable async invocations and error bubbling; for example if at some point of the async chain of invocation an exception is produced, then the exception bypasses all further invocations until a catch clause can handle it (otherwise we have an uncaught exception that breaks our web app).

What is Promise?


A Promise is an object that is used as a placeholder for the eventual results of a deferred (and possibly asynchronous) computation. A promise can always be situated in one of three different states:
  • pending - The initial state of a promise.
  • fulfilled - The state of a promise representing a successful operation.
  • rejected - The state of a promise representing a failed operation.
Once a promise is fulfilled or rejected, it can never change again. The promises ease significantly the understanding of the program flow and aid in avoiding common pitfalls like error handling. They provide a direct correspondence between synchronous and asynchronous functions. What does this mean? Well, there are two very important aspects of synchronous functions, such as returning values and throwing exceptions. Both of these are essentially about composition. The point of promises is to give us back functional composition and error bubbling in the async world. They do this by saying that your functions should return a promise, which can do one of two things:
  • Become fulfilled by a value
  • Become rejected with an exception

Cross Platform Support


Over the years developer community has sprung numerous implementations of Promises. The most notable are Q, When, WinJS and RSVP.js, however since our blog focuses on the latest developments in the JavaScript world, we'll be only covering newest Promise class introduced in EcmaScript 6. You can see the browsers' support for the feature here, and in case you wish of your program to work in other browsers, as usually you can use the polyfill.

EcmaScript 6 Promise


The Promise interface represents a proxy for a value not necessarily known when the promise is created. It allows you to associate handlers to an asynchronous action's eventual success or failure. This lets asynchronous methods return values like synchronous methods: instead of the final value, the asynchronous method returns a promise of having a value at some point in the future. So let's see our previous example using promises.
function readJSONPromise(filename) {
    return new Promise(function (resolve, reject) {
        fs.readFile(filename, 'utf8', function (err, res) {
            if (err) {
                reject(err);
            } else {
                try {
                    res = JSON.parse(res);
                } catch (ex) {
                    reject(ex);
                    return;
                }
                resolve(res);
            }
        });
    });
}
Oddly it seems very similar. So what do we gain? The true power reveals itself when we try to chain the calls.
readJSONPromise('./example.json').then(function onReadFile(res) {
    return res;
}).then(function onProcessFile(response) {
    console.log('response: ' + JSON.stringify(response));
}).catch(function onError(error) {
    console.error('error: ' + error);
});
Once you return the object, you can pass it to other function for further processing. It allows us to apply the concern separation design in an easy and clean way. You can look at the full code in Git repository.
Sunday, August 31, 2014

Automate JavaScript Testing with Grunt.js


So far we've learned how to test your JavaScript code with Jasmine and running them against Node.js and browsers with Karma. We've also got familiar with modular design patterns in JavaScript. And yet, somehow it seems that we're still missing one last puzzle piece connecting all the others, it's called Grunt.js.

What is it?


According to it's site:
In one word: automation. The less work you have to do when performing repetitive tasks like minification, compilation, unit testing, linting, etc, the easier your job becomes. After you've configured it, a task runner can do most of that mundane work for you—and your team—with basically zero effort.
Zero or not, there is a bit of effort in making everything play together, but no worry - we'll figure it out. So what's our plan?
  • Write classes, which are both usable in Node.js, Require.js and global environment.
  • Write Jasmine specs to test our code in both Chrome and Firefox
  • Write Karma and Node.js runners
  • Write Grunt task to automate the testing

Writing universal JavaScript classes


In the end we'll type one command to test our code from every aspect. Feeling excited? Let's start! All the code can be found in GitHub, to where I copied some code from my project called Raceme.js, JavaScript clustering algorithms framework (some harmless PR :) First one is Vector class, which wraps the JavaScript array with minor functionality:
(function () {
    'use strict';

    var Vector = function Vector(v) {
        var vector = v;

        this.length = function length() {
            return vector.length;
        };

        this.toArray = function toArray() {
            return vector;
        };
    };

    if (typeof define === 'function' && define.amd) {
        // Publish as AMD module
        define(function() {return Vector;});
    } else if (typeof(module) !== 'undefined' && module.exports) {
        // Publish as node.js module
        module.exports = Vector;
    } else {
        // Publish as global (in browsers)
        var Raceme = window.Raceme = window.Raceme || {};
        Raceme.Common = Raceme.Common || {};
        Raceme.Common.Vector = Vector;
    }
}());
Notice the lower part of the code, where we define our class as AMD module using Require.js, CommonJS module for Node.js and global class for window environment. To spice things up, we'll add additional class, PlaneMapper, which will depend on our Vector class. It exposes one method, mapVector, mapping 2-dimensional coordinate point into vector. The problem with writing dependent universal classes is the loading process. As you remember, Require.js and Node.js use different loading methods - asynchronous versus synchronous. loadDependencies method unifies the approaches into one loading process. Pay attention to continuation of declaration logic in line 29; Once we have our PlaneMapper object defined, we finalize the declaration depending upon the method.
(function () {
    'use strict';

    var COMMONJS_TYPE = 2, GLOBAL_TYPE = 3;
    var loadDependencies = function loadDependencies(callback) {
        if (typeof define === 'function' && define.amd) {
            // define AMD module with dependencies
            define(['common/Vector'], callback); // cannot pass env type
        } else if (typeof(module) !== 'undefined' && module.exports) {
            // load CommonJS module
            callback(require('../common/Vector.js'), COMMONJS_TYPE);
        } else {
            // Publish as global (in browsers)
            callback(Raceme.Common.Vector, GLOBAL_TYPE);
        }
    };
    loadDependencies(function (Vector, env) {
        var PlaneMapper = function () {
            var mapVector = function mapVector(node) {
                return new Vector([node.x, node.y]);
            };

            return {
                mapVector: mapVector
            };
        };

        // finalize the declaration
        switch(env) {
            case COMMONJS_TYPE:
                module.exports = PlaneMapper();
                break;
            case GLOBAL_TYPE:
                var Raceme = window.Raceme = window.Raceme || {};
                Raceme.DataMappers = Raceme.DataMappers || {};
                Raceme.DataMappers.PlaneMapper = PlaneMapper();
                break;
            default:
                return PlaneMapper();
        }
    });
}());

Writing universal Jasmine specs


Code is written, time for testing. We'll create two Jasmine specs, each for one of the classes. As in before, we start with Vector class:
(function () {
    'use strict';
    describe('Mappers', function () {
        var loadDependencies = function loadDependencies(callback) {
            if (typeof define === 'function' && define.amd) {
                // load AMD module
                define(['common/Vector'], callback);
            } else if (typeof(module) !== 'undefined' && module.exports) {
                // load CommonJS module
                callback(require('../../src/common/Vector.js'));
            } else {
                // Publish as global (in browsers)
                callback(Raceme.Common.Vector);
            }
        };
        loadDependencies(function (Vector) {
            var vector;
            describe('Vector', function () {
                beforeEach(function() {
                    vector = new Vector([1, 2, 3]);
                });
                it('check length', function () {
                    expect(vector.length()).toEqual(3);
                });

                it('check toArray', function () {
                    expect(vector.toArray()).toEqual([1, 2, 3]);
                });
            });
        });
    });
})();
Nothing new here - we load the Vector class prior to declaring the spec using the same technique. Same with our mapper, besides loading two classes.
(function () {
    'use strict';
    describe('Mappers', function () {
        var loadDependencies = function loadDependencies(callback) {
            if (typeof define === 'function' && define.amd) {
                // load AMD module
                define(['common/Vector', 'dataMappers/PlaneMapper'], callback);
            } else if (typeof(module) !== 'undefined' && module.exports) {
                // load CommonJS module
                callback(require('../../src/common/Vector.js'), 
                    require('../../src/dataMappers/PlaneMapper.js'));
            } else {
                // Publish as global (in browsers)
                callback(Raceme.Common.Vector, Raceme.DataMappers.PlaneMapper);
            }
        };
        loadDependencies(function (Vector, PlaneMapper) {
            var vector;
            describe('PlaneMapper', function () {
                var mapper, node;
                beforeEach(function() {
                    mapper = PlaneMapper;
                    node = {
                        x: 5,
                        y: 10
                    };
                });
                it('check mapping', function () {
                    vector = mapper.mapVector(node);
                    expect(vector.toArray()).toEqual([5, 10]);
                });
            });
        });
    });
})();

Configuring Jasmine spec runners


Testing Node.js modules is easy - just run the jasmine-node command with path to the specs.
jasmine-node test/spec
Moving on to browser testing. We'll start with easier case using global declarations. First we create Karma configuration file, karma.conf.js. The main interest is in files and browsers sections, where we define our source and spec files in correct order and browsers we want to test.
...
files: [      
  'src/common/*.js',
  'src/dataMappers/*.js',
  'test/spec/*Spec.js'
],
...
browsers: ['Chrome', 'Firefox'],
...
Then invoking the tests using karma command.
karma start karma.conf.js
Lastly, let's test our Require.js modules. Since the modules will by loaded by Require.js instead of Karma, a new Karma configuration file is required - karma.conf.require.js. The first difference appears in frameworks section, where we tell Karma to use Require.js framework. This will require installing additional package called karma-requirejs.
...
frameworks: ['jasmine', 'requirejs'],
...
files: [
    {pattern: 'src/common/*.js', included: false},
    {pattern: 'src/dataMappers/*.js', included: false},
    {pattern: 'test/spec/*Spec.js', included: false},
    'test/test-require-main.js'
],
...
Additional difference comes in files section. Here we inform the test runner not to load our source and spec files. So why to list them at all? Listing the files enables us to use them later, during configuration of Require.js in test-require-main.js. Usually Require.js configuration appears in JavaScript file, mentioned in data-main attribute of script tag. However since we don't want to load HTML files, we configure our modules in test-require-main.js.
(function () {
    'use strict';
    var tests = [];
    for (var file in window.__karma__.files) {
        if (window.__karma__.files.hasOwnProperty(file)) {
            if (/Spec\.js$/.test(file)) {
                tests.push(file.replace(/^\/base\//,
                 'http://localhost:9876/base/'));
            }
        }
    }

    requirejs.config({
        // Karma serves files from '/base'
        baseUrl: 'http://localhost:9876/base/src/',

        // ask Require.js to load these files (all our tests)
        deps: tests,

        // start test run, once Require.js is done
        callback: window.__karma__.start
    });
}());
At first we pass through each file listed in the configuration by using window.__karma__.files list and initiate spec files list. While doing so, we adjust the domain of the specs modules to one used by Karma - localhost:9876. It will also be used as a baseUrl attribute in Require.js configuration. Then we integrate Require.js and Karma together by passing Karma's stating method, window.__karma__.start, as a callback in line 21. The heart of the fusing appears in line 18, where we configure to load our specs prior to calling the callback. Once specs are loaded, callback will be invoked starting the testing.

Writing Grunt tasks


As promised, it's time to integrate all parts using Grunt.js. For this to happen, we'll require four packages: grunt, grunt-cli and grunt-karma, grunt-jasmine-node. The first two for running the tasks and the rest are for calling Karma and Node.js runners. Make sure to install the packages locally into project's folder, otherwise it will not work. In fact all the packages should be installed locally, when you work with Grunt.js.

Installing them can be done easily using package.json and bower.json files. Once the files are in place just call appropriate install commands. It will download all the packages automatically into project's folder.
npm install
bower install
If you an eager environmentalist like me, who doesn't wish to store anything, but essential data on your repository, you may use .gitignore file, which tells Git to ignore specified paths.
node_modules/
bower_components/
Grunt tasks are defined using JavaScript code in gruntfile.js.
(function () {
    'use strict';
    module.exports = function(grunt) {
        grunt.initConfig({
            pkg: grunt.file.readJSON('package.json'),
            karma: {
                unit_global: {
                    configFile: 'karma.conf.js'
                },

                unit_requirejs: {
                    configFile: 'karma.conf.require.js'
                }
            },
            jasmine_node: {
                options: {
                    forceExit: true,
                    match: '.',
                    matchall: false,
                    extensions: 'js',
                    specNameMatcher: 'spec'
                },
                all: ['test/spec/']
            }
        });

        grunt.loadNpmTasks('grunt-karma');
        grunt.loadNpmTasks('grunt-jasmine-node');
        grunt.registerTask('default', ['jasmine_node', 
            'karma:unit_global', 'karma:unit_requirejs']);
    };
}());
Not very intimidating, isn't it? Basically what it does is configures our test tasks, loads the required packages and then runs the tasks. Now in details. At first it configures our Karma tasks by specifying two children in karma node: unit_global and unit_requirejs, each states it's configuration file name. Then it configures Node.js runner. Since it doesn't have any configuration file, all the settings are listed here. In the end, it runs the tasks in the order they appear in parameter array of registerTask method. Notice the usage of semicolon, when Karma tasks are specified. It tells Grunt to run specific tasks under karma node.

Tasks names can be changed, both jasmine_node and karma node's names cannot.


Aren't you eager to see the results?
grunt
Grunt will load and run the gruntfile.js file emitting the following result:
Running "jasmine_node:all" (jasmine_node) task
Common
    Vector
        check length
        check toArray
Mappers
    PlaneMapper
        check mapping
Finished in 0.014 seconds
3 tests, 3 assertions, 0 failures

Running "karma:unit_global" (karma) task
INFO [karma]: Karma v0.12.23 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [launcher]: Starting browser Firefox
INFO [Chrome 36.0.1985]: Connected on socket HrOcIkaJ5aqQG85SOqIS
with id 63263274
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.032 secs / 0.005 secs)
INFO [Firefox 31.0.0]: Connected on socket wrrkgK5_skzDJztmOqIT wi
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.032 secs / 0.005 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.032 secs / 0.005 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.032 secs / 0.005 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.032 secs / 0.005 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.032 secs / 0.005 secs)
Firefox 31.0.0: Executed 3 of 3 SUCCESS (0.026 secs / 0.002 secs)
TOTAL: 6 SUCCESS

Running "karma:unit_requirejs" (karma) task
INFO [karma]: Karma v0.12.23 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [launcher]: Starting browser Firefox
INFO [Chrome 36.0.1985]: Connected on socket PXxh9c5vacKQovhSOsI2
with id 36823086
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.004 secs / 0.002 secs)
INFO [Firefox 31.0.0]: Connected on socket Xu3qldD3wfmNskyOOsI3 wi
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.004 secs / 0.002 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.004 secs / 0.002 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.004 secs / 0.002 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.004 secs / 0.002 secs
Chrome 36.0.1985: Executed 3 of 3 SUCCESS (0.004 secs / 0.002 secs)
Firefox 31.0.0: Executed 3 of 3 SUCCESS (0.005 secs / 0.002 secs)
TOTAL: 6 SUCCESS

Done, without errors.
Perfection! But it's only a tip of the iceberg. We'll be talking more about Grunt.js using conditional logic and reporting, so stay tuned ;)
Wednesday, August 27, 2014

D3 Data Visualization Library


Data visualization is the study of the visual representation of data, meaning "information that has been abstracted in some schematic form, including attributes or variables for the units of information". In the end everything we do, needs to be somehow presented to the users. Fortunately, we humans are intensely visual creatures. Few of us can detect patterns among rows of numbers, but even young children can interpret bar charts, extracting meaning from those numbers’ visual representations. For that reason, data visualization is a powerful exercise and is the fastest way to communicate it to others.

What is D3?


D3 is a JavaScript library, which helps in manipulating documents based on data. It uses HTML, SVG and CSS to create visualizations. With D3.js, the complete capabilities of new-age browsers can be used without being constrained to a framework. Fundamentally, D3 is an elegant piece of software that facilitates generation and manipulation of web documents with data. It does this by:
• Loading data into the browser’s memory
• Binding data to elements within the document, creating new elements as needed
• Transforming those elements by interpreting each element’s bound datum and setting its visual
 properties accordingly
• Transitioning elements between states in response to user input

Learning to use D3 is simply a process of learning the syntax used to tell it how you want it to load and bind data, and transform and transition elements.

Basics of D3


Naturally the first thing we need to do is to install it, which can be easily done using Bower. If you're not familiar with the tool, please read the article what is Bower is and why you need it:
bower install d3
I myself am made entirely of flaws, stitched together with good intentions
This Augusten Burroughs quote fits me well, when I try to explain someone a new technology. The reason behind this is trying to demonstrate live examples, instead of diving into theory, like many others do. Or maybe write a series of tutorials and gradually increasing the complexity of material. Today will be no different :) On D3 GitHub page, there is a whole gallery demonstrating it's capabilities. Even more examples can be found on Christophe Viau's site. We'll be picking on of them.

Force Directed Graph


I decided to choose Force Directed Graph example, cause it seemed cool enough to get your attention and the implementation wasn't too intimidating. The code can be found here - I've rewritten a bit the example to make it more readable and concise. Let's see what we're building first:


Pull and let go one of the nodes with the mouse and see what happens. Your mind should be blown away instantly, as it cannot comprehend the amount of coolness contained in a single example.

Once you look at the implementation, you'll be even more amazed how little code is needed to make things working and we shall see how the magic happens right away.
var width = 960,
    height = 500,
    svg = d3.select("body").append("svg")
      .attr("width", width)
      .attr("height", height),
    graph = miserables;

force = d3.layout.force()
      .charge(-120)
      .linkDistance(30)
      .size([width, height]);

force.nodes(graph.nodes)
    .links(graph.links)
    .start();
Firstly we create a svg element with specified dimensions - no news here, maybe only the d3.select method, which acts almost as you'd expect. That is selecting the first element, that matches the specified selector string, returning a single-element selection, even if selector matches several elements. If no elements in the current document match the specified selector, returns the empty selection.

Then we create our force layout, a flexible force-directed graph layout implementation using position Verlet integration. Force layout supports many behaviours, at this time we'll be focusing on the ones needed for our example. For broader description about the layout, please refer the it's API page.
In our snippet we override the default charge, linkDistance and size attributes. Size parameter is quite self explanatory. Now, what is charge? Charge is a force, that a node can exhibit, where it can either attract (positive values) or repel (negative values). In our case, repelling. The bigger the value, in it's absolute form, the sparser our graph will be. The last parameter, linkDistance, is the distance we desire between connected nodes. Most often this property is set to a constant value for an entire visualization, but D3 also lets us define it as a function. When we do that, we can set a different value for each link.

After configuring our layout, we initiate it with our nodes and links from the famous Les Misérables novel, formatted in the JSON format. start method starts the simulation; this method must be called when the layout is first created, after assigning the nodes and links.
var miserables = {
  "nodes":[
    {"name":"Myriel","group":1}
    ...    
  ],
  "links":[
    {"source":1,"target":0,"value":1}
    ...
  ]
}
Nodes can except any information, we might find useful in the visualization process. In our nodes we have the name of character and group to which one belongs. The group will be used for dyеing our nodes later. Links, on the other hand, must have source and target attributes, which serve for connecting the directed graph. The objects may have additional fields that you specify; this data can be used to compute link strength and distance on a per-link basis using an accessor function. In our case there is a value, which will be used later to calculate the stroke width. Moving forward:
var color = d3.scale.category20(),
  node = svg.selectAll(".node")
            .data(graph.nodes)
            .enter().append("circle")
            .attr("class", "node")
            .attr("r", 5)
            .style("fill", function(d) { return color(d.group); })
            .call(force.drag);

node.append("title").text(function(d) { return d.name; });

var link = svg.selectAll(".link")
    .data(graph.links)
    .enter()
    .append("line")
    .attr("class", "link")
    .style("stroke-width", function(d) {
      return Math.sqrt(d.value);
    });
We'll be using built-in category20 method, which constructs a new ordinal scale with a range of twenty categorical colors. There are several variations of this method with b and c suffix, returning different palette of colors. You can choose the one you like from library's wiki.

Next we select all nodes using selectAll method, which works similar to its single variant. Interesting fact you may notice, that we don't have any nodes yet. So what will be selected? The way D3 works is returning pseudo-array - a placeholders for our future elements. Once marked, nodes data is applied using data method. Then enter method actually does the job of entering selection: placeholder nodes for each data element for which no corresponding existing DOM element was found in the current selection. Note that the enter method merely returns a reference to the entering selection, and it is up to you to add the new nodes, which we do with append method, inserting the circle element on each node. Then we assign CSS class, radius and fill color. Notice the dynamic nature of fill color, which is retrieved according to the node's group using color alias to category20 method. In the end we invoke force.drag method, using call method, which is mere helper method, made for chaining the calls on the current selection. drag method binds a behavior to nodes to allow interactive dragging, either using the mouse or touch. Finally we add character's name to each node, by adding title element inside our circles.

Next we add the links to connect our nodes. Nothing interesting here, besides dynamically setting the stroke-width CSS attribute according to value attribute. Not sure what good it does, probably just for demonstration purposes. Running the example up until now, will generate all the elements positioned in the top left corner. The next section is what makes everything dance.
force.on("tick", function() {
  node.attr("cx", function(d) { return d.x; })
      .attr("cy", function(d) { return d.y; });

  link.attr("x1", function(d) { return d.source.x; })
      .attr("y1", function(d) { return d.source.y; })
      .attr("x2", function(d) { return d.target.x; })
      .attr("y2", function(d) { return d.target.y; });
});
From the moment we call start method of our force layout, tick events are dispatched for each tick of the simulation. The this section, we listen to the events to update the displayed positions of nodes and links. The event handler is executed at each iteration of the layout. When it does, the force layout calculations have been updated and would have set various properties in our nodes and linked objects, which we could use to position them within the SVG container. First let's reposition the nodes. As the force layout runs it updates the x and y properties, which define where the node should be centered. To move the node, we set the appropriate SVG attributes to their new values. Later we update our links by setting the appropriate start and end points. That's it!

The beauty of D3 library is how it empowers us with tools to visualize nearly for data in the way we like. Some say it is less efficient than it's competitors like Sigma.js and Processing.js, however performance issues, like in any other computer science domain, should be managed and here is a good post to get your started.

If you felt I was moving too fast or wanted to read more detailed tutorial about the library, have a peek at Dashing D3js site - it walks though the material quite thoroughly.
Sunday, August 3, 2014

Sass and Compass


It's first week of August, and it means it's time for continuation of JavaScript Developer Toolkit series. Last month we talked about Sass and I promised I would elaborate on the topic with Compass. So let's talk about Compass.

What is Compass?


Compass helps Sass authors write smarter stylesheets and empowers a community of designers and developers to create and share powerful frameworks. Put simply, Compass is a Sass framework designed to make the work of styling the web smooth and efficient. Since it's based on Sass, it's compiled into regular CSS rules and is not required to be installed on production environment. Let's start with installing it on our machine:
gem install compass
Yes, it's Ruby again and you'll have to live with that. If the command is not recognized, then you probably haven't installed the Ruby on your computer. To do so, please read the JavaScript Developer Toolkit article.

Compass is made up of three main components. It includes a library of Sass mixins and utilities, a system for integrating with application environments, and a platform for building frameworks and extensions. In order to start working with Compass, one should set-up a new project using it's CLI. We'll call ours sample:
compass create sample

Features


Let's look over some most useful features of the framework like css-reset, grids, css3 and sprites.

Reset CSS

The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on. The general reasoning behind this was discussed here.
@import "compass/reset"
It will insert the reset rules code into your CSS file.

Grid System with Compass

A grid is a layout framework that helps you make efficient use of whitespace in your web pages, providing uniform dimensions for columns and rows of content, as well as other whitespace elements like margins and gutters. Compass support both most used grid frameworks Blueprint and 960.gs; you can use which ever you prefer.

Blueprint

The blueprint core team, while having never officially announced that the project is over, has through negligence, caused the project to fall behind. It has not kept up with layout and responsive approaches that are essential to web design nowadays. As a result, as of Compass 0.3, it has been taken away from Compass's core. If you do still prefer to work with it, you'll have to install the plugin. Later just create a new project and all the files will be auto-generated.
gem install compass-blueprint
compass create sample --using blueprint/basic

960.gs

Similarly to Blueprint, a plugin is needed to make the framework workable. Install the plugin and create a new project.
gem install compass-960-plugin
compass create -r ninesixty sample --using 960

CSS3 and Compass

Compass also removes the headache of typing vendor specific CSS3 rules like border-radius. It does it through the usage of predefined mixins:
@import "compass/css3";
.notice {
 @include border-radius(15px);
}
Have a look at notice class above and see how it will be transformed once Compass is done with it.
.notice {
 -moz-border-radius: 15px;
 -webkit-border-radius: 15px;
 -o-border-radius: 15px;
 -ms-border-radius: 15px;
 border-radius: 15px;
}
Compass supports nearly all CSS3 rules and even provides cool features like PIE through plugins.
compass install compass/pie
After installing the plugin, you'll be able to use some of the CSS3 features in older IE browser.
@import "compass/css3/pie";
.rounded {
 @include pie;
 @include border-radius(15px);
}

Sprites

If you've even worked with sprites, then you knew that it was tedious work and required a great deal of effort. Every image needs to be measured, and its position in the sprite map needs to be recorded in your stylesheets. Maintenance is a nightmare. If you haven't, then you should start to and Compass will help you with this. To gain some knowledge about the sprites, have a look at this.
@import "compass/utilities/sprites";
@import "icons/*.png";
Firstly we include the correct module and then direct the Compass to our image folder from which sprites will be created. This will create a sprite file laying out the images vertically. It can be through customization.

Having the sprite in place, we can use the build-in mixin all-<map>-sprites to create classes of all the images in the sprite, where map is the name of our sprite folder - in our case icons. The classes are created in a .<foldername>-<filename> format, so if we had add.png file in our icons folder, the appropriate class will be named as icons-add. You can later extend these classes and add additional rules. For instance:
.icons-add { background-position: -43px -24px; }
.add-button { @extend .icons-add; }
If you'd like to add only specific image to your current CSS file, then another mixin should be used - <map>-sprite($name), where map is our sprite folder and name our file name.
@import "compass/utilities/sprites";
@import "icons/*.png";
.add-button {
 @include icons-sprite(add);
}
There are numerous mixins and published extensions already present on Compass site and even more can be found on Sache site. Have a look, play around - there is lot to find there.

Tools


Compass team offers an app for 10$, which helps designers to compile stylesheets easily without using to command line interface. Developers however should not use such atrocities, cause from CLI comes the Force :)

Both WebStorm and Sublime Text support Sass and Compass. If you're using Sublime Text, try installing this package and read more about it's integration here. WebStorm users get the Sass support built-in starting from 8th version and can install plugin manually on lower versions. For more details read their blog.
Sunday, July 13, 2014

Jasmine and Karma


Let's talk about testing again, and will surely again in the future :) Last time I introduced the JavaScript Testing with Jasmine and we ran a few specs, however it seemed some how half baked - you were required to create a special page and open it in the browser to see the results. I you wanted to check in various browsers, you should have iterated the same procedure on each browser again and again.

This is not how we do things in 2014! We want to streamline the process! This is where Karma comes. It is built on Node.js and allows you to run the tests of your front end code automatically on various browsers.

Installation


In order to install Karma on your computer, run the following npm command. If you're not familiar with the tool, please read the JavaScript Developer Toolkit article first:
npm install -g karma
After you try to call karma though, you'll get unknown command error, which can be easily solved by installing karma command-line interface (CLI):
npm install -g karma-cli
To initiate the framework, just run karma init and follow the steps.
Which testing framework do you want to use ?
Press tab to list possible options. Enter to move to the next question.
> jasmine

Do you want to use Require.js ?
This will add Require.js plugin.
Press tab to list possible options. Enter to move to the next question.
> no

Do you want to capture any browsers automatically ?
Press tab to list possible options. Enter empty string to move to the next quest
ion.
> Chrome
>

What is the location of your source and test files ?
You can use glob patterns, eg. "js/*.js" or "test/**/*Spec.js".
Enter empty string to move to the next question.
> spec/*.js
> src/*.js
>

Should any of the files included by the previous patterns be excluded ?
You can use glob patterns, eg. "**/*.swp".
Enter empty string to move to the next question.
>

Do you want Karma to watch all the files and run the tests on change ?
Press tab to list possible options.
> yes
Please notice the positive answer for the last question. If you running Karma stand alone, it should be set to true. On contrary it can be integrate with IDE and be executed from there, for instance WebStorm. Watch a very short tutorial about the integration of Karma with WebStorm. In the end of the initiation process, a configuration file karma.conf.js will be created, which will be used to run our tests. If you didn't specify the browsers or wanted to add another one, on which you'd like to run your tests, you can install them later from the list of supported browser launchers. To add Firefox support, run the following command to install it and add Firefox key to the browsers array in the configuration file:
npm install -g karma-firefox-launcher
Last touch is needed to be completely ready to go. Karma is a framework, which executes Jasmin's spec using karma-jasmine plugin. Once you specify it in the initiation process, the plugin is downloaded and installed in the global repository. However it installs 1.3 version and not the latest 2.0. To fix this, we'll download the correct version manually:
npm install -g karma-jasmine@2_0

Running the tests


We'll be using our test specs from our previous Jasmine article and the source code can be found in GitHub.
karma start karma.conf.js
INFO [karma]: Karma v0.12.21 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [Chrome 36.0.1985 (Windows 8.1)]: Connected on socket DOFTiS5FuL20HriB6iUZ
with id 19929084
Chrome 36.0.1985 (Windows 8.1): Executed 5 of 5 SUCCESS (0.021 secs / 0.006 secs
Pardon my using Windows 8 - I had to give my Ubuntu laptop for repair :) Anyway, you'll notice your browser being stuck and closing it will just rerun all the tests. To fix this, set singleRun property in your configuration file to true. Also be aware of the localhost:9876 address. It is used by Karma to run the specs, which means you can test it on any device connected to your network. Try pointing your phone’s browser to Karma by looking at the URL of one of the browser windows running the tests. Because Karma is running an instance of Node.js, your test machine is acting like a server and will send the tests to any browser that is pointed to it.

We'll talk about using Jasmine with your server side using jasmine-node package in the next article.
Sunday, June 8, 2014

Bower and Require.js Integration


In the past we've talked about Bower package manager and God knows, I have been obsessively repeating myself about using Require.js and it's integration with object oriented programming. So how do they integrate with each other? In this article we'll cover the integration of both and see how they get along together.

Bower Initiation


Let's start by defining, which packages we want to use in our project by filling the bower.json. You can create one yourself or run bower init command for interactive creation.
{
    "name": "RequireJS Starter",
    "version": "1.0.0",
    "dependencies": {
        "jquery": "1.9",
        "underscore": null,
        "requirejs": null
    }
}
So we'll be needing jQuery, Underscore and of course Require.js. Putting null as a version number will download the latest version. Now run bower install to download all the packages into bower_components folder. You can change the location along with other thing using .bowerrc configuration file. After everything is in place, we'll configure our dependencies in our entry point JavaScript file and use the libraries once retrieved:
require.config({
    paths: {
        "jquery": "bower_components/jquery/jquery",
        "underscore": "bower_components/underscore/underscore"
    }
});
require(['jquery', 'underscore'], function($, _) {
    $('body').text(_.range(10));
});

Automagical wire-up


This is how it works according to the writter of bower-requirejs plugin. It looks at the libraries installed by Bower and creates a JavaScript file with require.config call with all the paths in place. Just run the following line in your bash console:
./node_modules/.bin/bower-requirejs -c destination/config.js
It has some interesting flags you can use, all of them well described in the documentation.

CDN Integration


But my mother told me local libraries are bad. She was right! We should always try to use CDN for common libraries, since chances are it had been already downloaded to user's computer and cached version would be used instead of downloading fresh version from our server. Let's edit our code and add cdnjs urls as a first priority. I prefer them over others because they offer the biggest variety of libraries and it's always good practice to work with a single provider. We'll leave our versions as a fallback if something bad happens to the CDN:
require.config({
    paths: {
        "jquery": ["http://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.1/jquery.min", "bower_components/jquery/jquery"],
        "underscore": ["http://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.6.0/underscore-min", "bower_components/underscore/underscore"]
    },
    waitSeconds: 10
});
require(['jquery', 'underscore'], function($, _) {
    $('body').text(_.range(10));
});
Notice the waitSeconds parameter we've added configuring how much time to wait for the CDN's versions. Hope things started to clear bit by bit. What to use and how to use it. I'll continue to write articles on this topic including Grunt integration.
Sunday, June 1, 2014

CSS and JavaScript Live Editing


As planned we're continuing our tradition to present JavaScript Developer Toolkit. Last time we've talked about Emmet and today's article I'd like to devote to HTML/CSS/JavaScript editing.

How often do you change your CSS rules and JavaScript within your browser? How often do copy/paste the changes made into appropriate resource files? It's time to do this Zen style.

IDE integration


This is my preferable way to develop and live-editing the changes. Let me show you why. Wouldn't it be cool if you could develop using your beloved IDE with all the neat plugins it offers and see the changes reflected live in the browser? Well - you can, with both Sublime Text and Webstorm we've talked about during our previous JavaScript toolkit article. You do this by installing JetBrains IDE Chrome extension for Webstorm:


or Emmet LiveStyle for Sumblime Text:


Look into their sites and see how properly things should to be configured. Both tools only offer support for Chrome, so Firefox fans will have to wait for now...

Browser Extensions


As time passed, passionate developers have been creating bunch of extensions both for Chrome and Firefox to enable this functionality. The most prominent ones are Chrome DevTools Autosave and EditCSS. However this work has not only inspired the developer community, but also the creators of both most commonly used browsers. As a result as of Firefox 11 and Chrome 28 the functionality has been bundled with the browsers, making the extensions obsolete.

Browser built-in capabilities


While Firefox has done some progress and enabled the live editing of CSS using it's Style Editor, the real advancement came from Google camp with the introduction of workspaces. It allows one to save both CSS rules and JavaScript code and even supports Sass debugging of Sass (.scss) files in the Sources panel, and view the results without having to leave DevTools or refresh the page. When you inspect an element whose styles are provided by a Sass-generated CSS file, the Elements panel displays a link to the .scss file, not the generated .css file. We'll talk more about Sass and Compass in the future. Find the time to watch the whole presentation about this feature:

Sunday, April 13, 2014

What Is Bower And Why You Need It


So you've heard everyone talking about this mythical creature called Bower. But what exactly is it? Better to see once than to hear 100 times, so before we proceed any further take a peek at their site.


The problem


Recall how you used to manage, and maybe still do, your 3rd party libraries. Firstly you went to their official site or maybe github repository. After finding the latest minified version, you would get something like this - xxx-1.0.1.min.js, then downloaded and saved it into your project. At last referencing it in the HTML would do the trick by copy pasting the script tag - <script src="//code.jquery.com/jquery-1.11.0.min.js">.

But what would have happened if a new version came up? Well, if you were aware of the update, you would repeat the process again and put xxx-1.0.2.min.js in your library folder. Then you would change the reference in your HTMLs or JavaScript files. You could of course rename the file to xxx.js and omitting the version and 'min' suffix, but then you'd need to enter the file itself to verify the version; that is if the version was written there of course.

All this should have been done just for one library, but you well know that today's applications depend upon dozens of 3rd libraries. Each of them has its own version and keeping track of their changes has become a tedious if not impossible task for a man who just wanted to use some cool library. This is where Bower comes to help.


The solution


Basically, Bower is a package manager of JavaScript libraries. It was designed specifically to maintain the front-end related libraries like JQuery, Underscore and so on. You can use Bower to download libraries from the command line, without having to manually download each project from their respective sites. Bower keeps track of these packages in a manifest file called bower.json. Once you downloaded the package, the usage is up to you - Bower doesn't interfere nor assists with the loading process of the libraries.


The rumors


There is a lot of confusion among newcomers to the JavaScript package management world about the purpose of each tool and needs they come to solve. Let's talk about the most common rumors.

Bower vs npm


npm is most commonly used for managing Node.js modules, but some front-end libraries has crept into its repositories and may be downloaded from there as well.

Bower is created solely for the front-end and is optimized with that in mind. The biggest difference is that npm does nested dependency tree (size heavy) while Bower requires a flat dependency tree (puts the burden of dependency resolution on the user).

A nested dependency tree means that your dependencies can have its own dependencies which can have their own, and so on. This is really great on the server where you don't have to care much about space and latency. It lets you not have to care about dependency conflicts as all your dependencies use e.g. their own version of Underscore. This obviously doesn't work that well on the front-end.

Bower vs Requirejs


Bower is intended to keep track of the packages, whereas Requirejs for managing the dependencies inside the project. Once you've downloaded all the required libraries using the Bower, you would still need to reference all of them in your code in the right order. This is what Requirejs does.

The usage


Let us see how to install and use the Bower. In order to install it, just get it from the npm using the following code:

npm install -g bower

If you don't know what npm is or don't have one installed on your machine, please read the JavaScript developer toolkit article. Go to the project's folder and initiate the bower configuration file. The tool will ask you couple of question like naming and versions before it starts. To do this, type the following:

bower init

Once everything is set up, start downloading packages by typing their name:

bower install jquery

or typing the github repository directly:

bower install https://github.com/jquery/jquery

Bower supports many options to make your life easier like downloading specific version or auto-update all or some packages at once. All these can be read about on their site.