07 Jan 2014
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:
# Include which versions of node to test against here.
# Replace the next line with the output from travis.
- secure: "..."
- npm install -g modulus
- modulus deploy -p "my project name"
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
02 Jan 2014
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.
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
object of your
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
This target will run tests in a directory named
spec, if your tests are in a
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
"test": "make test"
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
$ 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 )
SRC variable may need to be updated depending on the structure of your
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. :)
27 Jul 2013
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