MVC (Model View Controller): For my Ninth Grader

While talking to my son, I realized that making him understand MVC is tough if I talk all geeky language. So I decided to explain the whole thing in very simple English and bring to the context which he can correlate.

Every high school has School newsletter which is published on period basis, say monthly. For Homestead High it is called, Mustang Pride. Naturally there will be student journalists and editor who will collect material, compile news items and articles. They will also receive the feedback from Mustang Pride readers which primarily consists of Students, school staff and parents. There are certainly some guidelines and rules which sets allow to disallow publication of articles and news items in Mustang Pride. The interaction of all these players can be depicted in following figure.

So with the start of achedmic year, in Aug first edition for year 2012 Mustang Pride is published. Readers give their comments and cuggestions to Mustang Pride’s journalists and editor. After take comments and suggestions into consideration and depending upon material available in their repository and under the rules and guidelines of the newsletter, Sep edition of Mustang Pride is published.

This interaction keeps on going every month.

This interaction has very interesting aspect. Readers want to read what they like as per their taste and pass that to journalists and editor. But editors cannot publish anything and everything; they are bound by guidelines, rules and material available with them. This check keeps system in balance.

Now translate this whole thing into computer systems.

Model is one who has repository of data and rules.

View is one which is shown to user. It is user facing aspect of model

Controller is one who interacts with user and update Model and influence model about what view should be shown to users.

Instead of paper version of Mustang Pride, lets’ make online version of it. For example purpose, Mustang Pride web site has very simple format.

Page 1: At this page user can select month and year of Mustang Pride. On click of month of a particular year, user lands to front page of that month of Mustang Pride (Page 2).

Page 2: Front page of Mustang Pride of a particular month lists various articles and news items and link to them. On click to that link, user lands to that specific article or news item.

Any other page: These are article/news item specific page. Each page has content related to article/news article, hyper link to next and previous page.

These pages constitute View part of the equation. In human body you can compare View to Skin, which is visible part.

There should be some repository of contents (articles and news items) and rules which affect what to be shown to user. This repository can be simple text files or database which stores content. Rules can be written any programming language – Java, PHP, Pyton, etc. Suppose depending upon users (say student, school staff or parent) you decide to show different material (hence View). These rules will reside in Model. In human body you can compare Model to Brain.

Now we have Model and View. A user sees View and Model is repository. But, how users interact with online version of Mustang Pride. This interaction happens via Controller.

If a user clicks on next on a certain page, what to be shown next? If user click on month for a particular year, which page to be shown to him? Controller carry these questions (may be with partial answers) to Model. Model answers these questions and shows appropriate page (View) to user. Controller is like your nervous system which carries messages from your skin to brain. In response brain updates itself and updates your skin (by blush or any other way).

Why programmers implement use MVC, why not MV (Model View). User sees a page and asks for next page and this logic can be embedded in View itself. Yes, this is doable and smaller computer applications do the same. But think about big applications (where Views reaches into hundreds or more). If any change to be implemented, one need to change multiple places and chances of error increases. MVC keeps the logic centralized, so maintenance is easier. Second aspect is complexity. Think about complex computer applications like bank, insurance, stock trading, retail, etc. These applications are immensely complex due to numerous types of users – various types of customers, various staff members with varying roles and responsibilities, various government officials, etc., complex logic. If all aspects are not arranged nicely then think about mess.

Though I have taken example from web based application but MVC is equally useful for non-web based applications as well.

Book Review: Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement

Book Review: Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Eric Redmond: Publisher- Pragmatic Bookshelf: ISBN- 13: 978-1934356920

Seven Databases in Seven Weeks is excellent commentary on contemporary databases. Eric’s background in database has helped in shaping the content.

Book covers seven databases which span from RDBMS to various flavours of NO SQL.

• PostgreSQL- traditional relational database;
• Riak - key-value database;
• HBase - columnar database;
• MongoDB - document-oriented database;
• CouchDB - document-oriented database;
• Neo4j - graph-oriented database, and
• Redis - key-value store.

From this list Object oriented databases are missing which seems to me OK as thier adoption is very limited and I feel they are dying specie.

The last chapters and two appendixes summaries whole book in addition of CAP theorem which add golden feather to book.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: I do not thing there is any book available which covers so many databases in so few pages.

One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Seven-Databases-Weeks-Modern-Movement/dp/1934356921

2. Publisher – Pragmatic Bookshelf: http://pragprog.com/book/rwdata/seven-databases-in-seven-weeks

3. PostgreSQL: http://www.postgresql.org

4. Riak: http://wiki.basho.com/Riak.html

5. HBase: http://hbase.apache.org

6. mongoDB: http://www.mongodb.org

7. CouchDB: http://couchdb.apache.org

8. Neo4j: http://neo4j.org

9. Redis: http://redis.io

OAuth 2.0: For My Ninth Grader

Tom is recently suffering from chest pain. Today he is with Dr. Michael for medical checkup. While talking his, Dr. Michael came to know that Tom had a heart procedure done few years back at Healthy Heart Institute and also ulcer related procedure at Good Body Medical Center.

To complete his medical investigation, Dr. Michael calls up Good Body Medical Center and asks for Medical records of Tom. Good Body Medical Center has all of its record online, Dr. Michael is asked to login to Good Body Medical Center and get the medical records of Tom. At Good Body Medical Center website to access Tom’s records, Dr. Michael is asked to provide Tom’s user name and passwords. Tom gave his user name and passwords to Dr. Michael who key in the details and get his all medical records.

In this case, Tom has no control over what information about his, Dr. Michael can access. It is ALL or NONE scenario. Apart from that if ever Tom changes his password for Good Body Medical Center website, Dr. Michael loses privileges to access his records until unless Tom passes him new password.

Now Dr. Michael requires data from Healthy Heart Institute. He calls to Healthy Heart Institute and asks for Tom’s medical records. Healthy Heart has little bit different way to access patient data.

As first Institute asks Dr. Michael to register with Healthy Heart Institute and provide Email address where patient’s (not only Tom’s) medical records can be sent. Dr. Michael complies and provides Michael@Chest-Doctor.com as email address. In turn Healthy Heart Institute provides a Doctor ID and Doctor Password to Dr. Michael.

Now Tom log in to Healthy Heart Institute and shows desire to share his medical records (for heart procedure only, not for the toe surgery) with Dr. Michael. Healthy Heart Institute provides Authorization Code to Tom and asks him to email the same to Dr. Michael. Dr. Michael sends Tom’s Authorization Code, his Doctor ID and Doctor Password to Healthy Heart Institute using his registered Email address. In turn Healthy Heart Institute sends a unique token to Dr. Michael. Using unique token, Dr. Michael can now access medical records of Tom.

Next time when Dr. Michael needs medical records of Tom, he approaches Healthy Heart Institute web site and supply the Token he has for Tom. Similarly Dr. Michael can access records of other patients using his Doctor ID and Doctor Password and token to be provided by respective patient.

If you notice here, even if Tom changes his password for Healthy Heart Institute web site, Dr. Michael can access his data without any problem.

Now let’s visualize the understanding we got in terms of software systems.

OAuth is a set of specifications which allow one application to access information about a user (human or machine) from another application. OAuth is also used for cross authentication, means one can login into application using his facebook account. This feature essentially facilitates single user name and password across applications.

To understanding purpose, keep yourself at place of Tom; replace Dr. Michael with a blog which asks you to login into facebook to comment and Healthy Heart Institute by facebook.

Yash is essentially an End User or Resource Owner. He can be human  or another computer. Blog is Client who will access information about End User from Resource Provider (facebook). Doctor ID is now Client ID. Doctor Password is Client Secret. Dr. Michael’s email address is redirect URI or Redirect Endpoint. Facebook has two parts. Part one is Resource Server which essentially means this computer has all data about End User which Client can access if End User has given permission for the same. Part two is Authorization Server which manages user name, passwords, permissions, and Authorization Token about End Users and Client ID, Client Secret, and redirect URI about Clients. We will be discussing Authorization Endpoint and Token Endpoint down the line.

In above picture Unique Token is not depicted. Unique Token essentially mapped to Access Token and facilitates Client (Dr. Michael/Blog) to access data about Tom/Yash (User). So if there is one more patients say Lucy with Dr. Michael and had some procedure at Healthy Heart Institute. In this case Dr. Michael will have a separate Access Token for Lucy.

To facilitate, facebook login to post comments and show some info about Users, this blog needs to registers itself with facebook’s authorization server. Blog supply redirect URI to facebook authorization server and in turn gets Client ID and Client Secret.

So Yash is reading a blog entry and like to post his comments on it. This blog is using facility to post comments using facebook credentials.

This is first time Yash is going to post his comments on this blog so computers need to work little bit extra. Yash clicks on “login using facebook” button which results a pop up from facebook which prompts Yash to key in his facebook user name and password. On submit of pop up, Yash’s facebook user name, password & permissions (End User’s facebook credentials & permissions), blog’s (Client’s) Client ID, Client Secret passed to facebook. If all is well, facebook redirects Yash to a page (redirect URI) where he can key in his comments. Facebook also supplies an authorization code to Yash. Under the hood, Blog gets authorization code from Yash and using that gets Access Code and Refresh Code from facebook.

Yash has posted his comments and moved on. But Blog has now access to his facebook account (not full but as per the permissions he has given like user_about_me). Now Blog can access information about Yash even if Yash changes his password.

Do not panic! Yash can login into facebook and revoke permissions given to blog or invalidate the Access and Refresh Token.

In real life, Authorization server may not like to give an Access Token to Client which never expires. Also due to security concerns, permissions associated with Access Token may be less than the granted by User. To alleviate these concerns, at the time of issuing Access Token, Authorization Server also issues Refresh Token. Refresh Token is used to get fresh Access Token.

We have not discussed yet about Authorization Endpoint and Token Endpoint. Authorization Endpoint is an URI which is accessed by End User to authorize itself. Token Endpoint is also an URL which is accessed by Client to get Access Token.

Holistically OAuth has brought standardization across web which facilitates:

1. Standardized way of communication among applications for authentication and authorization purpose. 
2. User need not to share their credentials (username and password) to cross pollinate data across application.

Review: What is DevOps? Infrastructure as Code

What is DevOps? Infrastructure as Code by Mike Loukides is in response to NoOps at Netflix.

Mike takes historic route of It operations and narrates how today’s IT operations has evolved. In the article has mixed up hardware, software (application) and networking aspects but still he nicely take us to evolution journey. If has taken little deep dive into interface between ops and development team that certainly added meat to article.