fiveisprime the more you node...

Deploying a Modulus Project From Travis

You'll need the following (or make sure they are up to date):

Log into Modulus CLI then create a token:

$ modulus token create
Welcome to Modulus
You are logged in as fiveisprime
[✓] Token: 4e287c37-2e7d-416f-bf53-dab7d564c262

The Modulus CLI checks for the MODULUS_TOKEN environment variable that is used to run commands without running the login command first. Obviously, you won't want this token to be visible in your .travis.yml configuration file so you'll need to encrypt it using the travis CLI.

$ travis encrypt MODULUS_TOKEN=4e287c37-2e7d-416f-bf53-dab7d564c262

This will output a secure variable -- something like secure: "...". If you already have a .travis.yml file, you can include the --add option to add the variable to your configuration file automatically.

If you don't already have a configuration file, create a file named .travis.yml in the root of your repository and paste in the following:

language: node_js
node_js:
  # Include which versions of node to test against here.
  - '0.10'
env:
  global:
    # Replace the next line with the output from travis.
    - secure: "..."
after_success:
  - npm install -g modulus
  - modulus deploy -p "my project name"

Notice the env:global:secure property which is where you will copy your encrypted token from travis.

This configuration will run the npm test script against node versions 0.8.x and 0.10.x then, if successful, install the Modulus CLI and deploy your application.

Using Make with Node.js

There are some great tools for automating client-side tasks such as Grunt and Gulp, but what if all you want to do is automate the lint and test that is already part of your workflow?

You already use JSHint's command line tool along with mocha and you just want to automate this process to work with a continuous integration service such as codeship or even travis.

Using Make

You can very quickly do this using Make. First, ensure that all of your test tools are installed as dev dependencies. For this example, I'm using JSHint, Mocha, Should, and Istanbul:

npm install jshint mocha should istanbul -D

This will install all of the modules and save them in the devDependencies object of your package.json.

Now create a Makefile that looks about like this:

Be sure to use tabs when creating your Makefile.

The Makefile is simply running the commands listed in the test target and will only execute the Istanbul/mocha tests if the lint passes (if the process exits with 0).

This target will run tests in a directory named spec, if your tests are in a directory named test, you will need to change the -R spec -- \ line to -R test -- \ and uncomment .PHONY: test so that make doesn't try to build your test files directly.

Now you can add the test script to your package.json

"scripts": {
  "test": "make test"
}

Running npm test will run your tests, but even better is that, because Istanbul is being used, you can add the coverage option to generate a code coverage report.

$ npm test
> make test
 ...

$ npm test --coverage
> make test

========================= Coverage summary =========================
Statements   : 100% ( 39/39 )
Branches     : 100% ( 2/2 )
Functions    : 100% ( 16/16 )
Lines        : 100% ( 37/37 )
====================================================================

Your SRC variable may need to be updated depending on the structure of your module.

Thoughts

Make is a quick and easy way to automate the workflow of your node.js module. Linting, running tests, and even generating code coverage reports is super easy - all in less than 10 lines of code. :)

Hanlon's Razor and working with young engineers

Think back to when you were a fresh engineer writing your very first production application. If you were anything like me, you didn't quite appreciate the value of separating concerns because you had never had to maintain somebody else's code. Not only that, but you probably didn't write any unit tests because you didn't know any better.

I'm not afraid to tell you that my first production application was a WinForms project written in C# and the entire application was in a single file. That's right, about 2,000 lines of code in FormMain.cs. Then came the day that I needed to add a feature and I hated the old me for doing this. What an asshole. Why would old me make life so hard?

Now consider Hanlon's Razor which can be summed up in a single sentence:

Never attribute to malice that which is adequately explained by ignorance.

Past me wasn't an asshole, he simply didn't have the experience, knowledge, or foresight to consider the consequences of structuring an application the way he did. It was so easy to be mad at past me rather than appreciating that current me knows better.

Take a moment to appreciate how far you have come in your career - the exercise of looking back works even if you've only been writing code for a week or month. It's quite amazing.

Now consider this when working with a young engineer or with somebody who has different experiences than you. Think about this when they ask a seemingly stupid question and be empathic to their position in their career. Extend the same appreciation to how far they've come because they deserve it as much as you do.