ict.ken.be

Delivering solid user friendly software solutions since the dawn of time.

npm 

Categories: Nodejs

https://www.npmjs.com/

  • node -v (higher v0.10.32)
  • npm install npm -g
  • npm -v
  • npm root -g
  • npm bin -g
  • npm set init.author.name "ken"
  • npm set init.license "MIT"
  • npm init --yes
  • npm install <package_name> --save-dev
  • npm outdated
  • npm update
  • dir node_modules/.bin
  • npm run
  • npm run-script test
  • npm run test
  • npm t -s
  • npm start
  • npm stop
  • npm restart
  • npm install mocha chai --save-dev
  • npm version patch
  • npm config set mypkgname:myvar myvalue
  • npm install http-server -g  && http-server .
  • npm install -g nodemon && nodemon app.js

package.json

{
    "name": "one-word-preferred-with-dashes-and-lowercase",
    "version": "1.0.0",
    "description" : "Some blabla",
    "keywords" : [
        "npm",
        "blabla"
    ],
    "author": "Ken Van Gilbergen",
    "license": "MIT",
    "scripts": {
        "lint": "jshint *.js **/*.js",
        "watch:lint": "watch 'npm run lint' .",
        "pretest": "npm run lint",
        "test": "mocha test -u bdd -R spec",
        "posttest": "echo 'after test'",
        "watch:test": "npm run test -- -w -R min",
        "start": "node index.js",
        "stop": "echo \"really"\" && echo \"stop"\"",
        "custom": "echo 'custom'; echo 'run independent of custom'",
        "parallel": "npm run first & npm run linux",
        "parallel": "START /b 'npm run first';START /b 'npm run windows'",
        "vars": "foo $npm_package_config_myvar", 
        "varsOnWindows": "foo %npm_package_config_myvar%" 
    },
    "repository": {
        "type": "git",
        "url": "."
    },
    "engines": {
        "node": "~1.1.1",
        "npm": "~1.1.1"     
    },
    "config": {
        "myvar": "whatever"
    }
}

Wallaby 

Categories: Testing

It's like NCrunch but for javascript.

http://wallabyjs.com/

JS Testing History

  • console
  • browser running tests
  • commandline with test watcher (needs stack copy)
  • resharper running tests (needs reference paths)
  • wallaby coverage and running tests

Wallaby

  • install through extensions
  • add wallaby.json to your solution

wallaby.json

{
  "files": [
    { "pattern" : "test/lib/chai.js", "instrument": false },
    "src/*.js"
    ],
    "tests": [
        "test/*Tests.js",
        "test/*Tests.ts",
        "test/*Tests.coffee"
    ],
    "testFramework": "mocha"
}
  • default test framework is jasmine
  • to exclude from coverage set instrument to false
  • right-click wallaby.json and select start
  • restart wallaby if you update the wallaby.json
  • yellow means partially covered (click to see what part was not processed)
  • screenshot of last runned test in context menu

Wallaby Visual Studio Shortcut Keys

  • Start Wallaby: alt-w alt-1
  • Stop Wallaby: alt-w alt-2
  • Restart Wallaby: alt-w alt-3
  • Run all tests: alt-w alt-4
  • Jump to failing test: alt-w alt-5
  • Context Menu: alt-shift-f10

Advanced

wallaby.js

var babel = require("babel");

module.exports = function (wallaby) {
    return {
        "files": [
            { "pattern": "test/lib/*.js", "instrument": false },
            "src/*.js"
        ],
        "tests": [
            "test/*Tests.js"
        ],
        "delays": {
            edit: 700,
            run: 300
        },
        "debug": true,
        "compilers": {
            "**/*.js": wallaby.compilers.babel  (
                {
                    babel: babel,
                    stage: 0
                }
            )
        },
        "env": {
            type: "node"
        }
    };
}

More

NodeJs 

Categories: Nodejs

Since november 2009 at http://jsconf.com/ europe by Ryan Dahl, because building progress bars into Ruby was just to slow. Written for a data center.

Who is using node

Best tool vs swiss army knife

  • Sharding complexity by separating your code
  • Composition in favor of inheritance
  • Avoid callback hell (http://callbackhell.com/)
  • No nested if-then-else, return early
  • Error-first callback
  • Leverage the ecosystem
  • Develop for the clueless stranger

Error-first callbacks

fs.readFile('/foo.txt', function(err, data) {
    if(err) {
        if(err.fileNotFound) {
            return this.sendErrorMessage('File Does not Exist');
        }
        if(!err.noPermission) {
            return next(err);
        }
    }
    console.log(data);
});

Use async

async.parallel({
    one: function(callback){
        setTimeout(function(){
            callback(null, 1);
        }, 200);
    },
    two: function(callback){
        setTimeout(function(){
            callback(null, 2);
        }, 100);
    }
},
    function(err, results) {
    // results is equal to: {one: 1, two: 2}
});

Testing

  • There are no points for clever tests
  • Test clarity above all else
  • Jasmine all in one testing framework
  • Mocha follows node standard, no mocks, no asserts

Mocha

describe('yourModuleName', function() {
    before(function(){
        // The before() callback gets run before all tests in the suite. Do one-time setup here.
    });
    beforeEach(function(){
        // The beforeEach() callback gets run before each test in the suite.
    });
    it('does x when y', function(){
        // Now... Test!
    });
    after(function() {
        // after() is run after all your tests have completed. Do teardown here.
    });
});

NodeJs Built-In Assertions

assert.equal(life, 42, 'some message');
assert(life === 3, 'some message');

Chai Assertion Library

foo.should.be.a('string');
expect(foo).to.be.a('string');
assert.typeOf(foo, 'string');

Sinon Spies, Stubs and Mocks

var callback = sinon.stub();
callback.withArgs(42).returns(1);

Mockery Require Mocking

before(function() {
    mockery.enable();
    mockery.registerAllowable('async');
    mockery.registerMock('../some-other-module', stubbedModule);
});
after(function() {
    mockery.deregisterAll();
    mockery.disable();
});

Rewire Require DI

var rewire = require("rewire");
var myModule = rewire("../lib/myModule.js");
myModule.__set__("path", "/dev/null");

Modules

Type example (preferred)

var privateStaticVariable = true;

module.exports = User;
function User(n) {
    this._privateVariable = true;
    this.name = n;
}
User.prototype.sayHi = function() {
    console.log('Hi, My name is ' + this.name);
};

var User = require('User');
var alice = new User('Alice');
alice.sayHi(); // "Hi, My name is Alice"

Slower, but real private variable (avoid)

module.exports = User;
function User(n) {
    var privateVariable = true; 
    this.publicVariable = n;     
    this.toggle = function toggle() {
        privateVariable = !privateVariable;
    }
}

Running multiple node versions

Using EcmaScript 2015 (ES6)

Clubbing the seal 

Categories: .Net

"There are those who think that a language should prevent programmers from doing stupid things, and those who think programmers should be allowed to do whatever they want." [Hackers & Painters by Paul Graham]

Cute seal toy on green carpet.

Imagine, you are implementing a DbExecutionStrategy for Entity Framework and you are thinking: Let me inherit this SqlException, so I can create a ThrowTimeOutExpiredSqlException and use this to test my execution strategy... a bit later you realise the class is sealed... bummer... ok let's just use the SqlException class itself and hopefully find the correct properties to make it behave the way I want... bummer again... it seems all the constructors are private... but wait it seems there are some factory methods called CreateException... I am sure that's what I need to use... euh or not since they are marked as internal.

I guess by now you realise I am belonging to the group of developers that thinks programmers should be allowed to do whatever they want.

So why make things so difficult? Why would I want to make things sealed, internal or even non-virtual?

  • Speed optimization
  • Security considerations
  • Ensuring immutables don't become mutables
  • Prevent inheritance fragility

OR...

Because I am to 'lazy' to design the class for inheritance and sealed effectivily says: "The writer of this class did not design this class to be inherited. Nothing less, nothing more."

Of course we need to read lazy as: I am working for a company and I have no time to implement all these other members and think of all the edge cases you might use this class for. Moreover if you inherit my stuff and then it breaks when I change stuff I have to work more and therefor spend more company money... and I think that's the main reason: Maintainability of legacy projects.

And this is also the reason many of the microsoft framework classes are sealed and have internals. Microsoft tries to prevent developers from using things they probably will change or not support in future versions. And if they would allow developers from using them, they would probably break the software when the user does the next windows update. And guess who get's the blame at that moment.

Maybe we should invent an attribute to mark classes with [I_Consider_This_Sealed But_I_Am_Leaving_You_The_Freedom To_Change_It] or some other way to express our intentions. Until then I believe that if you extend a class it's your problem if you break it. Start writing more unit tests.

Anyway, I solved the SqlException thing by using reflection to access the method and I for sure will blame microsoft if they change this method in future EF versions :)

More about seals:

ps: Most of the time I favor composition over inheritance.
ps2: Did you know static classes are actually sealed classes? Maybe that's why I don't like those either...

Page 9 of 43 << < 1 2 3 4 5 6 7 8 9 10 20 40 > >>