Lost Ferry

从小到大，在电视里面见到的超人牛人都有一个共同的特征，就是发飙的时候可以产生巨大的能量

有了巨大的能量，就可以无坚不摧，或者啥都可以做

汽车需要能量，电脑需要能量，手机需要能量。总之，基本上任何东西都需要。

同样，脑力活动也需要能量。

也就是说，编程需要能量。

把一个东西从无序变成有序需要能量。

构建一个抽象的解决放案同样需要能量。

构建一个金字塔需要很多年很多人的体力能量。

构建一个复杂的系统，需要很多年很多人的脑力能量。

当今的社会更多的依赖脑力能量。因为机器的缘故。

比如开车只需要控制，主要是脑袋的信息处理与决策。

软件的重构需要能量，因为把东西从无序转为更加有序。

软件的重构是为了能量更有效的作用。相当于把一个大石头分解为很多个小石头。推大石头花很多能量但是效果不大。而推小石头则效率很高。

原理是，集中火力，攻其一点。这样力量得到最大化。

力/面积=压强

或者 力/质量 ~ 速度 

一个混乱的系统会分散我们的能量。比如这儿需要改，那儿也需要改，很多地方都得看看。

而一个有序的系统，改动仅仅牵涉到某一个函数，或者某一个类，或者某一个模块。那么，相同的能量可以导致更快的速度。

另一个方面，能量需要积累，需要专注。

如果我们一时做这个，一时做那个。总是从头开始。那么，我们就相当于浪费了以前所消耗的那些能量。而我们所开发出来的东西也就不会有太大的价值。因为缺乏能量的积累。 

重用相当于能量的重用，所以很重要。

既然一个抽象的解决方案需要能量。那么知识也就是能量。知识的积累也就是能量的积累。学习知识也就是充电。 

知识牛到一定程度，才能发牛paper。

所以平时需要知识的积累。

上次isvc最大的收获就是听了堂tensor voting的讲座

tensor voting的创始人讲的。讲的非常简单，浅显易懂。之前下过那本书，但是一到理论部分感觉就糊了。而听Philippos Mordohai同学的讲座则感觉完全不一样。就像他说的，很simple，很beautiful。

今天又开始看这个。感觉又有一点儿糊。voting field的部分很清楚，tensor也很清楚。但是关键的细节不是很清楚。比如从头到尾的一个流程是如何，如果是pseudo code该怎么写？首先第一步，如何从一堆的点得到一些tensor呢？有了tensor才能做voting阿。那本书也没讲清楚。到网上找slides也没发现。后来来回看一篇paper，就是tensor voting, theory and applications，再看3D的那张slides，再进行强力的inference才搞明白。其实也很简单，就是对每一个点，取他邻近的一个点，可以得到一个tensor，汇集所有邻近的点所得到的tensor，就得到这个点本身的tensor。有了这个tensor，就可以对空间每一个网格点作voting。每个voting也是一个tensor。有了densor tensor map，就可以提取salient的特征，通过找local最大值。

还有一个问题一直萦绕着的，就是怎么得到那个三维模型的。那个模型显然不是简单的一个点。后来从一张slides里看到，原来是通过marching cubes。

以前我觉得这个东西其实没啥，如果简单的作一个multi scale，似乎也可以得到同样的效果。那些noise可以直接通过一个threshold过滤掉。后来听懂后，感觉还是有一些东西在里面。最关键的是那个field，就像电磁场一样。这个东西编码了local的结构特征，以及smoothness的constraints。用这个东西可以算出未知网格的值，可以算是一种更高级的interpolate。

当时听讲座的时候有一个人其实问的很好，说你这个跟clustering有啥区别。不过Philippos Mordohai同学直接把这个问题给回避了，说不怎么了解clustering领域。

很欣赏Philippos Mordohai同学做研究的方式。开始有一个简单的想法，然后一直坚持做下去，不断的完善和扩充理论，以及应用到各个方面。其实tensor voting这个东西已经研究了很多年。

再说tensor voting的应用。首先很广，从early vision到high level vision都有应用。其实核心很简单，就是从一堆的有noise的点里inference出结构特征，比如线，面等等，同时把noisy data过滤掉。有一篇paper是拿这个做epipolar geometry。原理和直线拟合是一样的。一般的方式是ransac。outliers要多了就不行了。tensor voting的另一个好处是可以同时得到多个salient的模型。比如空间里的多个面。

发现很多问题到最后都变成了面的拟合问题。。。。 

In 2001, marketing guru and bestselling author Seth Godin—who's seen more bad presentations than any man should be subjected to— had had enough. Seth decided he'd try to make a difference. So he wrote a 10-page e-book called Really Bad PowerPoint that he sold on Amazon for $2 (money went to charity), and it became the best-selling e-book of the year. "PowerPoint could be the most powerful tool on your computer, but it's not," Seth said. "It's actually a dismal failure. Almost every PowerPoint presentation sucks rotten eggs." 

most presentations remain mind-numbingly dull, something to be endured by both presenter and audience alike. 

My favorite book in the summer of 2006 was Daniel Pink's best-seller, A Whole New Mind (Riverhead Trade). Tom Peters called the book "a miracle." 

"The future belongs to a different kind of person," Pink says. "Designers, inventors, teachers, storytellers—creative and empathetic right-brain thinkers whose abilities mark the fault line between who gets ahead and who doesn't." 

We're living in an age, says Pink, that is "...animated by a different form of thinking and a new approach to life—one that prizes aptitudes that I call 'high concept' and 'high touch.' High concept involves the capacity to detect patterns and opportunities, to create artistic and emotional beauty, to craft a satisfying narrative...." 

it's increasingly clear that logic alone is not a sufficient condition for success for individuals and for organizations. 

The six aptitudes are: design, story, symphony, empathy, play, and meaning. Mastering them is not sufficient, but leveraging these aptitudes has now become necessary for professional success and personal fulfillment in today's world. 

Focus, specialization, and analysis have been important in the "information age," but in the "conceptual age," synthesis and the ability to use seemingly unrelated pieces to form and articulate the big picture before us is crucial, even a differentiator. Pink calls this aptitude "symphony." 

Communication is about getting others to adopt your point of view, to help them understand why you're excited (or sad, or optimistic or whatever else you are.) 

Logic is not enough. Communication is the transfer of emotion. 

If you believe in your idea, sell it.

deep down, we all want to be sold.

No more than six words on a slide. EVER. There is no presentation so complex that this rule needs to be broken. 

Talking about pollution in Houston? Instead of giving me four bullet points of EPA data, why not read me the stats but show me a photo of a bunch of dead birds, some smog and even a diseased lung? This is cheating! It's unfair! It works. 

Third, no dissolves, spins or other transitions. Keep it simple. 

The home run is easy to describe: You put up a slide. It triggers an emotional reaction in the audience. They sit up and want to know what you're going to say that fits in with that image. Then, if you do it right, every time they think of what you said, they'll see the image (and vice versa). 

The art of comics is another place to look for knowledge and inspiration. Comics, for example, are amazingly effective at partnering text and images that together form a powerful narrative which is engaging and memorable. 

Comics and film are the two major ways that stories are told through imagery. 

//最近不时地看到这本书，今天终于下载下来

//这儿有一篇不错的书评

http://www.douban.com/subject/2353270/

Simplicity is the ultimate sophistication. - Leonardo da Vinci

昨天哥哥结婚，恭喜他。祝愿百年好合，白头偕老！

昨天参加了同工会，kai卸任，bo成为新主席。真快啊。上次开同工会还是我卸任，kai上台。转眼大家叫我老主席了。我一直很欣赏kai，他是一个非常厚道，踏实，虔诚的人。有女生让我帮忙找男朋友，我第一个想到的就是他。不过他已经不available了。也就感恩节时候才知道的，kai跟yue恋爱上了。kai不小了,yue比他更大。其实很早我就想到过他们俩，没想到真的成了。老婆说yue是一个又红又专的人。确实，以yue的虔诚，能满足她条件的不会超过三个。kai是其中一个。如果照常人的眼光，他们俩似乎根本不可能。kai比yue小，而且比yue矮。也只有在神的国里，他们是最般配的。上次chen li的婚礼，yue捡到新娘扔出的花，看来是有原因的。kai的父母也刚到。我本来担心他们不同意。不过前天在团契，感觉他父母应该是赞成的。而且他父亲说希望kai在明年能结婚。

cindy星期四回来参加毕业典礼。父亲也过来了。一起照相，吃饭。碰到hu na了，她也毕业。还有好多认识的人。哎，自己还在这儿。cindy说sharp那边也在裁人了。不过她们部门目前还行。但她们也还是有担心。怪不得louie也在linkedin上到处拉关系了。太可怕了。本来还千方百计想进去的。吃饭的时候老板说young career award基本上拿到了。这真是个好消息。这样不仅有四十万的funding，评tenure也是很大的筹码。 

写了两个文件utils.h utils.cpp。结果被折腾惨了

随机爆出unresolved external symbols

明明定义了函数体

rebuild有时候通过，有时候报错

后来终于找到原因

opencv里面也有utils

把这两个文件名改掉就ok了

之前的代码特别慢

感觉测试和demo都不是很方便

总之感觉非常非常不爽 

这两天重新想了架构，目标是尽量高效

基本上对模块进行完全重写

今天测试了一下，很快揪出问题

原来是一个类的copy太慢

里面缺省定义了一些矩阵buffer

每次copy的时候这些矩阵都被重新算一遍

改用直接copy矩阵，速度也没快多少

有可能矩阵create和release都特别耗时间

重新定义了个参数类，不包含任何矩阵buffer

把需要的矩阵buffer放到另外一个地方

这样一下子速度快了一百多倍！

我开始明白为什么很多c/c++程序员对程序速度的提高非常痴迷

我开始恨不得把每个函数，每个算法都优化一下 

在新的架构下，做这种改变非常容易

另外，细节的visualize, log，测试也都变得容易很多

其实之前还将一个核心的算法单独提取出来作为一个模块

结果一下子又扩展了十几个类

老板昨天又问how far

我说基本上算法部分都完成了，主要是测试real data

这两天换了架构，估计把系统重新搭好还得花两天 

唉，本来一个月前就要搞定的，到现在还不知道啥时候才能做完

//接着说速度

除了良好的代码设计，提升编码速度的另一个核心是对领域问题的理解以及对解决方案的理解。或者，这个核心更加重要。

代码说白了其实是头脑知识的编码。

如果对一个问题的理解不够彻底，缺乏洞见，那么，写程序的时候必然会受到各种各样的魔鬼缠绕。这些魔鬼看不见，也不知道藏身何处，或者，即使知道是某个地方出了问题，却也无法纠出魔鬼，因为可能是我们本身的算法出了问题。

以前读书的时候，书上写程序=算法+数据结构。

而代码的设计与算法无关。

而算法其实相当重要。这一点经常被忽视。

不同的问题会有不同的算法。而好的算法，则需要好的数学功底。

最近搞robot。发觉很多不同的问题，最后都归结到一两个核心的问题。而核心的问题，我的解决方案并不能令人满意。于是我找了ye教授。ye教授不愧是数学牛人。问题说出来，答案立马出来。算法相当好，而且简单。唉。我就觉得我的数学还是不够。相当不够。

算法的问题一般到大量数据处理的时候才会冒出来。

对每个细微的算法，都必须有详尽的测试，批量数据的测试。保证算法的每个细节，自己都能有清晰的理解。

而算法本身，还需要专门写文档，用公式来描述。公式比代码更简洁。

之前头的那篇paper的算法，本来已经写到类库里。但是总感觉有问题。后来单独抽取出来作一个项目，写模拟，error evaluation，发现果然有漏洞。后来把所有的漏洞都解决，花费了不少功夫，但也发现了一些以前所没看到的东西。这些东西隐藏的很深。而这些漏洞的解决，基本上都要依赖数学的逻辑。

恩。对于核心的算法模块，必须详尽的写文档，分析每个可能发生的情况，必须作详尽的测试，做模拟，error analysis。 

昨天突然明白，对他人的要求，不能超过他力所能及的范围。

line tracking本来一直让师弟作，而且做了一两个月，但是也没有好的结果。而且，到后来进度越来越慢。前些天看他的代码，发现就像面条一样。面对这样的代码，即使是我，也很难再添加或者修改新的东西。所以我也就从头开始自己写。

其实，这个问题自己也有。到现在，robot也还没搞完。虽然有了一点儿初步结果，代码确实也写了很多。但是，感觉修改，添加新功能，调试，都不是很轻松了。昨天又梦到老板的追杀。哎。我想我得好好反省一下。

感觉问题可以归结为一点：速度。

速度似乎总是随着时间越来越慢，到最后就像蜗牛一样。

也许，代码的质量可以直接用改变代码的速度来衡量。

任何的代码，天生都是不断演化的。要么他死掉，要么就得持续的成长。如果有一天无法成长，那么也就到了死期。

robert martin的<<clean code>>其实主要解决的也就是这个问题。核心原则之一是，如果我们想修改或者添加一些东西，我们立马可以找到变化的地方，以及做出相应的变化。如果我们的代码可以做到这一点，并且持续做到这一点，那么速度应该是有基本的保证的。围绕这个原则，代码必须清晰易懂，必须职责分离，类和函数必须短小精悍，程序必须容易扩展，等等。

我想我基本也遵循了这些原则，并且。模块化也很细致。但是，对于核心的模块，改变却变得麻烦，这是什么问题？

感觉自己丧失了big picture，也就是对全局的控制，不知不觉之中。

最开始的时候，所有的模型都在头脑里面，很想尽快地把头脑中的模型实现出来。而代码就像一张白纸，空空如也。所以，可以随意的涂鸦。所以这个时候可以非常之快。这个阶段可以称为初始阶段。而过了这个阶段，比如系统的基本框架搭完，也有一些基本的测试。然后进入集成测试阶段，看看整体效果如何，还有调试。这个时候进入迭代演化阶段，算是中期吧。在这个阶段，已经有一个基本的系统，但是还不够完善，或者还缺乏广泛的测试，或者有些模块需要更换，添加。这个时候，系统演化的速度就开始慢下来。感觉就像小宝宝成长一样，剩下来的前几个月长得飞快，天天一个样，天天感觉得到体重的增长。在这个阶段，小宝宝的各个器官都在迅速发育。而过了这个阶段，小宝宝突然变得基本不怎么长了。也许过一个星期才感觉到有点儿增长。看来神的设计也遵循先快后慢的规律阿。hoho~。回到我的问题吧。感觉自己现在就在第二个阶段，而在这个阶段，慢慢失去对全局的控制。这儿加一点儿，那儿改一点儿，系统已经悄然发生变化。不仅如此，面对的不再是一张白纸，可以随意写下自己的想法，而是一个布满文字的纸，需要先找到对应的空隙，然后想出调整的策略，然后作一点儿改变，继而还得写测试类，以及对测试进行相应的调整，还没完，还得对受影响的代码进行调整。

虽然良好的模块化可以大大减轻这个问题。但是，人无法从一开始就设计出完美的方案。因为随着时间的变化，我们对系统的理解也发生了变化。ok，我们可以用重构。但是，重构似乎都是微观的，而且，重构带来的变化，也会让新的系统偏移我们最初头脑的模型。我们开始只关注细节，而丧失了对整体的把握。而重构，并没有强调对整体的把握。

我想这个时候得往后坐坐，重新看看整个系统的框架。就像画画，或者盖楼一样。得从细节跳出来，从更远的地方来审视整个东西。

敏捷编程说代码就是设计。这个不完全正确。应该说，代码是微观的设计。我们仍然需要宏观的设计。而宏观的设计，也许无法用代码表达。也许，一副图，一张表，一个文档，可以更好的表达。paper就是算法级别宏观的设计。以前听人说，其实先写paper，再写程序比较好。确实如此。所以，如果说重构的话，我们其实得时常进行宏观的重构。

有时候，也许需要完全更换一套解决方案。因为仅仅在原有的解决方案上修改是无法推进系统的。ok，这个时候，我们又不得不再次进行宏观的设计。

恩，说来说去，总结为一点，时常从代码细节跳出来，从宏观审视整个系统，理解整个系统，并在宏观上，进行必要的重构。

其实，缺乏宏观控制的问题仅仅是速度变慢的一个方面。 //怎么突然发觉经济危机也是因为缺乏宏观控制？大家太相信市场，而市场里的每个行动的主体却都是微观的。微观利益的最大化，同时又缺乏宏观的控制，经济危机就是恶果。

另外一个问题，也许，是更关键的问题，则是对问题领域的理解，以及解决方案。任何的问题都可以有很多的解决方案， 

build a rock-solid intuition for how it works

From: http://www.randomhacks.net/articles/2007/03/07/hefferon-linear-algebra-review 

已经花了三天时间搞line tracking了

发现经典的方法都没办法用

好多明显的line都找不到

而且有很多重复的line

反复尝试

决定自己开发一个方法

竖线的试验效果还不错

不过速度非常慢

可能是实现问题

不知道还要搞多久

今天发现空间扩大到了1G。这样基本上可以随心所欲的把第三方类库放上去了。

碰到林哲

刚刚注册，旁边出现一个人，叫我名字，一看，竟然是林哲。他说刚从洗手间出来。真是巧。六七年没见了。也没联系过了。只是听说他去了马里兰。他结婚了。看到了他的老婆。我也结婚了。而且我还有了孩子。他说了几遍我长大了。hoho。我想我以前就是一个小毛孩，而现在成了一个有小孩的大人了。中午一起吃了顿饭。他打算明年二月份毕业。真快。正在等西门子的消息。我以前听ye老师说西门子面试至少要三篇顶级会议的paper。看来他比我牛多了。听说hu guoqiang都当professor了。更快了。也不知道自己明年找工作会怎样。

来了这边四年多，这是第一次来las vegas。发现其实没什么好玩的。都没啥意思。路上很脏。很吵。到处都是赌博机，还有挑逗的图片。拍了几张照片。没有看show。很累。一个人也没什么意思。没有赌钱。记得在出国前跟xuhan聊过。他那次去las vegas。当时特别特别羡慕。现在终于来到这个地方。发现自己并不感兴趣。 

虽然程序不是那么多，但是分了很多单独的模块。每个模块有单独的solution，包含对应的src, test之类。每个模块有单独的目录。在chromium里面，非常普遍的做法是一个目录下包含上百个文件。感觉这样的话，改变程序的时候查找起来会不是很方便。也许是因为每个人只负责几个或者几十个文件。这样，负责的人也就很清楚。现在自己的麻烦是

1。每新建一个项目，就得设置很多path。如果是library，要设置include path。如果是test，还要设置library path和libs。

2。对library的头文件引用比较多。这样，如果library里做了一些文件的改动，其他项目的文件也会受到影响。

3。不知道怎么自动的集成各个模块生成一个统一的lib。 

好像主要也就是这两个问题。

对于第一个问题：核心类库模块的开发，使用project dependencies来解决引用。构建一个统一的solution。里面包含各个模块的projects。

对于第二个问题：每个模块单独构建一个头文件，包含所有必须引用的头文件。所有模块都使用整个类库的namespace，不用自己的namespace。

对于第三个问题：一个简单的方法是新建一个项目，包含所有必须的源文件。另外一个办法是使用scons脚本来构建。

对于应用，构建一些vsprops，包含通用的libs路径之类。 

http://stackoverflow.com/questions/111631/visual-studio-solutions-multiple-project-how-to-effectively-propagate-project-p

//继续研究chromium

chromium里的任何项目都没有设置include path，而头文件的引用都是以src为根目录。那么include path到底是在哪儿设置的呢？ vs环境也不可能设置这个。调查了一下，发现这个：Inherited Project Property Sheets。所有项目都设置了这个属性。这个属性对应有很多的.vsprops文件。而vsprops又是什么？网上的信息并不多。msdn讲的也很少。

http://msdn.microsoft.com/en-us/library/a4xbdz1e(VS.80).aspx 

开始那个问题，也就是include path在哪里设置的？就是在这些. vsprops里面设置的。任何的project文件可以引用多个.vsprops。vsprops其实也就是项目设置。可以设置include path之类。至于library path和libraries，chromium的做法是全部用project dependencies。每个solutions里面都单独设置denpendent projects的目录，并包含哪些projects。dependent project全部设为static library。

再回到.vsprops。一般来说对于本身项目，建立一个common.vsprops，里面设定本身项目的include path。而这个path一般回到chromium的src目录。对于libs的话，如果在solution里面包含对应的项目文件的话，就不用单独设置path。如果没有包含，比如googleurl使用libxml，那么，就引用libxml里面的一个using_libxml.vsprops，这个vsprops同时也可能会被其他项目引用到。那么使用libxml的include path在哪儿呢？就在using_libxml.vsprops里面。是这样的：$(SolutionDir)..\third_party\libxml\include。这么做有一个危险，那就是其他也使用libxml的项目的solution file的目录必须是对的，也就是，保证$(SolutionDir)..\third_party\libxml\include能正确找到libxml的include文件夹。由于大部分项目又都是static library，所以libs也就不用设置，只要include path设置就行了。 

很早就想下载下来看一看

今天终于抽空

也是因为新换的电脑，空间比较大

这个东西原始文件就有一个多G

感觉学到很多东西

最感兴趣的是项目是怎么组织，编译，测试的

最近这些问题搞的比较头疼

现在的做法是分成很多小的modules，每个module都有单独的solution，单独的src, test目录。这样做起来感觉写程序任务清晰了很多。不过问题是modules间的包含引用比较麻烦，总得设置一堆的includes，lib之类。另外，这样的划分对部属不是很好。觉得部署的话应该单独生成一个大的lib或者几个，而不是一堆小的lib。本来想找一个类似ant的工具，写配置copy, build之类。但是c++里面没有好的对应的工具。cmake好像只负责生成编译环境的项目文件。这两天看到scons，感觉很有前途，用python写脚本。然后发现chrome也用scons，id公司也用。scons的tutorial里的samples都很简单，没有介绍一个大项目里面怎么应用。于是索性把chrome的源代码下载下来了。简单的研究了一下：

1。用visual studio开发。项目文件里面没有任何的include或者lib设置，完全基于dependencies。//没想到可以这么做。真是弱啊。

2。单元测试文件都和源代码放到一起。基本上每个源代码文件都有一个对应的unittest文件。单元测试都只有源文件，没有头文件。不同的项目用了不同的测试框架。大部分是gtest，但也有其他的。

3。很多文件都有前缀名，比如render_view_host,render_widget_host,render_widget_host_view之类。也许这是在项目开始的时候没有设定render的目录，后来也就通过加前缀名来组织了。

4。browser项目没有namespace。v8源代码主要是v8::internal。googleurl的namespace比较多，但都是独立的。 感觉namespace比较乱。

5。没有用boost库

6。文件名全部是小写加下划线。大部分项目文件的都放到同一个文件夹里。以前缀来分组。比如base里面。

7。v8提供一个单独的头文件。include/v8.h。有两千多行。用户使用v8只需要调用这一个头文件。实现则完全是另外一套。

8。用scons来构建编译。每个项目都有单独的scons脚本。也都不复杂。

还有很多东西。慢慢看吧。 

其实是一个非常头疼的东西

但是也是编程过程中碰到最多的一个东西

XP里面提倡怎么简单怎么设计，不要过分的设计

说起来很简单，其实很难把握

一方面要追求好的设计，一方面又不能过分

另外还要测试驱动

好的设计就得遵循一些基本的原则

比如面向接口，比如srp，比如可替换原则

一旦过分追求这些东西，又会导致过多的类，过度的抽象

另一方面，最简单的设计又是什么？

这个似乎也没有人说。

改善设计的基本方法是refactoring

不过，设计很容易扩大

比如，对于一个问题，很自然的想法是设计出一个非常好的解决方案或者改善现有的方案

而任何试图改善解决方案的设计都会导致更多的问题要解决，也就是要单独花很多的时间

不仅要更新一个实现，还要测试，还要修改受影响的代码 

而如果不改善呢？ 也许现有的蹩脚方案总是让人不舒服，做起事来总觉得麻烦

那么到底是改善还是不改善呢？

而实际的约束是，过几天就deadline了

所以呢，那就先不改了，把deadline熬过去再说吧

不过呢，一般过了deadline人也就轻松了，又没有改变代码的动力了

而这个时候代码的质量已经下降

下一个deadline来到的时候，代码的质量又继续下降

到最后呢，不改不行了

怎么办呢，只有趁着deadline还不是那么紧的时候做refactoring或者改善设计了。

其实小的设计改动很方便

不过大的就会很麻烦了。

最近搞robot的程序，本来觉得很简单的idea，结果越整越多，还不见完。也许是因为更加测试驱动了吧。有了测试，感觉确实好多了。确保每个零件都没问题。测试驱动带来的另外一个好处是模块化。其实对research发paper也有很大好处。现在感觉任何一个项目都要划分这么几个模块：

1.核心的数据结构模块。领域的概念，以及领域的基本逻辑。

2.io模块。一旦数据结构变得复杂，需要读写文件，定义文件格式。io就最好单独划分出来。也方便以后更改。

3.算法模块。算法非常易变，而且有可能会有不同的算法实现相同的问题。核心的数据结构相对来说变化小得多。

4.demo模块。对于图形图像，这个非常非常必要。图形图像的很多东西都没办法拿cppunit来测试的，必须的人看结果才行。demo主要也就是visualization。

5.simulation模块。这个可以生成ground truth来测试算法，以及其他的任何模块。

每个模块都要写单独的测试。

其实robot程序里面还包含其他的方面，根据任务来划分。比如图像处理，特征提取等等。这些和robot分开来，另立模块。 

最近很忙，cvpr到底只搞了一篇，还是暑假的稿子。robot信誓旦旦要搞出来，结果程序越编越多，目标就像海市蜃楼一样，总觉得就在眼前，可是每走一步，总还是那么远。记点儿家里的事情：

准备让老爸签证的，但是材料寄丢了。下次得用快递。明年初再让老爸签吧。

嘉嘉已经会翻身，不过还不会连续翻。笑的时候能够偶尔发出声音了。睡觉还是很好，但是吃奶比较调皮。

旧的sony电脑坏掉了，买了台新的hp，4G内存，250G硬盘，算上税，减去rebate，合计680左右。速度很快，键盘很好使。感觉工作效率提高了很多。

老婆治了颗牙齿。最近有点儿过敏，经常打喷嚏，也没感冒。很多人在美国住上几年都会得这毛病，以前wang zheng也是。准备以后下午早点儿回来，陪老婆出门走走。

chen li结婚。谈了好几年，终于结了。据说伴娘在婚礼上昏倒，两次。

感恩节快到了，今年又在michael家。不知道michael现在怎么样。在婚礼上碰到pozhou，问他工作的事情。他说现在失业率比01年还高，如果有任何的面试机会，一定要尽全力的把握住，没有挑选的余地。他说michael也想去microsoft。michael现在在freescale，听说要裁人。

最近油价下跌的很厉害，已经不到两美元。老婆说这不是好兆头。

It's -> It is

[4] 之类的引用不要做主语

equation 的前面加上Eqn.

the design is not good

very big classes, violate single responsibility principle

circular dependences, bayes and slam

big functions

interfaces are not clean

hard to reuse

defined a lot of macros

hard to maintain and debug

too many non-necessary comments

the layout of code is not consistant, data definition and function definition are interwined

from head first design patterns

when you see "new", think "concrete"

when you use new you are certainly instantiating a concrete class, so that's definitely an implementation, not an interface.

depend upon abstractions. do not depend upon concrete class

好像没办法用

运行程序老是the application failed to initialize properly 0xc0150002

用depends看，cv110.dll有问题

换成1.0版就好了

现在决定尽量把第三方类库都包含在项目里面，这样在迁移的时候就不用重新安装，也避免可能出现不兼容的情况

In the beginning, we have good will.

Wish the code we write and the software we make are readable, maintainable, robust, scalable, and extensible.

But the road from the begining to the goal is not clear.

We need instructions and good senses.

We need the ability to discern what are good and what are bad.

We need to follow the instructuions; and resist temptations.

We need to think deeply to choose the right way.

We need to create a set of rules for ourselves; and then follow them, consistently.

seperate those change and those do no change; maximize decoupling

these are the basic principles of all designs

from the basic principles, we should

• minimize dependencies
• program to interfaces, not classes
• ocp: open for extension, close for modification
• keep the interface clean
• each object (classes, functions, modules, systems) only does one thing
• no duplication
• easy testable

another basic principle: readable

which leads to maintainable

from the basic principle, we should:

• make the name expressive, no ambuguity
• make the functions/classes small
• apply the seperation principles
• make the code organization easy to follow, easy to search, easy to understand

another basic principle: make others happy

make the libraries/systems/frameworks

• easy to use
• easy to compile
• easy to learn
• easy to test
• easy to change (without affecting client's code)
• easy to maintain 
• easy to be replaced

Concurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.

In fact, the design of a concurrent algorithm can be remarkably different from the design of a single-threaded system.

Getting Clean via Emergent Design

What if there were four simple rules that you could follow that would help you create good designs as you worked? What if by following these rules you gained insights into the structure and design of your code, making it easier to apply principles such as SRP and DIP? What if these four rules facilitated the emergence of good designs?

Many of us feel that Kent Beck’s four rules of Simple Design1 are of significant help in
creating well-designed software.

According to Kent, a design is “simple” if it follows these rules:

• Runs all the tests
• Contains no duplication
• Expresses the intent of the programmer
• Minimizes the number of classes and methods

The rules are given in order of importance.

Writing tests leads to better designs.

The fact that we have these tests eliminates the fear that cleaning up the code will break it!

But the most important way to be expressive is to try. All too often we get our code working and then move on to the next problem without giving sufficient thought to making that code easy for the next person to read. Remember, the most likely next person to read the code will be you.

So take a little pride in your workmanship. Spend a little time with each of your functions and classes. Choose better names, split large functions into smaller functions, and generally just take care of what you’ve created. Care is a precious resource.