Saturday, January 24, 2015

JavaScript Currying

Generic currying in JavaScript is so great but it takes time to understand the code. Closures!

'use strict';

// subCurry(fn, 1)(2, 3)
var subCurry = function (fn /* Multiple arguments possible */) {
  var args = [], 1); // Dont take the first argument
  return function () {
    var thisArgs =;
    return fn.apply(this, args.concat(thisArgs));

// curry(fn)(1)(2)(3)
var curry = function (fn, length) {
  // Length will only be available after the first curry
  length = length || fn.length;
  return function () {
    if (arguments.length < length) {
      var thisArgs =;
      var combined = [fn].concat(thisArgs);

      return curry(subCurry.apply(this, combined), length - arguments.length);
    } else {
      // All arguments ok
      return fn.apply(this, arguments);

var fn = function(x, y, z) { return x+y+z; }

var mFn = curry(fn);

Monday, November 17, 2014

Recent Reads

From the book "The Senior Software Engineer" from David Bryant

I had a code review once where the reviewer took issue with a stylistic decision that I had made. It had nothing to do with the underlying change or the correctness of the system. It was a classic "agree to disagree" situation and, as I was the maintainer of the code base, I kept the change the way I had done it. He complained to my boss, who then directed me to change it. NOT COOL.
You may encounter a similar situation when having your code reviewed. You may find that the reviewer is insistent that you do things "their way". This is a difficult situation, especially if the other developer is either senior to you or experienced
The first thing you do in this situation is re-think the change. Ask yourself if the reviewer has a point and if there really is something substantially wrong about the code in question. Chances are, the reviewer is right.
If you are not convinced of this, ask the reviewer to explain in more technical terms why you should make the change they are suggesting. Explain that you don't see anything substantially wrong and that, as the code's maintainer, you feel your style should be given more weight. This might either defuse the situation or lead to a deeper discussion of why the code is problematic. 
In the end, the reviewer may just forget about your code, but if the person is persistent and present roadblocks, you might need to just make their suggested changes just to move on. In the end, its more valuable to ship your code than to "be right" in a code review. If you end up taking this route, I would recommend you avoid including this person in future code reviews

Great read and great quote!  

Wednesday, July 30, 2014

Points and Animation

A simple code pen for travel between points and animation. Works for Firefox atleast!

See the Pen iebuc by Dinesh Vasudevan (@dinks) on CodePen.