Tuesday, October 7, 2014

Do you even Promise?


This post is a summary of a short presentation I gave a while ago at work. Its is a brief introduction to Promises in JavaScript. It doesn't explain the exact syntax or what Promise object is but rather what I consider as important advantage of using Promises over old callback approach and why every JS programmer should get familiar with this design pattern.

If you code JavaScript, sooner or later you will have to deal with asynchronous operations and callbacks. These callbacks as we know have its problems. You as a programmer often end up with code like that:

someAsyncOperation(function(data) {
    // do stuff
    // or something
    anotherAsyncOperation(function(data2) {
        // do stuff
        // or something
        andYetAnoterAsyncOperation(function(data3) {
            // do stuff
            // or something
            imRunningOutOfNamesAsyncOp(function(data4) {
                // do stuff
                thisSucksAsyncOp(function(data5) {
                    // do something
                    // or who cares now?
                });
            });
        });
    });
});


Pyramid of doom, callback hell, call it what you will. This is far from elegant solution and even though that above example is nicely indented and has hardly any actual code in it, it is already hard to read. Add some logic to it and you got yourself a mess. Trying to maintain it will be a pain and room for errors is enormous.

As ugly as it is, it’s not the main problem however. Look at the code below and try to guess what will be its output:

try
{
    setTimeout(function() {
        throw new Error(“BOOM”);
    }, 2000);
} catch (ex)
{
    console.log(ex);
}

This illustrates main problem with vanilla JS callback approach. The Error thrown inside of callback will not be caught inside of catch block. It will fail miserably. So will this code:

someAsyncOperation(function(data) {
    // do stuff
    // or something
    anotherAsyncOperation(function(data2) {
        // do stuff
        // or something
        throw new Error(“DOH!”);
        andYetAnoterAsyncOperation(function(data3) {
            // do stuff
            // or something
            imRunningOutOfNamesAsyncOp(function(data4) {
                // do stuff
                thisSucksAsyncOp(function(data5) {
                    // do something
                    // or who cares now?
                });
            });
        });
    });
});


Imagine this happening in your NodeJs code. It will very likely bring your process down. You can of course use domains or AFAIK depreceated process.on(“uncaughtException..) but there is a better way.

That's where Promises come in. It’s a design pattern that allows you to deal with callback hell and, most importantly, deal with exceptions. Imagine that instead of the mess above you can write code like this:

someAsyncOperation()
.then(function(data) {
    // do stuff
    return anotherAsyncOperation();
})
.then(function(data) {
    // do stuff
    return andYetAnoterAsyncOperation();
})
.then(function(data) {
    // do stuff
    return imRunningOutOfNamesAsyncOp();
})
.then(function(data) {
    // do stuff
    return thisSucksAsyncOp();
})
.catch(function(err) {
    console.log(err);
    return err;
});

Callback hell is no more and structure looks much more flatten and readable. Instead of nested callbacks, each .then(..) is executed only when previous one (returning a Promise) finishes. Top to bottom, very much like synchronous code. Also notice the catch block at the end of the chain. Readability is important of course, but the main point of using promises is the way it let us deal with exceptions. Exceptions will be caught in catch block and will let us recover gracefully. Without doubt this is most important point this design pattern delivers.

Now, this very simple example in no way covers everything you need to know about promises. I didn't even explain what the Promise object is, .then method and other details. I hope however it illustrates important point, that Promises allow us to deal with exceptions in an elegant way. This alone should interest you in Promises enough to google and experiment further. There are tons of articles available on the net. Google and try as its important to see for yourself how promises simplify development. If you are interested also have a look at my short presentation that is available here.

Thursday, September 25, 2014

My struggle with JSON

We all use developer tools. Console is of tremendous help when it comes to trying JavaScript snippets. Sometimes however something relatively simple e.g. like typing in JSON throws errors for apparently no reason. I had one of these moments and as usual started digging to see why it was happening. Ok, hit F12 in Chrome and type in:

{ “name” : “homer” }

Plain, old JSON it seems, nothing fancy. However you will be greeted with:



It is valid JSON so what gives? First thing that came to my mind was hidden characters. It’s (not so) well know fact that JSON is not quite a subset of JavaScript. JSON allows certain characters in a String and JavaScript doesn't. Given that one of the strings above contain Line Separator (line feed, carriage return etc.) this would sure spell trouble. Even though “Unexpected token :” would point problem to “:” rather than anything else I decided to check strings for any whitespace characters.

Fired up my trusted Notepad++ to see what Chrome doesn't show, but with no luck. No hidden characters of any type.

To make the matter worse running:

{ name:”homer”}

worked just fine. Almost fine actually, as the line was returning a “string” rather than object:



Why string though? Let me explain.. Using curly braces in console the way I originally did, creates a block statement. It is not parsed in expression context and so it does not create an Object. It does very much the same as I would execute:



It produces exactly same output so error pointing to “:”. If you look at this however it suddenly stops making sense. We simply creating here a string, followed by a colon, followed by another string. Clearly wrong.

Now, { name:”homer”} however was working. It was returning string rather than object, and for a good reason. Curly braces create block statement and so lets strip those and run:



You should see the problem by now. Obviously what I was trying to do here is to create a label followed by string “homer” and so “homer” was spit out to console as expected. If you are not familiar with labels in JS they are used e.g. to break out of loops e.g.:

var i, j;

loop1:
    for (i = 0; i < 3; i++) { //The first for statement is labeled "loop1"
        loop2: for (j = 0; j < 3; j++) { //The second for statement is labeled "loop2"
            if (i == 1 && j == 1) {
                continue loop1;
            }
            console.log("i = " + i + ", j = " + j);
        }
    }

// Output is:
// "i = 0, j = 0"
// "i = 0, j = 1"
// "i = 0, j = 2"
// "i = 1, j = 0"
// "i = 2, j = 0"
// "i = 2, j = 1"
// "i = 2, j = 2"
// Notice how it skips both "i = 1, j = 1" and "i = 1, j = 2"


So there it is. I was creating block statement with invalid syntax hence the error. Mistake that I won’t do again.

Tuesday, September 9, 2014

Help children and get healthy! its almost too easy!

I thought I should share it everywhere as it is for a good cause, helping children..  I encourage everyone to participate in Steptember, its easy and makes a big difference in lives of children and their families. At least have a look what Steptember is all about and participate if you can!

Monday, September 1, 2014

Memoize like a boss (part 2)

Memoization is fun and if you read my previous post you should have fair idea of how memoization can be easily implemented in JavaScript. Previous examples were using very simple function and now you might wonder how to deal with recursion and still get all the benefits. Last time around we end up with:

Function.prototype.memoized = function(a) {
if (typeof this.cache === "undefined") this.cache = [];
if (this.cache[a]) {
return this.cache[a];
} else {
this.cache[a] = this(a);
return this.cache[a];
}
}

Function.prototype.memoize = function() {
var t = this;
return function() {
return t.memoized.apply(t, arguments);
}
}

myTest = (function superLongCalculation(someArg) {
    return someArg * 3;
}).memoize();

console.log(myTest(2));


So to recap.. myTest function once called will call memoized method on original function object t:

t.memoized.apply(t, arguments);

memoized method will do the check if the value for argument ("2" in our example) has already been precalculated and if so will returned whatever is stored in cache. Otherwise will call original function, do the magic and return new value. If this doesn't quite make sense have a look at my original post where I went into details of my basic memoization implementation.

So now you might wonder what will happen if instead of something overly simple as above we will use recursive function to do the work. Calculating fibonacci numbers seems to be "Hello World" of memoization and so lets plug this thing into our memoization code:

Function.prototype.memoized = function(a) {
if (typeof this.cache === "undefined") this.cache = [];
if (this.cache[a]) {
return this.cache[a];
} else {
this.cache[a] = this(a);
return this.cache[a];
}
}

Function.prototype.memoize = function() {
var t = this;
return function() {
return t.memoized.apply(t, arguments);
}
}

myTest = (function fibonacci(n) {
return n < 2 ? n : fibonacci(n - 1) + fibonacci(n - 2);
}).memoize();

console.log(myTest(2));

Works like a charm. Returns correct values, however we can make it better. It still does unnecessary work and given our current code there is easy way to improve it.

Notice how the fibonacci function object itself is memoized, however internal calls to itself are not. This means that in this case we do half-assed optimization only and anything half-assed is not cool. Lucky for us the Function object has memoized method already that we can directly call as in the very first examples in part one:

Function.prototype.memoized = function(a) {
if (typeof this.cache === "undefined") this.cache = [];
if (this.cache[a]) {
return this.cache[a];
} else {
this.cache[a] = this(a);
return this.cache[a];
}
}

Function.prototype.memoize = function() {
var t = this;
return function() {
return t.memoized.apply(t, arguments); }

}

myTest = (function fibonacci(n) {
return n < 2 ? n : fibonacci.memoized(n - 1) + fibonacci.memoized(n - 2);
}).memoize();

console.log(myTest(2));

I also put few tests that are available here so you can see the difference. I also realise that there are other, more efficient ways of calculating fibonacci numbers, I believe however that examples above are simple enough to see how memoization can be used with recursive functions.

Tuesday, July 8, 2014

Memoize like a boss!

Concept of memoization is not new. There is like a billion articles on the topic. Out of many, Resig covered it in his Secrets of JS Ninja book and Stefanov in his JavaScript Patterns. Addy Osmani blogged about performance of different memoization techniques and if you've been leaving under a rock and you are not familiar with it google is your firiend. There is a lot of good stuff out there so make sure you check it out. Long story short memoization is a method of caching the results of a function, you know, to make it faster.

Imagine that superLongCalculation() function takes a parameter and returns value of some sort.

function superLongCalculation(someArg)
{
  // some complicated stuff is happening here with someArg provided and only when done return result

  return result;
}

Now, wouldn't it be nice if the function, after doing all the work could remember what the result is for this particular argument? Next time when its called with the same argument it should be able to look it up and return it right away, without recalculating same thing again. This is fairly simple to implement, just look at my attempt in JS below:

function superLongCalculation(someArg) {
    return someArg * 3;
}

Function.prototype.memoized = function(a) {

    if (typeof this.cache === "undefined") this.cache = [];
    
    if (this.cache[a]) {
        return this.cache[a];
    } else {
        this.cache[a] = this(a);
        return this.cache[a];
    }
}

console.log(superLongCalculation.memoized(2));

For the sake of example I keep it simple. Calculation is not all that complicated and code is pretty much self explanatory. We simply extending Function object with additional method. This memoized method, once called with argument, will check internal array if there is a precalculated value for the argument we passed. If so then will return this precalculated value. Otherwise will call original function (this(a)), this function will do very long calculations and the new value will be returned. To call it we simply use:

superLongCalculation.memoized(2)

Easy stuff yet very powerful. Yes, I know, extending native JS prototypes is a bad idea in general blah blah blah.. IMO it is useful in certain situation and as long as you understand what you doing and possible problems that come with it I see no issue.

Ok, then I stumbled upon Secrets of JS Ninja by Resig. He further extended the method allowing memoization to be called directly on a function. Real brainfuck if you ask me. And very interesting one. It allows retrieving cached results directly out of a function:

  superLongCalculation(2)

To implement this we need to go a bit further however. The code I managed to put together is below and explanation of bits and pieces will follow:

Function.prototype.memoized = function(a) {
  
    if (typeof this.cache === "undefined")  this.cache = [];
    if (this.cache[a]) {
        return this.cache[a];
    } else {
        this.cache[a] = this(a);
        return this.cache[a];
    }
}

Function.prototype.memoize=function() {
  var t=this;
  return function() {
   return t.memoized.apply(t,arguments);
  }
}

myTest = (function superLongCalculation(someArg) {
    return someArg * 3;
}).memoize();

console.log(myTest(2));

memoized function stays as it is. As previously it takes parameter and checks cache for precalculated values.

So lets start with figuring out what each bit is doing:

myTest = (function superLongCalculation(someArg) {
    return someArg * 3;
}).memoize();

We simply creating a function here:

(function superLongCalculation(someArg) {
    return someArg * 3;
})

It takes argument, multiplies by 3 and returns. This is in fact Function object and as such has memoize method we attached to Function prototype:

Function.prototype.memoize=function() {
  var t=this;
  return function() {
   return t.memoized.apply(t,arguments);
  }
}

Further we have a call to memoize method:

.memoize();

This call will give us back another method that will do stuff later. So to sum it up from now on, when we call myTest, in fact we will call:

function() {
   return t.memoized.apply(t,arguments);
};

This method has access to function object we created earlier (t) and in turn calls memoized method on this very object. Everyone's following? Right, so now at some point in our program we get to call myTest and spit out result to console:

console.log(myTest(2));

So now myTest(2) calls:

function() {
   return t.memoized.apply(t,arguments);
}

t (via closure) refers to function object we created earlier. On this object we call memoized method with "2" passed as parameter. memoized method checks if value is in cache, if so returns it, otherwise calls original method and then returns the result. And so we have basic memoization implemented now.

Now, that was the easy part and it gets a bit more involving when you try to make superLongCalculations recursive. If anyone actually read this post I might put together few more examples with fibonacci numbers or something later, for today its enough however.

Tuesday, June 24, 2014

AngularJs custom directive trouble

So I decided to build very simple directive in AngularJs. Came up with this simple code:

<!doctype html>
<html>
  <head>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.0/angular.js"></script>

    <script>

var app = angular.module('myApp', []);

      app.directive("taWithMessage",function() {
    return {
    template: "<p><h2>sample</h2></p>",
    replace: true
    };
   });

    </script>

  </head>
  <body>

    <div ng-app="myApp">

<div ta-with-message></div>

    </div>

  </body>
</html>

.. ran it and BOOM! Got this:


To make it more interesting replacing:

template: "<p><h2>sample</h2></p>",

with

template: "<p><span>sample</span></p>",

or:

template: "<div><h2>sample</h2></div>",

Worked just fine. It obviously didn't have anything to do with display of the element as div s well as p are both block, yet div works fine, p didn't. 

Then I started debugging and after a while I realised what a dummy I've been. Given original code, the browser was interpreting it as:

<p></p><h2>sample</h2><p></p>

This excerpt from specs should clarify what the issue was:

A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, nav,ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element.

If you ever read the HTML specs you already know that some elements do not need to have closing end tags. I was well aware of this yet at this point didn't realised that was the issue. 

Decided to dig further into AngularJs source itself to see what exactly is going on in there and as it turned out innerHTML is the culprit:



AngularJs nicely passes template code to JQLite (highlighted in yellow below) and JQLite at some point runs it via innerHTML. This spits out modified as per above specs code. Then as shown below, AngularJs checks if the code is valid, so have one root only:



One root meaning:

<div><p>something</p><p>something else</p></div>

Rather than:

<p>something</p><p>something else</p>

As the code JQLite spits out is:

<p></p><h2>sample</h2><p></p>

It fails the check and Angular throws Error.

All this Googling and head scratching could be avoided if I only remembered the basic specs. Shame on me.. =/

Thursday, June 19, 2014

(Mis)adventures with Zepto

I was blessed with a task of developing mobile version of existing site. “Easy” I thought as the site had decent HTML, CSS and decent JS code. After all I developed it ;). Module pattern kept things separated nicely, namespacing was in place and all the files in production were concatenated into one and minimized.

Then someone very smart suggested that as mobile site will not be Javascript heavy I should dump jQuery and go with lighter option Zepto. And so I did.

For those not familiar with Zepto, according to their website its:

Zepto is a minimalist JavaScript library for modern browsers with a largely jQuery-compatible API. If you use jQuery, you already know how to use Zepto.

Minimalist, sure, less than 10kb gzipped and largely compatible with jQuery. As I was writing JS from scratch it seemed like a great idea. Todays mobile browsers are quite capable anyway and I could do without fadeOut's and such.

Right, so I started developing. Code I developed for desktop version had bits that I could reuse in mobile site. Things like Cookies management, form validation and all this sort of stuff could (should) be reused and so I decided to put these bits into Common.js. In production, this Common.js file would be concatenated with desktop JS or mobile JS source depending on what device would make request. So far so good. Brilliant.

Only then I realized that these bits of code, sometimes contain functionality that is supported by jQuery, but not by its lighter brother (sister?) Zepto.

As you might expect effects like:

$("div p").fadeOut(3000)

Will not work. To be honest there was no need for that. Most of these can be done with CSS transitions anyway so it’s not a biggy. But then I noticed few other things didn't quite behave as expected. This was a bit worrying as not being familiar with Zepto I couldn't pick these up just by looking at the code. E.g. using some of the selectors was causing trouble:

$("div p:even")

As useful as this construct is with Zepto it will fail. There are few other, sometimes subtle differences. If you ever tried to clone element, jQuery provides very convenient “clone” method. In Zepto it seems to work just fine until you realize that it doesn't take optional argument that specifies if the event handlers should also be cloned. Element itself will be cloned, but you will have to attach events yourself somehow (or deal with these higher in DOM somewhere).

All in all Zepto is really nice and does most of the stuff. However if you have existing code that might not be worthwhile spending time modifying it just so it works with Zepto. There is always a risk that something might not work as expected and the behavior of “clone” method is the best example. After all, jQuery 2 is around 30kb gzipped and in most cases size is not so much of an issue. If it is however make sure you test everything when migrating to Zepto to avoid painful surprises.

Thursday, May 8, 2014

By value or reference?

In JavaScript writing functions is easy. No need to declare return type, no need for argument types, In fact you don't even need to declare arguments! One might argue if all this freedom is actually a good thing. Freedom or not, it is important to understand the JS very basics and understand if what we pass into functions is passed by value or reference.

If you are familiar with Java the behaviour in JS will make sense to you. For all those confused however about how arguments are passed into functions I put together quick example that I hope is self explanatory. Consider the code:

var a = 100,
    b = "Homer",
    c = {
        firstName: "Homer"
    },
    d = {
        firstName: "Homer"
    },
    e = {
        firstName: "Homer"
    },
    f = {
        firstName: "Homer"
    }

function changeName(a1, a2, a3, a4, a5, a6) {
    a1 = 200;
    a2 = "Bart";
    a3.firstName = "Bart";
    a4 = {
        firstName: "Bart"
    };
    delete a5.firstName;
    delete a6;
}

changeName(a, b, c, d, e, f);
// output
console.log("a1:"+a); // 100
console.log("a2:"+b); // Homer
console.log("a3:"+c.firstName); // Bart
console.log("a4:"+d.firstName); // Homer
console.log("a5:"+e.firstName); // undefined
console.log("a6:"+f); // object


Ok, a and b are primitive types and these are obviously passed by value. References to objects are also passed by value. Confused? Let me explain..

Lets start with c, its a3 inside of function. Its an objects reference passed into a function. Inside we modify its property and it does modify original object c that a3 references.

Now da4 argument inside the function. Again reference to object with firstName property "Homer" is passed (by value) into a function as a4 argument. Inside the function we assign other object to a4 argument. From now on a4 is a reference to different object. Modify it all you want, d from outside won't be touched.

e and f are straightforward really. In case of a5 reference to firstName is deleted and in case of a6 the a6 reference pointing to original object is deleted. Original object stays however and can be accessed by still existing reference f from outside of function.

Understanding of all this is pretty fundamental I believe and getting it wrong might result in bugs and confusion. Luckily for us all its also fairly easy concept to grasp and as easy to experiment with.

Wednesday, May 7, 2014

jQuery and Array-like objects in JavaScript

JavaScript with its closures, prototypal inheritance etc. is not the easiest language to learn. Knowing certain topics is very important in effective writing and debugging JS code. I believe that Array-like objects is one of those concepts that everyone should get familiar with. Where can we find such thing? arguments accessible inside of functions is one example. jQuery returns such animal when you call $(“someSelector”). It looks like Array, behaves (in some cases) like Array, but its not Array. Try:

var a={},b=$(“div”), c=[],d=new Array();

a instanceof Array // outputs false (duh..)
b instanceof Array // outputs false
c instanceof Array // outputs true
d instanceof Array // outputs true


c and d are arrays, a and b not so much though. a is self explanatory, its an object literal. b is Array-like object jQuery returns.

As a is furthest from what Array should look like lets try to make it closer to what arrays are. Start from beginning and attach few properties to it e.g.:

a={ 1:”first”, 2:”second”};

Now calling (e.g. in Chrome dev tools):

a

Will output:

Object {1: "first", 2: "second"}

And calling:

a[1] // outputs first

a[2] // outputs second


However:

a.length

Outputs:

undefined

And for a good reason. It is still plain object and length property doesn't exists. Ok, so lets fake it till we make it and lets add:

a.length=2;

Now calling a from console will output:

Object {1: "first", 2: "second", length: 2}

True Arrays also have number of methods so lets add some and see what happens:

a.push=function() {}

Outputs:

Object {1: "first", 2: "second", length: 2, push: function}

Not much change. The trick lies in splice method. Simply add:

a.splice=function() {}

and voila! Calling a will output:

[undefined × 1, "first"]

Now, look at our original object. Its missing “0” element hence undefined in output above. Also “second” is missing as our length was set to 2 only.

Now, can we make it even more Array-like? Sure we can! Our splice and push implementations are empty so lets fill one in, e.g.:

a.push=function(el) {
// here you can extend implementation or not, then we call Arrays push
Array.prototype.push.call(this,el);
}


Now try:

a.push(“third”);

And call:

a

Result will be:

[undefined × 1, "first", "third"]

Calling a.length will return:

3

So third element was added to our fake array. Even length property increased by one. Hows that for array? :)

All good. We got ourselves Array-Like object. a instanceof Array will still return false, but its close.

As you see jQuery isn't using any sort of black magic, and I hope this gives you better understanding of Array-like objects that you often see in JavaScript. This is only the beginning however and if you are brave and want to learn more there is no better way then try it for yourself e.g. play around with a.__proto__=[].__proto__ and var b={};b.__proto__.{}.__proto__ and such. Or try removing splice from jQuery Array-like object or .. ok I better stop now but TRY, all these are fun too!

Wednesday, February 26, 2014

Testing window.scroll with QUnit/Jasmine

So you have to write set of tests for your code. Lets say it modifies evilGlobal variable when window is scrolled past certain point, e.g.:

var evilGlobal=false;

$(window).on("scroll.singleJob", function(e) {
if (window.scrollY > 100) 
{
evilGlobal = true;
 }
});

Say you using either QUnit or Jasmine (I will provide examples for both) to write your tests and so you got yourself nice fixture setup:

<div style="padding-top: 0px;height: 20000px;">
        Very tall content
</div>

HTML seems straightforward so you put your test together in no time. Using QUnit it might look something like:

test("sets evil to true", function() {

window.scroll(0, 1000);
ok(evilGlobal, "test 1 was great success!!!");

});

Jasmine version:

it("sets evil to true", function() {

window.scroll(0, 1000);
expect(evilGlobal).toBeTruthy();

});

You run the test and it fails miserably. You called window.scroll(0,1000) but the callback will not be executed immediately. It will be put in tasks queue that every browser maintains (I wrote a post on tasks queues a while ago). As Javascript is single threaded the callback will have to wait till current thread is finished. So as our thread continues, the ok assertion that follows will be executed before the callback will have a chance to modify our evil variable. The interesting part is that the browser will however change the window.scrollY position and so if you call window.scrollY you will get 1000. 

Knowing that, the solution is simple. Simply trigger the handler manually and as we already using jQuery, trigger method will do the trick. QUnit code:

test("sets evil to true", function() {

window.scroll(0, 1000);
 $(window).trigger("scroll");
ok(evilGlobal, "test 1 was great success!!!");

});

Jasmine version:

it("sets evil to true", function() {

window.scroll(0, 1000);
 $(window).trigger("scroll");
expect(evilGlobal).toBeTruthy();

});

Why does it work? As the scrollY of the window is already updated all we need is to execute our callback. Trigger function of jQuery is called synchronously setting our variable to true so its ready for our assertion.

Monday, February 10, 2014

Deciphering IE10 popular check syntax

Lovely Microsoft decided to remove support for conditional comments in IE10. So what to do when for whatever reason we need to target this browser and only this browser? There are different ways. One interesting method I would like to discuss is use of self invoking function as:

Function('/*@cc_on return document.documentMode===10@*/')()

In IE10 this will return true and in a code might be used as:

if(Function('/*@cc_on return document.documentMode===10@*/')()) {

$("html").addClass("ie10");
ie10=true;
}

If you are after quick solution its as easy as copy and paste (or try this if(/*@cc_on!@*/false && document.documentMode===10){}). Some might wonder though what exactly this twisted syntax is. Lets try to decipher it step by step. So we trying to understand:

Function('/*@cc_on return document.documentMode===10@*/')()

Right, lots happening here, self invoking function, conditional compilation and what not. Lets start from something easy, consider the code:

var doh=function() {
         alert('DOH!');
}

doh();

This will create a function object and alert DOH! on the screen. Because its a function JS allows us to call it as doh(). Another way of creating function object is via Function constructor as below.

var doh=Function("alert('DOH!')");

doh();

We can still call doh() with no problem. The difference is that this time the body of a function is passed as an argument to Function constructor. 

Keep in mind that there are more differences that you need to be aware when deciding on using constructor syntax. For details I would recommend reading MDN docs for our purposes however all you need to understand is that body of a function can be passed as an argument to a Function constructor.

Easy stuff so far. Now lets make this function self invoking. All we need to do is:

Function("alert('DOH!')")();

We simply instantiating a function object and invoking it right away. When you execute the line it will pop alert on the screen as in previous examples. Very useful construct indeed. Now we might as well replace our alert with /*@cc_on return document.documentMode===10@*/ getting back to our original code:

Function('/*@cc_on return document.documentMode===10@*/')()

Now, what exactly is all this /*@cc.... voodoo you ask? Well, Microsoft folks came up with JScript which is their implementation of JavaScript. JScript also supports something called conditional compilation. You can think of it as sort of conditional comments but for JavaScript (in IE). As per MSDN @cc_on activates conditional compilation within comments in a script so in IE<11:

Function("/*@cc_on alert('DOH!')@*/")()

Will alert DOH!, all other browsers will recognise the function body as a comment only. Now replace alert with our return statement and you got yourself check for IE10 ready to use. 

Furthermore, as I found out skipping cc_on still gives the same results so in my code Function("/*@ alert('DOH!')@*/")() also does the trick. 

I know what you thinking now.. You can check for any IE with this method. From my experiments however, despite of what MSDN documentation is saying I learned that conditional compilation is not supported in IE11. Oh well, I'm sure MS will come up with more conditional improvements soon that will make our lives (not necessarily) easier.

Sunday, February 9, 2014

Sass now even better in Chrome!

So you've tried Sass and you love it. No more CSS-mess for you no more! BUT (isn't there BUT always?) when debugging your code in your favourite Chrome the line numbers in Styles tab do not refer to exact lines in your Sass source file. These refer to generated CSS file that you no longer directly modify. So in dev. tools you still see line number refering to CSS file:



It would be so much easier if tools referred directly to Sass source file as below:


Now (and have been for a while to be honest) it is possible as Chrome allows use of source maps. This basically will map properties from CSS file that browser uses to style elements to source Sass file you directly edit.

To make it happen you need to have late version of Sass installed, at the time of writing this is 3.3.0.rc.2 (whole list of versions can be found here). If you don't have it yet simply run:

gem install sass --version=3.3.0.rc.3

One note.. there is a long list of versions available. As I found out installing anything above version 3.3.0.alpha.201 and running sass with --watch argument does not seem to detect when the file is being updated. --watch argument as you probably know makes Sass to detect when new version of the scss file is saved and recompiles css accordingly. In versions newer then 3.3.0.alpha.201 this doesn't seem to work, at least on my system. That might be fixed by the time you reading this, but I couldn't get it working even with the current latest RC3. If thats the case and you find --watch useful install Sass via gem install sass --version=3.3.0.alpha.201

Now you have Sass installed so go to Chrome dev. tools settings ans tick as below:


And after that you need to tell Chrome where the source file is so it can map CSS properties to it. To do that in Settings-->Workspace "Add folder" and point to the folder where source file is located. Chrome will ask you to confirm that you want to give access to this particular location.


Right, Chrome part is set, all we need to do is run Sass with additional --sourcemap argument e.g.:

sass --sourcemap --watch path_to_scss_file:path_to_css_file

Now you might remember --debuginfo argument used with earlier versions of SASS, this is no more and now --sourcemap does the trick.

And that's pretty much all, hit F5 to refresh the page and enjoy new and improved Styles tab with line numbers referring to Sass file.

Thursday, February 6, 2014

Debugging much?

We all debug. It's easy enough.. hit F12, find a script where breakpoint is needed, set it and wait when JS execution will pause where the breakpoint is set. Wouldn't it be nice though if you could specify directly in the source code when the debugger should pause exactly as the breakpoint does? Well, thank you lucky stars that if you are using Chrome all you need is debugger function. So given code:

// some amazing JS here

debugger; // program will pause here, that's the breakpoint

// even more amazing JS

If dev. tools panel is open this will pause execution at the point where debugger call is. Pretty useful if you ask me.

Wednesday, February 5, 2014

Pure ASCII awesomeness

If you are old enough you might remember how ASCII characters where used to generate images. Non-geeks will say "ehh...I like jpg better", but if you anything like me you will fully appreciate ASCII art awesomeness. I googled this generator, uploaded photo of my lovely daughter and screenshot of result is below. It sure brings back memories of times when 8bit computers ruled.



No more Notepad++! Sublime Text all the way!

You know when a kid gets a new toy and is so excited that wants everyone know how cool the toy is? Well I feel like that kid today as found new tool that some of you might already know about.

Ok, as most of the work I do is JavaScript with usual mixture of HTML and CSS I tend to stick with simple tools. Set of web browsers, Git and text editor. Originally, years back I used Homesite (when it was still owned by Allaire). Then I switched to Notepad++ and been using it till today. Its simple enough, allows easy duplicating lines, folding etc. With a bit of configuration I was able to get it the way I like it. Using plugins you can compare files and it provides most of the basic functionality you would expect from simple text editor. It's far from perfect though and many times got on my nerves and e.g. folding I mentioned gets confused sometimes and N++ got few other glitches.

Every now and then I look up new tools. It's been few years with Notepad++ and thought I should give something new a try. Once my favourite, Homesite officially is dead and buried now. I still cannot believe that even though it wasn't improved since a decade or so Adobe was still charging money for it. Luckily I came across Sublime Text 3. I Downloaded the thing, installed and got totally blown away. All basic editing features that I constantly use are in there. Duplicate line by CTRL+SHIFT+D instead of CTRL+D as in Notepad++. Installing new plugins (they call it packages in ST3) is a breeze and in few minutes I had SASS support, Git and all ready to work. And the best thing is you configure everything by modifying JSON structures in config files. How simple is that??

Long story short Notepad++ compares to Sublime Text 3 like chariot to Merc C63. If you are still one of those unfortunate souls that code with Notepad++, you really should give Sublime Text 3 a try. For me there is no going back, not any time soon anyway. This thing really puts smile on my face and if you haven't already, you can download this gem from http://www.sublimetext.com/3.

Wednesday, January 29, 2014

Extending Javascript Array

It's surprising to some that Javascript has all sort of methods to manipulate Arrays but none of these (in current specs.) allows to quickly find Max/Min values stored in array. Sometimes its tempting to quickly extend native JS Array. So having array e.g.:

var beersDrunk=[22,33,44,32,1];

We trying to find max value stored in this array. One option is to add (static) max() method to Array below:

Array.max=function(v) {
    return Math.max.apply(this,v);
};


This will allow us to call:

Array.max(beersDrunk); // returns 44

Or other way you can define max() on Array's prototype as:

Array.prototype.max=function() {
    return Math.max.apply(this,this);
};


This allows you to call max() method directly on the Array's object itself e.g.:

beersDrunk.max(); // returns 44

If you think "cool, lets use it in my code!" beware.., its not bulletproof method and has obvious problems. It will fail (return NaN) if array contains anything else then numbers e.g. [22,"boom",44,32,1], its not the fastest way to look up Max/Min values etc. etc. Probably the worst however is that monkey patching like this breaks encapsulation. Imagine if at some point ECMAScript committee decides to add max() method to Javascript Array. Your implementation will override theirs and booom, this might cause serious problems. Extending array's prototype will also give you more headaches if you are using  (dont!) for in  to iterate over arrays. This is a huge topic and luckily for all of us there are ton's of resources all over the web on problems of extending native Javascript objects. It might be worth googling the topic if you decide to use this method in your code.

Despite all the problems it is interesting method nonetheless. If nothing else, being able to understand how the code above works will make you a better programmer.