The Eternal Truth...

There are only 3 ways to write a blog... The Right Way, The Wrong Way and MY Way :-)

Programming Myself....

If you want something you never had, you must do something you never have done!!! - That's meee!!! can't be better:-)

Wireless Mouse

Thanks to Phani, i am now in possession of a Micro$oft Wireless Mobile mouse 3000. He gifted that to me and I passed it on to my dad, as he is still not very comfortable with the laptop's touchpad. I think part of it has got to do with the fact that he works with Auto cad which is easier with a mouse rather than the touch pad.

                    mk_wmm3000blk_productfeatures

 

I just set it for my dad and i was impressed. The mouse is very comfortable and is ergonomically designed for comfort in either hand. A snap in receiver is present so that you can plug it in when you want to use the mouse, else you can pack it away when not in use. There are 4 scroll buttons for easy navigation. It's made up of high definition optical technology which promises high battery life. I still need to validate this part. Overall its compact and is designed with care for notebook users.

Married but available - Abhijit Bhaduri

The much awaited sequel to the bestselling Mediocre But Arrogant: The first ten years are the most eventful, they say, in anybody's working life. They certainly are in the case of Abbey, who walks into a job at Balwanpur Industries, fresh from B-school. Working in HR is fun, he soon discovers. What isn'tis  the fact that there's hardly anybody in the company who doesn't have a view of who Abbey is and what Abbey does—or should do. Add to this the complications of being newly married to a woman more successful than he is, a crusty boss, and a sudden turn in the company's fortunes that catches Abbey unawares. It's up to him now, to apply all that HR wisdom learnt in business school to the dilemmas confronting him at work and in love. Can he hold down his job or will it end the way his marriage threatens to—rapidly and without too many regrets?

but i am kind of disappointed with the lack of ingenuity of some of our brethren...All these books of married but available, keep off grass , 3 mistakes of my life....same thing , different institute...if not IIT , its IIM ! Dear Writers, there is more we need to explore now... for starters - How about MORE CRAP AVAILABLE????

Tiger Trail - Royal Harsha Orchid

Located on Park Road, Shivajinagar is this nice place called Tiger Trail. You can call - 22865555 to make any reservations, but for most part you can just drop in impromptu and still get a seat. Experience an eat out adventure like never before. In the rare ambience of a warm forest lodge. Warm earth-tone colors, wooden floors and an open hearth offset by white tablecloths and uniformed waiters, give Tiger Trail a feel that is rustic yet elegant look. Yet the only thing that is lacking is the non availability of space for parking your car and the one way's that lead to the hotel.

You can enjoy a great meal at a modest  Rs.200 on the lunch buffet. It would be great if you can give those guys a call before you drop in as you will get to know the items on menu. You should not miss the chicken Manchurian while there. However the desserts section sucks.

Code coverage - Dead code

A nice read for those interested in dead  code analysis while doing code coverage

Dead Code is a term that means more than just a block of code with no possible entry points. It's been used to describe code that's been commented out or exists in files but not being built.  Also in some cases, it's been inappropriately used to describe code that is very difficult to reach.

The following 3 categories are meant to clarify the different types of "Dead Code" and recommendations on what to do for each.

Unused Code:

Orphaned code that lingers in the build but has no possible customer usage scenarios. This is more like the classical “Dead Code” definition; code blocks with no possible entry points.

Example:

· Class that never gets instantiated anywhere.

· Function that is never used in any other code.

Risk:

· Likely untested

· Likely un-analyzed by various runtime tools

· Potentially wasted space (media, ROM images, etc. if not optimized out).

· Security exposure.

Unused code is most likely optimized out, but in the cases where it makes it into the binary, it should be considered for removal.

Unreachable Code:

Code that is unexecuted due to logic that does not currently evaluate to allow execution (ex. relies on config/environmental scenarios that do not exist).

Example:

· Blocks of code that are logically unreachable: if (some_condition) { ...code....}, where some_condition doesn’t exist as TRUE in the world today.

· Blocks of code to handle non-existent hardware:

· Exception handler code that may impossible to trigger.

Risk:

· Likely untested, and can be awakened if config/environment comes into existence (most serious for already shipped code).

· Likely un-analyzed by various tools

· Wasted space (media, ROM images, etc.)

· Security exposure.

Unreachable code may also be optimized out (like in the cases of if (0) {...}), but for other code in this category that makes it into the binary, it may require core code changes to enable test cases, like interface hooks or some other type of testing approach (like fault injection).

The most serious code in this category is code that could become active post RTM when the world changes in a way that causes it to be executed.

Boneyard Code:

Code that is kept around for either posterity, tradition, fear of unknown (like if confronted with “let’s get rid of if”), or just plain laziness.

Example:

· Code that is commented out

· Code in files that are not part of compilation (i.e. in tree, but not in sources)

Risk:

· Untested

· Un-analyzed by various static analysis tools

· May not go through security review

· If enabled/re-activated at some future date, may introduce anachronistic code

· Security exposure.

Boneyard code is not as serious as it has no presence in shipping code and thus, by definition, poses no risk to our customers. Should be remove during something like a MQ timeframe or some other "Codebase Clean-up" effort.