Good JavaScript Charting APIs

1. D3
This is the root of web data visualization. There are many examples to follow but coding is tedious. It’s easy to start but very difficult to master.d3
2. C3
A light-weighted library based on D3.
C3 makes it easy to generate D3-based charts by wrapping the code required to construct the entire chart.
3. ECharts
Charting API from Baidu Inc. It has many geo-charts target to China.
The most comprehensive charting API so far.
4. Hightchart It’s a carefully designed charting tool.Free for non-commercial. Pretty easy to take on.
5. Google Charts From Google. A lots of examples and still growing for improvements. However, you can’t use it in intranet environment.
6. AMCharts Like highcharts, this is designed by a group of commercial people.
7. EJS charts  You need to buy the license to use.

Web map based data visualization

1. Pseudo-Animation Move on road for direction on Google Maps First you select a source-destination, then the app will use Google Maps JS API to get a route, and update the bus marker on the map continuously. It’s not a real animation, but plotting the marker frequently.  direction
2. Animation on Google Maps + Paper.jsThis the combination of Paper.js and Google Maps JS API. It demonstrates the possibility of rendering self-contained canvas on top of Google Maps canvas.paper
3. Leaflet MarkerClusterGood Markercluster plugin for Leaflet, especially for the nice animation.cluster
4. Mapbox Courier Example for Logisticscourier
5. Taxis in NYC Amazing data visualization of a daily life of taxi driver in NYC. The creator described the whole tech in the blog. Some one introduces a brief skill on this. Cursor_and_A_Day_in_the_Life
6. Digital Attack Map
Showing live DDOS attack across the globe, from Google Ideas.
7. Events Visualization

A bug in ArcGIS REST Service

We run ArcGIS servers in two different environments DEVELOPMENT and UAT , and the guy who set up the infrastructure has gone.
Last week we deployed the working app into the UAT, and it didn’t work as supposed as in DEVELOPMENT.

Specifically,  we had problem with the ArcGIS login process. We use ArcGIS REST API token generation for login authentication, and the app host address as HTTP referer.
Details see
After user logs in, we use the generate Sitemap in REST service to get a list of access-controlled layers for the user.
We don’t use the REST method as it only returns the current folders and then again requires ajax under the folder to get all the layers, it slows down the whole app.

In DEV, we successfully get the sitemap XML with all the layers as shown like this.

However, we could not manage it in the UAT, and it always returned an empty XML, i.e. no layer services at all.

Token returned from UAT server was correct, and there was nothing wrong with code and configuration. We debug the login module, the token generation process and any possible out-dated codes. Nothing worked.

The bug cost me one week to catch.  See Server 1 as DEV and Server 2 as UAT, something is missing:


I doubt that the guy who implemented the REST interface was different from the one who implemented the Sitemap interface. The later just ignored the whole folders when there was None Services, but this None only means there is no service under the root. Damn!

Mixins in JavaScript

In object-oriented programming, a mixin is a class that contains a combination of methods from other classes.

JavaScript’s object mechanism does not automatically perform copy behavior when you inherit or instantiate. Plainly, there are no “classes” in JavaScript to instantiate, only objects. And objects don’t get copied to other objects, they get linked together. However, we can fake the missing copy behavior of classes in JavaScript using mixins, either explicitly or implicitly. Let’s see a mixin example:

// vastly simplified `mixin(..)` example:
function mixin( sourceObj, targetObj ) {
for (var key in sourceObj) {
// only copy if not already present
if (!(key in targetObj)) {
targetObj[key] = sourceObj[key];
return targetObj;
var Vehicle = {
engines: 1,
ignition: function() {
console.log( "Turning on my engine." );
drive: function() {
console.log( "Steering and moving forward!" );
var Car = mixin( Vehicle, {
wheels: 4,
drive: function() { this );
"Rolling on all " + this.wheels + " wheels!"
} );

Vehicle and Car are just objects that we make copies from and to, respectively. Car now has a copy of the properties and functions from Vehicle. Technically, functions are not actually duplicated, but rather references to the functions are copied. So, Car now has a property called ignition, which is a copied reference to the ignition() function, as well as a property called engines with the copied value of 1 from Vehicle. Car already had a drive property (function), so that property reference was not overridden.

Let’s examine this statement: this ). Because both Car and Vehicle had a function of the same name, drive(), to distinguish a call to one or the other, we must make an absolute (not relative) reference. We explicitly specify the Vehicle object by name and call the drive() function on itBut if we said, the this binding for that function call would be the Vehicle object instead of the Car object, which is not what we want. So, instead we use .call( this ) to ensure that drive() is executed in the context of the Car object. If the function name identifier for hadn’t overlapped with, we wouldn’t have been exercising method polymorphism. So, a reference to would have been copied over by the mixin(..) call, and we could have accessed directly with

If you explicitly mix in two or more objects into your target object, you can partially emulate the behavior of multiple inheritance, but there’s no direct way to handle collisions if the same method or property is being copied from more than one source.

Consider this code for an implicit mixin:

 var Something = {
 cool: function() {
 this.greeting = "Hello World";
 this.count = this.count ? this.count + 1 : 1;
 Something.greeting; // "Hello World"
 Something.count; // 1
 var Another = {
 cool: function() {
 // implicit mixin of `Something` to `Another` this );
 Another.greeting; // "Hello World"
 Another.count; // 1 (not shared state with `Something`)

With this ), which can happen either in a constructor call (most common) or in a method call (shown here), we essentially “borrow” the function and call it in the context of Another (via its this binding) instead of Something. The end result is that the assignments that makes are applied against the Another object rather than the Something object. So, it is said that we “mixed in” Something’s behavior with (or into) Another.

While this sort of technique seems to take useful advantage of this rebinding functionality, it’s a brittle this ) call, which cannot be made into a relative (and thus more flexible) reference, that you should heed with caution. Generally, avoid such constructs wherever possible to keep cleaner and more maintainable code.

Ref: Book: this & Object Prototypes

this keyword in JavaScript

A function’s this keyword behaves a little differently in JavaScript compared to other languages. It also has some differences between strict mode and non-strict mode.
In most cases, the value of this is determined by how a function is called. It can’t be set by assignment during execution, and it may be different each time the function is called.

Global context

In the global execution context (outside of any function), this refers to the global object, whether in strict mode or not.

console.log(this.document === document); // true
// In web browsers, the window object is also the global object:
console.log(this === window); // true
this.a = 37;
console.log(window.a); // 37
function test(){
Function context

Inside a function, the value of this depends on how the function is called.

Simple call

function f1(){
  return this;
f1() === window; // global object
In this case, the value of this is not set by the call. Since the code is not in strict mode, the value of this must always be an object so it defaults to the global object.
function f2(){
  "use strict"; // see strict mode
  return this;
f2() === undefined; //true
In strict mode, the value of this remains at whatever it’s set to when entering the execution context. If it’s not defined, it remains undefined. It can also be set to any value, such as null or 42 or "I am not this".
Note: In the second example, this should be undefined, because f2 was called without providing any base (e.g. window.f2()). This feature wasn’t implemented in some browsers when they first started to support strict mode. As a result, they incorrectly returned the window object.
As an object method

When a function is called as a method of an object, its this is set to the object the method is called on.

In the following example, when o.f() is invoked, inside the function this is bound to the o object.

var o = {
  prop: 37,
  f: function() {
    return this.prop;
console.log(o.f()); // logs 37
Note that this behavior is not at all affected by how or where the function was defined. In the previous example, we defined the function inline as the f member during the definition of o. However, we could have just as easily defined the function first and later attached it to o.f. Doing so results in the same behavior:
var o = {prop: 37};
function independent() {
  return this.prop;
o.f = independent;
console.log(o.f()); // logs 37
This demonstrates that it matters only that the function was invoked from the f member of o.

Similarly, the this binding is only affected by the most immediate member reference. In the following example, when we invoke the function, we call it as a method g of the object o.b. This time during execution, this inside the function will refer to o.b. The fact that the object is itself a member of o has no consequence; the most immediate reference is all that matters.

o.b = {g: independent, prop: 42};
console.log(o.b.g()); // logs 42
this on the object’s prototype chain

The same notion holds true for methods defined somewhere on the object’s prototype chain. If the method is on an object’s prototype chain, this refers to the object the method was called on, as if the method was on the object.

var o = {f:function(){ return this.a + this.b; }};
var p = Object.create(o);
p.a = 1;
p.b = 4;
console.log(p.f()); // 5
In this example, the object assigned to the variable p doesn’t have its own f property, it inherits it from its prototype. But it doesn’t matter that the lookup for f eventually finds a member with that name on o; the lookup began as a reference to p.f, so this inside the function takes the value of the object referred to as p. That is, since f is called as a method of p, its this refers to p. This is an interesting feature of JavaScript’s prototype inheritance.

this with a getter or setter

Again, the same notion holds true when a function is invoked from a getter or a setter. A function used as getter or setter has its this bound to the object from which the property is being set or gotten.

function modulus(){
  return Math.sqrt( * + *;
var o = {
  re: 1,
  im: -1,
  get phase(){
    return Math.atan2(,;

Object.defineProperty(o, 'modulus', {
    get: modulus, enumerable:true, configurable:true});

console.log(o.phase, o.modulus); // logs -0.78 1.4142
 As a constructor

When a function is used as a constructor (with the new keyword), its this is bound to the new object being constructed.

Note: while the default for a constructor is to return the object referenced by this, it can instead return some other object (if the return value isn’t an object, then the this object is returned).

 * Constructors work like this:
 * function MyConstructor(){
 *   // Actual function body code goes here.  
 *   // Create properties on |this| as
 *   // desired by assigning to them.  E.g.,
 *   this.fum = "nom";
 *   // et cetera...
 *   // If the function has a return statement that
 *   // returns an object, that object will be the
 *   // result of the |new| expression.  Otherwise,
 *   // the result of the expression is the object
 *   // currently bound to |this|
 *   // (i.e., the common case most usually seen).
 * }
function C(){
  this.a = 37;
var o = new C();
console.log(o.a); // logs 37

function C2(){
  this.a = 37;
  return {a:38};
o = new C2();
console.log(o.a); // logs 38
In the last example (C2), because an object was returned during construction, the new object that this was bound to simply gets discarded. (This essentially makes the statement “this.a = 37;” dead code. It’s not exactly dead, because it gets executed, but it can be eliminated with no outside effects.)

call and apply

Where a function uses the this keyword in its body, its value can be bound to a particular object in the call using the call or apply methods that all functions inherit from Function.prototype.

function add(c, d){
  return this.a + this.b + c + d;
var o = {a:1, b:3};

// The first parameter is the object to use as
// 'this', subsequent parameters are passed as 
// arguments in the function call, 5, 7); // 1 + 3 + 5 + 7 = 16

// The first parameter is the object to use as
// 'this', the second is an array whose
// members are used as the arguments in the function call
add.apply(o, [10, 20]); // 1 + 3 + 10 + 20 = 34
 Note that with call and apply, if the value passed as this is not an object, an attempt will be made to convert it to an object using the internal ToObject operation. So if the value passed is a primitive like 7or 'foo', it will be converted to an Object using the related constructor, so the primitive number 7 is converted to an object as if by new Number(7) and the string 'foo' to an object as if by new String('foo'), e.g.
function bar() {
}; // [object Number]
The bind method

ECMAScript 5 introduced Function.prototype.bind. Calling f.bind(someObject) creates a new function with the same body and scope as f, but where this occurs in the original function, in the new function it is permanently bound to the first argument of bind, regardless of how the function is being used.

function f(){
  return this.a;

var g = f.bind({a:"azerty"});
console.log(g()); // azerty

var o = {a:37, f:f, g:g};
console.log(o.f(), o.g()); // 37, azerty
As a DOM event handler

When a function is used as an event handler, its this is set to the element the event fired from (some browsers do not follow this convention for listeners added dynamically with methods other thanaddEventListener).

// When called as a listener, turns the related element blue
function bluify(e){
  // Always true
  console.log(this === e.currentTarget); 
  // true when currentTarget and target are the same object
  console.log(this ===; = '#A5D9F3';

// Get a list of every element in the document
var elements = document.getElementsByTagName('*');

// Add bluify as a click listener so when the
// element is clicked on, it turns blue
for(var i=0 ; i<elements.length ; i++){
  elements[i].addEventListener('click', bluify, false);
In an in–line event handler

When code is called from an in–line handler, its this is set to the DOM element on which the listener is placed:

<button onclick="alert(this.tagName.toLowerCase());">
  Show this
The above alert shows button. Note however that only the outer code has its this set this way:
<button onclick="alert((function(){return this}()));">
  Show inner this
In this case, the inner function’s this isn’t set so it returns the global/window object (i.e. the default object in non–strict mode where this isn’t set by the call).

this is neither a reference to the function itself, nor is it a reference
to the function’s lexical scope.
this is actually a binding that is made when a function is invoked, and
what it references is determined entirely by the call-site where the
function is called.

Copy Right @ MDN: