fiveisprime the more you node...

growing up in an open source world

A recent twitter conversation led me to a very different place than I expected. It all started with this tweet

First, a history lesson. My software career began in enterprise, the kind of place where your first week or so includes poring over style guides and best practices for the code base which you will be expected to follow. This is the world where failure to follow said guides means that your code is not high enough “quality” (that’s in quotes because it’s bullshit) to be pulled into the trunk.

Since leaving that world, I’ve spent time researching the Dreyfus model of skill acquisition which taught me that the novice needs rules to be productive while the expert works more on intuition where rules will impede productivity. With that in mind, it makes sense to have some kind of style guide for the junior developers.

I’ve been living a lie

I’ve been working with junior developers for many years in both the enterprise world and at Modulus and part of working with them is helping them become “great” engineers. In the past, that meant that they learn about coding style, patterns, and architecting solutions to problems, but there was always this strange emphasis on style that I picked up in enterprise.

The conversation from today made me realize that what I’m actually doing is limiting both their creativity and their flexibility.

So what does this have to do with open source?

One of the best parts of the Node and JavaScript ecosystem is the openness. The ability and encouragement to contribute to what we are all using is the primary reason for the growth and adoption of Node. This message sums up how this relates to open source

It's true. I've run into it myself with "damn, this project uses 4 space tabs, gross" which is an incredibly detrimental (and shitty in general) attitude to have. Why would anybody ever want to pass that on to others?

Also included in the thread was this link to Asbjorn Enge's JavaScript style guide which, as it turns out, is perfect for both personal and professional growth.

Moving forward

Let's focus on growing as engineers and shipping software by creating healthy engineering environments. "Burn the style guide" so to speak and let people be people and learn what works best for them in what situations. Teach flexibility and how to be a good open source contributor.

P.S. I'm writing this down so that I stick to it and thanks CJ et al. for helping me get here.

Npm Tips

Here are some quick tips to help you be more productive with npm.

npm outdated

Use this to see any module dependencies that are out of date. This can get kind of ugly though so specify the depth to see only your outdated dependencies.

$ npm outdated --depth 0

npm link

The link command creates a symbolic link to a module on your machine. Use this to easily consume modules that you are working on. You can also link a global module to your path when working on a command line module.

To use a local module, change to the directory of your project and run

$ npm link /path/to/module

You will then have access to that module from your project.

npm version

Use npm version to update the version of your module. This will update the package.json version for the module and commit the change.

$ npm version 0.1.1

.npmignore

Use this ignore file to prevent your test sources from being published along with your module. This works the same way as .gitignore.

# do not publish unnecessary files:
.travis.yml
.jshintrc
Makefile
spec
coverage

Shortcuts

npm has some helpful shortcuts to make your life easier, here are some common ones.

$ npm i <module>      # short for npm install
$ npm i <module> -S   # short for npm install --save
$ npm i <module> -D   # short for npm install --save-dev
$ npm i <module> -g   # short for npm install --global
$ npm r <module>      # short for npm uninstall

JSHint with Make

I talked about using make with node, but this is specific to the JSHint configuration/target for make.

.jshintrc

One of my favorite things about JSHint is how easy it is to configure the rules. I have an rc file that I typically use (this changes a little when I'm mixing client and server JavaScript).

This goes in the root of the directory alongside the Makefile.

This has the laxcomma and expr relaxing options turned on because I'm that kind of person. Also included are the globals for Mocha.

reporter

The default JSHint reporter is lacking. Mostly in the fact that, if the lint succeeds, there is not output, but also because it's just plain ugly and not too easy to read. Fortunately, our friend Sindre solved this problem with JSHint-Stylish which formats errors in a much better way and also lets you know when the lint succeeded.

Makefile

The actual lint target in make

lint: $(SRC)
  @node_modules/.bin/jshint \
  --reporter node_modules/jshint-stylish/stylish.js \
  $^

This relies on all of the source files being declared in a variable named SRC. I like to do this just to make sure that the target is clean and pretty. You can use $(wilcard dir/*.js) to ensure that all files in a directory are included in the lint.

There is no need to specify the rc file because JSHint checks the current working directory for a .jshintrc to use.