Monthly Archives: August 2016

John Michelin 3:44 pm on August 31, 2016
Tags: , , , umd, webpack   

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 https://npmcdn.com/random-character-name@1.6.0/dist/index.umd.js or for the minified version head to  https://npmcdn.com/random-character-name@1.6.0/dist/index.umd.min.js.

Happy random name generating!

John Michelin 7:02 pm on August 22, 2016
Tags: , , , ,   

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!

Methods

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.

Examples

var rndNameGen = require(‘random-character-name‘);
 
rndNameGen.list();
//generates a large array of names 
/* 
ex.
  [‘Em Andre Vento’,
  ‘Marsiella Lester Drisko’,
  ‘Lou Charley Hoang’,
  ‘Bettye Ransell Cristabel’,
  …
  ‘Shawnee Timothee Rigby’,
  ‘Roch Wilbur Ithnan’,
  ‘Shanta Wheeler Milicent’,
  ‘Janela Wally Marlowe’ ]
 
*/
 
rndNameGen.single(); 
//generates a string with a random name 
//ex. ‘Donnie Reinhard Levin’ 
 
rndNameGen.startsWithLetter(‘A‘,‘C‘,‘E‘);
//generates a string with a name with requested initials 
//ex. ‘Ajay Christophorus Elset’ 
 
rndNameGen.numberOfNames(3)
//generates an array with the number of names requested. 
/*
ex.
[ ‘Nedi Burt Lexine’,
  ‘Cairistiona Jacobo Merl’,
  ‘Annaliese Bartolomeo Cherian’ ]
*/
John Michelin 2:45 pm on August 5, 2016
Tags: bash, , sudo, travisCI,   

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.

John Michelin 5:15 pm on August 2, 2016
Tags: , , , semantic versioning, semver   

Sem.Ver.Blog

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:

(from http://semver.org/)

Summary

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