公司发了一个三星Note2，在设置中看到了一个很神奇的选项，NFC开关。于是兴趣上来了，准备尝试一下。设置界面如下图：

传说篇

在网上搜索了一些文章，写得都不是很清楚，当时抱着可以自制门卡，在地铁站刷手机的美好憧憬，开始了折腾。首先，门卡、公交卡之类的东西，是可以读取出来的。但是搞不清应该如何将手机设置成‘卡模式’，所以刷手机的尝试失败了。据网上说，可以将NFC手机模拟成卡模式，然后直接在一些NFC交易设备上进行交易。招商银行推出了手机银行，里面列出的手机硬件支持列表，就包括Note2。招行的政策好像是开设一个特殊的账号，捆绑在手机上，这个账号里面最多可以存放1000元钱，花完了，再往里面补充。网上也有一些台湾的朋友写博客阐述，要想实现卡模式，就必须要使用特定的软件来支持，不同的软件实现的卡模式，可以替代不同的卡来使用。电信好像还销售过带有NFC功能的sim卡，配合特定的手机，可以进行电子支付，不过本人使用的是联通的卡，联通好像也没有此类sim卡，所以无从证实。

希望破灭篇

到淘宝上购买了一堆NFC标签，价格是4.5元一个。购买的时候，询问卖家，这种卡是不是可以作为公交卡或工卡、门禁卡来使用，对方语言非常模糊，大致意思就是他只管卖，买家用这个卡去做什么，他不负责任，一切皆有可能。下图就是我购买的标签，一共20个，有些已经送给同事了，4个花色，正面有“安卓小人”、“睡觉的安卓小人”、“开车的安卓小人”、“在家的安卓小人”，背面都写着NFC。

迫不及待的开始尝试，一开始使用的软件是NFC ReTag Free，将门禁卡读取出来，写入NFC标签中。第一次写入的时候失败了，好像NFC标签是需要格式化的，否则无法写入。应该是NFC标签有很多种预设的格式，每种软件所对应的数据存取方式都不尽相同。我用自己制作的NFC门禁卡去尝试了一下，无法把门刷开。我想这应该是门禁卡中的数据格式，和软件提供的不兼容吧。公交卡也复制了，但是既然门卡都无法工作，我也就没有再去尝试了，毕竟这么做是有一定的风险性的。虽然本人并不想去赚公交公司的便宜，仅仅是希望能够将生活变得稍微简单有趣一些。不过这种事情，有时候解释起来还是很麻烦的。

如果有人能够将NFC卡里面的一些信息破解掉，应该是可以复制门禁卡和公交卡的，不过这种软件，在Google Play市场上应该是找不到的，他们应该是使用的PC上的NFC读写卡器来做类似的工作。这方面的尝试，没有进行下去的必要了，还是看看手机到底能够用NFC卡做些什么事情吧。

尝试篇

首先去下载一个软件，NFC Task Launcher，上文中的NFC ReTag Free的功能也差不多。但是，本人对于免费和收费版本这种事情，感觉不是很爽，所以决定换一种软件来对我的尝试过程进行说明。其实两种软件我都尝试了。NFC Task Launcher软件打开了，长得就是下面这个样子。

图标就是第三行的最后一个，这个应用的开发商同时还在销售印有同样图标的NFC标签。

第一次进入应用的时候，程序会询问你是不是要购买标签。估计这个免费应用的主要收入来源就是销售标签了吧。在刷标签的时候，状态栏也会显示这个图标的。

NFC手机的后盖打开，里面是有天线的。后盖上那两个黄铜触点，手机上相应位置也有两个触点。盖子上有一块颜色稍微不太一样的区域，就是NFC天线了。

折腾篇

进入NFC Task Launcher软件之后，选择我已经有标签了，不需要再购买标签，就可以进入一个示范标签的页面。里面有一些做好的样板标签：汽车——打开蓝牙，打开地图应用；办公室——关闭铃声，打开wifi；家——打开铃声，打开wifi；床头——静音，设定闹钟，等等。

我尝试着点击了一下汽车模式，蓝牙打开，那个要打开App的地方，弹出一个列表，让我去选择一个所需要的应用，我选择的是高德地图。我开车的时候最常用的免费导航工具。

向右滑动屏幕，可以见到My Tags的页面。在这个页面中，是我们存放各种标签。最开始，这个页面肯定是空的，可以点击右上角的加号创建新标签，创建方式有三个：1、创建新标签；2、从现有标签中导入（必须是使用同一个应用创建的标签才能导入）；3、使用Tagstand Writer程序，写一些标准信息，例如一个网址，一张名片之类的信息进去，然后作为新标签来使用。

新建的标签，里面是空的，可以往里面添加特定的动作，我将以前做的两个标签导入进去，就是下面这个样子了。本人会数数，之所以两个标签导入进去，显示了三个不同的Tag，那是因为同一个物理标签中是可以存储两套动作的，每次刷卡的时候交替做不同的动作，比如同一个标签，第一次刷是打开wifi，第二次就是关闭wifi。

有了标签，下一件事情就是往里面添加动作了。

选择添加actions之后，会出现一个很长的动作选择列表。

展开其中的无线与网络目录，里面有很多具体的动作。在这个地方选择自己需要的内容（多选）。其他动作这里就不一一介绍了，大家自己尝试。

点击下一步之后，进入具体的设置界面。上一页选择的东西越多，这个设置页就越长。这其中所有涉及打开关闭的项目，都有三个选项，分别是允许、不允许和反转，前面两个选项的意思比较明确，反转的意思就是原来的状态如果是开，就关掉；原来的状态如果是关，就打开。

设置完成之后，左上角有一个钩，打钩之后，确认这个标签的所有动作，下一步才可以写入。这个地方还可以调整动作的顺序或删除动作，已经设定的动作好像在这个版本中是不能修改的。

这个时候如果向←滑动屏幕，就会看到任务2的选项页面。上面说了，每个标签中可以存储两套不同的动作，第二套动作，就是在这里设定的。

点击添加任务之后，出现一个对话框，可以直接选择已经设置好的标签，也可以新建一个。

对于一个打开并连接wifi的标签，那么再刷一次的动作就应该是关闭wifi，打开移动数据传输了。

一切准备就绪，如下图所示，右上角有一个钩，标题是保存和写入。点一下这个按钮。

会看到下面这个界面，提示将需要写的标签放在手机后面。那个将标签写成只读标签的选项，建议大家谨慎使用。

写标签成功之后，会出现下图上的提示，告知你标签已经可用了。

这种标签，在手机锁屏的状态、待机的状态都是不工作的，必须在开机，并处于活跃的状态下才可以工作，这应该也算是一种保护措施了吧。手机是不会在机主不知情的情况下，去完成任何NFC动作的。如果手机没有安装相应软件，则会提示安装。我使用的是google play，其他没有google play的朋友可能要费些劲了。软件安装成功之后，再次刷标签，就能够完成预设的动作，再刷一次，将上文中提到的task2中的动作做一编。由于本文中的标签是使用NFC Task Launcher制作的，所以刷标签的时候，提示安装这个软件，如果是使用其他应用制作的标签，也会提示安装相应的软件。上文中提到的NFC ReTag Free，其主要目标是让用户回收使用那些废弃的旧NFC卡，比如门禁卡、公交卡等，其他功能本文中介绍的软件基本一致，就不再详细阐述了。

总结

二维条码包容天地

二维码，最近随着O2O一起热起来的，这种古老的东西，焕发了青春。

普通的条码，里面包含的信息相对比较简单，仅仅是一串数字。二维条码，则可以包含很多各种各样的信息。当然，这些信息也不是无限制的，信息越多，二维条码就越复杂。也就是说，内容越多，二维条码里面的那些东西，就越细密，要想拍摄清并识别这种二维条码，对于印刷或显示二维条码的设备的分辨率和拍摄二维条码的设备的分辨率都有更严格的要求。

我曾经做过测试，如果二维条码中只包含一个短网址，在1.5厘米见方的一块面积里面，使用喷墨打印机和普通纸张，就可以识别了。如果再包含一些日历信息，在原来的面积里面，就必须要使用激光打印机了。
所以，不要在二维条码中放置太多信息，否则会给传播和读取带来很大的困难。当用户拍摄了二维码之后，其实需要做两件事，第一、确认动作，打底要用什么服务或应用来解析这个二维码中所包含的信息；第二、信息本身，比如一个短网址，或一些相关的其他数据和信息。

这里面就有了一个问题，用户扫描了二维条码之后，是不是通常要连接网络？如果大部分内容都不需要连接网络就可以完整工作，那么就要想办法将尽可能多的信息塞进条码里面。如果通常用户扫描条码的时候，都是已经做好了连接网络的准备，那么就可以将尽可能多的信息放在服务器上，条码中仅仅记录一个短网址就好了。从现在的二维码使用习惯上来看，大部分人拿出手机准备拍摄二维码的时候，其实是做好了连接网络的心理准备的。
这就引申出两个问题，第一，我们的二维码包含的信息是不是太多了？第二，是不是二维码必须要放在可以免费使用wifi的地方，才能搞吸引更多的人来拍摄？

条码无处不在

现在，我们可以在地铁、公交、大街上、商场里、名片上看到条码，特别是二维条码。我经常会举出手机来尝试拍摄和识别这些条码。不幸的是，即使我的手机摄像头分辨率已经达到了800万像素，但是经常无法识别出条码里面的信息。地铁中，站台广告将一个二维码印在了一个角上，如果站在站台上，隔着铁轨，是肯定拍不清的。如果站在车厢里，只有正好是车门对着条码的时候，站在车门处的那个人才能够从合适的距离成功拍摄。有些广告上的条码由于印刷位置太低，没法从车门的位置露出来。有时候条码是出现在座位上方的，但是由于座位上的人是背对车窗的，而站在旁边的人，估计距离又不合适了，也无法被拍照。
这都是怎样的纠结啊。在上海地铁站里面见过一个手表的广告，是在检票口附近，吊在屋顶上，上面有一个二维码，我举着手机，垫着脚尖儿废了半天劲，还是没有识别出来。估计这个条码是给姚明专门设置的，提醒一下本人，姚明也是上海人的。

条码与交互

现在那些在自己的广告中添加条码的商家，他们考虑过用户交互吗？肯定考虑了，而且至少应该比那些没有条码的广告，考虑得更多一些。他们大多在考虑的是用户拍摄了条码之后的一些事情，如何登陆网站，如何注册信息等等。他们也考虑了最原始的问题，用户为什么要拍摄这些条码，比如去领一个优惠券什么的。但是他们肯定没有去考虑，用户是不是能够拍到这个条码，摆放条码的地方是否合适。北京地铁一些不同线路的换乘通道里面，特别是一些人流拥挤的楼梯边上，就有商家刷上了广告，并在广告里面嵌入和二维条码。如果真有人胆敢停下脚步去拍摄那个条码，那么结果比如是发生惨不忍睹的踩踏。还好广大人民群众还没有将自己的智商降低到无良商家的水平。顺带说一句，那个条码的位置，就算是姚明也是够不着的。

条码距离我到底有多远

距离一

无处不在的免费网络，让大部分用户都习惯性的全时在线。这肯定是二维码需要突破的第一道管卡。用户需要能够在有wifi网络的地方自动化的登上去，现在的wifi，大部分需要密码，登陆和使用起来非常麻烦。以机场、火车站、以及各个运营商的wifi网络最麻烦。
这呼唤一种可以让手机自动登陆各种wifi的方法，解决方法有两个，第一个是有运营商级别的家伙愿意为大家提供更加方便的wifi接入方式，然后通过广告或其他方式盈利，让用户可以使用免费的wifi资源。第二种则是类似于wifi万能钥匙之类的应用让用户的手机自动登陆到身边的wifi节点上。

距离二

更好的用户行为和体验分析与设计。至少不要将二维码放在那些容易发生踩踏的地方。目前那些二维码广告投放的地点，应该是按照人流量来标示价格的，人流量越大的地方，价格越高。这其实是不对的，很多人流量很大的地方，并不适合大家停下来拍摄二维码。二维码广告的理想位置，应该是那种人流量相对比较大，但人群相对静止的地方，比如放在地铁的候车区，而不是放在地铁的换乘通道里面。确保每一个放置的二维码，都能够有目标人群站在面前几分钟，如果是这些人站在那里正好非常无聊，那就更好了。人流量过大，其实也是不适合放二维码广告的，拍摄人和二维码之间必须有一个合适的距离，当人群的密度过大的时候，这个距离就消失了。所以在计算二维码广告位置价格的时候，以地铁为例，高峰时间段的人流量是要打折扣的。当目标人群静止时，一个二维码广告可以被多少人拍到，拍摄的位置是不是需要弯腰或垫脚尖等等，这些应该都是二维码放置时所需要考量的范围。二维码拍摄之后的动作设计，也需要仔细斟酌，到底要达到一个什么目标，需要用户投入多少成本，这里的成本指的并不是钱，而是用户需要进行多么复杂的操作，占用用户多少连续的时间，以及多少后续非连续的时间。用户能够从中得到些什么，优惠、资讯，还是娱乐？

距离三

用户拍摄二维码的合适距离。这其实是上一个距离的衍生问题，都是属于缺乏合适的应用场景。就像我在前面展示的那些地铁里面的照片一样，站在车厢里面的某个特定的位置，可以拍摄到。而且，条件异常苛刻，每次只能有一到两个人处在一枚二维码的最佳拍摄位置。大量的人群无法在不经意间拍摄到广告。这需要一个新的二维码拍摄应用来解决相关问题。目前的二维码拍摄应用，都是将摄像头设置到近景模式，然后要求二维码占据取景框面积的70%以上，才可以进行识别。其实对于现在的智能手机来说，配置500万、800万甚至上千万像素的摄像头，还可以进行特定点的对焦，完全可以在更宽泛的距离上对二维码进行拍摄和识别。在照片中识别二维码，应该比识别人脸要更容易一些吧，手机可以在人脸只占取景器面积不到10%的时候，将其识别出来，并对人脸进行对焦，按道理来说完全可以对出现在照片中的二维码做同样的事情。这样的话，二维码的可被拍摄的距离和范围就能够得以扩大，如果再配合一些多图像叠加所带来的图像增强手段，这个范围应该还可以得到进一步的扩大。原来只有一两个人能够拍摄到的二维码，在识别应用改进之后，应该可以被更大范围内的更多人拍摄到。这里面还有另外一个问题，那就是二维码中所包含的内容不能太多，包含内容越多，二维码的复杂度就越高，对拍摄距离的要求也就越严格。

总结

二维码是一种能够承载全新商业模式的革命性技术进步，虽然现在二维码越来越受到重视，但是二维码距离我们还有着很大的距离。目前合理的二维码应用场景应该是：有免费的wifi覆盖，人群相对静止，人群密度相对适中的环境。二维码内包含的信息不宜过多，二维码相关的应用场景还需要进一步的研究。二维码拍摄的应用也还有很大的提高空间。

最后附上本站的二维码。

自从开始看网络小说之后，真的是很长事件没有读过纸质书了。对于那些大部头的东西，看着都觉得头疼。
最近，图灵出版社的谢工和我们联系，他们要借用盛大创新院北京office的会议室来做读者活动，根据计划，第一次读者活动应该是在6月份吧。作为答谢，图灵出版社送给我们一批图书。其中有一本《简约至上》，非常薄的一本书，印刷非常精美，每一页，都是左侧文字，右侧图片。文字的部分看起来十分简洁，很多地方看起来更像是一些提纲或目录的样子。

由于工作的原因，看了不少的应用，也看到了不少的设想或应用的雏形。对于很多和设计、用户体验方面的东西，也有了一点点模模糊糊的想法。看了这本书之后，感觉再看身边正在开发的一些应用的时候，好像能够看得更加清晰一些了。

 
该书首先讲解了为什么要进行简约的设计，这里面我看了感觉印象比较深刻的有两点。第一就是用户分类，大部分用户是典型用户，他们没有时间去研究各种复杂的功能；而那些提出最多意见的往往是精英用户，这些用户的意见往往是最应该被忽略的。另外一点，就是要到用户使用软件的现场环境中去观察用户的行为，用户的使用环境通常是很嘈杂的，很多软件是必须挤占用户的碎片时间来为用户提供服务。
这些东西，现在听起来好像是很有道理的。但是，有一点很重要，真理都是有其适用环境的，当真理脱离了其适用环境之后，就不再是真理了。简约的设计，是在近几年特别流行的一个词，这其实是随着移动互联网应用，特别是IPhone应用广受好评之后才开始流行起来的。简约设计应该是非常适合现在以普通大众为目标用户群体的互联网，以及移动互联网应用的设计。对于那些传统软件，或者我们平时所说的行业软件来说，上面那两个点就不能够完全成立了，对于行业软件来说，使用人群都是经过培训的员工，他们通常是坐在办公室里面来使用这些软件的。行业软件应该也是需要简约设计的，但简化的方向和力度肯定和那些面向普通大众的应用是有所差异的。书中也举了一个汽车销售软件的例子，由于销售经理经常需要冲出办公室，去为那些想要买汽车的用户进行解说，所以他们的工作经常被打断。这应该是行业软件中一个非常特殊、非常极端的特例吧。

在介绍了为什么要进行简约设计之后，作者介绍了四种进行简约设计的方法。分别是删除、组织、隐藏和转移。其中删除讲得最为详细，将不太需要的东西删掉。这一部分主要讲的是如何选择需要删除的东西，里面给我印象最深刻的地方有两点。第一、很多项目会将不容易实现的部分删掉，这导致了一些基本需求无法得到满足，用户故事不完整，错删也是非常麻烦的事情。第二、删除的过程经常是非常血腥的，不要去理会“如果用户要如何如何”的假设，也不要太顾忌那些已有功能被删除之后，用户的愤怒和抱怨，只要核心功能完整，用户会逐步接受，而且新用户会更加喜欢简约的设计。

 
在删除之后，就是组织。将相同或相近的功能组织在一起。其中讲到了标识统一，也就是说同类型的东西要具备统一的标识是非常重要的。另外就是通过颜色来进行信息和内容的分层，作者是以伦敦地铁线路为例说明了这个问题，不过，个人感觉需要将地铁图那样信息密集的东西推送到用户面前本身就是一件非常难以想象的事情，用户必须看地铁图是因为他们必须乘坐地铁，很多人到了陌生的城市后，会选择更加昂贵的出租车，最主要的原因就是出租车司机认识路，乘客不需要自己去学习地图。而在互联网、移动互联网应用中，很少有什么是用户必须要做的。

这本书越往后章节就越短，关于隐藏功能，主要是如何隐藏、隐藏哪些、以及这些隐藏的东西，何时出现。作者对于那些能够适时自动闪现的隐藏功能十分推崇。当阅读软件中，当选中了一段文字之后，搜索的功能会自动的跳出来。

关于转移，也就是说将一部分功能转其他平台上去。这部分的内容，作者只是提了一下。 关键在于将合适的功能，转移到合适的平台上去。当然，前提是应用一定要是跨平台的。

在这本书中，反复提到的使用简短的语言去描述用户故事，是非常重要的。另外就是，用户调查应该是确认用户需求的比较重要的手段，可惜在身边好像没怎么看到过这种东西。

在看本书之前，我不是一个设计人员，所以看过之后，我肯定也还是不具备做设计的能力。只是感觉对于一些产品的设计有了更加清晰的体会。建议所有和产品发生关系的人，不论是不是设计，都能够看看这本书，会对今后的产品生涯有所帮助的。

好像有很长一段时间没有更新博客了。

最近在忙着一些社区活动的事情。后面的社区活动会越来越多。而且，周末时间还需要陪儿子玩耍，是不是能够抽出时间来写博客，还不一定。抽空写吧。

今天下午有PMI项目管理俱乐部的活动，上午就跑来办公室，趁着这一点点的时间，写一些吧。

最近组织、协办、参加了一些社区活动。也有了一些想法。现在先来写其中的一个。

所有公司里面和宣传，公共关系相关的部门，都刚刚度过了我们一年之中最重大的一个节日，这个节日是所有做公关的人都是又狠又爱的，那就是315。所有的中国公司，对于315这种东西的心态都是非常矛盾的。既希望315能够搞定竞争对手，同时也害怕315找上自己。这就体现了一个问题，所有公司都知道自己在诚信方面有所亏欠，但又都寄希望与老天睁一只眼闭一只眼放过自己，或者想着，我们只是为了一些小恶，社会上比我们罪大恶极的家伙多去了。这次不会轮到我头上的。

315也算是一个大话题了，这里要阐述的是另外一种比较小的诚信问题。那就是个人诚信、个人信誉。

诚信问题，分为很多方面。特别是有一些银行方面的信息，属于个人隐私，是不适合进行公开的。所以我所设想的个人信誉追踪系统，所追踪的也仅仅只能是个人或一些机构发表的公共言论，以及向公众所表达的一些观点的追踪和回溯。机构可以通过换人来快速的改变其信誉，但是个人不论走到什么地方，其信誉状况应该是不会发生跳跃性的变化的。所以我感觉，个人要比机构的信誉状况更加值得追踪。

记得很早以前在电视上看过一位大神级人物，讲解什么是诚信，那位大神讲道：为了远期利益，而放弃近期利益的方式，就是诚信了。诚信归根结底还是为了利益，并不是为了什么道德或真理、正义之类的东西。现在，很多的专家、学着、名人，在利用他们的声望，说着或做着一些事情，即使事后被证明了，这些事情可能有问题，他们也会放出，人总是要犯错误的之类的言语，来为自己辩解。甚至还有些可笑的人，做了不诚信的事情之后，堂而皇之的说，这是在牺牲小我，成就大我；牺牲个人荣誉，成就更大的利益。

这是为什么呢？为什么我们感觉有越来越多的个人或机构，变得不诚信了呢？我们无法相信社会，无法相信专家，无法相信其他的那些机构或管理者呢？当然，信任都是相互的，我们不信任别人，也不指望别人相信我们。归根结底，不诚信的成本太低了。诚信是为了远期利益，而牺牲近期利益的行为。那么不诚信就应该是不顾远期利益，而争取近期利益。但是如果人们在不择手段的获得近期利益的时候，对其远期利益基本没有损害，甚至还有所帮助，那么就不会有人选择去遵守诚信了。因为那是非常不划算的一件事情。

社会为什么需要诚信，这里就不讲了，相信大多数人都非常清楚。那么我们怎么得到一个诚信的社会呢？大的方面肯定轮不到我在这里胡说，那是党和政府考虑的事情。我们只能从一些小处着手，增加一部分人不诚信行为的成本。

我的想法是，建立一个跨平台的网络应用，能够让所有的用户讲他们看到、听到的事情记录下来。然后利用语义分析工具和人脸识别技术、声纹和语音识别等技术，对这些凌乱的信息进行整理，将信息以人为单位，以时间为顺序，进行归并。系统仅分析和记录那些公众场合发表的信息，图片、视频和语音信息，用户可以从各种新闻媒介摘要上传信息到系统中来。

对于一个事件，在系统的数据模型上，会形成一个节点。各个专家和学着、机构对于这个事件的观点会汇集在一起。系统可以自动的筛选出一些对于这个事件比较热心的用户来维护这个节点。并使其具备比较高的可读性。以方便其他用户的阅读并进一步的补充内容进来。用户可以在不同的时间段，对同一个事件，同一个人在这个事件中所起到的作用进行评判。社会大众在不同的阶段，对于同一个事情有不同的看法也是正常的，毕竟通常是需要日久见人心的。

人们也可以自己去上传一些自己的事件。大家可以去纠正那些错误的信息，这需要共识，然后找到一些共同关心这个事件的用户认可之后，才可以进行修正。被修正的内容，也不会被删除，而会作为被证实是虚假的信息，存放在系统中，用户仍然能够看到。

这个系统会通过众包的形式，搜集社会新闻媒体上面的公开新闻，然后让人们在不同的时期对新闻人物在新闻事件中所起到的作用进行评判。当事件随着时间的发展，前面那些人所说过的话，发表的意见，做过的事情，旁观者可能会给出不同的评价。这个系统存在的目的，就是为了让大家记住。记住那些人，在过去的那些事情上都做过些什么，让这些人的远期利益和他们现在的一些作为挂钩，让他们在做事情的时候，能够有所顾忌。让那些有信誉的人，能够享受他们牺牲掉近期利益所博得的远期利益，让那些没有信誉的人，在远期利益上能够受到相应的损失。

这个系统，是很理想化的，是否可行，是否有可能在现在的社会形态下出现，这都很难说。至少从技术上，是没有任何问题的。现在的微博数据，就完全可以支撑这种系统的运转。但是微博做得是严格的恪守时间线，如果出现了什么不好的事情，就可以通过另外的一些更加热点的事情，来增快用户遗忘的速度。只要将吸引力转移了，大家很快就会将事情忘掉的。当然也有一些认真的人，喜欢抓住别人的小辫子不放，比如方舟子之流。

我所设想的这个系统，就是希望能够有更多的人，能够通过系统来部分的实现方舟子那种很有研究能力的人才能实现的事情。方舟子在打假的时候，还是很有选择性的，这没有什么可批评的，毕竟他也要在这个社会下生存的。有了一套系统之后，大家通过众包的方式来搜集信息，搜集信息的时候，可以使用实名用户或匿名用户提交的信息，但信息必须是在公共媒体上发表的内容，或者是实名用户自己相关的内容。这样的话，那些提供信息的人们也就没有什么风险了。很多考证的事情，可以等到信息搜集起来之后再说，具体是采用人肉的方式，还是计算机算法，或者最有可能的是计算机算法和人肉相结合的方式，都是可以的。

那些曾经不诚信的人，或者是被其他人误解了的人，也可以到系统里面来解释，或者找其他人来帮其证明。

知错能改善莫大焉，总要给大家改过自新的机会。系统存在的目的不是为了让那些不诚信的人永远不溶于社会。而是希望能够起到一个威慑的作用，并能够告诉大家，善有善报恶有恶报。

此类系统到底有没有社会需求，这个事情很难说，但是从商业模式上来说，肯定是比较麻烦的。也许，能够用来作为某些诚信者记录自己工作生活状态的地方吧。最终成为一种媒体。

这个系统，只是我的一个设想，是不是有过类似的东西，本人不考证。设想这个系统的目的就在于：首先将现在发生的事情，记录下来。以后这些内容就是历史，不可磨灭的历史。让后人可以通过这些历史的记录来对参与到现在这些历史事件中的人们进行评判。

RSS阅读，对于我们这些人来说肯定是一天都离不开的，但其实这也是一个小众应用。
我个人对于RSS阅读的需求是这样的：

• 多平台的书签同步，标记那些读过，哪些未读。
• 不论源提供的是什么样的，所有的内容都分为标题、简介和全文三种状态，也就是说对于那些不提供简介的，要自动生成简介，对于那些不提供全文的要自动提供全文。
• 移动端的图片，进行预先的处理，下载的内容预先压缩，比如生成类似于epub的格式。
• 自动去重，如果我订阅的各个源之间，都报道了同一事件，那么就要去除重复的内容。
• 智能内容推荐，推荐那些热门的内容，推荐那些我好友关注的内容，推荐那些有趣的，新的源。
• 智能过滤，当我的时间比较紧张的时候，按照优先级和重要度，筛选比较重要的内容发给我。
• 提醒，当某些特殊事件发生时，主动的提醒我。
• 归纳总结，定期，比如一天、一周、一个月，出一份总结性的杂志。可以离线阅读。
• 分享和关注，分享我的阅读体验，关注我好友的阅读过程
• 将所有源的所有内容，按照类别进行分类、去重，然后按照类别进行阅读

我目前主要在使用Google Reader，IOS端使用的是Reeder。主要的功能是可以满足的。但是Google Reader是按照时间和源为基础来管理内容的。我希望能够安装状态和优先级、类型来进行组织和排列。

希望能够有跨平台的RSS离线阅读工具。
较为重度的RSS阅读者，对RSS阅读提出的想法。

现在有各种各样的稀缺资源，比如说高峰时间的餐位。那么就需要排队系统。来帮助用户和商家进行双向选择，以实现各种稀缺资源有序的分配。

现在有很多预约系统来解决这种问题。

但是，商家所需要的其实并不是简单的预约系统，而是解决两个问题：
第一、削峰填谷
第二、有效的选择客户
第三、降低赚取同样资金所消耗的时间和其他相关成本
削峰填谷自不必说，高峰时期接待能力是有限的，商家肯定希望在低谷时期能够多有一些人来消费服务。

下一件事情也就显而易见了。既然在高峰时期，服务接待能力是有限的，那么就需要选择用户了，让有限的资源尽可能为更合适的用户服务，以便赚取更多的利润。目前商家通常是通过三种形式来选择客户的：

1. 熟客，熟客肯定是需要优先服务的，即使为了他们牺牲一部分服务时间，只要是预约，那么就必须让服务资源空闲下来，在外面有人排队的情况下，等待预约的客人。这是不划算的，但是熟客的预约在使商家承受这种损失的同时，达到了广告的效果，可以让熟客的忠诚度和黏着度进一步提高，因为熟客享受到了特殊的服务，在别人排队的时候他先进去享受服务了，这是一种身份的尊崇，也是商家提高自身地位的一种手段。这是一种榜样的力量，可以促使其他用户成为熟客。最后，熟客还会经常在非高峰时段过来消费，这也可以弥补一定的损失。
2. 有偿预约，上面说了，空出服务资源来等待预约的客人，这本身是有成本的。那么如果客人愿意支付这个成本，空着也就空着了。
3. 客户选择，单位时间内并不是接待的客户越多，就越赚钱。每个客人的消费能力不同。所以，应该是在单位时间内，接待的消费能力高的客户越多，就越赚钱。商家总是在想方设法的选择那些消费能力更强的客户，比如在高峰时段提高价格，比如为预约的客户设定消费下限，等等。

在高峰时段，如果已经选择好了客户，那么还能做的最后一件事情就是尽量降低为这些客户服务的时间和其他成本。这个放在饭店里面来说，叫做翻台。也就是一桌客人吃完了，将桌子清理干净，再请下一桌客人用餐。提高翻台率就是各个饭店在高峰时段所期待的东西。饭店通常是通过推荐推荐当日特色菜，建议用户点选某些可以快速烹调的食物，在高峰时段不为那些非预约的用户提供那些难以在短期内完成的食物，比如正宗的佛跳墙，等手段来实现这个目标的。

推荐的特色菜，通常是需要较长时间烹饪的，饭店会统一准备好一大批成品或半成品，然后希望用户尽量集中的点选这些食物，以缩短服务时间。另外一个饭店里面经常采用的方法，就是让用户在等位的时候，完成点菜，甚至是付款，这样也可以有效的缩短每一桌客人的服务时间。
预约服务，其现金流通常是来自于商家。所能够为商家提供的服务，分为三个层次。
最低层次、帮助那些即使在高峰时段也没有用户登门的商家做广告，告诉用户周六的午餐，旁边那家不需要排队。
中间层次、帮助商家向用户收取有偿预约的费用，最后和商家进行分成。不过这个盈利方式有违目前的消费习惯，很难大范围的推广。
最高层次、帮助商家筛选客户，将消费能力高的客户筛选出来，并帮助商家培养忠实的熟客。引导客户在非高峰时段，享受一些高峰时段难以享受到的服务。

附加的服务，则是帮助商家向用户推荐商家希望推荐的某些特定服务，帮助用户在预约的时候，就直接将各种所需的服务做好选择。

这里只说了为商家服务，却没有提到为客户服务。这是从现金流的角度出发的。这是属于矛盾的两个方面，如果一个服务和应用，没有用户来用，那么对于商家来说也就是没有意义的。为用户提供准确的信息，做出能够实现的承诺，完成用户所需的服务，这是必不可少的。但设计的初衷，还是应该为商家服务。因为，预约服务，都是在消费高峰期才需要的，而消费高峰期的时候，通常是卖方市场，首先是商家挑选用户，然后才是用户的双向选择。

希望能够有一个非常棒的预约服务，来帮助我选择中午去什么地方吃饭。

云计算其实是中国人发明的。

很多人看到这里可能就笑了，云计算这么先进的东西怎么会是中国人发明的呢？

中国的IT发展史，或者应该说是各个政府职能部门的IT应用发展史更加合适吧，就是一部不断集中再集中的历史。在不同的阶段，根据当时计算机、网络和软件技术的发展，进行不同层次的集中。县级集中、市级集中、省级集中、全国大集中。银行集中、税务集中、保险集中、电信结算集中。中国政府的IT应用史就是一部集中史。而将原来分散的应用，集中到一起。分散的节点，通过集中的服务，统一的处理原来在本地处理的业务，这就是一个将本地应用虚拟化到云端的过程。而这个过程又是受到了中国几千年集权思想的引导而形成的。所以说云计算是中国人发明的，也不算过分。总比说全天下的伟人都是韩国人要更靠谱一些。

云计算，现在好像不云一下都没法计算了。各大IT厂商都在纷纷推出自己的云计算的产品和服务，至少也会推出一些似是而非的云概念。

这里要讨论的并不是谁是真王麻子，谁是老王麻子，而哪一个是又真又老的王麻子的问题。而是想讲一下各种王麻子产生的过程和故事，他们之间的关系。以及大家通常是根据什么原因来选择不同的云服务厂商，这些运行在不同云服务平台上，都从这些平台上得到了些什么。

常见的云

云应用

现在大家经常能够在网络和媒体上看到的云。有云电视、云手机、云杀毒、云输入法、云邮件、云中相册、云中通讯录、云安全，甚至是云电子商务平台什么的。这些其实都是云应用，是面向最终用户的，也就是说不需要再编写任何程序，就可以直接被使用的云服务。最终用户不论是个人还是机构，都可以直接调用、使用这些服务。

由于是向最终用户提供的服务，所以这些应用在很多的公众媒体上投放了很多的力量，市面上能够看到最多的也就是这一类的云服务了。

所谓的运营用，分为几类。有的却是是将某些分散应用集中到云端去了。有些则仅仅是使用了其他层次的云服务构建的应用。或者在应用中提供了一些其他层次的云服务。这其中有很多云应用都是在中国独一无二的，只有作为云计算的发明国家，才会有那么多独特的云计算模式。

开放平台

这些应用，通常会在用户积累到一定程度时候，开放出API来。让其他个人或团体帮助他们开发一些辅助的功能或扩展。毕竟一旦大家开始使用一个服务或应用，就总会对其产生出这样或那样的需求。这些需求中有些是大多数人需要的，那么运营那些应用的机构会开发升级的版本来实现这些需求。另外，就是有些需求只为一部分人所需要，并不是所有用户的需求，那么就可以开放出接口来让其他人来开发。

当API聚集到一定程度，就会形成一个有规划的API包，这就是开放平台的由来。

现在国内腾讯、阿里、盛大、新浪等这些聚集了大量注册用户的服务商，都放出了庞大的开放平台。

这些平台功能之庞杂，变化、迭代之快，也绝对是世界范围内绝无仅有的。也算是一种中国特色了吧。

App Engine

有些人使用这些开放平台上的服务，开发出了新的应用。一开始的时候，这些应用还是跑在提供这些服务的各自的服务器上。为了能够提高这些应用的效率，很多IT服务商提供了App Engine，也就是说允许服务提供者开发一段代码，直接跑在提供开放平台的服务商的服务器上。这样做的好处有两个：第一、新服务提供者的开发量极大的降低了，很多重复模块不需要重复的开发；第二、这些程序运行在距离核心服务和应用很近的地方，效率和安全性都得到了有效的提高。

现在Google、新浪、腾讯、阿里提供的就是这种云。

根据平台的要求，开发者开发一段代码。这种代码要受到平台的限制，比如新浪要求的是php代码，google要求的是java或python代码。然后使用服务商提供的数据库存储数据，比如新浪使用的是一种NoSQL数据库，而腾讯提供的则是MySQL。再使用他们各自提供的其他相关服务，比如腾讯和新浪都提供了不同的，类似于Memcached的cache服务。然后，才可以连接开放平台所提供的各种API接口，比如调用新浪微博的认证，并向微博中发送内容，或读取微博数据进行一些统计和分析等。最后，这些代码将被上传到google、新浪或腾讯、阿里的服务器上。AppEngine通常会提供一个控制面板，来帮助开发者管理上传代码的版本，以及控制其启动、停止，监控这些代码的运营状态，甚至是计费。

Google App Engine上的应用，五花八门，杂乱无章。再看看国内的情况，新浪SEA上的程序，基本上100%都是为新浪微博用户服务的，而腾讯和阿里上的应用也基本上都是为他们各自的基础服务，提供补充的。由此可见，国内互联网公司对App Engine的理解，要比美国人先进得多啊。

虚拟机

上面的App Engine方式，用起来实在是太憋屈了。有一种更加自由的方式，那就是有些云计算服务商直接提供虚拟化的基础设施。比如虚拟服务器、虚拟硬盘等。

亚马逊和盛大云，所提供的就是这种服务。开发者拿到的就是虚拟的服务器，开发者可以自由的决定在上面使用什么语言，什么架构来开发应用。

由于国家为我们建立了墙，可以很好的对天朝局域网进行保护，所以如果有人将应用放在亚马逊的云上，这个应用在过国内访问的速度将是任何人都无法忍受的，甚至还会有很多服务，突然就无法访问了，比如dropbox。所以国内的用户，或者是国外那些想要开展中国业务的用户，最佳的选择就是直接购买类似于盛大云这样的公司提供的云主机服务就好了。对于国人来说，根本就不需要知道亚马逊云，因为上面最著名，最有趣的应用在国内几乎都是无法访问的。越是有趣的应用，在国内能够被访问到的几率越小。

大家是怎么云起来的

以前本没有路，走的人多了自然也就形成路了。以前没有云，后来中国人实在是太喜欢集中，太喜欢统一了，于是就有了云。看来路是被走出来的，那么云到底是怎么来的呢？通常的、国际化的解释会从分布式计算讲到SOA，再到亚马逊宣布AWS，然后是google的云平台等等。这仅仅是美帝国主义为了掩盖他们剽窃中国人聪明才智所作出的掩饰。其实即使是在上面提到的这些公司里面也不乏大量的华人工程师、架构师、设计师。说任何一个美国软件公司的发明创造是中国人的发明，都是说得过去的。比如亚马逊著名的存储服务S3的构架师就是个中国人。这个人就是现任盛大云老总的何刚。老一辈的无产阶级革命家从美国回来建造两弹一星，现在也有在美国工作的科学家，回国建设云计算。

将应用通过虚拟化的方式进行集中

最标准的云服务，比如google document、salesforce。原来每个人都要在自己的电脑上安装office之类的文字处理软件的，现在不需要了，这些功能被虚拟化到云端了，虚拟化到google document上面去了。原来上些规模的销售型公司都要购置CRM（客户关系管理）系统的，现在也不需要了，只要直接使用salesforce的服务就好了。这就是云服务，或者叫做SaaS(软件即服务）。

集中过程或集中之后提供的API接口

服务已经被虚拟化到云端了，但是既然云计算是中国人发明的，也就必须符合中国人的基本哲学，那就是众口难调。服务集中了，但是总会有一些不同地区或人群的特殊需求需要解决。那么下一件事情就是制定标准和开放API接口了。最早想到这个问题的应该是秦始皇，他统一了度量衡。看看，我又找到了中国人发明云计算的证据了吧。

google API、Facebook API、新浪API、腾讯API、盛大的API Pool，这些都开放出来了，可以让不同的个人、团队或机构，根据各自的需要，开发出各种相关的应用出来。

通常API都是在应用运营成功之后才会推出来，因为使用一套API或框架，是需要消耗学习成本的，在没有足够利益（海量有价值的内容或用户）吸引的情况下，是不会有人愿意投入的。也有特例，那就是API所提供的服务是一些类似于存储之类的基础服务时除外。

将使用开放平台的应用再集中到一起

因为云计算是中国人发明的，所以那种大集中，在技术允许的情况下不断集中的倾向一直都在影响着云计算的走向。很多人通过使用开放平台上面的服务，开发出了许多新的应用和服务，这又是一个发散的过程了。于是在分久必合，合了之后还可以在更大的范围内再合的典型中国思想的指导下，App Engine诞生了，现在可以将那些分散出去的应用再重新集中回服务商的服务器上去了。每一个服务商，都是以“四海之内，莫非王土；率土之滨，莫非王臣”为目标而不断增长的。

GAE——google App Engine、SAE 新浪App Engine就是这么产生的。

这就是云计算说明文档或教程上经常出现的PaaS（平台即服务）了。通常，开放平台就能够算是PaaS了。

直接提供底层架构服务

总会有些团队希望开发出不同的应用来，不希望被各种App Engine所限制，希望发展自己的用户，而不是为其他平台的用户服务。甚至还有些团队心怀远大的理想，希望能够在将来的某一天，自己也能够开发出能够吸引到足够用户的应用。

比如Evernote或Dropbox那样的公司，现在已经吸引到了足够多的用户，他们也开放出API，希望其他人帮他们写出更加个性化的扩展，或为其他应用提供特定的服务。

这样的公司或团队，就对App Engine提出了质疑。

于是，直接提供底层架构虚拟化的服务就出现了。也就是说直接提供虚拟云主机和云存储、云端数据库等底层架构。这就是IaaS（基础设施即服务）了。

现在腾讯和阿里提供了一些介于基础IaaS和PaaS之间的东西，这其中的区分方式就在于是否限定开发者的开发语言和框架，开发者得到是否可以自由的使用裸服务器。他们在提供裸服务器的同时，主要推广的其实是一种被他们叫做“网站云”的东西，也就是使用php、mysql架构的PaaS。

如果说程序运行的控制面板是App Engine的一个标志（App可以随时根据开发者的需求上线、下线）的话，IaaS的一个标志就是按需计费，按小时计费。现在腾讯的云主机是按照天计费的，而阿里的有些服务更是按月计费的。

选择不同的云平台

普通用户

普通用户是没有选择的，他们只能选择开发好的云应用或在开放平台的基础上开发出来的，或架设在云主机上的云应用。

开放平台通常绑定一些资源

上面说了，选择开放平台是有成本的。所以那些资源不好的开放平台是没有人选择的。那么人们如果选择开放平，则是为了得到开放平台上的那些资源。

比如选择新浪开放平台的人，都是看中了新浪微博上面的海量用户、内容。选择腾讯平台的人，则是看重腾讯的十亿账号。选择盛大开发平台的，则是希望能够得到盛大十多亿的预付费账号，以及这些账号上以亿万计的预支付现金。

既然开发者是冲着这些资源去的，那么选择不同的平台，也就是为不同的用户群体在服务。最终，即使应用成功的赚到了钱，用户也还是属于平台的，并不属于应用。有些应用希望为不同平台上的用户服务，于是他们就会将应用部署到不同的PaaS上面去，这就导致了在同一个应用中的用户群体的认为割裂。就像是同样的手机用户，就会分为移动、联通、电信用户那样，而且不仅如此，手机号码还是属于移动公司的，是不可以被用户带着走的，那么如果希望为这三家移动运营商的用户提供应用的话，就必须将系统分别搭建在三家运营商的平台上。

这也是社会分工的一种，有人提供了平台，就要有人在上面做应用赚取利润。提供平台的人得到用户，使得平台的价值上升；而提供应用的人，则实打实的赚到了现金，并通过对不同平台用户的分析，得到了更进一步的数据，以便能够做出更加好的应用，术业有专攻。

在这个过程中，AppEngine只是PaaS的一个延伸。归根结底还是资源吸引了开发者。

底层基础设施的服务，是完全中立的

又要说到那些有理想，追求自由的开发者了。中国人大多都是很有理想的，比如人人都想当皇帝也算是一种很民族的理想吧。这些人就会选择完全中立的IaaS，不希望受到限制，期望能够积累自己的用户，并在将来的某一天中，自己也能成长为google、新浪、腾讯，甚至是盛大那样的公司。

结论

云有好多种，这些云是在中国人根深蒂固的中央集权的思想引导下，逐步演化产生出来的，适应于不同类型的用户和应用。不同形式的云，应该还会并存很长的一段时间，这是一个社会分工不断细化的过程，是社会生产力上升的一个标志。每一个层次的人，专心致志的做好自己的事情。选择任何一个层次的云计算，不论是选择构建云计算的服务，还是使用这些服务为最终用户提供服务，这并没有高低贵贱之分，只是社会分工不同罢了。

当然，中国人也还会凭借着自己的聪明才智，不断的创造出更多，很稀奇古怪的云应用和服务方式来的。

云计算是一种真正革命性的，会真正对每一个人都带来影响的东西。就像中国人的其他发明那样，不论是否理解，不论是否喜欢，都必将为人类带来全新的未来。

今天在http://openpk.org 上的 #盛大云计算大赛# 创意投递中，看到了一个非常有趣的创意，叫做Face-API。其实前几天 @孤云大兵 同学提交创意“明星脸”时还有人在评论“这个技术门槛不低，要如何实现相关技术”的问题？当时孤云大兵表示准备去看一看论文，找一些相关的算法，不料今天就有人直接送服务上门了，真是无巧不成书。

• Face-API的介绍

Face-API是基于云主机提供的一套实现人脸识别服务的开放API。

Face-API的工作方式是这样的：首先，调用这套API的应用要将照片上传到云端；然后Face-API会在云端进行人脸检测，即使是合影，只要人脸所占像素达到了识别的标准，就会被一一检测出来；检测到人脸之后，根据五官的角度和比例来判定人脸在照片中的角度；最后一件事情就是进行人脸聚合，计算机是无法判定哪张脸属于哪个人的，它能做的仅仅是将同一个人的人脸聚集在一起。

Face-API将聚合的信息发送给调用它的应用，然后就会删除上传到服务器的照片，仅仅保留下聚合之后的人脸特征信息。当下次该应用再传输照片上来的时候，只需要和留存的人脸特征信息库进行比对，就可以知道这些新照片中哪些人脸以前曾经被识别和聚类过，并再次进行聚类。

到此为止，计算机能做的事情已经结束，操作权再次交回用户手中。也就是说，用户要自己将识别出来的聚类与具体的人关联起来，以及进行少量识别结果的校对。在这个人工参与环节之后，才算是完成了人脸识别的完整过程。

在此之后，应用还应该将用户反馈的信息（尤其是如不同聚类其实是同一个人、或某个聚类中有个别照片有误）反馈给Face-API服务器，以便服务器对算法进行校正，以提高今后继续识别的精确性。

当然，这并不是一个完全的训练过程。比如一个儿童，随着年龄的增长，其相貌变化是很大的，就算是人隔上几年看到一个儿童也不一定能够认出来，对于计算机系统来说，能够做的也就是记住“这是某某人，那也是某某人”，足矣。

上面解释的是最基本的服务流程，真正使用起来还要略微复杂一些。Face-API除了能够提供基本的人脸检测功能之外，还准备提供相似度比较、性别判定及年龄判定等，以后应该还会不断添加新功能进来。

• Face-API的用户隐私保护

如果需要进行人脸检测，就必须要上传照片。但是对于Face-API来说，系统并不知道这些照片上的人具体是谁，只是会进行人脸聚集。应用不断地传照片上来，Face-API服务器只能知道这次传上来的照片中有某个人脸和以前传上来的某个很像。

当用户将某张照片与某个人进行关联之后，这个数据并不会上传到Face-API服务器。对于Face-API来说，某一个聚类的照片，所指向的那个用户永远都是一个唯一的随机数，而不是某一个现实中存在的具体的人。

用户上传的照片，在识别之后会被删除，Face-API服务器上只保存人脸的一些特征信息，并不会长期保存用户的原始上传照片。比如一个照片流式的应用，本身就会要求用户上传照片，那么只需要在应用的服务器收到用户的照片之后，传送一份到Face-API服务器进行人脸检测和识别，应用可以保存用户的通讯录或照片中那个人的具体信息，但是这些东西Face-API的服务器上都不会保存。

在Face-API的接口上，允许应用对照片进一步进行用户标识，也就是说应用可以告诉Face-API服务器，哪些照片是属于一个用户的，而哪些是属于另外一个用户的。在Face-API的服务器端，将实现严格的用户数据隔离，一个用户的照片，只会和这个用户自己的照片进行比较和聚类，在比较和聚类的过程中，不同用户的照片是隔离的，这就在最大程度上保证了用户隐私的保护。

• Face-API和云计算和移动互联网

人脸识别技术在PC端已经有一些案例了，比如苹果的iMovie和Google的Picasa都带有人脸识别功能。但是，在移动互联网应用方面、在移动设备上，人脸识别运算（特别是最后的人脸聚类运算）所消耗的运算资源和内存资源都是不被允许的。移动设备本身的局限性导致了这个计算无法在本地完成，所以只能交给服务器去完成。

对于人脸识别类的应用来说，识别和比对的运算量是很大的，Face-API完全可以在用户请求比较少的时候，使用很少的服务器计算资源，也就是说使用一个配置较低的服务器来支撑日常的API调度和低请求量的人脸识别和比对计算需求，而在有大量照片需要比对的时候，同时使用很多服务器进行并行运算。

这种工作模式在传统的IDC机房中问题很大，但是有了弹性的云计算环境之后，事情就变得容易多了。

Face-API可以将数据存放在集群的NoSQL数据库中，然后将计算服务器的镜像也存储下来。在需要大规模运算的时候，只要调用云服务API，使用事先准备好的镜像使用1分钟时间部署出所需要的运算服务器，然后通过云计算API启动这些服务器，之后就可以自动调度服务器和NoSQL数据集群中提取所需处理的任务和数据进行高性能的运算。

运算结束之后，或者说是在运算请求量降低，不再需要那么多服务器进行并行运算之后，将并行运算服务器上的数据重新写回NoSQL集群中，然后自动执行关机脚本。调度服务器再通过云计算服务API将这些多余的服务器退掉。

值得一提的是，这次为盛大云计算大赛提供支撑的盛大云服务，是按照小时计费的。

• 人脸识别技术普及后的SNS

长远来看，人脸识别技术并不仅仅是一种简单的计算机智能模式识别技术，更将是一种对人与人之间的关系将带来深远影响的技术变革。

近年来非常火爆的SNS，也就是社会化网络服务，本身就是基于真实的人际关系建立起来的（比如Facebook），由此可见标识个人身份的照片对于SNS是多么重要。如果计算机能够相对准确地对这些照片和身份之间进行一个自动的标识和关联，那么SNS上肯定会出现很多完全不同的、很酷的甚至我们现在还无法想象的应用和服务模式。

人脸识别技术给SNS带来的改变，肯定不会比LBS小。

每一项技术，通常是首先出现在实验室中，然后再尝试将其产品化，在这个过程中新的模式将不断涌现。比如GPS（全球卫星定位系统）最初完全是为了军事目的被发明出来，民用化之后除了进行定位和导航外，很长一段时间并没有新模式出现。突然有一天，人们发现可以提供很多基于位置的服务，一种全新的应用模式就诞生了。

这不是技术创新，而是应用模式创新。人脸识别技术目前也处在这样一个阶段，技术基本成型但缺乏创新的应用模式。这个过程不是单纯靠实验室里面的科学家就可以完成的，而必须集思广益，靠整个社会的智慧来推动。

相信随着Face-API服务的上线，会不断有新的应用涌现，让我们来共同期待吧。