上周末 Revision demoparty 结束,其中 64K Intro 项目是利用扩展和压缩技术极限发挥，完成一个小于64K的单可执行文件的展示程序。实时渲染动画，声音、3D模型和纹理。

第一名是 Approximate 开发的 Gaia Machina，第二名是 Ctrl-Alt-Test 的 F – Felix’s Workshop，第三名是 rez/Razor 1911的The Scene Is Dead。
第一名视频：

第二名视频：

第三名视频：

北京时间4月17日消息，据国外媒体报道，甲骨文律师迈克尔·雅各布(Michael Jacobs)今天在位于旧金山的美国联邦地方法院作开庭陈述时表示，Google早在2005年就知道，开发Android移动操作系统必须许可Java技术，Google之所以没有许可Java，原因是它不想共享 Android。

雅各布说，使用Java确保Android迅速获得了移动应用开发商的青睐，使Google获得了商业利益。雅各布在开庭陈述中表 示，Google的问题在于，没有获得允许其使用Java，并要求其共享Android的许可，“企业不能因为有好的创意就随意使用其他公司的知识产权。 Google利用Android获得大量收入，其中一部分理应归甲骨文所有”。

甲骨文诉称Google侵犯了Java专利和版权。预计该案庭审将持续8周，出庭作证的将包括甲骨文CEO拉里·埃里森(Larry Ellison)和Google CEO拉里·佩奇(Larry Page)，以及由双方和主审法官指定的损害评估专家。

甲骨文要求Google赔偿10亿美元经济损失，要求法院责令Google除非获得许可，否则停止继续发行Android。

Google否认侵犯了甲骨文的专利，称其使用的名为API(应用编程接口)的技术不属于版权的范畴，对Java平台部分组件的使用是合理、合法的。 Google律师罗伯特·冯内斯特(Robert Van Nest)在向法院提交的一份文件中说，“计算机编程语言以及甲骨文的API不具有版权。甲骨 文指控Google完成与甲骨文API相同的功能侵犯版权，这是声称对创意而非表达拥有版权的典型案例。”

Google律师将于明天作开庭陈述。

冯内斯特去年在一次听证会上表示，Google曾拒绝Sun在2006年提出的在Android开发中使用Java需交纳1亿美元许可费的建议，Sun的建议不仅仅包括许可费，还包括双方联合开发Android。

Google依靠Android在智能手机和平板电脑市场上与苹果竞争，削弱对传统互联网搜索的依赖程度。

甲骨文还诉称Google侵犯了两项Java专利。法庭指定的专家估计，Google的侵权行为给甲骨文造成了280万美元的损失。

法庭驳回了甲骨文要求的61亿美元赔偿请求，称损害估计应当以1亿美元为基础。

文/搜狐IT

【搜狐IT消息】4月17日消息，网易抄袭大众点评事件有了新的进展。据大众点评发来数据显示：大众点评通过北上广三大城市6000家抽样商户的数据比对， 网易“饭饭”上的商户数据与大众点评上的商户数据（包含推荐菜等大众点评独家信息）信息重合度高达97%以上。

而网易有道运营副总裁金磊接受媒体采访时也承认“抓取”了大众点评的数据，但却未表示要停止该行为，与网易只因外观和设计等问题大张旗鼓谴责腾讯抄袭其新闻客户端相比，网易呈现出矛盾的两面。

大众点评资深副总裁龙伟表示，这些商户数据并不是普通意义上的公开数据。以商户“推荐菜”为例，大众点评上的商户“推荐菜”并不是商户提供的固 定信息，而是从上百个可供选择的菜中，通过大众点评超过4200万活跃用户投票，用统计学的原理获得的十几个推荐菜，是该商户真正意义上的“推荐菜”，这 种极具参考价值的内容，不是任何网站、任何人都能轻易收集、复制出来的。

面试过一些应聘者，当我问到为什么换工作的时候，他们都会告诉我，现在的工作没有挑战，无聊，所以想换一个有挑战的工作。我总是为有这样的认识的朋友感到惋惜，因为我总是认为有挑战的东西无处不在啊，不能因为工作上没有，自己就放纵了自己。比如，面试过一个做地图的工程师，他的工作是做计算地图上任意两点的最短或最优路径的一部分功能。我觉得这个事很有挑战，也有难度，应聘者说，没什么挑战，因为他做的东西只是调用相关的算法库。他在这个项目干了2年了，当我问他有没有看过算法库，知不知道地图是怎么存储的？他却告诉我，因为没有去做，所以就没有去了解，等做的时候再了解（我希望有这样想法的人都去看看程序员的谎谬之言还是至理名言？）。这样的例子很多，很多应聘者在面试中不能和我一起解决某个问题的时候，比如：OOD，数据库设计，系统设计，等，他们都会告诉我，不好意思，因为没有做过相关的事情，所以就不懂了，所以，他需要一个像我们这样的项目来学习和锻炼。

但另外一方面，他们都会告诉我他们对技术充满和热情和兴趣，有着很强的学习能力，也有很能吃苦的态度。这也许是某面试宝典上看来的，面经上可能都会说，如果面对不能作答问题，可以说一下自己的态度和决心。可惜的是，我并不这么想的，我在我的两篇关于招聘的文章里（我是怎么招聘程序员的，再谈我是怎么招聘程序员的）都说过一些我对如何择人的想法。这里重点说明一下其中两个观点：

• 关于热情和态度，说白了就是不要给自己找借口。比如：“工作忙事多没时间学所以可以不懂”，“工作中没用到所以可以不懂”，“工作没有挑战，一直没有遇到合适的项目”等等。时间可以挤，工作之余可以学，随时随地去思考，挑战是无处不在的…… 想想那些你有热情的事，你会发现，几乎没有什么可以阻止你去做那些事。

• 对于某些事情，如果以前没有在你身上发生过，那么这个事情在未来也不会发生。如果你以前没有对你接触过的东西去学习，去深挖，去思考，去改善，那么我不会相信你会在未来面对新的东西的时候也会有这样的态度；如果你以前没有用业余时间学习一些项目之外的东西，那么我也不会相信你会在未来会这样做；如果你以前没有把你的热情和态度转换成你的知识，经验和成果，那么我也不会相信你会在未来能做到。

这两个观点可能太刻薄了，但是，当我回想我自己的经历的时候，观察程序员的成长过程的时候，我发现，优秀的程序员都是相似的，当他们还在是一个菜鸟的时候，就已经有各种成为高手的苗头了，这些苗头就是——他们热爱思考，喜欢解决难题，对新鲜事物非常好奇，总是找人讨论，可以用自己的业余时间狠命研究很多和工作无关的技术，会在业余的时间里写些有趣的小程序，或是会把自己的思路书写下来，等等，等等。

一些问题

我这样说，大家可能会觉得“挑战无处不在”这句话太虚了，而且可能不明白什么叫“热爱思考”，这里，我把我的或别人的思考的东西罗列一下，这些问题，有的会让我思考推敲，有的会让我疯狂地查资料，问人，或是找人讨论，询问。大家不妨可以跟着我一起思考一下。

酷壳上有一些小问题，比如：火车运煤问题，赛马问题，这些问题都不够实际，我觉得也这些问题有点无聊，我们不妨观察一下我们身边的东西，我们就可以看到很多有挑的战的东西，对于这些问题，如果是你来做，你会怎么做呢？

0）许多年前，当我看到珊瑚虫QQ把IP转成地实际地址的时候，我就在思考，如果我有一个IP网段的数据（全球IP地址数据），我怎么来完成这个功能呢？比如：某地点的IP网段是：10.10.1.* – 10.10.5.*。我要有一个IP地址是：10.10.3.20，我怎么匹配这个网段？用Hash表吗？好像有问题。把IP字串转成整型？排序+二分法，好像更容易解决一些，但是如果有一些修改的话好像有点不方便。用树型结构（森林）会不会更好一些呢？如果我要通过地点反查IP段呢？

1）网上短网址服务，你有想过这个短网址生成的算法是什么，如何能做到能最短？怎么查询？你也许觉得会用key-value的NoSQL。那么，如果对于同一个URL，如果要重用已生成的短网址，你怎么用key-value的NoSQL来解决？

英汉词典的检索和这个很相似，如果通过英文查汉语，又通过汉语查英文？如果是N多种语言的互相翻译呢？你的数据存储和检索如何做呢？

2）当我看到Dropbox这样的云同步的软件的时候，我不知道你是否会和我一样会去思考，在多个设备间的文件同步是怎么做的？如果网盘上有几万，甚至几百万个文件，当要和我的本地数据同步时，他如何比较经济地知道哪些文件更改了？需要向服务端同步或是向客户端同步。更进一步，你有没有想过没有中心结点的文件同步问题？你有没有想过，文件冲突的问题？

3）我们的新员工入职的时候，有一些公司会给新员工的帐号生成一个随机口令，然后新员工可以在登录后修改口令（我一直在想我们的银行应该为用户生成一个随机口令，而不是设置一个6个0或是6个8的初始口令）。那么，对生成随机安全口令的算法知道怎么做吗？如果你写出这个算法来了，你怎么证明这个算法是足够随机，生成的密码强度足够大的？（你会发现，测试口令是否随机是否安全的程序，会比生成器更难写）

4）关于动态密码RSA SecurID（如下图），这个小设备上的6位数字会每60秒变一次，在你登录的时候，需要输入这6位数字，服务器上会认证这6个数字，那么这个事怎么做？再试想一下，这样的小设备我要发给我的客户，我希望我的每个客户都使用不一样的随机算法，就算是算法一样，算法的种子也不能一样。那么，如果我的客户一共有百万甚至千万，我的服务端怎么管理这些用户的SecurID？

5）看看我们的网银或是ATM的用户登录功能，如果你登录时输错口令超过3次以上，你的帐号就会被冻结，需要去柜台重置口令。这个功能看上去很安全，因为可以防止黑客在线尝试破解你的登录口令。不过这又带来了另一个问题，如果有一个恶意用户知道你的卡号，他就上网或是造个卡故意输错你的口令，导致你的帐号被冻结，让你一次又一次地去银行排队重置。面对这样的情况，你该怎么解决？

6）当你在网上购物的时候，你会去一些电子商务的网站，这些网站都会对他们的产品进行分类，有大分类有子分类。你进到分类后，你可以通过不同的属性来过滤不同该分类下的商品，注意，不同分类下的商品的过滤属性不一样，如，手机分类和电视分类的属性都不一样。试问，你如何设计你的数据库表结构？

7）当你在泡各种论坛或SNS社区的时候，你会看到，用户在互相回复的时候存在一个问题，尤其是用户量很大的时候，大家的回复完全交织在一起什么 也看不清楚。以前有的论坛使用树形列表来解决这个问题，树形列表好是好，但是把一棵大树放在那里还是很难看。Twitter.com给了一个非常不错的解决方式，就是所有人的回复或是回复的回复都按时间线放在一起，如果你要查看某回复的上下文的话，点击一下这个回复就可以看到了（我在我在“国内微博和Twitter的最大不同”中批评过这个事）。新浪微博在禁评论事件后也开发出了这个功能。你知道这个事怎么做吗？

更进一步，新浪微博的设计上有很多的缺陷，单说新开发的“查看评论”功能这个事来说，还是不完美，因为某些评论会随着转发带到别的地方去，他的“查看评论”功能只能看到当个贴子下的东西，不能把所有转发出去的贴子的评论一起综合起来。虽然这对于用户使用来说没有什么在不了的，但是对于软件设计来说，我们不妨做一个练习，可以思考一下，怎么样设计会更好。

再举一反三，有时候，我发现多个网友会提出同样的问题，我很想用一个回复同时回复他们。如果有这样的功能的话，我们的回复就会从一个树形变成另外一种形状了，我们又该如何设计才能支持这样的功能呢？

8）说到新浪微博，我就想多说几句，我最近观察到了两个事：

• 一个是验证码的事，如果你在你的帐号设置里设置了“登录需要验证码”，你会发现，在登录新浪微博的时候，仅当你输对了口令后，系统才会提示你输入验证码。为什么呢？因为，这个“登录需要验证码”这绑定在你的帐号设置里的，所以，要取这个设置，就需要你登录成功（？！），老实说，这个功能在设计上有点二（中国特色）。如果是你，你怎么设计呢？

• 另一个事情是新浪微博或Twitter的用户名修改后，被他人@过的信息就再也链接不到你这里来了。我们来试想一下，如果是你，你怎么解决这个问题？（我的我的微博里讨论过这个事，不一定对，供大家参考）

9）我有时候我会发一些快递，有时候是一些小东西，有时候是一些大包裹，有时候近，有时候远。我发现一个有趣的现象，就是快递员来收件的时候，快递的价格都是快递员自己说了算的，我还可以和他们砍价。我观察到他们会以距离，重量大小来订价。于是我在想如果你要运营一个物流公司，你作为这个物流公司的程序员，你需要开发一个软件来标注快递价格，你会怎么做？比如，这个快递公司会说，在北京五环以内是一个价，以外是一个价，出省后，上海以北是一个价，上海以南是一个价，等等，这只是北京的，如果把全国的各个城市到别的城市的价格都考虑进来，还要受到重量，体积，价格，是否加急等等因素的影响，你的数据库设计要怎么做呢？

A）国内的水军太恐怖了。他们活动的刷排名，刷信用，刷积分，刷粉丝等等地方，你是否想过如何解决这个问题？还有广告联盟的欺诈问题，等等。这些东西，有的还是可以通过技术手段进行限制和计算的，你有思考过应该使用什么样的方法吗？

B）说到水军就不能不提垃圾邮件和垃圾短信。你有没有想过邮件系统怎么过滤垃圾信息的？

C）关于推荐功能，这必然是一个热点，这是软件产品从request -> response的被动方式到主动方式的进化。微博上有推荐关注者的功能，电商有推荐商品的功能，豆瓣上有推荐影片音乐书籍的功能。不同的领域的推荐算法各不相同，你有没有思考过，如果是你来做推荐算法的时候，你会怎么做吗？更进一步，推荐通常伴随着学习和匹配，学习用户的行为，匹配相似的东西，你想过怎么学习用户的行为，怎么匹配相似的东西了吗？

D）关于微博，某名人有几千万的粉丝，当这个名人发一个微博的时候，需要通知这几千万个粉丝，这个在系统架构上应该怎么做？如果某天这个名人与人发生口角，和人吵架，拼命的刷微博，那么，系统架构要怎么设计才能支持这样的事呢？

E）想想火车票的分段卖票的方式，现有的解决方案是为每个站点预留票，于是我们可以看到火车始发时，有很多空坐，这些空坐都是留给下一个站点的，我们能否开发出一个系统来，可以把一条线上的这些这站上那站下的旅客统筹规划一下，制定出一个最经济的方式，让火车运行得更有效。

F）对于地铁公交网络，我们希望这个网络既能有更多的覆盖，又能节省路线，你能不能设计出一个系统，当我们输入一些数据（如：站点，是否终点或起点站，该站的下一站可能方向（多个），该站是以上车为主，还是下车为主，等等），你的系统能自动安排出各种线路吗？

这样的问题实在是太多了，都是可以让我们去思考的，并不一定有经济效益，但是至少可以让你锻炼一下怎么去分析问题，怎么去思考，怎么去解决问题。

总结

综上所述，我想说的是：

1） 只要你想，挑战是无处不在的。那怕是你现有的觉得无聊的东西，只要你想做到极致，那怕是一个简单的功能（比如用户登录的功能）也会让你充满挑战。

2）观察身边的事物，去思考，去调查，举一反三，这才是你成长的源泉。不要把你的成长推给客观原因。

3）我的软件开发的三重门中说过，第三重门是解决实际问题，让你的业务处理更为的智能，更为地强大。我不知道为什么这一两年，我们的圈子里所有的人都在关注着“云”，“海量数据处理”，“高性能架构”这样的东西，尤其是那些性能调的高性能的东西并不很难，而这些更为实际问题更有挑战性，也更有前景。

（全文完）

根据定义，任务关键型产品的故障成本非常高。将敏捷方法应用到运行它们的软件和系统开发中，可帮助预防导致故障的缺陷。敏捷开发方法可提高产品品质、减低 成本、缩短面市时间和提高成果的可预测性。但是，您需要先对敏捷方法进行一定程度的微调，使它们适合这些复杂且严苛的项目。敏捷治理、动态规划、测试驱动 的开发、增量式开发和高效的风险管理，这些都是敏捷在任务关键型系统开发中成功应用的关键。

任务关键型系统和敏捷开发

任务关键型系统对人类安全具有重要的影响。这些系统的故障成本可能非常高，不仅会导致财务损失，还会造成伤害或死亡。针对他们严格和复杂的开发而应用和调整敏捷方法，有助于预防故障，改善质量，提供更可预测的成果，以及减少上市时间和成本。以下 5 大技巧可用于将敏捷性应用于任务关键型系统开发中。

技巧 1: 敏捷治理

敏捷治理在于通过避免常常纠缠着传统开发工作的不必要的阻碍，让一个环境中的开发团队可满足他们的目标。它的理念是，您和您的团队确定目标并将如何满足它们。但是，最重要的步骤是，首先真正制定决策来管理项目。然后，您需要理解您将衡量的对象、您将如何衡量它，以及您将如何应对这些衡量结果。

许多人管理着错误的事情，即那些容易衡量的事。敏捷并不在于容易；它在于做出了对于取得成功和避免失败有意义的事情。您需要决定与您的成功定义相关联的关键绩效指标 (KPI)，然后不断使用它们监控质量和完成进度。一个 KPI 可能是项目速度，它不仅表示您在时间上完成了多少工作，还表示这些工作具有多高的价值。拥有 KPI 后，您就可以使用它们驾驭项目。因此，进度的透明性和可视性至关重要。

技巧 2：动态规划

敏捷是一种严格、井然有序的系统和软件开发方法。作为一种瀑布式方法，这需要进行规划。但是区别在于，对于敏捷来说，规划是动态的。主要前提是 1) 规划必须基于改善的项目知识而不断调整，2) 您的计划只能跟您当前拥有的信息深度一样详细。敏捷治理提供了 “现场的真相”，您应该准备至少在每次迭代后进行调整，但常常会每星期或者甚至每天进行调整。您在工作的过程中将了解更多信息，而且该信息应该反馈回您的计划。

我还建议采取一种两级的动态规划方法。第一级是一个总体规划，主要基于为 4 至 6 星期所计划的一组迭代，每次迭代包含构建版本和在该构建版本上的直接测试。第二级是用于每个迭代的更详细的规划，或者这个月到一个半月内的进展情况的描述。在每个迭代结束时，您回顾已完成的工作并将其与计划进行对比。如果存在差异（也就是说，如果结果与计划没有准确匹配），那么返回调整计划以反映事实。

技巧 3：测试驱动的开发

从完成的软件中消除缺陷需要大量的工作，可能需要很高成本。事实上，研究已经表明，60% 的软件开发工作通常都花在测试和消除缺陷上。最好一开始就避免在产品中引入缺陷。为此，可以采用测试驱动的开发。采用测试驱动的开发，您可以不断地对软件进行编写和测试。您使用 20 – 60 分钟的微型周期，而且使用微型周期的一半时间来编写代码，另一半时间用于执行测试，以证明它有效。您所实施的项目类型决定了您的微型周期。例如，在我曾经研究的一个航天器项目中，微型周期平均时长为 20 分钟。结果得到的是质量高得多且缺陷少得多的代码，减少了在项目结束时测试项目的成本。

另一个敏捷最佳实践是使用持续集成 将团队的工作集中起来，通过使用所有组件的功能流证明集成的正确性。持续集成通常在整个项目上每日执行一次，但一些组织每星期执行一次。一般而言，您发现缺陷或集成问题越早，解决它们的成本就越低、工作就越轻松。在项目结束时，将没有出现任何集成问题，这些都是传统软件开发方法将分开开发的软件各部分集成 时经常会出现的问题。所以，缺陷的避免总比（事后）缺陷修复更好。

技巧 4：增量式开发

任务关键型系统的项目在本质上是困难和复杂的。因此，执行这些项目的最佳方式与我们解决所遇到的大项目时所采用的方式相同：将它们分解为更小的部分。将您的系统构建为一系列迭代（“冲刺”），每个迭代持续 4 – 6 星期。

每个迭代应该有一个任务陈述。目的在于履行其任务，它的任务主要专注于要实现的需求（通常通过用户案例或使用案例来采集），但也包括要支持的平台、要包含的架构概念、要缓解的风险和要修复的现有缺陷。验证和校验测试在每次迭代结束时执行。

对于我的项目，我们还在每个迭代结束时有一个 “聚会阶段”。一些人将此称为事后检查，但我将它作为对持续成功的庆功会，而不是确定故障问题的事后分析。我会查看任务陈述，确定我们满足该陈述的程度，寻找改善该流程的方式。我们总是会问我们还能如何做得更好、更快、更有效？

技巧 5：动态风险管理

风险是您在一个项目中不知道的所有事物。在我参与的 300 多个项目的经验中，忽略风险是任务关键型系统项目故障的首要原因。许多组织很少执行任何类型的风险规划，而曾经创建过风险计划的组织，从来没有回头查看它。这是针对灾难的一个处方。您在构建任务关键型系统时，必须关注风险。因此，您应该使用动态风险管理计划（也称为风险列表）来管理风险并频繁地更新它。

在风险列表或风险计划中，您会发现风险是一个两个值的函数，即您想要避免的成果的严重性和发生这一成果的几率。这两个值（严重性和几率）是对您可能跟踪的风险的定量测量。然后您再执行风险缓解活动，也称为 “spike”，这是一些减少风险的计划活动。因为不是所有风险都足够严重或能保证赢得特殊关注，风险缓解活动仅为超过一个阈值级别的风险而创建。当风险足够高时，就会规划一个风险缓解活动，它会变成一个计划的活动。

结束语

当恰当应用于任务关键型任务的开发时，敏捷方法可帮助避免高成本的故障。敏捷方法还可以提高这些系统的品质，减少应用它们所需的工作。敏捷方法将注意力放在风险上，如果忽略了风险，它们会成为故障的首要原因；敏捷方法还消除了同样会导致故障的静态、冲击式规划。尽管工具不像方法那么重要，但 IBM Rational 软件工具（比如 Rational Team Concert、Rational DOORS、Rational Rhapsody、Rational Quality Manager 等）以及 Jazz 有助于带来减少易于出错的流程，并改进规划所需的自动化和透明性。结合敏捷最佳实践，比如 Harmony 流程中的最佳实践，您会获得一个必将取得成功的开发组合。

文/IBM developerWorks