上周硅谷非常热闹，重大消息频繁出现，其中包括了乔布斯因病休假，苹果的恐怖财报等等。对于我们所关心的移动业界跟互联网来说，Google 换帅是另外一个重量级消息。

Quora 上有一个讨论串，题目是“Larry Page 上任之后，Google 的重点应该是什么？”，讨论相当活跃。我也在这里凑个热闹，谈一谈在我看来，Larry Page 应该如何去改变 Google。

1：关注核心业务，也就是搜索

Google 前段时间在搜索结果上算是饱受攻击，由于与日俱增的垃圾内容，搜索结果的污染状况越发严重。Stack Overflow 的创始人之一 Jeff Atwood 在一篇文章里这样评价 Google 现在的搜索结果：

Google ，这个曾经的必备工具，某种程度上已经失去了它的优势地位。垃圾内容制造者、以点击率为终极目标的内容聚合站点正在走向胜利。

在 这一点上来说，ifanr 感同身受。作为内容提供者，我们是创造价值的人，是在给互联网不断添砖加瓦的一方。而之前在 Google 里搜索我们的原创文章，出现在结果最顶端的却往往是是通过拷贝+粘贴、有时候还不注明出处进行转载的内容聚合站点。它们用毫无成本的方式夺取着应该属于原 作者的访问量。

好在 Google 似乎已经认识到了这一点。之前搜索质量组的 Matt Cutts 表示他 们已经意识到了垃圾内容的增多，以及劣质内容聚合站点引发的不满，并且会很快进行处理。从我今早的实验来看，似乎 Google 已经采取了措施，最近 ifanr 的原创文章都出现在首页头条。从根子上（点击量带来的经济利益）驱逐劣质内容聚合站点，对现代互联网来说，确实是件好事

搜索，是 Google 的立身之本，从上周发布的财报来看，Google 收入的主要增长点仍然是在网站本身的业务。不断改进搜索，添加新的搜索方式，才能保持和增强 Google 在这个领域的领导地位。后院不起火，才有在其他领域发展的资本。

这一条，是 Larry Page 上任以后最需要关注的。未来十年的搜索是什么样子？如何提高内容关联性，改进使用体验？怎么样通过创新，把 Bing 等竞争对手远远甩开，对 Google 来说，至关重要。

2：在社交网络方面另辟蹊径

Google 在社交网络方面的试探，到目前为止都是悲剧，坦率地说，我个人认为Google 已经错过了第一班社交网络的列车。

作为新生事物的社交网络，从一开始负载的是用户虚拟交流的需求。

目 前的胜利者里面，Facebook 满足了人们交流的愿望，利用网络，表现了某种程度上真实的人与人关系，而大量互动元素的引入，则是模拟了现实生活的部分人际往来，从根底上来说，没有理念 上的创新，然而它仍然足够伟大，Facebook 把现实生活成功投影到了虚拟世界，是真正意义上的创造者。

另一个赢家是 Twitter，它满足的，是人们表达自己的愿望。通过简短的 140 个字，人与人之间形成了一种奇妙的交流关系，普通人也可以第一时间见证重大事件。可以说，Twitter 与智能手机的结合，创造了一种新媒体。表达自己，记录周边，关注别人，是 Twitter 类社交网络的根本。无论是变种的 foursquare，还是 Quora，从理念上看，都是这样的东西。

Google 之前的尝试呢？ Wave 那个体验一塌糊涂的东西不去说它，出生太早了；Buzz 则是无限制版本的 Twitter：Google 试图利用现成的庞大用户群，但没有实质性创新，再加上拙劣的整合方式，这个产品的前景乐观不到哪儿去。

社交网络走到现在，实际上已经到了一个重要的关口，即：虚拟的内容如何与现实社会结合起来，怎样把线上关系与实体经济整合，创造出一个崭新的商业模式。在我看来，这才是第二代社交网络，也即成熟版本的社交网络。这个方向是未来两年的热点，也是 Google 下一步可以突围的角度。

Google 的最大优势是什么？大家应该都非常清楚，其一是庞大的用户群，其二就是信息了。Google 相对于 Twittter、fousquare 等来说，先天就有信息方面的优势。而 Google 在建设社交网络的时候，却完全忽略了这个优势，捆着手脚去从头开始跟已经成熟的对手竞争，怎么可能胜利？

举个最简单的例子，Google Maps 信息丰富，我经常用它来寻找晚餐地点，最大的好处之一就是可以看到多个网站的用户评价，看看截图：

看 到了吧，有 Buzz 选项，然而搞笑的事来了。我可以看到其他网站的评价，可以在 Buzz 上分享这个地点，然后呢？没了。我完全看不到 Buzz 关于这个餐馆的讨论，看不到我分享以后朋友的看法——一点也没有。实体经济方面的内容本身就是 Google 的长项，然而在它的任何产品里面，都没有把这个长处跟自己的社交网络更紧密得结合起来。

放着庞大的现实数据不用，几个产品之间几乎没有交流，捧着金饭碗要饭，这就是 Google 的社交网络。跟现实社会结合的社交网络，将是 Google 在这一领域的最后一个机会。

3：细节，细节，还是细节

有一句老话，细节决定成败，然而 Google 现在的很多做法，却表现了一种对细节的漠视，极大影响了产品的使用体验。还是要以 Android 为例（这玩意简直就是反面教材）：

就从简单的设置界面说起。Android 平铺直叙的设置界面，完全没有突出重点（我甚至怀疑这帮人安排顺序的时候是不是拍脑门做出的决定。），跟右边的 iOS 比，孰优孰劣，一目了然。

还有应用市场，每次谈到 Android 的应用市场，我都有爆粗口的冲动。缓慢的速度、时常丢失的已下载应用列表、迟迟没有解决的应用无法下载问题……这是整个产业的核心之一，Google 就准备这么糊弄下去？

Android 不讲究的地方何止这些，工程师文化并不代表着可以不拘小节，Google 的目光，应该多放些在细节上。移动设备，用户体验至关重要。

4: 继续拥抱云，下注新能源产业

在这个卖杂货的、搞 B2C 的、做软件的都在搞云应用平台的当口，互联网界巨头，拥抱云的先驱之一，可能拥有着世界上最好硬件以及网络设施的 Google，当然也拥有自家的 App Engine。

云 计算平台对于中小企业、个人的意义，无论如何赞扬也不会过分，它直接引领了当前的互联网创业潮。低廉的平台成本，按需付费的方式，Amazon EC2 吸引了大量的个人开发者，Google 的 App Engine 当然不错，但我要说，还是不够灵活，如果能提供更多语言支持，就再好不过了。

新能源很好理解，随着碳交易市场的兴起，碳排放量眼看就要变成金融市场上的一个新产品。在这个趋势影响下，每个企业都应该考虑下自己的能源来源，为将来更加严格的排放调控措施做好准备，规避可能的经济风险。

降低所消耗能源的碳排放，对于 Google 这种能源消耗大户来说，是经济跟政治上都很正确的方向，而且同样有大量的利益存在。新能源产业，应该成为 Google 下一步的重点投入方向。

5：提高决策速度与质量，减少内部沟通环节

大 家都知道 Google 著名的 20% 规则：员工可以把 20% 的上班时间放在其他项目上。Google 的员工无疑是优秀的，这些业余时间做出的项目也应该有很多不错的点子，然而，从中孵化的成果却并不多。其中的部分原因，恐怕与 Google 的内部引导以及沟通机制存在很大的关系。由于缺乏引导，员工的项目往往与 Google 本身没什么联系，而因为沟通问题，好的项目不一定能够获得公司的帮助。

Google 的前员工遍布整个互联网业界，大量创新却往往出现在他们离开 Google 以后。应该如何去引发员工的创造力、提高内部效率跟执行力度，Larry Page 需要仔细考虑，以便调整内部架构来适应这个变化迅速的世界。三星这个反应快到根本不像大公司的大公司在全世界攻城掠地，诺基亚反应稍微迟缓一点就束手束 脚，Google，你要快一点，再快一点，才能跟 Facebook 以及数以千计的创业企业进行竞争。

转自：http://www.oschina.net/news/14996/larry-page-google-five-things-todo

没有人能说清哪种缓存算法优于其他的缓存算法。（以下的几种缓存算法，有的我也理解不好，如果感兴趣，你可以Google一下）

Least Frequently Used（LFU）：

大家好，我是 LFU，我会计算为每个缓存对象计算他们被使用的频率。我会把最不常用的缓存对象踢走。

Least Recently User（LRU）：

我是LRU缓存算法，我把最近最少使用的缓存对象给踢走。

我总是需要去了解在什么时候，用了哪个缓存对象。如果有人想要了解我为什么总能把最近最少使用的对象踢掉，是非常困难的。

浏览器就是使用了我（LRU）作为缓存算法。新的对象会被放在缓存的顶部，当缓存达到了容量极限，我会把底部的对象踢走，而技巧就是：我会把最新被访问的缓存对象，放到缓存池的顶部。

所以，经常被读取的缓存对象就会一直呆在缓存池中。有两种方法可以实现我，array 或者是 linked list。

我的速度很快，我也可以被数据访问模式适配。我有一个大家庭，他们都可以完善我，甚至做的比我更好（我确实有时会嫉妒，但是没关系）。我家庭的一些成员包括LRU2 和 2Q，他们就是为了完善 LRU 而存在的。

Least Recently Used 2（LRU2）：

我是 Least Recently Used 2，有人叫我最近最少使用twice，我更喜欢这个叫法。我会把被两次访问过的对象放入缓存池，当缓存池满了之后，我会把有两次最少使用的缓存对象踢走。 因为需要跟踪对象2次，访问负载就会随着缓存池的增加而增加。如果把我用在大容量的缓存池中，就会有问题。另外，我还需要跟踪那么不在缓存的对象，因为他 们还没有被第二次读取。我比LRU好，而且是 adoptive to access 模式 。

Two Queues（2Q）：

我是 Two Queues；我把被访问的数据放到LRU的缓存中，如果这个对象再一次被访问，我就把他转移到第二个、更大的LRU缓存。

我踢走缓存对象是为了保持第一个缓存池是第二个缓存池的1/3。当缓存的访问负载是固定的时候，把 LRU 换成 LRU2，就比增加缓存的容量更好。这种机制使得我比 LRU2 更好，我也是 LRU 家族中的一员，而且是 adoptive to access 模式 。

Adaptive Replacement Cache（ARC）：

我是 ARC，有人说我是介于 LRU 和 LFU 之间，为了提高效果，我是由2个 LRU 组成，第一个，也就是 L1，包含的条目是最近只被使用过一次的，而第二个 LRU，也就是 L2，包含的是最近被使用过两次的条目。因此， L1 放的是新的对象，而 L2 放的是常用的对象。所以，别人才会认为我是介于 LRU 和 LFU 之间的，不过没关系，我不介意。

我被认为是性能最好的缓存算法之一，能够自调，并且是低负载的。我也保存着历史对象，这样，我就可以记住那些被移除的对象，同时，也让我可以看到被移除的对象是否可以留下，取而代之的是踢走别的对象。我的记忆力很差，但是我很快，适用性也强。

Most Recently Used（MRU）：

我是 MRU，和 LRU 是对应的。我会移除最近最多被使用的对象，你一定会问我为什么。好吧，让我告诉你，当一次访问过来的时候，有些事情是无法预测的，并且在缓存系统中找出最少最近使用的对象是一项时间复杂度非常高的运算，这就是为什么我是最好的选择。

我是数据库内存缓存中是多么的常见！每当一次缓存记录的使用，我会把它放到栈的顶端。当栈满了的时候，你猜怎么着？我会把栈顶的对象给换成新进来的对象！

First in First out（FIFO）：

我是先进先出，我是一个低负载的算法，并且对缓存对象的管理要求不高。我通过一个队列去跟踪所有的缓存对象，最近最常用的缓存对象放在后面，而更早的缓存对象放在前面，当缓存容量满时，排在前面的缓存对象会被踢走，然后把新的缓存对象加进去。我很快，但是我并不适用。

Second Chance：

大家好，我是 second chance，我是通过FIFO修改而来的，被大家叫做 second chance 缓存算法，我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一样也是在观察队列的前端，但是很FIFO的立刻踢出不同，我会检查即将要被踢出的对象有没有之前被使用过的标志（1一个bit表示），没有没有被使用 过，我就把他踢出；否则，我会把这个标志位清除，然后把这个缓存对象当做新增缓存对象加入队列。你可以想象就这就像一个环队列。当我再一次在队头碰到这个 对象时，由于他已经没有这个标志位了，所以我立刻就把他踢开了。我在速度上比FIFO快。

CLock

我是Clock，一个更好的FIFO，也比 second chance更好。因为我不会像second chance那样把有标志的缓存对象放到队列的尾部，但是也可以达到second chance的效果。

我持有一个装有缓存对象的环形列表，头指针指向列表中最老的缓存对象。当缓存miss发生并且没有新的缓存空间时，我会问问指针指向的缓存对象的标 志位去决定我应该怎么做。如果标志是0，我会直接用新的缓存对象替代这个缓存对象；如果标志位是1，我会把头指针递增，然后重复这个过程，知道新的缓存对 象能够被放入。我比second chance更快。

Simple time-based：

我是 simple time-based 缓存算法，我通过绝对的时间周期去失效那些缓存对象。对于新增的对象，我会保存特定的时间。我很快，但是我并不适用。

Extended time-based expiration：

我是 extended time-based expiration 缓存算法，我是通过相对时间去失效缓存对象的；对于新增的缓存对象，我会保存特定的时间，比如是每5分钟，每天的12点。

Sliding time-based expiration：

我是 sliding time-based expiration，与前面不同的是，被我管理的缓存对象的生命起点是在这个缓存的最后被访问时间算起的。我很快，但是我也不太适用。

好了！听了那么多缓存算法的自我介绍，其他的缓存算法还考虑到了下面几点：

• 成本。如果缓存对象有不同的成本，应该把那些难以获得的对象保存下来。
• 容量。如果缓存对象有不同的大小，应该把那些大的缓存对象清除，这样就可以让更多的小缓存对象进来了。
• 时间。一些缓存还保存着缓存的过期时间。电脑会失效他们，因为他们已经过期了。

根据缓存对象的大小而不管其他的缓存算法可能是有必要的。

原文：http://www.zavakid.com/27

提交 B3log Solo（运行在 GAE/J 上的博客程序） 代码后发现 Google Code 版本控制系统会将提交日志同步发布到 Google Buzz 中：

但在 Buzz connected sites 里并没有看到与 Google Code 关联：

现在一提交代码就 Buzz，还是比较无奈的....

有时我们需要随机地获取数据记录（实体），比如博客程序中的“随机文章”的实现。

目前 GAE 并没有 API 可以直接获取随机实体，要实现这样的需求我们只能自己想办法了 :-)

在 stackoverflow 上也有人提过该问题，总结如下：

• Generate and store a random number on your entities as you create them, then pick a random number and look (via a query) for the closet record(s) to it.
• Implement some mechanism to ensure your entity ids are "densely" populated, then fetch within the known range using keys.
• Periodically generate random lists of the entities and return entities from those lists. This may take the form of a stack that entities are popped off of, or as actual lists that are returned.

目前 B3log Solo 在处理“随机阅读”上采用的是方法一，即在每个文章实体上添加一个属性保存 0-1 的随机浮点数。

在获取随机文章时生成一个 0-1 的随机数（mid）作为查询条件，以此查询条件作为边界（0 <= mid <=1）来过滤实体保存的随机值属性。

这个方法基本可以达到随机的效果了，为了让随机的效果更动态一点，我们可以考虑经常更新文章实体中的随机浮点值：

• 访问文章时（即在更新文章浏览次数时一并更新该文章的随机浮点值）
• 后台定时任务（获取一定数量的随机文章然后更新它们的随机浮点值）
• 用户做文章更新时

加上以上处理后，随机的效果比较好了 :-)

作者 荣浩 发布于 2010年12月28日 上午12时0分

对jBPM来说，今年最大的事件莫过于jBPM的创建者Tom Baeyens离开JBoss了。Tom Baeyens离开的具体原因尚不清楚，但他的离开产生了两个结果：一是jBPM的下一个版本jBPM5完全放弃了jBPM4的基础代码，基于Drools Flow重头来过；二是Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的开源工作流系统Activiti。 由此不难推测Tom Baeyens离开的部分原因：JBoss内部对jBPM未来版本的架构实现产生了严重的意见分歧。更加巧合的是12月1日Activiti5刚发布，紧 接着12月2日jBPM5就发布了第一个候选发布版本，jBPM与Activiti之间的微妙关系可见一般。

在这篇文章里，我们将一起回顾jBPM从jBPM3到jBPM5以及Activiti5的发展历程，我们可以清晰的看见jBPM（包括 Activiti）设计所遵循的一致原则：强调流程服务的可嵌入性和可扩展性。同时，从各个版本之间的变化我们也能看见产品设计思路的变化：更加强调面向 业务人员，增加BPMS（业务流程管理系统）特性。

在回顾之前，我们首先讨论一下BPMS应该嵌入还是独立部署的问题，因为不管是jBPM还是Activiti，都强调了流程服务的可嵌入性。此外，我们还需要讨论一下什么是BPMS的特性，它们所解决的问题是什么。

一、嵌入式还是独立部署？

不管是jBPM还是Activiti，都强调了流程服务的可嵌入性。Tom Baeyens在其个人博客里称作为独立部署的BPMS已死，原因有两个：一是独立部署的BPMS需要很高的安装使用成本，需要独立部署、需要用户支出大 量的培训成本和维护成本；二是独立部署的BPMS与外部系统的交互方式是分布式，这使得很多问题变得复杂，例如分布式事务。Tom Baeyens代表了相当一部分人特别是开发人员的观点。

Tom Baeyens没有完全理解BPMS。什么是BPMS？BPMS最重要的目标就是需要打破各个应用系统（CRM、ECM、ERP、SCM）之间的界线，将 分散在这些系统中的流程集中管理，这是BPMS的实质。一如流程再造，打破各个部门之间的壁垒，减少浪费，建立流程驱动性的组织。如下图1所示：

图 1：BPMS打破应用系统之间的界线

BPMS所要解决的问题要求其必然是独立部署的。Tom Baeyens错误的根本原因在于其将BPMS与工作流系统的定义混为了一谈，他如此定义BPMS：BPMS旨在简化对组织核心流程进行支撑的软件创建。 也就是BPMS面向的是软件开发人员，旨在简化他们的开发，降低他们使用流程的门槛。而这正是工作流系统需要解决的问题。

BPMS面向企业用户，工作流面向开发社区和系统集成商。

二、BPMS特性

jBPM4、jBPM5和Activiti5都增加了其BPMS特性，那些特性能够称为BPMS特性呢？我们先看一看BPMS需要解决的问题，为解决这些问题所增加的特性就是BPMS特性。

1. 如何设计流程，在组织中高效地对设计出的流程进行沟通，取得共识？

   • 提供跨越组织的流程标准标记符号与术语（BPMN已经成为标准）
   • 流程及相关文档的可视化（流程/内容存储仓库）
   • 提供在组织结构内进行不同层次之间的流程导航（流程存储仓库支持组织模型）
   • 流程定义在各个层次/部门间的一致性，避免业务人员的流程建模转换到IT系统时受到损耗（流程引擎支持基于图的建模，支持扩展）

2. 如何更好地执行流程？

   • 业务活动的实时监控，预警与控制（BAM）
   • 流程执行的仿真
   • 流程执行的统计分析与反馈（报表）
3. 如何更好地管理流程？
   • 打破各个应用系统之间的界线，统一管理所有流程（EAI，与ESB的集成）
   • 对业务人员友好的建模工具
4. 如何在执行流程过程中遵循业内最佳实践和规则？
   • 面向流程的知识管理
   • 规则引擎

三、完整的工作流实现jBPM3

jBPM3的最新版本是3.2.7，其包括了以下组件：基于Eclipse的流程设计器、用于监控案例（流程实例）和处理任务的Web控制台以及jPDL核心库。如下图2所示：

图 2：jBPM3组件

1. 基于Eclipse的流程设计器

   提供给开发人员绘制jPDL流程图，因为该设计器基于Eclipse，所以生成的流程文件可以与开发代码一起组织管理，非常容易进行单元测试。实现了工作流管理系统参考模型里的接口1。

2. Web管理控制台

   主要有两个功能：一是作为工作流客户端应用接口，给用户提供一种手段，以处理案例运行过程中需要人工处理的任务；二是对案例的状态进行监控与管理。实现了工作流管理系统参考模型里的接口2和5。

3. jPDL核心库

   jPDL核心库是一个单独的JAR包，可以嵌入到目标应用中执行，它包括了：

   • 流程仓库：解析jPDL流程定义文件并存储读取；
   • 流程引擎：对流程定义进行初始化和调度执行，节点的运行期行为与jPDL里定义的节点类型一一绑定；
   • 任务管理：生成任务节点所对应的工作项，管理工作项的生命周期（初始化、分配执行者、执行、挂起、结束、终止）；
   • 事件管理：发布案例和任务的开始、结束事件，通过监听者模式调用相应的事件处理器；
   • 异步执行机制：通过线程实现了Job Executor，进行异步工作的处理，这些工作包括了时间处理、异步动作。
   • 身份组件模型：实现了一套简单的身份组件模型，包括了组、用户和权限。

   通过调用自定义Java代码实现了对外部应用的调用，从而实现工作流管理系统参考模型里的接口3。

jBPM3是一个轻量级的嵌入式工作流系统。它在Java社区的成功得益于两个方面：一是嵌入式，这降低了使用工作流的门槛；二是对开发人 员友好，这表现在易读的jPDL、流程的可测试性(Eclipse插件)以及节点行为的可扩展性，我们可以非常容易的在流程运行中加入自己定制的行为（通 过事件处理器和Action）。jBPM3面向开发人员，它解决的问题是流程的自动化，它的影响力集中在Java开发社区，是一个完整的工作流系统实现。

四、向BPMS努力的jBPM4

与jBPM3相比，jBPM4最大的变化是引入了流程虚拟机（PVM），同时增加了BPMS的特性。jBPM4不再满足于工作流系统的定位，开始向BPMS努力。

1. 为什么引入流程虚拟机

   尽管jBPM3在Java社区取得了很大的成功，但是有一件事始终被人们诟病，那就是它不支持流程语言规范，从最开始的XPDL、BPEL 到后来的BPMN，它采用了自定义的jPDL。在jBPM3中，节点的运行期行为与jPDL里定义的节点类型是一一绑定的，这造成了流程引擎与特定流程语 言的绑定，要支持其他的流程语言变得困难。于是在jBPM4中，jBPM提出了流程虚拟机的概念，即流程引擎与流程语言解耦，通过一套通用的流程模型并配 以可定制的节点运行期行为实现了对多流程语言的支持。

   流程虚拟机带来的好处是多方面的：第一也是最重要的是jBPM4支持了BPMN。

   第二是实现了基于流程组件的流程引擎，流程图(语言)与实现解耦，我们使用通用编程语言实现节点运行期行为，称之为流程组件，通过将流程图 与流程组件挂接，避免了图的损耗。在这一点上，Tom Baeyens对BPMN到BPEL的转换提出了一针见血的批评：BPMN和jPDL以及XPDL都是基于图的，而BPEL是基于块的，这造成了当将业务 人员使用BPMN所建立的流程模型向BPEL执行模型进行转换时，出现许多的不匹配，最初的流程模型会扭曲变形。而扭曲的后果就是业务人员与开发人员之间 的协作困难，这影响了流程从业务到技术的实现。

   第三个好处是我们可以定义领域特定语言（DSL），在特定的应用里，采用DSL约定并隐藏了大部分的技术细节可能做到业务人员对执行流程的直接修改，例如企业文档管理里的审批流程。

2. BPMS特性的加入

   这表现在以下三个方面：第一是支持了BPMN，BPMN已经成为业务人员的流程建模标准；第二是引入了Signavio作为面向业务人员的Web建模器；第三是在已有的Web管理控制台加入了对案例和任务的统计功能。jBPM4的组件如下图3所示：

   

   图3：jBPM4组件

   和jBPM3一样，jBPM4依然是轻量级的、可嵌入的工作流系统。相比jBPM3，它将业务人员作为最终用户之一，增加了部分BPMS特性，同时PVM的引入使得它的可扩展性得到了极大的增强，我们甚至可以定义自己的DSL。

   在BPMS特性里我们提到了应该避免业务人员的流程建模转换到IT系统时受到损耗，最理想的情况是业务人员与开发人员共用一个流程模型，业 务人员能够直接对流程进行调整（在特定应用中，通过DSL是可以做到的）；其次是通过BPMS将业务人员的模型与实际执行的技术模型关联起来（很多商业产 品已经做到了这一点，在Activiti5中我们也会看到这一点），业务人员、开发人员以及运营团队之间能够做到很好的协调；最差是业务人员与开发人员各 自为政，独立维护各自的流程模型，并且模型之间存在极大的不匹配，此时流程的迅速变化基本上是奢望。

五、鸠占鹊巢的Drools Flow与jBPM5

目前jBPM5刚刚发布了第一个候选发布版本，jBPM5基本上完全抛弃了jBPM4的代码，所有代码全部来自原先的Drools Flow。Drools Flow最初被用来解决规则执行顺序的问题。其实从Drools Flow开始支持BPMN时起，我们已经预感到它与jBPM的竞争关系。

jBPM5依旧定位为轻量级的可嵌入的工作流系统。在jBPM5的特性里，有这么两条引人关注：一是引入了Guvnor作为流程仓库，这解决了流程 的可视化问题，流程定义作为资源被管理，我们可以对流程定义进行可视化管理以及全文检索（Guvnor使用了Jackrabbit作为了其存储实现，但我 们的经验表明Jackrabbit在大数据量情况下性能存在严重问题）；第二是规则引擎(Drools Expert)、事件处理引擎(Drools Fusion)与流程引擎的合三为一，这是jBPM5最让人期待的地方。jBPM5的组件如下图4所示：

图 4：jBPM5组件

规则引擎在流程中的应用已经非常广泛了，我们这里说说事件处理引擎。

事件处理引擎是业务活动监控（BAM）的基础，BAM的功能及执行过程，如下：

• 捕获：BAM捕获各种事件（通过消息监听器、适配器、代理等）。这些事件来自应用、系统软件、外部交易伙伴。消息是BAM的核心——它们反应底层业务流程的状况。
• 过滤：BAM过滤掉没有直接后果的事件，在很多情况下由支持事件流处理（Event Stream Processing，简称ESP）或复杂事件处理（Complex Event Processing，简称CEP）引擎来进行过滤。
• 分析：BAM根据分析模型和规则将相关事件联系起来。
• 警告：BAM向用户提出警告，以便用户在必要时进行控制。

如上所示，BAM的执行过程包含四个步骤，而前三个步骤都是对事件进行相关的处理（捕获事件、过滤事件、分析事件、关联事件），因此在大多数BAM的技术实现方案中，都基于CEP和ESP的引擎来实现BAM的功能。

与jBPM4相比，jBPM5对PVM的放弃也带来了几个不小的问题：第一是对开发人员来说只支持BPMN，不再支持jPDL（当然提供了迁移工 具）；第二是流程执行的可扩展性回到了jBPM3的年代，仅仅支持自定义动作（相当于jBPM3里的Action）。此外，Web建模器由 Signavio替换为了Oryx Designer。

总而言之，jBPM5通过引入流程仓库和BAM继续向BPMS迈进（目前的进展是与流程仓库的集成还未完成，BAM基于日志进行分析），同时，由于不再支持PVM和jPDL，带来了流程扩展性的降低和社区开发人员的未来流失。

六、Activiti5的反击

Activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的开源工作流系统，1号刚刚发布第一个版本。Activiti的开发团队相比与jBPM强 大了许多，有23位核心开发者。当然这也是由于activiti规划的功能所致：包括核心引擎、Web的流程建模器、协作工具Activiti Cycle、Activiti Probe、Activiti Explorer、与Spring的集成、与Mule的集成等。

图 5：Activiti5的组件

如上图所示，Activiti5由三种类型的组件组成，分别是：专用工具（Dedicated Tools）、内容存储工具（Stored Content）和协作工具（Collaboration Tool）。

专用工具包括以下：

• Alfresco—Alfresco公司的企业级内容管理产品

Alfresco 是一个开源的、企业级的内容管理系统，功能包括：文档管理、协作、记录管理、知识库管理、Web内容管理等功能。Alfresco与Activiti的深 入集成实现了流程及相关文档的可视化。更重要的是Alfresco支持组织模型，能够提供在组织结构内进行不同层次之间的流程导航。

• Activiti Modeler—建模器

基于开源Signavio Web流程编辑器的一个定制版本，提供了对BPMN2.0图形化规范的支持，建模后的流程以文件格式进行存储。

• Activiti Designer—Eclipse插件形式的建模器
• Activiti probe—管理及监控组件

对流程引擎运行期实例提供管理及监控的Web控制台。包含部署的管理、流程定义的管理、数据库表的检视、日志查看、事务的平均执行时间、失败多次的工作等功能。

• Activiti Explorer—任务管理组件

提供任务管理功能和对案例、任务基于历史数据的统计分析（报表）功能。Web应用程序。

内容存储工具：包括了文档仓库、模型仓库、SVN仓库、MVN仓库和Activiti引擎。其中文档仓库、SVN仓库和MVN仓库三个组件为协作工具（Activiti Cycle）提供底层的支撑。Activiti引擎则是以前的PVM。

协作工具：与jBPM4相比，Activiti5最令人瞩目的特性就在于它的协作工具组件。

Activiti Cycle完全是一种新类型的BPM组件。它是一个用来促进业务人员、开发人员和IT运营人员协作的Web应用程序。 在现实的场景中，业务文档有业务人员所持有，而软件程序由开发团队所管理，被部署的软件应用则被IT管理人员所管理。三者之间不能很好的协作。我们可以想 象这样一个场景，业务经理用文档来维护需求和visio格式的流程图，开发人员管理可执行的流程和大量的Java源文件而IT维护人员则管理部署在 Tomcat中的.war文件和存储在Activiti数据库中的流程。

图 6：Activiti cycle协作组件逻辑示意图

Activiti Cycle通过BusinessLink将与流程相关的业务人员、开发团队与IT维护人员关联起来，实现他们之间的协作。

总而言之，与jBPM4相比，Activiti5目前最重要的增强就是实现了流程的可视化以及创新的Activiti Cycle协作组件，此外，通过与Mule的集成加强了其集成能力。其对PVM的保留使其继承了jBPM4强大的可扩展能力，对jBPM的老用户来说，这是向其迁移的重要理由。

七、总结

jBPM3是一个完整的工作流系统实现，面向开发人员，目的在于简化对组织核心流程进行支撑的软件创建，不支持标准。

jBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。

jBPM5基于原先的Drools Flow，支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM，引擎的可扩展性受到损害，并且不再支持jPDL。

Activiti5基于jBPM4，与Alfresco的集成增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，最后，它加强了集成能力。

对于工作流应用或者jBPM3、jBPM4的老用户，建议转向Activiti5。

关于作者

荣浩，ThoughtWorks咨询师，关注敏捷和企业流程改进过程，目前正与辛鹏合著《Head First Process-深入浅出IT流程》一书。博客地址http://ronghao.javaeye.com。

转自：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5

有很多理由都能说明为什么我们应该写出清晰、可读性好的程序。最重要的一点，程序你只写一次，但以后会无数次的阅读。当你第二天回头来看你的代码 时，你就要开始阅读它了。当你把代码拿给其他人看时，他必须阅读你的代码。因此，在编写时多花一点时间，你会在阅读它时节省大量的时间。

让我们看一些基本的编程技巧：

1. 尽量保持方法简短
2. 永远永远不要把同一个变量用于多个不同的目的
3. 使用自描述的变量名和方法名
4. 尽可能的把变量定义在靠近使用它的地方
5. 拒绝神秘数字
6. 友好的对待你的语言
7. 不要逆常规而行
8. 警惕过早优化
9. 积极重构测试过的程序
10. 不要过度沉迷于技巧
11. 通过习例学习新知

现在，让我们把每个小点展开来详细讲一下。

1. 尽量保持方法简短

尽管很多人都遵循这个规则，但它仍然非常的重要。你写的方法要始终能在一个屏幕里放得下。如果你需要去滚动屏幕，这会分散你的注意力，而且你看不到 整个的上下文。最佳长度是5-20行，这根据你的情况而定。当然，getters/setters 通常是一行代码的方法，但与其说它们是真正的方法，不如说它们只是存取工具。

2. 永远永远不要把同一个变量用于多个不同的目的

一个变量应该始终只为一个目的服务。通过使变量常量化(C++里的const， Java里的final)，使得编译器能够优化编译，而且使你的代码醒目表达这个变量是不能改变的，你的程序的可读性会变得更好。

3. 使用自描述的变量名和方法名

你的代码应该，对于任何人来说，只要看一眼就能知道是干嘛的。尽量不要用简写方式，除非有特殊的习惯，就像下面的：

 src - source
 pos - position
 prev - previous

如果你认为描述性的名称并不是那么有价值，请对比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。

4. 尽可能的把变量定义在靠近使用它的地方

盖房子时，你可不希望把锤子放到别人的院子里。你希望把它们放的离手头越近越好。定义变量也是同样的道理。

int foo = 3;
int bar = 5;
// 一大段使用“bar”的代码，
// 但没用到“foo”
// ...

baz(foo);

这段代码可以简单的重构成

int bar = 5;
// 一大段使用“bar”的代码，
// 但没用到“foo”
// ...

int foo = 3;
baz(foo);

当你把变量的声明和第一次用到它的地方间隔太远时(距离超过一个屏幕)，这确实会成为一个问题。记住上下文关系会变得困难，你需要滚动屏幕去找哪来的这个变量。

5. 拒绝神秘数字

当你要把什么东西跟一个常量值做比较时，记得把这个值定义成常量。没有什么会比去猜测你的同事写的这样的代码更让人头疼的事了：

il < 4384

换个形式感觉如何？

inputLength < MAX_INPUT_LENGTH

6. 友好的对待你的语言

学习新语言是一种很有乐趣的事情，你能学到一种新的完成任务的途径。当一个对一种语言已经很专业的人去学习另一种语言时，会出现一种很大的负面效应。比如说你是一个Java开发者，试图去学习Ruby。你应该学会用Ruby的方式解决问题，而不是沿用Java的解决问题的思想。

当你需要重复5遍”Hello world！“时，在Java里，你可能会这样做：

for (int i = 0; i < 5; i++) {
    System.out.println("Hello world!");
}

在Ruby里，你也许会禁不住这样写：

for i in (0..5)
  puts "Hello world!"
end

这样看起来没问题，但有一个更好的方式：

5.times { puts "Hello world!" }

7. 不要逆常规而行

每种语言都有自己不同的习俗约定。一般来说，人们听的最多的是Java的编码规范。让我们看看其中的一些习俗规范：

• 方法名应该小写字母开头，其后用字母大写的单词连接(veryLongVariableName)
• 类名应该都使用首字母大写的单词连接而成
• 常量名应该全部大写，用下划线连接(MY_CONSTANT)
• 左大括号应该跟 if 语句在同一行

只有在有必要的理由时才去打破这些常规，不要轻易的因为你不高兴就违反它。如果你只是在团队里改变一些这样的习惯，那也没问题，但当把你代码拿出来和其他的没有这些思想准备的程序员共享时，问题就会来了。

8. 警惕过早优化

过早优化是所有问题的根源，至少电视上是这么说的 … 你第一应该关心的事情是写出易于理解的代码。起初写的程序不要求快。除非你的程序很慢，否则谈优化都是为时太早。如果你想优化什么东西，你首先需要知道问题出在哪。这就是我们需要profilers这个工具的原因。

在没有知道问题在哪的情况下试图对程序进行优化，其结果必然是把程序能坏，至少你的代码会丧失可读性。如果你觉得有些地方很慢，不要盲目的重写代码，你应先找到慢的证据。

不要傻乎乎的去解决根本不存在的问题。

9. 积极重构测试过的程序

没有任何东西会是完美的。即使你感觉你真正写出了一段完美的代码，几个月后回头再看看，你可能会惊讶道”怎么会这样傻？“

改进程序的一个好方法就是重构，但要等程序测试通过之后。你首先要确保程序是好的可运行的，你可以通过自动化测试或手工测试完成这个工作。

之初，你需要的是程序可用。不要期望在第一次就写出完美的程序，你只需要把它写出来，可用。然后重构它，使之完美。对于你们当中知道测试驱动开发 (TDD)的人来说，对这个会很熟悉。这里的关键就在于你要习惯于重构这种事情。如果你使用的是像IntelliJ IDEA这样强大的集成开发工具的话，重构的工作会变得简单的多。

重构之后，你也许会弄出一些Bug，导致某些功能出问题。这就是为什么说写自动化测试的原因。不论何时重构后，只要运行一下所有的测试用例，你就能准确的知道什么地方出了问题。

10. 不要过度沉迷于技巧

当我第一次读到有关设计模式的知识时，我觉得我找到了圣杯。这些精心设计的思想作用显著，它能使你的设计易于理解，因为你可以简单的说”我使用的是 ‘观察器模式’“，而不用从头到尾的解释一遍。那么，有问题吗？一切看起来都这么自然、简单，你开始不论在哪都使用设计模式。为什么不把这个类做成 singleton呢？干嘛不去再创建一些工厂类呢？

于是一个80行就能写完的脚本，你最终使用了10个类，15个接口，外加一大堆范式和标记符。97%的代码不做任何事情。设计模式是一种十分有用的用来简化你的设计的工具，但这不意味着你该在所有能用到的地方都用它。你应该用它们，但不能滥用。

11. 通过习例学习新知

编程是一种学习新知的过程。当你学到了新的程序库或新语言，你可能会迫不及待的丢掉旧的代码，用你新学到的东西重新写一遍。有很多的理由都能说明你不该这么做。

往现有的应用里增加新的类库或框架同属于这种情况。就说你写了一个Javascript的web应用，期间，你发现了jQuery。现在你突然急切的想丢到你的Javascript程序，重新用jQuery写，尽管你还从来没用过它。

最好的方式是你先用jQuery写一些简单的例子，通过这种方式把你在应用里将要用到的知识都学会。需要AJAX？在你的项目之外做一些小例子，当完全弄懂了后，丢掉例子，应用到你的产品里。

如果你非常关注编程技术，我强烈的推荐你阅读Steve McConnell写的 《代码大全》 一书。它会永远的改变你对编程的认识。:)

[英文出处]：11 tips for better code

[译文来源]：外刊IT评论