Thursday, April 25, 2019
Sunday, August 14, 2016
Tuesday, April 15, 2014
- He wasn't born in a royal family; so ruling India isn't his birth right
- Potholes on Gujarat's roads rival lunar craters while Karnataka roads are like Hemamalini's cheeks:
- Gujarat farmers are committing suicides in droves
- The Narmada river being diverted has made Gujarat a desert
- His brother-in-law did not make millions in dubious land deals
- He is anti-women, as evidenced by his fake marriage(s)
- and by his comments on rape:
- He is a tyrant and will become India's Hitler
- He has lowered the level of the political discourse:
- He made India a police state by attacking unarmed protesters
- He slept while his cabinet ministers looted the country
Saturday, March 22, 2014
Most of you, my dear readers, are familiar with binary relations. For those who are unaware, a binary relation, as the name suggests, is a relation between two entities. Think for example, “square-of-a-number” – this defines a relation between a number and its square. Relations have properties: for instance, a relation is symmetric if it applies both between a and b and between b and a.
Recently, my wife mentioned a custom in Hinduism where devotees poured small cans of milk into a large container that was then offered to the deity by the priests in their name. That struck me – religious offerings are transitive! And it begged the question: So what other properties of binary relations do religious offerings satisfy?
Surely, the offerings are irreflexive and antisymmetric – no one makes offerings to himself, and devotees make offerings to the deities, never the other way around. (One could however make a case that when prayers are answered, it is an offering made by the deity to the devotee thereby satisfying the symmetric property.)
Religious offerings are surjective (i.e. onto) (find me a deity who doesn’t have a devotee!), but they are not bijective – one devotee typically worships many gods (at least in the Hindu faith).
Any other properties I’ve missed? Add them as comments :)
Thursday, October 24, 2013
Do we humans have an innate need to categorize and distinguish between groups people? You know the usual ones – race, caste, skin color, sex, language, religion, state and even how one wears a tilak on their forehead. And only recently, we found that even when everything else was the same, people are ready to divide a state based on whether a Nizam ruled them or not.
Correspondingly you have racists, casteists, sexists, linguists(!), communalists, and now, nizamists.
I think I’ve found a new one – cityists. These are people who divide based on which city you are from. Folks in the US are aware of this: New yorkers looking down on New Jersey, San Fransicans looking down on NY, and the southern Republicans looking down on all big cities.
Of course, most of these are in jest, or out of a sense of (sometimes misplaced) pride, and in the case of the Republicans, sheer ignorance.
Cityism, it seems, has now spread to India. Not that it wasn’t there earlier, but there was more of a regional (linguistic?) tinge to the hatred Bangaloreans expressed for Chennai weather, or contempt Chennaites showed for the Bangalorean classical music scene. Rarely did the city spirit cross the boundaries of state, or language. Rarely did the city you came from define who you are, and almost never more than your religion or caste (or language/region). Slowly however, belonging to a city is becoming as important as belonging to a caste, religion or language. I’m sure Tamil and Marathi speaking Mumbaikars identify with themselves more than their Tamilian or Maharashtrian kin. I know for a fact that I identify myself with my north Indian colleagues than with, say, Kannada authors. I’m also reminded of my friend, a Telugu-ite who once told me that he couldn’t stand Andhra telugus (only in jest, of course). And of Amitabh, who defended Mumbai from his state-mates from UP.
These are of course, simply anecdotes. Do they point to a more secular trend of cityism, and will it change India for the better?
Tuesday, September 10, 2013
I love Bill Maher’s show, “Real time” on HBO, and in particular, am a big fan of the section “New Rules” where Bill Maher sets what are typically a new (and unusual) set of rules for his favourite targets. (This is one of my favourites, and there are more here.)
Of late, I’ve been thinking about announcing a set of “New rules” myself – but for library developers. Here are a few I can think of right away:
1. You will NOT accept a base class type as parameter to a function unless you mean it.
This is one of the sad legacies of Java. You have a class that you think might have multiple implementations, and so you create a class hierarchy. You then want to use this class in some function, and in conformance to traditional OO principles, you accept a base class (or interface) object as parameter. But you know that there are multiple incompatible implementations of the interface, so in your code, you specialize by adding a runtime check on the type of the object passed. Days go by, and an intrepid developer looks at your interface, and develops a class that implements it, and a third developer comes in and invokes your function using this object as parameter. The interface allows it, the compiler allows it, but voila, he runs the program and everything crashes!
Think this is a fairy tale? A classic .NET example of this is LINQ, which in theory takes a DbConnection parameter, but is really expecting a SqlConnection object (that establishes SQL Server connections). So, it does a runtime check on the type of the class, which I’m quite sure is something like:
if ( connection.GetType() != typeof(SqlConnection) )
Enter the Microsoft Enterprise Library, and its class: ReliableSqlConnection, which establishes a reliable connection to a SQL Azure database. Create a connection of this class, and pass it to LINQ, and LINQ immediately throws an exception, even though this is a SQL Server connection, and LINQ supports SQL Azure databases!
2. You will not have hidden dependencies between your types
A class should be a single, cohesive unit of abstraction. Everything a class method needs should either be created in the constructor or in a static constructor, or must be taken as a parameter.
Consider the RetryManager and RetryPolicy classes in the Enterprise library. You use a RetryPolicy to specify how many times an operation should be retried. However, what is unknown is that the RetryPolicy class expects the RetryManager class to be initialized earlier. Now, my question is, if that is the case, why not do it in the static constructor of RetryPolicy? Or why not have the RetryManager create instances of RetryPolicy?
3. You will NOT generate user documentation exclusively from code comments.
This is another tragic consequence of Java’s influence on the programming world. When introduced, Javadocs were a boon to programmers – you wrote all your documentation as comments and there was a tool that automatically generated formatted HTML documentation, freeing developers from mucking around with Word and repeating everything one wrote in their code comments.
An unfortunate consequence of this is what I call “instant documentation”. Normally, when developers document functions, they are focused on documenting the behaviour of the function, and not the big picture or the 10,000m view. Extrapolate this to all functions and classes in the code and the entire documentation becomes about the trees in the forest, while excluding the forest itself. Users of the API are now unaware of why a certain structure/behavior exists, they are unaware of the interdependencies between the API components (except when bitten badly by them) and are unaware of the thought process behind the behavior, all of which are lost in the minds of the creators.
Sadly, there is now no incentive to write classic documentation like that of early versions of MFC, or like that in the *-nix man pages. No engineer gets to the Principal level by writing good documentation. What is worse is that even books are now being written this way, essentially printing copies of generated documentation. Which is a shame because this reduces developers to search-engine users rather than system-aware engineers. It prevents transfer of useful insights from those who build these APIs to those who use them.
4. Your test cases shall be your sample code
I have been frustrated time and again, by the sparseness and triviality of the sample code that accompany libraries. Why not supply test code written to test the API as samples? At least in theory, test code should cover corner cases, combinations of functions, and other conditions that would interest users of the function/class.
5. You will make simple things easy, complex things possible
This is probably the golden rule of API development. The API must be easy to use for the most common scenarios. Most things must be accomplished with one or a few function calls. At the same time, users who have complex requirement should be able to meet them, maybe by writing complex code.
6. You will NOT write incomplete APIs
Completeness of an API is of course, a relative measure. It is easy, in the name of completeness, to fall down the slope of adding too much functionality. For instance, adding an encrpyt() method to a String class! On the other hand, today’s agile API writers fall into the YAGNI trap, by not adding necessary functionality – like a cache that does not have a clear() method! APIs must have the full set of methods that a typical user might consider necessary.
7. You will avoid the “Kingdom of nouns”
APIs are no different from books. Have too many characters in your book, and the resulting mental overload will turn off most readers (with honourable exceptions of George R R Martin and Tom Clancy). So, think about every word you use for your class and function names. Class names are concepts – use as few of them as necessary. Use standard verb-ese for function names – like store/retrieve instead of AddToStore and GetFromStore – the simpler names have the full meaning of the longer ones with none of the conceptual overload. And never, never overload the meaning of a common verb to do something other than what its common usage suggests.
8. Your code shall be idempotent
Idempotency is probably the most important property in today’s multi-threaded, distributed environments. If your API depends on state, it is inherently unsuitable for a world where computations fail and are retried!
Before I conclude, apologies for the lack of examples, the poor organization and the length of the post. I’ve been away from writing for too long now .
Needless to say, even though I present examples from the Microsoft world, these problems are not exclusive to it.
Wednesday, March 13, 2013
In the Mahabharata, Yudhishtira was asked by the Yaksha of the lake what the greatest wonder in the world was. Yudhishtira replies promptly: “Day after day countless creatures are going to the abode of Yama, yet those that remain behind live their lives as though they’ll live forever. What can be more wondrous than this?”
I was in a similar state, until last Tuesday when my father passed away after a hard-fought battle with pneumonia.
Nothing is more final than death. Nothing is more gut-wrenching than doctors and nurses referring to your loved one as “the body”. Nothing is more shocking than seeing the body of your loved ones burn and their bones get handed down to you in a pot.
Over the past year and a half, my father was diagnosed with multiple health problems. He had a blocked Right Coronary Artery, his kidneys were failing, and in April last year, he had a fall that led to a hemorrhage in his brain. Still, he and his doctors fought hard, which led to a partial recovery from all the ailments, sufficient enough for him to lead a near-normal life. However, from January this year, he was forced onto dialysis, and his health kept deteriorating until the final blow came in the form of pneumonia that proved to be untreatable.
I miss him.
While my dad had many accomplishments to his credit, the one that mattered to me the most was that he was an intense dad. The intensity with which he approached his role as a father (or grandfather) had to be seen to be believed. Be it carrying a sick 8 year old (me) for over six kilometers to get treatment, or waiting hours in front of my school to pick me up after my exams, or waiting in queues so that I didn’t have to - my dad always put my needs, desires, and even wishes before himself. He was always there for me and my brother – even for my nephews, when we needed him. He set the dad bar very high for my family.
Today, I feel orphaned – even though it was I (and my brother/wife/sister-in-law and mother) who was taking care of him! I realize now how many things my father had insulated us from; how many responsibilities, duties and dirty tasks he had taken on his shoulders so that we wouldn’t feel the burden. Suddenly, I feel like a teenager who woke up one morning to find himself a middle-aged man.
However, life must go on, lessons must be learnt, and we must look ahead. Therefore, let me conclude with some bit of advice from this experience:
* Get regular medical checkups: True, it is a hassle, it takes at least 1/2 a day, and it is tremendously annoying. But it detects many potentially deadly disorders in advance. So, if you are over 30, get a checkup done at least once in two years. If you are over 40, get a checkup done at least once a year. We came to know about my dad’s kidney failure only when it was too late to remedy it.
* Get health insurance: While it was heart rending to see my father take ill and be in pain, we were spared financial pain, thanks to a superb health insurance policy offered by Microsoft and my dad’s CGHS facility. If your company offers health insurance, ensure that you have at least a 5 lakh cover, and that your parents, spouse and kids are covered.
* Don’t take antibiotics at random: One of the most difficult aspects of my dad’s illness was seeing that a curable disease like pneumonia became incurable because of resistance to antibiotics. Apparently, this is because of indiscriminate use of antibiotics in the general population, both with and without doctor prescriptions, leading to the evolution of more and more resistant strains of bacteria and virii.
* Do talk to the people you love regularly: My father was in the ICU for nearly 4 weeks, during which he couldn’t utter a word. Day after day, we would go in only to see him either unconscious or unable to speak. He probably wanted to tell us something, but couldn’t. Neither could we convey to him any words of strength. Do not postpone words of love, encouragement or strength.
If there is a soul, I hope his finds peace. If not, there are our memories where he’ll be cherished as long as we live. Thanks dad, for all you did for me. And If I ever have kids of my own, I hope I can be half as good a dad to them as you were to me.