Monthly Archives: April 2016

Being Stupid

So my struggle with long distance trains doesn’t seem to stop. This time, just like the last time, my train got late. By 30 days. And I am to be blamed for it.

Like Will Smith says in ‘The Persuit Of Happiness’, ‘this part of my life is called being stupid‘, after trusting a hippie with his expensive scanner and realizing how bad a decision it was. I had the exact same feelings this morning about myself. Let’s rewind two weeks. I had to book train tickets for attending a wedding function at my native place, Karwar, on 29th April. As always, I did so from the irctc.co.in portal, and got three confirmed seats for May 28th. Awesome, I said, knowing how hard it is to get tickets during the holiday season. Got the confirmation email with all details and I was good to go.

Today, in the morining, we were all set. All dressed up and ready to start our day journey. We don’t usually do day travels since it is too hot in the non air conditioned coaches that we usually book our tickets in. Anyways, it was going to be fun, I thought. Called up the railway enquiry number 139 to make sure train was on time. Surprisingly, it said the charts weren’t prepared yet. Odd, because the train left the originating station a full day ago. Must be a technical glitch, I thought. Made sure I took everything; Misty, mobile phone, charger, water bottle and what not. Great. We left for our train that was scheduled to be departured at 08:10 in the morning.

The station is just a few kilometers away. We reached there at 8 sharp. Reaching there, I immediately started to look for the platform where our train was expected to arrive. The indicator didn’t say anything. Must be a fairly new train, I thought, trying to bury the little doubt I was starting to have. Let’s ask the station master, said my uncle, and so we went to the station master, to get some solid confirmation.

The station master’s office was a large room with a table in the center. More like a bollywood movie’s police station. The man there was wearing his shirt then. We entered and he asked us what was the matter. I asked him about the status of our train, numbered 22656. He thought for a second before quicky replying that the train only ran on saturdays. Damn! That wasn’t possible. I had a reserved ticket in that same train and it showed today’s date. Station master asked us for the ticket. I showed him the eticket on my mobile phone. Now he was confused. He called up someone on his intercom and asked if there was this particular train running today. The other guy said the same thing, this train only runs on saturdays. Umm. Weird. Station master tried to confirm it by asking if there was any additions to its trips. The answer must have been in negative.

Now we three were real confused. We tried to reason the possbile explanations. ‘Maybe the train is so new that even the station master doesn’t know about it’, said my uncle. Meanwhile the station master rang another number, this time of the previous station, called ‘Vasai Road’. He asked if any train with the said number had left the station or is scheduled to leave. No, was the reply. We thought for another few seconds when suddenly, with a little frustration in his decenly polite voice, the station master said, ‘This ticket is for 28th May’. I went silent for five full seconds. With my tongue stuck out, all I could say there was ‘sorry sir’. I and my uncle came out silently, glad that he didn’t swear at our stupidity. Okay, MY stupidity. We came out, and had the greatest burst of laughter. For him, it was funny. For me, a little less towards funny and a lot more towards the incoming embarassment. I, with my 17 years of schooling, couldn’t tell May from April. Stupid. Very, very stupid. We went to where my parents were waiting. I told them, smiling and trying to make a poker face simultaneously. My mom, got so furious that she actually started to laugh. Things were pretty serious, and yet somehow, that was so stupid that no one knew how to react.

We thought for some time then, and decided to go in some other train in the unreserved compartment, which, if you know, you know the struggle and if you don’t, you’re pretty lucky and rich. I am still in the train, tired, sleepy and dirty with sweat and dirt all over me. I’ll reach in three or four hours, and then it will be life a usual.

Googling And Asking Better Questions

Like many of the things you do in your lives, Googling is an art. Getting to the right page that you were looking for, with the right set keywords and clicking the right links, all this seems to be quite random and uncertain, but once you get into the groove, things become natural and predictable. Finding that random song you heard on the street is no big deal, and neither is finding the article that you had read couple of years ago, the only part of which you remember was the author’s last name. Information is growing each day, and having the right set of tools always within you is so much important. Yes, there’s that shiny history feature in you latest Chromium browser with sync, so that you never lose your tracks, but knowing how to find something on a totally random public PC without having to look into your history is very convenient, also cool.

But then, you might ask, what is the point of remembering a whole new set of rules just so that I could type in proper queries on Google’s homepage? Yeah, if you think about it this way, not much. Every other site has a search functionality built into it. But, think. Googling for a computer problem with site:stackoverflow.com and searching the same problem on stackoverlow’s search is somewhat different. Stackoverflow doesn’t invest as much time on search optimization as Google does. That is the case when stackoverflow’s search is one of the best you can find on the Internet. Think about others. Now, every site having its own search has its own small set of advance search syntax. Would you go around memorizing rules from each and every site that you visit? Are you not better off memorizing for just one site and using it to find everything else? In my opinion, yes.

And learning how to google or how to search in general doesn’t just mean memorizing the dorks, although it does certainly help. It generally means asking better questions. What does that mean? Well, in general, the more you research before asking a question, the more are the chances of you getting a proper and to the point answer. That doesn’t just apply to online searches, but also when asking for help to your fellow classmate or colleague. The research helps in a number of ways. Firstly and most importantly, it can spare you the need to ask for help by finding the answer yourself. Secondly, research also helps to properly understand your problem’s causes, such that any similar problem can be solved with the same approach. Thirdly, it creates a psychological difference in the mind of the answerer when he or she reads a “this code doesn’t work” and a “this code throws a undefined variable error on line 42” and a “the ‘name’ variable on line 42 is undefined as the async function on the previous line hasn’t returned yet.”. As you see for yourself, the third problem definition is far more probable to get answered, and the first one is likely to get ignored (or worse, downvoted, if you’re on StackExchange).

I have people who send me program source code files in emails and the only line of text inside of the email being the obvious title that ‘the code doesn’t work’. That is where the problem lies. When all you say is ‘it doesn’t work’, then the only reply that you deserve is ‘congratulations on figuring that out’. It’s that simple. And to understand the importance of it, you need to value the time of others.

So how does one turn from a naive help addict to his or her own problem solver? The answer is simple, know what the problem is and start searching for already answered questions. You always have documentations and manuals at your disposal, but let’s face it, it is not easy to get hold of manuals if you’re new to the subject. And even if you’re well versed with the topic in hand, you can always save time by searching the popular forums first. So what do you do? You search for the exact problem message, or keyword, keeping it as concise as possible. Trust me, the query string is all that matters, because rarely you’ll encounter a problem that somebody else didn’t face and asked somewhere. You want to keep the variable count low, and so if you’re learning A, use popular libraries and operating systems B and C that would keep the entropy factor low. As an example, if I’m not hacking into linux core and simply programming Javascript, I prefer to use Debian and Nodejs stable, just to make sure that when I fall into a ditch, the ditch is a popular one.

In case you still didn’t get a working solution, now start to dig into documents and manuals. It is usually the case when the component that you think is broken, isn’t actually broken. Look out for platform specific notes and details. Troubleshoot your way backwards to the line where your code broke. If you manage to find that out, then you know the problem. Start by making a fresh google search for that error. In most of the cases, a forum thread might have the answer, which you can find easily with [SOLVED] in their titles. There are also many instances when if you are working with an open source dependency, you’ll find the issue raised by somebody on the project issues section of their repository [like github issues page]. Reading those has helped me countless times.

If even then, in the rare (very rare with computer problems) case that you still haven’t found a solution for your problem in the online forums and documentations, start by properly defining the problem. It is time to ask for help. Always, ALWAYS remember, the people you’re asking questions to, are busy people. If you want to have a percent chance of getting your question read by experts, value their time. The essential things that must be included in every help request are,

  • Precise problem definition with the problem and the current and expected results.
  • Steps to reproduce it. Code snippet that points the line of error (You should never paste 200 lines of code into the question).
  • What have you tried yet. List of the things that didn’t work out.
  • The platform you’re running, everything relevant to the problem. More the detail, better is the understanding of your situation by the reader.
  • A paste of your latest logs relevant to the error. Learn to use pastebin like sites to paste large text files.
  • The links to those similar problem-answers that didn’t work for you.

Add or remove things depending upon the situation. It may or may not apply every time. Important thing here is, try to be a problem solver. Don’t be part of the problem, but try to be part of the possible solution. It is okay if no one answers, but hang there for the first 30 minutes at least, in case someone asks for more details that you didn’t provide.

This should really answer your question, and in case not, don’t lose hope. There are hundreds of specialized forums that you can head to, if the problem is that important to you. Back to Googling, what is it that some people better at finding stuff on the Internet than others? Now you know the answer to that. See, this is how it generally works. Most good questions are answered. Now that you know how good questions are asked, you know what is inside them. You can make a pretty educated guess about what an existing question may contain. Now your task is as simple as just using those keywords to find that answer. This works. Trust me.

Concluding it, I hope this post was informative. Ask wise questions. People really appreciate when you ask good questions. They say no question is stupid. That is not an excuse to not trying to search from the existing resources, or being a naive help addict. Keep exploring.

WebSockets

If you’re like me, then you must have gone nuts on hearing about WebSockets for the first time. We now have a totally independent protocol that will not terminate connection after a request-response cycle, which means all hacks to keep a persistent connection from the browser (long polling, I’m looking at you) would now be part of the history. Welcome to the world of WebSockets.

Let’s start with the Wikipedian and Mozillian definition of WebSockets, to get some initial traction.

Wikipedia says that..

WebSocket is a protocol providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C.

Mozilla Developer Network says that..

WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.

To begin with, let us all make sure we have websocket support by clicking . Assuming you do, let’s begin. Web browsers provide us with the WebSocket class. To create a websocket, we simply need to

let ws = new WebSocket('ws://server.com/endpoint');

This gives us a websocket object which supports methods like send() and close() and event listeners like onmessage and onerror.

Creating a nodejs instance running a websocket server is easy with modules. I did try to do it natively, but it went too tedious. Finally I settled for ws module from npm. The server side code looks trival.

On the browser, things are even simpler.

// call the object constructor
var ws = new WebSocket('ws://nagekar-ws.herokuapp.com/'
// attach a message listener
ws.onmessage = function(msg) {
	console.log(msg
}
// send some message
ws.send('hello server!'

Once we call the constructor, an HTTP GET request is generated to initiate the transaction. You’ll find that these headers are sent by your browser.


GET / HTTP/1.1
Host: nagekar-ws.herokuapp.com
Connection:Upgrade
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:ut0NjBQxxBnmtUStHfMUDw==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.108 Safari/537.36

The ones to notice are the URL, which begins with ws:// protocol. Cross domain requests are allowed. This initial step requires the use of HTTP(S) or web, hence the name ‘web’ sockets. The ‘Connection:Upgrade’ and ‘Upgrade:websocket’ and what requests the server to change this connection to a socket one. The Sec-WebSocket-Key header is what client sends to the server. The server crafts another key with this and returns it back in the response header. A response header looks like this.

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Sec-Websocket-Accept:7CAJHdL7QMG4ceqd0M1O8SDbM2Q=
Sec-Websocket-Extensions:permessage-deflate
Upgrade:websocket
Via:1.1 vegur

On receiving the Sec-Websocket-Accept header, the handshake is completed, and now the client and server are connected via persistent sockets, ready to perform both way message delivery.

Click ‘Connect’ button to initiate WebSocket handshake. The server will respond with a timestamp every 2500 milliseconds. Also, the server will echo back everything to send at it. The close button will call the WebSocket.close() method which will terminate the connection.

Message Box






Pretty interesting, isn’t it. Things get even more interesting when you use a readymade library built on top of WebSockets, such as Socket.io. It supports all browsers (through fallback to XHR/polling), has better looking APIs, is easy to use and allows you to broadcast without having to worry much about raw connections. If you’re going to use these WebSockets in production, there’s no reason not to use Socket.io. Using native websockets is not recommended if you’re planning to support some legacy browsers. Even Mozilla terms it as an ‘experimental technology’. Check out the compatibility table for more information.

I hope this post was informative. I did learn a lot while researching on this topic, and I’m glad I did. As always, thank you for reading. Please drop a comment in case of feedback or correction.


Event Driven Programming

I remember starting to learn Javascript. It was all a nightmare. Functions used to execute out of order and seemed very random. There was chaos all around, and I was usually left wondering, ‘what is the order of execution here?’. Of course, that question never got answered, because that wasn’t the right question. The right question would’ve been, what drives these functions in this code.

Fortunately, I asked it at an early stage. The things that make Javascript tick are called events. Without these, your browser window is just a dead canvas. Not just the browser, but other Javascript environments as well, work because of events. And when you understand it, events and event driven programming are probably the most intuitive form of developing applications. Events are not difficult to visualize, once you start to relate them to the real world events.

Suppose you’re alone at your home. You’ll need to make sure you open the door in case someone arrives. There are two ways of doing it. First way is to periodically keep checking if someone is outside the door, say every 5 minutes. In the best case, someone will arrive the moment you open the door, but in the worst case, a visitor has to wait for about 5 minutes before you make your next visit. This is just ridiculous. It is inefficient (visitors have to wait for you) and waste of time (when you check but no one has arrived). Who does this? Well, most procedural languages work this way. And it works, for their use cases. But when you’re dealing with real life scenarios, like checking doors or handling HTML form responses in browsers, where the time of completion of an action or arrival of a visitor is unknown, a better approach has to be used, especially when time, muscle and browser resources are so scarce. Here comes event driven programming.

Suppose, you’re alone again, in the same house. But this time, you decide to make use of events. You install a doorbell. Now, whenever someone arrives and rings the bell, you know you have to go open the door. That’s simple. That’s event driven. It doesn’t matter if the next visitor comes after a minute or after an hour. You’ll open the door instantaneously, without waste of your own time. And the fact that most homes have doorbells and this is our natural workflow when dealing with similar situations, is the proof of how intuitive this programming paradigm is.

Okay, that was cool, so far. But I know that I have to listen to a doorbell and then on hearing it, walk to the door to open it. How do I make the machine do that. The answer is callbacks. If you are not quite sure what they are or how they work, do check out my other article on how callbacks and event loop work. So essentially, we attach a ‘callback’ to an event. The callback, as the name suggests, calls back when the event occurs, and lets us control the aftereffect. Such a callback is also called an event listener, which infact is what you attach to the element.addEventListener('event', callback); when working in the DOM. In Nodejs environment, you get a custom EventEmitter class that you can use to emit and listen to events. If you haven’t heard of it, socket.io is all about custom events and the data transfer between the client and the server. It makes use of websockets along with XHRs. If you are into creating sockets and data interexchange between remote hosts like I am, socket.io is for you.

Finally, I hope to have given you some insights of event driven programming with Javascript. Not a lot of code, but that is something you’ll find everywhere. I always like to emphasis on the concepts rather than implementation. It makes for a better implementation.