Announcing ncline: a Node Program/Platform for Executing JavaScript Functions from a Command Line

JavaScript , Node.js No Comments »

I'm pleased to announce the release of my new open-source project, ncline.  ncline stands for "Node Command Line", and it's a platform for writing Node-powered JavaScript functions ("commands") that can be executed from a command line interface.

When you launch ncline, it loops through the collections of module folders within the master "cmdModules" folder and adds any functions exported under the "commands" property to a catalog of executable commands.  The user can then execute any of those commands from the ncline command prompt by typing the command name followed by any required or optional arguments.


Instructing Proxyquire To Ignore Nested Requires

JavaScript , Node.js 1 Comment »

When writing unit tests for Node.js applications, you can use the proxyquire npm module to override the modules pulled in by the file under test using require(), replacing them with your own.


CORS in Grails 3 Using An Interceptor

Grails , Grails 3.x 2 Comments »

The other day I started working on a personal project involving Angular 1.x and the latest version of Grails (3.0.1).  I created a Grails controller with a method that returned a list of domain class objects as JSON, while on the Angular side I wrote a service method to make an HTTP request to retrieve that JSON.  But because the HTTP request came from a different domain, it was disallowed:  I needed to instruct Grails to accept the request via CORS (cross-origin resource sharing).

After some trial-and-error, I came up with a solution involving the Interceptor artefact introducted in Grails 3.


Angular Material Design, $mdToast, and HTTP Interceptors

AngularJS 5 Comments »

Recently I've been playing around with the current beta distribution (0.8.3) of Angular Material Design: a set of Angular modules and resources that apply the "Material Design" style and behaviors used in Android 5.0 to an Angular website.

One of the services added by the Angular Material modules is the $mdToast service,  which provides an easy way to display small pop-up notifications ("toasts") in response to events (a common behavioral convention on mobile devices).  I wanted to use the $mdToast service in my httpInterceptor service function for handling HTTP response errors so that I could display a toast message if the server returned a nasty 500 HTTP status code.

But I ran into a problem:  when I tried to inject $mdToast into my interceptor service factory using standard Angular dependency injection, I got a "circular dependency found" error message when I loaded my Angular app.  The same thing happened when I tried injecting $mdToast into a service module of my own creation - toastService - and injecting that into my interceptor service factory.

The solution to the problem offered on the "ngmaterial" Google Group forum was to manually inject $mdToast into the service factory via $injector:


Mild Hack for Unit Testing the Run Method of an Angular Module

AngularJS No Comments »

In Angular 1.x, the run() method of a module behaves similar to the main method or constructor method concept found in other languages:  it's a method that runs as soon as all of the dependencies have been resovled and the module has been configured.

Because of this, even if you use run() to execute a named method that can be called separately in your unit test, the code in that method gets executed during the process of instantiating the module to use in your tests.  That makes it difficult to do any testing that compares the state of data prior to running the method or tests that require mocking dependencies and dependency behavior inside of the method.

So when I ran into this problem, I came up with a mild "hack" to work around the immediate execution of the run() method.  I made the execution of the code inside my run method dependent on the value of a Boolean constant:

angular.module( 'mainModule', [] )
    .constant( 'executeRunMethod', true )
    .run( runMethod );

function runMethod( $rootScope, authService, executeRunMethod ) {
    if ( executeRunMethod ) {
        //Execute the code as expected

runMethod.$inject = [ '$rootScope', 'authService', 'executeRunMethod' ];

With the executeRunMethod constant set to true, the runMethod() code executes via run() once the module is wired up as expected, so everything "runs" normally.

In my unit test however, I can override the executeRunMethod constant during the process of instantiating the module, setting it to false, effectively preventing the run() method from executing.

'use strict';

describe( 'mainModule', function () {
    var $rootScope,

    beforeEach( function () {

        module( 'mainModule', function ( $provide ) {
            // The executeRunMethod constant is overridden to be false
            $provide.constant( 'executeRunMethod', false );
        } );

        inject( function ( $injector ) {
            $rootScope = $injector.get( '$rootScope' );
            mockAuthService = { requestUser: function() {} };
        } );


Later in the test file, I can test the runMethod directly, passing in the needed arguments, including a "true" instance of the executeRunMethod argument allowing the code to be executed:

describe( 'the runMethod function', function() {

        var executeRunMethod = true;

        it( 'performs the expected action', function () {

            runMethod( $rootScope, mockAuthService, executeRunMethod );

            expect( result ).toEqual( expectation );

So this arrangement lets me test the code used by the module run() method just as if it was a normal method.