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岁的老先生，当时就憋了一个大红脸，而且满头大汗。反复尝试之后，发现是他自己的操作有误，并不是产品质量有问题之后，长出一口气，然后很欣慰，也很开心的告诉我们，日本产品的质量确实是很好的，他老了，对于新产品不是很熟悉，刚才只是他自己操作不当，绝不是产品质量出现了问题。
当时不是很理解这种心态，现在回想起来，真的是理解了。这就是一种热爱，让我们用这种热爱，来做好我们的产品吧。我们在做产品不是为了完成什么指标，而是真的在做自己的产品。
11 月 21
Luke Fan杂谈
以前办比赛的时候遇到过一个问题，就是作品如果让用户来打分，就会出现有些作品只有几个人、甚至是一个人打分，但平均分数极高；而有些作品打分的人数很多，但平均分却不是很高。感觉按照普通平均分的方式来计算好像不是很公平。投票要省事儿得多，投票算的是累加。打分的话，如果有一个作品被打了很多5分制的1分，累加起来，可能也会比那个只有几个人打5分的数量多，所以肯定是不能累加的。
上学的时候，数学没有学好，于是只能去请教别人。感觉应该不是一个很复杂的统计问题。老婆是医学院的英语老师，于是就求她去问了问她的学生。
她的一个学生看来我的问题之后，表示这确实是一个最基础的统计学问题，并给出了一个医药方面的类似统计例子。
有两个医疗方案，进行临床试验，并统计否定率。
| |
甲方案
|
乙方案
|
|
不喜欢
|
220
|
20
|
|
喜欢
|
9780
|
980
|
|
合计
|
10000
|
1000
|
|
否定率
|
22‰
|
20‰
|
从表面上看，甲方案的否定率（22‰）高，应当放弃。但这里的问题就和我们用户打分时遇到的问题很相近了：
甲乙两个方案的评价人数过于悬殊，因此某些不可忽略因素的构成差异十分容易造成假象。
比如现在考虑选举者的年龄分层
|
年龄组（岁）
|
甲方案
|
乙方案
|
|
评选人数
|
不喜欢人数
|
否定率（‰）
|
评选人数
|
不喜欢人数
|
否定率（‰）
|
|
＜45
|
4000
|
40
|
10.0
|
800
|
10
|
12.5
|
|
≥45
|
6000
|
180
|
30.0
|
200
|
10
|
50.0
|
|
合计
|
10000
|
220
|
22.0
|
1000
|
20
|
20.0
|
这个时候就需要用率的标准化，也就是说需要让每个年龄段评价两个方案的人数一致。
怎么让人数一致呢，比较常见的做法是用各个分层的总人数代替之前的人数，比如4000+800=4800，换句话说就是假设找4800个小于45岁的人从新来评价甲乙两个方案。
|
年龄组（岁）（1）
|
标准人口数（2）
|
甲方案
|
乙方案
|
|
否定率（‰）（3）
|
预期否定数（4）=（2）（3）
|
否定率（‰）（5）
|
预期否定数（6）=（2）（5）
|
|
＜45
|
4800
|
10.0
|
48
|
12.5
|
60
|
|
≥45
|
6200
|
30.0
|
186
|
50.0
|
310
|
|
合计
|
11000
|
18.0*
|
234
|
27.5*
|
370
|
标准化后的甲方案否定率：234/11000×1000‰=21.2‰
标准化后的乙方案否定率：370/11000×1000‰=33.6‰
这时候，明显乙的否定率（33.6‰）远远高于甲的（21.2‰），卡方检验也可以证明差别有统计学意义。换句话说，乙方案由于样本量较小，且有参选人中年轻人比例过高（80%），导致否定率较低，实际上乙方案在中年大叔中是不受欢迎的！
以上是不完全假设，因为谁也不能保证“某些不可忽略因素”都能被找到并且分层出来。
以上的这个例子，是学习医学的人提供的例子。
那么网络投票怎么办呢？关键还是在于如何划分打分用户的来源。我们恐怕很难搞清楚用户的年龄和性别。具体考虑哪些不可忽略的因素，又忽略哪些因素呢？这肯定没法做到绝对公平。而且，他给的例子计算的是否定率，而用户打分打回来的肯定是5分制或10分制、百分制的一个数字。估计在统计学里面应该还会有更加贴近的这种应用的算法。但是我觉得可以直接采用一些相对公平的简单方式来进行处理。
我的想法是这样的。首先，增加用户打分时的操作成本是不可取的，也就是说让用户提供额外的个人信息，以便我们来进行分类，这是不可取的。因为，这有可能会极大的降低用户打分的数量。
那么，我们可以使用的，也就是用户打分时的IP地址了。可以通过IP地址来分辨出用户来自于哪个地区。全国有三十几个省级行政区划，如果按照这个来分的话，好像又太过细碎，而且各个省级行政区划之间的发展平衡度差异极大。也许可以对这些数据进行合并，将一些参与人数很多的省份，和参与人数很少的省份进行合并，最终形成五到十个相对平衡的区域，海外投票如果有的话，根据数量可以放在一起，也可以加入到某个地区的票里面。毕竟这里需要的只是一个完整的统计数字，并不像苹果的AppStore那样，需要考虑到给各个国家和地区出分别的排行榜。
将所有的打分数据人工的分为五到十个相对平衡的区域之后，再按照上面的那个方法，分别计算出，给予各个分值的人数，占的总比例。最后，我们能够得到的就将是，百分之几的人给了5分、百分之多少的人，给了4分，等等。现在，每一个作品打各种分值的人数的百分比加起来，肯定不会等于百分之百。比如：一个作品进行5分制得评分，经过上面那个公式计算之后，可能计算出：
| 打分比例 |
分数 |
| 4% |
5 |
| 3% |
4 |
| 10% |
3 |
| 3% |
2 |
| 0% |
1 |
计算得出：(3%*2+10%*3+3%*4+4%*5)/(3%+10%+3%+4%)=3.4
也就是说，这个作品的平均得分是3.4分。
这种计算方式，可以部分的解决网上打分的计算问题。这里面还有一个问题，就是有些作品的传播做得很不好，在某些区域里面就没有任何一个人给他打分。那么如果是一个互联网或移动互联网的应用，没有达到传播效果的话，肯定是不行的。可以将该地区起始平均分设置在一个比较低的位置，比如是2分，这个地区参与所有项目打分的有效人次，如果是1000人的话，那么没有在这个地区得到任何一个分数的作品，就可以按照这个作品在其得到过打分的区域里面的平均打分率，在这个区域中得到那么多个2分。也就是说这个作品，在其他区域，平均得到打分的几率是10%，也就是说会有10%的人给这个作品打分，那么在这个区域1000人次参与，却没有任何人给它打分的区域中得到10个2分。
以后是不是会将这套计分算法用在其他比赛中，还不确定。如果有些比赛遇到了此类问题，倒是不妨拿来一试。任何方法肯定都无法保证绝对的公平性，只能尽量公平，以后即使真的有机会去应用这套计分方式，也肯定还会根据具体的情况进行参数上的调整。
本人没有学过统计专业，上学的时候统计方面的东西学得也很是一般。这里也仅仅是拿着一个道听途说的公式来生搬硬套。如果有什么不对的地方欢迎指正，没准以后某此比赛上，这套东西就能用上，不要让我这个连半瓶子醋都没有的人，耽误了那些参赛者的热情。
11 月 18
Luke Fan杂谈, 随笔
校车出了车祸，这是因为什么呢？这是因为校车超载了。
那么，让我们来治理超载校车吧。首先要把责任搞清楚吧。
那些学校将校车服务承包给私人了吗？也许吧？那么，是那个承包校车业务的个人他不顾学生的生命安全，为了追求更高的经济利益，开着超载，也许还是超龄服役的老旧破车上路了吗？也许吧。那么，是不是所有这一切都是那个校车承包者个人的行为造成的呢？
可能这个开校车的司机，也是勤勤恳恳的在工作，赚取一点点微薄的工资。那辆车也许是老板的，他可能只是被老板雇佣的打工者。好吧，这个事情看来也许也不应该怪司机，应该怪那个承包校车，并雇佣司机的老板？
老板可能也很痛苦，校车的竞争很激烈，学校拿不出更多的钱，学生也拿不出更多的钱了。运送单位学生的成本是恒定的，用这些钱可能没法使那辆破车保持足够良好的运营状况，如果按照核定载员来承运那些学生的话，这个成本肯定是不够的。汽油涨价了，司机的工资也必须要涨了，司机也要吃饭、养家糊口、甚至还要住房子，按照劳动法，还要跟司机签订劳动合同，还要给司机买三险一金。这些都是成本。即使是再破的车，想要在路上跑，交警那里怎么着也是要去孝敬一些的吧？这些也都是成本啊，承包校车的小老板，也许是个人，不是一个很有奉献精神的人，他不能自己贴钱来做这件事，即使能够贴一些，也不能长期的贴下去吧？毕竟人家也要养家糊口的啊，没准儿还要住房子呢。
那么多的破车，学校为什么就能把校车的生意包给这个老板呢？是不是学校的领导拿了回扣呢？
学校的领导那么多，又不是哪一个人就能够说了全算，谁没有个七大姑八大姨啊？大家也不能做得太过分吧，老师们也很清苦，有了好处大家也都要稍微改善改善吧？
看来这个事情，学校、校车的承包者、司机好像都有些责任，又好像都没有什么责任。
出了这么大的事情，死了那么多的人，总要有个人出来负责任吧？也许这仅仅是那个司机的个人行为吧，毕竟这样就可以将事态压缩在最小的范围内了。
下面就要解决这个校车的问题了。
也许可以再开个培训班什么的，可以给开校车的司机发个证书，那样的话，交警部门没准儿还能增加一些收入呢。为什么还能有人在这个事情上发财？那是当然的了，交警部门的警力也是很紧张的，增加了他们的工作，肯定也是有成本的啊，这是无可厚非的啊。以后必须是有了校车证的司机，才能够开校车，而且如果有了违章，则终身不得再开校车了。现在好了，有校车证的司机成了稀缺资源，司机考取校车证也是需要支付成本的，那么校车司机的工资就要涨了，好在天朝还不会出现校车司机公会这种扯淡的东西。总之，校车运营的成本也就上升了。学校可能无法承担这笔费用，那么为了让学生能够准时、安全的抵达学校，只能采取两种办法，向学生多收一些钱，或者偷偷雇佣黑校车。看来这个方法有问题，而且也还没有解决破车上路的问题。
那么，政府统一招投标一款专用的校车吧，这种校车由政府集中招标，然后发给校车准入证，没有这种准入证的车辆不能成为校车。学校或承包校车服务的企业，只能购买这种有准入证的校车来运营。车况也是个问题啊，好吧，让车管部门，专门为这种校车，制定一套严格的检验机制，每年四验，拿不到验收合格证的车辆禁止上路。
在这个过程中，需要招投标，如果是各省组织的，那么车企就需要到各省去公关，如果是全国统一的那么就需要跑部了。这都是成本吧，这些成本都需要摊入车辆的价格吧？验车也是需要费用的啊？政府的机构工作那么忙，编制那么紧张，还要额外的增加工作量，这总不能是免费的吧？成本又上升了。学校和学生的负担又加重了。这好像也有问题吧？
学校承担不起那么高的成本，那么就只能雇佣黑校车了。这个要杜绝啊。校车服务统一招标吧，由各地区的公交、出租等公司，购买有准入资格的校车，聘用有校车证的司机，去各地区的教委招投标。中标的承包该地区所有学校的校车服务。
招投标这种事情，就是这样的，如果彻底没有利润了，也就没有企业愿意去了。那么就必然是有利润的，原来是学校自己包车，这个盘子比较小，现在权利集中了，整个地区的学校统一招投标，现在这个盘子就大了，那么为了得到这份大合同，就必须支付更多的公关成本吧。原来只是学校里面几个领导们分一分就够了的回扣，现在需要去拜教育局领导的码头了，盘子变大了，领导升格了，那么需要孝敬的东西是不是更多呢？这个不好一概而论，不敢说所有的地方都搞潜规则，但是估计也没有任何人能够保证：绝对没有任何地方敢在这笔钱上伸手。总之成本上升了，总要有人来承担这笔成本吧？教育口的钱，也是一个萝卜一个坑，只会不够花，绝不会出现剩余的情况吧？
现在需要解决的就是根本问题了，那就是钱的问题。
国家有钱修高速公路，这个对地方的经济建设有帮助的，比较重要，不能动啊。国家也有钱修高铁的，虽然这个东西的安全性并不比校车高多少，但是这个也是对地方的经济建设有帮助的，也不能动啊。国家还到国外去购置大量的飞机，这个关系到国家的形象啊，更加重要了，更不能动了。发射神州飞船和天宫太空站好像也花了不少钱的吧？这个好像扯得比较远了。总之，大家都困难啊。地主家也没有余粮啊？好钢要用在刀刃上不是？
即使国家给钱了，至少可以印些钞票或加税吗？这样也许还能缓解一些人民币的升值压力，CPI的上涨也不差这一星半点儿。这样就可以了吗？
那么通常的做法都是国家给一部分，各级地方政府再给一部分，学校也要自筹一部分，也许还是会有一些负担落在学生的身上。这个事情就热闹了，权利通常是和义务对等的，每一级出了钱的政府，在这个事情上肯定都是有一定的发言权的。比如是不是应该适当的扶植一下本地企业啊？本地企业在服务方面是不是可以做得更好啊？或者有些地方确实是太困难了，给领导们盖宿舍楼的钱还没着落呢，是不是可以先挪用一下啊？毕竟领导们是要为人民服务的，他们要是休息不好，怎么能够更好的为人民服务呢？好钢要用在刀刃上啊。
当然，肯定也不是每个出钱的，都能够有话语权的，比如那些学生，他们可能也要出钱的，但是他们肯定会被他们所信任的领导们代表着行使他们的权利。
这还不是最麻烦的问题，最麻烦的问题是，这个里面涉及到了太多的机构和部门，太多的地方利益和部门利益。就像是内蒙大堵车那样，有些地方为了地方经济的繁荣，以罚代管，将超重卡车罚一笔钱放行了。到了帝都之后，这里秉公办事，必须卸载，超载车辆就不允许进京，必须在卸载场将超载的部分卸载下来，然后分批运送进京。这个效率就低了，必然造成大堵车。现在，搞校车工程了，也必然会遇到这个问题，每一个地方、每一个部门、每一个地方的每一个部门都会有他们自己的问题和具体情况，他们可能在执行的效率、时间和程度上有一定的差异，那么是不是也会出现以罚代管、设置路障进行突击大检查，以及超载校车的卸载站呢？谁也说不好啊。
为了保留竞争，或者说是中央和地区、地区领导之间互相也要给些面子吧，搞些平衡，抹些稀泥，那么也许一个地方就会出现多家校车企业，那么会不会像是某地的电信企业互相剪线，并斗殴那样，将校车开成碰碰车呢？没有任何人能够保证这种事情在天朝这么大的行政区划下就不会发生。
难道这个问题，即使依靠印钞票或者加税都无法解决吗？其实也不一定的。每件事情都是有解决的方法的。
记得在一本架空官场小说里面看到过一句话，认真起来的我党干部，是无所不能的。这个我是绝对相信的。好像是很多年前，有一位地方领导曾经在电视上说过，老大难问题，老大一管就不难了。但是这几年好像再也听不到这种声音了，那位记不清是什么地方的老大，也许遇到了什么连他自己都搞不好的事情了吧。至少是在这么复杂的环境下，轻易的做这种表态，实在是太不够稳重了。
话题扯远了，校车问题，如果想要彻底解决，必须在国家层面上立法，并且统一提供全部的资金，搞上一两家大企业，统一发放企业牌照，招标设计符合中国特色的校车，然后委托多家汽车厂进行统一的生产，就像二战的时候美军生产吉普那样。让那一两家超级校车企业，在各个地方建立分支机构，使用统一培训出来的司机，开着统一采购来的校车来为各地学校进行服务。根据学校的规模，配足所需的人员和车辆，建立充足的配件库、设立备用司机和校车。为公立学校、私立学校、农民工子弟学校、贫困地区的希望工程学校提供统一的服务。然后，由国家定期的向这些企业进行补贴。可以按照实际运送学生的人次进行补贴。然后再立法，对这些车辆进行免费的养护和检测、这些校车可以免费的通过各种高速公路，可以行驶在公交专用道，甚至是在某些城市的某些特殊路段施划出专门的校车专用道和停靠点，以及各种各样的校车优先规则。
这样就能解决问题了吗？
好像还没有彻底的解决问题，那种巨型企业总是很大、很臃肿的，而且他们的领导很喜欢喝高档白酒或洋酒。组建这么大的企业，浪费那么多的管理陈本，解决校车的问题是否划算呢？
天朝喜欢在他们认为是关系到国计民生的重大领域组建这种超级公司，比如那些喜欢喝昂贵白酒的大公司、比如拿着入网牌照互相剪线缆的公司，还有那个遇到下雪和高温，都会让大家用不上电的公司、甚至有些像是企业，但又大到没法变成一个公司的东西，只能作为一个部委，这个部委还可以发行债券，并用这些债券修建高铁。
校车，肯定也是一件关系到国计民生的大事，一点儿都不比高铁、电力、石油和通讯差。我们既然已经为了那些关系到国计民生的重要的事情，养活了那么多的巨型企业，承受了他们的亏损，为他们的高价白酒和洋酒买了单，那么也让我们来为孩子们每天都能够有一个安全的出行方式来买单吧。
这里只是我自己的一些牢骚而已，作为普通的一个群众，坐在这里指点江山，也就是图个自己痛快。真正能够代表我做出决策的领导们，他们所了解到的信息肯定要比我多得多，既然我们已经通过层层的选举，将他们选了出来，那么他们肯定能够代表我做出比我更英明的决断，即使这些决断我并不能理解，也没有什么关系，谁让咱是不明真相的群众呢。
Older Entries Newer Entries
RSS