什么是 1% 规则?

作者:Charles ArthurThe Guardian
翻译:ShiningRay

一个正在浮现的规则告诉我们——如果你的网站有100个人(一组)的在线量,只有1个会创建新的内容,有 10 个会与之进行交互(回复或者提供改进) ,剩下的89个就仅仅浏览一下。

在YouTube的统计数据中也显示出了几乎一样的情况。YouTube在18个月内就从零开始,占据了现在所有在线视频浏览的60%的份额。

数据显示出:每天有10亿次下载以及6,5000次上传——正如 Antony Mayfield所指出的那样,每次上传有1,538次下载——每个独立用户每月20m。

这个数据中的“创作者对消费者”的比率只有0.5%,不过是现在下最终解决还比较早,因为还不是所有人都发现了YouTube(还有就是下载比上传要方便得多,因为任何网页都能包含YouTube的链接)。

再思考一些其他的依赖社区产生内容的项目的统计数据,Wikipedia:Wikipedia所有文章的50%的编辑工作是由0.7%的用户来完成的,而有超过70%的文章是由1.8%的用户来撰写的。该数据来自Church of the Customer的Blog

从一些社区网站收集的早期的数据显示大约80%的内容是由20%的用户产生的,但是不断增长的数据量给出了清晰的图景,告诉我们Web 2.0的网站应该如何去思考。例如,一个网站如果是要求大量的用户交互和从用户创建的内容的话,它会发现10个人中有9个只是路过而已。

Yahoo的Bradley Horowitz指出相同的情况也适用于Yahoo:在Yahoo Groups(Yahoo的讨论组)上,“用户人口中的1%可能会创建一个讨论组;10%的用户可能会参与地比较活跃,同时实际创作新的内容——开启一个新的主题或者回复已有的主题;100%的用户可以从前面的用户的活动中受益,”他于二月份在其Blog上谈论了这一点

那么结论是什么?就是你不能对在线的用户期待太多。。问题在于——和现实生活一样——是如何找到构建者。

Web 2.0需要测试

原文: Web 2.0 needs testing 作者:Sam Newman

翻译:ShiningRay @ Nirvana Studio

我带着很多怀疑,耐着性子看完了Cal Henderson的高度富有娱乐性的(而且推荐大家观看)
构建Flickr作坊》,
从中听说自动化测试在他们的优先级列表中并不是特别地高
(有趣的旁白——Cal还认为面向对象编程是“神经错乱的”,所有的“健全”的代码则在“一超大函数”编程和OO之间的空间中存在)。
“测试Web应用”Cal说,“很困难”。其实这是一个普遍的误解。像任何其他应用的类型一样,只要你针对测试性设计了结构,测试是很容易的。然而,同时如果你采用了针对Web应用的测试而制作的测试工具(FITFITnesse, 以及Selenium都是很好的例子),那么即使那些没有带着测试的概念写的应用都没有借口说不利用他们进行开发。

但是现在放在我们面前的是Flickr这样一个姿态鲜明成功的应用,我只能假设自动化测试还存在一个更加成熟的途径。这种对自动化测试的放任自由的方式是不是很普遍呢?

让我们看看这另一条道路。如果你没有自动化测试,你要么手工进行测试(这意味着更长的发布时间)要么干脆不测试。如果你要着眼于交付有质量的产品,这也许意味着你最终还是要做很多手工测试,而这些测试本来可以自动化地更快完成的,甚至只要你想,可以在
在每一次的代码提交中完成

Web的架构产生了一个及早的快速发布、同时有一个经常发布的过程这样的想法。有了Web,你所有要关心的最终目标环境仅仅是你的服务器和客户端的浏览器。推出一个发行版真的可以像Flickr使用的“一点部署”(One-click Deployment)。有了一个成熟的测试框架,如果有必要的话,还可以办到一天之内多次直接给你的用户发布。

测试也许看起来不怎么好玩——但是一旦你明白了它意味着你可以更频繁地对你的用户发布更酷的功能,同时你可以在修复Bug上花费更少的时间,那么我们都可以去更加喜欢书写测试了。