Wednesday, November 30, 2005

World AIDS Day

Having the Virtual Red Ribbon on your site will link visitors to that site where they too can find ideas to get involved in World AIDS Day.
Support World AIDS Day

Thursday, November 24, 2005

Man Made Man

The Man in this photo is a 50 year old man... was sitting before the Director's chamber on Thursday, at Visakhapatnam steel plant Main Administrative Campus. Many of them thought that he too came to submit some forms. If you try to talk to him he wont speak, he wont even respond to you, and worse he doesn't even blink his eyes. Finally what will you do if some one says that he is not a man. Yes, it is true he is not a man.

Rama Krishna, Ravi Chandar, Shiva Prasad Reddy, students of Andhra University Fine Arts, have worked for 3 months under the name of "Life Model", to build this master piece with clay and plaster of paris. They wanted to install this at the Steel Plant Museum, so they thought to see what every one will feel like if it was put before the officials chambers. Any way they did not get the permission for other reasons.

Source: Online Edition of Eenadu Paper dated 25th November 2005.

Monday, November 21, 2005

A Toaster for the king

The actuall title is Electrical Engineering vs. Computer Science.

Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?" One advisor, an engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."

The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."

"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelet classes."

"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."

"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."

"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v.8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."

"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."

The king wisely had the computer scientist beheaded, and they all lived happily ever after.

Wednesday, November 16, 2005

Murphy's Computer Laws

  1. Any given program, when running, is obsolete.
  2. Any given program costs more and takes longer each time it is run.
  3. If a program is useful, it will have to be changed.
  4. If a program is useless, it will have to be documented.
  5. Any given program will expand to fill all the available memory.
  6. The value of a program is inversely proportional to the weight of its output.
  7. Program complexity grows until it exceeds the capability of the programmer who must maintain it.
  8. Every non- trivial program has at least one bug
    • Corollary 1 - A sufficient condition for program triviality is that it have no bugs.
    • Corollary 2 - At least one bug will be observed after the author leaves the organization.
  9. Bugs will appear in one part of a working program when another 'unrelated' part is modified.
  10. The subtlest bugs cause the greatest damage and problems.
    • Corollary - A subtle bug will modify storage thereby masquerading as some other problem.
  11. A 'debugged' program that crashes will wipe out source files on storage devices when there is the least available backup.
  12. A hardware failure will cause system software to crash, and the customer engineer will blame the programmer.
  13. A system software crash will cause hardware to act strangely and the programmers will blame the customer engineer.
  14. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
  15. Make it possible for programmers to write programs in English, and you will find that programmers can not write in English.
  16. The documented interfaces between standard software modules will have undocumented quirks.
  17. A working program is one that has only unobserved bugs.
  18. No matter how many resources you have, it is never enough.
  19. Any cool program always requires more memory than you have.
  20. When you finally buy enough memory, you will not have enough disk space.
  21. Disks are always full. It is futile to try to get more disk space. Data expands to fill any void.
  22. If a program actually fits in memory and has enough disk space, it is guaranteed to crash.
  23. If such a program has not crashed yet, it is waiting for a critical moment before it crashes.
  24. No matter how good of a deal you get on computer components, the price will always drop immediately after the purchase.
    • All components become obsolete.
    • The speed with which components become obsolete is directly proportional to the price of the component.
  25. Software bugs are impossible to detect by anybody except the end user.
Murphy Laws Site - The origin and laws of Murphy in one place.