Juixe Techknow

Most business applications display some amount of data in charts and graphs. If a picture is worth a thousand words, then a clean visual representation of business data is worth a lot more. Business charts can condense a lot of data points into a easy to understand graph.

Recently, I was tasked with updating the graph solution of a financial application with a HTML5 friendly charting tool or library. I looked at about half a dozen JavaScript chart libraries and eventually narrowed the selection down to two based on features and functionality: Google Charts and jQuery chart plugin jqPlot. Both Google Charts and jqPlot support a large number of chart types, from the basic bar and pie to more advance features such as multiple y-axis and and zoom. Both libraries support HTML5 graphics, the legacy chart solution I was to replace generated a pixelated image. Google Charts and jqPlot both draw the graph into div tag instead by using HTML5 graphics and don’t anti-aliasing issues.

For this particular project, we picked jqPlot over Google Charts for the following reasons. Google Charts is not open sourced and it uses a loading mechanism that requires you to be online to load the JavaScript source files from Google’s servers. This is great if you are always online, but the project owners wanted a HTML5 charting solution that works offline. jqPlot is a freely available open source JavaScript library which can be hosted alongside with the other application resources. jqPlot, like Google Charts, has a large number of chart types it supports including line, area, bubble, bar stacked, pyramid, pies, donuts, gauges, and much more.

jqPlot JavaScript Chart Library

ICANN, the organization that regulates domain names, has allowed organizations and individuals to apply for new generic Top Level Domains (gTLD). A Top Level Domain (TLD) is the a domain extension such as .com or .org used by millions of websites. In addition to .com and .org there are country specific TLDs such as .co.uk, .fr, and .mx. ICANN has nearly 2,000 applications for new gTLDs. ICANN has released to the public gTLD application information such as the newly proposed domain extension and the applying company. For example, Google has applied for nearly 100 domain extensions including for .app, .youtube, .goog, .plus, and many more. Google clearly can afford the $185,000/application fee.

I downloaded the data, played around with it and generated some graphs to help me visualize the new land rush for domains. Please note that I discounted and removed a few gTLD applications for non-latin domains.

The first chart shows that nearly 50% of the new domain extension originated from North America. North American and Europe combine make up over 80% while African organization only applied for roughly 1% of proposed new domain extensions.

The following chart shows that a large number of the new proposed generic domain extension are under five characters long but there are a few that are up to eighteen characters in length.

The following graph shows the most popular proposed domain extensions. For example, thirteen different individuals or organizations applied for the .app TLD, eleven for .inc and .home, ten for .art, etc. This chart shows only domains with five or more applications.

As previously noted, Google applied for nearly 100 domain extensions… 98 to be exact under Charleston Road Registry Inc. Top Level Domain Holding Limited registered 68 gTLDs followed by Amazon with 65. Apple doesn’t appear in this chart because this graph shows application organizations with more than ten domain extension applications.

I also wanted to graph the number of applications per primary contact and found out that a single individual, Daniel Schindler, has filed for three hundred domain extensions. Looking at the data, each of the applications submitted by Mr. Schindler are for distinct legal entities.

So who is the real domain squatter? ICANN will be squatting on nearly $400 million because of the $185k/application fee. Another question is, how will a flood of new gTLDs affect the value of current domains? And perhaps most importantly, how will the private organizations use and restrict access to these domain extensions?

It’s clear that we are in a bubble. I am not saying we are in a stock market bubble, even though most tech investors will agree that private valuations are frothy and that this frothiness is caused by the bubble in which we are in, a user adoption bubble. Where it used to take a long time for people to adopt a new technology, now new products and services gain more users faster than ever before. It took decades for traditional telephone companies to get a signification penetration rate, were as mobile carriers already have garnered an estimated 97% penetration rate in the United States. A similar user adoption rate acceleration can now be experienced by startups that execute well, Facebook has a stepper adoption curve than Yahoo did, and Google Plus had a steeper adoption curve still for its number of Daily Active Users. Products that execute well, such as Instagram, can see an adoption rate that is appealing to investors. An increase in user adoption rate, especially at the 1 million to 50 million user accounts, and a decrease in the cost of running a startup has been a key factor to the trends we have seen in Silicon Valley. The formula, as demonstrated by Instagram, is simple; small team + millions of users = a billion dollar valuation.

Even though some social networking related startups have seen user fatigue, I don’t see or expect the user adoption bubble to burst at an industry level any time soon, especially for well startups that consistent execute on user engagement and amazement. At the individual product or service we’ve already seen where companies have faltered, such as the reports that Draw Something has seen a significant drop in daily users.

The user adoption bubble has been brought on by a number of factors including the ubiquity of internet access, growing number of smart devices and inexpensive computers, as well as social engaging techniques such as poking, liking, following, retweeting, pinning, etc.

Error handling and debugging had been made difficult in JavaScript because the lack of tools and the language itself. Unlike Java, that has a strong type and hierarchy of exception classes, JavaScript didn’t even have a direct approach to print the execution stack trace. For years I used a workaround to navigate around stack trace of a method call in JavaScript by using the Function arguments property. In JavaScript, all functions have an arguments property defined. The arguments property is available even if the function is defined with no explicit function parameters. The function arguments property behaves like an array and you can iterate through the argument parameters used to call the function but it also has a reference to the caller via the arguments.callee property. The arguments.callee property references the currently executing function itself, which has a caller property to that of the previous function call in the execution stack.

function basicFunction() {
   var isTrue = arguments.callee == basicFunction; // true
   var callingFunction = arguments.callee.caller; 
}

In the above code, the callingFunction variable holds a reference to the Function object that called the basicFunction.

The caller property returns a Function object or null, so you can chain these until you get to the root of the call stack. You can iterate through a call stack in JavaScript with code similar to the following.

function basicFuction() {
   var caller = arguments.callee.caller;
   while(caller != null) {
      console.log(caller);
      caller = caller.caller;
   }
}

Unfortunately, there is no clean way to get the function name out of the Function object returned by the caller property. This is made slightly more difficult because somethings functions don’t have names if they are created anonymously. If you print or log a Function object, it displays the function definition in its entirety.

Fortunately, the JavaScript console object provides a trace function that will log to the web console the JavaScript stack trace.

function basicFunction() {
   console.trace();
}

If the above function is invoked from an on click event, the whole JavaScript track trace from the on click to the basicFunction function is logged out in the web console. In addition to the function names, the web console in Safari, Chrome, and Firefox have a link to navigate to the exact location your web application where the functions were called.

As the saying goes, if a thing is worth doing, it’s worth doing well. It has been proven that doing a thing right the first time is most efficient and cost effective. But what is the cost of doing something wrong? In terms of money, I’ve seen cases where something is done incorrectly and then had to redone at a loss of $100k. In terms of time, you can model it in the following thought experiment.

If a task takes x amount of time to complete and it is done wrong the first time, how long does it take to fix it?  More than 4x. It takes to x amount of time to complete the task the first time, probably at least x amount of time to find out it was done wrong, another x amount to figure out what the first guy did, and finally x amount to fix it correctly.

We all can agree that time is money and if a task is done incorrectly it may cost at a minimum as much as four times as much as it would cost if done correctly the first time around.

In the early days of JavaScript there were few options for debugging large web applications. You could have used the multiple alert notifications or possibly even calling document.write to write messages into the document. Firebug changed web developers lives, and I think how we view JavaScript, by making it incredibly easy to debug HTML, CSS, and JavaScript. Since Firebug, most current versions of web browsers include powerful debugging tools. In addition to the debugging tools browsers have made available a JavaScript console object to help write debug statements. With console, there is no need to pop up alerts to inspect the state of an object. To write a log message intended for the console, just write the following JavaScript statement in the right place.

console.log("This is a log message");
console.log("Message one", "Message two", "Message three");

To open the console, you can find it in Safari by looking for the the Web Inspector, in Chrome it’s called Developer Tools, and in Firefox you’ll find it under the Tools menu as Web Console.

The console object has a lot of useful debugging messages for errors with different severity, such as log, debug, info, warn, and error.

console.info("I'm here.");
console.warn("Do I smell smoke?");
console.error("The roof, the roof, the roof is on fire.");

In addition to logging String messages, you can log whole JavaScript objects. It may be useful to inspect a complete object and it’s state. To write out the state of an object to the console use the dir method as in the following example.

console.dir({fname:"Bill", lname:"Gates"});
console.dir(document.getElementById('SomeElementId'));

In Chrome and Safari, you can also use dirxml to display the a HTML element object in the console as HTML. In my version of Firefox, this method did not work.

console.dirxml(document.getElementById('SomeElementId'));

You can also group related log messages, no matter their severity. To group console messages surround them with a group and groupEnd. You can even nest groups inside of groups.

console.group("Server update");
console.log("calling server...");
// ... any number of console log messages.
console.groupEnd();

You can also test the performance of your JavaScript code with time and timeEnd. Both of these methods accept a String label and it needs it needs to be the same value for both methods.

console.time("Process Data");
// ... some time consuming code
console.timeEnd("Process Data");

When the timeEnd method is executed it will generate a message in the log console with the amount of time it took to run the code between the time and timeEnd method.

Chrome Developer Tools Web Console