# Note to Self

This is a note to myself and to anybody else reading this blog. These things have been helpful in college and also go a long way in helping others too. So I just thought of jotting them down.

1. Document what you do: You always experiment, try out cool things everyday (they may not seem cool to you, but it maybe for others), just take some time out and make a note of that, write a blog post. Not because that would be show-off but because it will go a long way in inspiring and helping your juniors or any other person from outside your college as well. I can vouch for it because there have been many blogs from whom I have taken inspiration.
2. Be passionate for engineering: Make things, create! Its the best way to have fun, when code that you had been hacking on runs, or the Arduino LED glows, the ecstasy is incomparable. At the end you will end up tinkering with a lot of things and a whole bunch of messy ideas in your head.
3. Give back: You will always find yourself looking up answers on Google, Stack Overflow and the like. Take a moment after you solve your problem, share it with the world, answer a few questions on Stack Overflow, or on our group. Improve the community as a member, because if others hadn’t contributed you wouldn’t have found the answers.
4. Open your eyes and ears: Look outside your world, there are a lot of great people to meet and find out. Keep yourself updated with the latest from the tech world. Read other blogs, HN, etc.
5. Re-invent the wheel:You can go ahead and try to make a square wheel (doesn’t matter if you fail), the experience that you gain along the way will be what will be valuable to you. Don’t be afraid to re-implement something because it already exists – who knows, yours could be different or better?
6. Find your specialty: That one thing that you are good at, do it often, iterate until you are good. You find yourself drawn to cool user-interfaces then just do HTML/CSS just don’t for Python because your friend is doing it. As it is stated in the Unix Philosophy – “Do one thing, do it well!”

Following points have been added by Rishi Ayyer, and I feel they will be an useful addition to this post.

1. Travel: Because you need to get out of that comfortable armchair, with the comfortable food and sleep that you know will be there. Don’t worry, it’ll be there when you get back. But go and have an adventure. You’ll learn a lot more in just a few days roaming out in the world, from practical problems, to meeting people who “do” in the real world.
2. Be versatile: Yes, it’s good to have a specialty. It’s great if you’re a master at it too. But be open to other aspects, other interests. Always approach situations with an open mind, and an eager heart. Learn to be interested in various aspects of a particular thing. One-dimensional views can be misleading, and won’t help you build a “system” or “product”. At the end of the day, that’s the aim.
3. Learn to code: It’s my greatest regret. And I know that’s it’s indispensable today. (Though I myself agree somewhat with this, but still I prefer my own #6)
4. Take charge of your life: Don’t let life happen to you. Make life happen. To quote Marley, “Live the life you love. Love the life you live.”

# Work in Progress

I have been writing a few patches recently, mostly related to moving parts of main-thread I/O off the main-thread and few related to the JS engine, mostly associated with the ES6 spec. Though I am still learning and picking up things, it has been quite a good experience so far.

1. Already merged are the String.prototype.repeat (Bug 815431) and the iterator methods of Sets (Bug 869996), fixing minor deviations of iterator Map, Sets and Array prototypes from the spec (Bug 875433).
2. I am working on implementing Map#forEach and Set#forEach (Bug 866847) and Array.from and Array.of (Bug 866849). Self-hosting has been the choice in these cases, it has turned out to be pretty good, though I sometimes miss the flexibility of C++.
3. I had also undertaken the work to self-host Array.sort (Bug 715181). Though I am kind of lagging behind in this, but still I have managed to implement Tim Sort in JS (I fear it to be very much a broken implementation – because half the browser including devtools stop working), run it through benchmarks on JSPerf, and the results have been pretty impressive and I am getting drastic speed boosts. But need to spend some time on this so that it is spec complaint and the tests stop failing.
4. In working on async I/O I came across this key manager of the URL Classifier module, that was using blocking I/O. I am converting it to off the main thread I/O with OS.File (Bug 867776, 879724). It was some pretty old code and I had to spend some time figuring out what to do for the test cases.
5. Among other things I worked on fixing a bug on PopupNotifications (Bug 864895), making the Alarm API preserve a few more milliseconds (Bug 877888), removing AudioBufferSourceNode.gain (Bug 880265).

But my schedule is a bit tight now, with my intern going on as well. I don’t plan to pickup new bugs any time soon. On the other hand I have started working on Google Summer of Code project (Bug 335448) and its going to be a while before I bring the module to a basic working stage, and I have been sneak-peeking into the bug for doing a read-ahead on Linux every now and then (Bug 865387).

# Tid-bits from my GSoC

The community bonding period is currently on, and I am talking to my mentor. We having trying to decide the nitty gritty details of the project.

Here is my original project proposal that I had submitted. We have also set up the tracking bugs on Bugzilla to track the progress of the work. Bug 335448 will be the main bug and any other depending bug will be added to this only.

There has been slight change of plans as well, we plan not store the user searches fully anymore, instead use the Places API that currently handles the bookmarks and history to extract our relevant information. We plan not use SQLite for data storage, but flat JSON files because now the data to be stored will be minimal. Also Autosuggest Search Engines will be a module in itself.

So that’s all for now! I’ll be posting the next developments here.

# Grite: Blogging for Hackers

Last night I sat down and built a simple blogging platform, that lets you write based on GitHub Gists. I most blogging platforms are an overkill when you ‘just’ want to write (yes, including this blog of mine). There has been recent rise of static blog/site generators like Octopress, Hyde, etc. But these need to rebuild the static site in case new content comes in.

GitHub Gists offer a clean way of sharing text snippets, formatted by Markdown if you wish so. So why not have a blog that aggregates your gists in the form of a blog?

Grite does exactly that. Its a clean, minimalist and responsive blogging tool, fully powered by client-side JS. You just write your gists and update the configuration file directly on GitHub online, without cloning the repository on your machine. Boom! Your blog is also updated, nothing to rebuild. Check out the example site.

You don’t need to do anything to set it up as well. Just fork it on GitHub, write your gists, and edit the configuration file. Give it a try, and let me know!

# Google Summer of Code it is

This summer I will participating in Google Summer of Code working on the Autosuggest Search Engine project for the Mozilla Firefox web browser. So I will begin by introducing myself.

I am Sankha Narayan Guria, (sankha93 on IRC), a second year from Indian Institute of Technology Jodhpur. I have been contributing patches to Mozilla Firefox project for quite sometime now, and recently I have been trying to work on a few bugs relating to implementing the ECMAScript 6 spec. You can find me on the channels #introduction, #developers, #jsapi, #devtools.

I will be trying to make searches from Firefox a bit more easier by automatically detecting whether you are doing a search or not when you submit a form and then present the user to add the search engine to the browser. A beautifully detailed description of the project has been written by Felipe in his blog.

You can find all the GSoC related posts under the tag ‘gsoc‘.

# Simple chatrooms with Redis

Redis the in-memory key value store, provides very efficient storage of data structures and is amazingly fast. Its pub/sub system can be used to create a simple chat room or message broadcasting system for your server with zero code on the backend to handle the messages. I’ll be using Node.js to build a simple chat room (which obviously can be modified to use a message broadcasting system for your server).

Here we have a channel, and anybody can join the channel as a publisher or subscriber. Publisher pushes messages into the channel, which is then sent to all the subscribers. In our chat client we will be creating 2 connections, one as publisher and other as subscriber because we will need to send and receive messages.

Next we will need the Redis client for Node.js. To install it execute:

npm install redis

We will be creating to connections to the server, one to publish the messages and another one to receive the incoming messages. To create a server we have:

var redis = require('redis'),
client = redis.createClient();

We will just need to handle the events from now on. In case of error, we handle it gracefully by:

client.on('error', function(err) {
console.log("Error: " + err);
});

When we receive an incoming message, we get a message event:

client.on('message', function(channel, message) {
// we are printing on screen, you can do whatever you want
console.log(message);
});

Once the client has subscribed, the subscribe event is raised:

client1.on('subscribe', function(channel, count) {
// we can publish anything in the channel
process.stdin.on('data', function(text) {
client2.publish(channel, text);
});
});

Just make sure you subscribe the client to the channel.

client.subscribe(channel);

Combining all these and a little bit more, I have written a minimal chat client.

With this we can build a high performance message broadcasting for the servers, with very little code handle the transfer of data in the channels.

# When I dreamt of being a Game Developer

You read it right! It was back in my school days, early days of when I had laid my hands on computer. I knew only QBASIC and Microsoft Visual Basic 6.0 back then. Like any kid, I loved computer games, and more than that used to think of building one. Game concepts used to come in my mind, I could see myself standing in those 3D worlds of fantasy.

Few days back I managed to lay my hands on the game that I had created back in class 9. Pardon me, but it were the days of Macromedia Flash back then, and I had just played enough with Flash 5, that my dreams of making a game re-ignited again. And there I was, played around with ActionScript and cropped graphics from various sources (video games, rendered images from Maya 4, etc.). Oh well, I didn’t know of any game engines, so I hand-coded the full player movement to collision detection. It was definitely a learning exercise. And what is a game without sound? Hence, ripped off sounds from various sources, put my own fading effects to simulate distance in the game. And here is what I ended up with:

Sorry, cannot give it out in public due to multiple copyright infringements it will have if I do (otherwise how will I get my favorite sound track in my game? ). But what I ended up with is a game fully developed by me and one month wasted for it.

### Back to today

I run away from game development, though I encourage anybody who wants to build one. Maybe the experiences from my first attempt haunt me!

# Take care, it’s Floating Point Arithmetic

Yesterday night, I was just idling on IRC and happened to come by an interesting discussion that was taking place there. The original issue was that doing Taylor approximation used to give identity for very small numbers, which gradually turned out to be an enlightening discussion. Thanks to Boris Zbarsky for clearing my doubts on this topic.

This post is a note to self (and others as well) so that I can keep them in mind in future.

For example we want to calculate $e^x - 1$. By the normal Taylor Series expansion of $e^x$, we would get:

But if we want to add them in a computer as $x + \frac{x^2}{2!} + \frac{x^3}{3!} + ...$ then you would probably get a correct answer. But if you were to do the same for a very small $x$ you would probably end up getting $x$, which is not correct.

The correct way out of the problem would be to use something like $\frac{x^3}{3!} + \frac{x^2}{2!} + x$. The reason being for a very small $x$ the correct answer is “basically $x$“. So for this we would need to use:

• Next term error estimation to decide how many terms we would want
• Add the terms from smallest to largest

This gives as some important insight into floating point arithmetic. For example we just want to add the following floats $1$, and $2^{25}$ instances of $2^{-25}$. So what is $1 + 2^{-25}$?

You would say almost $1$ (even I thought so). But to the computer that is exactly one. This where floating point arithmetic turns evil, because single precision floats only have $23$ mantissa bits. So the rest of the thing is rounded off, and you get one.

But if you start off by adding with the smaller guys, they can actually accumulate and give the correct result. So if we add $2^{-25}$, $2^{25}$ times and then add $1$, we would get $2$, quite opposite to the previous result.

Floating point arithmetic is not arithmetic we learnt in school. Its not commutative nor associative nor distributive. It also implies that just because these properties are not satisfied, compilers cannot optimize floating point operations either. The same reason why you have -ffast-math to tell gcc just to do your floating point operations fast and not care about the correct answer at all.

# Bootstrapping Mozilla Devs – Mozboot

This February our college fest Ignus witnessed the meet-up of like minded people who wanted to contribute to FOSS and Mozilla – reason Mozboot @ IITJ – a flagship event to get people introduced to the world of free and open-source software and give them a head start to contribution to the development of Mozilla Firefox.

The first day was utilized for getting the attendees acquainted with the world of Free and Ope-source software and the freedom it provides you. We organized a mini-hackathon to get them the feel of using open-source tools.

Next day, the day of the prime event, we started off full fledged with Mozilla. Saurabh Anand joined us all the way from Delhi to get people started with development of the Mozilla Firefox. We talked a bit why contribute and general terminologies like the mozilla-central repository, Bugzilla, etc. Obviously Josh Matthew’s FOSSDEM slide deck saved the day. Then we guided the participants to setting up their system, getting the dependencies and the mozilla-central source tree. Once done, we started the build process. In the meantime we had Shree Kant Bohra and Paras Kuhad to introduce people to Python and Django.

Once the build process was completed, Saurabh talked about the brief procedure to work on a bug, the review process and how to create a patch. We then showed them Bugs Ahoy and select a bug of interest and start reading about it. After sometime most of the participants had one bug selected and were reading about it. We told them to ask questions on IRC in case they faced any problems.

We used an Etherpad to share links and put up the bugs selected by the participants. The Etherpad can be found here.

The event was a success with the first of its kind by the Mozilla India Community, where people actually selected the bugs they wanted to work on and were getting involved with it. To ensure that their participation is maintained we are following up with them to track their progress. We generalized the event and have come up with a format to organize the developer events by the community here.

And this was one of the big events by Programming Club, IIT Jodhpur – one event that brought a lot of people from different colleges together.

At the end of the day going to Mehrangarh Fort to see the spot from which Bruce Wayne rose from the well in Dark Knight Rises didn’t hurt either.

# Back to Bangalore

This January I was back to Bangalore once again. This trip was a great one. There is something different about Bangalore – the kind of awesome people you get to meet there, and the ambiance as a whole is great!

One workshop, that I will never regret attending. From the MIT guys we interacted with to the other attendees, the bunch of people that this workshop brought together is incredible. I was in the Tangible User Interfaces track with my instructors being Anirudh Sharma and Daniel Leithinger. I got introduced to the values of inter-disciplinary work and the level of innovation that can be reached through it. A way to find innovative solutions to problems from our daily lives or how we could make certain things easier.

My project was to design a human posture detection kit, something that could trace how we move our hands, whether the posture we are in causes strain in the body, etc. With this we planned to study the ergonomics of the human body.

Finally we came up with our prototype system – a gloves equipped with flex sensors and haptic feedback mechanism connected to an Arduino board. A couple of hand-made pressure sensors that we made by sticking together sponge strips and aluminum foil. What we generated was interesting data on how different hand movements and working conditions affected the stress conditions on our hand. Using the pressure sensors that we made we could generate pressure gradients for seats, using which it was possible to figure out how people sit generally. Our haptic feedback mechanism, we could provide feedback to the user in case of any erroneous or potential harmful posture.

We have open-sourced the code at https://github.com/sankha93/biosense/.

### Firefox OS App Days

A trip to Bangalore is always incomplete without some open-source or tech meet-up. Last time I came here it was JSFoo 2012. This time it was Firefox OS App Days, a series of global events conducted by Mozilla to get people to know and develop apps for the Firefox OS platform. It was a great experience interacting with Matt Basta and Arun Ganesan who flew all the way from the Mozilla HQ to Bangalore for the event. Moreover, it was my first time as Mozilla Rep I was attending an event and meeting the full Mozilla India community.

After the little intro by Matt and Arun about Firefox OS, it was Hackathon and people came with real cool apps for Firefox OS. Few of us were busy providing tech-support and getting people started on building apps for Firefox OS. By the afternoon, I could see people presenting apps on education, real-time content sharing and information search apps powered by Wolfram Alpha, etc. And guess what? All the teams with great apps won a free Firefox OS Developer Preview Phone.

So another trip to Bangalore, well spent! (And a few other incidents that happened and I am not blogging about! 😉 )

# It’s (never) over

It was over. He knew it.

He gradually started moving memories of her out of his life. He changed his 57 passwords. He changed his SSH passphrases to refer to “the-brown-fox-who-jumped-over-lazy-dog” instead of her. He stopped the SMS updates on Facebook. Moved her to a less important list. He stopped coming online at that specific time of the night. He reworked his schedule so that he did not have to meet her every now and then. He did not unlock the phone’s screen every now and then to check if he had missed any messages from her.

He channeled all his emotions elsewhere: towards anger, towards solitude, towards work, towards football, towards coding. Anything except her.

It seemed to work. He was forgetting about her.

A week later he saw her again. He knew that he couldn’t have her, because he was too chicken to go grab it when the opportunity was there. He saw the biggest failure in his life ever.

He will never get over her again.

– Adapted from “It’s (never) over” from yuvipanda.in

# The power of Communities

Communities are awesome! Not because I am saying so, but because I have tried and tested this out. I am talking about our own Programming Club.

There was a time when, people would say there was no flow of information from the “pro”-s to the people who wanted to learn. They didn’t know where to begin, where to start. The need was there to bridge this gap.

At the same time, Facebook was one thing that was used the most in our institute ( I don’t need to give any justification for this 😉 ). So why not make Facebook a medium for consumption of information, make it the channel for everyday discussions that should be there?

So, one random day, the Programming Club, IIT Jodhpur group was born, over a random idea that spawned when Nishchay and I were talking. The group started out small in number. We did not add everybody we knew. We wanted the group to evolve – to grow into a community. We started out by posting different links ourselves, commenting on each others post and so on. Reason? For the culture to start of asking questions out in a group and sharing stuff that we discover, somebody has to take the initiative and do it.

It evolved just as we expected, it behaved as a community a mini-social network. The people we added, added their friends and this ripple effect grew. So the group that stood at 15 members for the first few days now stands at 329, and we are still growing.

The spirit of sharing knowledge also came by itself, it was not only us that shared the links, but people came and shared tid-bits of info that found all over the web. They began to ask questions. And it worked better than StackOverflow, where things are formal and you are answered by somebody you do not know, here you would get instantaneous answers by the seniors themselves, or anybody who knows the solution.  That’s the power of the community – you know you help, because next day when you will need help there will be somebody else there for you. It connected seniors, juniors, alumni, outsiders and even faculty alike on the common ground. We could see our group becoming useful when we used to see teachers as well as alumni joining the discussions.

Sometimes discussions have been productive, sometimes inflammatory. Newcomers have asked questions and got their answers. But what we have accumulated in the process is perhaps a vast knowledge base of our collective efforts. Its perhaps greater than any wiki could provide. We can scroll down the group to see the posts back in the early days or use the search feature in the group (I wonder how many of us use that) to throw us the relevant information.

That’s the power of creating a community around which people want to connect and share. Join the Programming Club community now.

# Trends in Developers

I tried to measure the relative trends that go on in respective developer communities. Say for example, whether Ruby people are more active than Java developers. How do they compare with each other, by the use of different metrics and if we could deduce any important conclusions from that.

Before I begin, I would like to make an important confession: I am in no way any data scientist, nor have too much of education in statistics. I have just tried to analyze the trends using standard tools and techniques. Maybe my inspiration was:

The best way to get started in data science is to DO data science!

First, data scientists do three fundamentally different things: math, code (and engineer systems), and communicate. Figure out which one of these you’re weakest at, and do a project that enhances your capabilities. Then figure out which one of these you’re best at, and pick a project which shows off your abilities.

I wanted to try some real world data collected by me, so I turned to the Github APIs and collected the following metrics about some random 2,600 projects for the languages Java, JavaScript, Ruby and Python:

• Watchers –  People who are following the project, but not contributing code to it
• Forks – People who have created a fork and making their own contributions to the project

Both my assumptions are the ideal case. I assume the watchers are following the project, while people who fork are contributing code (though in many cases, people may not make any changes to the forks).

I first wrote a Python script to pull out data from Github on some projects for each language and store them into CSV files. The Search API came of help here.

This creates datasets for the languages with columns in the order – name of project, owner of projects, number of watchers, number of forks, if the repository is a fork or not. Since Github doesn’t list projects by language without a search keyword, we iterate over all the alphabets to get a list of 2,600 repositories.

Next just to compute it by the number of forks for Java vs. JavaScript, I sort the datasets for Java and JavaScript by their 4th column, ie. the number of forks and then plot one against one. I tried to fit a linear model in the data with a zero intercept to find the best fit line. These computations were done using R.

### Java vs. JavaScript

It yielded a linear model:

javascript = 3.609 * java

Thus we can notice that the tendency to fork is more in the JavaScript developers than Java. JavaScript folks like to take some project and then make changes or contribute to it more easily compared to Java.

I did the same computation for the number of watchers by sort them by column 3 of the original dataset and make appropriate changes to the code.

This yielded a linear model:

javascript = 7.22 * java

This result confirms that the there are lot more JavaScript developers who follow other JavaScript projects compared to the Java developers.

### Java vs. Python

After trying to compute it by the number of forks for Java vs. Python here is what I got:

The linear model came out as:

python = 0.7672 * java

Thus we can see the trend-line is more oriented towards Java, giving us a conclusion that Java developers fork repositories more than Python devs and try to make changes or contribute.

On doing the same analysis for watchers,

This result was a bit surprising, the linear model came out as:

python = 1.423 * java

Thus in the Python community there are more watchers for other projects compared to the Java community. So Python people love to follow a project more, when Java devs prefer forking it and contributing it.

### Python vs. Ruby

The results of the number of forks for Python vs. Ruby is:

This gives a linear model:

ruby = 2.743 * python

The trend-line is more oriented towards the y-axis, ie. Ruby, concluding that Ruby devs fork a repo much more are compared to a Python developer. Rubyists like to jump into it, and make changes right away.

For the number of watchers:

This gave us:

ruby = 2.329 * python

I don’t need to say much. Rubyists follow others projects more than the corresponding Python devs.

### Conclusion

We can figure out important trends between different programming languages by comparing different aspects together and we can figure out certain important facts, like Java developers like to fork more than Python developers while Python developers like to follow others projects more. Rubyists fork and follow the projects more as compared to Python people, etc.

Its a nice way to learn and analyze different trends developer communities. More can be done, this is just a scratch on the surface.

# My little build notifier

Building the Mozilla source tree takes quite some time on my laptop, I’ll tell the truth, I love to have my fair dose of Facebook and Twitter and other other social networking sites in the mean time. Well, switching to the Terminal window from time to time just to check whether the build is complete is disruptive!

I run a Linux system, I have libnotify installed so why not put it to good use? I had written this side project called Coocoo – a tool to send notifications to different systems over the network (read wifi in our college). I left it incomplete and moved on with other things, things like an Android app to receive the notifications in phone never got built. But one thing that it could do is sent notifications from one Linux box to another via libnotify.

So lets put it to some good use and let my system notify me when the builds were done, instead of me checking it everytime. So I wrote a shell script:

So I started the notifier on my system using:

python notifier/coocoo-linux.py

and executed mozbuild.sh and went on to do something else. Voila! The notification was there when the build completed.

You can find Coocoo on Github at https://github.com/sankha93/coocoo

# Becoming a Mozilla Contributor

Firefox is one of those open-source projects that I have used since its version 1.0 and have been using it since then. Since this July, I started contributing patches to the project. Contributing and helping develop something that I love to use and giving back to the community and helping develop a product that so many people use daily is something awesome. In this post I’ll share my experience as a contributor.

I started off as a newbie, some basic programming knowledge (I am not a Computer Science student anyways), but always wanted to give back to the community. I think this is what sets Mozilla apart from the rest. They welcome new contributers and a very well documented docs give a good boost to people who are starting off with developing stuff.

1. The initial step for anybody would be to build Firefox from the source, the details of which can be found on their MDN wiki. Once I had the initial build done, I wanted to work on something that would be really very easy to solve but at the same time get me familiarized with the source.
2. Luckily, Mozilla had this thing called mentored bugs, where we have mentors to guide anybody working on these. The easiest way to find out a bug to work on would be to use Bugs Ahoy by Josh Matthews.
3. Once you find the bug that you want to work one, you can get the bug assigned to yourself and then start working on it right away.
4. Once you are done, create a patch and post it for review from your mentor or the owner of the module you are working on. They may suggest changes, then just update you patch accordingly and post it once again for review.
5. Once you get a r+ (ie. the patch is approved), your patch is tested on Mozilla Try Servers and once it passes all tests it will land in the source tree. Thats it, you are done with your first patch! Just repeat these steps and you start working on your next patch.

My first patch was for shifting the position of the Web Console Window from the top to bottom of the window. Although I making that change was easy, I had to update the tests as well. It was the first time in my life that I ever wrote a test. My mentor for the bug Mihai Sucan helped me readily with it, and I had no problem writing my first tests.

The experience is really amazing, you can hang out on IRC, talk to anybody and ask for help and people are there to help you out with any problem. Another thing that I do often is add myself to the CC list of a bug that I am interested in and so that when any new development occurs I am notified. That way you get to learn how that part of the code works and what the patch is doing.

You get to interact and work with a lot of great people, which perhaps you will never get in your university. I have worked with Josh Matthews, Victor Porof, Yoric, Jared Wein, Ms2ger, Boris Zbarsky, etc. (sorry if I am missing someone) and they are really helpful and helped me out with anything that I got stuck on. A tweet that I came across really captures this spirit:

The thing I really learned while writing my patches was that, the people who have mentored me in the Mozilla community actually actively encourage inquisitiveness. People ask each other questions and help each other out or they say who else in the community may know about it. This openness is on of the greatest spirits of the community, which also helps newcomers to get easily associated with such an enormous project.