Home » 中文
今天的湾区阳光灿烂,280州际公路两边的绿色山坡和蔚蓝的白云,让人觉得自己是Windows XP桌面上的一个图标。
下午,2点,终于来到Facebook这个神奇的公司。他们的新家在南加利福尼亚街的最里面,一幢两层的楼里。他们刚刚从车位紧张的Palo Alto城里搬到这里,据说一层楼又要搬了。我好像是他们再次搬地方前的最后一批访客。这里,车位依然紧张。Facebook有那种蓬勃向上的感觉,处处都在生长。长得结实的前台问的第一个问题就是:你是来访问的,还是来面试的?
Facebook的格局和百姓网很像,就是平板桌子,一个接一个排开,没有隔间,像是巨大的停车上的车位。每个人站起来都可以看到其他人。这架势,豆瓣有一点,Six Apart也是,Mozilla也是。比起Google来说,Facebook身上依然可以看到创业公司的影子。办公室很Cool(绝大多数的硅谷公司都很cool),很实用。没有Google那样fancy的航天飞机,也没有太多的装饰,除了人,就是人,非常的实用主义。
Facebook里面到处挂着国旗。毕竟Facebook已经是全球的网站,美国已经只占30%的访问量。书架上摆着不同版本的Risk游戏 - 他们非常推崇的桌游,是一种战略游戏,两个人一个国家一个国家的PK,看谁最后占领的领土大。Facebook的市场,的确就是按照Risk的战略来做的。
让我有些想不到的是,Matt向我介绍一个人。他坐在5张桌子拼成的岛的里面一张桌子上,远离光线好的窗户,身后是一个人来人往的会议室。我们握手,然后我看他很眼熟,然后想了半天,总算觉得好像是。。。“Are you that Mark?" 他说是呀。他就是Facebook的Mark Zuckerberg,创始人和CEO。
之后我们聊了会儿,期间还有域名注册商的推广电话打进来,我估计是想让他买Facebook的其他什么服务的(这位打过来的老兄也挺雷人的,估计不知道电话这边是谁,不见得Facebook的DNS的联系人还是Mark吧)。
Mark显然比我想象的年轻,并且安静。别人都有超大的屏幕,他就一个白色的笔记本电脑。那个桌子,显然就是一个拘谨的访客,除了电脑和几张纸,好像没有什么了。这让我相当惊奇。不过他确认,这就是他干活的地方。那种不羁的感觉,在我认识的朋友中,倒还真和VeryCD的黄一孟同学神似。

关于Mark的评论,我觉得最有趣,也最深入的是这一篇:Mark Zuckerberg: The evolution of a remarkable CEO。
当看到一个长相普通的年轻人站在身边,并且可以做出成就的时候,对于我这样比他大7岁的人来说,还是有很大的启发 - 如果可以和神话里的主角聊聊天的时候,神话就不是神话,而就是生活。至少,我们不再觉得很多事情不可能。
Posted by Jian Shuo Wang at 03:54 PM | Comments (9) | TrackBack (0)
为了大家看起来方便,我把最近的几篇文章的全文也放在这里了,希望可以通加增加鼠标的拖动距离来减少鼠标的点击次数。
在三亚的时候,Wendy同学在经历了从5星级到家庭旅馆的不同住宿以后,评论道:
酒店服务的作用,就是把房间里其他人住过的痕迹彻底抹掉,让下一个一点都察觉不出来,不留一根头发,或者被人动过的痕迹。
这次海南之行,自驾车1100公里,带着小逸凡,环岛一周,彻底的爱上海南这个大小正合适的岛。
记录如下:
- 东线高速比西线高速景色好是真的。东线从海口到三亚,经过文昌,琼海,万宁,每个地方都可以住下,都可以去看几个湾。西线高速,恩。。。,是一条高速。
- 西线高速比较搞笑,三亚出来到尖峰岭那一段的很多出口接着土路。土路延伸进一片椰林,就不见了。
- 海南的自然景观加上高速公路不收费,下一个出口兜一圈再上来很方便,和硅谷的开车体验很像。
- 海南汽油比上海贵1块多,但不收养路费了。所以海南几乎都是丰田,本田和尼桑等省油的日本车。
- 在所有的湾中,我的最爱:第一名:香水湾;第二名:石梅湾;第三名:海棠湾;第四名:亚龙湾;第五名:三亚湾;第六名:椰林湾。
- 最漂亮的山:第一名:终年云雾环绕的牛岭
- 对东环铁路很期待,海口到三亚90分钟,4分钟一班的规划,就好像地铁一样,把整个海南连成了一个大的城市。
图片如下:
香水湾:

雅力士远比我想象的好,很不错的小车:

三亚港还是很有港口的感觉的。

尖峰岭

更多照片:
如何最大限度的提升中国的网站速度,今天发信给我信任的朋友们,老冒回复如下:我朝Internet南北不畅通的解决方案(老旧方案)(需要翻墙。可以在Google Reader里面订阅http://robertmao.com/feeds/latest/访问)。很多要点老冒几乎都提到了,我在此列出我的一些问题和思考,共有用样需求的各位讨论。
1. MySQL跨越广域网的复制(Replication of MySQL)是否稳定可靠
除了老冒写到的基于页面或者部分页面的缓存方案(Squid as cache),还有一种更加冒险,但是实时性更好的方案就是在异地的数据中心建立MySQL的slave节点,进行主数据中心和附属数据中心的Master-slave replication. 按说MySQL复制本身已经是一个非常健壮和成熟的解决方案,但是跨越广域网的效果如何,尚待验证。我觉得,只要延迟平均在秒级别,偶尔出现分钟级别的延迟也可以接受,毕竟整体已经好于缓存+通知过期。
如果通过VPN+SSH在两个机房建立稳定的链路连接,把两个机房可以当成一个网络延迟稍微长一点,稍微不稳定一点的局域网来用,至少比cache方案有一个优点:可以在大动态数据量的时候,获得更好的秒级别的实时性。
同理,基于这种链路的Solr (Lucene)复制,也是一个可以考虑的架构,但是一个未知数。具体情况如何,如小马过河,只有各家自己试过才知道。
如果实现,就可以在系统级别,而非在应用代码级别实现异地的数据的自动cache, validations, rebuild。看起来很美。
2. MySQL master-master复制
除了主从方案,还有一种多中心方案。数据中心A和数据中心B各自有自己的数据库,但为了避免命名冲突,一个中心的数据采用奇数编号,另外一个采用偶数(或者等中心数大于2的时候,对某一大于中心总数的数字取模)。如果从MySQL以及绝大多数的数据库角度,这个操作非常方便。简述如下:
假设A和B在初始时候的数据是一样的,最大编号(auto_increment的上一次给出值)是401。这个时候,只要简单的把两个数据库的auto_increment_increment设成2,
auto_increment_increment = 2
另外有一种直接使用GUID作为id的方案,个人觉得太重了。
这个方案做ID切分以后,就为master-master replication做好了准备。之后两个中心可以相互实时互相复制了。开起来也很美。
但问题是,在大型系统里面,就算有再成熟的技术,简单的永远胜过复杂的方案。对于master-master的复制,我现在依然心有余悸。我的心理障碍就是因为以前技术支持的时候做过一个case,就是因为Windows 2000里面的Domain Controller可以master-master的复制,原理上是一个有问题,其他的可以把好的信息传过来,但实际上,一个小bug或者一个不小心的配置,可以让一台主域控制器的错误拖垮其他的所有控制器。master-master的方案在多于2个节点的时候,也需要额外的设计。
3. 关于cache
基于文件静态化的方案的好处显而易见,但是过期永远是心头的痛。对于像带有翻页这样的操作,除了第一页,其他页面的cache几乎不可能,因为谁都不愿意因为一条信息的更新,让后面的无穷无尽的翻页页面的cache重建。
对于链路层的动态加速,觉得在现在的CND提供商无法获取真正优势网络资源的实际情况下,好似概念多于实际。
所以,如果需要实时,或者准实时的加速,权衡所有方案,我觉得在异地放置Smart CDN是一个比较可行的解决方案。Smart CDN(抱歉,是我新造的词),就是前端部署的不仅仅是页面缓存,而是包括MySQL,搜索,Memcached等等一系列的服务,然后通过第一条提到的方式进行同步。这。。。。。。不是100%确信,只是一种想法。不过我相信这么做的人应该不在少数。
我这里抛砖引玉,希望有过经验的同学分享你的好主意,尤其是成功的案例。在此谢过。
Posted by Jian Shuo Wang at 11:09 PM | Comments (9) | TrackBack (0)我的一个朋友要做提醒服务,发现如果帮用户注册139.com的邮件,发邮件过去,用户就可以收到短信通知。免费,简单。唯一的问题是,139.com的注册过程有一个识别码,就是那种写的乱七八糟,机器无法识别而人却很容易看出来的那种图片(学名CAPTCHA),真的把这个自动注册服务给难住了。
他用了一个简简单单的做法:就是把图片拿过来,原封不动的给注册他的服务的用户,当做自己的CAPTCHA图片。当用户识别之后,他再把用户的输入原封不动的给139.com,这样,电脑要解决的问题归电脑,人脑要解决的问题归人脑。倒还真是个好主意。
其实,这种借别人之脑,解决自己之问题的办法,早在2004年就出现。有人建立免费色清网站,由大量的用户来解决只有人才能容易的问题。他们的用户有足够的动力,来解决哪怕是最简单,最复杂,最无聊的问题。
Google也在使用这个聪明的主意。除了Image Labeler和SearchWiki这样基于兴趣和自愿的工具,我觉得最绝的一步棋是收购reCaptcha项目。reCaptcha是卡内基梅隆大学的spin-off项目。原本是为了帮助网站防止spam。Google收购的原因,确实为了帮助识别图书扫描中遇到的不可识别的扭曲的文字。每次用户会看到两个词。一个词是reCaptcha已经知道正确结果的词,另外一个词是不知道结果的。只有答对第一个词,就可以证明你不是机器,而第二个词的答案,如果和另外一个或者更多用户一样,就把这一答案作为正确答案,放入正确答案库里。就此轮回。可想而知,每天有多少人基于自己的目的(比如发个邮件,发个帖子等)来帮Google解决计算机解决不了的问题。
不仅仅是这些小的应用,现在越来越多原来认为很难解决的问题,开始由人脑来解决。比如说搜索(很多人在尝试social search),还有新闻(social news),还有很多类似的带social的词,暗示的都是这种用互联网把大量的人脑连在一起,共同解决一些难以解决的问题。
这种趋势,如果一定要起一个名字,我会把它叫做“人肉云计算”。它是“人肉计算”(参见人肉搜索),也是云计算(分布的,作为服务的计算模式)。
P.S. 再次重申这个blog的留言政策:广告性质的签名,或者包含广告性质的链接,无论内容是否有价值,直接删除。
Posted by Jian Shuo Wang at 08:37 PM | Comments (11) | TrackBack (0)在一个培训里,我们做了个有趣的游戏。那个游戏是一个囚徒困境的翻版,是为了证明双赢的可能性和重要性的。简化来说,是这样的:
两个人猜拳。如果是你参加这个游戏,你会选择以何种逻辑出拳呢?如果是几百个人,两两玩这个游戏,8个小时以后,最高分获胜,你又会怎么玩呢?
每个人都可以出剪刀或者布。
积分规则如下:
若两人都出剪刀,各得1分;
若两人都出布,各得3分;
若一人剪刀,一人布,剪刀者得5分,布者得0分。
如此往复很多次,积分最多者获胜。
局部和整体
如果从个人自私和理性的角度判断,任何人在任何时候都应该出剪刀。在对方出剪刀和布这两种情况下,自己出剪刀总比出布得到更多的积分:
如果对方剪刀,自己出布,得0分;自己出剪刀,得1分。
如果对方出布,自己出布,得3分,出剪刀,得5分。
同时,把两个玩家的积分相加,就得到总财富的增加。两个人都是剪刀的时候,总财富加2,一个剪刀一个布,总财富增加5,而只有两个人都是布的时候,总财富增加最多,是6。从集体的角度,每个人都出布最佳。
这是一个虽然游戏双方都知道出布对于整体更加有利,却又不得不出剪刀的困境。
最优解
在二十年来的竞赛中,最高分的算法如下(相见维基百科的解释):
第一步永远出布。这是个出奇简单的算法。尤其是第一招就出布好像挺傻的,但最终,这种做事准则总能赢得最多的分数。为什么呢?
第二步和对方上一步出的相同,以此类推
出布,可以说是一个友好牌。他向对方表明自己的善意,虽然这对自己而言危险,等于把赤手空拳的自己把一把匕首交给陌生人一样。现实社会,会有人真么傻吗?
出剪刀,是防卫牌,是不合作的牌,是准备损人利己,或者至少也是正当防卫的牌。
赢得战斗还是赢得战争
对于永远出剪刀的人,他几乎赢得了每一次单独的战斗(不是比对手多得5分,也是至少和对手打个平手)。但最终因为
对于永远出布的人,也是死路一条。没有原则的“善良”,是没有原则的放弃自己的利益,是最快被淘汰出局的。
对于最终获胜的那个仅仅出于自己的私利(就是获得最多的个人分数),却展示了如下的美德:
现实的意义
这个实验的分数设置是有讲究的,它模拟了我们现在的社会:这不是一个零和游戏(不是你死,就是我活),而是一个可以双赢的游戏(只有合作,才能让社会总财富增加,自己的那一份也要增加)。
在这样的游戏中,如果只有一次交锋,或许出剪刀是正解。但如果是多次的多人的游戏,最终,选择做好人是可以被验证的正解。
这也告诉我们为什么我们见面的时候会需要握手,虽然对方不见得一定会伸出手;为什么在电梯里面需要向邻居问好,虽然在现在的社会,会给与回应的机会不会很高;为什么在竞争的时候,不要出损人利己的招数,因为看似一个公司占了另外一个公司的便宜,却实际上伤害了两家公司所处的行业,最终伤及自己。
做好人,不仅仅是乌托邦的理想,和不切实际的道德要求,更是自己利益最大化的必由之路。
小家伙早上有些哭闹,好不容易稳定下来,一个人在小桌子前玩积木。爸爸上班的时候,悄悄地拉开门,希望避免小宝一定要跟着出门的情况发生。就在我马上就消失在门后的时候,被小宝一回头看到。于是,他就站在那里瞅着爸爸。爸爸很尴尬的看了看他,一转身,溜走了。小家伙倒也没有什么反应。爸爸窃喜。
晚上回来,妈妈告诉我,小宝下午问她,“发生什么事了,爸爸为什么早上不理我呢?”
Posted by Jian Shuo Wang at 05:53 PM | Comments (0) | TrackBack (0)© 2002 - 2003 Jian Shuo Wang. All right reserved.


