2013.03.05

Mout & Modularity

Discussions about modularity are recurrent. Some people say that each function should be a separate module/file/package; others say that methods should be contained by a package and grouped by similarity/concerns; and there is still a 3rd group that thinks that a single namespace is the way to go. I will try to explain the design decisions that influenced the creation and current structure of moutjs and why single function packages are not always the best solution.

Read more…


2012.12.10

Travis CI : Continuous Integration Made Easy

This weekend I spent some time improving the structure of some of my open source projects repositories and also finally decided to add a Travis-ci hook to the most active/newest ones.

Travis is a free continuous integration server for open source projects that can be used to automate tests and help you deal with projects that have multiple contributors. If you are familiar with GitHub you probably seen their build status icons on a few projects before (on the image above). It can be used to test multiple languages like JavaScript, PHP, Python, Ruby, Java and many others. It also have options to notify the project maintainers every time the build status changes or on each commit. (email, IRC, campfire, etc)

It is really easy to setup it if your tests are already executed on the command line. If the tests needs a browser to work you can hook a headless browser like PhantomJS. - For my projects I’m just executing the tests on node.js for now since that should be enough to catch most errors. - Having a headless browser can help to double check if the code works on multiple environments.

Travis documentation is very clear and the amount of boilerplate is minimal, for a regular node.js project you just need a file named .travis.yml on the root folder containing:

 language: node_js
 node_js: 0.8

Read more…


2012.11.09

Avoiding the this keyword on jQuery related code

jQuery implements some nice abstractions for DOM manipulation and browser events, removing a lot of crossbrowser issues and making it easier to accomplish non-trivial tasks. - it also has drawbacks and some poor design decisions, but I will leave that for another post. Maybe one day I will write my jQuery 2.0 wishlist… - Today I will explain why I usually avoid using the magic this keyword inside event handlers and inside most methods that manipulates jQuery collections.

Read more…


2012.10.29

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…


2012.09.12

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…