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:


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.



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:


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.


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:


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");}();

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?



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

Try this instead:



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:)



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

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:



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.



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:



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



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.



Instead you probably just wanted this.



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?



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.