Recently in Others Category

很多争论其实是源于沟通和理解。人们的理解能力往往是有限的，这些限制很可能来自于不同的教育背景、知识面等等，因此，为了更好地理解对方，人们往往习惯于使用 自己熟悉的 知识去设法理解对方所说的。

这带来的一个现象，在技术人员之间的讨论中，就会是这样：例如，讨论应该怎么造一枚火箭，往往不会有人去随便做评论，因为他们很清楚自己并不是这个专业的人，而这件事明显需要许多非常专业的知识；而如果讨论火箭发射基地的车棚应该漆成什么颜色，则几乎每一个人都会去发表自己的意见，因为车棚的颜色是什么样子，在多数人看来往往没有造火箭那么重要，并且，似乎每个人都能够胜任这样的决策。

将讨论如何造火箭的话题，阴差阳错地变成一群人争论火箭发射场外面的车棚应该漆成什么颜色，就是我们所说的 Bikeshed 现象。

我在这一天时间里遇到了两次这种问题。第一次是我自己把冯牛说的税的算法问题想错了，第二次是我的关于什么时候该用线程的问题被另一个人活活 扯成了 线程 vs 进程的开销问题。

解决 bikeshed 是需要时间的。不过，每一个参与讨论的人，其实都可以尝试使用一些方法来减少这种情况的发生。例如：

头脑空白原则：如果对方讨论的是一个你认为自己很熟悉的话题，不要首先根据自己的理解去下结论，而要先看清楚对方到底在说什么。许多时候，我们自己的知识背景会限制我们能够看到的问题的范围，很可能对方想要讨论的并不是这些东西。

在发现争论持续了很长时间，双方各执己见时，暂时停止讨论，而不是继续论证自己的观点。一个观点的对错取决于观点本身，而不是争论双方所说的话。

避免情绪化的语言----那不会增加你的说法的说服力。

欧盟日前正式无条件批准了Oracle收购Sun的交易，至此，有着28年历史（1982 - 2010）的Sun公司作为独立公司的历史正式宣告终结，今天，Sun的网站已经变成了301 http://www.oracle.com/。

"For 28 years, Sun has stood for courage, innovation, a willingness to blaze trails, to envision and engineer the future."

A tribute to Sun Microsystems

前几天看了一下 iGoogle，感觉就是，做门户首页的真可以洗洗睡了（我说的是首页，我很少去门户网站的首页，而是直奔新闻之类的子站）。

做反垃圾邮件的人应该感谢发垃圾邮件的人吗？

当然不。

今天在推上有人说反垃圾邮件的人应该感谢发垃圾邮件的人，很显然这是斯德哥尔摩综合症。

从微观角度说，给做反垃圾邮件的人发钱的人，是那些不喜欢垃圾邮件的人，要感谢，应该感谢给钱的人。这个世界上比反垃圾邮件有意思的事情有很多，不做这个可以做别的。

从宏观角度说，发垃圾邮件不创造价值，相反它增加了很多人的成本。如果没有垃圾邮件，你本可以做更多能够创造价值的、更有意思的事情，赚更多的钱。

凭什么要感谢那些搞破坏的人？

我还是那句话，发垃圾邮件的人，留神生小孩没屁股眼。

看文档的时候，最恶心的事情就是明明那不是一份作弊条文档，却只罗列作者是怎么把一件事做起来的，譬如说列出命令行选项，但是不说这些选项是干什么的，以及为什么选上这些选项。

一篇不说是作弊条，却又写成作弊条的文档，特别是，假如这张据说是课后辅导书，结果实际上是作弊条的东西还有错（常有的事），就太让人郁闷了。

前一段日子，偶然又看了几集 千王之王重出江湖。其中有一集说到了沈胜天和龙四的决裂，两个人各执己见最后断绝师徒关系。

原则是什么？原则是一个人判断事情的准则，或者说价值观，但又不完全是。我想，还需要再加上一条：不会轻易改变。没有原则的人，要么对于事情的是非没有观念，要么对于是非的判断会经常发生变化，和这样的人长期合作会比较危险。

不知道为什么我总是觉得PIXAR的电影都是主旋律电影，或者说很大程度上都在宣传美国的价值观。

电影开头的部分其实是一段悲剧----老人和妻子从幼年相识直到暮年，希望通过存钱来完成他们周游南美洲的梦想，但因为一次次意外而不得不放弃，到最后老太太快要去世的时候，老爷子用他们童年时候一样的蓝色气球----老人后来成了一个钉子户，因为房子是他和妻子一生的回忆。

一个胖胖的小男孩出现了，老人不想受到打扰而编了一个谎言把小孩骗走，此时建筑工人出现，在争执中老人将对方打伤，法院判决让老人住进老人院，离开房子。老人又找到了年轻时候的那本探险日志，一夜未眠，第二天老人院工作人员来接老人时，他终于放起了一大片的气球，将房子拔地而起，开始了旅行。

影片余下的部分主要是探险的经历，这里就不剧透了。影片的配乐非常不错。

那啥，我是写给那谁看的。

共同点：持有价格低于其价值的资本。

不同点：套牢的含义是，在资本价格较高时买入并持有（此时抛出会导致损失）；抄底的含义是，在资本价格较低时买入并持有（通常，是在价格较低甚至最低的时买入）。

嗯。

最近一段时间在看的一个网站 Accounting Coach。之前在贷款的时候在这里了解的关于贷款现值、PMT等等概念；其他一些概念，如摊销等等，也很有用。

关于Scalability这个词的中文译法，目前还没有一个非常确切的定论。一些文献中将其翻译为"可扩充性"，而"扩充"指的主要是Scale up；而在一些实际的用法中，Scalability还包括Scale down，因此，"可伸缩性"也许是比较贴近原文意思的说法。

互联网应用的可扩充性体现在两个方面：其一，是能够对系统容量进行扩充，也就是说，这个系统各个组件能够提供的服务的量，能够在需要的时候予以扩充（特别是通过添加新的服务器等等）。其二，是这种扩充是有效率的扩充，即，增加硬件投入时，其投入与所产生的效果是接近甚至达到成比例增加的。通常说来，"可扩充"同时暗含的需求是用户的使用习惯尽可能保持不变。如果我们关注某一具体的计算节点，可扩充性还应体现于提高计算节点性能，例如增加其CPU数量或内存容量时，能够相应地改善系统的容量或响应时间，等等。

而另一方面，"可缩减性"主要指的则是说一套系统能够运行在尽可能少的软硬件环境之中。对于大型互联网公司而言，这一点可能并不重要，而对初创公司来说这一点则非常重要。

在设计互联网应用的时候，充分地考虑系统的可伸缩性，能够极大地减少日后的维护开销，并帮助决策者对于投资所能获得的回报进行更加精准的估计；另一方面，高可伸缩性的系统往往会具有更好的容灾能力，从而提供更好的用户体验。

与解决很多其他问题类似，改善可伸缩性最常用的方法就是分治法(Divide and Conquer)。分治属于大道理一类，在实践中，我们比较常用的分治策略包括：

• 提高计算的可并行度。简单的计算，例如连续执行的加法，可以将中间结果的计算并行完成；而复杂一些的计算，例如搜索，也可以通过类似的方式分派到不同的单元中进行，并最终在另外的地方完成汇总。这种策略，比较适合于数据集中数据之间直接关联度不大、生成数据集比输入数据集小很多，并且汇总计算本身引起的开销较小的情形。
• 增加能够完成同一类任务的计算/服务单元数。这类做法中，计算/服务单元仅仅完成某种将输入变换为输出的工作，并且，这类工作不太依赖于其与外界交互产生的状态，简而言之，对于输入数据，计算/服务单元能够自行完成一个环节的计算任务并给出输出。这种策略比较适合于存在，或可能成为瓶颈的位置。举例来说，对于读多写少的应用，通过适当增加cache环节（这些cache是全冗余的，也就是不同的机器之间可以完全地相互取代），就能够有效地提高其负载能力。
• 消除单一故障点/瓶颈。如果一个系统中某些数据只存在一份，或某种计算只能在某一点上完成，那么这些环节就会成为单一故障点，或性能瓶颈。消除这类问题需要更巧妙的设计，简单地将数据复制到更多的机器上并不能够从根本上解决问题，因为在这种结构中"主"节点仍会成为瓶颈。有时，为了达到这个目的需要进行一些折衷设计，例如分段提交的方法，在容忍一部分竞态条件（race condition）的前提下避免另一些、不能容忍的竞态条件。这类做法往往会导致局部吞吐量受到负面影响，或使设计变得复杂。

如题。orz

http://blog.kangkang.net/
http://blog.kangkang.org/

和蛇头GG讨论了一个关于卖票的问题，简单地说是票很有限，需求量很大，如何能够尽可能高效地让票以尽可能公平的方式卖出去。

我设计了一个分布式的结构来解决这个问题，当然这个原型可以进一步改进，此处按下不表。记录一下我对这个结构公平性的描述的一个比喻：

"因为其他人也hash了，或者换句话说，这个系统其实不介意一开始有人就注定拿不到票。 就跟一大群人排队抽签是一样的道理，其实这个就相当于说一帮人排队抽签决定去拿一个信封， 然后拿到空信封的可以重新排队抽签，要么拿到票。"

这个系统其实要求参与进来的客户机一起参与计算（但是这些计算并不会明显加大服务器系统的负载），有一些能想到的缺陷，也许需要克服，也许根本不是问题？先把想法记下来再说。