Weight your toys

After sleeping for nearly 12 hours, another sleepless night passed. I decide to write this post because this post reminds something about my weakness when dealing with algorithm problems. Maybe my low IQ is which I should blame to. But I love my parents, this is not their fault. So I think I should try to confront the shadow side. At least I have plenty of time to prove how poor my mind is, and before that I shall not give up my weakness.

Enough for dirty words. Here’s the problem, I put it to the gist.


 

How to abstract reality problems to sort problems, and how to take advantage of sort to find out things that interest us?

The code above, I want to use observer design pattern ( compare_event ). Yes that’s the part to emphasise that we always want to search things interest us, if not, why we search things? So that is the pattern of human beings, and I always decouple things when I find a point that fit normal brains.

Here is the steps that I always follow to create a solution:

  1. Understand them, feel them, and try to measure them. We always have a way to quantify things, though most people die here or find a really bad way to measure things.
  2. So we have convert states to numbers in the first step. We can use the numbers to compare two things.
  3. If I want to search something, I always search things while sort them. You always do the two things together, think about it when you are paring the socks from your washing machine. Even school child does it without thinking.
  4. I interpolate tasks while each comparison. Searching itself is also a task. Each task can access the current comparison result and process state.
  5. Choose a sort algorithm which fit the situation best
  6. Launch the whole process.

 

Git Daemon Two Common Mistakes

This is a powerful function introduced since git 1.7. The git will listen to a port and receive  incoming git protocol request. When we need to auto deploy project inside a private network, it is one of the easiest way to work with. It doesn’t depend on http or ssh, and much faster. Though it doesn’t support user authentication, it still a good solution for sharing code.

Two common mistake that the git documentation doesn’t mention:

  1. A white list path must be set.
    Something like this won’t work: 
  2. The white list path should be an absolute path or ‘./‘ prefixed.
    Something like below won’t work, the  test_repo should be prefixed:   ./test_repo , or use absolute path 

A simple correct example should be like below.

Then access your server by git push git://server_addr:8123/test_repo .

I wrote a simple shell function to help setup:

 

Circular list formula

This example, list length is 2 elem, mask length is 1 elem.
So the total item number should be 3 elem.
The total virtical offset should be 2 elem.

Distribute virtual disk mapping development

Most teams use the remote development technics to reduce the wasting of time when setup big projects’ complex environment. Normally, they use virtual disk mapping, such as samba server or sshfs. And then they map the remote disk to local directory. The final result is that everyone in the team will be happy to use their favorite tools to play with the project, and don’t need to worry about the product environment.

But these solutions all have a same disadvantage. They store the development files on the remote machine, which means if the network is bad or out of access, the development will be a painful tragedy.

Here I’d like to introduce my thought about the distribute virtual disk mapping development. In one word, we mapping in a reverse way. So if we simply virtual mapping out local disk to the remote machine this problem will be solved? Of course not. We still need network to connect to our development environment. So why not distribute the development machine as a virtual machine to every developer and lock the vm, only allow user mapping their own disk to his local vm. As the vm is solidified, so when can easily sync all virtual machines by script program, then use scm to manage these scripts.

We all know it’s better to store everything on the cheap, secure and safe cloud? But why GIT finally beat the SVN? Because we put to much trust on that the network is everywhere and fast enough. But on the contrary, the network is never good enough and if the cloud is down our only repo will disappear. So that’s why people want a copy to keep things more reliable.

我眼中日语里的谓语

前略,虽然顺利的通过了N2考试,但接下来12月的N1才是重头。今天是教师节,我觉得有必要写点什么来表示我对老师的感激。不善言辞,这里就写点日语学习的心得吧。

语言的最主要的作用就是跨越时间和空间传递讯息。而实现这一目标的主要手段便是对事物进行描述。中文和日语在事物描述方面我觉得最值得注意的区别就是它们描述事物的角度。中文描述对象的时候主要以主语为中心推导事物的性质,关于这点英语也是如此。但日语则一般不以主语为出发点描述事物。

举个例子,中文里我们说“我喜欢这个”,此时是站在我的角度发出喜欢的感想。日语的说法是“これが好き”,从“が”这个自动词助词就能看出语言间的差异,日语这句话表达的是这个东西具有让人喜欢的特性,日语并没有直接表明说话人本人的意见,而是间接的通过说这个东西很好来表达我喜欢它这件事,我们从“好き”这个汉子便能猜出,古代日本一开始启用“好き”的时候就是想说这东西好,所以才值得喜欢。这也解释了为什么日语常省略掉主语,因为这东西具备好的品质,任何人都可以喜欢。也即是说“これが好き”这句话只要语境不同,也可以表示妈妈喜欢这个,不局限于说话人本身。这一点体现了日语相较于中文具备某种更加客观的感情,虽然过于客观不一定是好事。日语希望抛开主观偏见来描述事物,于是到处都充满了省略了主语的句式,甚至有时候你如果强加入主语,反而会显得别扭。

由这个论点可以进一步推导日语的语序为什么和中文有如此大的差距。我认为为了方便初学者学习日语可以将日语的很多谓语动词不理解成动词,而是以描述事物性质的形容词来理解。比如“これを食べる”,这句如果传统的翻译成“吃这个”就会丢失掉很多意思,我觉得应该理解为,这个东西具备能被吃的特性,于是吃这个。这个初想你会觉得多此一举,但是如果你仔细看看“食べる”这样的一类动词的结构,就能解释为什么要有“る”这样的う段结尾假名了,从语言上来猜测,日语源自汉语,而汉语常常用“的”这个字结尾来形容事物,比如“吃的”,在“吃”后面加上“的”之后就是表示为“能吃的东西”这个意思了,日语在这点上似乎是保留了汉语的这种特性。然后他们把这个形容词特性委婉的用成了动词,“可以吃的东西”于是去吃。

知道了这些,就可以更好地理解“日语是个宾语谓语颠倒的语言”这句话了,其实它并不是颠倒了,而是把其他的东西当谓语用了。然后你发现一个有趣的问题,这语言竟然同时省略了主语又没有谓语!?听上去我这是个很疯狂的想法,但是如果行得通的话,正是因为句子里全是名词形容词,所以一句日语可以说的超长,并且似乎能无限再往成句里插入更细节的形容词。因为他们不必担心缺少主语和谓语而语法不成立,反正都可以没有。这也印证了日语的另一个特点:“听日本人说话基本就是在猜”,恩,猜的其实就是主语和谓语是什么。比如说“これが好き”,听了这句话你就要通过语境猜是谁,然后默认值就是说话人本身,然后句子里提到这东西很好,于是猜既然很好那主语大概会喜欢这东西,然后组合起来就可能是“我喜欢这个”,当然也可能是“他喜欢这个”。

而这些结论也告诉我们日语的重点在于句末,所以我们时常从句未开始翻译。

了解了这些以后初学日语的人大概会减少对日语这种异常语序的反感度。

PS:以上仅供参考,我是在毫无依据的情况下发出的思考,仅希望能提出一个看待问题的新角度。

Why my naming convention thought is different

I heard a lot of voices saying that they want to make their coding style the same with the corresponding frameworks, so they study the ancestors’ codes and mimic the so called golden standards.

Keeping coding style the same with the framework is no wrong. But don’t lost your own voice when you are trying to follow other’s. 

I prefer my coding style being different from the framework that I’m using. One big advantage is that it will be much easier to distinguish which part of the codes is mine and which belongs to the API. For example, a mix of camelCase and underscore conventions:

If a new member comes to read this java snippet, he will find it useful to find the road map of this project. Sometimes I think a proper way to mix will make life easier, isn’t it?