Added UMD version to NPM Module

I added a browser consumable version of my amazing (to me at least) random-character-name module. Now you can just include the cdn version and you are good to go. It was pretty easy really. I just needed to add a few build scripts to package.json. I installed webpack as a dev dependency and put in the following two scripts:

"build:umd": "webpack --output-filename index.umd.js",
"build:umd.min": "webpack --output-filename index.umd.min.js -p",

You can use it over at or for the minified version head to

Happy random name generating!

My first NPM Module

I finally got around to publishing an NPM module (Thank you Kent C Dodds!) It is pretty simple, but it  solves a problem I have had as a writer. Names! It let’s a user generate a name, an array of names with a given length, a massive list of names or a name with specific Initials.

Simply run the following.

npm i random-character-name

and you are good to go! Head to npm or github if you want to contribute!

The method list() will return a list of all random names that were generated. The method single() will return a single random name. The method startsWithLetter(f,m,l) will let you set the initials. The method numberOfNames(number) will return the requested number of names.

var rndNameGen = require(random-character-name);
//generates a large array of names 
  [‘Em Andre Vento’,
  ‘Marsiella Lester Drisko’,
  ‘Lou Charley Hoang’,
  ‘Bettye Ransell Cristabel’,
  ‘Shawnee Timothee Rigby’,
  ‘Roch Wilbur Ithnan’,
  ‘Shanta Wheeler Milicent’,
  ‘Janela Wally Marlowe’ ]
//generates a string with a random name 
//ex. ‘Donnie Reinhard Levin’ 
//generates a string with a name with requested initials 
//ex. ‘Ajay Christophorus Elset’ 
//generates an array with the number of names requested. 
[ ‘Nedi Burt Lexine’,
  ‘Cairistiona Jacobo Merl’,
  ‘Annaliese Bartolomeo Cherian’ ]

Super Useful!

If you are doing a fresh install jump to step three! It will save you the hassle of doing it later. I had to do this to make my travisCI much easier to deal with on different machines.

  1. Find the path to npm’s directory:
     npm config get prefix

    For many systems, this will be /usr/local.

    WARNING: If the displayed path is just /usr, switch to Option 2 or you will mess up your permissions.

  2. Change the owner of npm’s directories to the name of the current user (your username!):
     sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}

    This changes the permissions of the sub-folders used by npm and some other tools (lib/node_modules, bin, and share).

This worked for me but there are other options. On the npm docs site.


It is just Numbers and Dots, right?

I just released a new version of software. I called it 1.0.0. Why did I do that? Really it was because that is just what I do. When I make a very tiny change I adjust the last number up. When I have enough tiny changes that I can bundle them up I adjust the middle number and when I have a significant number of those changes I adjust the first number.

Is this right? No, no it is not. So it’s time to figure this out. Let me go to the source:



Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

This makes way more sense. When you make incompatible API changes the major version must change, otherwise it is just extending the current versions functionality (still backwards-compatible) and finally if you are making changes, that don’t add functionality but fix originally intended functionality while maintaining the same backwards-compatibility it is a patch.

Why should I care? Do you want to live in dependency hell? I thought not. The more complicated software gets, the more likely conflicts occur among dependencies and interdependencies.  How do we avoid this? By making sure that when we write a library with a public API we show how it’s used and how it will not be used. Once these restrictions change we know we have to think about bumping up the major version. Those who want to keep their code working can stick with the working major version until they have reviewed potential impact and decide to upgrade or not.

It is not overly complicated, but I highly suggest reading the full spec to become fully enlightened. versioning


5 Myths About Javascript

1. JavaScript is ECMAScript.

ActionScript and JScript are other languages that implement the ECMAScript.  JavaScript was submitted to ECMA for standardization but due to trademark issues with the name Javascript the standard became called ECMAScript. Every browser has a JavaScript interpreter.

2. JavaScript just for the front end.

With the advent of nodejs and io.js (and others) this is no longer true. JavaScript can now be used to build full fledged RESTful and socket based API’s. Take a look at and hapi.js for two (of many) API libraries.

3. JavaScript is simple.

There was a period of time that JavaScript was for front end DOM manipulation and that was about it. Over time the language has matured into a wonderful and powerful functional programming language that can emulate multiple types of inheritance paradigms.

4. JavaScript is not scalable

If this were the case we would not see companies like Google and Facebook spending so much time using it. These guys know scalable and almost everything you use on both of those sites rely on the fact that it is scalable, modular and extensible.

5. JavaScript is boring

No way! You can do so much with it that boring should never enter your mind. Even if you think you have mastered the language, if you explore a bit more you will find the weird stuff left over to maintain backwards compatibility. Check out for more.