5 Things a QA Should Never Do

• Believe that the application will work with the way it supposed to be
  This is why QA are paid, to ensure that the application will work with the way it supposed to be, according to every words in the software requirement documents.
  
• Trust a programmer
  Programmers are all big liars. Maybe not all, but most of them are. Never trust these liars.
  
• Make assumptions
  You think out a problem where the application might have a leak. You told the programmer and what they DON'T WANT TO FIX IT because they assume that it would never happened in the real world. According to the Murphy's law, bad things has a big chance to happen.
  
• Don't know how to make a set of tight test cases
  Go grap some testing book and learn from it how to make good test cases.
• Intended to run the tests one time
  Software aren't gonna developed once even for a project-based software. A bug might happen in the future and QA has to retest the entire application or at least a module where the changes might take effect.

Signs of a Bad Boss

• He ignores the classic, time honored cliché, “Praise in public, criticize in private.”
• He gives you assignments and doesn’t follow up.
• He doesn’t support you when something goes wrong.
• He thinks everything is fine when it isn’t.
• He constantly claims that he is empowering you, but isn’t.
• He micro-manages and needs to know everything.
• He acts paranoid.
• He jumps to conclusions.
• He doesn’t know how to plan, prioritize or organize.
• If it isn’t his idea, then it can’t be good.
• He implements two-faced attacks.
• He tells sarcastic jokes or teases.

The bold ones is the one that I encountered personally.

And believe it or not, even there are books which specially talk about bad boss stuff, , for example Crazzy Bosses written in 1992. Stanley Bing composed it to help people spotting, serving, surviving them - not run away from them.

Reference: http://humanresources.about.com/

Eclipse not Copying XML Files When Building

This problem is pretty annoying me, because I absolutely don't want and will forget to manually copy xml files to the build path everytime I change something.

From Eclipse development forum I got this:

There is a preference for controlling what files NOT to copy to the output directory during a build - maybe XML files are included there somehow. You can check the Preference dialog - enter "filtered" (without quotes) into the search field at the top of the dialog.
Report back if you find *.xml or something similar there, or not.

And it solved the problem.
It seems that because there is a wrong configuration in a fresh copy of eclipse of which default filter for building has *.xml included.

Don't Reinvent The Wheel

Since very long ago, ppl has invented wheel. The wheel are made round, because the inventor had tried so many shapes and by the end of the day, he decided that round is the best shape to move things.

Here is a summary of Futurama's episode, my favorite cartoon all the time.

Mom is the founder of the largest robot factory in 3000. Once on the Mother's day, she activated the signal to all of the robots to rebel to human kind. In the future, everything use robots. So, ppl cannot live at all without robots.

Mom's sons go over the plan: Mom will be in a cabin in the Bronx. They have a precious non-computerized map to find their way, but they're not sure how to get there without a hovercar. Fry tries to explain an old invention called The Wheel. He builds a wooden cart with oval wheels.

Leela: Wouldn't it work better if the wheels were round?

Fry: It's my invention, we do it my way! 

Fry lugs them to Mom's cabin.

I applied this story as: "don't re-build your own library, use one that has been built and stable".

The author of the library might have spent so many hours to design, write and test the library. Bugs have been reported and fixed. People requested for enhancements that are applicable to them. It might be as well wise to contribute to the library (if it's open source), by adding features that it doesn't have yet. Other people might need it too, and they will be so thankful to you.

Expanding a DVD/CD Lifetime

Usually, ppl made backup by storing the data into a DVD or CD. The DVD/CD themselves have some limited lifetimes in fact. Do you remember the last time you found some collection of old songs on some pile of stuffs which you hadn't touch for several years? Then you tried to play the CD/DVD, and what did the player's screen said? "No disc", or "Please insert a disc".

If you read this article on CD Freak, you'll be surprised by the fact that a CD-R only survive between 2-5 years depend on:

• The quality of the CD: cheap CDs degradate faster
• How they're stored

To lengthen CDs lifetime what you can do is:

• Store them in a cold and dark place
• Store them vertically, because horizontal storing give to much pressure to the disc surface

Well I think the same rules apply for DVD.

There is nothing in this world that is eternal. The same rule apply for there is no storage medium which last forever.  However, banking industry prefer storing backup with magnetic drives because they last longer. Remember that you found some old tapes in on some pile of stuffs which "your parents" hadn't touch for several decades? Then you tried to play the tapes and it works despite of some distortions.