India: my pride, my shame

Today India completes 61 years as a Sovereign, Democratic and Republic state. We have been an independent nation for 64 years.

In this short span of time India has perfected the art of being corrupt. The CWG scam, the 2G scam, the Adarsh scam, $500 billion dollars of the country’s money stashed away in secret accounts abroad, bureaucrats discovered with Rs.300 crore stashed in suitcases at their home - these are the ones that are being talked about now. There are many from the past that we have forgotten. More importantly, we don’t remember anyone of any importance being ever punished.

With such a capacity to indulge in it, it is no surprise that corruption is so pervasive in our society, even soiling venerated institutions like the Armed Forces and the Supreme Court. We don’t need Transparency International’s studies to tell us we are rotten.

As a nation we need stalwarts in public life to look up to. The picture below defines stalwarts. We don’t have people of their vision, stature and influence anymore; however, we are desperate for them, gauging by our admiration for people like Dr. Abdul Kalam and Narayana Murthy. We need more and more people like them; we need their influence over us.


[Photo source: http://en.wikipedia.org/wiki/File:Gandhi_and_Bose.jpg. Don’t know who they are? See here.]

India has many good things going for it. Game-changing activities in the last 6, mostly in the last 3, decades in areas as varied as computerisation of railway reservations, telecom, low cost airlines, software and manufacturing, space research and technology, media, freeing the economy, strengthening the Election Commission, have taken our nation forward. These have been achieved by ordinary citizens doing extraordinary things without funfair, helped by some good thinking by those in government.

We need to do more: in infrastructure, providing quality education, improving agriculture, maintaining the unity without diluting the diversity and, our eternal bug bear, eradicating poverty. And there are many, with insight and zeal, already doing their bit in bringing about these changes. The scale is huge, given India’s diversity, size and population - and this all pervasive corruption makes the work tougher.

To be counted as an advanced nation, a nation truly respected, we must eradicate corruption from our midst.

The privilege and responsibility of software development

From Grady Booch:
".. It is a privilege because -- in spite of some inevitable dark days -- we collectively are given the opportunity to create things that matter: to individuals, to teams, to organizations, to countries, to our civilization. We have the honor of delivering the stuff of pure intellectual effort that can heal, serve, entertain, connect, and liberate, freeing the human spirit to pursue those activities that are purely and uniquely human. At the same time, we have a deep responsibility. Because individuals and organizations depend on the artifacts we create, we have an obligation to deliver systems of quality in a manner that applies scarce human and computing resources intentionally and wisely. This is why we hurt when our projects fail, not only because each failure represents our inability to deliver real value, but also because life is too short to spend precious time on constructing bad software that no one wants, needs, or will ever use. As professionals, we also have a moral responsibility: Do we choose to labor on a system that we know will fail or that may steal from a person their time, their liberty, or their life? These are questions that do not have a technical answer, but rather are ones that must be consciously weighed by our individual belief system as we deploy technology to the world. .." The privilege and responsibility of software development

And from the Software Engineering Code of Ethics and Professional Practice:
".. Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems. Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. .."

Help...

http://www.saveourtigers.com

Where the mind is without fear ...

"Where the mind is without fear and the head is held high;
Where knowledge is free;
Where the world has not been broken up into fragments by narrow domestic walls;
Where words come out from the depth of truth;
Where tireless striving stretches its arms towards perfection;
Where the clear stream of reason has not lost its way into the dreary desert sand of dead habit;
Where the mind is led forward by thee into ever-widening thought and action…
Into that heaven of freedom, my Father, let my country awake."

- Gurudev Rabindranath Tagore, Noble Laureate, Literature, 1913

Tagore's poem is a prayer of universal appeal. It is also a vision and a mission.

It is a vision, a mission and a prayer not only for my country, but for all mankind, especially in these times of conflict all over the world; replace the 'my country' with 'me' and it is a vision, a mission and a prayer for each one of us.

Design Principles:Don't Repeat Yourself (DRY) - A guide to its implementation

"DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software." From: Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II (emphasis mine).

How does this apply to code? Read the article here.

Design Principles: Program to interfaces, not implementations - A guide to its implementation

One of the recommended principle of OO design/programming is to ‘program to interfaces, not implementations’.

Consider a password policy defined like this in XML: 

<policy>
 <password>
  <min-length>
   <administrator>18</administrator>
   <end-user>8</end-user>
  </min-length>
  <expires duration="days">
   <administrator>60</administrator>
   <end-user>30</end-user>
  </expires>
 </password>
</policy>

In design, this will look like:

The abstract Policy class exposes 2 abstract methods, which are implemented in its sub-classes. The AdministratorPolicy class implement these methods to return values appropriate to the administrator from the XML file; the EndUserPolicy class implement these methods to return values appropriate to the end user.

And in code we can write:
Policy policy = new AdministratorPolicy();
int pwdMinLength = policy.GetPasswordMinLength();  //returns 18
int pwdExpiresInDays = policy.GetPasswordExpiresInDays();  //returns 60

Or:
Administrator policy = new AdministratorPolicy();
int pwdMinLength = policy.GetPasswordMinLength();  //returns 18
int pwdExpiresInDays = policy.GetPasswordExpiresInDays();  //returns 60

We are programming to an interface when we code Policy policy = new AdministratorPolicy(), because the Policy is an abstract class. We are programming to an implementation when we code Administrator policy = new AdministratorPolicy(), because AdministratorPolicy is an implemented or concrete class.

Notice that no matter how we instantiate it, the policy object is the same, exposing the same methods. This is because the super class and its sub-classes exhibit behavioral equivalence. To implement the design principle ‘program to interfaces, not implementations’ we need to ensure that the super class and its sub-classes are equivalent.

However, this is not always easy because:
1. Behavior in the derived/implemented class may vary.
2. Data in the derived/implemented class may vary.

How do we achieve behavioral equivalence under these circumstances? Read the full article here.

A for Ajax, Part 8: The XMLHttpRequest object (Part 3)

In this post we modify the XHR Library. This is now capabale of:
•  working with GET and POST requests
•  handling JSON formatted text and XML documents returned by the server
•  handling timeouts, and aborting requests

You can read the full article here.