BDD Style Test Phrasing… What’s Your Poison?

I’ve had this question come up a few times recently, and I wanted to get everybody’s take on it…  when you write BDD style tests, what practice do you prefer?

…I’ll have a follow up to this poll in a few days and explain some of my own reasoning to the whole situation.

Bashit… Just a Custom Bash Prompt Setup for Git

I use git. I’m honestly shocked when someone doesn’t use git (or at least some DVCS) these days. It just seems somewhat draconian to use any of the legacy source control systems (albeit there are some rare exceptions, like game development graphics collateral). I was reminded of something by the great hands on session that Pamela Ocampo @pmocampo and Rachel @raychatter gave at OS Bridge titled “NerdCred++; How to Customize your Bash Prompt“.

After the session I dug into customizing my bash prompt. After doing a lot of manual editing I ended up just forking and implementing Michael Gonderman’s (@magicmonty) bash-git-prompt. The way to get this installed is pretty simple, albeit it does include a few steps (and yes, the basically has the instructions, but I’ve copied them here just to discuss and for ease of readability). Another key points of reference include Sebastian Celis’s (@scelis) “A zsh prompt for git users” on his blog.

First clone the repo (even though I’ve forked it I still pulled directly from

$ cd ~
$ git clone .bash-git-prompt

To verify that it is cloned ok, source the file from bash. It should immediately dive into a new prompt with a check mark and current directory, with the time immediately under that. Sweet, that worked!

$ source ~/.bash-git-prompt/
✔ ~
10:48 $

Where the check mark is where git changes will display when navigating into a directory path that is a git repository and making changes. The format will look something like (<branch> <branch tracking>|<local status>). The symbols on the prompt, when working with git are as follows:

Bash & Git in Action

Bash & Git in Action

✔: repository clean
●n: there are n staged files
✖n: there are n unmerged files
✚n: there are n changed but unstaged files
…n: there are n untracked files
⚑n: there are n stash entries
↑n: ahead of remote by n commits
↓n: behind remote by n commits
↓m↑n: branches diverged, other by m commits, yours by n commits

The next step is to make this permanent. Open up your ~/.bashrc file (or whichever you use, in my case I’m using ~./bash_profile, so be sure to figure out which one your system is using to actually load your bash). In the bash file add a single line to source the file.

# a bunch of other stuff in the file, whatever it might be... etc., etc.

source ~/.bash-git-prompt/

I’ve added some links below that add additional options to customize your bash prompt (thank Pamela & Rachel). Even though all of this might seem like such a small little thing, having that extra information readily displayed on the prompt can be a huge time saver. Especially if you’re regularly in the code, committing from TDD or BDD practices or even just paired with somebody going through doing a refactor. It can be HUGE time saver, it definitely has for me.

…and thanks to ALL that gave me the motivation & for putting together the presentation and code for the prompt. Props to @scelis@pmocampo@raychatter & the others that have contributed to making bad ass bash prompts!



Pamela & Rachel’s Slide Deck & Additional Information:

Getting in Some Code Stylings, Looking Good for the Code Dance

In every language there are opinions about how to format code. With JavaScript, the community abounds with opinions about how the code should look, how variables are declared, whether there should be semi-colons to end each statement, spaces before or after parenthesis, and more than I care to list in a simply worded paragraph like this. Recently the team at Deconstructed sat down to determine what our ongoing code style format would be and how we can enforce it.

The first thing we did was figure out what we could use for enforcement of the coding style. Milan (@milanloveless) quickly discovered node-jscs per suggestion from Adam Ulvi (@s5fs). He implemented that code as follows.

First install node-jscs.

npm install jscs -g

After installing jscs we added a file called .jscsrc to the main path of the project. In that file we set the following settings for jscs.

  "preset": "jquery",
  "excludeFiles": [

Now let’s talk about the jquery code style preset. We decided to go with the jQuery preset for a couple of specific reasons; naming and spacing. Some of the other styles are interesting but didn’t really matter in the decision making process.

Sublime has a way to add a linter to check for all the code style present but one beauty of WebStorm is that it picks up the .jscsrc file automatically and prompts to turn on a linter to check for the code formatting.

All in all, does code style make that much of a difference? In some ways yes, in some ways no. But it sets a standard to maintain a discipline around the code, a familiarity to the code, and allows one to adapt to reading the code in a particular way.

More on Using the Nools DSL and Engine…

Nools Objects

In the helloworld.nools object there is a single object defined called Message. This object has two elements defined; the text property and the constructor. The specific object definition is shown below.

define Message {
    text : '',
    constructor : function(message){
        this.text = message;

This object can now be referred to by name throughout the nools file. The other way to reference this object is to call the getDefined function from the flow object that is being used in code processing the business rules. In the nools language any javascript has can be put inside the define blog. By defining the constructor as shown, it overrides the default constructor behavior.

Nools Rules

In the nools DSL writing a rule consists of the following format.

rule <name> {
   when {<constraints>}
   then {<action>}

Let’s take a look at some of the example rules from the previous blog entry Learning “nools” Rules Engine and break those down. The first example is the Hello rule.

rule Hello {
    when {
        m : Message m.text =~ /^hello(\s*world)?$/;
    then {
        modify(m, function(){this.text += &quot; goodbye&quot;;});

In this rule when the content starts with the word hello then the rule is set to modify the text of the object to append goodbye. So if I sent a message of ‘hello’ the message would become ‘hello goodbye’. As an example, modify the code in server.js as I’ve done below.

var nools = require ('nools');
var ruleFilePath = __dirname + &quot;/rules/helloworld.nools&quot;;
var flow = nools.compile (ruleFilePath);
var session = flow.getSession ();

var Message = flow.getDefined (&quot;message&quot;);

session.assert (new Message (&quot;hello&quot;));
session.assert (new Message (&quot;hello or goodbye&quot;));
session.assert (new Message (&quot;hello world&quot;));
session.assert (new Message (&quot;goodbye&quot;));


In the code above I’ve added four new message objects to have the rules process against. In each of these the Hello rules would process these four messages and produce output with a call of the match() function. When executing the code to compile and process the nools rules run node server.js command. The output then returns the following.

$ node server.js
hello world goodbye
hello or goodbye
hello goodbye

Each of the messages, even though entered in a particular order, returns the process results of the objects in reverse order. In this case the message ‘hello’ becomes ‘hello world’, ‘hello or goodbye’ remains ‘hello or goodbye’, ‘hello world’ becomes ‘hello world goodbye’ and last ‘goodbye’ is left untouched since it doesn’t start with ‘hello’. The other rule Goodbye, shown below, is also processed for each match.

rule Goodbye {
    when {
        m : Message m.text =~ /.*goodbye$/;
    then {

But since the first rule Hello processes, rule two actually runs every time (since post the Hello rule every message ends with goodbye) and displays the results based on the Goodbye rule.

That covers nools objects and rules. Stay tuned and there will be more on the nools from me in the near future. Cheers!

Learning “nools” Rules Engine

Recently I sat down to work up a solution around a rules engine. There were a few things I noticed right off.

  1. When there is a request to implement or build a rules engine it is very often (I’m guessing a solid 40-60% of the time) reasoned that there is a need solely based on a lack of understanding around what the problem space is that actually needs a solution. The simple assumption, is 40-60% of the time somebody says “let’s implement a rules engine to solve these unknown problems” really translates to “we really don’t know much about this domain so let’s implement something arbitrary as a stop gap”.
  2. Implementing a business rules engine can quickly become a “support the user” scenario for the developers that implement the rules engine. This is a situation in which the developers actually have to help the people writing the rules to be processed. This is not an ideal situation at all, generally developers supporting users writing rules is a quick way to ensure burn out, misappropriation of skills and turnover.
  3. Many developers will, without hesitation, spout out “are you sure you want to implement a rules engine?” and then follow that up with “let’s discuss your actual problem” with that leading to “are you sure you want to implement a rules engine?”. Other developers upon hearing that one will implement a rules engine immediately respond with, “shit, I’m out.”

At this point I realized I had X, Y and Z reason to use it and would just have to persevere with all of the threats that are inclusive of implementing a rules engine. Sometimes one just has to step into the realm of scary and get it done.

So here’s what I dug up. I’m really not sure about the name of this project, as it appears to be some sort of odd usage, so whatever, but it is indeed called nools (github repo). Nools is a business rules engine based on the Rete Algorithm, something that is helpful to read up on when implementing. The main deployment for nools is to a Node.js server, but I’ve read that it is prospectively deployable in most browsers too.

The Browsers That Have Known Support, ya know, if you want to use nools in a broswer.

The Browsers That Have Known Support, ya know, if you want to use nools in a broswer.

There are a few other things that need definitions. So before moving on here are a few key words.

  • rule – A collection of constraints that must be satisfied for in order for a action to occur.
  • action – The code that will execute when a all of a rule’s constraints have been satisfied.
  • fact – An object/item inserted into a session that the rule’s constraints match against.
  • flow – This is container for rules that will be executed, you can think of it as a rule book.
  • session – This is an “instance” of a flow used to match facts. Sessions are obtained from a flow.

Working With the Examples

The first thing I tried to run was a simple little sample of a nools rule file using the DSL. The nools file I named helloworld.nools and put in a directory called rules. The file looked like the example available in the of the nools repo, but I immediately hit a bump.

The nools Rules

define Message {
    text : '',
        constructor : function(message){
        this.text = message;

//find any message that starts with hello
rule Hello {
    when {
        m : Message m.text =~ /^hello(\s*world)?$/;
    then {
        modify(m, function(){this.text += " goodbye";});

//find all messages then end in goodbye
rule Goodbye {
    when {
        m : Message m.text =~ /.*goodbye$/;
    then {

I created a server.js file with a simple bit of code just to see the results.

var nools = require("nools");
var ruleFilePath = __dirname + "rules/helloworld.nools";
var flow = nools.compile();
var Message = flow.getDefined("message");

console.log("Rules executed @ " + ruleFilePath);

I tried running this with a simple node server.js command. The result, unfortunately was just an error dumped into the bash.

16:29 $ node server.js

throw new Error("Name required when compiling nools source");
Error: Name required when compiling nools source
at Object.exports.compile (/Users/adron/Codez/testing-nools/node_modules/nools/lib/index.js:61:15)
at Object.&amp;lt;anonymous&amp;gt; (/Users/adron/Codez/testing-nools/server.js:3:18)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3

Ugh, I suppose some things just don’t work on the first try. Based on that error message I dove into the actual nools code, to line 61 to get some insight into what the error messages actually means. The function the error is actually located in looks like this.

exports.compile = function (file, options, cb) {
    if (extd.isFunction(options)) {
        cb = options;
        options = {};
    } else {
        options = options || {};
        cb = null;
    if (extd.isString(file)) { = || (isNoolsFile(file) ? path.basename(file, path.extname(file)) : null);
        file = parse(file);
    if (! {
        throw new Error("Name required when compiling nools source");
    return  compile.compile(file, options, cb, FlowContainer);

Line 61 is the line that reads throw new Error(“Name required when compiling nools source”);, which I suppose is a bit obvious. I did a little search on the for the word options, which brought up the way to complie a nools rule and how to name it in the function call. I then looked back at my code and realized I’d not passed in the actual file to the compile function! Doh! I made that minor change of

var flow = nools.compile();

to this

var flow = nools.compile(ruleFilePath);

Before running I noticed I’d have one more little path problem and changed this

var ruleFilePath = __dirname + "rules/helloworld.nools";

to this

var ruleFilePath = __dirname + "/rules/helloworld.nools";

Now when I ran node server.js the result displayed as expected.

22:10 $ node server.js
Rules executed @ /Users/adron/Codez/testing-nools/rules/helloworld.nools

At this point the individual parts of this code are in need of explanation. But those explanations will be coming in a subsequent blog post. So keep reading, subscribe, and that post will be coming Sunday (that’s tomorrow) at 8:00am!

Framework: Strongloop’s Loopback

Recently I did a series for New Relic on three frameworks, both for APIs and web apps. I titled it “Evaluating Node.js Frameworks: hapi.js, Restify, and Geddy” and it is available via the New Relic Blog. To check out those frameworks give that blog entry a read, then below I’ve added one more framework to the list, Strongloop’s Loopback.

Strength: Very feature-rich generation of models, data structures and related enterprise-type needs. Solid enterprise-style API framework library.
Weakness: Complexity could be cumbersome unless it is needed. Not an immediate first choice for a startup going after lean and clean.
Great for: Enterprise API Services.

When I dove into StrongLoop, I immediately got the feel that I was using a fairly polished package of software. When installing with ‘sudo npm install -g strongloop’ I could easily see the other packages that are installed. But instead of the normal Node.js display of additional dependencies that are installed, the StrongLoop install displayed a number of additional options with a shiny ASCII logo.

StrongLoop's ASCII art begins.

StrongLoop’s ASCII art begins.

Once the library was installed, I took it for a test drive. The loopback library builds a basic API service with a simple command of ‘yo loopback’.

More ASCII Art!!!!

More ASCII Art!!!!

To build an initial model in the API service, simply run ‘yo loopback:model WidgetStuff’. From here I dove into what was being generated.

Taking a look at the JSON for WidgetStuff, the default generation looks like the code below.

	"name": "WidgetStuff",
	"base": "PersistedModel",
	"properties": {},
	"validations": [],
	"relations": {},
	"acls": [],
	"methods": []

In the JSON, the library has done a good job of leaving hooks for validations, relations, ACLs (Access Control Lists) that all point to an enterprise-grade product.

Moving along to other parts of the standard generated application, I took a look at the server.js file. In that file the code is simple, with comments to explain where to integrate other elements of the application. By default there are other parts of the application that are already in place with a basic minimal functionality. The code file starts off with the basic code as shown.

var loopback = require('loopback');
var boot = require('loopback-boot');

var app = module.exports = loopback();

// Set up the /favicon.ico

// request pre-processing middleware

// -- Add your pre-processing middleware here --

// boot scripts mount components like REST API
boot(app, __dirname);

// -- Mount static files here--
// All static middleware should be registered at the end, as all requests
// passing the static middleware are hitting the file system
// Example:
// app.use(loopback.static(path.resolve(__dirname', '../client')));

// Requests that get this far won't be handled
// by any middleware. Convert them into a 404 error
// that will be handled later down the chain.

// The ultimate error handler.

It’s good to see a starting code base that already has compression, basic error handler, not found handler and related functionality. Toward the end of the file there is the startup code.

app.start = function() {
	// start the web server
	return app.listen(function() {
			console.log('Web server listening at: %s', app.get('url'));

	// start the server if `$ node server.js`
	if (require.main === module) {

This code from start to finish is pretty clean. And with basic functionality for API services already represented, I can start building a working application right from the start.

I found StrongLoop’s Loopback product to be a great starting point to build APIs off of with minimal ties to dependencies. Plus, the user interface provides an excellent way to interact with the generated API endpoints. In short, StrongLoop offers one of the best API-building experiences available on the Node.js platform. This will give you a better idea of what I’m talking about:

The first user interface screen that displays upon navigating to the explorer end point i shown here.

The LoopBack API web user interface. Very Enterprisey.

The LoopBack API web user interface. Very Enterprisey.

A number of endpoints for the WidgetStuffs model that I generated are now available. To interact with the actual endpoint itself, simply click on one to list or expand the operations.

UI Expanded.

UI Expanded.

The real time saver? Having the ability to check out the explorer interface and immediately send data to the APIs without typing in cryptic curl commands.

My Sample Loopback Project:

Troubleshooting Node.js Deploys on Beanstalk – The Express v4 node ./bin/www Switch Up

I’ve gotten a ton of 502 errors and related issues that crop up when deploying the Beanstalk. One of the issues that cropped up a few times recently, until I stumbled into a working solution was the 502 NGINX error. I went digging around and ended up just trying to deploy a default, fresh from the ‘express newAppNameHere’ creation and still got the error.

I went digging through the Beanstalk configuration for the app and found this little tidbit.

Node Command (Click for full size image)

Node Command (Click for full size image)

I’ve pointed out the section where I’ve added the command.

node ./bin/www

Based on the commands that are executed normally, it seems `npm start` would work work to get the application started. But I have surmised the issue is that the commands are executed sequentially;

node server.js
node app.js
npm start

When these are executed in order, errors crop up and the command that should work `npm start` begins with a corrupted and error laden beginning. Leaving the application not running. However by adding the `node ./bin/www` to the text box all the others are skipped and this command is issued, resulting in a running application.

The other thing is to follow the now standard approach of just issue `npm start`, but being sure to replace what I put in the text box above (`node ./bin/www`) with `npm start` so that beanstalk only runs npm start instead of the ordered execution.