Tasty JavaScript Curry

JavaScript Curry:

A useful technique to partially evaluate functions.

Coming Soon…

function myFunc(a, b) {
if (arguments.length < 1) {
return myFunc;
} else if (arguments.length < 2) {
return function(c) { return a + c }
} else {
return a + b;


var add4 = myFunc(4);


var add = myFunc();

var addTwo = add(5,6);

var addOne = add(1);

A thank you note!

I was going through my twitter feeds and came across WWCode’s tweet which asked to submit a story about how WWCode has impacted our careers. I was getting ready to go to office, but I stopped to write this story.

I have been looking for a way to thank WWCode Bangalore and couldn’t find this form any better!

It all began on 7th May, 2015 when I sent a talk proposal to WWCode Bangalore’s upcoming meetup to Devangana Khokhar (Director of WWC Bangalore).

The talk was about Intel’s RealSense 3D technology and how I had developed a game using my face as a game controller. I am a JavaScript aficionado and the best thing about this game was that it was built entirely on JS. How cool it is to do all of this perceptual computing using JS! Ever since I had accomplished this, I wanted to do a demo of this at WWCode Bangalore and we scheduled a meetup for 8th August, 2015.

That was exactly 3 months after I had sent the proposal ;).

Not many showed up for the meetup, but whoever was present were all taken away by the awesomeness of JS. It turned out to be a great 6 hour session and after that there has been no looking back!

The next day there was DataKind Bangalore Chapter’s sprint session and they were looking for data experts in visualizations and
I got a direct entry to be a part of this awesome team too. Thanks to Devangana and Gaurav Godhwani.

Oh, by the way, I need to make a mention here that I go crazy when you talk about D3.js and visualizations. Next to JS, D3.js and visualizations are close to my heart.
Anand S from Gramener is my inspiration to this!

Following this WWC’s session, I got lot of applauds on Facebook and Twitter.
I also got two enquiries from prospective startups who were interested about my work in perceptual computing. They were (and are still) generous to offer me to use their office space and 3D cameras for any R&D related work. I was thrilled.

Meanwhile, I won a fully paid diversity scholarship to attend JSConf.EU. It was my first international trip and I got to go to one of the most beautiful place – Berlin.

The next big leap was when I was invited to be a speaker at JSConf.Asia.
My first proposal to JSConf.Asia was rejected saying they thought the talk was more about an advertisement to Intel’s RealSense technology.
I didn’t want to give up and sent another proposal, which got accepted and I would be presenting my work at Singapore for JSConf.Asia on 19-20th November, 2015.

The idea behind this talk had generated when I was preparing for my first demo for WWC. This is where I would want to thank WWCode whole heartedly.

Little did I know back then that it would become a hit.
This is a little abstract about my talk for JSConf.Asia: “This talk is about a web based solution to simulate 3D cameras for prototyping, developing and testing perceptual computing, augmented reality applications without using a physical device. I will walk you through the immense possibilities which could be explored through JavaScript and web.”

The next big thing happened when my first technical paper on the above subject got selected for Grace Hopper Conference India 2015 which is scheduled for 3-4th December, 2015.

I got excellent feedback for this.

So this has been my summary for 2015 and major credits go to WWCode Bangalore.

It wouldn’t be fair to conclude this thank you note, if I don’t mention Cohan Sujay Carlos, CEO, Aiaioo Labs, the person behind getting me to enjoy coding.
He will always remain as my mentor.

Also, Sreeraman Vaidhyanathan, Co-founder and MD, IStar India Skills Pvt Ltd, for making me realise how fast I can code. Today, if I am able to come up with any crazy ideas and make them a reality, then the credit goes to Sreeram.

Amruth Ravindranath and all my other colleagues at Guru-G Learning Labs have been way too kind to offer me all the required support towards my external fun projects.

Last but not the least, my family who will be always there for me.


CORS – Cross Origin Resource Sharing

This is a sequel to my post on cURL.

“Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated” from wiki.

The above explanation is self explanatory. For instance, a resource loaded from Domain A (http://A:3000) such as an HTML web page, makes a request for a resource on Domain B (http://B:4000). The Same-Origin Policy restricts the browser from performing certain actions by scripts or documents based on the origin. The origin is everything in the URL before the path (e.g., in http://A:3000/images/bg.png, http://A:3000 is the origin and /images/bg.png is the path). For certain actions, the browser will compare origins and, if they don’t match, won’t allow things to proceed.

We kept getting CORS error, when we were trying to test our REST API. The server sided REST API logic was written on Node.js and was running on port 3000 on one system. The client side logic was also written on Node.js and was also running on port 3000, but on another system. I had initially tested the API using POSTMAN, and it worked great. But, when we tried integrating the front-end with the back-end, it was erroneous. And it was CORS. I had encountered something similar related to CORS, way back in 2011, during my first job, but it was resolved in few minutes. I cannot recall the exact issue, all I remember is that it had to do only with JQuery (front-end only).

This time, I tried understanding CORS in more detail.

Let’s assume, the server-side code was running on http://A:3000 and the client-side code was running on http://B:3000. We were trying to test the login api, i.e. front-end accepts username/password through a form and on button click, submits the values (HTTP POST) to the server. The server then validates the username/password combination. If successful, server returns the user id, else, returns appropriate error messages. We had agreed upon both the input and output to be JSON only.

Things looked alright, when the input type was x-www-form-urlencoded, i.e. normal form data being passed through JQuery AJAX request. But things went awry, when we restricted it to JSON only (POSTMAN still had no issues).

Following is the list of errors when we tried with JSON input, and how I went about solving each one of them.

1. http://B:3000 made a POST request to http://A:3000/login. But instead of POST, it always made a OPTIONS request.

Now the first thing to wonder about was why did this happen. To be honest, I wasn’t sure about the HTTP OPTIONS method until then. But this is what it is. “This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.”
Nobody uses this OPTIONS method, but it is used for CORS access to API’s. When doing a CORS request, the browser will do a ‘preflight’ OPTIONS request to discover if the server will answer the real request.

The next thing to wonder was what is this preflight.

CORS requests are usually preflighted. This request is basically there to ask the server if the full request is permissible. If POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML/JSON payload to the server using application/xml or text/xml or application/json, then the request is preflighted. Only if the server responds positive to this preflight request, the actual POST request will be sent to the server.

At this point it was clear why the POST request always came as an OPTIONS request for JSON input and not for x-www-form-urlencoded.

2. After I understood about OPTIONS method and the preflight request, following was the next error. XMLHttpRequest cannot load http://A:3000/login. The ‘Access-Control-Allow-Origin’ header has a value that is not equal to the supplied origin. Origin ‘null’ is therefore not allowed access.

I was running test.html locally on the browser as file:///E:test.html. Running it this way, always sets the Origin to Null in the request header. This took quite some time for me to understand and resolve. I then created another local Node.js server running on port 4000 to serve test.html. Alternative to this could have been serving test.html through WAMP Server/Apache on port 80. This resolved the null origin issue. The origin was now set to http://localhost:4000.

3. Following was the third error. XMLHttpRequest cannot load http://A:3000/login. The ‘Access-Control-Allow-Origin’ header has a value http://B:3000 that is not equal to the supplied origin. Origin http://B:3000 is therefore not allowed access.

This wasn’t scary, like the earlier one. I could make sense, what was happening here. On my server sided logic in Node.js, I had restricted “Access-Control-Allow-Origin” to http://B:3000 only. res.header("Access-Control-Allow-Origin", "http://B:3000");
On the client side code, I had to add the below line to JQuery AJAX method. When the CORS makes a preflight request, both the client and server should have the same headers set.
beforeSend: function (request) { request.setRequestHeader("Access-Control-Allow-Origin", "http://B:3000"); }

This is the full JavaScript working code after understanding about CORS, OPTIONS, preflight and setting headers through AJAX.

var login = {username: "sadmin", password: "sadminasd"}; $.ajax({ dataType: "json", beforeSend: function (request) { request.setRequestHeader("Access-Control-Allow-Origin", "http://B:3000"); }, contentType: "application/json", type: "POST", data: JSON.stringify(login), url: 'http://A:3000/login', success: function(data) { console.log("Success", data); //alert("Success "+data); }, error: function(err) { console.log("Error", err); //alert("Error "+err) } });

At one point, we took the approach of solving this problem using JSONP. JSONP was initially the solution prior to CORS for making cross domain requests. But JSONP supports only GET and not POST.

In my next blog, I shall talk more about JSONP and also about JSONP vs CORS.


Yesterday, I tried running a Node.js server on port 80 on Ubuntu. I normally run Node.js server on ports > 3000.

First time when I tried running the server, I was expecting an error, because Apache2 was running on Ubuntu on port 80(default port for Apache2). I stopped Apache2 sudo service apache2 stop.

I tried running Node.js server again, and now it gave me EACCESS error. I was clueless about this.

When I tried to search for this error on Google, I found the answer on stackoverflow.com.

“Non-privileged user (not root) can’t open a listening socket on ports below 1024.” from stackoverflow

I then ran Node.js server using sudo node app. Bingo, it worked.

Also, when I was talking to my colleague Shiv (Guru-g Learning Labs), I learned that if applications run on port 80, then we can access them without the port number.

Eg: http://localhost/ instead of http://localhost:80. The latter option works too, it’s just that, we don’t have to explicitly specify the port numbers for port 80.

P.S: I haven’t tried running Node.js server on port 80 on Windows. Will document my results soon.


We were trying to test our new Node.js app. I was building a REST API and it worked fine with JSON input. I used POSTMAN (which I heard just a week ago from my colleague Shiv). I must tell you, it is really great. POSTMAN could have been a new topic under #LearningItMyWay. But anyways, it has got a mention here.

When our Front End Engineer Sanjeet tried calling my REST API through JQuery AJAX, we kept getting CORS (cross origin resource sharing) errors. This part is yet to be resolved, and I shall blog on it soon (Insha Allah). Read More

Shiv came and tested using curl on PHP. This wasn’t the first time I had heard about curl, but I had never used it earlier. So this becomes a good topic for #LearningItMyWay.

“curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction.

curl offers a busload of useful tricks like proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer resume, Metalink, and more.”
(from this link)

So, basically, cURL is a command line tool for getting or sending files using URL syntax. curl url

There are various options for this command, but I haven’t bothered to know all of them for now. I only tried finding about this -L option. curl -L url

The -L option, allows to follow redirects with curl.

In my REST API written using Express on Node.js, I was using passport module for authentication. Passport does appropriate redirects based on login success or failure. When Shiv tested this API using curl, the redirects weren’t working as expected, and for once we were trying to find if Express redirects were working fine or not. Later, I found about this -L option for curl, and that was #LearningItMyWay.

Blogging has been fun so far, happy two days of blogging for me 🙂