1. 所有公司都已经是某种程度的数据驱动。
2. 数据驱动不是增长的充分条件，也不是必要条件。
3. 数据很贵，性价比一般。
4. 数据的目标分为三个层次：观察、描述、行动。
5. 数据只能驱动符合特定模式的问题持续改进。
6. 数据项目也是项目。
7. 没有银弹。
—
图好玩的一个戏仿，不要当真。
数据哲学论
3
分类目录归档：观点
为什么感觉豆瓣在走下坡？
知乎上的一个问题：http://zhi.hu/WhTD
—–
豆瓣的问题在于它太过偏执于“长尾”(1) 和“自发秩序”(2) 了。
如果你仔细看，豆瓣的大部分产品都遵循类似的思路：首先满足用户的“长尾需求”，再想办法把同质用户汇聚成组，最后相同兴趣用户的组内行为可以形成正反馈强化整个系统的运转。当然，具体到实现这个流程的方式还可以再细分，比如利用算法的（FM）或者利用社交网络（小组）来分组；“组”的概念比较弱的（书影音用户利用友邻关系和猜你喜欢形成的“隐性组”）或者形式感非常强的（小组、九点、广场、阿尔法城）。
大体上讲，虽然单个产品各有成败，但沿着这个思路去解决用户的“长尾需求”是没有大问题的。
问题在于豆瓣把这个思路贯彻到了偏执的程度。于是就有了不断重复的广场、部落、阿尔法城这些“自发生长”的理念高于用户实际需求的“玩意”，以及在有热点的垂直领域里也偏去玩草根 provider 和 consumer 的小圈子——读书的征文比赛、音乐人、同城的小型演出票务（可惜没有一个的草根电影人圈子，不然就圆满了）。甚至在运营、推广层面也践行“不运营，自生长”的策略 (3)。
但是如果按照长尾（帕累托）分布不严谨的表述“20/80法则”来看，费了这么大力气满足的可只是20%用户（对长尾里80%事物）的兴趣……
当然这其中有一些美好的假设，比如从长尾中涌现80%人会感兴趣的热门内容。的确，豆瓣里也涌现出了“失恋33天”这样的 case，但是最终把握住这些 case 的可不是“不运营”的豆瓣。至于《长尾理论》里暗示的“随着互联网的发展，用户数量/兴趣曲线会变平缓，整体长尾化”也好像并没发生。
回到问题“为什么感觉豆瓣在走下坡”，“感觉”两个字用在这里很好。豆瓣也没走下坡，书影音评论这看家的东西不还好着。只是这些年早前就不关注长尾而是玩热点的别人家已经把制造热点这个事情玩烂了，现在都去忙移动互联网和穿戴计算了。而豆瓣还在这儿纠结“长尾”和“自生长”纠结了六七年了，自然让人有种不进则退的感觉。
一定要说个原因，大概就是世界不是豆瓣想像的那个样子吧。
1. 长尾年代，http://book.douban.com/review/1095674/
2. 豆瓣是一座仁者见仁、智者见智的城市，http://www.douban.com/note/12053438/
3. 杨勃：豆瓣社区不运营 用产品来表达，http://tech.163.com/…
随记二三
Opera Unite: 所有电脑都是平等的
只不过一些电脑比另一些更加平等。。。
Opera Unite的视频告诉我们：现在服务器统治了Internet，但是每台电脑都应该是网络上的一等公民，所有电脑都是平等的。
不过如果仔细看一下，Opera Unite的文案就会发现，其实有一些电脑比另一些电脑更加平等……
引文：“The interaction is all done via a central Opera Unite server — Opera Unite uses a proxy between the server and its clients (found at operaunite.com) to avoid the need for any special firewall configuration.”
如果我没理解错的话，拿这东西做File Sharing大概不会比QQ传文件或者开心网盘好用吧。。。
也许轻量级的小圈子social应用有用武之地。不过单点瓶颈，所以对墙的免疫力几乎是零，即使所有用户在一个局域网内。
Java on GAE
抓紧时间撇几句。这个东西还蛮值得一提的，当然更重要的不是Java on GAE，而应该是JVM on GAE。
于是反而得归功到M$当年搞了.net clr，这逼着sun这边应对出了JRuby、Groovy等等。
现在jvm一上gae，很容易就可以联想出GRails on gae（进行中），Rails on gae（这个相对难一些，因为gem等等）。总而言之，对于诸如我这种非专业pythoner，生活一下幸福多了。
当然，对于像我一样的半专业javascripter，其实还应该记得伟大的Rinho~ 所以Helma（以及同质物） on gae应该没准已经可行了吧~ 等我熬完论文一定要试一下，囧~
Some Solutions for Pure-javascript Web Application
——–闲着没事备忘下，完全是因为在windows上装couchdb失败后无聊所致——–
其实3年多之前还挺瞧不起js的，结果这几年混下来，糊里糊涂js就成了自己第一称手的语言。
用得顺了也就喜欢起来，而且很多时候js的表达力也挺强的。所以虽然RoR也一直在手边没放下，但是也挺留意用js写server端的项目。毕竟短期来看无论flash还是sl都不能让browser是逃不出js的掌握，如果有特别合适的js写server的东东，我就可以把RoR扔了，完成自己的语言大一统，XD——当然到现在也没看到特合适的，囧。
归正传，题目所谓Pure-js Web App就是只用js这一种编程语言通吃Server和Client端。目前这种项目数量倒是挺多的，不过粗劣分一下类的话，大面上也就两类种东西：一个是维持现在Client-Server-DB这种3-Tiers的体系结构，只是把Server端的编程语言从java、php等等换成js；另一类相对好玩一点，这类基本上抹掉了Server这层，体系结构变成了Client-DB，而全部所谓的业务逻辑代码全都移动到了browser的html页面中。
先说第一类，这类我最早关注的一个是helma——这个是最纯粹的用js写server。我还比较喜欢这个项目：部署简单，内置了jetty，默认情况解压直接跑（其他很多项目需要部署到其他的http或者servlet server中）；内建了一个基于xml的对象数据库，不用一开始就配mysql（也可以用mysql）；server和app管理和调试工具；文档全；良好的MVC支持。不过helma也有这类的server-side js的通病，他的定位是用js替换php、java、ruby等等server-side语言，这结果是虽然听上去使用这类项目后client和server端代码都是用js写，但是其实这两个地方写出来的js完全不一样。
相对来说，虽然同是server-side js，Aptana旗下的jaxer看上去漂亮得多。jaxer给html中的script标签加了一个runat的属性（M$好像搞过类似的东西？），通过将runat属性设置为server（提供一组用于访问db、调用远程service的api）、both或者client（default），可以决定js运行的位置。而通过一个runat=”server-proxy”的特殊标记，client可以很容易调用server的功能。这样理想下开发人员只需要写包含js的html再部署到jaxer server上就行——咋一看用同一语言同一编程方式挺好的整合了server和client端。不过仔细一想，我还是挺怀疑的。虽然代码文件的区分基本没有了，但是物理上server和client的界限还是存在的。结果就是用helma这类东西，开发人员必须在项目中来回切换server代码和client代码。而用jaxer，开发人员必须在脑子里来回切换server代码和client代码，囧……而且jaxer文档里的例子大多是inline js，真正开发谁这么写呀……一旦外联js，因为这些js文件是区分server和client的，所以很直觉就分到不同的目录，然后……鉴于jaxer并不内建支持mvc，于是我猜会很像js版本的php。补一句，我并没有真正用过jaxer，可能有点信口开河，有兴趣的最好还是去自己看看，如果有jaxer大规模开发经验的，欢迎留言~
第一类我看得多一些就是这两个，另外还有很多在servlet server上跑rinho以及在apache、lighttd上跑spidermonkey的项目。但是总得来说大同小异——我见过比较另类的是把extjs跑到asp服务器上增强jscript能力的，据说很好用，而且鉴于国内虚拟空间的国情，这做法还真挺实惠的。
直接用js作为server side脚本的问题是因为体系结构不变，server和client的区分还在，结果client js和server js完全是不同编程方式。如果只是想用js写server也没什么问题，不过总会觉得有点不优雅。
于是第二类的方案本质上是修改了我们传统中的3 Tiers体系结构。这类方案里，client端直连db。server端基本不再运行任何业务逻辑代码，变成了单纯host html和js的静态服务器。
这类解决方案，我现在知道的就是OpenResty、Couchdb和dojo的Perservere，应该还有其他的。
OpenResty是yahoo一帮人搞的，现在还不开放注册，账号可以发信索要。这个项目提供一组REST和json访问PostgreSQL的接口。用了这个东西，开发的模式变成了，开发人员在前台写html+js客户端，直接操作后台数据库的内容。所有的业务逻辑代码都统一在前端的js代码中。openresty这个作者的blog据说就是用这种模式搭建的。
Couchdb和Perservere从思路上和OpenResty没有区别。前者是很热的erlang项目。文档数据库，加之erlang这个东西，传说水平伸缩性无敌。这个项目一直很贴js，view直接用js写，访问走rest和json，包括他自己的管理界面也是直接用html+js做的。这里还有一个用js操作couchdb的例子（windows装couchdb失败的我，没有试……）。后者是dojo的一个子项目，也是对关系数据库的一个包装，好处是与dojo紧密集成。
当然用这种提供REST和json接口的Storage，前台并不一定是js+html，任何通用语言都可以。但是看上去这些项目都很往js贴（比如json而不是xml），毕竟browser上js独大，而现在在desktop上又有了air——air的跨平台还是很诱人。
如果扯大词的话，这种Client-DB直连的模式还可以扯到“云”中。比如OpenResty的服务也可以看成云存储的一种。于是后端用云做存储，前端在浏览器中做计算，大家还真是省事了，XD。（写到这，忽然想起来su27同学写过这么一个东西，gae的js interface。恩，好吧，多么的云计算呀）
不过目前看上去这种模式也有几个问题，一是代码安全，如果全是html+js，那就真是什么秘密都没有了。虽然可以做混淆，但不是万全之策；二是安全性，比如连接远程Storage的用户名和密码总不能放到js中吧？三是跨域，如果用第三方的Storage，这个问题也挺不好解决。综合2，3的话，至少目前来看想完全只用静态服务器也不太可能，还得搭一个Proxy中转。
最后，wiki上还有一个关于Server-side Javascript很完整的列表，可以参考。
虎头蛇尾的结束~
豆瓣API: One Year Later
正好是豆瓣API发布一年的时间。之前有打算写一点总结性的东西，可最近很不在写字的状态里——有好几篇东西都是开了头就进行不下去了，所以这里也就只能流于简短。
过去
写这种东西，往往都脱不了回顾过去展望未来的路子。回顾来说，过去一年里，还是很happy的看到豆瓣API从一开始比较简陋的书影音只读接口，到现在基本上覆盖豆瓣主要功能的很成型的东西。
这里必须要感谢大头鱼、davies和subdragon在Server和Client两端工作，没有这些努力，所有东西都只能是纸面上的空中楼阁。
还要感谢所有关注豆瓣API的豆友们。特别是其中那些使用API的开发人员，Meaglith、wu yuntao、Livid、刀马、EmilMatthew、MJiA、Hooopo、tsing、14、狮兄、bc1998，排名不分先后。我相信我一定忘了谁的名字，不过一定原谅我，因为这绝对是我越来越老，记忆力越来越差的缘故，我对所有人的感谢是一致的，因为没有你们的应用，API的工作没有意义。
接着说一点遗憾的事，虽然从06年刚接触豆瓣的热情，到07，再到08一路经过，我自己对于API的预期和动力都已经消磨了很多，但即使在这种情况下API流行程度还是低于了我的预期。这一部分是源于我们工作的不成熟，比如API入门门槛还是有点高，虽然我们也进行了一些工作试图改变，但总得来看降低API的上手难度仍然是有很大空间来做的事。另外不得不说在这块神奇的土地上，大家的生存压力如此之大，比之海外无偿的第三方开发工作需要更多的付出。理解这些，我也就更加感谢现在这些开发人员。
未来
即使在寒冷的冬天，未来仍是让人向往的。豆瓣API的第二年，依照自己的想法，希望豆瓣API会在以下这些方向上继续前进。
首先是开放更多可以通过API使用功能，包括相册、豆列、留言这些功能，而online、artist这些还在演化中的工作，随着他们的完善，也会早日将他们纳入API的范畴。总之为开发人员提供能力更强，更能激发创意，更有施展空间的接口。
其次是API的推广，这个可做的事情很多。而我目前最想做的是提供更好的应用展示平台。如今的豆瓣API还是有一些很“产品级”的应用的，然而因为现在缺少展示平台 ，应用的传播走的还是小组推荐这些很豆瓣很草根的方式。并不是说这样不好，不过既然大家在这么大的生存压力下辛辛苦苦花了很多时间来做应用，那么专门的页面总是应该有的吧~~
最后，我个人的希望是可以把API更好地适用于插件小组。API小组和插件小组基本集中了意愿为豆瓣做第三方开发的全部草根力量。然而插件小组从我建组，到NP同学接手过去，一直在fx gm的路线奋勇前进，大部份工作和API全不相交。这有点脱离我当初希望做API来帮助插件开发的本意，接下来的一年里我希望这两个小组可以有更多的交集。
结语
说是流于简短，写起来真是很多废话。其实文字絮絮叨叨是我的特质，难免让大家厌烦了。
总之最后还是要说很感谢所有人对于豆瓣API的努力和关注，真的很感谢。
题外话是2009年，我要好好读博，天天向上，努力在2011年毕业，囧~~
我需要什么样的RIA Client Framework
研究flex有一段时间了，一直想写一点比较实在的东西。然而真到动手的时候往往又被困住了。
我现在真的懒了，过了原来学js时不用任何framework裸奔干活还不忘了写得很oo的年纪了（其实那时候我在做js方面的intern）。每次在脑子预构要做的时候，发现自己不得不做这么多“dirty work”，重新发明那么多轮子，一下就把我给吓住了（如果有钱发什么也吓不倒我）。
结果是，我什么大东西也没编，倒是一直幻想一个好用的RIA框架应该是什么样子（也就不限于flex了，如果gear、sliverlight、java fx方面上能用类似的东西我会考虑立马转向）。所以就随便写一点想法在这里，没准这种东西已经有了也可能的说，如果这样的话，麻烦在回复里推荐给我吧
—懒懒的分割线—-
这里先撇清我说的RIA是带着Server端的（不然怎么叫Internet App），所以题目中说的是Client Framework（不过很多东西还是要server配合才能搞）。Server端提供Service（RESTful、SOAP、AMF或者什么都行）。Server和Client之间传递xml、json或者什么编码的value object。
接着看客户端，MVC是必须的。不过这部分已经从Framework角度讲已经没问题了，无论是PureMVC还是Cairngorm都已经够用了。所以我就每一个部分的说
Model部分：
1. 统一的model class。指的是server端和client端model的统一，现在一般得搞两份，实在没必要。理想状况下用同一份model，server或者client专用的属性或者方法用继承或者annotation说明。
2. 考虑server端代码不可见的情况。至少可以通过server返回的vo生成model的桩（soap没有这方面的问题，但现在restful居多）。
3. 对本地数据库管理的封装。air和gear都支持sqlite，在本地缓存数据的好处是显而易见的。但是现在开发人员需要事无巨细地处理这个功能。理想情况下，首次创建数据库，client升级时数据库的升级，等等这些常用必要操作，框架应该封装好。开发人员提供必要的sql script即可。
4. ORMapping。这个不废话了。
5. 离线支持。Client数据同步到Server，参考greader离线阅读的方式。这个能力应该被框架支持，开发人员需要说明那些操作可以离线处理，如何在本地缓存操作结果，同步时机即可。
6. Server更新的处理。用于处理在本地缓存数据之后，server端数据更新的情况。需要server和client统一的方案。最理想情况下是应该有一种开放、通用的协议被广泛支持。大概思路是client提供时间戳和资源类型，server返回时间戳之后更新的资源。
Controller部分：
一句话就是更强的Comet。现在的观点Comet是server push data。考虑Rich Client，可以换一种观点，变成server调用client的功能，原来push的data只是参数（所以放到controller部分）。其中现在Comet谈到传输协议一层，但是之上还应该又一层互操作协议以及对应实现。这里：
1. 首先是让server和client很好地相互理解。至少也是一个类似xmlrpc的东西，从发起调用到调用成功，中间打包、拆包、client上的method dispatch之类全部透明。
2. 其次是对常用功能的封装。连接，断开等等。也要透明。
3. 最后考虑server和client不是同一方开发的情况。不同于client invoke server的调用，这里的反向调用是从层级结构上讲是下层调用上层。IoC原则，server方提出接口描述，client实现。接口描述语言肯定是互操作协议的一部分，但是扮演的角色和传统稍有不同。
View部分：
这里我能谈的不多了。只随便说一两句flex。
1. 需要一个更好的中文默认skin。现在的默认skin完全不适用于中文。
2. 更容易地借鉴（抄袭）设计。好吧，我到底不是一个设计人员。如果不是网上有那么多“免费”的css，我估计连勉强看得过去的html页面都写不出来。flex这方面门槛太高了。联合上面那点。业余开发人员很受打击。
—-又是分割线——
信手写了一大篇，半是存底备份，怀疑中间有一些点还是很有意思可以做一做玩一玩的。不过原来胖客户的时候以及现在在一些c/s体系结构的应用领域里（例如网游、数据库），估计类似的东西或多或少都解决了一些。
所以很多东西也许只要有对应的走http的轻量级版本就好了。
Burning Google Chrome
"We knew we had to break her, burn her straight down, or she might come after us." – William Gibson, "Burning Chrome"
珂萝米，不知道为什么是这个名字，不过这个名字在Cyber空间里是个坏角色。
如果这不是另一个不合时宜的愚人节新闻，那么大概在24小时之内我们就可以下载到这个Google的新浏览器，Google Chrome。
目前比较完整的消息都来自这个漫画（题外话，很难适应美漫，一点代入感都没有地难读）。要点是这样子的：
- 稳定性，多进程架构（每个tab是一个进程，独立的js线程，同时内置一个任务管理器之类的东西，让用户监控或者中止不适当的tab页）
- Webkit用于html渲染，加上全新的jsvm——V8（class支持类似虚表的机制，JIT，更好的GC）
- 用户体验（地址栏搜索，布局类似Opera基于浏览历史的快速索引页，关闭后清空所有浏览历史记录的只读模式，Popup确认）
- 安全性，Sandbox，浏览安全（基于Sandbox的malware防护，基于黑名单的Harmful Site防护）
- 内置Gear，开源
仔细看一下，其实新东西不多，三个值得提一下的。
第一个是每tab每进程的架构。这方面其实不了解，所以不多说。总之漫画里google讲了一些多进程非常通用的好处。而具体效果，包括速度、内存的使用等等，还要用实物测试才知道。
第二个是v8，新的js引擎。基本上所有做前端的人的想法是一致的，标准的反派形象。因为不管新引擎有多好，很直观的一点是，调试兼容性的工作量的又增加了。对于开发人员来说，最邪恶的事莫过于此，因为这是让已经混乱的世界更加混乱。虽然在测试之前一切结论都是草率，不过肯定的是一旦v8的兼容性表现不好，而chrome又占据一定的市场份额的话，那么这对所有前端开发人员来说都是噩梦。（另外，值得注意的是fx3.1的js引擎也是新的——TraceMonkey）
第三，在比较high level的层面值得注意的是Gear的集成。所以chrome的目的大概并不是浏览器市场。对于浏览器市场，和mozilla有良好关系的google大可不必扮演一个坏人来搅局。但是如果是作为RIA的最后一块的拼图，chrome是合适的。至此，google有了浏览器+插件+web应用的完整RIA方案，结果是google得到了将web应用的功能和体验再进一步发展的可能性。这一点是ms、adobe、mozilla、yahoo和apple都比不了的。长久以来Google Gear一直是一个低估的角色，也不普及。然而从上次google developer day上的演示来看，gear还是具备相当能力。相对与flex和sliverlight来说，gear具有的无可比拟的优势，因为gear可以从google自己的web应用那里获得进化的方向。相对与flex和sliverlight，gear避免了高大全而是切实地在实用性上下功夫——这恰恰也是google的特长。所以google是不是可以借chrome的东风，彻底改变RIA的局面，这个也算值得大家仔细观看的事情吧。
最后，不得不说，历史真的总是惊人的相似。又一个新浏览器~如果有一天，我们发现chrome之外的浏览器无法获得google系列应用的全部功能和最好的用户体验，我们会不会又一次扔掉手头习惯的浏览器而转向chrome呢？所以呢，开篇的那句话就让ie、fx、opera、safari、flex、sliverlight等等的大家们共勉吧~