选择产品经理，这后面其实是个问号。 跨入产品经理（PM）这个行当四五年，看到不少同学美好地一拥而进，一两年后又看到他们的彷徨：看看当初做技 术或咨询的同学要不生活滋润，要不俨然已接近成功人士圈，真是又累又没成就感；PM苦逼啊，说话没人听，自己想搞点东西没技术也玩不转；做了两年，说出去 都学了啥！？

转自：http://qing.weibo.com/2613724775/9bca466733000d90.html

大的软件公司有很多资源，研发能力不错，各种推广资源也非常优越，但很少开发出来优秀的互联网产品。初步看上去，原因很多，比如很难调动个人的积极性、内部管理协调非常困难等。我认为还有一个重要的原因，就是方法不得当。大公司资源多，一个互联网创新项目，投入大量资源后，公司期望值高，考虑的问题自然多了，反而不容易做好。

从大公司离职出来创业，首先要“挥刀自宫”，干掉大公司这套做法，控制成本尽量少花钱，集中精力和资源解决核心的一两个问题就足够了。

不要想太多，不做太长时间的计划，尤其是计划不能太复杂！创业成功需要的是发现机会和快速突破的能力，再加一点运气。大公司的工作经验太多，有时候反而会限制自己的做法。 互联网创业，越简单越单纯，越容易成功！

1.专注：解决用户一个迫切的需求，解决的问题一句话就可以说清楚。

(1) 一个明确而且用户迫切需要的产品，很容易找到明确的用户群。这样，产品研发出来后，不容易走偏。(2) 选择的用户需求要有一定的普遍性，这点决定这个产品的未来市场前景。(3) 解决的问题少，开发速度快，也容易控制初期的研发成本和风险。(4) 解决明确问题的产品，容易给用户说清楚，推广也会相对简单。

2.极致：要在这个功能点上做到所有同类产品的极致，做到最好才能赢。

(1) 极致是互联网产品的核心，只要极致才能超出用户的口碑，形成口口相传的效应，给后期的推广带来了很大的便利。(2) 专注才能做到极致，做到极致才能击败竞争对手。

3.快：开发周期一定要控制在三到六个月的时间，一定要快。

(1) 互联网时代，用户需求变化比较快，而且竞争也比较激烈。快速的开发，容易适应整个市场的节奏，并且节约成本。(2) 用户试用过程中，如果发现问题，反应速度也要快，尽快改善尽快更新。初期，我认为要保持在一两周的更新速度。

4.口碑：初期市场营销坚持少花钱甚至不花钱，才能看出产品对用户真正的吸引力。

(1) 产品完成后，不要着急，先坚持在一个小规模的用户群中试用，听听用户反馈。(2) 大规模的推广会带来如下的两个问题：一、投入大量市场费用后，用户期望值很高，如果产品不完善，很容易引起负面的口碑，为以后的推广留下了隐患。二、大规模市场推广得到的测试效果不准确。如果产品不完善，甚至需求选择有问题，会被数字掩盖。当推广费用停止后，用户量不增长甚至下滑，再改就来不及了。过去几年成功的互联网创业公司，其实在市场营销上花的钱都非常少，但这些公司在市场营销上花的精力并不少。(3) 刚开始最重要的推广技巧是搜索引擎优化和病毒式营销。

互联网创业的葵花宝典就是“专注”、“极致”、“快”和“口碑”！

一次完美的互联网创业，最好是技术、产品高手搭配的两三人创业，三到六个月内完成产品，再用半年到一年的时间测试完善产品，达成初步成功的门槛，再寻求融资，摸索成功的商业模式，然后投入大量的市场资源推广，形成规模化业务。

初步成功的标准，不同的业务要求不同。我有一个简单的标准供大家参考，就是产品推出半年到一年时间，网站页面过一百万PV，或者客户端产品日净增安装量1万次，而且用户数还在持续增长。达成这个目标之后，需要琢磨的事情，就是在保持增长速度的同时，如何探索好的商业模式。

作者：雷军
转自：http://blog.sina.com.cn/s/blog_4b0e23c90100c1ok.html

近年来，中国企业管理者要面对的不仅是以客户为中心的市场竞争的挑战，更需要在技术、成本、质量、服务等具体环节不断增强实力。一份来自Value Research的调研报告指出，企业CIO需要解决IT系统和企业整体发展需要之间的矛盾，并利用IT资源更好地服务于企业业务规划。

该报告同时指出，以往企业IT投资和建设忽略了对企业员工的关注。过去的20多年，中国企业的IT建设主要以满足业务应用需求为主——例如硬件设备的搭建、流程化与结构化数据的处理等。这也直接导致了IT投资没有充分考虑与人的结合，从而不能发挥出最大的效用。

伴随着国内外市场环境的变化，以及各种新技术的迅猛发展，“人”的因素越来越受到关注。一场“以人为本”的信息化建设浪潮正在掀起——让流程和数据为人服务，将企业内部沟通和外部协作紧密结合，充分辅助“人”去完成相应的业务操作并实现业务价值，从而为企业带来最大的投资回报率。

“以流程为本”到“以人为本”

在这样的大背景之下，过去单纯的以“流程+数据”为中心的企业信息化建设，已经很难适应企业对组织架构或业务的调整需求，无法支撑企业完成迫切的转型和变革。只有实现从“以流程为本”到“以人为本”的转变，IT才能够帮助企业有效应对众多复杂多变中的不确定性因素，以及内外部环境带来的新挑战和新需求。

从“以流程为本”到“以人为本”，意味着以往的传统信息流通模式将被打破——从人为数据和流程服务，变化为让数据和流程为人服务，从而创造更好的商业价值——充分发挥“人”的主观能动性，重视其在业务操作和价值实现过程中的关键作用。

因此，企业CIO需要在移动化、云计算、IT消费化的大趋势下，关注员工作为“人”的基本需求，甚至让这种需求享有优先级，并借助IT的手段来充分激发人的潜能，使员工摆脱传统办公方式和管理模式的束缚和制约。

 “下一个10年，ERP+SNS可能会成为企业信息化的一个方向。”金蝶中国公司副总裁郝登胜说。SNS作为Web 2.0时代产物，早已风靡互联网。那么，如果将基于个人应用的SNS融入企业级应用，将Web 2.0思想融入传统的企业管理思想，将会如何？基于Web 2.0技术的网络软件在组织和商业中的使用，便被成为 “企业2.0（Enterprise 2.0）”。

企业2.0最早由麻省理工学院斯隆管理学院数字商务中心首席研究科学家Andrew McAfee（安德鲁·麦卡菲）提出，并定义为公司内自然出现的社会软件平台，或者公司与其合作者及客户之间自然出现的社会软件平台（Emergent Social Software Platform，ESSP），让人们相互交往中固有的模式和结构变得可视化。

Andrew认为，企业2.0的核心思想是：当信息的流通和交换愈加畅通时，企业人与同事、团队、客户及其合作伙伴等的沟通也会愈加高效，从而避免囚徒困境的出现。而当沟通变得更加自由和开放时（在合理范围内），企业人就可以从周围得到更多的反馈，从而实现更多的互动（从而产生协作），同时企业人对问题的反应也会愈加迅速、敏捷，因此做出的判断也会愈加准确。

“在企业2.0的模式里，企业里的每一个人都将发挥更大的影响力。这在人力资源成本不断增长而人才又相对紧缺的商业社会里，是一个非常重要的转型。”金蝶集团互联网产品事业部总经理王天宇认为，“一个成功的社会化管理体制可以帮助企业更加有效地协调资源，快速地分享信息，加强管理的透明度，增强部门之间协同合作，并逐渐改变企业里的官僚文化。”

在互联网从Web 1.0到Web 2.0的转型中，信息流通实现了从“一点到多点”向“多点对多点”的传播方式的转变，打破了传统的传播瓶颈。企业从1.0向2.0的转变与此类似：企业1.0管理模式依赖于传统的资源分配型软件，以 “记录信息” 的模式辅助企业的管理者。而企业2.0则让管理软件逐渐互联网化和碎片化，以企业里人与人之间的关系为主线， 关注企业里的不同部门和不同组织的协同需求， 增加信息分享的速度， 提高企业的综合生产力。

企业1.0到企业2.0的转变，正是“以流程为本”向“以人为本”的转变，“人”的因素被充分重视起来。通过将分散于企业员工大脑中的知识汇聚起来，降低企业内部信息的沟通成本，形成对外的信息优势。“传统ERP的重点是‘数据+流程’，而基于‘人为核心的社交网络’的信息化构建可能是企业信息化很好的补充。”郝登胜说。

企业微博≠微博

在Web 2.0时代，社交网络的普及将人与人之间的沟通无限拉近，使得信息更加透明化、信息沟通更加便捷化。在企业2.0时代，企业Wiki、Blog、企业Tagging、企业微博等典型的企业2.0工具，通过“多点对多点”的信息流通模式，将组织中的每个人充分调动，运用群体的力量和智慧应对业务挑战。

企业微博是一种基于企业级应用的信息分享、传播、交流平台，当前具有两种存在形式。一种例如新浪微博中的企业微博，其实质是企业专属的品牌页面，主要用于与合作伙伴、供应商、客户等进行“弱关系”的沟通和交流，能够一定程度上帮助企业实现扩大知名度、提升企业形象、产品品牌推广、上下游业务扩展等目标。

另一种为Yammer和金蝶微博类的企业微博，其实质是企业内部沟通交流的SNS平台，主要用于企业内部同事间进行“强关系”的沟通和交流，能够帮助企业实现团队协作、管理透明化、知识管理、创意搜集等目标。

这种企业微博的属性特征表现为：基于工作性质的商务属性，主要用于企业内部沟通交流，所谈论的内容多与工作相关，不同于新浪微博的媒体属性、腾讯微博的娱乐属性，商务属性有利于公司管理的扁平化和沟通的透明化；基于工作内容的协作属性，主要用于企业内部团队了解彼此工作状况、进行工作协同，注重互动，而公共平台微博更注重分享，协作属性能够降低人际沟通成本、提升人员工作效率，能够聚合集体智慧，降低创新成本、加快创新速度；基于工作范围的私密属性，企业微博只允许企业内部员工实名制访问，为企业用户提供了专属的私密空间，不同于公共平台微博的开放性和公开性，能够帮助企业保护敏感信息，加大沟通的安全感。当然，目前Yammer和金蝶微博虽然允许企业用户建立外部沟通社区，但也需实名邀请。

争做企业级twitter

企业微博的社交属性，可以帮助企业内部实现从“人机互动”到“人人互动”的转变。而在该领域，Yammer和金蝶微博值得关注。

Yammer成立于2008年9月，在国外企业微博领域具有“企业级twitter”之称，能够为企业提供社会化的网络服务。据Yammer CEO David Sacks透露，截至2011年底，公司的企业用户数为400万，该数字在2010年底为160万，其目标是在2012年底达到800万到1000万企业用户。

在国内市场上，2012年1月9日，金蝶正式推出“金蝶微博”平台。金蝶微博定义为“私密的企业社交平台”，承诺永久免费，致力于在企业社会化网络的深刻商业变革中为企业提供信息交互的竞争优势，使需要协作的员工更方便、有效的进行交流与分享，降低企业沟通成本，提高工作效率，凝聚专业知识工作者和远程同事。

在此前两个月的公测中，已有超过5000家的企业用户使用，并呈直线上升趋势。来自Alexa的监控数据显示，金蝶微博目前的日均PV值和IP值均超过其他国内企业微博产品的总和。“中国的企业需求已不仅仅停留在软件层面，它们更多的是要求一种全面的整合服务。未来金蝶微博将全面融入ERP产品解决方案，并携手合作伙伴共同转型。”金蝶集团董事局主席徐少春表示，金蝶微博是金蝶集团向互联网转型的重要步骤与载体。

RT公司每天下班的时候都会接到ZWZX负责人的电话，询问一天的工作情况，然后布置任务要求晚上加班做完，RT公司的员工很无奈也很气愤因为每天 都要加班，员工们就问项目经理：“为什么天天加班赶需求，今天才提一个需求，明天就要上线，还让不让人活了?” 项目经理无奈的说：“我有什么办法啊？这是人家ZWZX负责人说的啊，对方逼得紧。”

多次以后项目经理也忍不住了，就问ZWZX的负责人怎么天天这样啊，ZWZX的负责人就说了:”明天就要向YD的负责人展示这个页面，我也没有办法啊？YD那边老总就是这么要求的，我怎么办，我也不想这样啊？”

然后RT的项目经理实在受不了了就辞职了，新上任的项目经理又会走他的老路，因为从开始我们就被培养“满足客户的需求是最重要的”。RT的员工也就这样一直抱怨着，一直忍受着。天天在心里咒骂YD的老总真是没有人性，不拿人当人看啊！

人换了一批又一批，加班也就慢慢的变成了应该的，你不加班说明你不敬业，不合格。

故事二：
IE6一直存活着，所有的前端开发人员都痛恨它，都不想兼容它，可是产品经理看到IE6的市场占有率还是这么高，就会要求前端开发人员必须兼容IE6。

矛盾又来了，就像故事一一样，前端开发人员天天抱怨，产品经理也天天抱怨，但是面对IE6的市场份额，产品经理会劝开发人员说：“我有什么办法 啊？IE6的市场份额就是这么高，不兼容怎么办啊？我也不想啊！” 开发人员也就这样忍受着，然后不断地抱怨用IE6的用户低端，没文化，怎么还用IE6啊！天天兼容IE6就够烦的了，还怎么创新啊！

这两个故事里出现的问题到底是谁的错误引起的？ 

故事一的罪魁祸首是YD的老总吗？

故事二的罪魁祸首是那些还用着IE6的用户吗？

从这两个嫌疑最大的罪魁祸首眼中看一下这两个故事：

故事一：
我是YD的老总，我要建立一个网站，找到了ZWZX公司，签订了合同，我提需求他们实现。

我不懂制作网站，可是我才思敏捷，创意无限，不停的会有好点子从我的脑海里蹦出来，每当有一个好点子蹦出来后，我都会给ZWZX公司的负责人讲清楚 我的想法，让他实现，开始我不知道做一个页面需要多长时间。第一次我试探性的说了一周必须把我这个点子做出来，ZWZX公司负责人很痛快的答应了，一周后 我果然看到了这个功能。

可是会不会我给他们的时间太长了？对！肯定是，要不也不会答应的这么痛快。这些人啊！天天就是想拖时间，好多骗我点钱。

点子又来了，这次我要求5天做出来，这个点子和上个点子类似，我倒要看看5天能不能做出来~  ZWZX公司负责人一副痛苦的表情，我会不会逼的太紧了，5天是不是真的做不出来？到时候看看吧，如果5天没做出来估计是我给的时间太少了。

5天过去了ZWZX公司的负责人很高兴的拿出了我要的功能实现，哎，看来开始真的骗了我两天。就是不知道5天会不会还是多了啊？下次给3天~

又拿出来了，虽然他装的好像时间太紧似的，可别以为我不知道，你第一个功能最多3天就做出来了，我还给了你7天的项目经费，你们多赚了我多少啊！！！！ 真是没良心。 下次1天！！！

啊啊啊啊啊啊啊啊!!! 1天就出来了，这些人。。。。。  有没有良心，原来做这个这么简单，以后就给1天，不 ！ 一天N个功能。

故事二：
我买了个电脑，没什么别的用途，就是打开电脑上上网，上上QQ和儿子聊聊天，QQ是儿子给我装上的，这样我就可以和他视频了。有一次QQ提醒我说我的QQ 版本太低了，不能视频了，我打电话问儿子，儿子说按提示升级一下QQ就行了，呵呵，我按QQ的提示，儿子的指示一步一步的升级QQ成功了，看来电脑也不难 啊！

到这里您认为开始的两个故事的罪魁祸首是谁啊？

我们一直以加班，甚至通宵去满足客户不合理的要求，只因为他是客户。只因为人人都认为满足客户的要求是我们最大的
价值，可是不合理的要求不能去拒绝吗？套用刘欢说的一句话“我们是不是活的应该有些尊严”，一味的迎合客户，只会让我们自己越来越痛苦，反而得不到用户的尊重，肯定。

我一直有个疑惑，很多人说网站不支持IE6，而选择让用户去升级IE，这样的用户体验不好！如果按照按照这个逻辑，是不是我们都应该是Web应用， 而且都应该是IE6下的Web应用呢？为什么微软还要出WIN8，一直XP不是挺好的吗？让用户升级系统，用户体验多么不好啊？QQ，360，搜狗输入 法，等等客户端软件用户体验不都不好吗？ 都还要用户下载。

实在搞不懂为什么我们做个东西非要去支持IE6呢？检测到用户是IE6，给个提示，给个升级链接不就行了？ 这样做用户体验是有多么不好吗？ 你天天去支持IE6，还要天天磨叽用户使用IE6，你不觉的很矛盾吗？再说我一个普通用户，你如果不提醒，我怎么知道要升级IE6啊？

对于遭遇了故事一，故事二的人只能送上一句话“哀其不幸，怒其不争！”

原文链接：http://hfcc8685.github.com/blog/2012/04/19/shui-zhi-cuo/

问题

某海量用户网站，用户拥有积分，积分可能会在使用过程中随时更新。现在要为该网站设计一种算法，在每次用户登录时显示其当前积分排名。用户最大规模为2亿；积分为非负整数，且小于100万。

PS: 据说这是迅雷的一道面试题，不过问题本身具有很强的真实性，所以本文打算按照真实场景来考虑，而不局限于面试题的理想环境。

存储结构

首先，我们用一张用户积分表user_score来保存用户的积分信息。

表结构：

示例数据：

下面的算法会基于这个基本的表结构来进行。

算法1：简单SQL查询

首先，我们很容易想到用一条简单的SQL语句查询出积分大于该用户积分的用户数量：

select 1 + count(t2.uid) as rank from user_score t1, user_score t2 where t1.uid = @uid and t2.score > t1.score 

对于4号用户我们可以得到下面的结果：

算法特点

优点：简单，利用了SQL的功能，不需要复杂的查询逻辑，也不引入额外的存储结构，对小规模或性能要求不高的应用不失为一种良好的解决方案。

缺点：需要对user_score表进行全表扫描，还需要考虑到查询的同时若有积分更新会对表造成锁定，在海量数据规模和高并发的应用中，性能是无法接受的。

算法2：均匀分区设计

在许多应用中缓存是解决性能问题的重要途径，我们自然会想能不能把用户排名用Memcached缓存下来呢？不过再一想发现缓存似乎帮不上什么忙， 因为用户排名是一个全局性的统计性指标，而并非用户的私有属性，其他用户的积分变化可能会马上影响到本用户的排名。然而，真实的应用中积分的变化其实也是 有一定规律的，通常一个用户的积分不会突然暴增暴减，一般用户总是要在低分区混迹很长一段时间才会慢慢升入高分区，也就是说用户积分的分布总体说来是有区 段的，我们进一步注意到高分区用户积分的细微变化其实对低分段用户的排名影响不大。于是，我们可以想到按积分区段进行统计的方法，引入一张分区积分表 score_range：

表结构：

数据示例：

表示[from_score, to_score)区间有count个用户。若我们按每1000分划分一个区间则有[0, 1000), [1000, 2000), …, [999000, 1000000)这1000个区间，以后对用户积分的更新要相应地更新score_range表的区间值。在分区积分表的辅助下查询积分为s的用户的排 名，可以首先确定其所属区间，把高于s的积分区间的count值累加，然后再查询出该用户在本区间内的排名，二者相加即可获得用户的排名。

乍一看，这个方法貌似通过区间聚合减少了查询计算量，实则不然。最大的问题在于如何查询用户在本区间内的排名呢？如果是在算法1中的SQL中加上积分条件：

select 1 + count(t2.uid) as rank from user_score t1, user_score t2 where t1.uid = @uid and t2.score > t1.score and t2.score < @to_score 

在理想情况下，由于把t2.score的范围限制在了1000以内，如果对score字段建立索引，我们期望本条SQL语句将通过索引大大减少扫描 的user_score表的行数。不过真实情况并非如此，t2.score的范围在1000以内并不意味着该区间内的用户数也是1000，因为这里有积分 相同的情况存在！二八定律告诉我们，前20%的低分区往往集中了80%的用户，这就是说对于大量低分区用户进行区间内排名查询的性能远不及对少数的高分区 用户，所以在一般情况下这种分区方法不会带来实质性的性能提升。

算法特点

优点：注意到了积分区间的存在，并通过预先聚合消除查询的全表扫描。

缺点：积分非均匀分布的特点使得性能提升并不理想。

算法3：树形分区设计

均匀分区查询算法的失败是由于积分分布的非均匀性，那么我们自然就会想，能不能按二八定律，把score_range表设计为非均匀区间呢？比如， 把低分区划密集一点，10分一个区间，然后逐渐变成100分，1000分，10000分 … 当然，这不失为一种方法，不过这种分法有一定的随意性，不容易把握好，而且整个系统的积分分布会随着使用而逐渐发生变化，最初的较好的分区方法可能会变得 不适应未来的情况了。我们希望找到一种分区方法，既可以适应积分非均匀性，又可以适应系统积分分布的变化，这就是树形分区。

我们可以把[0, 1,000,000)作为一级区间；再把一级区间分为两个2级区间[0, 500,000), [500,000, 1,000,000)，然后把二级区间二分为4个3级区间[0, 250,000), [250,000, 500,000), [500,000, 750,000), [750,000, 1,000,000)，依此类推，最终我们会得到1,000,000个21级区间[0,1), [1,2) … [999,999, 1,000,000)。这实际上是把区间组织成了一种平衡二叉树结构，根结点代表一级区间，每个非叶子结点有两个子结点，左子结点代表低分区间，右子结点 代表高分区间。树形分区结构需要在更新时保持一种不变量(Invariant)：非叶子结点的count值总是等于其左右子结点的count值之和。

以后，每次用户积分有变化所需要更新的区间数量和积分变化量有关系，积分变化越小更新的区间层次越低。总体上，每次所需要更新的区间数量是用户积分 变量的log(n)级别的，也就是说如果用户积分一次变化在百万级，更新区间的数量在二十这个级别。在这种树形分区积分表的辅助下查询积分为s的用户排 名，实际上是一个在区间树上由上至下、由粗到细一步步明确s所在位置的过程。比如，对于积分499,000，我们用一个初值为0的排名变量来做累加；首 先，它属于1级区间的左子树[0, 500,000)，那么该用户排名应该在右子树[500,000, 1,000,000)的用户数count之后，我们把该count值累加到该用户排名变量，进入下一级区间；其次，它属于3级区间的[250,000, 500,000)，这是2级区间的右子树，所以不用累加count到排名变量，直接进入下一级区间；再次，它属于4级区间的…；直到最后我们把用户积分精 确定位在21级区间[499,000, 499,001)，整个累加过程完成，得出排名！

虽然，本算法的更新和查询都涉及到若干个操作，但如果我们为区间的from_score和to_score建立索引，这些操作都是基于键的查询和更 新，不会产生表扫描，因此效率更高。另外，本算法并不依赖于关系数据模型和SQL运算，可以轻易地改造为NoSQL等其他存储方式，而基于键的操作也很容 易引入缓存机制进一步优化性能。进一步，我们可以估算一下树形区间的数目大约为200,000,000，考虑每个结点的大小，整个结构只占用几十M空间。 所以，我们完全可以在内存建立区间树结构，并通过user_score表在O(n)的时间内初始化区间树，然后排名的查询和更新操作都可以在内存进行。一 般来讲，同样的算法，从数据库到内存算法的性能提升常常可以达到10^5以上；因此，本算法可以达到非常高的性能。

算法特点

优点：结构稳定，不受积分分布影响；每次查询或更新的复杂度为积分最大值的O(log(n))级别，且与用户规模无关，可以应对海量规模；不依赖于SQL，容易改造为NoSQL或内存数据结构。

缺点：算法相对更复杂。

算法4：积分排名数组

算法3虽然性能较高，达到了积分变化的O(log(n))的复杂度，但是实现上比较复杂。另外，O(log(n))的复杂度只在n特别大的时候才显出它的优势，而实际应用中积分的变化情况往往不会太大，这时和O(n)的算法相比往往没有明显的优势，甚至可能更慢。

考虑到这一情况，仔细观察一下积分变化对排名的具体影响，可以发现某用户的积分从s变为s+n，积分小于s或者大于等于s+n的其他用户排名实际上 并不会受到影响，只有积分在[s,s+n)区间内的用户排名会下降1位。我们可以用于一个大小为100,000,000的数组表示积分和排名的对应关系， 其中rank[s]表示积分s所对应的排名。初始化时，rank数组可以由user_score表在O(n)的复杂度内计算而来。用户排名的查询和更新基 于这个数组来进行。查询积分s所对应的排名直接返回rank[s]即可，复杂度为O(1)；当用户积分从s变为s+n，只需要把rank[s]到 rank[s+n-1]这n个元素的值增加1即可，复杂度为O(n)。

算法特点

优点：积分排名数组比区间树更简单，易于实现；排名查询复杂度为O(1)；排名更新复杂度O(n)，在积分变化不大的情况下非常高效。

缺点：当n比较大时，需要更新大量元素，效率不如算法3。

总结

上面介绍了用户积分排名的几种算法，算法1简单易于理解和实现，适用于小规模和低并发应用；算法3引入了更复杂的树形分区结构，但是 O(log(n))的复杂度性能优越，可以应用于海量规模和高并发；算法4采用简单的排名数组，易于实现，在积分变化不大的情况下性能不亚于算法3。本问 题是一个开放性的问题，相信一定还有其他优秀的算法和解决方案，欢迎探讨！

更多信息请查看原文：http://www.cnblogs.com/weidagang2046/archive/2012/03/01/massive-user-ranking.html

This is the first in our series of articles about WebGL. The objective of this series is to provide the information and resources you'll need to get started learning WebGL. In this piece, we will discuss how WebGL works, what you need to create WebGL applications, and what a simple example looks like.

What is WebGL?

WebGL is a JavaScript API that allows us to implement interactive 3D graphics, straight in the browser. For an example of what WebGL can do, take a look at this WebGL demo video (viewable in all browsers!)

WebGL is a web standard developed by the Khronos group; Opera is an active participating member along with Google (Chrome), Mozilla (Firefox), Apple (Safari), and other 3D graphics developers.

WebGL runs as a specific context for the HTML <canvas> element, which gives you access to hardware-accelerated 3D rendering in JavaScript. Because it runs in the <canvas> element, WebGL also has full integration with all DOM interfaces. The API is based on OpenGL ES 2.0, which means that it is possible to run WebGL on many different devices, such as desktop computers, mobile phones and TVs. You can view the WebGL specification at the Khronos site.

How do I run WebGL?

To access WebGL content you need to have a browser that supports it.

• Opera 12.00
• Chrome 9 or higher, on Linux, Mac and Windows
• Firefox 4 and higher
• Safari 5.1 or higher on Leopard, Snow Leopard, or Lion (make sure you enable WebGL in Safari — go to Preferences > Advanced and check "Show develop menu in menu bar", then go to Develop > Enable WebGL)

Also, having a good graphics card will likely improve WebGL performance on your computer. If you don't already have it, get the latest Opera release and check out the above video example running as a live demo. Another great demo to check out is Hello Racer.

What is WebGL used for?

WebGL allows developers to put real-time interactive 3D graphics in the browser. WebGL can be applied to interactive music videos, games, data visualization, art, 3D design environments, 3D modeling of space, 3D modeling of objects, plotting mathematical functions, or creating physical simulations.

Interactive music videos

Games

Data visualization

Art

3D design environments

3D modeling of space

3D modeling of objects and textures

Plotting mathematical functions

Creating physical simulations

How does WebGL work?

WebGL is slightly more complicated than your typical web technologies because it's designed to work directly with your graphics card. As a consequence, it's pretty low level. This is what allows it to rapidly do complex 3D rendering involving lots of calculations.

You don't need to fully understand the inner workings of WebGL. There are several WebGL libraries available to take some of the complexity out of your hands. However, gaining an understanding of it can be useful in case you want to spice up your code with features that are not in your library of choice, or you feel that having a better grasp of the technology will help you find your way around what the libraries have to offer.

When programming in WebGL, you are usually aiming to render a scene of some kind. This usually includes multiple subsequent draw jobs or "calls", each of which is carried out in the GPU though a process called the rendering pipeline.

In WebGL, like in most real-time 3D graphics, the triangle is the basic element with which models are drawn. Therefore, the process of drawing in WebGL involves using JavaScript to generate the information that specifies where and how these triangles will be created, and how they will look (colour, shades, textures, etc). This information is then fed to the GPU, which processes it, and returns a view of the scene. Next we will look in more detail at how this last bit happens.

The rendering pipeline

Note that this section is adapted from Joe Groff's explanation of the graphics pipeline in OpenGL.

The process starts with the creation of the vertex arrays. These are arrays that contain vertex attributes like the location of the vertex in the 3D space and information about the vertex' texture, colour or how it will be affected by lighting (vertex normal). These arrays and the information they contain are created in JavaScript in one or more of these ways: processing files that describe a 3D model (for example .obj files), procedurally creating the data from scratch, or using a library that provides vertex arrays for geometrical shapes.

Then the data in the vertex arrays is sent to the GPU by feeding it into a set of one or more vertex buffers. When a rendering job is submitted, we also have to supply an additional array of indices that point to the vertex array elements. They control how the vertices get assembled into triangles later on.

The GPU begins by reading each selected vertex out of the vertex buffer and running it through the vertex shader. The vertex shader is a program that takes a set of vertex attributes as inputs and outputs a new set of attributes. At a minimum, the vertex shader calculates the projected position of the vertex in screen space. But it can also generate other attributes such as colour or texture coordinates for each vertex. You can code your own vertex shader or use one provided by a WebGL library.

The GPU then connects the projected vertices to form triangles. It does this by taking the vertices in the order specified by the indices array and grouping them into sets of three.

The rasterizer takes each triangle, clips it, discards parts that are outside of the screen, and breaks the remaining visible parts into pixel-sized fragments. The vertex shader's outputs for other vertex attributes are also interpolated across the rasterized surface of each triangle, assigning a smooth gradient of values to each fragment. For example, if the vertex shader assigns a colour value to each vertex, the rasterizer will blend those colours into an appropriate colour gradient across the pixelated surface.

The generated pixel-sized fragments then pass through another program called the fragment shader. The fragment shader outputs colour and depth values for each pixel, which then get drawn into the framebuffer. Common fragment shader operations include texture mapping and lighting. Since the fragment shader runs independently for every pixel drawn, it can perform the most sophisticated special effects; however, it is also the most performance-sensitive part of the graphics pipeline. As with the vertex shader, you can code your own fragment shader or use one provided by a WebGL library.

The framebuffer is the final destination for the rendering job's output. A framebuffer is more than a single 2D image: in addition to one or more colour buffers, a framebuffer can have a depth buffer and/or stencil buffer, both of which optionally filter fragments before they are drawn to the framebuffer. Depth testing discards fragments from objects that are behind the ones already drawn, and stencil testing uses shapes drawn into the stencil buffer to constrain the drawable part of the framebuffer, "stencilling" the rendering job. Fragments that survive these two filters have their colour value alpha blended with the colour value they're overwriting. Final colour, depth, and stencil values are drawn into the corresponding buffers. The buffers' outputs can also be used as texture inputs to other rendering jobs.

How do I get started using WebGL?

The first thing you have to do is get a browser that supports WebGL. You can code WebGL using your favourite JavaScript development environment.

For your first WebGL project, I'd suggest using a WebGL library. If you have read the previous section you can probably imagine why directly using the WebGL API can be a bit exhausting. Unlike other web APIs, "naked" WebGL can be pretty low level. The people who designed WebGL decided to make it that way to keep it flexible and applicable to any use case, with the idea that libraries would later add a layer of convenience to accelerate and simplify development.

Most libraries provide a selection of ready-made models, vertex shaders and fragment shaders that can drastically decrease the amount of code you need to write. If you are still not convinced, have a look at the code for an example 3D model of the Moon — with a library and without a library. Even if you just take a quick look, the difference in length and complexity of code is apparent and makes a good case for using a library.

There are many WebGL libraries. What most do is build on top of WebGL to create elements intuitive to a 3D environment like a scene, a camera, a light source, ambient light, ready-made shapes, materials, textures, and effects such as fog, and floating particles. The idea of these elements remains pretty much the same across libraries. How they are used, however, depends on the library's architecture. Because WebGL can be interactive, most libraries provide easy ways to handle events as well. Finally, most libraries also provide some vertex and fragment shaders. When you do your own library exploration you'll see that this is by no means an exhaustive description of what libraries have to offer, but it gives you a good idea to start with.

Choose a WebGL library!

(Not a comprehensive list)

Three.js (Three Github repo)

Three.js is a lightweight 3D engine with a very low level of complexity — in a good way. The engine can render using <canvas>, <svg> and WebGL. This is some info on how to get started, which has a nice description of the elements in a scene. And here is the Three.js API documentation. Three.js is also the most popular WebGL library in terms of number of users, so you can count on an enthusiastic community (#three.js on irc.freenode.net) to help you out if you get stuck with something.

PhiloGL (PhiloGL Github repo)

PhiloGL is built with a focus on JavaScript good practices and idioms. Its modules cover a number of categories from program and shader management to XHR, JSONP, effects, web workers and much more. There is an extensive set of PhiloGL lessons that you can go through to get started. And the PhiloGL documentation is pretty thorough too.

GLGE (GLGE Github repo)

GLGE has some more complex features, like skeletal animation and animated materials. You can find a list of GLGE features on their project website. And here is a link to the GLGE API documentation.

J3D (J3D Github repo)

J3D allows you not only to create your own scenes but also to export scenes from Unity to WebGL. The J3D "Hello cube" tutorial can help you get started. Also have a look at this tutorial on how to export from Unity to J3D.

As mentioned, you can also write your own WebGL from scratch, using no libraries. Find out how at the Learning WebGL blog.

Looking at WebGL code

Now it's time to have a look at some actual WebGL code. To make it simpler, this code has been created using a WebGL library. For the following example I have chosen PhiloGL because it has very good documentation, making it a great library for someone who wants to get started with WebGL.

This code shows some of the basic WebGL features that you may want to include in a simple program. The accompanying notes provide ample explanation, and links to the PhiloGL documentation for further details. You should take this example and experiment, making changes to what's there already and maybe even adding a few things of your own design. If you're curious you can compare this PhiloGL implementation with its equivalent in "raw" WebGL.

This scene has been translated into PhiloGL from Learning WebGL lesson #11. It shows a 3D model of the Moon, with textures applied from a NASA Moon map. The Moon can be rotated using drag-and-drop. You can see the moon example running live.

The next code snippet shows what your HTML file should look like. We import the PhiloGL script, as downloaded from the PhiloGL website, and the index.js file where we will write our code. We also create a <canvas> element where we want the WebGL scene to be rendered. When the document is loaded, webGLStart(); will be called. This function resides in index.js and will initialize the WebGL application.

Now Let's walkthrough the code inside index.js. The webGLStart(); function is the entry point for creating the WebGL application.

The moon is created using the PhiloGL O3D module. O3D provides model management and 3D primitives, like the sphere used in this case. The number of parallels (nlat) and meridians (nlong) and the radius are specified. A texture is applied to the sphere from an image file:

Next, the WebGL application is created by calling the PhiloGL constructor. The PhiloGL constructor automatically creates a WebGL context, a program, a camera, a scene, options for loading textures via IO, events handlers, and more. In this example we are going to use the default shaders, so no program needs to be specified in the constructor. The scene is also left unspecified. It will be created with its default values. The camera's position is modified. We declare a texture from an image source (moon.gif), and use some event handlers: drag-and-drop to rotate, and the mouse scroll to zoom the model.

Once the application is created successfully (the WebGL program is compiled, images are loaded and converted to textures, etc.), the onLoad callback will be executed. The first argument to the onLoad callback is a WebGL application. The WebGL Application class has useful methods to manipulate the program, the camera, the scene, etc. We also get a handle to the WebGL context through the gl property, in case we want to do some fine tuning at the WebGL API level:

In this example, users can dynamically modify the lighting values (ambient light colour, point light colour, and position) using a form on the page. Here we get a handle to those form elements:

Next we define some basic WebGL setup information: we set opaque black for background colour when clearing the canvas, we enable depth testing (this hides objects that are "behind" other objects in the scene), and we set the viewport to occupy the total width and height of the canvas.

Now we add the moon to our scene, and draw it. For each frame in the scene, the draw() function clears the screen, sets up the lighting, renders the moon and makes a request for the next frame to be drawn:

Summary

I hope this article gave you a good idea of what WebGL is about and how to get started building a simple WebGL application. Most importantly, however, I hope it got you excited about trying it yourself. We expect to publish more about WebGL in the near future. Stay tuned!

Useful links for more information:

• The Khronos WebGL forum
• Frequently asked questions about WebGL
• The Learning WebGL blog, a cool place for WebGL news and resources

Then the data in the vertex arrays is sent to the GPU by feeding it into a set of one or more /aThen the data in the vertex arrays is sent to the GPU by feeding it into a set of one or more

Read Part 2 of this series: Porting 3D graphics to the web.

原文：http://dev.opera.com/articles/view/an-introduction-to-webgl/

别担心，咱们不去管那些啦，因为有些还远远没有完成呢，在浏览器中见到它们还要等一阵子。然而，其它已经在浏览器中，或者距离您很近，或者马上就要 出现。人们可能将称之为“HTML5”，尽管它们并不是。其实，它们都属于令人激动的新兴Web技术（New Exciting Web Technology），值得每个开发者关注。

 
WebGL
WebGL是一种基于Web的Graphic库，由非盈利组织Khronos运营,目前结合HTML5<canvas>元素广泛应用在3D图形开发中。

学习WebGL比较困难，因为它是底层开发——它运行在GPU上面，而且它实际上是一个OpenGL的JavaScript port，是一种游戏开发者使用的已经长期建立的API集。WebGL的主要受众是哪些已经拥有丰富OpenGL经验的游戏开发者，他们可以通过 WebGL为web平台编写游戏。

好在有很多资源可以帮助您学习WebGL，这些资源不仅仅是关于游戏开发的，还有很多奇幻的图形、视觉和音乐视频等方面。作者个人比较推荐的是：
 

• Introduction to WebGL。http://dev.opera.com/articles/view/an-introduction-to-webgl/作者Luz Caballero，简介可以获得的各种库。
• Raw WebGL 101。http://dev.opera.com/articles/view/raw-webgl-part1-getting-started/适合那些不使用库的用户。
• Learning WebGL。http://learningwebgl.com/一个非常好的引导网站。
• WebGL 101。http://www.youtube.com/watch?v=me3BviH3nZc一个由Erik Moller制作的介绍视频（2.5小时）。
• See Emberwind。http://operasoftware.github.com/Emberwind/一个由Erik Moller做的WebGL游戏port，您可以深入Github或看代码。
  
  
   
  
  WebGL目前在所有桌面浏览器（发布版和开发频道）中都支持，除了IE10（微软表示不支持）。对于移动产品来说，已经在Opera Mobile 12中发布了，最终会出现在Android，BlackBerry Playbook 2.0，Nokia N900，SonyEricsson Xpertia Android Phones等以及Firefox移动浏览器中。
  SVG
  SVG（Scalable Vector Graphics）已经在Opera，Firefox，Chrome中存在多年了，但是直到IE9开始支持它之后才渐渐变得主流一些它在 HTML5<Canvas>的光环下显得有点暗淡，尽管SVG和HTML5<canvas>是面向不用应用的不同工具。
  
  Canvas2D可以迅速paint图形到屏幕上面，这一点很犀利。但是其全部功能就是paint了，没有内存来做那些（位置，顶层或其他）其他功 能。如果您需要那种book-keeping工作，就只能自己用JavaScript实现，因为Canvas2D不会把DOM保存到内存中，也正因为如此 Canvas2D速度快，十分适合第一人称射击类应用。
  
  与Canvas2D不同，SVG在您需要保存DOM的时候就给力了。使用JavaScript，所有的Objects都可以移动并且与动画无关。您 可以试试Daniel Davis做的复古类SVG游戏Inbox Attack（http://people.opera.com/danield/svg/inbox-attack.svg）来体验一下，并且看看源代 码来了解如何完成动画效果。
  
  
  
  因为shape和path是用Markup来描述的，所以他们可以用CSS来定型。与<canvas>不同，text在SVG中保持 text格式并且更加的灵活，更加可扩展，更加易于访问。在Canvas中，text变成了像素，就像Photoshop中的图形text。
  
  SVG最强大的特性是它基于矢量，这样您的插图，图形和UI图标等都是矢量图了，这样无论是在50英寸的电视屏还是手机屏幕桌面上，看上去感觉都是 一样的清晰。在当今这样一个web应用无处不在的时代，SVG图形甚至可以包括媒体查询（http://my.opera.com/ODIN/blog /2009/10/12/how-media-queries-allow-you-to-optimize-svg-icons-for- several-sizes），可以是响应式的，可以根据不同的目标设备做尺寸的调整。
  
  综上所述，在最新的桌面浏览器中SVG已经能被广泛支持了。在移动产品方面的支持总体上来说也很好，以及预期在Android 3.0版本之前原生浏览器也会支持它了。
  
  Daniel Davis有一些SVG 介绍性的资源（http://my.opera.com/tagawa/blog/learning-svg），作者个人也推荐一本免费的电子 书：Learn SVG（http://www.learnsvg.com/book-learnsvg/），您也可以看看《SVG or Canvas？Choosing Between the Two》（http://dev.opera.com/articles/view/svg-or-canvas-choosing-between- the-two/）来了解二者的区别。
  
  getUserMedia
  
  不像那些被错误地称为HTML5的API，getUserMeida（在下文中简写为gUM）有个相对正当的理由：起初它是HTML5<device>元素，之后它改名了然后离开了W3C WebRTC规范集合。
  
  gUM允许访问用户的摄像头和麦克风，本来是在WebRTC规范中在浏览器中进行P2P视频会议的，当gUM拥有了其他的用途，就离开了WebRTC。
  
  摄像头的访问最终在Opera12安卓版，Opera桌面实验室和Google Chrome Canary里面实现了，不过Opera和Chrome都还没有实现麦克风的接入。
  
  W3C规范依然在用，所以Opera和Webkit有不同的语法规范，这样的麻烦被一个叫做The gUM Shield（https://gist.github.com/f2ac64ed7fc467ccdfe3）的小JavaScript片段搞定了。如果 您想更深入地了解这方面请看作者的另一篇文章：It’s Curtains for Marital Strife Thanks to getUserMedia（http://html5doctor.com/getusermedia/）
  
  当视频从设备开始流传输的时候，源数据可以被做成变成了<video>元素，如果需要的话还可以被定为到屏幕外面，然后拷贝 到<canvas>里面进行所需要的操作。Paul Neave写的《HTML5 变成玩具！》（http://neave.com/webcam/html5/）为了方便操作把流媒体数据拷贝到WebGL中。作者在.net 杂志的226话有采访他的报导（http://www.netmagazine.com/shop/magazines/april-2012-226）。
  
  
  
  如果想把web app的功能做得像native app，gUM需要做很多的工作。试了一下Neaver的gum和WebGL 在Opera Mobile 12上面的demo，感觉和平台独有的app一样富有响应式并且很时髦。当在浏览器产品中其功能被广泛应用的时候，作者语言会有很多基于web的QR代码 阅读者以及很多增强现实的应用。
  
  File APIs
  
  W3C File APIs允许JavaScript访问本地文件，其中最常用的API是FileReader，可以从Opera，FireFox，IE10平台等的预览版看到（不包括Safari）。
  
  这一份W3C规范“为了在web应用中提供API来代表文件对象，以及编程选择和访问数据”。例如：你可以上传文件到浏览器中，并本地查找相关信息 （例如文件名，尺寸，类型）而不需要到服务器端。您也可以打开文件，操作内容，这样可以加强基于浏览器的应用的交互性，用起来更像是本地应用。
  
  另一个常用的用途是使传统的图像上传兑换狂更具有Web2.0特色：通过允许在浏览器内部的Drag and Drop，而不是本地文件系统中改变。
  
  您可以通过使用一个普通的<input type=”file”>开始，然后循序渐进地提高。HTML5 Drag&Drop支持特征检测，如果存在的话就使用<div>替换<input>，那就是您的drag图像目标了。当 图像被drag到目标的时候，使用File Reader API来显示一个指甲盖大小的图像。您可以看一下Remy Sharp的demo（http://html5demos.com/file-api）。
  
  还有很多写文件和操作文件系统的规范，不过这些对目前的跨浏览器应用来说还不太够：
  
  W3C文件API：（http://dev.opera.com/articles/view/the-w3c-file-api/）非常基础的介绍。
  
  开发文件系统API：（http://www.html5rocks.com/en/tutorials/file/filesystem/）HTML5 Rocks文章，（仅限Chrome）。
  Feature-detecting, progressive enhancement and upgrade messages（特征检测，渐进式增强和消息通知）
  诚然，在没有那些奇幻的API的时候，大家总是试图使用渐进式增强和HTML语义的方法让网站照常工作。然而有时候却不能这样，例如Paul Neaver的《HTML5变成玩具》中，如果gUM和WebGL现在不存在的话，其网站不能有什么补救措施了，整个网站的核心都没了。
  
  在这样的情况下有两种典型的惯例：要么是显示一条消息说“你的浏览器太垃圾了，塞油哪啦”或者说“你必须用Chrome6/Firefox 4/Opera10等[插入能支持你应用的浏览器]才能访问”。第一种方法又没用又粗鲁，没有建议和补救措施；第二种方法是个临时办法，因为六个月之内所 有浏览器可能都能支持你现在使用的技术了，让你在网站上留下的信息过时：例如您写的解决方案是建议使用Firefox4来访问，可是半年后用户安装着 Firefox7回来访问你的页面了，这可就真的没救了。
  
  如果您真的不能使用渐进式增强，那么就用新型的HTML 5 Please API吧（http://api.html5please.com/）。这是Jon Neal，Divya Manian和其他几位大虾创作的。通过使用它，可以先查询caniuse.com然后返回一个最新（能支持你的新特性的）的浏览器版本列表。
  
  如果您已经做了一个需要Canvas或WebSQL DB技术的DEMO或者网站，恐怕你已经处在一个这样的尴尬境地了：您只是在告诉访问者们他们的浏览器不咋地。但是您不能只推荐他们使用一个能支持这些特 性的浏览器来补救，例如“找个支持WebRTC性能的浏览器再来吧”，这样对于大家都没啥效果。
  
  HTML5 Please API把开发人员的语言（和特性）翻译成用户能理解的语言（浏览器）。通过调用这个API你就可以得到一些HTML返回值来告诉访问者，或者返回一个带有 相关数据的JSON对象（包括浏览器Logo及下载介绍等信息）。这样您可以根据不同的客户来显示不同的补救信息了。
  
  使用这种方式最令人欣慰的是：如果所有新特性在客户当前浏览器的升级版都能支持的情况下，Please API值建议访客对浏览器升级，而不是让访客单纯为了访问你这个页面而更换浏览器。效果图如下：
  
  
  
  结束语：
  
  正如您所看到的，大量的令人惊喜的新技术正在接踵而至，您着手研究上述某项技术的时候恐怕又要担心更新鲜的技术到来了吧。希望您开发得愉快，请记得让您所开发的应用在尽可能多的浏览器上面测试一下。
  
   

框架目标

OneRing是一个跨平台的桌面应用框架。和Adobe AIR类似，它支持用html/js/css制作用户界面，与之不同的是，它的应用为本地程序，可以直接访问操作系统的数据。

架构

一个OneRing应用程序分为两个部分：框架部分和应用部分。

框架部分

框架部分为通用框架，各应用都一样。其提供各操作系统上的界面展现，为本地窗口内嵌一个WebKit浏览器，并提供一致的js接口让应用和操作系统功能进行交互。

框架以运行时库的形式提供。

框架以系统原生语言编写，提供其他语言的绑定。

应用部分

应用部分为一个web server，负责应用逻辑，用html/css描述界面，用js提供用户交互。

运行流程

1. 应用启动时，会加载框架的运行时库，注册应用url的访问方法（如WSGI），并调用框架的loop函数。
2. loop函数会访问应用的 /init URL，得到一个json数据，描述初始应用窗口的相关参数，如位置、大小、窗口属性、初始页面url等。
3. 框架根据该数据创建窗口，并让该窗口内的浏览器访问初始页面url，渲染用户界面，然后等待UI事件。
4. 用户在界面上操作时，可以通过超链接改变整个窗口内容，也可以使用AJAX技术更新窗口内部分内容。
5. 应用可以让浏览器调用ONERING名字空间下的js函数，和操作系统进行交互，该名字空间由url onering://onering/onering.js 加载。
6. 应用通过 bind(event, function) 函数监听窗口更改大小、移动等操作系统UI事件。
7. 可以使用pub/sub机制主动推送消息给浏览器。
8. 调用 ONERING.exit() 可以退出应用；所有窗口都关闭后也会退出应用。

Python应用示例

#!/usr/bin/env pythonimport jsonimport webimport onering urls =(    '/init','init',    '/','index', )class init:    def GET(self):        web.header('Content-Type','application/json')        return json.dumps({'width':400,'height':300,'url':'/'})class index:    def GET(self):        web.header('Content-Type','text/html')        return"""<html><head><script type="text/javascript" src="onering://onering/onering.js"></script></head><body><p>Hello, world!</p><button onclick="javascript:ONERING.exit()">Exit</button></body></html>""" app = web.application(urls, globals()) if __name__ == '__main__':    onering.register_wsgi_app("demo", app.wsgifunc())    onering.loop("demo")

各组件之间的交互

一个OneRing应用中，存在三个需要互相通讯的组件:

1. 操作系统 OS ，控制窗口行为（如最小化窗口），及操作系统相关界面元素（如系统通知图标）
2. 运行在WebKit内的javascript，控制界面内元素（如程序界面里的按钮）
3. WSGI应用，控制HTML/JS的生成逻辑，以及应用相关的后台逻辑

js -> os

当js需要通知os对js所在窗口做某个行为（如最小化），通过调用 onering.js 中的get_current
_window()返回值（为Window对象）的相应方法实现：

var current_window = ONERING.get_current_window();current_window.minimize();

当js需要os执行整个应用层面的操作时（如结束应用），通过调用 onering.js 中的函数实现：

ONERING.exit();

当js需要os创建一个新窗口时，通过调用createWindow函数实现，并获得新建窗体的句柄实例：

new_window = ONERING.createWindow('/a_dialog',400,300);

当js需要向另一个窗口做某个os行为时（如隐藏另一个窗口），通过调用窗体的句柄实例的方法实现：

new_window.hide();

os -> js

js可以通过bind机制，关注操作系统发生的时间（如窗口大小改变）：

current_window.bind('resize',function(event){    if(event.width <300){        $('#sidebar').hide();    }});

js -> app

js可以通过类AJAX调用，从app获取数据。

ONERING.getJSON('/userdata.json',function(data){    ...});

app -> js

app希望向窗体内的js主动推送消息时，可以采用pub/sub机制。

首先js通知框架自己关注的事件:

current_window.subscribe("a_file_scanned",function(fileinfo){  ...});

然后当app希望发送消息时，调用onering框架提供的publish方法：

for fileinfo in scan_files():    onering.publish("a_file_scanned", fileinfo);

其中的fileinfo为可以转化为JSON的python对象（即 json.dumps(fileinfo) 不会抛出异常）。

Perhaps one of the first inescapable observations that a new Google developer (Noogler) makes once they dive into the code is that Protocol Buffers (PB) is the "language of data" at Google. Put simply, Protocol Buffers are used for serialization, RPC, and about everything in between.

Initially developed in early 2000's as an optimized server request/response protocol (hence the name), they have become the de-facto data persistence format and RPC protocol. Later, following a major (v2) rewrite in 2008, Protocol Buffers was open sourced by Google and now, through a number of third party extensions, can be used across dozens of languages - including Ruby, of course.

But, Protocol Buffers for everything? Well, it appears to work for Google, but more importantly I think this is a great example of where understanding the historical context in which each was developed is just as instrumental as comparing features and benchmarking speed.

Protocol Buffers vs. Thrift

Let's take a step back and compare Protocol Buffers to the "competitors", of which there are plenty. Between PB,Thrift, Avro and MessagePack, which is the best? Truth of the matter is, they are all very good and each has its own strong points. Hence, the answer is as much of a personal choice, as well as understanding of the historical context for each, and correctly identifying your own, individual requirements.

When Protocol Buffers was first being developed (early 2000's), the preferred language at Google was C++ (nowadays, Java is on par). Hence it should not be surprising that PB is strongly typed, has a separate schema file, and also requires a compilation step to output the language-specific boilerplate to read and serialize messages. To achieve this, Google defined their own language (IDL) for specifying the proto files, and limited PB's design scope to efficient serialization of common types and attributes found in Java, C++ and Python. Hence, PB was designed to be layered over an (existing) RPC mechanism.

By comparison, Thrift which was open sourced by Facebook in late 2007, looks and feels very similar to Protocol Buffers - in all likelihood, there was some design influence from PB there. However, unlike PB, Thrift makes RPC a first class citizen: Thrift compiler provides a variety of transport options (network, file, memory), and also tries to target many more languages.

Which is the "better" of the two? Both have been production tested at scale, so it really depends on your own situation. If you are primarily interested in the binary serialization, or if you already have an RPC mechanism then Protocol Buffers is a great place to start. Conversely, if you don't yet have an RPC mechanism and are looking for one, then Thrift may be a good choice. (Word of warning: historically, Thrift has not been consistent in their feature support and performance across all the languages, so do some research).

Protocol Buffers vs. Avro, MessagePack

While Thrift and PB differ primarily in their scope, Avro and MessagePack should really be compared in light of the more recent trends: rising popularity of dynamic languages, and JSON over XML. As most every web developers knows, JSON is now ubiquitous, and easy to parse, generate, and read, which explains its popularity. JSON also requires no schema, provides no type checking, and it is a UTF-8 based protocol - in other words, easy to work with, but not very efficient when put on the wire.

MessagePack is effectively JSON, but with efficient binary encoding. Like JSON, there is no type checking or schemas, which depending on your application can be either be a pro or a con. But, if you are already streaming JSON via an API or using it for storage, then MessagePack can be a drop-in replacement.

Avro, on the other hand, is somewhat of a hybrid. In its scope and functionality it is close to PB and Thrift, but it was designed with dynamic languages in mind. Unlike PB and Thrift, the Avro schema is embedded directly in the header of the messages, which eliminates the need for the extra compile stage. Additionally, the schema itself is just a JSON blob - no custom parser required! By enforcing a schema Avro allows us to do data projections (read individual fields out of each record), perform type checking, and enforce the overall message structure.

"The Best" Serialization Format

Reflecting on the use of Protocol Buffers at Google and all of the above competitors it is clear that there is no one definitive, "best" option. Rather, each solution makes perfect sense in the context it was developed and hence the same logic should be applied to your own situation.

If you are looking for a battle-tested, strongly typed serialization format, then Protocol Buffers is a great choice. If you also need a variety of built-in RPC mechanisms, then Thrift is worth investigating. If you are already exchanging or working with JSON, then MessagePack is almost a drop-in optimization. And finally, if you like the strongly typed aspects, but want the flexibility of easy interoperability with dynamic languages, then Avro may be your best bet at this point in time.