jshint is good, but...

Let's just be upfront here because I don't want to hurt peoples feelings on jshint (which is apparently known for hurting people's feelings.) I can say many things about jshint , and 99% of them are good. In fact, there are a LOT of good practices that jshint enforces that I think are absolutely invaluable. Yet, here I am really just annoyed with a bunch of these "Code errors." Let me give you some examples.

1. I'm a NodeJS developer working on a test suite, using SHOULD and MOCHA, and I use jshint to test and make sure I use good coding practices. Here's what happens:

	Expected an assignment or function call and instead saw an expression.
	(x.should.be.a.Function;)
	Expected an assignment or function call and instead saw an expression.
	(x.should.be.a.Function;)
	'require' is not defined.
	'require' is not defined.
	'describe' is not defined.
	'describe' is not defined.
	'it' is not defined.
	'describe' is not defined.
	'it' is not defined.
	'describe' is not defined.
	'it' is not defined.
	'describe' is not defined.
	'it' is not defined.
	'describe' is not defined.
	'it' is not defined.
	'describe' is not defined.
	'it' is not defined.
	'it' is not defined.

view raw gistfile1.txt hosted with ❤ by GitHub

Well SCREW YOU TOO. Look at all these unmeaningful errors. I mean, require is definitely defined. I shouldn't have to deal with the jshint output like this.

2. I'm working on a token reader for the front end.

	while(var token = tokenizer.readToken()){
	}

view raw ObviouslyCanBeReWrittenButWhy.js hosted with ❤ by GitHub

	Expected an identifier and instead saw 'var'.
	Expected ')' to match '(' from line 7 and instead saw 'token'.
	Expected an identifier and instead saw '='.
	Expected an assignment or function call and instead saw an expression.
	Missing semicolon.
	Missing semicolon.
	Expected an identifier and instead saw ')'.
	Expected an assignment or function call and instead saw an expression.
	Missing semicolon.

view raw JSLintOutput hosted with ❤ by GitHub

What happened here? I expected an assignment and a falsy check to occur during a while loop, and I got this lame output. Sure it's scrutiny and you can easily rewrite it to something like this:

	var token;
	while(true){
	token = tokenizer.readToken();
	if(typeof token === "undefined"){
	break;
	}
	}

view raw YouMadeMeRewriteMyCode.js hosted with ❤ by GitHub

The question is "Why?". So some novice developer can come in and see what your code does faster? Chances are this small obscurity will teach the novice developer about javascript and the things you can do with it. Sure it's "cute" and silly, but is it really worth your time to change your coding style like this? Just document it.

	// This loop reads the token and performs a falsy check
	// to assert the token exists before performing the code
	while(var token = tokenizer.readToken()){
	}

view raw Documented.js hosted with ❤ by GitHub

See, that wasn't so hard. I'd rather teach the beginner the "rules" and then break them.

The following example kills me every time:

	switch(true){
	case true:
	case false:
	console.log("this is a test");
	default:
	}

view raw switch.js hosted with ❤ by GitHub

Expected a 'break' statement before 'default'.

What if I wanted it to bleed over into the cases and use spaghetti code? Apparently novice coders are too dumb to spend time and figure it out for themselves. Chances are if your code is more complicated, you wanted another statement anyway. Yet, what if the offending sample is simple? What if the code happens to be easier to write and read with the switch statement? That's a matter of your opinion and really the decision should be left up to you.

(It also told me console was not defined but that's arbitrary.)

Look, just make a decision for yourself and use jshint to let it find your bugs before you do. Just make sure you read the error and make a determination for yourself if it's worth "fixing."

I probably spend more time sifting through 'console' is not defined more often than I would personally like to.

~function(){console.log("Josh");}();

	Expected an assignment or function call and instead saw an expression.
	~function(){console.log("Josh");}();
	'console' is not defined.
	~function(){console.log("Josh");}();

view raw JSHint Output.txt hosted with ❤ by GitHub

Slightly Advanced SQL Aggregation

I hold myself as a programmer first, and a blogger second: so I hope you don't mind if I post a bit on a few SQL techniques I used this week.

Here's today's example:
I need a table of information containing a list of clients with their ID that shows counts by order type: 1,2,3, and OTHER.

Sounds like you should just do multiple select statements for each client right?

	SELECT Client_ID,
	(SELECT COUNT(1) FROM Orders OS WHERE OS.Client_ID = O.Client_ID AND OS.Order_Type = 1) Type_1,
	(SELECT COUNT(1) FROM Orders OS WHERE OS.Client_ID = O.Client_ID AND OS.Order_Type = 2) Type_2,
	(SELECT COUNT(1) FROM Orders OS WHERE OS.Client_ID = O.Client_ID AND OS.Order_Type = 3) Type_3,
	(SELECT COUNT(1) FROM Orders OS WHERE OS.Client_ID = O.Client_ID AND (OS.Order_Type NOT IN (1,2,3) OR OS.Order_Type IS NULL)) Other
	FROM Orders O
	GROUP BY Client_ID

view raw Such_Subquery.wow.sql hosted with ❤ by GitHub

WRONG. This query is very hard to maintain and does at least 4 table scans per client. Yuck.

Try this instead:

	SELECT Client_ID
	COUNT(CASE WHEN Order_Type IN (1) THEN 1 ELSE NULL END) Type_1,
	COUNT(CASE WHEN Order_Type IN (2) THEN 1 ELSE NULL END) Type_2,
	COUNT(CASE WHEN Order_Type IN (3) THEN 1 ELSE NULL END) Type_3,
	COUNT(CASE WHEN Order_Type NOT IN (1,2,3) OR Order_Type IS NULL THEN 1 ELSE NULL END) Other
	FROM Orders
	GROUP BY Client_ID

view raw One_Table_Scan.sql hosted with ❤ by GitHub

Look at that maintainable easy to read code (unless you didn't know you could put a case statement inside of an aggregate function.) Now step up your ante, find the latest Order_Date split out by types using the mentioned technique using the Max function.

(hint, here's the answer:)

	SELECT Client_ID
	MAX(CASE WHEN Order_Type IN (1) THEN Order_Date ELSE NULL END) Type_1,
	MAX(CASE WHEN Order_Type IN (2) THEN Order_Date ELSE NULL END) Type_2,
	MAX(CASE WHEN Order_Type IN (3) THEN Order_Date ELSE NULL END) Type_3,
	MAX(CASE WHEN Order_Type NOT IN (1,2,3) OR Order_Type IS NULL THEN Order_Date ELSE NULL END) Other
	FROM Orders
	GROUP BY Client_ID

view raw Order_Date_One_Table_Scan.sql hosted with ❤ by GitHub

Sure, this is nothing special, but to someone who wants to increase the size of their Developer Toolbox, don't forget about speed and efficiency.

Have fun,
~Josh

Prudent Object Inheritence (that isn't classical)

Don't even think about classes. I'm really just tired of them, and you should be too. Forever we have been chained to classical inheritance (which I admit is faster for compiled languages.) Yet, maybe it's time we broke free from our bonds of definition and un-define ourselves in a meaningful way.

Hello Inheritance

It is prudent that we remember that our world is not defined. No matter how much science we throw at it, no matter how much the book of definitions grows, there will always be unknown. Our code will never be able to match the vastness of our comprehension and definitions. Clearly there is never a way to get around the fact that computers live in a supremely deterministic world. For this reason, every program should be known as art.

The very first definition of art when googling [Definition of Art]:

"the expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power."

We should remember that we actually make a living off of the fact that programmers take something defined and absolute to create something amorphous and functional. Programmers also take requirements and turn them into something displayed on a screen. This alone is remarkable. In the context of art, we are untypical, yet we try to produce works to be appreciated by their physical or tangible power, rather than their beauty or emotional power. (Or maybe you do?)

The Chains of Determinism and Convention over Configuration

	public MyClass : IDisposable {
	public MyClass(){}
	public Dispose(){
	//disposal work
	}
	}

view raw IDisposable.cs hosted with ❤ by GitHub

Given the example, I show you inheritance that actually makes sense. When you inherit a simple interface in C#, things become more generic and happy. Do not confuse this for complicated inheritance chains that convolute your code. Applying an interface to multiple objects makes your code flow better and work with different definitions faster. These specific kinds of contracts are exactly what you need.

It also bodes us well to remember that javascript ascends beyond this need to define. It takes all the deterministic work out of your code. What you are stuck with are the conventions you use to define your work, and the configurations you provide to your client.

Why not instead of classes, think of your javascript code like you would a composer? The composer cares not about determinism. In fact, some composers would say their work leads them to the solution. The composer applies musical conventions and not configurations to define their pieces. In fact, most configurations are left up to the conductor who interprets the pieces created by the composer.

Even if you can define the notes used to compose a piece, it makes sense that those notes would mean something so much more!

What does this mean for you?

You are not a composer, (or maybe you are,) and thus, should act accordingly. Instead of relying on supreme indeterminism, rely on some convention in your code. Convention will make your code faster and smaller. Of course, definitely do type checking, but be willing to be flexible where you do it. Wherever your API interfaces with a developer, be flexible enough to call Object.prototype.toString.call(object) and really see what is going on. You may be accepting the input of another library (hopefully with the right conventions) but in complete honesty, you never know what you are going to get.

So throw in the towel, right?

HECK NO.

You should instead, play into javascript like you mean it.

Have the courage to do something like this:

	var objectDef = {
	proto:{
	funcs: function(){
	console.log("funcs is called!");
	}
	},
	defaults: {
	name: "John Johnson"
	},
	createObject: function (){
	var obj = _.mixIn(Object.create(this.proto), this.defaults);
	Object.defineProperty(obj, "type", {
	get: function(){
	return "customObjectType";
	},
	set: function(){}
	});
	return obj;
	}
	}
	var myObj = createObject():
	myObj.type;
	//"customObjectType"
	myObj.funcs();
	//"funcs is called!"

view raw SleazyTypeChecking.js hosted with ❤ by GitHub

Yeah. I totally went there.

The only adjustment you need to work with javascript is your attitude towards it. Javascript cannot be deterministic. So embrace it's functions and super generic objects, and enjoy your smaller (and somehow faster) code base.

You won't regret it.

Lastly, here is a sample of the stuff you can do with a very small (2kb minified) library that I wrote by hand.

	~function(){//self invoking closure
	//you can ignore this function declaration if you are not using requirejs
	require(["Composer"], function(Composer){
	var events = Composer.piece().phrase(function(){//compose a piece
	var self = this;//clunky terrible x = this syntax;
	var events = {};
	Composer.remix(self, {//add some private methods
	on: function on(nameSpace, func){
	(events[nameSpace]=events[nameSpace]||[]).push(func);//add a function to the array
	return self;//chain!
	},
	trigger: function trigger(nameSpace){
	var args = [].slice.call(arguments, 1);
	(events[nameSpace]||[]).forEach(function(func){
	func.apply(self, args);
	});
	return self;//chain!
	}
	});
	});
	//another piece
	var getset = Composer.piece().phrase(function(){
	var obj = {};
	//add public get and set methods
	Composer.mixin(this, {
	"get": function get(item){
	return obj[item];
	},
	"set": function set(item, val){
	obj[item] = val;
	if(typeof self.trigger === "function"){
	self.trigger("set:"+item, val);
	}
	}
	});
	});
	//created with as little bloat as possible
	var myNewObject = Composer.symphony(events, getset);
	myNewObject.on("set:width". function(){
	console.log("hello world!");
	}).set("width", 50);
	//"hello world!"
	});
	}()

view raw Composer-Example.js hosted with ❤ by GitHub

This is the way object coding should be (minus the pyramid syntax that plagues the gist's version of callback hell.)

You define repeatable closures and mixin objects. Suddenly, you have a repeatable way to generate objects. Just don't forget that those pieces can be called directly like this:

	var e = events();
	e.on("x", function(){
	});
	e.trigger("x");
	var z = getset();
	z.get("y");
	//undefined
	z.set("y", "duh");
	z.get("y");
	//"duh"

view raw finalExample.js hosted with ❤ by GitHub

Want to actually use it in your project? The command is simple (for node anyway:)

npm install --save composer.js

view raw gistfile1.txt hosted with ❤ by GitHub

In functional health,
~function Josh(){}()

Classical Inheritance is dead and what you can do about it

There is nothing new in this blog post, but all of this is worth mentioning to everyone repeatedly. If javascript was meant to have classes, it would have had them in the first place. Instead we are stuck with the following clunky syntax and keywords to do type checking.

	function classType(name){
	this.name = name;
	}
	classType.prototype = {
	//methods here
	getName: function(){
	return this.name;
	}
	};
	//or if you want inheritence...
	function classType(name){
	otherClass.call(this, name);
	this.name = name;
	}
	classType.prototype = Object.create(otherClass.prototype);
	//underscore.js
	_.mixIn(classType.prototype, {
	//methods here...
	getName: function(){
	return this.name;
	}
	});
	//then you have to instantiate it
	var myobj = new classType("John");
	myobj.getName();
	//"John"
	Object.prototype.toString.call(myobj);
	//[object classType]
	classType.prototype.isPrototypeOf(myobj);
	//true

view raw lame.js hosted with ❤ by GitHub

Instead you probably just wanted this.

	var myobj = {
	name: "John",
	getName: function getName(){
	return this.name;
	}
	}

view raw easy peasy.js hosted with ❤ by GitHub

Look at how simple that is! It's so much faster. Even to a beginner programmer, the hint that this.name may actually be the name property of the object literal.

Need to do instanceOf? Why not do something like this instead?

	var x = {
	getName: function(){
	return this.name
	}
	};
	var y = Object.create(x);
	_.mixIn(y, {
	name: "John"
	});
	x.isPrototypeOf(y);
	//true
	y.getName();
	//"John"

view raw instance hosted with ❤ by GitHub

Seriously! There's so much less code. In fact, why not just  forget the whole "new" paradigm? Well, maybe not forget, but use it wisely. It also begs the question, how do you make objects repeatedly? Don't you need some kind of overhead? What about applying prototypes to already created objects? Or worse. What about multiple linear inheritance?

Your goal when making applications is get the banana. Not the gorilla, not the jungle, and not everything else. See the following video.

Perhaps it might be overstated that using stampit is quite useful. It is also very close at getting the banana. At 10kb I found that stampit was the correct solution on the back end where we control  the modules. Size doesn't matter on the back end. On the front end, it might be more like a fruit salad to a mobile phone. I also have nothing but respect for Eric's library, because it really showcases the fundamental units of object creation.

Could you perhaps have wanted something smaller? (Yeah it's a pretty shameless plug.)

After all, passing callbacks should be really terse.

We should always remember the few components that comprise our objects and functions: Properties, values, closures, functions, prototypes, and contexts.

Edit:
Don't forget to check out the npm registry for my library composer.js.