2014 in review

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 670 times in 2014. If it were a cable car, it would take about 11 trips to carry that many people.

Click here to see the complete report.

Understanding REST

What is REST?

The concept of REST (REpresentational State Transfer) was introduced by Roy Fielding in 2000, as a part of his doctoral dissertation. Basically, he described an architectural style that exploits the existing technology and protocols of the Web, including HTTP and XML. So, we can define REST as a scalable architecture for building services on a uniform interface(HTTP) focused on resources.

A resource can be anything from IT infrastructure elements such as servers, computers and includes web pages, scripts and other entities as well.

REST is considered to be a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL). Some of the popular REST API services are used by Google (Google Glass API), Twitter, Flickr and Atom. Despite being simple, REST is fully featured and supports everything that Web Services can do.

Continue reading

What is WCF anyway?

Window Communication Foundation (WCF) is the new unified “communication” framework for Windows. It takes all the best ideas from the existing communication models provided by Microsoft and attempts to merge them to form a single logical model.



It has become the “default choice” for connecting applications today. Most of the WCF functionality is found within a single namespace System.ServiceModel.dll (introduced in .NET 3.0).

Continue reading

Let’s Learn Ember : Ember Architecture

From this post onwards, I will continue my “Let’s Learn Ember” series by delving into the application components that make up the Ember.js archnitecture. You can refresh your Ember.js basics in my last posts that dealt with installation stuffs and the object model of Ember.

Let’s get started with the very basics of Ember architecture. It is very important to know how components are coupled together in Ember because Ember has a very unique way of doing things. Even a little mistake here or there may cause hours of headaches! 🙂

But before we dive into Ember.js architecture, it would be a good idea to understand how applications are developed generally.

Server-side MVC

Most of the web applications are built using MVC pattern. The following snapshot outlines the standard workflow of a server-side MVC application. This is the procedural way of delivering the content from the server to the browser.


  • A request from the browser or any Httpclient is sent to the server.
  • The server contains the application and processes data returned from the request.
  • The router first process the request url and dispatches the correct behaviour. It is responsible for filtering out which behaviour the browser wants. It dispatches correct controller that renders a particular view or template that is delivered to the browser. The view can an html, javacript or json.
  • The data is handled by Models and the controllers have direct access to the models.
  •  Once the router knows which controller should take action, it delegates the responsibility to the controller. So the controller handles everything from that moment on.
  • The data is retrieved by the controller via different models. It then dispatches a new view that is to be delivered to the browser.

Client-side MVC

The architecture of Ember, however, does not work the same way. The entire application is centered in the browser in Ember. All of the controllers, views, models, routers are stored in the application in javascript.


  • First of all, the router processes the each request url correctly and maps it to the appropriate controller.
  • The controller then renders a view , which in turn renders a template.
  • So far, the architecture may resemble the server side architecture. But the difference lies on how the models are dealt with in client-side architecture. Since, Ember.js follows clients-side MVC  pattern, it might not be feasible to store the data on the browser or any other client end-points.
  • Hence, Ember.js introduces the concept of “Store”. It is an object that handles the responsibility of retrieving and saving data in form of models.
  • Router has the responsibility of retrieving the content from the store which in turn retrieves the models and respective data to the controller.
  • So controllers simply manipulates what’s in the application in client-side and not in the server-side.
  • Each component share a partial responsibility towards one another. The controller manages views and interacts with the router. The store manipulates the models. All the data comes through the store. Router is responsible for accessing those models into the controller.
  • So, the model data passes through the router which delegates the information into the controller, in form of a proxy.
  • If the view wants to access the models in order to represent its data, it needs to ask the controller which in turns proxies the request to the model.
  • The main catch here is that there are multiple controllers in memory in client-side architecture. There will one controller for list of items, another for a single item and so forth. Each controller has a single responsibility.

Naming Conventions

To understand the naming conventions implemented by Ember, let’s take an example of a standard request for a list of bookmark items. When the browsers makes a request for a list of bookmarks items, there should be corresponding route, controller, view and model. If anyone of them is not present, then Ember creates them for us via active code generation pattern. It is of utmost importance that one grasp the standard naming convention of Ember, as it will ease the learning process.


In my post, I have tried to explain the Ember architecture, while contrasting the server-side architecture with client-side architecture.In the coming posts, we will look into each application component in detail, starting with Router.

Till then, Happy coding!! 🙂

Let’s Learn Ember – Observers

After a one-month break, I am finally continuing my “Let’s Learn Ember” series. In this post, I will delve into the in-and-outs of Observers. Let’s get started!


Observers are those objects that “observe” any property including computed properties in Ember. We can achieve this by setting up an observer on an object using the “observes” method on a function.


Let’s start with a computed property “fullName” defined as below. It depends upon the properties “firstName” and “lastName”. This means that whenever any one of the property changes, the value of the computed property is updated.


Continue reading

Let’s Learn Ember – Computed Properties


Computed Property is one of the interesting feature that Ember provides which helps the users build a clean Javascript interface. As defined by Ember in its official website, a computed property lets you declare a function as a property. As we create a computed property as a function, whenever we call this property, Ember will automatically invoke this function and treat its return value as the value of the computed property.


In the example illustrated below, we have created a computed property called “fullName”, which depends upon the other two properties “firstName” and “lastName”.

In the above example, we have created a computed property “fullName” by injecting property method to the function so that this function will be declared as a property. The parameters “firstName” and “lastName” passed to this function (computed property) denote that the value of this property depends upon these two properties. Whenever we access this computed property “fullName”, this function will be called , which will in turn gets the properties ‘firstName’ and ‘lastName’ and returns the value.


One interesting feature to note here is that whenever there is any change to the properties that the computed properties depend upon, the value of the computed properties is dynamically updated upon their invocation. This is illustrated in the example below.

Example - Computed Properties

So, we observed that computed properties help to relieve the server load to some extent, as it does not generate the content based on the properties. The server need not render all the data as the data is manipulated and new content are created based on them. The usefulness of computed properties will be accentuated while using templates, which we will cover in later chapters.

So, in this post, I gave an overview on the computed properties, illustrated with an example.

In the upcoming post, we will look into Observers.

Till then, Happy Coding!! 🙂

Let’s Learn Ember – The Ember Object Model

In this post, I will delve into the Ember Object model.

Ember has adopted more of an object-oriented model unlike Javascript. The Ember.Object is the main class for all the Ember objects from which all the almost every object in Ember.js is derived. This Ember.Object is the basis for creating all the views, controllers, models and the application itself. Consequently, all the objects share the same core capabilities as they all have been derived from a same object.


Now let’s create a new object in Ember. For that, we just need to use the function create() of Ember.Object class as shown below.


If an object literal is passed to the create() method (which is totally optional), then it is defined as the properties on that instantiated object. In the above example, we have defined a property called “message” and passed it value “Hello World”. Even though, we are just creating a simple Ember object with a single defined property, if we look up this object “emberObject” in the browser console, we can see that there is a lot more going on behind the scenes. Continue reading