Author: 爱因万江斯坦

比较Google,百度,搜狗的即时搜索效果

刚在2011年11月07日 23:26 发表了一篇博文,Common law is the law for the common man,随后在Google中搜索了一下,结果如下,时间大概是在11月07日 23:40分:


 

在搜索结果的第五条,出现我15钟前发表的博文,结果显示:14 minutes ago,五分钟后,考虑到搜索结果是来自于google.com.hk ,其中是会包含英文的,我又选择了只搜索中文(简体)结果:

ok,这一次结果是出现在第一位了,紧跟的第二条相关性够高,但页面时间太久远了。

再来看看百度的搜索结果:

不错,也出现在第一条,显示的是15分钟之前,与Google不相上下,因为有搜索的时间差,但第二条的相关性与第三条差很多呀。

 

再看看搜狗,没有我刚才发的文章,后几页也木有,但前两条的结果我在Google与百度里竟然没有找到,三家的算法用的好怪:

 

再试试了搜搜,有道,就连相关性都没有了,更不用说即时性了,大家可以忽略不计了。

一个好产品的市场占有率真的是与其产品质量成正比的。当然了,我发的博文能如此快的出现在搜索引擎的结果中,也与我用的是wordpress有关,因为它有自动更新功能:“当您发表一篇新文章时,WordPress 将会向下面的站点发出通告。更多关于“更新服务”的信息。”

 

后记:考虑到我搜索的关键词比较长“Common law is the law for the common man”,很考验分词算法,而且还是英文的,其结果Google与百度相比,百度好像搜索结果更好一些,当然我是基于中文的结果去比较的,没有比较英文。
我又搜索了一下这篇博文的标题:“比较Google,百度,搜狗的即时搜索效果”,这一次竟然是Google赢了号称最懂中文的百度,在Google的第一页第四个结果就是我的博文,而百度翻了五页了,都没有该文的索引。

Common law is the law for the common man

看港剧《法政先锋3》,看到一处精彩的法庭辩论,立刻想到了大前研一写过的《专业主义》一书,再一次领略专业的魅力。

在本剧的11集40分钟左右,辩方律师在庭上假装了一个喝水的动作,让控方的法证证人错误的判断其真实行为,从而想推翻之前控方的证据推论,而这位法证专家以自己的专业意见给予反驳,表示了反对:

法证专家:我不同意。

辩方律师:请说理由。

法证专家:Common law is the law for the common man。香港法律的基础是普通法,普通法的法治模式是承认规则的客观性,也就是大多数人不成文的做法:习惯、对错,黑白,这是普通法法例的基础。一个行为意义如此,不但是我的估计,是来自普通法的基础,是大多数人的做法。被告将药瓶塞入死者口腔里面,他的行为意义,就是逼死者吞服瓶里面的氯胺酮。

辩方律师:法官阁下,证人的解说已经脱离身为法证人员的专业范畴。

法证专家:我的专业绝对是必须基于普通法的法例基础,所以我的作供并无脱离我的专业。

法官:专家证人,可以继续作供。

法证专家:所以,你刚才拿起杯子放到嘴边,头微微昂起,喉咙有吞咽的活动,这整套的行为动作在正常合理的情况之下,杯子里面一定有水或是其他饮料,正常人才会做出一个喝水的动作。当然,有人会拿起一个空杯子装喝水 ,因为他们在演戏,是一个演员。你刚才这样做的行为意义,是刻意制造一个好像合乎常理,但其实是异于常人理解的假象,是企图推翻事实的真相。在你的立场处境,要否定我的推断,这么做其实可以说是很合理,不过,我必须要强调,凭我基于普通法法例基础而做出的专业判断,被告把一个装有大量氯胺酮的药瓶塞进死者嘴里,逼她吞服,导致死者死亡,这个绝对是接近事实的正确判断。

“我的上司乔布斯教给我的8堂管理课”

史蒂夫·乔布斯影响了无数人,这其中包括前苹果工程师,Posterous创始人Sachin Agarwal。在他看来,乔布斯教给了他如何在一家百亿美元的大公司中建立创业文化,以及如何建立一个应该由工程师说了算而不是由经理说了算的环境。让我们来看看他从乔布斯学到的8堂管理课。

1. 一家科技公司应该由工程师而非经理主导

苹果并没有过多地进行产品管理,大部分项目组规模都不大,而且他们都是由工程师驱动的。最重要的是,大多数经理都是工程师,而非纯粹意义上的产品经理或者由MBA充当。这意味着监管项目的人懂得技术,清楚项目的需要,并能真正参与到团队中。

2. 建立起经理和员工之间的相互尊重

由于大部分经理有着很强的工程背景,产品经理与程序员之间没有很多公司中存在的彼此看对方不顺眼的情况,而且二者之间存在着许多相互尊重,这对于苹果小而紧密的项目团队来说至关重要,也是苹果成功拼图上的关键一块。

3. 给予员工自由,让他们改进产品

在苹果,如果员工使用产品当中发现一个困扰他们的问题,他们有权直接动手修复它,而无需官僚的打报告等待批准。
在苹果,所有的项目都是由长期目标驱动,但最好的东西往往来自于工程师们的自发奉献。

4. 激励你的员工成长

经理们往往会给下属略超出他们的能力、具有挑战性的任务,但员工往往能从中获益匪浅。在挖掘员工潜力、激励员工成长方面,苹果做得相当到位,能给予他们所需要的技能,与公司一起成长。

5. 最后期限至关重要

在苹果对最后期限的要求非常严格,而他们总是能在最后期限前完成任务。Agarwal称,“至于质量方面,我在苹果学到的东西是,我们不能将没有达到‘苹果水准’的东西推向市场,这意味着我们有时候要砍掉一些在最后期限前无法完成的东西,坚持最后期限,并逐步改善。”

这或许就是苹果的妥协文化的根源。

6. 不要和你的竞争对手搞扩军备战

苹果从不会和竞争对手搞扩军备战,他们更多地专注于自身产品的目标,而不是拿自己和竞争对手相比。苹果从未试图在同一水平上超越他们,而是在更高的水平上做自己的事情。这一使命已经深植于苹果的企业文化中,所以苹果的员工不会专注于竞争对手在做什么,而是以创新为导向,拿出产品,挑战现状。

7. 雇佣那些痴迷于你的产品的人

苹果员工首先是苹果的粉丝,这让他们的工作更加具有积极主动。

是否对公司、产品具有热情,是否对整体风格和使命认同,这是苹果招聘过程中考虑的重要因素。苹果员工通常会热爱自己的产品,并会为之不断努力。

8. 在工作和生活中平衡

苹果强调工作与生活的平衡。苹果的理念是,你努力工作的目的是为了能够更好地享受自己的生活。因此苹果会为员工提供优良的健康服务,慷慨的圣诞节和感恩节假期和优良的办公环境。苹果的格言是:“努力工作,享受生活。”

总结:哪怕你已经成为一家大公司,也还要保持创业文化

 

苹果的成功之处在于,它是一家巨大的创业公司。

没有官僚主义,以工程师为中心的文化,强调员工的热情与忠诚,这家大公司一直保持了创业初期的公司文化。这也正是苹果为什么取得如此巨大成功的秘诀。

俄科学家抛惊人理论 黑洞里可能存生命

英国《每日邮报》9日报道,俄罗斯宇宙学家维切列夫·道库恰耶夫称,尽管黑洞被认为是太空中最具破坏性的力量,然而它内部的环境条件却适合生命存在,更令人震惊的是,拥有“超级文明”的外星人可能已存在于黑洞里。然而,也有科学家对此提出质疑,称任何事物都无法脱离黑洞巨大的引力,因此无法判断这一理论是否正确。

黑洞可能存在生命 时空在此稳定

尽管超大质量黑洞被认为是太空中最具破坏性的存在,完全不适宜生命居住,但生命体仍有可能存在于超大质量黑洞之中。道库恰耶夫表示,如果真有生命存活于超大质量黑洞中,它们将进化成为星系中最先进的文明。

道库恰耶夫提出了某些黑洞类型的可能性。他说,在一个带电旋转的黑洞内部,某些区域的光子能在稳定的周期轨道上存活。也就是说,尽管黑洞破坏性无比强大,但是它的内部环境却适合生命存在。

他近期在康奈尔大学在线期刊上发表了一份研究报告,报告指出,如果黑洞中存在适合光子的稳定轨道,那么将有可能存在行星的稳定运行轨道。但这种稳定的轨道仅存在于跨越黑洞表面的临界点,进入黑洞表面则出现时间和空间的逆转。

超越黑洞表面还有另外一个领域,叫做“柯西表面”,在这里时间和空间处于稳定状态。在“柯西表面”可能存在生命体,但它们的进化和生存状况与人类完全不一样,它们能够承受巨大的潮汐引力波动。

文明程度远胜人类 外界无法观测

道库恰耶夫分析说,超大质量黑洞非常强大的引力足以吸收周围一切物质,包括光,所有经过黑洞“视界”的物质都不再存在。

道库恰耶夫认为,黑洞中很有可能存在外星生命,它们的文明程度已经远胜人类,属于三级卡尔达肖夫指数的智慧文明,从黑洞外部根本无法观测到。

然而,也有科学家指出,虽然道库恰耶夫提出的是一个令人兴奋的观点,但该观点目前仅停留在理论阶段。由于超大质量黑洞具有巨大的引力,任何事物都无法脱离黑洞,无法判断这一观点是否正确。

●多知道点儿

卡尔达肖夫指数:它共有三个等级,一级卡尔达肖夫指数文明是指可以控制利用一个星球;二级是指可以控制利用一个恒星;三级是指可以控制利用一个星系。

雅虎收购twitter的可能性

最近yahoo的CEO被炒,又引起了大家对yahoo这家公司的关注,看到其中一些为 yahoo出点子的文章,有一篇提到建议yahoo收购twitter,我觉得这个建议的可能性非常小。

yahoo目前股票14美元,市值不到180亿美金,Q2的财报是营收12.29亿,净利2.37亿;twitter市场估价在60~80亿美金,由于twitter还没有上市,所以得不到它的真正营收与赢利情况,估计twitter今年全年的营收是1~2亿之间,收支应该趋于平衡,如果好的话能有微弱赢利。假如yahoo收购twitter这个命题成立,他只有两种方式:

1,付出60~80亿的现金,全现金交易

这只会导致yahoo在收购当年全年的营收变成负值,这将来几年利润会狂跌,股票得跌好一阵子,yahoo的董事会首先就不会答应,而且yahoo手头也没有这么多现金可以支出,他还得维护日常的正常运作。再看twitter,他的目前还没有清晰的赢利模式,只要看看新浪微博目前的情况就知道,靠网络广告肯定是不行了,网络广告总市场就这么大,微博能真正从google和门户中分得多少?还是得有新的印钞机模式出现才能支撑这么大的公司运营。

2,用股票+现金的方式收购twitter

给多少现金合适?给10亿?一年的利润没了,剩下的给股票,那twitter的那几个人岂不是成了yahoo的大股东了,yahoo的董事会得乱了。

说到底,很多事情是资本因素在起作用,上市公司就是有这样的束缚,如果收购方的市值没有达到被收购方的10倍,最好勿谈收购。

yahoo是我曾经很喜欢的一个公司,上网的记忆就是从yahoo开始的,yahoo唯一错的,就是中国雅虎的政策,否则,整个yahoo不至于这么惨,惨到连中国的一口蛋糕都没吃上。

”Twitter搜索现在快3倍啦“

在2010年春季,为了服务不断增长的流量、提升最终用户的响应时延和服务的可用性、有能力快速开发新的搜索功能,搜索团队开始重写我们的搜索引擎。作为不努力的一部分,我们发布了新的实时搜索引擎,将后端从Mysql迁到了lucene的实时版。上周我们发布新的前端,替换了Ruby on Rails版:我们称之为Blender的Java服务器。我们很高兴地宣布这些改变使我们的搜索时延下降了3倍,同时也使得我们有能力在接下来的几个月里快速迭搜索特性。

性能收益

Twitter搜索是世界上注量最重的搜索引擎之一,每天服务超过10亿的查询。在我们发布Blender的前一周,日本 #tsunami 产生了很大的查询负载,并产生了查询响应时间的峰值。随着Blender的发布,我们的95%时延减少了3倍,从800毫秒到250毫秒,同时前端的CPU负载降低了一半。我们每台机器的容量能服务10倍的请求增长。这也意味着我们能能够用更少的机器支持同样的请求数,从而降低前端服务的成本。

Twitter搜索现在快3倍啦

blender发布前后的95%的查询接口时延对比图

Twitter改进后的搜索架构

为了弄明白这些性能收益,你首先必须明白我们以前的RoR前端是如何地低效。前端运行固定数量的单线程工作进程,每一个做下面的事情:

. 解析请求
. 同步查询索引服务
. 聚合并展现结果

我们很早就知道,同步方式处理请求会低效地使用我们的CPU。经过一段时间,在Ruby的代码层累积欠了重大的技术债,这样很难增加新特性和改进我们搜索系统的可靠性。

Blender通过下面的方式解决了这些问题:

 创建了一个完全异步的聚合服务。没有线程会去等待网络IO完成
. 从后端服务中聚合结果,例如,实时的,最流行的微推和地理分片
. 优雅的服务之间的依赖关系处理,工作流自动处理后端服务之间的传递性依赖

下图显示了Twitter的搜索引擎架构。从网站、接口或内部客户过来的查询请求通过硬件负载均衡设备转发到Blender上。Blender解析请求,然页转发给后端服务,使用工作流来处理服务之间的依赖。最后,将后端服务返回的结果进行合并,以合适的语言呈现给客户。

Twitter搜索现在快3倍啦
Twitter跟Blender有关的搜索架构图

Blender简介

Blender基于Netty http://www.jboss.org/netty打造的Thrift和HTTP服务,Netty是用Java写的高扩展的客户和服务器库,基于它能快速地开发各种协议的客户和服务器端程序。我们没有用其它产品,如Mina和Jetty,主要是因为在其它项目中已经用过它,当然它的接口更简洁、文档也写得不错,这也是我们用它的原因之一。为了让Netty跟Trift一起工作,我们写了解析Thift的代码,专门解析从Netty的channel缓存中的过来的Thift请求,当它从socket读请求或需要封装Thrift响应时,都会调用它些代码。

Netty定义名叫通道的抽象功能,用来封装到网络套接字的连接,提供读、写和连接等IO请求的接口。所有通道的IO请求天然都是异步的。这意味着任何IO调用立即返回一个通道实例对象,以通知请求是否完成、失败或被取消。

当Netty服务器收到一个新的连接,它会创建一个通道流水线来处理这个连接。一个通道流水线不是别的,其实就是通道处理程序的序列,通过它实现处理连接的业务逻辑。在随后的一个小节里,我们会说一下Blender是如何将这些通道流水线映射到查询的工作流处理上的。

工作流框架

对于Blender来说,一个工作流就是一组后端服务,服务之间有依赖关系,每个后端服务都需要处理才能处理收到的查询请求。Blender自动解决后端服务之间的依赖,例如,如果服务A依赖于服务B,首先会请求A,把它返回的结果返回给B。工作流可以很方便地用有向无环图来表示(见下图)

Twitter搜索现在快3倍啦
6个后端服务的Blender工作流示例图

在上面的示例图中,我们有6个服务{s1,s2,s3,s4,s5,s6},之间有依赖。从S3到S1的边意味着先要访问S3,之后才是S1,因为访问S1时需要访问S3后的结果。对于这样的一个工作流,Blender框架先会进行拓扑排序以确实所有服务的顺序,它们也必須以这样的顺序依次调用。上图的服务执行顺序将是{(s3,s4),(s1,s5,s6),(s2)}。这也表明s3和s3可以在第一轮里并发调用,一旦它们返回结果,S1、S5和S6可以在第二轮里并发调用,最后才调用S2。

一旦Blender确定了工作流的执行顺序,工作流将会映射成Netty的流水线。流水线是一个处理程序序列,请求依次会通过这些处理程序。

复用进来的请求

因为工作流映射成了Netty的管道,我们需要将进来的客户端请求转发给合适的流水线。因为这个原因,我们设置了一个代理层,它负现复用并转发客户端请求到流水线上:

. 当一个远程Thrift客户端跟Blender建立一个长连接时,代理层会创建一组本地的客户,跟每个本地的工作流服务对应。注意当Blender进程起动时,会在同一个java虚拟机里起动所有的本地工作流服务
. 当从套接字上收到一个请求时,代理层读取这个请求,计算出需要请求那个工作流服务,然后转发给对应的工作流服务
. 类似地,当收到本地的工作流服务的响应时,代理层读取结果,并把结果转发给远程的客户

我们利用Netty的事件驱动模型来异步完成上面的所有任务,这样也没有任何线程需要等待IO。

分配后端请求

一旦请求转到了工作流流水线,将依次由工作流定义好的服务处理程序处理。每个服务处理程序创建一个合适的后端请求,转发给远程的服务器。例如,实时处理程序会创建一个实时搜索请求并异步地将它发给一个或多个实时索引服务器。我们使用twitter commons库https://github.com/twitter/commons(最近开源了!)来提供连接池管理、负载均衡和死主机检测。

当请求分配给所有后端之后,请求对应的IO线程就将被释放。一个定时线程每隔几毫秒就检查有没有后端的请求返回,并设置对应的标记,表明请求成功、超时或者失败了。在一个查询请求的存在周期内我们为它维持一个对象,用来记录上面这些状态信息。

成功的响应会聚合在一起,再发给工作流中的下一批处理程序。当第一批所有请求的响应的返回之后,将异步地发出第二批请求。这个过程会一直重复直到我们完成工作流或者超出工作流设置的超时时间。

你能够看出,在工作流执行期间内,没有任何线程会去等待IO。这让我们有效地利用Blender机器的CPU,并且处理大量的并发请求。我们能将大量请求并发发给后端去执行,从而也能减少请求的时延。

Blender部署及以后的工作

为了在我们的系统中增加Blender的时候,能确保提供高质量的服务。我们用老的RoR前端作为代理,转发请求给Blender集群。这样使得我们在对后边的技术进行大的调整时,给用户一个一致服务体验。我们下一阶段部署时,会从搜索的服务栈中完全去掉RoR,让用户直接去连接Blender,从而进一步降低访问时延。

原文链接:
Twitter Search is Now 3x Faster

技术型领导

Facebook前工程总监黄易山撰写了一系列文章,很好地总结了Facebook卓越研发文化中的宝贵经验。本文是这一系列文章的第五篇,也是最后一篇。

何谓技术型领导

所有从外部聘用的管理人员包括技术部门负责人,都必须能够编写代码,并且要达到炉火纯青的地步。如果是一家技术公司,CEO也应如此。

现在有个误区就是认为编程不是高管或者经理的必备能力,仿佛只是一种花哨的打字形式。但其他专业化行业都不这样认为:银行业高管必须能够阅读资产负债表;汽车业高管则需要了解催化转换器等。

有人可能会说,技术的精通程度无法检验,因为一个杰出的管理候选人最近几年可能只关注于管理,与技术已无直接的接触。而且,一个杰出的经理可以管理一切事情。显然,这是不真实的。

当然,并不是希望候选人能用当前有限的扩展性技术创建一个大规模系统,或者在芯片集这种底层进行优化,或者能记住特定语言或框架的详细语法。但检验一个经理候选人是否具有较强的个人技术背景是合理并且可取的。当然我指的是基本技能测试,如果候选人曾经是一个称职的技术人员,他肯定能通过编程测试,包含某些简单迭代或递归算法,以及计算机基础学科中指针、散列和操作系统原理等概念题。

即使是一些门槛很低、许多人可能认为任何一个程序员都会的问题,还是有很多程序员搞不定(我并不是说能够做到这一点就意味着是一个优秀的程序员,但做不到这一点则意味着你肯定不是一个优秀的程序员)。在其职业生涯早期,他们发现自己不是优秀的程序员,但又恰好处在一个技术要求没那么严谨的组织中,因此他们能够被提拔,完全是因为他们碰巧很擅长与人打交道(或善于用人)。现在,他们中的许多人已经进入了技术管理和高管候选人的行列。此外,他们通常非常善于谈论一场精彩的比赛,听起来就像他们知道自己在做什么(否则他们也不会到那个位置)。

检验一个候选人是否具备技术实力的唯一方法是:给他们出一些简单的代码题目进行测试或者找一些他们写过的开源代码直接评估检验。不能通过测试或者没有可供验证的公开技术记录的候选人将不会被雇用。

原因是显而易见的——那就是管理者需要纵观大势,以便作出明智的决定。一个有经验但无技术背景的经理可能会有好想法,但在同等情况下,一个有类似技术背景的经理则可能有更突出的表现。换句话说,前者肯定提供不了技术领导力,如果希望你的公司成为行业的技术领导者,你的领导者首先需要具备技术。

为什么需要技术型领导?

一个没有技术型领导的“技术”公司往往会失败,原因可以归咎于以下两者或者其中之一。

领导无法分辨技术人员执行的工作是否符合标准,因为在面临技术挑战时他们无法区分是技术人员执行力太差还是确实遇到了技术瓶颈。进而,也就无法实行绩效管理,这会导致业绩平庸,并将最终导致彻底甚至反复的失败。

业务需求导致领导不顾技术人员的建议或者想法。当今严酷的商业环境要求企业领导推进企业不停地超越旧边界,这意味着领导不仅要告诉他的员工警惕“该死的鱼雷”,还要能够深化拓展,不能仅求安逸。不幸的是,非技术型领导人没有个人能力来衡量首要技术问题的实际风险状况(例如:某些特殊情况下已经非常过时的限制),并往往会推翻那些不应该被推翻的建议。

在Facebook之外,我见证了不止一个由于管理层缺乏核心技术力而导致的大型公司的失败。而在Facebook,个人技术能力恰巧是所有工程管理人员所必需的,甚至包括部门领导及CEO(是的,Mark Zuckerberg还在继续参与Hackathon编程活动)。这使得该公司敢于多次进行技术冒险,以达到更大的产品创新目标并实现一贯快速的前进步伐,正所谓越了解游戏规则,玩得就好。

作者介绍:黄易山,1997年毕业于卡内基-梅隆大学。2001年加入PayPal,曾任高级工程总监。2005-2010年在Facebook领导研发,在公司研发环境的建设上发挥了重要作用。