This blog entry is for those cribbing about their low salaries and comparing their salaries with their friends in other companies. Not intended to hurt anyone's feelings and opinions.To be taken in a lighter spirit.
I received a mail today about something called as the Knowledge Theorem, that states "An Engineer cannot make as much money as the Politicians, artists". The author used the following "inductive procedure" to substantiate the theorem.
Two adages everyone is aware of - "Knowledge is Power" and "Time is Money". If represented mathematically, these two adages would be
Knowledge = Power
- eqn. 1
Time = Money - eqn. 2
High school physics has taught us that
Power = Work/Time.
From eqn. 2, Time = Money, so
Power = Work/Money
From eqn. 1, Knowledge = Power, so
Knowledge = Work/Money
Rearranging the quotient and the divisor would result in
Money = Work/Knowledge
The lesser the denominator, the more is the fraction. Hence proved!
If a person is earning less, that means he is more knowledgable. The converse of the statement is, however, not true.
Tuesday, November 29, 2005
Wednesday, November 16, 2005
The best description of OO
Had been reading an article titled "OO in One Sentence: Keep It DRY, Shy, and Tell The Other Guy" from pragmaticprogrammer. A funny sounding title, but the content explains the essence of OO in a more interesting way. I liked a particular paragraph so much that I'll quote it all in verbatim:
"The best code is very shy. Like a four-year old hiding behind a mother’s skirt, code shouldn’t reveal too much of itself and shouldn’t be too nosy into others affairs. But you might find that your shy code grows up too fast, shedding its demure shyness in favor of wild promiscuity. When code isn’t shy, you’ll get unwanted coupling."
This is the best description of OO I've heard of so far.
"The best code is very shy. Like a four-year old hiding behind a mother’s skirt, code shouldn’t reveal too much of itself and shouldn’t be too nosy into others affairs. But you might find that your shy code grows up too fast, shedding its demure shyness in favor of wild promiscuity. When code isn’t shy, you’ll get unwanted coupling."
This is the best description of OO I've heard of so far.
Wednesday, November 02, 2005
AJAX Mania
Oflate, the "ajax" is in the limelight. The technology has created so much excitement among the web developer community and eventually is conferred with laurels. Some of the accolades received are "The next big thing", "revolutionary web technology", "web2.0", etc. The technology indeed has a potential and some applications have leveraged and demonstrated it. The most famous and often cited are the google maps, gmail, flickr.
Recently, rediffmail rolled out a new version of their web mail that offers some goodies implemented using ajax - mail preview, instant download of attachments, drag drop unwanted mails to trash, auto suggest of email ids while composing a mail, etc. It is now pleasure to use rediffmail with all the ajax goodies.
We have an ajax implementation in our product to retrieve information at lower levels from a hierarchically organized data, on click of expand/collapse (+/-). The existing functionality retrieved all the data at once, dumped the data behind the div tags and the selected div would be made visible using javascript. This worked fine for smaller amounts of data and for large data, apparently, became a bottleneck in terms of retrieval and rendering times. Subsequently, the issue has been resolved by implementing ajax. When someone suggested the ajax solution to our chief architect, he suggested some concerns and asked us to explore more for an optimal solution:
1. Browser compatibility - there should be a utility to check for the compatibility of the browser for ajax to serve the ajaxified and no-ajaxified versions accordingly.
2. Increase in the server hits for every ajax call
3. Feedback mechanisms during ajax calls and appropriate messages on the screen
4. Processing order of the ajax calls
5. The change should have a least impact on the existing functionality/code and should be maintenable.
These concerns were very realistic and very soon we realized that ajax is not a panacea. The final solution used ajax at only certain points where it added value. My request to fellow developers and friends is not to get carried away by the excitement, understand the true potential of the technology and implement it at a place where it makes sense.
Recently, rediffmail rolled out a new version of their web mail that offers some goodies implemented using ajax - mail preview, instant download of attachments, drag drop unwanted mails to trash, auto suggest of email ids while composing a mail, etc. It is now pleasure to use rediffmail with all the ajax goodies.
We have an ajax implementation in our product to retrieve information at lower levels from a hierarchically organized data, on click of expand/collapse (+/-). The existing functionality retrieved all the data at once, dumped the data behind the div tags and the selected div would be made visible using javascript. This worked fine for smaller amounts of data and for large data, apparently, became a bottleneck in terms of retrieval and rendering times. Subsequently, the issue has been resolved by implementing ajax. When someone suggested the ajax solution to our chief architect, he suggested some concerns and asked us to explore more for an optimal solution:
1. Browser compatibility - there should be a utility to check for the compatibility of the browser for ajax to serve the ajaxified and no-ajaxified versions accordingly.
2. Increase in the server hits for every ajax call
3. Feedback mechanisms during ajax calls and appropriate messages on the screen
4. Processing order of the ajax calls
5. The change should have a least impact on the existing functionality/code and should be maintenable.
These concerns were very realistic and very soon we realized that ajax is not a panacea. The final solution used ajax at only certain points where it added value. My request to fellow developers and friends is not to get carried away by the excitement, understand the true potential of the technology and implement it at a place where it makes sense.
Subscribe to:
Posts (Atom)