Monday, April 24, 2017

node: creating a debugger setup for visual studio code and mochajs for typescript tests

The title of the post says everything that I wanted to say. I have been looking at how to create a more streamlined environment for my nodejs typescript development.
I was specifically interested in how to start only a specific test with the interactive debugger. I did not want to change the launch config every time I worked on a new test and I also wanted to handle mocha test  written in typescript.

I normally have a tsc process started in separate command window running tsc -w command.This watches all files and compiles when needed.

Here are the changes I made to Visual Studio Code and my environment.
In my project I installed:

  • typescript
  • mocha
  • mocha-typescript

I decided to hide all TypeScript generated files via adding a files.exclude directive to my USER SETTING  (access via File:Preferences:Settings), like so:

"files.exclude": { "**/.git": true, "**/.svn": true, "**/.hg": true, "**/CVS": true, "**/.DS_Store": true, "**/*": true, "**/*.js": { "when": "$(basename).ts"} }

Then came the harder part. Finding a launch.config elements that would work (access via Debug:Open Configurations). I wanted to be able to open the debug pane and open the typescript test file I was working on, set breakpoints and click on "Start Debugging" button (green play button) and have the process kick off correctly.

This was not as trivial as I initially envisioned and much googling and blog reading ensued.
Here is the launch.config segment that worked for me.

{ "type": "node", "request": "launch", "name": "Debug TS mocha", "program": "${workspaceRoot}/node_modules/mocha/bin/_mocha", "stopOnEntry": false, "args": ["${fileBasenameNoExtension}.js","--no-timeouts", "--trace-warnings","--colors"], "cwd": "${fileDirname}", "sourceMaps": true, "outFiles": [], "env": { "NODE_ENV": "testing"} }

This works well with standard mocha js test as well as typescript test files. For typescript you need to either have a watcher going or add a preprocess to the launch.config that transpiles your typescript first.

Hope this will save someone the head scratching I went though.


Thursday, March 9, 2017

node: A deeper look into npm (Node Package Manager)

Our topic for our last NodeJs user-group meeting was npm.
npm is automatically included when Node.js is installed. npm consists of a command line client and a remote repository. The command line client, of course, interacts with the remote registry. This combination allows users to consume and distribute JavaScript modules that are available in the repo. It was created in response to what its creator said "module packaging done terribly". There are many elements in this toolbox, did you know you can use npm without node??
Here are the slides of our deep dive. Hopefully it gave all of you who attended a better understanding a few helpful tips and tricks.

Thursday, September 15, 2016

nodejs: Continuous Code Deployment using Node.js and AWS Stack

Yesterday we had our monthly Node.js usergroup meetup. I want to thank all for coming and exchanging interesting ideas for us to ponder.

We looked into how to create a complete deployment cycle using cloud technologies to support our node development.

We reviewed the complete process (build, test, deploy) and how tools like:
- AWS CloudPipeline
- AWS CodeCommit
- EBS (Elastic Bean Stalk)

We also used Solano Labs CI build service which is a cloud based alternative to build tool like Jenkins.

Building a continuous deployment cycle can change the game for even small shops to roll out quality code from development to production in very little time.

Here are the slides from the presentation, this will probably help those that were taking diligent notes. Most command line text are present on the slides.


Saturday, September 10, 2016

serverless: Serverless Framework and ethics vs the shiny object dilemma

For the last little while I was working on serverless concepts and exploring the Serverless Framework. It allows me to automate many manual steps but at the same time  it also imposes its way of thinking. Thus, it is a highly opinionated framework.

Though one can be of different opinions some of the good things provided by this framework are the ability to organize your project locally, abstract configuration, and deploy to different clouds from the command line.

The local development and testing paradigm is still rough and docs and examples are rather high level in many places.

It is also very much at the beginning stages with version 1.0 just about to be released. As such it has an enthusiastic crew with a lot of passion to push things forward. So, in short it is the new shiny thing that is cool and thus enjoys mindshare and interest.

In general that is a good thing. In particular, I can already see that there are cracks in the foundation. Two things in particular come to mind:

A) Dogma 

There is a sense of "we know better what you need" that permeates much of the later work on this framework. Whether it is through heavy configuration driven mechanisms in lieu of any convention elements or the careless breaking of implementation from earlier beta releases. For example, here is just a sprinkling of frameworks that believe in less configuration is better:

  • Apache Maven
  • Appcelerator's Titanium Alloy
  • CakePHP
  • ColdBox Platform
  • Contao
  • Crosslight
  • Durandal (JavaScript SPA Framework)
  • Ember.js
  • Enduro.js
  • Grails
  • Java Platform, Enterprise Edition
  • Laravel
  • Lift (web framework)
  • Meteor (web framework)
  • Play Framework
  • Roxy rest-API
  • Ruby on Rails
  • Sails (web framework)
  • Spring Framework
  • Symfony
  • Yii

This does not appear to be relevant to the current team and my fear is that the shininess will not overcome the effort it takes to maintain this when an alternate framework emerges. Ignorance in this case is not bliss.

B) Ethics of Tracking

The framework uses automatic enabled tracking of usage data. To discover this you will need to dig deep into docs and code. I understand that this is anonymous, however, this is not the way to approach the issue. Take Apple's location tracking for example, it is anonymous as well. How good do you feel about it?

For me the issue is with the enabled by default attitude. It is the complete undermining of faith of the user community. I believe firmly that any company making the automatic assumption of collecting data about me is living on the edge of ethics. Rather than playing in the muck, I would like to encourage the team to elevate themselves from questionable practices. There is time, and there are better alternatives.

Yes, you can disable all this once you find out where in the documentation it is hidden and run the right commands. This is not the point. If you don't ask me assume that you should not do it.

Here is the disable command if you are looking for it (run against all instances and all machines that you own):

$ serverless tracking --disable


So in short, this framework has potential but it is sliding into the area of big, obtuse, and rather in-the-way-of-the-task with ethical dangerous undertones before even hitting version one. These are achievements we should not be proud off given the great promise that it has.

If you have a project that is small or medium sized there are alternatives that work equally well and don't involve you sharing your personal command history. You still get automation and deployment in place with full control. Look at connecting AWS Code Commit to Lambda through Continuous Integration Pipelines via CodePipeline. That is some sweet stuff.

I am planning on outlining how to do this in more detail in later posts.
I will also put some things on serverless how-tos as contrast. There is good stuff there so an eye should be kept on it.


Thursday, April 14, 2016

node: April 2016 Charlotte Node.js User Group material

Folks please find the links to the presentation materials and code samples from our April 2016 Node.js meeting. I hope this will get you kickstarted with node:

The presentation slides
The sample code

Here again the objectives from out meetup "Kicking it with Node, starter edition" :
By popular demand we will focus our sessions on how the node ecosystem works. This will include the setup of the environment the idiosyncrasies of JavaScript and base understanding of the event loop and asynchronicity.

So in the next session we will look at some of this:

  • installing Node.js 
  • understanding async tasks 
  • understanding the event loop 
  • what are callbacks  
  • creating projects 
  • understanding node modules and packages  
  • organizing code  
  • writing your own module 
  • what is the package.json file 
  • managing 3rd party packages with npm 
  • the require system 
  • exploring core module examples in node


Wednesday, November 11, 2015

node: Easier debugging of nodeunit with node-inspector on Windows

I was exploring how to get insight into a piece of JS code running on NodeJS. All the things were there but for some reason the unit tests were not behaving correctly. To debug this using node-inspector seem to be the logical choice but I could not find an easy way avenue to get things started.

I would normally start my unit test pointing nodeunit to a directory using the windows command that becomes available after installing nodeunit via npm globally:

c:\> nodeunit /test

This would run through all the unit tests in the /test directory. I wanted a similar mechanism when I needed to run debugging. Googling things was not very helpful as all the examples I found were OSX or Linux specific. However, the solution in the end was fairly simple.

Here are the steps from the beginning:

a) install node-inspector globally

c:\> npm install -g node-inspector

b) install nodeunit globally

c:\> npm install -g nodeunit

c) locate the nodeunit command file normally somewhere like C:\Users\[logged in user]\AppData\Roaming\npm\nodeunit.cmd. Or you can use the "where" command like so:

c:\> where nodeunit

d) use a text editor like notepad to open the command file

e) change the nodeunit command file by adding the debug flags (--debug-brk) and save as nodeunit-debug.cmd. Here is the content of the fully changed command file:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" "--debug-brk %~dp0\node_modules\nodeunit\bin\nodeunit" %*
) ELSE (
  node --debug-brk "%~dp0\node_modules\nodeunit\bin\nodeunit" %*

You are done with your setup config. Thereafter you only need to use the new debug command when you want to debug test cases.

a) run your tests with new nodeunit-debug command you just created. You should, of course, do so in the directory of your application rather than in the root of the drive. Assuming that all your unit tests are under a /test subdirectory you could do it like so:

c:\[app dir]> nodeunit-debug /test

b) in second command window run node inspector instance and inspect code in browser (Chrome)

c:\> node-inspector

c) open chrome to debug your code (

Here is an image of a,b, and c steps in action:

That is it.


Wednesday, July 15, 2015

JQM: A mini MVC Application Structure using jQuery Mobile and RequireJS

The Rational

When it comes to the power jQuery Mobile (jqm) to help us organize our code we could pretty much say it in one hyphened word: "non-existent".
How could this pass with such a popular library. Well, the simple answer is that it is by design. This does not mean, however, that you should not organize your jqm code projects. You are free to use any JavaScript organizing principle or helper library, e.g. BackBone or Ember, you like. Jqm's  focus is the page paradigm and rendering of touch friendly UI.

This, of course, does mean that you have your work cut out for you to make decisions surrounding your project. Looking at very common pattern of jqm apps, they tend to be an amalgamation of different libraries that have many layers of code and logic that needs to be organized. And, needless to say, there is always seems to be a little bit of overlap in library's coverage, e.g. if you used Backbone for route handling, we will need to turn off the native jqm methodology etc.

In the particular approach I am outlining in this post, the goal was to use minimal amount of libraries while still creating convention based organization of code, ui, and data. We should be able to split our program into distinct parts that the browser can load when needed.
This will help us in following manner:

  1. decoupling of presentation and logic
  2. modular JavaScript code
  3. decoupling of the page paradigm from singular page apps
  4. organization of code by convention

Overall, the maintenance of our program should be easier, while adding new parts becomes child-play ;o)

After a little experimentation, I decided the only thing needed was a little extra JavaScript and the RequireJS library. Let me explain how.

The Setup

Standard application initialization occurs through the index.html page. However, unlike most JS apps there is only one <script> tag and that tag loads RequireJS. Thereafter the application parts are either loaded by RequireJS or JQM page loader. Thus, the script tag jungle is avoided. Clean abstractions of dependencies and libraries are all captured in the RequireJS config file.

Since this is a sample app it makes liberal use of console.log function.

    <script data-main="app/config" src="libs/require.js"></script>        

Also something that is different here is the externalized page header. I did not add an externalized page footer which can be easily done but was not needed for my example. An externalized header can easily be repeated on each subsequently loaded jqm page and thus we can focus on the page content. We will still change the header display dynamically and add proper navigation as we move between pages.

<!-- external header used on all pages we will hide buttons dynamically -->
<header data-theme="b" data-role="header" data-title="Simple App" data-position="fixed">          
    <a id="btnHome" data-rel="back" data-transition="slide" 
       class="ui-btn ui-shadow ui-corner-all ui-icon-arrow-l ui-btn-icon-notext ui-btn-inline" 
       title="move back">back</a> 

    <a href="#info" id="btnInfo" 
       class="ui-btn-right ui-btn ui-btn-inline ui-btn-icon-notext ui-mini ui-corner-all ui-icon-info" 

The Application Structure

The application is structured in such a fashion that a certain convention can be observed.
The main directories under /app are

  • controllers
  • data
  • pages
  • services
  • stores

All code files except the RequireJS config file are in a slightly modified JavaScript AMD Module format.We are also caching jqm views (pages) once they have been loaded using the jqm domCache directive:
$ = true;


This is where we place all controller logic for our views. I maintained a convention where views do not have any logic or binding and minimal links. Controllers are automatically loaded and initialized based on the view (page) that is being requested. The app will check for a similarly named controller and start the process. Thus, all page behavior, event binding, business logic would be handled here.

If the controller exports (or exposes) a function named "init", that function will be called after each page load or display.

The overall convention for the controller loading process and application behavior are coded into start.js module. It acts as the overall controller for the application.

Here is the basic controller construct example.

//controller sample
    function() {

    console.log("empty controller loaded");

    //public (export)
    return  {
        init: function(){
            console.log("init was called")



I have placed a file containing a json array of objects into this file. Thus, we can refer to this as our "database". This is not a convention that is enforced on the code layer. I chose to abstract data in this fashion. It could easily be extended to be the connection layer to a database API etc.


The pages in our app are the view of the MVC model. I chose to use very simple views. These are snippets of HTML just with the JQM markup needed to render a basic skeleton. Logic that changes the view is either in controller or services layer.

Here is an example of a view. It is just the date-role="page" part of the jqm html markup.

<section data-role="page" id="composerDetail" data-title="Composer Detail">
    <div role="main" class="ui-content">

    <h2 id="composerName">Composer Name</h2>

        <!-- composer info -->
        <div class="ui-grid-a ui-responsive" >
            <div class="ui-block-a center" style="width:20%;">                
                <div class="">
                    <img id="composerImage" src="" alt="composer image" style="vertical-align: middle;"> 
            <div class="ui-block-b" style="width:80%; vertical-align: top;">
                <div class="ui-body ui-body-d"><p id="composerDescription">composer information</p></div>

        <!-- buttons -->
       <div class="ui-grid-a center" >
            <div class="ui-block-a" style="width:20%;">
                <div class="ui-body ui-body-d"><a data-rel="back" data-transition="slide" class="ui-btn ui-shadow ui-corner-all ui-icon-arrow-l ui-btn-icon-notext ui-btn-inline" title="Back to composer list">back to list of composers</a></div>
            <div class="ui-block-b" style="width:80%;">
                <div class="ui-body ui-body-d">
                    <button id="btnWiki" class="ui-btn ui-icon-arrow-u-r ui-btn-icon-right ui-corner-all" title="More information on WikiPedia" style="width:80%">WikiPedia</button>


This is where I paced example services that can be used in other modules. In my case just a way to abstract jquery ajax calls and handle generic responses. But, this could be easily expanded to anything that is shareable across the modules or detailed implementation that would be make controllers large and unwieldy. This is not a enforced by code but a convention I am suggesting. It helps to separate heavy logic into distinct modules for maintainability.


I used the stores to abstract interaction with the data layer. For example my sample ComposersDataStore.js in this project can sort the composers, return a specific one etc. This is also not enforced by code, but rather a convention I am proposing for your app build.

The Init Process

After loading of the index.html a list of dominoes begins to fall

  1. Require will load config.js which contains the environment definition and load dependencies. 
  2. config.js will, in turn, load the start.js module which contains our overall application controller
  3. config.js will also switch to the "main" page (view) which will trigger common actions by the overall application controller as defned in start.js
    1. Load the main view (main.htm)
    2. Load the main_controll.js controller
    3. Call the init function of main controller

Thereafter it is up to the user and his/her interactions which pages will be loaded and which actions will be triggered.

Unfortunately there seems to be a bug in the jQuery Mobile page loading (page widget) which makes initialization phase inconsistent. The process is not always kicked of correctly so it required for me to do a check in the index.html itself. If we did not find the main controller module loaded after 5 seconds, we would switch to the main view one more time, which triggers the part 3 and seems to fix things. This loaded the app consistently across all devices.

            if (!require.defined("controllers/main_controll")) {
                console.log("catch all triggered.");
                $( ":mobile-pagecontainer" ).pagecontainer( "change", "app/pages/main.htm", { showLoadMsg: true } );

The Hook

The element that drives the main convention of this app is implemented in the pagecontainerchange  event hook. This event is exposed by jQuery mobile.

$(document ).on( "pagecontainerchange", function() {}

Here we automatically load the appropriate controller based on the id of the view (page) and initialize and call the init() function of the module. In addition, we change display name of the view based on what is in the data-title of the jqm view definition. All this happens in the start.js application controller. 

Of course, in a more opinionated implementation, additional conventions could be coded here; for example, automatic loading of data-stores and even binding of the store's fields to form elements. Thus, the concept can be expanded. Experiment and see if you could add to it.

GitHub baby

The complete project can be reviewed or downloaded from GitHub. I have included the libraries and versions of jQuery and RequireJS so things should be able to work out of the box:

Expanded Project for Download from GitHub