My another blog

This is my independent home site, http://184.82.230.172/

Taobao has sold their data

Data Create Money : http://blog.sina.com.cn/s/blog_4e424e2101000b5y.html

春天来了，给笔记本洗洗澡

笔记本最近风扇似乎出了问题，稍微运行大一点的程序就开始老牛叫一样，趁着今天打扫房间干脆也给小黑做个清理。

拆解笔记本并非易事，极有可能拆不开（放弃清洗吧）或者拆开了装不上（这才是真正的悲剧开始）或者是装上了开不了机（。。。。。）

要想防止悲剧，就要做足工作。先查了N多的帖子，总算心里有点普，然后就开始干了。

先去买好机油，硅胶，清洁套装等，然后买扁平的和梅花的螺丝刀，ok，开工。

先拆掌托，螺丝好办，咔嚓咔嚓就拆下来了，接下来要将掌托的信号线弄下来，用手扯了一下还挺结实，再用点力，叭下出来了，心想坏了说不定线扯断了，仔细看还好，是因为扯得方向不对，并线路并无损害，笔记本的结合方式和台式机差的蛮远。

接着是键盘，看起来还顺利。到了关键点了，U型架就是噩梦，一个很窄的架子居然有10处之多的卡扣，我顾得了左边顾不得右边，最后用螺丝刀使劲撬才搞定，事实证明，对U型架太温柔是不行滴。

接着是光驱，电扇，CPU，拆起来不算太难，电扇拆下来后果然里面灰尘满面，赶快清理之后，顿时自己都觉得神清气爽。然后开始给风扇滴机油，弄了半天总算灌进去了一些，试着转了一下，恩，很流畅。接着是CPU涂点硅胶，ok，开始还原。

叮叮当当，一路顺畅，最后都搞定之后，发现居然剩下了一颗螺丝，崩溃。看那螺丝还蛮大的，应该不是内部用的，在外部仔细查看发现确实有几个地需要螺丝，但是也不需要那么长的，哎，算了，多了就多了，总比少了好，IBM机器够硬，少个螺丝应该问题不大吧。开机，哈，果然风扇生硬消失。棒棒。

一个字，慢；两个字，很慢

早上访问淘宝，首先是在firefox下布局一片混乱，然后试图用IE打开，恢复了漂亮的界面，然后试图输入物品的时候居然卡住了，我靠，难道IE也玩死机？再次刷新，界面又是一片混乱，淘宝啊淘宝，咋办？

很多格言，只要我们遵守了其中的20%就可以生活的很美好，可是看起来遵守5%都是如此的困难

一个既亲密而又相互独立的关系，胜于一千个一般的关系。这样的关系，会把我们从不可救药的孤独感中拯救出来，是我们生命中最重要的一种救赎。 如果不曾体验过，你就无法知道这种关系的美。

直面痛苦。直面痛苦的人会从痛苦中得到许多意想不到的收获，它们最终会变成当事人的生命财富。

人的动机分两种：内部动机和外部动机。如果按照内部动机去行动，我们就是自己的主人。如果驱使我们的是外部动机，我们就会被外部因素所左右，成为它的奴隶。

 

幸福最完整的定义就是：期望和现实的距离。如果我们相信，人生就是一连串苦难的历程，那么我们就心怀感激，开心生活，是不是？

testing should be move with time

right logic

available service

consistent data format

Do we really know who is user? who is customer? where we will go?

软件延期，我们真的知道自己该做什么吗？

对于没有做过软件开发的人，他大概是很难理解软件延期的概念的，特别是当软件一延再延的时候，那些家伙一定会发火。让我们来看看软件为什么会延期，难道真的No Silver Bullet 吗？搞个Mercury也好啊

1. 我们清楚的知道每个时间点吗？注意，是我们，而不是PM自己。是不是每个人都比较清晰的知道在各个时间点自己要交付什么样的功能或者性能？

这当然是个很大的话题，我相信三本书也写不完，但是基本的问题是：

• 每个人都清楚未来一个星期中的每一天他要做的是什么吗？
• 我们是否一开始就清楚验收标准（各种UT，FT）然后逐一实现呢？
• 我们是否常常进行阶段性的review以查看自己是否真正的完成自己设定的目标呢？
• 再细一点，每天早晨我们坐在电脑前的时候，一天的todo list是不是已经按照优先级，并且被具体化，细化的列好了？

2. 我们真的弄清楚了需求了吗？

    我们有了比较细化的功能点，还是在凭印象，拍胸脯？模糊的一拍脑袋，这个东西应该可以满足用户的需求，捋起袖子就开始干了。到了中间，决定跟用户的需求好像不太match，看看自己费尽心思写的代码，其中还不乏令人叹为观止的方案和算法，怎么忍心丢弃呢？于是在这个基础上修改修改，耶，基本满足需求了呀。设计方案有review吗？那些参加review的家伙真的花了时间仔细看你的文档并且准备给你提建议了吗？

3.  当初的那个大的计划框架是谁制定的来着？那个家伙为什么指定计划的时候没有跟我讨论一下？

     如果不能跟相关方一起指定计划，项目延期几乎是必然的，这里的相关方多指合作方，客户。在一个团队内部，这个问题一般没什么。

4.  计划真的被执行了吗？

     哎呀，明天有个milestone啊，开始询问每个成员：明天那个milestone能赶上吗？什么？不能，为什么？&&&&$$#$@)@#@…,PM总是最后一刻才知道事情这么糟糕。

     当PM拿出计划表准备核对的时候，他发现上面只有：XX月XX日 CC，XX月X日 ZBB，XX月XX日发布；哦，天哪，那个细化的时间表在哪里？在哪里？我们真的在执行计划吗？

5.  谁在追求完美主义？

     恩，这个设计很cool，用了不少新东西，看起来也花不了多少时间，好，就这样了。搞了两天，发现搞不定，时间无情的流逝了。

     用户说这个功能会让他们很节省时间，恩，难道我们不能做吗？怎么可能，我们是谁？好吧，加上去，为什么不呢？更改一下计划，结果发现，那个功能真的不好做。

6.  开会是在节省时间还是谋杀时间？

     大部分时间开会时为了提高沟通效率，节省沟通时间的。事实是这样吗？那些超过30分钟的会议都是必须的吗？那些会议的记录在哪里？1个星期后拿过会议记录看看，这个会议带来的价值真的值得所有参会者花费那么长时间？或许根本就可以取消。

GCC 4.4.4 来了，其中加入了部分C++0X中的内容

http://gcc.gnu.org/gcc-4.4/changes.html

网络视频速度太慢了

大家都看到了网络视频这块蛋糕，可是没有一个做的让我满意的（youtubo等访问受限的除外），为什么？为什么那些那些家伙搞不出更好的压缩算法？也许是他们根本就没有细心用过自己的产品。

也许我们也要注意这个问题，当我们觉得产品还可以的时候，可能已经被用户骂得狗血喷头。

视频压缩的确是个难题，但是如果我们能区别对待的话，也许会好一些，比如斯诺克，就是一些坐标，提前压好放在那里，然后给客户端加载一个皮肤也许就解决问题了，至少解决了看斯诺克的问题。

让我们爬山去

没想到有时候拿出时间和心情爬山也会成为一种想法，即不是那么容易实现的。或忙或懒，总是能找到一种理由去不做，还是那句经典的话：如果你不想，你有一千个理由能支持你不去做。

从老和山麓上去，选了一条没有走过的小径一直走到山顶的亭子，中间累的气喘吁吁，就开始瞎想。运动员体力比我们好，人家在运动的时候是通过增加每次呼吸的深度缓解的，而我们呢，是通过增加呼吸频率来解决的。增加呼吸频度肯定是有个上限的，到了这个阈值之后，再牛的人也不行了，让你每秒呼吸300次，呼吸这个动作消耗的能量恐怕比产生的还多，肯定不靠谱了。类似的现象很多，比如之前的摩尔定律的一个部分是说CPU的主频会上升的很快，计算能力会随之大幅度增加，但是现在呢，频率到了极限了，那些家伙们开始加core了，于是问题得到了部分解决，等到多个core也解决不了问题的时候，分布式又出现了，多台机器一起解决；未来，我们会碰到非常难解的问题，需要多个数据中心一起解决。以上两个例子似乎说明了一点，我们总是倾向于首先靠自己解决问题，当问题复杂到实在无法解决的时候，我们会依靠团队，依靠其他部门，其他公司，这还是符合人类的基本思维方式的。

中国有句古语：分久必合，合久必分，跟这个道理很类似。

在人类的起始阶段，如果不合作就很难生存，所以，人类是以部落为单位存在的，部落内部的分工，合作是非常紧密的。当生产条件好了之后，各种生活设施也更加先进了，随时随处的合作就不必要了，于是人们开始成立家庭为单位的单元，但是其实家庭不是team，不是group，不能算是合作的一种（我很难想象老公对老婆说，我们结婚吧，因为这样我们可以一起做好某件事情，如果这样，下场一定很悲剧），因为里面融入了最复杂难解的部分——人的感情。也就是说，随着生产的进步，人们合作的不再那么紧密了。社会继续发展，人们发现，需要解决的问题过于复杂，凭借个人的能力实在搞不定了，于是合作又开始多起来，比如现在人们常常提到的团队合作，社会常常宣扬的“个人英雄一去不复返”等等，都说明合作又开始进入主流，这是因为我们确实又碰到了个人解决不了的问题。

CPU解决问题首先靠自己提高频率，实在搞不定就开始加core；人类解决问题首先靠自己，搞不定了就开始团队合作；剧烈运动时候先考肺部自己提高呼吸频度，搞不定了就要求胸腔合作每次多吸入一点氧气。。。，我想，如果狮子，猩猩等学会了独立生活而不是必须群居，也许会和人类一样智能，不是有句话吗，集体的智慧等于三岁小孩。