Saturday, June 27, 2015

PAUS, Mideval history, pre-islamic middle east, religion - A saga of Wikipedia addiction

I came across the word "PAUS" today in an email and I did not know what it meant. The email did not have much context either. As usual I googled for "define: PAUS" and the smart boy Google showed me the Wikipedia link for some Norwegian patrician family from Oslo named PAUS. I was very sure that the "PAUS" word I had come across had nothing to do with a medieval family from Oslo. Nevertheless being a big Wikipedia addict, I bravely caressed my laptop touchpad, moved the mouse pointer to the Wikipedia link and clicked on it.. ! And the Saga begins.. !

The Paus family has some semi-interesting history, not very intriguing or aything, but still there is something to read. The one piece of information that got my attention, apart from the awesome estates they own, is one of their coat of arms : They call it "Crane in its vigilance". Intrigued by the "vigilance" word I click on that link to see if I will get to read some nice history or myth about some super vigilant crane. I was wondering if it had anything to do with this Crane :


The link took me to this page...!!! It was such a "Duh" movement..! :(

But Wikipedia being Wikipedia, never ceases to amaze me. After glancing over the page reading a little here and there about the bird I came across this section about Cranes in Mythology and Symbolism. Here I found that in pre-islamic Arabia the three chief goddesses were referred to as the "the three exalted cranes". Being a religion history buff I immediately opened the three Wikipedia pages to the three goddesses. I did not read all of it but merely glanced over. I found this very interesting modern depiction of the three goddesses.

                                                                                 Source : Wikipedia

What immediately caught my attention was that the temples of all three goddesses were raided and idols destroyed when Muhammad and his army seized Mecca at the very beginning of the Islamic period. It was also mentioned that a lot about these idols is written in the "Book of Idols". Apparently this book was instrumental in molding the Islamic belief that idol worship is sin. Anyways, religious beliefs apart, the page on this book mentioned about the "founding of Kabba" and I did not know that. As you would have guessed, next I started reading about Kabba.

Contrary to what I though Kabba existed much before Muhammad. There were apparently 360 idols before Muhammad seized Mecca and destroyed them. Amongst several other things, one very interesting incident from history caught my attention. It was the attack on Kabba and the stealth of the black stone by a sect of people called Qarmatians. After this the ruling caliph had to get the stone back by paying a ransom. One can imagine how much of a tremor this would have created in the Muslim world back then. Now I had to know who these Qarmatians were and why they attacked Kabba. Turns out that Qarmatians are a sect of Shia Muslims itself. Their history is pretty interesting. Apparently the basis of forming this sect was their belief that one of their imam was the Mahdi. Who or what is a Mahdi you ask? Exactly the question that came to my mind and I opened the page on Mahdi.

So Mahdi is this prophesied redeemer of Islam who would come back to earth, sent by god himself, and who would cleanse the world and uphold Islam. Pretty standard fare. Almost every religion has such prophecy I believe. Well so far 4 prominent people have claimed to be the Mahdi (very surely amongst several other not-so-prominent ones). Guess what? Out of the 4, 2 have been from India.. !! 50% share man... wohooo..! We really are a country of god-men, religion no bar.. ! :)

One of the two men was "Mirza Ghulam Ahmad" founder of the Ahmadiyya movement in India. This one instantly rang a bell in my head. I had heard and read a little about the Ahmadiyya sect. I immediately started reading about this person. His life history was somewhat interesting not very much though. He had some pretty radical thoughts about interpretation of Islam and Jihad. Like any other god-man he had debates with several religious people, wrote a bunch of books. Apart from that the Wikipedia page on him did not offer anything interesting enough to click and go to a new page.

And at that point this particular Wikipedia journey came to and end.

However, after all this I still did not know what the "PAUS" in the email meant. Surely my work has nothing to do with a medieval Norwegian family.. ! So I went back to the email to try and get more context. Digging through some of the older emails from the same person I finally found what he was referring to.

Here comes the grand ending : ;-)

After all this it was revealed to me (probably by divine grace) that, the sender of the email was referring to nothing but this :


YES.. !! He was referring to PAVS (P - A - V - S).. Pavs as in Vada Pav, Misal Pav, Samosa Pav, Pav Bhaji, etc etc.. !

He had misspelled it. He had put in a "U" in place of "V" and that made me wade through Wikipedia for about 45 minutes and then another 30 minutes writing this blog post.. !!

All hail the PAU.. !

There you go. That's the root of this entire saga. In honor of this epic saga, I am going to eat Pav... oh sorry PAU BHAJI today.

Happy PAUing to you too...! :-) 

Monday, March 30, 2015

Layman's analysis of an ULIP : Bajaj Allianz Future Gain

Recently a friend of mine asked me whether he should choose to invest in a Mutual Fund or this ULIP named Bajaj Allianz Future Gain. The ULIP salesman have apparently been pestering him a lot to invest in that scheme while I had strongly suggested him to not go with any ULIP at all. In my books ULIPs have a blanket ban. My friend Prabhakar Kudva and Dhirendra Kumar of valueresearchonline.com have given me enough information to realize that combining investment and insurance is not a good idea and ULIPs in India are definitely very bad investment options for almost all.

valueresearchonline.com had been a regular critic of ULIPs back  in 2000s when ULIPs had a free run without any check. In those days ULIPs charged insane charges like 25% to 30% and have literally scammed investors. After a lot of noise was made about this, IRDA finally woke up and put in some nominal rules to regulate this kind of practice. It however left a huge holes in the policy for these insurance companies to exploit. Insurance companies are not so closely watched as the Mutual Fund companies are watched by SEBI and transparency requirements are also lower for insurance companies. As a result ULIPs become very risky options for investors because of the exploitation possibility.

Anyways that was the history. Despite all this gyaan, my friend however wanted me to take a specific look at this particular ULIP - Bajaj Allianz Future Gain.

So I tried to do a quantitative analysis of the same to demonstrate how bad an investment option it is.

NOTE : Professionally I am an engineer and finance is just a hobby for me. So calculations below are as per my understanding and hence should not be taken as serious financial advise.

Bajan Allianz Future Gain plan facts (Source : http://www.bajajallianz.com/Corp/content/endowment/future-gain-web.pdf)

Minimum premium : 25,000/- Yearly
Minimum sum assured : 2,50,000/- (10 * annual premium)
Minimum Policy term : 10 years
Minimum Premium paying term : 5 years
Lock in period : 5 years

Premium allocation charge :
1st year : 5.5.% of Annual premium = 1,375/-
2nd - 5th year : 3.75% of Annual premium = 937.5/- per year. (3,750/- for 4 years)

Average yearly charge = (1375 + 3750) / 5 = 1025

Yearly charges so far = 1,025/-

Policy administration charge :
33.33/- per month increasing at 5% p.a. every month
Assuming this 5% is compunded every month at the end of 5 years this value will be 42.77.
So for the sake of simplification let us take the average of starting and ending value as the monthly dedudction

Average monthly dedudction = (33.33 + 42.77) / 2 = 38.05 =~ 38/-

Yearly policy administration charges = 38 * 12 = 456/-

Yearly charges so far = 1,481/

Mortality charge :
For a person aged 30, charge = 1.34 per thousand sum at risk (Deducted at monthly anniversary a.k.a every month)

Sum at risk = Maximum of [death benefit – regular premium fund value - top up premium fund value, zero]
Death benefit = 2,50,500/-
Regular Premium Fund value will keep changing depending the fund performance.

At beginning for first year = (First premium - charges) = 25,000 - 1481 = 23,519
So sum at risk = 2,50,000 - 23,519 = 226481/-
Mortality charge = 227 * 1.34 = 304

Yearly charges so far = 1,785/-

NOTE : The mortality charges will decrease as you pay more premium and also as the fund gains more value. But to keep things simple taking an average value is acceptable for this calculation and to illustrate the point that ULIPs are not really good options.

So for a yearly premium of 1,785/- you get a life cover of 2,50,000/- for 5 years (assuming you do not want to pay a premium after the mandatory 5 years)

Now consider the Anmol Jeevan - II (822) term plan from LIC.
For a yearly premium of 1,617/- you get a life cover of 7,00,000/- for 5 years (Source : https://www.licindia.in/premium_calculator.htm)

So wouldn't it make sense to separate out investment and insurance? For insurance take a plain term plan and for investment choose a decent ELSS scheme. This way your investment will perform much better and you will also have a much better insurance life cover.

Saturday, February 7, 2015

AJAX for beginners - what it is and how it evolved

Today's websites or web pages are very complex structures involving several components. It can be daunting for a beginner to understand it all at once. To ease the process let's break things down and see how the various pieces fit together.

At the core of web pages is the HTML. It is the language that browsers understand and it is what web developers use to showcase rich content. Without HTML all our web pages would have been simple text files. Now I assume that you are aware of HTML and how it is used in web pages. Another critical piece that works closely with HTML is CSS, but we can skip that one for now.

Plain HTML web pages are pretty dull. They are not really interactive. What they mainly have apart from text are :
  1. Some formatting information which tells the browser how to show the contents.
  2. Some media content like images or videos.
  3. A bunch of hyperlinks which lead to other similar web pages.
  4. In slightly evolved pages there would be forms which allowed a user to send data back to the servers.

It is the third one which helped form this "web" of pages which we call the Internet. How do these links work? Pretty simple actually. Each link typically points to a web page on a server. Whenever a user clicked on a link, the browser would fetch that page, remove the existing page and show the newly downloaded one. Some times the link could point back to the same page in which case clicking on it would just "refresh" the existing page. We all know about the refresh/reload button in the browsers don't we?

There are a few things to note here.
  1. These basic web pages were dull in the sense that they were not interactive. They did not respond to user actions except for clicks on links, in which case the existing web page goes away and a fresh page is loaded.
  2. When a link was clicked the browser would decide to send a request to the server. The web page itself did not have much control on when the request should be made.
  3. When the browser was making a request in response to a link click, there was pretty much nothing you could do with the web page until the request completed. Every request to the server blocked the entire page and if there were multiple requests that had to be made it had to be sequential, one after the other. A fancy technical word to describe this would be "synchronous".
  4. An obvious observation is that the data that came from server in response to request from a browser was HTML, as in the data and information on how to display that data were sent back from the server all the time.

While the fourth point appears as not such a big problem, the first three are definitely limitations.

To work around the first problem browser developers came up with JavaScript. Browser folks told web developers that they can make their web pages interactive and responsive to user actions by writing code to handle those interactions in this new language called JavaScript and including it in the web pages. Web developers could now write different pieces of code to handle different user actions. The browser provided a few functions (aka APIs) in JavaScript which the web developers could use to make changes to the web page. This API is called DOM (Document Object Model). Thus web pages became interactive and responsive.

The second and third limitations still existed however. The only way to request data from server was through links or in case of evolved pages through forms. Also the web page was one single unit. Whenever something had to change the whole page had to be reloaded. Imagine something like that with your gmail page. How would it be if the page refreshed every time you received a chat message or worse every time one of your contacts logged in or out of chat? That would be disastrous. The fate would be similar of something like a sports website in which the small corner showing the score needs to be updated a lot more frequently than the rest.

To solve this some people thought of iframes as a solution. Iframe is a HTML tag inside which you can put another HTML page. Now with this arrangement the inner page could be reloaded without affecting the outer page. So the sports website could now put the score part in an iframe and refresh it without affecting the rest of the page. Similarly gmail could break up its page into multiple iframes (It actually does this in reality, but it also does a lot more than this).

With iframes the "synchronous" problem was somewhat solved. Multiple requests could now be made in parallel from a single web page. However the method of making the request largely remained the same, using links or forms. It was either not seamless or almost impossible to make requests in any other manner, like say whenever user typed something (like Google search). Now let's see what all capabilities we have on top of the basic web pages.
  1. Web pages can respond to user actions. Some code can be executed on various user actions made on different parts of the page.
  2. This code can modify the web page using DOM.
  3. Browsers are now capable of making multiple requests in parallel without blocking the web page.

The browser folks now combined these abilities thereby allowing web developers to make requests to servers in response to user actions using JavaScript. These requests could be made in parallel without blocking the page i.e. Asynchronously. Now when the response came back the same JavaScript code could add the HTML received in the response to the existing page using DOM.

The developers went a step ahead and said "why receive HTML every time? In most cases the formatting or presentation information is already there in the web page. What is needed is only new data or content (For example, in the sports website example, all that is needed is the updated score. Information on how to show that score is already present in the web page). So instead of fetching HTML every time let's just fetch data to make things much faster and efficient". And back then the most popular way of representing data in a structured manner was XML. So developers started receiving data in XML format from the server and using that to update the web page. XML was so popular that browsers added support for automatically parsing XML data received in response to these requests.

This approach of making requests and updating parts of web pages became very popular and was much widely used. Since this was predominantly used to make requests over HTTP (The protocol of the web) to fetch XML data this technology was called "XMLHttpRequest" (Internet explorer called it something different, it probably still does).

What all does this XHR offer?
  1. Making requests "Asynchronously"
  2. Making requests from "JavaScript"
  3. Making requests for "XML"

Put together it forms "AJAX - Asynchronous JavaScript and XML".

Notes :
  1. Several things have been simplified here as this is aimed at people new to web development and Ajax in particular. This should nevertheless give a good starting point.
  2. References to XML should be read as " something other than HTML". Nowadays XML has been largely replaced by JSON because of several advantages.
  3. XMLHttpRequest does not necessarily mean making asynchronous request. It supports making synchronous requests also. But I don't know if there is a good reason to do it. Making a sync xhr will block the entire page until that request is complete. Really don't do that.