I have long preferred Bash over Zsh for one simple reason. Speed. Zsh, with all its awesome features is just the tiniest amount slower than Bash. And with some good dotfiles, you can pimp out your bash to work great. I have used Paul Irish’s dotfiles for my Mac for the last couple of years.

Paul Irish has dotfiles that are tailor-made for a mac. Apart from the obvious goodies like syntax highlight, z jumps, and the obvious aliases, they also include script files to install common packages, and some seriously funny aliases, and useful little functions.

Two of my favourites:

• please : a much better alternative to using sudo
• c : a super awesome cat replacement with syntax highlighting

But one feature pushed me over the edge — autosuggestions. Here’s a demo:

If there is one thing faster than quick keyboard shortcuts, its not typing at all. Once I saw this, I had to have it. I...

Sublime Text is hands-down the most popular text editor among web developers. Arguably, it’s also the best. The Vim and Emacs aficionados will argue that once you master their editor of choice, your productivity goes through the roof compared to GUI text editors. I argue that while Vim and Emacs have steep learning curves and take weeks if not months or years to master, Sublime is easy to learn and you can get running within days. Moreover, with awesome plugins, endless and customizable keyboard shortcuts, you can get as productive, if not more as you would with vim and emacs. Not to start a flame war, but it’s true. (Yes, Sublime text supports the regex based find and replace etc.)

At any rate, there are definitely similarities between Sublime Text and other text editors. First and foremost, you need to set it up to make it awesome. Here are a set of steps to get there.

Step 1 -

My introduction to javascript began, like many other people, with jQuery. For a while, javascript and the DOM seemed like the same thing. Later, as I learnt what javascript really was, I started to use and appreciate tools such as Underscore.

Soon, I discovered Lazy.js which seemed like a much better way to do things. Still, Underscore, Low-Dash and Lazy were essentially tools for dealing with existing collections. The Range Class from Ruby seemed like a breadth of fresh air in comparison.

Wouldn’t it be better if instead of storing actual values in a collection, we could just store a formula (or function) that could generate those values. Wouldn’t it be even better if we didn’t have to have a limit on the number elements we could generate.

Using my new love, Generators, I tried to solve the problem of dealing with infinite sequences with a library I call Grunge.js

Grunge.js is part...

My new found love for promises is well documented on this very blog. Once you start using promises, it’s hard to go back. It is also very easy to forget the challenges in understanding promises in the first place.

I recently came across this article that talked about how node should have been built on top of promises to begin with, and how they missed a huge opportunity by going with callbacks.

Now, while I love the promises, considering the sort of steep learning curve, I still see value in callbacks and libraries like Async.

One of the places where I find Promises to be extremely limiting is when dealing with events. Promises can only be resolved once. They become useless for dealing with streams and events. (The progress event can be used here, but it’s an optional part of the Promises/A+ spec, and many libraries don’t even implement it)

On the flip side, it is kind of a bummer...

fs.readFile("myFile.txt", function(err, fileContents){
  if(!!err) {
    throw Error(err)
    return;
  }
  myConvertFile(fileContents, function(err, newContents){
    if(!!err){
      throw Error(err);
      return;
    }
    fs.writeFile('myNewFile.txt', newFileContents, function(err, saved){
      if(!!err){
        throw Error(err);
        return;
      }
      console.log("YAY! SAVED FILE!");
    }
  }
});

Don’t write your code like that.

Just don’t.

Node.js is fairly new, but javascript developers have been dealing with Callback Hell for more than a millennia now. Learning from history and after traversing the far reaches of the inter-webs I have looked for the many ways to deal with the pyramid of doom. Here are my findings:

Past Tense : Named Functions

Javascript lets you have many anonymous functions. They can be immensely powerful. But, even more importantly, it lets...

People new to Javascript get tripped up by it’s ‘strange’ Event Loop. It may feel like that Javascript is inconsistent, slow and inefficient. SetTimeouts, take a time, but animations based on SetTimeouts can be unreliable, and it doesn’t have predictable time.

What gives?

Well, it is well understood with the idea of a giant infinite loop wrapping your entire javascript program. It goes down executing each statement and expression in your code. Anything wrapped in a setTimeout is skipped however, and marked to be executed ‘later’.

setTimeout(<some function>,1000);

I use an ambiguous word like ‘later’ on purpose. Even though we put in 1000 milliseconds, the function may not be executed exactly 1000 milliseconds later. But it will take at least 1000 milliseconds for it to start executing. The idea is that the javascript event loop checks back after every iteration, and if the given...

If you’re a javascript developer, you’ve probably used underscore (or lo-dash). Underscore is an amazing library that really helps keep your code functional, and provides a whole bunch of simple methods to keep your code ‘for-loop-free’.

Underscore can really help keep your code terse, and minimal. However, sometimes, it can be wasteful in terms of CPU cycles. In other words, it could be faster.

There are a few ways that code can be made faster while solving a problem:

1. Using a faster algorithm.
2. Improving the code that implements your algorithm.

But there is another way to make your code faster that many people seem to overlook. (usually rightly so):

• Only solving a subset of the original problem.

That, in a few short words, is what I think is the philosophy of Lazy.js. ‘Be lazy, and do as little work as possible.

Take this for an example. Let’s say you want to pass an array and...

In my previous post, I talked about how you could use Object.create() (or Object.defineProperty()) to supercharge your javascript object with unwritable properties. In this post, I’ll talk about what else is possible with Objects in ES 6.

Firstly, I would like to put it out there, that just as ‘write’ can take a boolean value for an object keys, there are are ‘read’ (does what it says) and ‘configure’ (that enables and disables further behaviour modification) properties as well.

But what can be even more exciting that setting read-only values on objects? It’s getters and setters. Many other languages have had them for objects, and javascript is finally getting it’s native implementation. I would love to tell you that everything is great in javascript land, but that would be a lie. On the surface, getters and setters seem to be a great idea, but once you actually look at them, they are...

Javascript’s approach to objects can be quite daunting. There are a few ways to achieve the goal of making an object factory. In general, though, it comes down to two ways.

1: Factory Function

var makeObject = function(){
  var obj = {};
  obj.prop = "object name";
  return obj;
}

This is probably the most explicit way of creating an object constructor or the closest thing to a class in a javascript. (The Pseudo-classical way is another but we’re not talking about that here.)

The interesting part comes when you want to add a prototype to this object. The code turns to something like this:

var makeObject = function(){
  var obj = Object.create(prototype); //pass in the prototype object
  obj.prop = "object name";
  return obj;
}

(If you don’t know about prototypes, you should read about that here. The interesting part is the optional, second argument of Object.create. Head over to...

Sails.js is a great framework that is easy to learn, well-documented and getting a lot of traction in the market. Sails.js is based on Ruby on Rails and follows its philosophy of convention over configuration. There is a lot of magic and things just work. That said, the magic seems to make more sense here than in Rails, and it usually doesn’t surprise you. (That’s a good thing.)

The problem is that with convention over configuration philosophy comes the assumption that most people will stick to defaults. As a result, straying from the expected defaults can land you in a lot unchartered territory with little community help and almost no documentation.

In my recent project, Scribbler I strayed from the conventional Sails.js path on multiple occasions and after much strife, I emerged victorious. Here’s my story.

Easy beginnings

Right off the bat, Sails is super easy to work with, as is...