3 月 30
Luke Fan新文化, 杂谈, 梦想园, 随笔 产品, 杂谈, 社区
好奇怪的一个标题啊？事情是这样的，几个月前，我进行了一次工位的调整。在这个过程中，遇到了一些不是很爽的事情，虽然过去了这么长的时间，但每次想起还是觉得不爽。最近看了很多的产品，感觉有些很有趣，也有些看起来很不爽。看着看着，就想起了我那次不爽的工位搬迁经历了，并在其中找到了一些共通之处，在这里写一写。另外，可能和某些社会现象也有一些共通之处，如果有人看到了，觉得有所触发，那么很好；如果有些人看到了这篇文章，觉得不爽，那么只能说：如有雷同，纯属偶然。
首先还是先来介绍一下事情的经过吧。
几个月前，被通知需要调整工位，在大公司里面这是很正常的事情，长期不动地方，说明公司缺乏活力。好了扯远了，我接到了通知，于是就进行了搬迁。但是调整之后，却发现，我的分机号码变了。办公室购买的是昂贵的avaya IP电话机，电话号码是跟着电话走的，只要把电话从这边网线上拔下来，到那边插上，号码是不会变化的。但是在搬迁了工位之后，却被告知，我一定要更换一个分机号码，感觉非常的不解、不爽。
我已经将这个分机号码印在了名片上，印着原来那个分机号码的名片已经发掉了一盒，还剩下一盒。我还将这个分机号码标注在了我的邮件签名里面，应该也发出了几百上千封的邮件了吧。在我将那么多带有分机号码的邮件和名片发放出去之后，在保留分机号码那么方便的情况下，为什么一定要挑换呢？由于工作的需要，我们需要挑换工位，这没有问题。外面那些需要联系我的人，并不知道我的工位在什么地方的，但是分机号码就完全是另外一个问题了。需要联系我的人，是需要打那个分机来找到我的。
我感觉非常不爽，于是我就去抗争了。我先找到了行政人员，行政人员告诉我，这是IT部门的规定，于是我就又找到了IT人员，他们一开始告诉我，为了他们自己管理方便，所以才这么规定的。然后，我说，现在的设备，只要每个人抱着自己的电话机换工位，就不会有问题了啊，不会有任何不方便的地方啊？然后，IT人员又告诉我，这个规则是以前在行政岗位上的一个人，和他们一起商量确定的，就一直这么执行下来了。然后，我又找到了以前的那位行政人员，她告诉我说，她也没有此类的经验，这个规则是在办公室装修，设备还没有采购回来之前制定的，她也不了解现在话机的功能。而且，她已经离开了原来的岗位，如果其他人发现现在情况变化了，完全可以进行调整啊。最终，IT和行政人员还是在我的抗争下屈服了。但是，只有我一个人得以保留了原来的分机号，其他参与那次工位调整的同事，都换了新的分机号。以后再有调整工位的同事，我没有询问他们的情况，估计那个莫名其妙的规定应该还在执行着吧。也许部分去抗争了的人，能够保留自己的分机号码吧。
故事有些绕，但基本就是这样的了。在这个事情中，有人有错误吗？有那种需要承担责任的错误吗？应该说没有，但又应该说所有参与这个事情的人，都有一定的责任。
现在的行政人员，在发现情况发生了变化的时候，为什么没有去调整政策呢？也许他们以前并没有发现情况发生了变化，但是在有人抱怨了之后，他们选择了维护那个谁也搞不清怎么回事的规定继续运行下去，当有人来抗争的时候，就小范围的调整一下，息事宁人之后，继续保持原有政策的运行。
制定这个规则的时候，首先应该考虑的肯定是办公方便，业务方便。毕竟大家坐在这里是为了做事情，做业务的，那些管理部门存在的原因是维持业务的运转。而不是反过来，我们所有人坐在这里是为了被管理的。这里并不是要求完全不顾管理难度，一味的追求业务方便。而是应该达到一个平衡，在管理服务能够支撑的范围内，最大限度的为业务提供方便。至少在这一条规则的制定上，考虑管理方便的因素就大大的超越了业务方便。我以前的公司，换座位的时候，就会去调整程控交换机，最大限度的保证业务的连贯性。而在这里，在设备升级换代，大家只要抱着电话换工位，就可以达到不换分机号的情况下，制定规则的人，已经完全忘记了他们存在的意义是服务于业务，而是将自己摆在了一个管理者的位置上，为了管理方便而牺牲业务连贯性的需求。而且制定这个规则的时候，当时的行政人员没有经验，但是IT人员却是一个老IT了，他不可能没有相关经验的。
这里不是写批判文章。让我们看看在产品开发过程中是不是也会出现类似的问题呢？
一个产品的设计，目的肯定是要解决用户的一些需求。然后，还会有很多其他需求，比如做产品的人需要吃饭，需要有下载量，需要有点击数。需要用户支付等等。这就是其实也是一个平衡。前面的人可能还在做平衡，当团队大了之后，是不是会有人为了盲目的维护原来的一些策略，而放弃用户需求呢？会不会有人将产品本身的生存需求，放到了比用户需求更高的位置上了呢？
一个产品，其实有两块需求，用户需求和产品生存发展本身的需求。这就像是刚才说的例子一样，应该在保持产品生存和发展的条件下，尽最大可能的去满足用户的需求。而且，应该在做出每一个判断的时候，进行每一项功能取舍的时候，都从这个最原始的出发点来考虑问题。时时刻刻的反省，是不是条件发生了变化，在新的条件下，是不是应该调整原来设定的一些策略？
先举几个例子吧。
第一，原来一个sns网站，开放了API，让其他人在上面做游戏。他们看到那些用户做了游戏，赚到了钱，于是他们自己也开发游戏。然后，他们发现自己开发的游戏，没有用户开发出来的同类游戏赚钱，于是他们封闭了同类的游戏。后来，他们发现好像还是不怎么赚钱，于是他们就再去抄袭另外一个他们认为赚钱的游戏。周而复始，很快他们的平台上就没有人在上面开发游戏了。
第二，另外一个sns项目，运营的人发现互动太少，里面的游戏没有什么人玩儿，于是就不断的发大量的游戏信息出来，并且不断的提醒用户你的好友在邀请你玩儿什么什么游戏。很快这个平台上面的信息流就被游戏信息给淹没了，用户也快速的流失掉了。
第三，一些做电子阅读器的人，为了能够让用户购买他们的阅读器设备，不在客户端软件上放置阅读功能。他们担心如果用户在pc端软件上阅读了，就不会再购买阅读器了。其实他们要解决的问题不是买阅读器，而是让用户在任何时间和环境下都可以阅读。后来他们还是推出了一个单独的pc端阅读器软件，生生的将用户割裂开来。
第四，一个用户多媒体内容分享和传播的应用，在用户希望进行微博分享的时候，为了迫使用户点击微博中的链接，故意将某些内容截留下来，最终阻碍了用户希望信息得到传播这个需求的满足。发出去的微博本身的感染力也下降了，被转发和引起互动的能力下降。
上面都是一些反例，也有做得很好的。
第一，facebook为了保证用户收到信息的质量，限制了广告。
第二，google将广告放在搜索结果的外面，决不让广告污染搜索结果。
第三，一些轻博客网站，在分享内容到微博的时候，会按照最有吸引力和表现力的方式来摆放图片，从而提升微博的传播力。只有在需要的时候，才放链接进去，比如内容超过了微博允许的范围的时候才放链接，其他时候就不放链接。
关于如何区分不同的需求之间的平衡性的问题，故事讲了，道理也讲了。
下面讲另外一些故事。
当项目中发生争执的时候，经常会听到这样的话。这个事情是以前就是这么定下来的（虽然我说不清为什么），所以就是不能改。当有人要求修改的时候，，他会告诉你，以前出过故事的，你会比以前那些人更加了解情况吗？你会比以前那些人更聪明吗？而这个时候，以前那些人往往已经身居高位了。这就像上面那些人做得事情一样，规则有了，虽然我们搞不清当初为什么制定这个规则，那么好吧，让我们将这个规则执行下去吧。
不记得是在哪篇古文里面看到过这么一句话：上胡不法先王之法。意思就是说，国君为什么不取法古代帝王的法今制度呢？ 以前旧的规则，肯定是会有人去维护的，有些人是从自身利益出发，或者经过反复思量之后决定保留那些古法的。但是也总是有些人，会无条件的遵循固有的东西。并不是说打破古法就是对的，而是说一定要经过自己的思考，再决定是不是要执行还是改变固有的规则。
现在是互联网时代，各个团队的发展速度都是很快的。如果一个团队突然成功了，那么这个团队可能还没有来得及去总结到底哪些策略带来了他们的成功，他们所经历过的一切就都会变成先王之法。而很多曾经从不同的侧面了解到这些内容的人们，就会把这当作先王之法认真的执行下去，但这些人又往往是瞎子摸象、管中窥豹。现在流行的一种说法，说某某公司具备或不具备什么什么基因，这些基因就是这么形成的。
复制别人的成功为什么那么难？由此可见一斑。这个法先王之法的现象所造成的另外一个结果就是富不过三代。还有一个典型的例子就是邯郸学步了，现在copy to china蔚然成风，但是又有多少人真的学会了邯郸人走路的姿势了呢？
故事讲得差不多了，希望以后做产品的时候，能够时刻清醒的认识到，到底哪些需求是产品生存的需求，而哪些才是真正的用户需求。时刻注意自省每一个功能或策略到底是在满足用户需求，还是满足产品生存的需求。满足产品生存需求的时候，是否伤害了用户的根本需求。在当前的生存环境下，产品是不是已经最大化的满足了用户的需求，是不是可以做得更好一些。过去制定的各种策略和措施，在当前环境下，是否还适用，是否需要做出调整。如果需要的话，就及时的进行调整。
标题里面还有“其他”。那么最后讲一点点其他吧。涉及这个话题的社会现象通常都比较敏感，这里就讲一个比较不那么敏感的。
我们的手机号码是属于移动运营商的，不属于我们这些出钱的人。我们不能将号码从一个运营商转到另外一个，这就是一个典型的产品生存需求侵占用户需求的案例。当然，这还不算过分的，我们在同一个运营商那里，不可以将一个地区的号码迁移到另外一个地区去，这是一个典型的法先王之法的案例，以前由于计算能力有限，对号码进行了分地区的限定，为每个地区分配号段，现在技术进步了，计算机的运算能力增强了，既然我们能够实现手机的漫游，那么为什么不能实现跨地域的手机号码迁移呢？最后一个案例，是这两种弊端的结合，我们没法使用一个传统2G的号码，在同一个城市的同一个运营商那里开通3G服务。如果要使用3G号码，就必须要换一个3G的号码。这是当前技术无法解决的问题吗？很显然不是，那么为什么要这样做呢？理由很可笑，第一、以前就是这么干得，第二、这样可以发放出更多的3G号段的号码。
这个“其他”肯定还包含很多很多社会上的东西。这里就不列举了。我上面的那个亲身经历的故事里面，肯定还有很多其他有趣的东西值得挖掘，比如当发现问题的时候，私下向喊得最大声的那个低头，将事态控制在最小范围，维持大范围的稳定等等。以后有空再拿出来写吧。
3 月 29
Luke Fan梦想园 活动, 社区
2012年的3月20日，是IT龙门阵第一次走进盛大创新院。也是IT龙门阵的技术专场的第一次活动。这期活动，演讲的嘉宾，分别是来自盛大多媒体创新院，负责人脸识别技术开发以及应用的单霆先生和来自腾讯研究院的负责手机人机交互方面研究的陈波女士。这一期活动的主题，是移动终端上多媒体模式识别技术的应用。
在开始之前，主办方先请单霆先生和陈波女士这两位来自不同公司的多媒体模式识别和人机交互方面的专家，做了一个小范围的沟通会。他们交流了一下各自在这个领域中的一些经历和看法。
这次的活动还是吸引到了不少专业技术人员的参与。IT龙门阵已经很久没有做过这么技术的话题了，平时很多都是媒体方面的人来听一听各个公司的大佬们来讲故事。据说还有人是专门从南京过来这边参加活动的。我在现场还碰到了专门赶过来的天津大学老师。看来纯正的技术话题，对专业人士的吸引力还是很大的啊。
我作为这次活动的主持人，也是倍感荣幸。可以主持这么专业的技术研讨，感觉压力还是很大的。
讲演过程中，单霆先生回顾了他的创业经历，他很早就开始从事人脸识别技术在应用方面的尝试，以及投资界对于这个领域是多么的热切。然后又讲解了人脸识别的具体算法和这些算法的演进历史。很遗憾，算法的这一部分我没怎么听懂，这 一部分的内容确实有太专业了。不过看样子其他的那些听众还是听得很有感觉的。希望他们能够从中有所收益吧。
单霆先生在讲完了技术之后，还介绍了两个应用人脸识别的技术的产品。其中F ace-API是比较有趣的，直接将人脸识别技术封装成API放在云端，提供给那些想要使用这个技术的团队或个人使用。现场就有不少听众找他们要邀请码，希望进行尝试。
在正式的IT龙门阵活动之前的小范围沟通交流会上了解到，腾讯的陈波女士和他们的团队，也已经申请了Face-API的试用邀请码，并在Face-API的即时通讯群组中潜伏一段时间了，当天其实是单霆和陈波以及腾讯研究院的这个团队里面的一些成员的第一次线下网友见面，这个圈子看来还真是小啊。
陈波的演讲范畴要更加宽泛一些，包含多媒体模式识别和人机交互的很多领域。这位腾讯研究院的美女专家，首先纠正了大家的一个误解，她说腾讯现在已经改变了很多，现在腾讯已经是一家非常开放的公司了，愿意开放出很多的资源和数据，和大家一起创造财富。以前创业者总是担心会遭到腾讯同类产品的竞争，现在这种状况已经发生了变化，腾讯正在逐渐向着开发者和创业者的朋友的方向转变。
在陈波的演讲中，介绍了模式 识别和人机交互的发展历程，以及腾讯在这方面的一些尝试。她反复的强调，很多人现在对于模式识别的应用抱有过高的期望，这是不正确的。模式识别技术，还远远没有达到能够让计算机或智能设备达到人类识别事物的能力，在短期内，这还是很难实现的。但是，现在，特别是元计算的到来，为模式识别带来了重大的发展和机遇。使用现有的技术，已经可以做出很多有趣的，改变人们生活的应用了。腾讯利用这些技术，实现了手写和语音的输入，并通过图像识别技术，开发出了QQ慧眼这种有趣的产品。这个产品可以让人们在旅游的时候，看懂外文的路牌。QQ慧眼就是陈波女士的团队自主开发的。他们还有很多技术，被应用到了腾讯的其他产品之中。腾讯也会逐步的将这些技术，开放出来供更多的开发者使用。
两位专家结束了演讲之后，会场上的听众们向他们提了不少问题。这里面有些非常专业的技术问题，更多的则是现有技术的一些应用前景相关的问题。过程非常热烈，由此可见，大家对于多媒体模式识别技术在移动互联网领域的应用还都是非常感兴趣的。
最后单霆先生做的总结是：多媒体模式识别技术，可以是人机交互摆脱语言和文字的束缚，重新回归的更加贴近自然的状态。这就是在这个领域里面努力着的人们的共同目标。
IT龙门阵下一场的技术活动还在规划之中，现实增强、虚拟现实，或者云计算等主题，还没有确定下来。请大家拭目以待吧。
3 月 25
Luke Fan新文化, 梦想园 梦想园, 社区
好像有很长一段时间没有更新博客了。
最近在忙着一些社区活动的事情。后面的社区活动会越来越多。而且，周末时间还需要陪儿子玩耍，是不是能够抽出时间来写博客，还不一定。抽空写吧。
今天下午有PMI项目管理俱乐部的活动，上午就跑来办公室，趁着这一点点的时间，写一些吧。
最近组织、协办、参加了一些社区活动。也有了一些想法。现在先来写其中的一个。
所有公司里面和宣传，公共关系相关的部门，都刚刚度过了我们一年之中最重大的一个节日，这个节日是所有做公关的人都是又狠又爱的，那就是315。所有的中国公司，对于315这种东西的心态都是非常矛盾的。既希望315能够搞定竞争对手，同时也害怕315找上自己。这就体现了一个问题，所有公司都知道自己在诚信方面有所亏欠，但又都寄希望与老天睁一只眼闭一只眼放过自己，或者想着，我们只是为了一些小恶，社会上比我们罪大恶极的家伙多去了。这次不会轮到我头上的。
315也算是一个大话题了，这里要阐述的是另外一种比较小的诚信问题。那就是个人诚信、个人信誉。
诚信问题，分为很多方面。特别是有一些银行方面的信息，属于个人隐私，是不适合进行公开的。所以我所设想的个人信誉追踪系统，所追踪的也仅仅只能是个人或一些机构发表的公共言论，以及向公众所表达的一些观点的追踪和回溯。机构可以通过换人来快速的改变其信誉，但是个人不论走到什么地方，其信誉状况应该是不会发生跳跃性的变化的。所以我感觉，个人要比机构的信誉状况更加值得追踪。
记得很早以前在电视上看过一位大神级人物，讲解什么是诚信，那位大神讲道：为了远期利益，而放弃近期利益的方式，就是诚信了。诚信归根结底还是为了利益，并不是为了什么道德或真理、正义之类的东西。现在，很多的专家、学着、名人，在利用他们的声望，说着或做着一些事情，即使事后被证明了，这些事情可能有问题，他们也会放出，人总是要犯错误的之类的言语，来为自己辩解。甚至还有些可笑的人，做了不诚信的事情之后，堂而皇之的说，这是在牺牲小我，成就大我；牺牲个人荣誉，成就更大的利益。
这是为什么呢？为什么我们感觉有越来越多的个人或机构，变得不诚信了呢？我们无法相信社会，无法相信专家，无法相信其他的那些机构或管理者呢？当然，信任都是相互的，我们不信任别人，也不指望别人相信我们。归根结底，不诚信的成本太低了。诚信是为了远期利益，而牺牲近期利益的行为。那么不诚信就应该是不顾远期利益，而争取近期利益。但是如果人们在不择手段的获得近期利益的时候，对其远期利益基本没有损害，甚至还有所帮助，那么就不会有人选择去遵守诚信了。因为那是非常不划算的一件事情。
社会为什么需要诚信，这里就不讲了，相信大多数人都非常清楚。那么我们怎么得到一个诚信的社会呢？大的方面肯定轮不到我在这里胡说，那是党和政府考虑的事情。我们只能从一些小处着手，增加一部分人不诚信行为的成本。
我的想法是，建立一个跨平台的网络应用，能够让所有的用户讲他们看到、听到的事情记录下来。然后利用语义分析工具和人脸识别技术、声纹和语音识别等技术，对这些凌乱的信息进行整理，将信息以人为单位，以时间为顺序，进行归并。系统仅分析和记录那些公众场合发表的信息，图片、视频和语音信息，用户可以从各种新闻媒介摘要上传信息到系统中来。
对于一个事件，在系统的数据模型上，会形成一个节点。各个专家和学着、机构对于这个事件的观点会汇集在一起。系统可以自动的筛选出一些对于这个事件比较热心的用户来维护这个节点。并使其具备比较高的可读性。以方便其他用户的阅读并进一步的补充内容进来。用户可以在不同的时间段，对同一个事件，同一个人在这个事件中所起到的作用进行评判。社会大众在不同的阶段，对于同一个事情有不同的看法也是正常的，毕竟通常是需要日久见人心的。
人们也可以自己去上传一些自己的事件。大家可以去纠正那些错误的信息，这需要共识，然后找到一些共同关心这个事件的用户认可之后，才可以进行修正。被修正的内容，也不会被删除，而会作为被证实是虚假的信息，存放在系统中，用户仍然能够看到。
这个系统会通过众包的形式，搜集社会新闻媒体上面的公开新闻，然后让人们在不同的时期对新闻人物在新闻事件中所起到的作用进行评判。当事件随着时间的发展，前面那些人所说过的话，发表的意见，做过的事情，旁观者可能会给出不同的评价。这个系统存在的目的，就是为了让大家记住。记住那些人，在过去的那些事情上都做过些什么，让这些人的远期利益和他们现在的一些作为挂钩，让他们在做事情的时候，能够有所顾忌。让那些有信誉的人，能够享受他们牺牲掉近期利益所博得的远期利益，让那些没有信誉的人，在远期利益上能够受到相应的损失。
这个系统，是很理想化的，是否可行，是否有可能在现在的社会形态下出现，这都很难说。至少从技术上，是没有任何问题的。现在的微博数据，就完全可以支撑这种系统的运转。但是微博做得是严格的恪守时间线，如果出现了什么不好的事情，就可以通过另外的一些更加热点的事情，来增快用户遗忘的速度。只要将吸引力转移了，大家很快就会将事情忘掉的。当然也有一些认真的人，喜欢抓住别人的小辫子不放，比如方舟子之流。
我所设想的这个系统，就是希望能够有更多的人，能够通过系统来部分的实现方舟子那种很有研究能力的人才能实现的事情。方舟子在打假的时候，还是很有选择性的，这没有什么可批评的，毕竟他也要在这个社会下生存的。有了一套系统之后，大家通过众包的方式来搜集信息，搜集信息的时候，可以使用实名用户或匿名用户提交的信息，但信息必须是在公共媒体上发表的内容，或者是实名用户自己相关的内容。这样的话，那些提供信息的人们也就没有什么风险了。很多考证的事情，可以等到信息搜集起来之后再说，具体是采用人肉的方式，还是计算机算法，或者最有可能的是计算机算法和人肉相结合的方式，都是可以的。
那些曾经不诚信的人，或者是被其他人误解了的人，也可以到系统里面来解释，或者找其他人来帮其证明。
知错能改善莫大焉，总要给大家改过自新的机会。系统存在的目的不是为了让那些不诚信的人永远不溶于社会。而是希望能够起到一个威慑的作用，并能够告诉大家，善有善报恶有恶报。
此类系统到底有没有社会需求，这个事情很难说，但是从商业模式上来说，肯定是比较麻烦的。也许，能够用来作为某些诚信者记录自己工作生活状态的地方吧。最终成为一种媒体。
这个系统，只是我的一个设想，是不是有过类似的东西，本人不考证。设想这个系统的目的就在于：首先将现在发生的事情，记录下来。以后这些内容就是历史，不可磨灭的历史。让后人可以通过这些历史的记录来对参与到现在这些历史事件中的人们进行评判。
3 月 04
Luke Fan梦想园 LBS, 社区
今天下午去参加NTalks的活动，一群人坐在一起聊一个务虚的话题，那就是明年创业到底应该做什么方向。具体的内容，大家去关注NTalks吧，这里就不阐述了。
记得在最后，有一位先生站起来，问了嘉宾一个问题。在LBS中，签到的作用到底是什么呢？现在，一说到LBS，好像就必然有签到的功能。而签到好像也成为了LBS应用的一个标志性功能。但是，签到到底能够为LBS带来些什么，好像谁也说不大清楚。
那位VC嘉宾，作答。他说，他也曾经为此困惑过，于是就跑到foursquire去询问。却被告知，签到对于foursquire的作用很简单，就是快速的矫正POI。签到本身并不重要，重要的是持续的低成本保持POI信息库的及时性和准确性。
那位提问的先生还在不断的表述，签到是多么的有趣，大家如何比赛，如何在twitter上建立四方党，然后互相比较签到的次数，互相炫耀通过签到所得到的荣耀等等。
由此可见，签到并不应该成为LBS的标志性，甚至核心性的功能。但是通过增加游戏性，甚至直接通过一种签到游戏，来低成本的，依靠众包的方式建立其POI信息库，这是一件非常有趣的事情。对于LBS应用来说，不断的更新和矫正POI信息库，无疑是最重要的。国内的项目，当然可以用签到的方式来达到这个目的，但也可以想出一些其他的，更有趣的方式，来实现这个目的。重要的在于游戏性，而不是签到本身。通过在更新和矫正POI信息库的这个众包过程中加强游戏性，来调动用户的积极性，使得他们愿意参与到这个过程中来，不厌其烦的，一次又一次的提交POI信息数据，这才是最重要的事情。
国内的LBS应用，多是采用爬取或购买的方式，来实现初始POI信息库的构建。然后问题就出现了，用户矫正的信息，是否应该快速的替换和矫正那些购买到的信息呢？换种中国人比较容易接收的说法，是不是要用免费得来的信息，去替换那些花钱买来的信息呢？由于数据分析和过滤的能力不强，所以在取舍的时候，大家都很纠结。到底是相信用户的数据，还是相信买回来的数据？
记得以前使用切客的时候，由于POI推荐算法极烂，基本上当前所在的位置，很难出现在第一屏的推荐列表里面，于是大家就都喜欢开荒，最终的结果就是，对于一个poi，会有很多很多的地名指向它。
总之：去重、搜索、过滤和推荐，应该是维护POI信息库的最基础算法了。如果这些算法最终无法达到比较好的用户体验，那么设计再有趣的游戏，意义也不是很大。当能够满足基本需求的时候，就需要设计一些有趣的，游戏性极强的方式，来调动用户的积极性，维护和更新POI信息库。
对于国内的LBS应用来说，首先应该注重服务本身，也就是Service。在服务的体验能够让用户满意的情况下，再想办法设计一些小游戏，让用户帮忙提交POI信息。从重要程度上来分析，第一重要的是服务本身，然后是服务的体验，再然后，才是如何增加用户使用过程中的游戏性，使得用户能够主动的参与到POI搜集和维护的行列中来。签到，仅仅是这其中的一种形式而已。
2 月 21
Luke Fan梦想园 梦想园, 社区, 阅读
RSS阅读，对于我们这些人来说肯定是一天都离不开的，但其实这也是一个小众应用。
我个人对于RSS阅读的需求是这样的：
- 多平台的书签同步，标记那些读过，哪些未读。
- 不论源提供的是什么样的，所有的内容都分为标题、简介和全文三种状态，也就是说对于那些不提供简介的，要自动生成简介，对于那些不提供全文的要自动提供全文。
- 移动端的图片，进行预先的处理，下载的内容预先压缩，比如生成类似于epub的格式。
- 自动去重，如果我订阅的各个源之间，都报道了同一事件，那么就要去除重复的内容。
- 智能内容推荐，推荐那些热门的内容，推荐那些我好友关注的内容，推荐那些有趣的，新的源。
- 智能过滤，当我的时间比较紧张的时候，按照优先级和重要度，筛选比较重要的内容发给我。
- 提醒，当某些特殊事件发生时，主动的提醒我。
- 归纳总结，定期，比如一天、一周、一个月，出一份总结性的杂志。可以离线阅读。
- 分享和关注，分享我的阅读体验，关注我好友的阅读过程
- 将所有源的所有内容，按照类别进行分类、去重，然后按照类别进行阅读
我目前主要在使用Google Reader，IOS端使用的是Reeder。主要的功能是可以满足的。但是Google Reader是按照时间和源为基础来管理内容的。我希望能够安装状态和优先级、类型来进行组织和排列。
希望能够有跨平台的RSS离线阅读工具。
较为重度的RSS阅读者，对RSS阅读提出的想法。
1 月 30
Luke Fan新文化, 杂谈, 梦想园 团购, 服务, 梦想园, 电子商务
现在有各种各样的稀缺资源，比如说高峰时间的餐位。那么就需要排队系统。来帮助用户和商家进行双向选择，以实现各种稀缺资源有序的分配。
现在有很多预约系统来解决这种问题。
但是，商家所需要的其实并不是简单的预约系统，而是解决两个问题：
第一、削峰填谷
第二、有效的选择客户
第三、降低赚取同样资金所消耗的时间和其他相关成本
削峰填谷自不必说，高峰时期接待能力是有限的，商家肯定希望在低谷时期能够多有一些人来消费服务。
下一件事情也就显而易见了。既然在高峰时期，服务接待能力是有限的，那么就需要选择用户了，让有限的资源尽可能为更合适的用户服务，以便赚取更多的利润。目前商家通常是通过三种形式来选择客户的：
- 熟客，熟客肯定是需要优先服务的，即使为了他们牺牲一部分服务时间，只要是预约，那么就必须让服务资源空闲下来，在外面有人排队的情况下，等待预约的客人。这是不划算的，但是熟客的预约在使商家承受这种损失的同时，达到了广告的效果，可以让熟客的忠诚度和黏着度进一步提高，因为熟客享受到了特殊的服务，在别人排队的时候他先进去享受服务了，这是一种身份的尊崇，也是商家提高自身地位的一种手段。这是一种榜样的力量，可以促使其他用户成为熟客。最后，熟客还会经常在非高峰时段过来消费，这也可以弥补一定的损失。
- 有偿预约，上面说了，空出服务资源来等待预约的客人，这本身是有成本的。那么如果客人愿意支付这个成本，空着也就空着了。
- 客户选择，单位时间内并不是接待的客户越多，就越赚钱。每个客人的消费能力不同。所以，应该是在单位时间内，接待的消费能力高的客户越多，就越赚钱。商家总是在想方设法的选择那些消费能力更强的客户，比如在高峰时段提高价格，比如为预约的客户设定消费下限，等等。
在高峰时段，如果已经选择好了客户，那么还能做的最后一件事情就是尽量降低为这些客户服务的时间和其他成本。这个放在饭店里面来说，叫做翻台。也就是一桌客人吃完了，将桌子清理干净，再请下一桌客人用餐。提高翻台率就是各个饭店在高峰时段所期待的东西。饭店通常是通过推荐推荐当日特色菜，建议用户点选某些可以快速烹调的食物，在高峰时段不为那些非预约的用户提供那些难以在短期内完成的食物，比如正宗的佛跳墙，等手段来实现这个目标的。
推荐的特色菜，通常是需要较长时间烹饪的，饭店会统一准备好一大批成品或半成品，然后希望用户尽量集中的点选这些食物，以缩短服务时间。另外一个饭店里面经常采用的方法，就是让用户在等位的时候，完成点菜，甚至是付款，这样也可以有效的缩短每一桌客人的服务时间。
预约服务，其现金流通常是来自于商家。所能够为商家提供的服务，分为三个层次。
最低层次、帮助那些即使在高峰时段也没有用户登门的商家做广告，告诉用户周六的午餐，旁边那家不需要排队。
中间层次、帮助商家向用户收取有偿预约的费用，最后和商家进行分成。不过这个盈利方式有违目前的消费习惯，很难大范围的推广。
最高层次、帮助商家筛选客户，将消费能力高的客户筛选出来，并帮助商家培养忠实的熟客。引导客户在非高峰时段，享受一些高峰时段难以享受到的服务。
附加的服务，则是帮助商家向用户推荐商家希望推荐的某些特定服务，帮助用户在预约的时候，就直接将各种所需的服务做好选择。
这里只说了为商家服务，却没有提到为客户服务。这是从现金流的角度出发的。这是属于矛盾的两个方面，如果一个服务和应用，没有用户来用，那么对于商家来说也就是没有意义的。为用户提供准确的信息，做出能够实现的承诺，完成用户所需的服务，这是必不可少的。但设计的初衷，还是应该为商家服务。因为，预约服务，都是在消费高峰期才需要的，而消费高峰期的时候，通常是卖方市场，首先是商家挑选用户，然后才是用户的双向选择。
希望能够有一个非常棒的预约服务，来帮助我选择中午去什么地方吃饭。
1 月 02
Luke Fan新文化, 梦想园 LBS, 新文化, 时间, 梦想园, 社区
帮助人们实现梦想的系统
前文已经写了很多内容，那里面其实已经将系统的结构和工作方式都讲过一些了，但是这里还是想再将这两个部分分拆开来，分别讲述一下。
本文主要是想要讲解帮助人们实现梦想的系统，可能会拥有哪些模块，哪些参与者，以及这些模块和参与者之间是如何在系统中进行互动的。
本文包含的内容，应该会比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 总结
好像又停更很长时间了。最近在忙盛大云计算大赛的事情，我负责去点评所有的作品。里面有不少作品都提到了学习和帮助别人实现梦想。看来这是一个很多人都在关注的热点啊。
不能保证下一篇什么时候出来，只能说我也是希望尽快的。本文讲了系统的一些基础架构，下一篇希望能够讲一讲这个系统的实现过程。当然也可能下面会写一些其他的东西，然后再继续写这个系统的下一篇博客。
12 月 16
Luke Fan梦想园 梦想园
云计算其实是中国人发明的。
很多人看到这里可能就笑了，云计算这么先进的东西怎么会是中国人发明的呢？
中国的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、新浪、腾讯，甚至是盛大那样的公司。
结论
云有好多种，这些云是在中国人根深蒂固的中央集权的思想引导下，逐步演化产生出来的，适应于不同类型的用户和应用。不同形式的云，应该还会并存很长的一段时间，这是一个社会分工不断细化的过程，是社会生产力上升的一个标志。每一个层次的人，专心致志的做好自己的事情。选择任何一个层次的云计算，不论是选择构建云计算的服务，还是使用这些服务为最终用户提供服务，这并没有高低贵贱之分，只是社会分工不同罢了。
当然，中国人也还会凭借着自己的聪明才智，不断的创造出更多，很稀奇古怪的云应用和服务方式来的。
云计算是一种真正革命性的，会真正对每一个人都带来影响的东西。就像中国人的其他发明那样，不论是否理解，不论是否喜欢，都必将为人类带来全新的未来。
12 月 08
Luke Fan梦想园 云计算, 梦想园
今天在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服务的上线，会不断有新的应用涌现，让我们来共同期待吧。
11 月 28
Luke Fan新文化, 杂谈, 随笔 Bambook
周一早晨和大家分享一个故事，
昨天，老婆送给他们一位退休的老领导一个bambook，他们老领导还特意自己买了100元的盛大充值卡，准备充值了去购买一些传统名著。
但是绑定账号和充值的过程总是有问题，于是拿回我家来，让我帮忙处理。
结果，sdo的网站时常打不开，云城的网站也时常上不去，绑定账号也报网络异常或超时。当时搞了我一个满头大汗。虽然对bambook没有做出过什么特别的贡献，但至少我自己是一直都自豪的当bambook是自家的产品。现在牛吹出去了，自家的产品却掉了链子，实在是觉得面上无光啊。
晚上，辗转的找到了负责服务器的相关同事，他热性的帮助我确定了问题所在，原来是北京地区联通的主DNS服务器发生了故障，所以每次域名解析出来的IP都会有些问题，除了我们的那些网站之外，很多国外网站也会发生解析故障的问题，将DNS调整为8.8.8.8，一切正常了。
当发现问题不是出在我们自己身上的时候，我和那位远在上海的同事都长出了一口气。
那位同事说他早就已经习惯了，由于bambook在我们公司内部的普及率非常高，所以出现任何问题，大家都会马上找到他，每次处理了问题之后，也都会长出一口气。这就是对自己产品的热爱了。大家也都会将bambook当做自家的产品，所以出现了任何问题，也都会很不见外的直接找到能够解决问题的相关同事。
记得99年去日本，当时接待我们的日本JVC公司特机（相对于民品来说，专业设备叫做特机）事业部，海外本部的本部长。这位为JVC工作了一辈子，快要退休了的日本大企业中高层管理干部，和我们一起去游览秋叶原。他拿了一个olympus的数码相机，当时数码相机还算是个稀罕玩意儿，并告诉我们日本的产品质量是很好的。正说着，那个相机出现了故障，伸缩镜头被卡住了。那位快60岁的老先生，当时就憋了一个大红脸，而且满头大汗。反复尝试之后，发现是他自己的操作有误，并不是产品质量有问题之后，长出一口气，然后很欣慰，也很开心的告诉我们，日本产品的质量确实是很好的，他老了，对于新产品不是很熟悉，刚才只是他自己操作不当，绝不是产品质量出现了问题。
当时不是很理解这种心态，现在回想起来，真的是理解了。这就是一种热爱，让我们用这种热爱，来做好我们的产品吧。我们在做产品不是为了完成什么指标，而是真的在做自己的产品。
Older Entries Newer Entries
RSS
