1) Does my application have to be aware of where a web-request is coming from and respond with the the static files pointing to the correct cdns?

2) How does the Internet know what server is closest to the user?

3) Which part of the Internet knows this?

I will try to answer these in order.

The short answer to the first question is “No”. An application need not figure out where a request is originating from and embed appropriate static urls. In short, this would be an inappropriate solution simply because it would not scale — Scale in terms of the CDN. What if a CDN decided to remove/add new servers in a country? He would have to inform all subscribers/clients about the new/removed servers !!

So how does the Internet automatically resolve this?

The short answer to this Anycast addressing. Anycast addressing is  conceptually a method on the Internet by which several endpoints on the Internet advertise the same IP addresses (typically resulting in a conflict when these are withing a LAN. I am sure you have seen IP address conflicts). The point to Anycast addressing when it comes to CDNs is that all servers that are geographically spread out can publicize the same IP address. What this does is that when a DNS Resolver (insert link here) tries to resolve a1.akamai.com/image it will always receive the same IP address from DNS servers irrespective of whether the resolver (conveniently viewed as the client) is located in Australia/Asia. However when the client tries sending out a request to the resolved IP address, different routers in different parts of the world understand this address differently. How is this done?

Enter Border Gateway Protocol : A simple mechanism using which routers can speak to each other and advertise their ability to reach particular addresses. So when 2 routers advertise to a Router R1 that they can both reach “1.2.3.4″ with weights x and y respectively, it is R1′s prerogative to chose to send messages intended to 1.2.3.4 via either of thses based on which advertised a cheaper “reach” mechanism. This essentially is part of the shortest path finding mechanism that the Internet has incorporated.

To answer the third question ,Servers setup by a CDN advertise the same IP. DNS resolvers even resolve these to the same addresses at all points on the Internet. However, the routers are the gatekeepers that chose to route to the correct edge-of-the-Internet thanks to shortest path finding mechanisms that are hacked around. The router simple thinks that it is sending a request out through via the shortest path that it knows to the IP. The fact that these are different servers that are potentially in different geographic locations is not known to the routers. Ah… how we hack!

There are parts of this article that I might have over simplified — like DNS caching and DNS Resolvers. However, the best way to understand how the Internet “works” is to view these as orthogonal concepts that are built keeping each system’s autonomy in mind. Hence over-simplifying is the right way to go. Forming a holistic view will happen with time.

State Space Explosion is what limits checker from being built at run time. So what do you do? Build some abstractions over some things in your program and keep asserting these at all points. For eg: My mutex C program should never call unlock or lock twice continuously– clearly a cause for deadlock. This is a predicate that is invariant over the lifetime of a program (Did I just say lifetime? Rich Hickey influence I guess). Now, how does one make these abstractions? Remove all lines of code in your program that are not associated to the assertion(s) you are making and retain just those that are.

Fintd the state space and you are practically done. This may not have been a simple task in terms of the programming work involved with building the tool. But there are several gaps between what I would expect a tool to do and what SLAM and BLAST accomplish.

Many of the thoughts and conclusions I have expressed on BLAST may be premature since they are predictive more than experiential. In the interest of analyzing how BLAST would do “on the field”, I was forced to take the (bold) predictive approach. BLAST (like SLAM) is designed to check if software conforms to the recommended behavioral properties of interfaces that are used — much like unit-tests that seem like BLAST’s design-driving runtime counterparts. Like UT, BLAST has the overhead of needing a specification from a programmer. Since it requires this meta-data (meta-code actually), I tend to feel that it is most beneficial in cases where the test is to be run on several pieces of software that need to conform to a common specification — Eg: Windows Drivers need to conform to interfaces provided by the OS’ API. In such cases the return on investment on the meta-code will clearly be high.

It is also interesting to think of what it would take to rewrite BLAST for other (some dynamic) languages. Several difficulties that may have (possibly) been encountered with regard to providing memory safety and pointer aliasing intelligence tend to get trivialized with languages like Java that provide well-managed memory. There is a necessity to abstract a piece of code into a boolean program to control the state space explosion that is a run-time consequence of having a “rich” type-system like C does. Drawing from that, rewriting BLAST for a duck-typed language like Ruby can pose challenges in other domains too. Contrary to what may seem, the state space explosion problem will only be more acute in duck-typed languages. Hence it may be necessary for BLAST to bring in a pseudo-type system into itself  in order for any meaningful predicate/propositional assertions to be made before a Ruby program runs —- a bit of an irony. In either of these language-types, I find that the specifications (meta-code) can often communicate intent better than the code itself (much like unit-tests).

Another interesting aspect of the implementation is how the atomicity of operations has been handled. When a statement long pval=0 is encountered in a program, the ART constructed assumes that Predicate(pval == 0) holds true after that statement. It is clear from this that BLAST will not handle multi threaded software. The assumption of all assignments being atomic can cause havoc in most languages (C included). Although this may be more related to the non functional way the code is written and the static nature of the mechanism, it is still fair to expect that a tool understands atomicity of operations in a language and constructs its ART considering other threads running (in the same process). This may bring us back to the state explosion problem once again on account of the numerous orders of execution threads may assume. Intuitively, languages like Clojure that support immutable data structures may tend to benefit/tolerate the static nature of the atomicity that blast proposes. I am thinking of building an equivalent tool for a language with immutable data structures for a final project.

This blog is about model checking or checking every state of a finite state automata system just so as to make sure that some undesirable states are unreachable in real time. To make this sound more human,  you want to exhaustively test a system by  bringing it to all possible scenarios(states) that it can encounter during the course of its life and ensuring that none of these scenarios get it to misbehave. Quite like any normal tester would want to do.

However the need to formalize the concept comes in only because of the practical difficulties involved in bringing every system to all states and testing it exhaustively.  This is particularly applicable to software and prog languages.  For example, if you are writing your program in a language that supports complex types i.e most object oriented languages, you are basically in an infinite state space. Even simpler languages that have not support for OO techniques are difficult to exhaustively test. If your language supports long numbers for example, every possible that a particular long variable might assume might introduce a new state in the program. Technically your program could show behavioral difference only selectively i.e  if long_var>1000 perform_action1 else perform_action2. However, there are still infinite state spaces in the above case if (say) comparison in long variables is not an atomic action in the language that you are programming. Concurrency will bring in infinite state spaces #fail

In the past week I have come across so many papers and tools that do exactly the same thing and call it different things. SLAM from Microsoft is the original (I think). All these software and code testing tools bring in some sort of abstraction or modelling into the system and then exhaustively test the space that can be occupied by the code. Clearly, the abstraction reduces the states that can be occupied. In the case of SLAM this abstraction seems to be by reducing C programming Language’s type system to only a boolean type system, clearly removing the infiniteness of the space caused by complex types. Quite ingenious.

Whats been striking is the number of other tools that seem to be doing things that are similar. I do not want to trash any of these on a public post, but this one in particular was just unavoidable.

State explosion of software systems is just a complex way of saying that it is not possible to exhaustively test software. Knuth’s famous “I have not tested these algorithms but only proved them to be correct” yada, yada are causally related to this. Inspite of model checking mostly stating the obvious, I loved the math. Quite analogous to a reason I like programming. Not too many people seem to get it.

The book has several rare and interesting cases of neural (mal)functions and VSR conducts some ingenious experiments to diagnose these cases. Almost every case is a bizarre, seemingly incomprehensible neuro-psychiatric case and the experiments are typically aimed at disproving some ingenious yet incorrect Freudian Explanations for the syndromes and identifying precise scientific explanations using the known neuro-anatomy of the brain. At the risk of sounding like a stereo-typer, it is quite scientist like

Phantom Arm and the Inappropriate Pun

One very interesting syndrome explained in the book and this video is that of the Phantom arm. It is a syndrome that is experienced by people who have lost or had their hands amputated as a result of some accident/surgery. The syndrome being that they continue feeling sensations in the non existent arm, sometimes severing pain (sorry about the inappropriate pun) in a part of the hand that does not exist anymore. Hence phantom. VSR beautifully explains why the pain is caused.

What a hack by Evolution!!

Before the arm was amputated, it was found that several of these patients had their arms attached to a sling for several months (because of a fracture / severely damaged tissues). When the brain issued a “Move” command to the arm and the arm refused to move there occurs some learned paralysis. Apparently the brain looks for a visual feedback from the eyes expecting to hear that the arm is moving. Since there is no such thing the brain is forced to learn the paralysis. ( Quite a hack for something that is a result of million year long evolutions). And this learned paralysis is retained, even after the amputation.

Watch the video to see how VSR treats the paralysis in an arm that does not exist.

Identifying the  Separation of Concerns in DEBUG mode

Every case in the book was diagnosed fascinatingly. All cases explained were seemingly rare. By conducting a series of experiments on the patients, their oddness in  physiology and psychological behavior were mapped to the specific parts of the brain that had been affected. This is really the way medical researchers identify the separation of concerns in the neuro-anatomy. Sort of the same way how you would identify what part of your code is responsible for doing what? By removing some part of the code, and seeing what blows up in your application.

One more Pun

Thank God all my code has unit tests.

Non Atomic Entities and Functions Spread over Time

One great issue confronting OO programmers is that Objects are actually composite entities that take intermediate(unexpected) states over a time dimension. A reason why functional programming languages thrive today. The brain seems to be having quite the same problem. There are clearly 3 independent functions that moving your arm is composed of. a) Sending out signals to move it b) Responding with ack c) Getting visual feedback by seeing it move. If any of these composite behavior were to fail, you would acquire a learned paralysis. Quite a high risk situation.

Functional Programming getting ahead of evolution?

Immutable datastructures, pure functions and the likes seem to have surpassed evolution in achieving larger atomicity of functionality. Maybe its because we have not yet programmed anything as complex as the human body! But the possibilities theoretically exist atleast. I pride myself of my ability to understand Darwinian Selection and I am quite stunned why it has given us a chance to think we are doing better than evolution in coming up with functional programming! Maybe it is really this chance to think that you have bettered  evolution that is reffed to as mutation.

Befuddled as usual.

It is interesting to think of how human beings actually avoid such intermediate states while exchanging ideas/arguing. Think about this (not so) hypothetical situation:

Person1: I want no hierarchy in the organisation that I am working in!
Person2: Eh? Every decision that you take, you are picking one choice over another. You are establishing hierarchy right there
Person 3: (Boing! But I still want to work in a place with no hierarchy)

How do we manage to keep minds stable and keep belief systems from toppling over in such conversations. Is it because we have managed to keep our thoughts completely decoupled from each other? Or is it because we have really made sure our belief system is simply just protected from rationality(selectively).

Why is this really something that cannot be done with code? Selectively have a purely functional/rational part? And then another part that is state based? Every (commercially) successful functional programming language (Clojure say) has a story to say about a functional part and a non-functional state based part. It all maps together beautifully if you ask me.

For the sake of convenience, I have taken a small block of code that you can write with eventmachine (Ruby’s most popular gem for building evented apps).

require 'eventmachine'
require 'em-http'
require 'fiber'

def asynchronous_call
  current_fiber = Fiber.current
  puts "making calls"
  http = EventMachine::HttpRequest.new("http://www.google.com").get :timeout => 10

  puts "declaring callbacks"

  http.callback {
    puts "resuming things";
    current_fiber.resume(http);
  }

  http.errback {
    puts "resuming things";
    current_fiber.resume(http);
  }

end

EventMachine.run do
  asynchronous_call
  puts "its all over"
end

##making calls
##declaring callbacks
##its all over
##resuming things

Its easy to see how cumbersome it gets to  debug evented code apart from the fact that it may get less cohesive progressively. Taking a bottom-up approach to debug nested calls is painful. Obviously it is possible to thread your way out of the situation and get things in order. However, that would tend to contribute to making the code less cohesive as well.

Fibers are a construct in ruby that are not essentially a concurrency construct but can effectively solve some of the same problems that threads intend to. Fibers are really nothing but coroutines that can simply be entered at several points and exitted at several points as well. In fact, a subroutine is a specific strain of a coroutine where there is only a single entry and exit point.

require 'eventmachine'
require 'em-http'
require 'fiber'

def asynchronous_call
  current_fiber = Fiber.current
  puts "making calls"
  http = EventMachine::HttpRequest.new("http://www.google.com").get :timeout => 10

  puts "declaring callbacks"

  http.callback {
    puts "resuming things";
    current_fiber.resume(http);
  }

  http.errback {
    puts "resuming things";
    current_fiber.resume(http);
  }

  puts "pausing fiber until call is complete"
  Fiber.yield
end

EventMachine.run do
  Fiber.new do
    asynchronous_call
    puts "its all over"
  end.resume
end

##making calls
##declaring callbacks
##pausing fiber until call is complete
##resuming things
##its all over

Obviously a cleaner way to structure and write evented code. Not only do co routines help you clearly bind the order of execution of code to the order that is apparent, but they are quite efficient in memory as well.

Unlike threads, Fibers are blessed with a memory stack of 20KB each. Every time a coroutine/Fiber is paused and restarted, the overhead of switching context is avoided since the memory stack is .. well already available.

Clearly this comes at the limitation of not having 100s of Fibers concurrently paused. It will simply blow your stack. However, with the above example the cohesiveness they bring into the code is commendable.

Its important to bear in mind that Fiber i not really a concurrency construct. Threads are. Clearly understanding the differences and similarities will help writing better evented code.

If you wish to understand more about Fibers in Ruby, here are a list of must read articles.

The online application was written in a conventional MVC where some of the models made REST api calls(and you though they were all ActiveRecord?), parsed and returned results that the controllers could understand.

The jobs used these models in exactly the same way the controllers did except that these processes were off-course offline and each job invoked the model methods 1000s of times.

At the end of the project we came to a point where we wanted to parallelize some of these jobs to get them to run faster and it was clear quite immediately that the blocking calls made to the REST APIs were the biggest bottlenecks. For starters, parallelizing these calls could save us time. These were the factors that had to be addressed as part of this:

1. All calls were being made from inside the models that were clearly unaware (in a good way) of whether its methods were being invoked by (online) controllers or by (offline) jobs. What this meant was that a lot of code that was written in the model was tuned to being invoked from a request-response pattern following system. This meant that there was no effort to keep the model’s code thread safe as like most conventional request-response patterns. What did this mean? A good amount of refactoring to write thread-safe code.
2. Some of the most common xml-parsing libraries in Ruby (the likes of Nokogiri and HappyMapper) are not thread-safe.
3. Ruby is not really the king of concurrency. Threads in ruby are provided to make parts of your code concurrent. This concurrency is unfortunately not pushed to the operating system but is instead handled by the ruby interpretter. What this means is that a threaded application can never really directly benefit from increasing the number of cores on your processor since these are run as sub-procs of your ruby-interpretter process. This is a topic that requires much larger a debate and I am not going to address it as part of this blog. Lets assume for now that Ruby’s concurrency is not so cool!

For me no 2 was the most compelling reason to rethink our strategy. There was no way I am going to write a thread-safe xml parsing library of my own (in the interest of time and personal-ability combined).

I remembered a chat  with Mark Needham where we were speaking about pushing the concurrency out of `your` system. The riskiness involved in refactoring, replacing the core libraries in the system in the last few days before release clearly suggested that pushing the concurrency out of the system would win it for us. Here is what we did!

Before the jobs are run, we made a quick computation of all the rest urls that were going to be hit during the course of running the job. We hit these from the job with the help of some asynchronous libraries like typhoeus. The calls were not only asynchronous, but we also ensured that the rest of the job would not wait for the responses of the jobs to come in but would simply continue.

What we also did was to put a forward proxy (Squid FP) caching all responses between out system and the rest services. What this actually did for us was that, once the calls were bundled and made asynchronously, all calls would simply get cached at the FP that would handle the asynchronous nature of the http responses. And the jobs would simply continue running hoping that when the calls are made the equivalent calls have already preemptively been fetched into the Forward Proxy. Improved our job performance by over 100%.  Clearly a win as a result of pushing the concurrency onto squid and out of our system. #win
Off course, from an OO perspective, we did remove the cohesiveness of the Rest API calls from the models. But by inserting a decorator in between the models and the jobs/controllers, a clear strategy could be devised to avoid this cohesion removal. #refactoring

Wiki Link. Use this in cases where your DSL seems to have a hierarchy. The hierarchy can be established  by data/logic i.e Tasks & SubTasks, Parts & SubParts.

class Part
  def initialize name
    @name = name
  end
  def weight
    0
  end
end

class Hand < Part
  def initialize
    super("Hand")
    @children = []
    5.times {add_child Finger.new}
  end

  def weight #component object
    weight  = 5
    @children.each { |c| weight += c.weight }
    weight
  end

  def add_child child
    @children << child
  end
end

class Finger < Part
  def initialize
    super("Finger")
  end

  def weight #Leaf object
    1
  end
end
hand = Hand.new
puts hand.weight #7

Note here that the complex weight methods have been implemented in the component class and not the leaf class.

Iterator

Composite Objects often are composed of lists of elements that are treated alike. This is particularly simple to accomplish in a duck typed language like Ruby. There is often a need to access individual items in the list. That really is the problem that iterators solve. For the Java folks java.util.iterator & java.util.Enumeration interfaces should strike a Bell. Typical use-case (Java Code):

ArrayList list = new ArrayList();  //Composite Object
list.add("java");
list.add("c++");
list.add("ruby");
for(Iterator i = list.iterator(); i.hasNext();)
{
  System.out.println("Language:" + i.next());
}

Although these are inherently a part of the code that you may write everyday, it pays to have an understanding of the problem that iterators essentially solve. There are essentially External Iterators. External since they are external to the Composite Object that they iterate.

Ruby on the other hand has internal iterators. Here is what is internal about them.

list = ["java", "c++", "ruby"]
list.each do |language|
  puts "Language: #{language}"
end

The difference here clearly being that the logic that you wish to apply in an iterative way is passed as a code bock to the composite object. Its clear from this example that internal iteratirs are an inherent part of languages that support closures. In this case the method each takes the code block to be applied iteratively.
Here is a nice article that explains the pros and cons of using different types of iterators.

Command

Wiki Link. Clearly, the closures in Ruby are bound to have an influence on the command patterns. As explained in the Composite pattern above, we can maintain commands as a bunch of proc objects. This example however is meant to demonstrate cases where there is a need to remember states. Hence the more conventional approach to solving command problems.

class Command
  def initialize(description, proc1, proc2)
    @description = description
    @function =  proc1
    @inverse = proc2
  end

  def execute
    @function.call unless @function.nil?
  end

  def unexecute
    @inverse.call unless @inverse.nil?
  end
end
class CreateFile < Command
  def initialize
    proc1 = Proc.new do
      puts "File Created"
    end
    proc2 = Proc.new do
      puts "File Destroyed"
    end
    super("creating new file", proc1, proc2)
  end
end

class CheckMemory < Command ##ireversible
def initialize
  proc1 = Proc.new do
    puts "Checking Memory..."
  end
  proc2 = Proc.new do
    puts "Mem Check need not be reversed"
  end
  super("Checking memory avalability", proc1, proc2)
  end
end

class Installer
  def initialize
    @commands = []
  end

  def add_command command
    @commands << command
  end

  def install
    @commands.each {|c| c.execute}
  end

  def uninstall
    @commands.reverse.each do |command|
      command.unexecute
    end
  end
end

installer = Installer.new
installer.add_command(CheckMemory.new)
installer.add_command(CreateFile.new)
installer.installinstaller.uninstall

I had a chance to be a course coordinator, a role that was made up to act as the assistant to a placement coordinator. So the experience and the emotions that I express here are validated beyond the common Joe’s point of view. Kuberan, a very good friend of mine and I played this role not just once but twice. He did most of the donkey’s work. I was witness.

As a grad there were just 2 things that I heard so often from folks around when asked what kind of a job they wanted. These classifications are not just misnomers, but barely represent what graduate students use as the classifiers.

1) Management Job

2) Technical Job. (Further classified as Core Job for the non Tech Grads. Coding Job for computer-science grads)

What is interesting is that these are the classifiers that grads were expressing. What they really used to classify was.

1) Pay Package

2) Travel Opportunities

3) Exclusivity of the Job (in terms of the number of grads recruited from the campus. Lesser the better)

It really is possible to rationalize each of these criteria with reasons like ‘phamily pressure’. Pretty short sighted if you ask me. After all, we are a generation that is yet to see what it is for an IT engineer to lead a retired life. It is mathematically unknown.

Amidst these things, it was/is at times flustering to see FaceBook status messages “Life Sucks.. Lost something that I was aiming for a very long time!” from grads who were not selected into firms that they wanted to be a part of. Seriously? how much about the job did you really know for it to have been a life long dream?

No more ranting. Now for some advice

1) Dont mix education and jobs. Dont mix jobs and money. These are actually beautifully isolatable concepts. And if your thinking I am wrong by saying this, well it is MY blog post after all. Education, Work and Money are needs.(Work is a need too. Read Dan Ariely’s Upsides of Irrationality).

2) All these are needs at all points of time in life. They are not exclusive to specific stages. Try and find jobs that can offer you clearly isolatable benefits. Benefits like learning, money, travel, chance to meet hackers, chance to attend conferences, chance to pursue your technical interests outside work hours, incentives for learners, incubation facilities if you have a cool idea, freedom to express opinions, freedom to drive the business. I agree that these are things that are driven by the individual and not by the workplace. Well then, why look for a job? Do something on your own.

3)Stop wasting your time trying to compete with other classes and courses and trying to show to the rest of the world that your better. Believe me!  Noone gives a shit about your contest.

4)Stop ranting on FaceBook about how you missed your Dream Job. Disappointments are understandable. But let me tell you this. There is no history (exhaustively) of a deserving grad not landing up in a good job. You think you deserve a good job right?

5)Stop using fuzzy terms like job satisfaction. You have not worked before. You dont know what it means. I did not.

6)Instead of wasting time finding ways to better your competitor courses, spend some time speaking to people who work at the companies that you are looking at. Think about whether you can do what they do to make a living.

7) Prioritize your learning very highly. After a year, any job typically gets boring. Learners will find it easy to switch jobs at this point.

8) If seniors/alumni (which I am clearly now a part of) are disappointed with your class’s performance on the job charts, they can F*** off.

Dont take campus recruitments too seriously. They truly mean nothing. Remember you are in college to get educated. Traditionally, these institutions were never meant to be job fairs. Learn your way through college. I am not going to say “It will pay in the long run”. I am just saying that there is tremendous joy in learning something new everyday. Dont let recruitment drives ruin that joy.

P.S: If at any point, you were thinking “Sure Ashwin, speak on. You have a job now. I know you were no different when you were at PSG”, your argument/comment is exactly my point.