Grunt-based JavaScript CodeShip build

I have been playing around with CodeShip lately. I really like it! Here's what I'm doing for Grunt-based builds on CodeShip, running the Jasmine specifications on Karma with PhantomJS.

Setup Commands

gem install compass
nvm install 0.10.33
nvm use 0.10.33
npm install
npm install -g grunt-cli
npm install -g bower
bower install

Test Commands

grunt test

Resolving issue with Yeoman-generated Angular web project and the jasmine framework provider

I'm kicking off a new Angular web client project today and I'm using Yeoman to get me up and going here. Seems the angular-generator for Yeoman doesn't properly link in the plugins needed for running Jasmine specs within karma, reported on this StackOverflow question. Add the following to your karma.conf.js file in the project root directory:

plugins: [
    'karma-jasmine',
    'karma-coverage',
    'karma-junit-reporter',
    'karma-phantomjs-launcher',
    'karma-chrome-launcher',
    'karma-safari-launcher',
    'karma-firefox-launcher',
    'karma-ie-launcher'
],

I also needed to install these node packages and save the configuration to the package.json file:

npm install karma-jasmine --save-dev
npm install karma-coverage --save-dev
npm install karma-junit-reporter --save-dev
npm install karma-phantomjs-launcher --save-dev
npm install karma-safari-launcher --save-dev
npm install karma-firefox-launcher --save-dev

CoffeeScript Application Development by Ian Young

I had the opportunity to read CoffeeScript Application Development by Ian Young recently and thought I would put together a book review.

The author does a nice job describing why parentheses are required for executing CoffeeScript no-argument functions. This is an idiom that I have seen many developers trip over when first coming to CoffeeScript. CoffeeScript preserves JavaScript’s view of functions as first-class citizens. Parentheses are optional except when necessary to avoid ambiguity.

The author gives some nice examples of loop comprehensions, one of the snazzier features of CoffeeScript. Loop comprehensions come from Python and they make for a more readable way to iterate a list and selectively act on list elements which meet a certain criteria. I’m always looking for more examples of loop comprehensions in CoffeeScript and this book has some nice examples.

The CoffeeScript switch statement is explained thoroughly. This is a handy flow-control statement that works really well in its incarnation in CoffeeScript. There are numerous examples in the book where different usage scenarios are demonstrated. Very handy and welcomed.

I found the author’s treatment of classes and inheritance in CoffeeScript to be a nice, gentle introduction. The examples that are given in the book work well and the explanations that accompany the examples are clear and concise. It would have been nice to get an explanation of the boilerplate code that CoffeeScript generates for you when defining a class, but I guess that’s considered part of the magic of CoffeeScript. It isn’t until the discussion on inheritance that the author starts to poke his head under the hood to investigate the generated JavaScript. The inheritance discussion is extremely valuable and a big plus for this book. If you get this book for anything, it’s for this discussion. CoffeeScript is doing a whole bunch of interesting stuff when creating classes and implementing inheritance, and this is one of the first times that I have seen the generated JavaScript described line by line.

In typical fashion, the author introduces the fat arrow syntax in a gentle manner, clearly explaining the reasoning for such a feature. The author then gives a very good explanation why you should not overuse the fat arrow syntax in your CoffeeScript (hint, it’s due to memory usage). He also includes a very succinct definition and example around memoization in CoffeeScript. This is a feature that I have not had much exposure to, so it was great to see it described and used in an example.

IcedCoffeeScript is introduced in the chapter on Going Asynchronous. I have not used IcedCoffeeScript, so that was an interesting exploration into an extension to CoffeeScript for managing asynchronous invocations. Looks interesting.

The topic of debugging CoffeeScript is broached. This is an interesting subject, as I have seen a few developers really get frustrated with the mapping of generated JavaScript back to the original CoffeeScript. Luckily the author introduces source maps, which does this work for us. The author shows us how to set this feature up in Firefox and Chrome developer tools. Your mileage will vary on this feature, but it is an interesting tool for easing the inertia of moving to CoffeeScript. This discussion comes with a lot of screenshots that help you understand how the source maps feature can be used in the developer tools.

Overall I really liked this book and it’s a worthy addition to my other documentation on CoffeeScript. Link to the book

Jasmine spying on jQuery selectors

Quick blog post about how to spy for jQuery selectors. Say I want to write something like the following:

var $element = $('div.my-element');

How would you write a Jasmine specification to drive this line of code in a Backbone.View function? Here it is:

it("find the element using a jQuery selector", function() {
   var spy = spyOn(jQuery.fn, 'find');
   this.view.doSomething();
   expect(spy).toHaveBeenCalledWith('div.my-element');
});

The reason you can do this is that $(selector, context) becomes $(context).find(selector). By default, selectors perform their searches within the DOM starting at the document root. However, an alternate context can be given for the search by using the optional second parameter to the $() function (from http://api.jquery.com/jQuery/#jQuery1). Had to write this down in a blog so I remember it again some day. Cheers!

Adding HTTP headers to AJAX calls in Backbone.js

Just a quick note about setting custom header in the HTTP request that Backbone.js manages. This is super easy to do. In the example code below, I have a Backbone.Collection assigned to messagesCollection variable and I'm triggering a fetch on that collection: messagesCollection.fetch({ headers: { 'x-my-custom-header-1':'foobar', 'x-my-rest-api-version':'1.0' } });

Grails GSPs consume Underscore.js ERB-style interpolation delimiters

If you are planning to do any work with Grails and Underscore.js (or Backbone.js) and you have view templates maintained in Groovy Server Pages (GSP) with Underscore.js ERB-style interpolation markup, watch out! GSP will eat up the Underscore.js interpolation markup (<%= %>) before Underscore ever gets a chance to use it. I assume evaluations would also be consumed by GSP. Took me a while to figure this out, so I thought I'd raise it up as a concern. Underscore.js does give you a way to change the delimiters using regexes.

Rationale for CoffeeScript's 'Fat Arrow' syntax

I gave a CoffeeScript presentation last night at our local Groovy Users of Minnesota meet up. One of the questions that came up last night had to do with CoffeeScript's fat arrow (=>) syntax, which will both define a new function and bind the new function to the current value of this. This is super helpful for callback-based libraries, such as jQuery.

I was building a Backbone.View today (in JavaScript) and had to deal with this binding. In my JavaScript, I wanted to call fadeOut on the view's el property (which happens to be a jQuery wrapped element). Without using the jQuery proxy method to bind this appropriately, my statement of 'this.el.fadeOut();' will not work. The this reference is no longer the view at the point I'm using it in the anonymous function; the context for this has changed within the anonymous function declaration. The correct JavaScript code is below.

var MyView = Backbone.View.extend({

    initialize: function() {
        this.template = _.template($('#my-template').html(), this.model.toJSON());
        this.render();
    },

    render: function() {
        this.el.html(this.template);
        return this;
    },

    events: {
        "click button#doSomethingButton": "doSomething",
    },

    doSomething: function(e) {
        this.model.set({someValue: $('#someValueTextField').val()});
        var promise = this.model.doSomethingOnModel();
        promise.done($.proxy(function() {
            this.el.fadeOut();
        }, this)).fail(function() {
            alert('Failed to check sequence uniqueness.');
        });
    }                                               
});

So how does this relate to CoffeeScript? Well, the fat arrow operator is performing the proxying of the 'this' reference for you. If I wrote the above in CoffeeScript, I could write the done callback as:

…
promise.done => @el.fadeOut()
…

Chaining the done and the fail callbacks would necessitate the use of parentheses, but still very succinct. Score one for CoffeeScript!