传说篇

在网上搜索了一些文章，写得都不是很清楚，当时抱着可以自制门卡，在地铁站刷手机的美好憧憬，开始了折腾。首先，门卡、公交卡之类的东西，是可以读取出来的。但是搞不清应该如何将手机设置成‘卡模式’，所以刷手机的尝试失败了。据网上说，可以将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也算是一个大话题了，这里要阐述的是另外一种比较小的诚信问题。那就是个人诚信、个人信誉。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前文已经写了很多内容，那里面其实已经将系统的结构和工作方式都讲过一些了，但是这里还是想再将这两个部分分拆开来，分别讲述一下。

本文主要是想要讲解帮助人们实现梦想的系统，可能会拥有哪些模块，哪些参与者，以及这些模块和参与者之间是如何在系统中进行互动的。

本文包含的内容，应该会比use case稍微丰富一些吧。

以后应该还会找时间再写一写这个系统的开发、发布和运营的步骤，也就是说如何一步一步的开发并推广这个系统。

1 系统结构

1.1 梦想故事展示

这应该是一个用于展示梦想和成功故事的portal类网站，依靠SEO，吸引那些有梦想或对相关主题感兴趣的人们，进入系统。

1.2 计划的录入

用户可以自己编制并录入一个计划，也可以是一些专门提供计划协助的个人或机构，提供相关的计划。

同一个项目，可以有很多并列的计划被录入进来，比如学习英语，会根据目的、时间、地域等条件进行细分。每一个细分，也都可以有很多不同的协助者，提供不同的计划。

用户可以将自己执行成功的计划，也分享出来，供其他人尝试。

1.3 测评系统

系统提供用户测评的功能，并能够帮助用户了解其自身在某一特定领域的知识或技巧掌握的程度。系统可以允许那些提供计划辅助的个人或机构，根据格式要求，录入新的测评项目和题目。测评的结果，可以是系统自动评定，也可以由特定的测评人给出主观评定。

测评系统仅仅是提供一个测评的规则体系平台。

1.4 计划的搜索和推荐

当用户有了某方面的梦想或对某些梦想感兴趣之后，系统会根据梦想的描述，给出实现该梦想的计划列表，并在列表中对提供计划辅助的个人或机构进行筛选、排序和推荐。

1.5 计划任务系统

根据用户的生活、工作情况，根据附近计划协助个人或机构的服务能力和排期，根据用户所选择的计划，进行细节调整。并确定最终要执行的计划。

监督用户执行计划，询问用户计划执行过程中的反馈，并根据反馈，必要的时候，在计划协助个人或机构的协助下，调整后续计划。

1.6 Social分享

根据用户的设定，将计划执行过程中的信息，分享到social network中去。

2 相关的人和角色

2.1 提供计划的人

提供计划的人，也就是上面所说到的计划的协助个人或机构，比如培训机构、健身教练等。他们将是这个系统的受益人。

2.1.1 提供计划

提供计划的人，要做的第一件事情，就是提供计划。一个驾校可以培养驾驶员，那么他们就需要录入一些培训计划。比如多长时间，多少钱，在什么地方培训，培训的相关条件，自己的资质，历年的通过率等等信息，以便用户进行挑选。

2.1.2 辅助用户执行计划

在线上或线下协助用户完成计划。比如培训或训练等等。

2.1.3 对用户在执行计划中的成就进行评定

录入评测系统中的评测项目和评测题目，评测方法。让用户可以自主或在协助下进行评测，衡量自己在某一个领域的知识、技能或体能等其他可以进行评测的项目的水准。

某些评测也可以在线下进行，然后将成绩记录到系统中也是可以的。比如驾校的交规是可以进行线上模拟的，而真正的交规考试、桩考和路考则必须是在系统外进行的，然后登记成绩。

2.1.4 提供成功故事

提供一些成功故事，以便在用户选择的时候提高被选中的机会。

2.2 浏览和讨论梦想故事的人

总有一些好事者，是会跑来看热闹的，看看有什么有趣的东西。他们不会很深入的参与到系统中去，但他们也是有可能转换成用户或计划提供者的，虽然转换率可能会低得惊人。系统的一些PV、IP、广告栏位价格等，可能也需要靠这些人来冲击。

2.2.1 通过SEO或Social Network进入

这些人通常是通过搜索或社交网络上相关的信息，进入系统的。所以系统的SEO和Social Network分享做得好不好，就是能够吸引到多少路人甲的根本了。

2.2.2 浏览梦想故事

这些人可能会浏览梦想故事，评论梦想故事，并根据系统的格式要求记录自己的梦想故事，然后再分享出去。

当某些梦想故事非常吸引人的时候，这些路人甲也可能订阅这些故事，时刻跟踪故事的最新进展，比如美国的地狱厨房和减肥达人等真人秀节目，其实就是这种可以被订阅的故事。

2.2.3 用户转化

如果这些人受到梦想、成功故事的感召，也想要实现一个什么计划。这个时候，就需要录入详细的身份信息，完成注册的过程，成为一个用户。

当路人甲也希望能够录入一个计划，并协助其他人来经过这个计划实现某种梦想的时候，这些人就会转化为一个计划录入者。

2.3 用户

大多数系统总是喜欢将那些支撑整个系统运行、支付费用的家伙，叫做用户。系统设计的目的，就是为了这些用户服务的，再决定功能的取舍时，唯一需要考虑的问题，就是这个功能是不是用户的根本需求，或这个需求是否会影响到用户的最终体验。

这是一个帮助其他人实现梦想的系统，那么用户自然就是那些有梦想，并愿意在系统的协助下实现梦想的人们了。

2.3.1 搜索相关的计划

用户会提出一些梦想，也就是搜索一些计划。系统会根据用户的梦想，向他们推荐一些可供选择的计划。

2.3.2 选择并调整计划

选择了计划之后，下一件事情就是需要根据用户和计划协助个人或机构的安排，进行计划细节的调整了。比如用户某一个阶段比较忙，或者身体状态不是很好，那么就需要进行调整。并不是所有的计划都需要其他人的协助，可能大部分计划都是用户自己就可以自主完成的。但是那些需要其他人协助的计划中，计划协助个人或者机构作为任务系统中的一种资源，肯定不可能是无限的。比如羽毛球教练、场地就需要进行事先的预定。驾校里面的师傅和教练车肯定也是有承载限制的。

系统在这个时候就要协助用户调整计划。并最终确定下来计划的各个细节。比如：学习驾驶需要非连续的40天时间，系统会帮助用户和驾校协调具体是从什么时候开始的哪40天时间里，来完成这个训练。

2.3.3 执行计划

这部分应该和传统的任务系统基本是一致的，提醒用户按照计划进行执行。询问用户或计划辅助个人或机构，用户执行计划的情况。

和普通任务系统不同的地方在于，普通任务系统如果发现任务的执行情况和计划不符，则会自动对计划进行调整，任务系统的管理者会在他认为必要的时候，主动的去修改后续计划。而这个系统里面没有管理者，所以系统就会根据计划执行的情况，询问用户和计划辅助个人或机构，是否需要调整后续计划。用户和计划辅助个人或机构会在协商之后，对计划后面的部分进行得到双方确认的调整。

2.3.4 参加测评

用户有了梦想，在选择计划，选择计划的不同阶段（比如围棋初级、中级、高级班），选择不同的服务商的过程中，计划执行的过程中，或计划结束的时候，都需要对自己的水准进行评测。以便准确的掌握自己在梦想之路上的具体位置。

2.3.5 向协助者支付费用

这个系统的现金流应该有两个源头：

第一个是辅助性质的，也就是广告收入。帮助那些提供培训服务的机构和个人，宣传他们的计划。广告和搜索推荐算法是绝对隔离的，不会出现广告影响推荐结果的情况。因为那并不符合用户的需求，会降低用户的使用体验。

第二个，也是支撑这个系统运转的根本将是用户向提供培训服务的机构或个人支付的费用。系统将从这个费用中进行非常低比例的抽成。

为了避免线下交易，必须是完成线上交易的用户才能对培训机构进行点评，而这个点评的结果将计入推荐算法，影响推荐算法上面的排名。

这个系统中的计划，大部分应该是免费的，是不需要用户支付费用的，也没有专人在计划执行的过程中提供很多的线上或线下的辅助。那些培训机构也可以提供以培训视频和自主测评为基础的免费培训计划。也可以在培训过程中提供一些纸质书籍或材料，通过培训课程在线上销售这些培训资料。

对于那些需要辅助人员参与的，需要付费的培训课程，也可以提供一些免费的试用体验课程。体验课程可以是视频教学，也可以是定期的线下示范课。

计划的辅助个人或机构，可以通过线上或线下的方式，为用户提供培训或教育。并通过测评的结果，来评定培训的成果。

计划的付费可以分为几个类型：

• 完全免费的线上学习，可以使用一些智能程序来进行线上辅助，也可以辅以很少量的线上专人辅助。
• 少量付费，有专门线下资料的培训，辅以大量的线上资源和线上专人通过IM或VoiP、视频通话等方式提供的辅助。
• 适中付费的线上专人课程。
• 较高付费的线下课程和活动。

几种方式可以结合进行，比如先进行完全免费的试用和体验，然后根据用户的要求对几种课程进行调配。

2.3.6 将计划执行过程中的成就分享到Social Network

用户可以设定，将计划执行过程中的信息，分享到那些Social Network上面去。系统会在用户完成某一阶段的计划之后，或参加了某些测评之后，提示用户进行分享。

2.3.7 横向的比较，得到更多的成就感和游戏性

学车的时候，是有师兄弟的。在学习过程中，在Social关系谱中，在同一个计划的同学中、在同类计划、同地域的学习者中，就可以进行比较。比如某某人时在学开车过程中，某某地区、某某驾校，或亲朋好友之中，是学习倒库速度最快的一个家伙。可以将不同时间段学习同一个课程的人放在一起比较，也可以将不同地区的人放在一起进行比较。

总之是希望增加用户在执行计划，实现梦想过程中的成就感和游戏性。从而促进用户更好的实现梦想。

系统可以组织类似于地狱厨房或减肥达人那样的淘汰赛事，从而实现更加彻底的游戏性。

2.3.8 完成计划，并将过程自动汇总到梦想故事中

在计划完成之后，系统会自动的将用户实现梦想的过程汇集成梦想故事。并在用户允许的情况下，发送给用户指定的人群。系统可以将故事按照不同的详细程度公布在梦想故事的模块中，比如完整的故事，或去掉名字的完整故事，或仅仅是成为某个培训机构的一个统计数字。

2.3.9 用户和协助其完成计划的个人或机构，进行相互点评

要实现系统的平衡，那么就需要有一套点评系统。用户和培训服务机构之间的双向点评。这些数据将协助双方进一步的进行选择。用户会选择那些优质培训机构，而培训机构也会去优先选择那些优质的，诚信的客户。

3 任务系统中计划的描述方式

3.1 计划就是一个个的状态机

计划将是一种穿插着自我学习、辅助学习和各种测评的状态机。

计划可以是封闭或开放的。所谓封闭计划，就是那种有终点，执行完成之后，进行考核的计划。开放式计划则是没有终点的，可以一直坚持下去，也可以由用户自主的选择放弃执行。

计划可以分层次，可以设定基础计划和后续推荐计划。比如，如果想要学习Android开发，则必须要熟悉Java语言编程。学习过了Android开发之后，还可以推荐一些更进一步的学习计划。

3.2 计划的标定方式

计划可以进行描述和标签标定，这些标签有些是可以量化的，有些则不是。比如下一期还可以接受多少学员，就是一个量化标签，通过率也是量化指标。讲解清晰，资深专家等等就是非量化标签。对于那些非量化的标签，可以通过自评和用户的点评，通过加一减一的方式，来实现量化。然后根据所有量化的指标，在用户搜索计划的时候进行推荐和排序。

4 成功故事的形成

4.1 将用户执行计划过程中的故事，穿插成一个完整的脚本

系统会在用户执行计划的每一个环节，都去鼓励用户保存一些他们的感受。如果他们将这些感受分享到了Social Network上，那么还会自动的收集这些信息在Social Network上所得到的反馈。

系统会自动记录用户计划执行过程中，得到的各种成就。

成功故事就是根据用户在执行计划的过程中保存下来的感受，分享出去得到的反馈，以及执行计划过程中该所得到的各种成就，自动生成的。在生成的过程中，用户可以自己进行加工和调整。成功公式是以脚本的形式来存放的。即使是一篇完整的成功故事也是可以根据脚本重新拆解成一个个节点和片段的，进行重新的组合和排列。

成功故事是可以续的，当一个人学习了初级厨师、高级厨师、中式面点、西式面点之后，他的成功故事应该是一个完整的故事，而不应该是一个个分离的故事。当这个人取得了有某个已经实现了的梦想相关的成就时，也可以将这个成就补充到那个成功故事之中去。比如某人学会了飞行驾驶，然后驾驶单人小飞机穿越了什么什么地方，并拍摄了什么什么照片或影片。这些就可以记录到那个学习飞行的梦想故事后面。

4.2 计划提供者可以提供一些符合格式要求的成功故事

那些提供计划的人或机构，也可以提供一些没有经过系统，而是完全在线下培训过程中发生的成功故事。

4.3 对故事中的环节提出异议，并进行讨论

如果某些人对梦想故事中的某些节点存在异议，可以对其提出异议，大家可以针对某一个节点，进行讨论。

4.4 允许浏览者提交其他成功故事

即使不是用户，也可以提交一些他们自己的成功故事。并不一定非要进行注册。

5 总结

好像又停更很长时间了。最近在忙盛大云计算大赛的事情，我负责去点评所有的作品。里面有不少作品都提到了学习和帮助别人实现梦想。看来这是一个很多人都在关注的热点啊。

不能保证下一篇什么时候出来，只能说我也是希望尽快的。本文讲了系统的一些基础架构，下一篇希望能够讲一讲这个系统的实现过程。当然也可能下面会写一些其他的东西，然后再继续写这个系统的下一篇博客。

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

中国的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、新浪、腾讯，甚至是盛大那样的公司。

结论

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

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

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

• 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服务的上线，会不断有新的应用涌现，让我们来共同期待吧。

记得小时候总是被教育说：君子立长志，小人常立志。也就是说那些道德高尚的人，会树立远大得目标和理想，然后坚持不懈的一直执行下去；而那些反面典型，则会经常树立各种人生目标，然后再不断的放弃。
就像每个人从小到大都在被教育着：“君子立长志，小人常立志。”一样，其实每个人都希望能够成为一个君子，他们身边的父母亲朋，也都希望他们能够成为一个君子。这就是这个人，以及他得整个社交关系群体对他得期盼。

当然，按照古人的想法，成为一个君子并不是那么容易的事情，这其中是包含很多方面的修养的，仅仅是立长志肯定是不够的。经过古人的总结，并不断将这些总结记录在圣贤书里面，代代传承，如何成为一个君子，是有很明确规范的，有一整套的培养体系和计划。
这里要讨论的肯定不会是如何成为一个君子，那是国学大师们的事情。这里要讨论的是，如何能够帮助人们实现他们的梦想，能够让他们成为自己和身边所在意的那些人们所共同期望的那个人。

让我们看看当一个人要立志成为一个君子的时候，是怎么做的吧。首先，这个决定通常并不是这个人自己独立做出的，而是在身边人们的建议和影响下做出的。
那么这个帮人实现人生梦想的系统要做的第一件事情就是要向使用者推荐一些有趣的、有意义的，被身边的人所认可、推崇的人生梦想。
这个过程可以进行协同过滤，也就是说先对用户进行分类，然后将这一类用户所喜欢的梦想推荐给他。也可以做一些问答，询问一下身边的人们，那些用户真正在意的人们，他们对自己的期盼到底是什么。然后再根据用户的当前生理和心里状态，以及经济、时间、地点方面的情况，将这些人生梦想进行排序，推荐给用户，供用户选择。

古人如果要立志成为一个君子，则会告知身边的父母、亲友和师长，以便大家能够激励和监督他，并在他修行成君子的过程中不断的从这些人身上得到建议和意见。
帮助人们实现其梦想的系统，也应该有类似的功能，也就是说当用户树立了一个人生梦想的时候，可以选择性的告诉一些人，向他们宣告自己的人生梦想，并让他们激励和监督自己，在实现梦想的过程中给予自己意见和建议。

如何成为一个君子，是有系统的培训体系的。
那么一个人的人生梦想，通常也是有一些可供参考的实现步骤的，甚至会有很多商家在其中提供成系列化的服务。比如学习外语或练习瑜伽之类的修行类服务。那么如果系统想要帮助用户实现其人生的梦想，就应该能够提供几种可供选择的，有可操作性和可实施性的方案。
这些方案可以是由专家提供，由专业的编辑进行编制；也可以是由已经实现了类似梦想用户的成功经验总结而成；或是共同期望实现类似梦想的用户之间探讨得到。
由于用户已经将自己的梦想告诉了一些人，那么这个方案和计划的制定和调整，这些人应该也是可以参与意见和建议的。
总之，在用户提出并确认自己的梦想之后，系统应该给出一个实现梦想的计划，计划可以是已经存在的，也可以是由用户和那些支持他实现梦想的人共同制定的，可能更加常见得情况是在现有的计划基础上进行调整。计划在执行的过程中是可以进行调整和修订的。

梦想已经有了，计划也已经有了，那么下一件事情就是执行了。
执行计划，就是任务系统来完成的事情了。但是和普通的任务系统不同的地方在于，这个任务系统会自动的根据计划和用户当前的状态，帮助用户安排具体某项任务的执行时间，并在提醒之后，主动的询问用户任务的执行状态。
比如用户计划要进行体育锻炼，根据用户的身体状况，系统给出了相应的锻炼计划，然后再根据用户的时间安排和用户所在地区的天气预报，建议用户在某日早晨进行慢跑锻炼。然后，系统会主动询问用户是否完成了慢跑锻炼，慢跑的效果如何，比如时间、距离、速度，以及心跳等。
当然，如果用户在慢跑的过程中携带了手机或其他可以记录其运动状态的设备，系统也可以自动的记录这些信息，而不是去直接询问用户。

计划已经开始被执行了。
在执行的过程中，有可能会出现各种变化。比如，原来计划要去慢跑的时候段，由于用户希望多睡一会儿而被耽搁了。或者由于运动量过度，而出现了四肢酸痛等身体不适的感觉。那么，系统就应该根据最新得到的反馈，自动的、或在用户的建议和协助之下，对计划进行调整。
这种调整在涉及到多人的计划时尤为重要，比如打羽毛球需要至少两人，参与这项计划的除了人之外，还需要预订场地，即使某些人由于临时有事而无法参加，场地的时间作为一种稀缺资源，也是很难进行调整的，那么在这种计划需要发生变更的时候，首先需要考虑的就应该是找到其他的人来替补，而不是调整羽毛球场地的时间。如果实在是找不到人来替补，那么也只能取消羽毛球场地的预约，并尝试重新预约大家都方便的时间。

在计划中的任务被执行了之后，计划的状态就要逐步的进行调整。
比如一个学习外语的计划，当用户参加并通过了一些考试或测评，通过了一些计划中的重要节点之后，系统就会根据考试和测评的结果，决定用户是进入下一个阶段还是将当前的阶段再重复一次，或者是进行一个补充的增强阶段，以达到预期的效果。

当用户完成了某些任务，或达到了某些程度之后，系统会将用户提交的一些测评的成绩和计划执行的状态分享到用户指定的社交平台。
前面说了，用户有了一个梦想，然后告诉了一些人，请他们对自己进行激励和监督。现在就是向这些人告知自己成就的时候了。
应该还有一些和用户选择类似梦想的人，那么这就有了一个排序的可能，对于用户来说成为吃过最多地方美食的达人和成为周围减体重最快的人，成为朋友中唱歌长得最好的人，甚至仅仅是唱某一首歌唱得最好的人，成为在朋友中最先看完某一本书的人，成为看完一本书所需时间最短的人，这些都会成为一件相当有趣的事情。这些成就可以让用户拿来炫耀，并激励用户或和他选择同样梦想的人在实现梦想的道路上更加坚定的前进下去。

最后，我们的用户真的实现了他的某个梦想。
这个时候，除了评定和分享他的成就之外，这个系统应该能够帮助用户将其实现梦想的每一个步骤都记录下来。为了成为户外运动达人，这个用户于某个时间和地点做了什么事情，他购买了什么装备，参加了什么活动，完成这些任务的时候他留下了什么记录，拍摄了什么照片或视频。向哪些朋友进行了分享，那些朋友又给予了什么样的回复和评价，给予了什么样的意见与建议，计划根据这些意见与建议进行了什么样的调整。以什么样的成就完成了计划中的一个个节点，并最终实现了人生的梦想。
系统应该可以将这些记录下来的信息，作为用户人生的一部分，永远的存储在用户的梦想空间之中，供用户回味和分享，在用户允许的情况下，供其他用户检索和借鉴。
系统会根据这些信息，进行分析之后，对用户执行计划，实现梦想的过程进行评价。并根据这些信息，在需要为该用户设定新计划或为其他相似用户设定同类梦想的计划时，进行相应得调整。

这就是我所设想的能够帮助用户规划人生、实现其人生梦想的系统。这篇博客从需求的角度，对这个系统进行了描述。后面应该还会有一篇从系统实现的方向再描述一次。

前面因为身体的原因，以及看小说的原因博客更新的比较不稳定，以后希望能够慢慢补上。