Node.js Protip: Avoid Global Test Runners

Some of the most popular Node.js test frameworks advertise that they should be installed globally: Jasmine, Mocha, Buster.js, etc… I consider this an anti-pattern.

On this post I will try to explain why it’s an anti-pattern and show how to avoid global installs by using npm test instead.

Read more…


Namespaces are Old School

Let’s start with an overly simplified/generalized and mostly wrong history of the JS community during the past decade.

Let’s go back in time 12 years, to the distant year of 2000. JavaScript is being mostly used for form field validation, analog clocks and mouse trails. Nobody really cared about namespace cluttering, all the code resided on the global scope. This is considered the dark age of JS.

Now let’s fast forward 5 years, to the the first stage of the JavaScript Renaissance (2005-2007); libraries like jQuery, Mootools and Prototype.js are getting extremely popular, AJAX is the buzzword of the moment. Augmenting native prototypes was a very common practice and no caution was taken into consideration, the rule of thumb was easy development and brevity. Larger projects started being developed by more people and best practices started to appear. Sometime around this period closures became a popular way of hiding information and IIFE became the De facto standard. Namespaces also became really popular.

Now back to 2012. Everybody knows that augmenting built-in native objects is a bad thing, specially host objects. Polluting the global namespace is also considered a bad practice and many people avoid it as much as possible. It is not uncommon to see people adding their own application code into objects that they don’t own, proving that they don’t really understand why they shouldn’t have globals to begin with, but at least we are moving towards the right direction. <rant>Polluting any namespace is a BAD thing, not only the global scope, you should NOT put your application code into the $ object…</rant> Script loaders and package managers are becoming more popular each day, node.js is the buzzword of the moment and Harmony might become a reality and provide a native module format.

OK, no more history… Let’s see some code.

Read more…


Node.js, Ant, Grunt and other build tools

I started using node.js to write build scripts since last year and even wrote a post about it before. The main reason why I decided to write my build scripts in plain JS is because I want them to be flexible and easy to edit. (Use the language you and your team are familiar with).

On this post I will try to cover some issues and the main reason why I’m not using a tool like grunt, buildr.npm, smoosh and gear on my projects. I’ll focus on Grunt since it is the most popular node.js build tool out there but the issues are present on other build tools as well (written in JS or not).

A couple days ago I sent a few tweets about it:

TL;DR; Build scripts should be real scripts and not configuration files.

Read more…


AMD-Utils: Math Utilities

This post was going to be about the Math utilities present on AMD-Utils. Some of them are essential to my day-to-day work and simplify the code structure a lot.

I was going to explain how to use them (which is very easy) but most importantly, why they are useful and when to use them. But instead of publishing it as a post I decided to update the docs and add all the info there so everything is centralized.

I recommend that you try to understand these methods and which kind of problems they try to solve. They are all very trivial to implement but of an extreme usefulness depending on the kind of project you are building. I also think that some of them changed the way I approach some kinds of problems. I use them so much that it’s hard to imagine coding something complex without something similar (I coded the methods clamp/loop/lerp/norm a million times).

So jump over to the docs and understand how to (ab)use these helpers. Even if you are not using amd-utils you can check the source code and implement it by yourself or extract the methods. Most of them are common knowledge but I feel that not that many people know how to use them properly or outside of the regular context, that’s why I thought some explanation would be helpful.

Docs: http://millermedeiros.github.com/amd-utils/math.html


Keep your modules and functions small

This post is about a very simple thing that I’ve been doing since I started to code (by coincidence) and that I feel that increases a lot the readability and organization of my code. Some people may not agree with it but for me it makes total sense and was also documented by some experienced developers like Uncle Bob on his great book Clean Code. I tend to think that a single approach may not be the best one for everybody - since every person thinks on a different way - but I’m pretty confident that this advise will be good to a lot of people and that it will increase the overall quality of the code.

The rule is simple, split larger functions/classes into smaller specialized ones, period. It will not only increase the readability but it will also make the code more reusable since it will be easier to override the default behavior if needed (especially if extending a class or reusing a 3rd party lib). I will try to explain how and give a basic example.

Read more…