Day 20, coffee script and more data structures

I definitely begun to like Backbone once I knew what was going on. It would still take a couple of projects to really get it though. Since all my personal projects are in Meteor right now, I need to come up with at least one more new project…

Today we also talked about basic network stuff. I heard that an extremely common interview question is, “what happens after the user clicked the submit button of the form?”

We covered:

– client / server. Client sends request and server listens to the request and responses. Server is supposed to be available all the time and wait for requests. HTTP protocol deals with packet loss or entire bundle loss or timeouts(?). Some limitations are server can’t push information to the client side.

– TCP. It is an agreed communication protocol between two computers. An good example is a light house communicating with a ship. They agreed that the ship would use sound to send message first; then they both switched to light signal, communicating using Morse code.

– domain / IP / port / url. Domain name is sent to DNS server and IP addresses are returned. To avoid this extra roundtrip, DNS request is aggressively cached. Domain is like the street address; IP is like the actual coordinates; port is like one person’s name inside the household at the particular street address.

– structure of an url: protocol :// top level domain names :port(optional)?/path/to/file?query_string1=value1#achor_points(only seen by the browser)

– HTTP requests / methods / headers / parameters. Headers include multiple key-value pairs with each pair occupy one line. There is on blank line between the hader and the body. POST has post parameters carrying information while GET has to rely on query strings to carry information. GET works between servers and can’t update images. POST don’t work between servers(?) and can upload images. PUT and DELETE are not supported by browsers (?) and can only be used with other tools.

– cookies. Sent between client and server along every request or response. Only the client side keep tracks of the cookie, meaning the server side is almost stateless. When there are conflicts, the last updated side should win.

– still to be covered: page requests, asset requests, forms, ajax and REST

– alert / prompt are blocking methods

– to read: jQuery’s author’s article on timers

After finishing the sprint requirements, I also had a chance to go back to revisit some of the data structure questions.