VIM useful commands

gw exchange two words
CTRL-X CTRL-L complete line
CTRL-X CTRL-F complete file
CTRL-X CTRL-P complete word, useful when you use snippet and still want to have omni-complete
tab complete word
\s substitude the current word
\S substitude with question
ALT-O open file with the same name
\F find in all files
\g find file
\f find tag
,r run matlab script
,o open matlab
:make check matlab syntax

\ll compile latex
\lv view latex

I can leave, finally

After the past 2 years of working, the most important thing I learned is humanity. I learned that when facing the lure from the dark side of Force, who can stand up with it and who cannot. It's good to see most people choose the light side. Nevertheless, the Jedi are still out-numbered by the Sith. In order to succeed, I have to find more Jedi, so now I am leaving to start my journey. Wish me good luck.

The true meaning of "Organizational Change"

In M, there will be at least one "Organizational Change" for each year.

When I was young, I thought a programmer is cool because they are very professional and can produce many cool stuff (like computer games). Therefore, I chose computer science as my major at university. I hoped I could become as professional as them and produce many cool stuff as they do. After several year, I left school and joined Mediatek to start my career as a programmer.

Then I disappointed.

The reason why I disappointed is not due to the fact that what I did in the company is a completely useless junk. The true reason is that nobody in this company cares what they did are completely junk or not. All they care are nothing but power and money. The politics, as a result, is the most influential factor to what they care. That's why people care about politics. They like to talk who is going to be promoted and who is going to be f**ked. They share political information and form a small political group to fight against each other. One who spends most time on politics gets promotion while the hardest worker gets fired. The company rewards who conslidate their power and punishes who improve the quality of products.

Somebody called it "a process to become mature". One must know the differences between idealization and reality. One must understand the human society is very competitive and cruel. The mature people should know the rules of the society and the necessary political skills to get what they want. The mature people should adapt themselves to the society and stop complaining about it.

I disagree.

We shall not adapt. We must understand that we are still in the stone age of software industry. There are currently no effective tools to estimate the contribution of a programmer. There are also no ways to estimate who is capable to become the leader of a software team. It's very likely to choose a incapable leader. The incapable leader, as a result, is going to fire the most productive worker in his team due to the lack of software managerial skill. He will also hire many incapable workers because these incapable workers are the most similiar to the best employee in the world--himself. Several years later, the company will be full of incapable workers. Since they are incapable, they don't do any software product nor do them improve it. So what do they do in the company? One possible answer is, unsurprisingly, "Organizational Change". Period.

Tips on how to write a thesis

The most useful part of the handbook of UBC CS department is "Tips on how to write a thesis" by Bob Woodham. I keep reading it again and again while thinking what I was doing when I was in graduate school. Sometimes I invented a new technique to solve a known problem. Sometimes I applied the exsiting techniques to another problem. Which one is the "good research"?

Bob Woodham's article makes me think this question again. He stated that the third step of a research project is to discover new knowledge. Even so, most of recent computer vision research lack in this step. A popular trend of computer vision research is to transform a problem into statistical domain and apply new statistical methods. They consist only step 1, 2 and 4. Are they "good research"?

Another trend of vision research is to follow classical works and do some "tweak". For example, a one possible way to do image inpainting is to choose a different "filling algorithm" of the classical work "Region filling and object removal by exemplar-based image inpainting" by A. Criminisi, P. P´erez and K. Toyama. Since the filling algorithms are different, it's quite possible that we can find another set of images which the new algorithm can perform better. This kind of research consists all four steps. Are they "good research"?

He also stated a researcher should commit to a research problem, not a technology. However, all computer vision people commit themself to use camera to solve problems. Is it a kind of commitment to a technology? One of the most noticeable problem is to estimate image depth. Everyone knows that Laser Depth Micrometer(LDM) can outperform the stereo-based approache to several magnitude, but there are still many people try to estimate depth by stereo cameras. I know cameras are much cheaper than LMD. Nevertheless, shouldn't we just put our effort on cut down the production cost of LDM instead of researching another cheap and unreliable technology?

In the beginning, I thought a graduate school can help me understand what research is. I end up with much more questions when leaving.

Here is a excerpt from Bob's article.


The purpose of research is to contribute to knowledge. Selecting a problem is the major part of any thesis project. Avoid the Computer Science tendency to think only in terms of tools and techniques (and mindless programming tasks). There are four steps to a research project. Step 1 is for motivation and is done first. The thesis addresses steps 2 and 3. Step 4 typically occurs only after the thesis is completed. The four steps are:

1. Identify the research problem. Understand the state-of-the-art within a topic area well enough to determine fundamental obstacles to further success. You have identified a research problem when you can make clear where necessary new knowledge is needed.
2. Choose the research domain. Choose a domain that is rich enough to demonstrate the intended result yet simple enough to avoid wasteful diversions. Pragmatic considerations best determine the choice of domain. This best choice often is not the domain of the original problem. The link is simply that the necessary new knowledge required is the same. Choose the domain that supports the most rapid prototyping and testing of your ideas.
3. Discover the new knowledge. This is where you add your talent and creativity!
4. Apply the new knowledge to the original research problem. This will complete the research and will provide a foundation for future research by helping to identify the next set of obstacles.

Here are more suggestions to avoid common pitfalls:
1. Decide on the research problem before committing yourself to a particular domain. Bad way: I like to play chess and I need a thesis topic. Maybe if I implement a chess program I will discover something interesting. Good way (after P.H. Winston): Learning is difficult. Maybe there is power in noticing similarities and differences between symbolic descriptions. I can explore this easily in the context of the world of the blocks.
2. Does the research problem demand exploration. A lot of work in AI and computational vision is on non-problems. A demonstration that a tool or technique is sufficient for a given task is not a demonstration of necessity. Convince yourself that your research problem is necessary. What is to be learned? Who is likely to care about the result? Is the problem of fundamental importance? Without necessity, you can easily be scooped by a better tool or technique.
3. Examine your commitment to the research problem. Commitment to a problem means that you will accept a solution, regardless of the scientific discipline that gives rise to it. If you only accept solutions of a certain type, then your commitment is to a technology, not to scientific research.
4. Develop a detailed scenario to demonstrate your work. A scenario provides an organizing principle for your research. As much as possible, carefully work through the scenario by hand simulation. Identify critical components. Work hard to develop the new ideas required dealing with these components.


Evaluate Mr. O's abilities

Today, one of my colleague--Mr. O asked me to evaluate himself. The reason is that I will tell the truth since I am quitting my job. However, the truth is that I always tell the truth no matter I am quitting or not.

Let's see Mr. O's ability scores:
Social Skill:
One of the most remarkable skills of Mr. O. He knows how to joke with his boss and make his boss happy -- a very rare skill. He also knows how to maintain good relationship with his fellow engineers. Most important of all, he doesn't bully young engineers. He'll share knowledge and joyful work with them. Very remarkable.

Programming Skill:


Sexual appearance:
He is a handsome boy. Not only girls but also some guys are willing to sleep with him.
Nevertheless, he is not as handsome as myself, so he gets a score of 4.

Working Attitude:
He is one of the laziest workers in my team. He keeps chating with his friends on MSN  during working hours. He surfs the blogs and does little of this and little of that. I am always wondering what he is doing in the office.
His working attitude deserves the lowest score--1. If I were his boss, I would fire him.

Geek Level:
Honestly, he is not a geek. He is not ACG fans, not start wars fans, and know how to date beautiful girls. However, his passion to programming and vim raises his score to 3 -- a half geek.

How to prevent your OO program growing a GIANT INHERITANCE TREE

Object-Oriented programming is a paradigm for software engineers to seperate a computer program into discrete and reusable units, which are called "objects". One of its technique to resue the existing source codes is through "inheritance". That is, we find a common operation among objects, then we create a "parent class" to represent this operation.

"Inheitance" is an important technique to reuse source codes. However, we find it harmful in some cases.  One of download tools in our team faces suce a problem.
The functionality of the tool is to download binary images into the flash memory of a mobile phone. Since there are a wide range of mobile phones to support, the tool contains a lot of objects. Each objects represent a download process of a specific type of mobile phones. The problem is that the download processes are just slightly different with each other. One of the reasons why they are just slightly different is due to workarounds of hardware bugs. The "slightly different" codes then result in a tall and giant inheritance tree. Inheritance, generally, is a good technique. Nevertheless, when a object has too many ancestors, the operation of the object becomes obscure. The real implementation of a virtual function may be resided in any of the ancestors. It's hard to tell which one really takes effect from the source codes.

One of my colleagues wants to resolve this problem by refactoring the existing inheritance tree into a shorter one. He designs a common downloading procedure for all kinds of mobile phones. The procedure contains many but fixed steps, and each mobile can have its own step implementation if the its step is slighlty different than other mobiles phones. I am sure that he is going to succeed to reduce the height of the tree, but I doubt that he can prevent the tree from growing higher again.

The reason why he is going to succeed is primary because all of the workarounds of previous phones are known, so he can devise a download procedure general enough to cover all of the workarounds. On the other hand, the workarounds of future phones are impossible to known. When a workaround happens, it might break the existing download procedure and require to refactor the existing codes or increase the height of the tree. He said to me that the new download procedure is so general that it's impossible to break.

I think otherwise.

In the software world, it's better to have less assumptions on your source code. The less you assume, the less you will rewrite when the assumption fails. From my point of view, it's not necessary to assume that there is a one general download process which can cover all kinds of mobiles phones. Why not just assume that the download processes of mobile phones are all different. The reason why we want to find common procedures in our codes is because we want to reuse our codes. We don't want to copy and paste the same code in every place. If we do so, the code will be very hard to maintain since we need to change the same codes in many different places.

For the download tool, it's not the case. The download tool is basically a one-time programing. We write the code for a specific mobile phone. If it works, the coding is done. There are no more maintainence effort on the code. We just need a working code to download the binary images. That's all. For most of the time, it's very dangerous to refactor the source code of the download tool, because it might break the existing code and make the download tool fail on older mobiles. To prevent such problem, we need to perform a lot of regression tests. So it's even better if we don't maintain the code and leave the working code unchanged. If we want the inheritance tree shorter, we need to refactor our existing codes, which might break them. Alternatively, if we avoid inheritance and treat each download process as a seperate script, assume different mobile phones have different download process, we can get a clear program architecture. The program will be easier to read, because the download script shows all operations and workarounds it performs. It also avoid changing the existing codes and therefore it does not require the tedious process to test all old mobile phones.


Sound great. Now, please prove I am wrong

Panasonic Let's Note CF-Y8EWJAJR

Centrino(Santa Rosa)
CPU: L7800 @ 2.0GHz Merom
CPU voltage: 0.96V
Intruction: SSE3
L2: 4MB

Display: GM965 (X3100)
IDE: ICH8M
Sound: AD 1884
Wifi: Intel 4965AG
Net: Marvell Yukon 88E8055
SD card: Ricoh RL5C822
Cardbus: Ricoh RL5C476