竹磬网-邵珠庆の日记 生命只有一次,你可以用它来做些更多伟大的事情–Make the world a little better and easier


2511月/100

A/B测试:实现方法

发布在 邵珠庆

上文介绍了 A/B 测试的基本概念 ,接下来我们继续探讨如何实现 A/B 测试

我们先来看一个图:

A/B testing 部署概念图
(注:感谢Algo 提供本图。)

上图展示了 A/B 测试的实现原理。从左到右,四条较粗的竖线代表了 A/B 测试中的四个关键角色:客户端(Client)、服务器(Server)、数据层(Data)、数据仓库(Data Warehouse)。从上到下代表了三种访问形式:无 A/B 测试的普通访问流程(Non AB test)、基于后端的 A/B 测试访问流程(Back-end AB test)、基于前端的 A/B 测试访问流程(Front-end AB test)。

一般情况下,用户在一次浏览中,会从客户端(Client)发起一个请求,这个请求被传到了服务器(Server),服务器的后台程序根据计 算,得出要给用户返回什么内容(Data),同时向数据仓库(Data Warehouse)添加一条打点信息,记录本次访问的相关信息。这个过程也就是图上横向的流程。数据仓库收集到足够的数据之后,就可以开始进行分析 (Analytics)了,这也即是图中右上角的部分。

A/B 测试需要将多个不同的版本展现给不同的用户,即需要一个“分流”的环节。从上图中我们可以看到,分流可以在客户端做,也可以在服务器端做。传统的 A/B 测试一般是在服务端分流的,即基于后端的 A/B 测试(Back-end AB test),当用户的请求到达服务器时,服务器根据一定的规则,给不同的用户返回不同的版本,同时记录数据的工作也在服务端完成。

基于后端的 A/B 测试技术实现上稍微简单一些,不过缺点是需要技术部工程资源介入,另外收集到的数据通常是比较宏观的PV(Page View)信息,虽然可以进行比较复杂的宏观行为分析,但要想知道用户在某个版本的页面上的具体行为往往就无能为力了。

基于前端的 A/B 测试则可以解决上面的问题。它的特点是,利用前端 JavaScript 方法,在客户端进行分流,同时,可以用 JavaScript 记录下用户的鼠标行为(甚至键盘行为,如果需要的话),直接发送到对应的打点服务器记录。这样的好处是不需要技术部(如果你们和我们一样,前端工程师与后 端工程师分属不同部门的话)参与,并且可以比较精确地记录下用户在页面上的每一个行为,甚至包括后端方法难以记录到的无效点击!

下面,我将重点介绍一下我们在基于前端的 A/B 测试上的一些实践。

一、分流

首先遇到的问题是如何分流的问题。对于大部分需求来说,我们希望各个版本的访问人数平均分配。解决办法有很多种,比较简单的一种即是前面提到过 的,根据某一个 Cookie ID 来划分用户,前提是你的网站上每一位访客在第一次访问时就要有一个不重复的 Cookie ID,比如“123.180.140.*.1267882109577.3”。然后,可以根据这个 Cookie ID 的最后一位(在本例中是“3”)来划分人群,比如单数的显示 A 版本,偶数的显示 B 版本。

因为 Cookie ID 一般设定后不会轻易改变,基于 Cookie ID 的好处是我们能很好地对访客保持一致性,某个用户如果第一次看到的是 A 版本,那他刷新后看到的还是 A 版本,不会一会儿看到 A 版本一会儿看到 B 版本。但不足之处就是如果用户浏览器不支持 Cookie 的话,分流就不能正常进行了。不过,现代浏览器默认情况下都是支持 Cookie 的,如果真有用户的浏览器不支持 Cookie ,那也应该是极少数特殊情况,对结果的影响非常微小,对于这些特殊情况,我们一般可以安全地忽略掉。

还有一点需要注意的是,A/B 测试的页面必须有较高的 UV (Unique Visitor,独立访客数),因为分流带有一定的随机性,如果页面 UV 太小,分到每一个版本的人数就更少,结果很有可能被一些偶然因素影响。而 UV 较大时,根据大数定理,我们得到的结果会接近于真实数据。就像想知道一个地方的成年人的平均身高,当然是取的样本越大结论越可信。

二、展示

决定向当前访问者显示哪个版本后,怎么用前端的方法加载对应的版本呢?这需要分情况处理。

一般情况下,如果两个版本只有一个较小的区域不一样,我们可以同时将两个区域的 HTML 都加载到当前页面中,先用 CSS 把它们隐藏起来(也可以默认显示一个版本),等 JS 判断出该显示哪个版本后,再控制对应版本的 CSS 显示。

有时候,测试区域比较大,代码比较多,或者需要后台较多的计算资源,如果一开始就把两个版本的 HTML 全加载到当前页面中,就会需要比较大的开销(比如带宽、后台计算量)。这种情况下,我们可以先把测试区留空,之后再用 Ajax 的方式延迟加载。

还有的时候,测试区域非常大,几乎占了整个页面,或者完全就是不同的页面,这时,用 Ajax 方式加载也不适合了,可以将不同的版本做成不同的页面,然后再用 JS 跳转。不过这样的方式并不是很好,因为前端 JS 跳转需要一定的时间,这个过程很有可能被用户感受到,并且留下不好的体验。对这个问题,似乎没有很好的解决办法,至少在前端层面很难完美解决,所以并不是 非常推荐这种跳转方式,如果真的需要跳转,最好是在服务器端由后端代码来操作。

三、数据采集

正确展示对应的版本后,就要开始采集需要的数据了。有一个可选的数据,是当前版本有多少 PV (Page Views,访问量),如果需要记录这个数据的话,在正确版本加载完成之时就要发送一个打点信息。不过很多需求中,具体版本的 PV 的精确数值可能不是很重要,而且要收集这个信息需要多一次打点操作,所以一般情况下这个数据是可选的。

必须的数据是测试区域内用户的点击信息。当用户在测试区域点击了鼠标左键(无论这个点击是点击在链接、文字、图片还是空白处),我们就需要发送一条对应的打点信息到打点服务器。一般来说,这个打点信息至少需要包含以下数据:

当前 A/B 测试以及版本标识
点击事件的位置
点击时间戳(客户端时间)
当前点中的URL(如果点在非超链接区域,此项为空)
用户标识(比如 Cookie ID)
用户浏览器信息

为了尽可能精确地还原用户的点击位置,我们的页面对前端有比较高的要求,要求页面在不同的浏览器下有基本一致的表现,至少在IE6、7、8以及 Fiefox 下,页面横向的元素要精确一致,纵向上很难做到完全一致,但也要尽可能保持统一。另外,这样的测试也不太适合自适应宽度的页面,比较适合定宽 的页面,为了避免不同分辨率下页面左右空白不同导致鼠标点击位置的不同,点击位置取的应该是相对于测试区域 左上角的位置。除此之外,最好再记录一下测试区域相对于页面内容左上角的位置,在后面还原点击分布图以及绘制热区图时会用到这个数据。

这一阶段的流程大致如下图所示:

A/B 测试打点生命周期

数据打点该如何发送以及如何存储呢?这要取决于你的打点服务器如何存储信息。

四、数据存储

我们使用了一台专用的服务器收集打点信息,为了能支持尽可多尽可能密集的打点请求,这台服务器的 apache 服务网站目录下只有两个静态文件,分别是 abtest.html 和 abtest.gif ,两者都是非常小的空白文件(空白图片)。访客端进行打点时,只需要以 GET 的方式带上相关的参数请求两个文件中的任意一个即可。比如:

http://abtest.xxx.com/abtest.gif ?abid=1-a&clickBlockX=244&clickBlockY=372&clickBlockW=392&clickBlockH=76&clickTime=1263264082137&clickRX=233&clickRY=47&clickURL=&clickBeaconID=123.180.140.*.1267882109577.3&browserType=FireFox

这个请求可以通过 Ajax 的方式发送,也可以通过 JS 在页面上创建 new Image() 对象的方式完成。

对打点服务器来说,这只是一条普通的 HTTP 请求,它会在日志里留下一条普通的日志记录,形如:

123.180.140.* - - [13/Jan/2010:15:21:15 +0800] "GET /abtest.gif?a=123&b=456&c=789 HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.6 (KHTML, like Gecko) Chrome/4.0.266.0 Safari/532.6"

可以看到了,除了 JS 发送给我们的信息外,Apache 还帮我们记录了一些信息,比如访客 IP 、服务器时间、用户浏览器信息。

对于数据记录和存储来说,到这一步就足够了。Apache 静态文件 + 日志的方式足够高效,基本不用担心性能的问题。剩下的,就是另外一个问题,如何从 Apache 日志中读取打点信息并加以分析,这已经和前端无关了,并且是一个比较复杂的问题,将在后续日志中介绍。

2511月/100

A/B测试:基本概念

发布在 邵珠庆

网站设计中,我们经常会面临多个设计方案的选择,比如某个按钮是用红色还是用蓝色,是放左边还是放右边。传统的解决方法通常是集体讨论表决,或者由 某位专家或领导来拍板,实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的,但A/B 测试(A/B Testing)可能是解决这类问题的一个更好的方法。

所谓 A/B 测试,简单来说,就是为同一个目标制定两个方案(比如两个页面),让一部分用户使用 A 方案,另一部分用户使用 B 方案,记录下用户的使用情况,看哪个方案更符合设计目标。当然,在实际操作过程之中还有许多需要注意的细节。

A/B 测试并不是互联网测试新发明的方法,事实上,自然界也存在着类似 A/B 测试的事件,比如下图中的达尔文雀 。

达尔文雀

达尔文雀主要生活在太平洋东部加拉帕戈斯(Galapagos)的一个名为伊莎贝拉(Isabela)的岛上,一部分生活在岛的西部,另一部分生活在岛的东部,由于生活环境的细微不同它们进化出了不同的喙。这被认为是自然选择学说上的一个重要例证。

同样一种鸟,究竟哪一种喙更适合生存呢?自然界给出了她的解决方案,让鸟儿自己变异(多个设计方案),然后优胜劣汰。具体到达尔文雀这个例子上,不同的环境中喙也有不同的解决方案。

上面的例子虽然和网站设计无关,但包含了 A/B 测试最核心的思想,即:

1、多个方案并行测试;
2、每个方案只有一个变量(比如鸟喙)不同;
3、以某种规则优胜劣汰。

需要特别留意的是第 2 点,它暗示了 A/B 测试的应用范围,——必须是单变量 。有时我们的多个设计稿 可能会有非常大的差异,这样的情况一般不太适合做 A/B 测试,因为它们的变量太多了,变量之间会有较多的干扰,我们很难通过 A/B 测试的方法来找出各个变量对结果的影响程度。比如,土豆烧肉和豆腐鲫鱼汤都挺美味,但我们很难比较土豆和豆腐哪一个对菜的美味影响更大,而土豆烧肉和豆腐 烧肉则是不错的比较。另外,虽然 A/B 测试名字中只包含 A、B ,但并不是说它只能用于比较两个方案的好坏,事实上,你完全可以设计多个方案进行测试,“A/B 测试”这个名字只是一个习惯的叫法。

回到网站设计,一般来说,每个设计方案应该大体上是相同的,只是某一个地方有所不同,比如某处排版、文案、图片、颜色等。然后对不同的用户展示不同的方案。

要注意,不同的用户在他的一次浏览过程中,看到的应该一直是同一个方案。比如他一开始看到的是 A 方案,则在此次会话中应该一直向他展示 A 方案,而不能一会儿让他看 A 方案,一会儿让他看 B 方案。同时,还需要注意控制访问各个版本的人数,大多数情况下我们会希望将访问者平均分配到各个不同的版本上。要做到这些很简单,根据 cookie (比如 cookie 会话ID的最后一位数字)决定展示哪个版本就是一个不错的方法。

下面是 A/B 测试示意图:

A/B测试示意图

可以看到,要实现 A/B 测试,我们需要做以下几个工作:

1、开发两个(或多个)不同的版本并部署;
2、收集数据;
3、分析数据,得出结果。

关于 A/B 测试的基本概念就介绍到这里,其余部分我会在后续文章中继续介绍。

2511月/100

为什么AB测试

发布在 邵珠庆

很多朋友都问我怎么进行A/B测试,我一般都不直接回答他们的问题,而是首先问一句:“你的日IP是多少?”。当对方的回答是不到一百的时候,我一般都说这个没必要了解。

或许你会纳闷,为什么日IP少的站没必要了解A/B测试,原因很简单,A/B测试需要大量的IP,如果你的IP只有十几个,那么测试出来的数据很可能不是很准确,换句话说A/B测试的站日流量越大测试的结果越准确。

好了,说了这么多,还是把A/B测试跟大家谈谈吧。

举个简单的例子,当你有一个日IP过千的网站,而你的网站首页几百年没有更改了,这个时候你想启用新的网页,而你有害怕新的页面用户不一定就非常喜欢,那 么这个时候你就需要进行A/B测试了。测试的方法是将老页面定义为A页面,新页面定义为B页面。到谷歌网站优化工具申请进行A/B测试(免费的),这是时 候谷歌会给你一串代码,我们只需要将代码添加到谷歌要求的页面即可。

代码添加完毕,如果有一千个用户访问你的网站,那么会有500个用户看到A页面,500个用户看到B页面,这个时候再统计下通过A页面到达网站内页的用户 占的百分比是多少,通过B页面到达内页的用户占的百分比是多少。假设A的是6%,B的是20%那么恭喜你,这说明你新设计的页面是博得了用户的欢心。如果 你对20%的结果还不满意,那么继续修改你的页面,直到这个转化率不能够再提高为止。

A/B测试是一个科学的统计方法,这一统计的诞生,再也不用为了争吵是使用A图片好,还是使用B图片好,好不好,按照效果说算。还是邓爷爷说的好,实践是检验真理的唯一标准。停止争吵,来做个A/B测试吧。

前提是你要有上千的IP,而且还是每日。数据太小的话,往往不准确。

2511月/100

HTML5将重塑Web世界

发布在 邵珠庆

HTML5将改变互联网的方方面面。Html5可能不会完全取代Flash,但它会重塑互联网,使浏览器无需借助插件就可以做更多的工作,从位置跟踪、视频播放到把云端的数据缓存到本地,最终能使互联网更安全、更高效、更灵活。

HTML5将重塑Web世界?

■ 乐天 编译

Adobe和Apple围绕

Flash发生的冲突是

今年上半年的一个焦点事件,引起了很多人的关注,其中有不少人因这一事件第一次了解到HTML5的存在。初次了解HTML5的人可能会非常惊讶,HTML5规范早在6年前就开始制定了,如今尽管HTML5规范草案已经非常好,但何时能真正成为标准却仍然不确定。

的确,HTML5规范制定委员会工作进展非常缓慢。因为关于如何改进浏览器和改进Web世界,不管是浏览器供应商还是其他人都有太多的想法,而这些都要汇聚到HTML5规范中并达成一致,这需要时间。许多新的标签和JavaScript函数尽管已经在一些浏览器上进行了实验,但互操作性和标准化问题还没有解决。比如,Apple所做的HTML5演示虽然令人印象深刻,但它们也只在Safari上运行良好。这就是为什么Flash的支持者嘲笑HTML5要把Web带回到2000年浏览器大战时代的原因。

虽然这种嘲笑可能让HTML5的支持者很伤心,而且漫长的等待的确很难熬,但如果就此忽略HTML5却是不对的。因为在HTML5的背后不仅有行业巨头的推动,更为重要的是,标准化是IT技术发展的必然趋势。就软件而言,不论是浏览器还是相关的开发工具,都会不断吸纳周围的各种技术,最后对其进行标准化,这是技术发展的必然规律。

可以肯定的是,HTML5将改变互联网的方方面面,显然它不会完全取代Flash,但HTML5的确会重塑互联网,使浏览器无需借助插件就可以做更多的工作,从位置跟踪到把数据保存到云端。HTML5的标签将取代那些完成比较简单任务的插件,至少在某些时候,它可以把一些高级的功能开发给更多的用户。最终它可能使互联网更安全、更高效、更灵活。

那么,即将成为新标准的HTML5到底会把我们带向哪里?下面收集了开发者、程序员以及设计师的一些看法,从中可以了解到HTML5如何改变互联网。

降低插件的重要性

从前,Web世界是非常欢迎浏览器插件的,因为它鼓励创新的想法和大胆实验,而声音、动画及其他一些非常生动的网页,通过Sun、Adobe、RealAudio、微软以及其他的一些公司开发的插件第一次在网络呈现时也的确让人耳目一新。然而,问题很快就出现了,插件的接口是向所有人开放的,每个人都在尝试给旧的、以文本为基础的世界增加新的功能,混乱不可避免。其中最有名的插件就是Flash,其他类似的插件更是数不胜数。

出于多种原因,Apple禁止Adobe的Flash在自己的平台上运行,这使得广大Apple迷们不能在Apple平台上看到Flash,而HTML5的流行将让这种冲突不再出现,它将逐步淘汰那些相对封闭的开发体系:JavaFX的功能可能真的很强大,但既然JavaScript和Canvas对象就能做同样的工作,为什么还要学习另一种语法?如果video标签能将音视频同步,谁需要Real的生态系统?

那么,插件真的会全部消失吗?也许吧,但这要取决于你想做的事情。如果你的目标只是绘制图像,那么Canvas对象可能就够用了。但如果你想建立一个专业的3D世界,正如在复杂的Flash和Shockwave游戏中所看到的那样,你可能还得依赖专有的插件技术,因为这些插件技术可以直接访问视频硬件,运行3D游戏。

支持动态生成图像

过去,网页中显示的图像来自于直接下载的GIF或JPG图像,而在HTML5中,图像可能并不是直接来自图像文件,而是由某个Canvas(画布)对象临时生成的。网络上已经出现了大量的非常好的图形库,这些图形库的存在使得动态生成图像更加容易。

如今,JavaScript层可以根据数据进行计算然后绘制出图形。如果软件开发商有足够的时间和人才的话,完全可以让网络上的一切变得更加生动,而纯文本内容越来越少。Flash只是一个开端,HTML5环境让Web开发人员更易于开发出复杂的图像。市场已经出现了一些类似的工具,它们将进一步提高Web开发人员驾驭图像的能力,而且随着工具的成熟,开发人员也将开发出更多更为专业的复杂图形。

这里可能存在的一个问题是,这种图像的处理可能会给客户端处理器带来很大负担,比如对客户端的处理器处理能力有一定要求。在过去,一些开发人员根本不敢用Flash插件,因为渲染和展现Flash内容可能会给处理器带来很大压力,极大地影响用户的最终体验。未来这不应该成为问题,开发者不应该因担心影响性能就不让用户体验生动的图像,只是开发者应该做出一个折中的选择。每一个抱怨Flash影响性能的人都应该知道,这与技术本身没有关系,问题来自设计师们为了吸引我们的注意力,他们过多地使用了这项技术。

允许Web程序

利用本地存储

Web程序员其实早就可以利用浏览器端的本地存储空间存储很多信息,比如IE允许最多300个Cookie,最多存储4096个字节的内容。不过,要开发真正实用的Web程序,可能需要比这更多的存储空间。比如,以前的Dojo工具包使用Flash插件来分配用户硬盘上的部分空间,把它留给浏览器使用,而现在很简单了,使用HTML5就可以达到同样的目的。

对于这部分存储,程序员可以按照自己的需要任意使用,比如把云服务的应用和数据保存在本地硬盘上。这也使得云应用的交付、安装和部署都非常像传统的应用程序。比如,无论是否有互联网连接,云应用程序都可以照常运行,因为之前已经从服务器上下载了HTML5应用的JavaScript代码,这部分代码就保存在本地。

当然,这种技术的应用并不会影响云应用的普及,因为现在的运行模式与过去有很大不同,本地数据库实际上扮演的是智能缓存的作用。另外,游戏开发人员可以在本地存储一些情景信息和装备信息,这样可避免每次一连机就要下载这些信息,省了下载资料的时间。而不利的方面就是这些数据库深埋在系统文件夹之中,这样,进行数据备份时就变得非常复杂。用户如果想把数据从一台机器迁移到另一台机器,数据迁移工作可能就会变得更为复杂。

或许混合云的出现可能解决这一问题,混和云允许云端和本地都保存有数据,而本地计算机只是缓存数据,最终版本保存在云中,这样从任意一台计算机上就可以访问到。

简化Web开发中的

数据提取

曾从网页中提取过数据的Web开发人员都知道,现有的HTML结构除了告诉浏览器这些信息在哪里之外,几乎不能再提供任何有意义的信息。而开发人员需要了解与数据本身有关的信息,这些信息能帮助程序员了解这些数据的真正含义。 HTML5中所谓的微格式(Microformat)引入了一种新的机制,它在HTML中新增了一些专门的标签,可以帮助程序员分析标签之中的数据的真实含义。

没有人能够预测微格式到底将带给网络多少改变,但很容易看出,这种新的机制将给程序员带来很大方便,帮助程序员开发出更有效率的Web应用。比如,如果有一个好的、标准的方式来表示日期和时间,那么程序员在为网站开发与时间有关的Web程序时,就无需另外编写专门的代码来分析或者猜测别人可能用的什么时间格式。这样,日历、时间表、日程安排等需要从多个数据源收集时间信息的应用也就变成非常简单的工作了。

支持位置服务

在Web世界里,过去我们只知道其IP地址,那些数字对应着一个什么样的真实世界我们根本不知道。比如,某台电脑究竟在哪里,过去几乎不可能知道,而现在出现的位置服务可以解决这个问题。HTML5标准中允许JavaScript询问浏览器用户的地理位置,比如纬度和经度信息。通常桌面系统不支持这一功能(因为需要有GPS或Wi-Fi),但如果终端是手持智能手机,这个功能就可以发挥作用。

今天,没有人能知道聪明的程序员会基于这些位置信息创建出什么应用来,但有一点可以肯定,未来一定可能以一种变幻莫测和难以置信的方式将把虚拟世界与现实世界整合到一起。

让Web视频

播放更流畅

HTML5中的“video”标签使Web开发人员很容易地把视频内容与网页中的其他内容整合起来,也让那些从事jQueryPHP开发的人员可以加入到Web开发队伍中,使得Web开发不再仅仅是Flash、Silverlight和JavaFX开发人员的专利。

尽管这一设想看起来很诱人,但面临的困难依然不少,因为HTML5标准中没有指定任何编解码器,而每个人都想发布自己的视频和声音编解码器。这就意味着我们用一种混乱取代另一个混乱:只是过去我们把嵌入到浏览器中的软件称为插件,而今天把它称为编解码器而已。因此,今天我们虽然有了一个标准的“video”标签,但浏览器可能知道也可能不知道到底如何解释这些视频内容。

在洛杉矶任教的HTML5应用开发讲师Erich Ocean认为编解码器的战争仍在继续。“计算机开发人员和Mozilla组织如果认为他们能为视频专业人士制定视频标准,那就大错特错了。”他说,“我们看到谷歌的新视频格式在一些地方得到了使用,比如在YouTube网站,但永远不会像H.264那样普及。”

尽管视频播放可能面临比较混乱的局面,因为无法让大家达成一致,但是新的“video”标签肯定会让互联网视频内容越来越丰富,网页将成为视频内容的主要发布源地,而同时单纯的文字内容也会越来越少。只是这对孩子的教育未必是好事,因为现在的孩子们变得越来越习惯于看动画,而很少花时间来阅读,更别提书写了。

Widget将更丰富

在IFrame中运行的Widget让网页可以把其他网站的内容(比如天气预报)嵌入进来,非常实用也非常受欢迎,但由于安全方面的原因,这些Widget一直运行在一个相对独立的环境中,与网页中的其他内容基本保持隔离状态。

而HTML5为这些Widget提供了一个相互通信的标准机制。尽管它们仍然不能够相互进入对方的运行环境中,但它们已经可以相互发送信息来协同工作了。

广告商对此早就期盼已久,它们非常希望能把分散到同一个网页各个位置的旗帜广告整合起来,而从开发的角度来说,开发人员也一定会找到其他实际用途。例如,在Web页面上播放的网球比赛画面可以和左右两边的球员信息同步起来,这在HTML 1.0时代是难以想象的。

不过,可以发送信息、相互通信机制只是一个开始,下一个亟待解决的是通信协议的问题,因为至今还没有这方面的一个标准。只有为传递信息设立一个标准后,两个不同开发团队开发出来的Widget之间才有可能相互通信。换句话说,通信双方需要更多的标准词汇。

提高浏览器的

安全性

每个浏览器插件都是一个单独的应用程序,不同的浏览器插件是由不同的程序员按照不同的标准开发的,发布时间不同,安全模式也不同。很自然地,有些插件会比其他的更安全。随着浏览器中的插件越来越多,要跟踪每个浏览器插件中可能存在的安全漏洞越来越复杂。比如,你企业中去年年末某个时候的安全漏洞到底是出在插件还是浏览器,最后是通过升级浏览器而不是升级插件来解决的还是反过来,可能很难有人记得那么清楚。

把很多功能内置到HTML5而不是使用插件可以大大降低安全风险,避免与插件开发有关的多个环节出现问题,更可以防止有人故意利用插件中的API安装恶意代码。因为相对而言,Firefox、Chrome或IE浏览器等的安全性通常会经过更多的人(包括安全小组)的审计,如果安全小组认为某个浏览器安全,一般来说,其安全风险肯定要少得多。

不过,这里所说的安全性有所改善带有一定程度的主要臆测。这个世界总会有一些人把它们的聪明才智用到“邪道”上,他们完全可能利用HTML5的某种特性来从事一些恶意行为。只是现在没有人能够预测HTML5的新功能中到底可能隐藏着哪些危险。

简化Web开发

在一家Web软件开发公司工作的开发人员的话很有代表性,它简明扼要地阐述了HTML5可能带来的变化。他说:“我更喜欢HTML5,主要是因为它使我能够在一个统一的开发环境下进行开发,这个环境就是浏览器加JavaScript再加上DOM,而不必在Flash世界和HTML5的世界之间来回切换。未来只要掌握一门开发语言和一个工具集,就可以开发任何插件。”

他补充说,“我认为,对于用户而言好处也是很明显的,而现在Flash仿佛在互联网世界里另外创立了一片天地。”

的确,HTML5采用了统一的语言(JavaScript)、统一的数据模型(XML和DOM)和统一的表现规则(CSS)来表现文本、音频、视频和图形,对于开发者而言无疑的是非常理想的,基于一个统一的标准开发环境,工作肯定会简单不少。但要让一切都成为现实挑战仍然是巨大的,一个突出问题是工具的缺乏,现在HTML5的相关工具方面还很少。不可否认,Flash的流行与Adobe为Flash的开发提供了非常好用的工具密不可分。

链   接

HTML的演进历程

HTML全称是超文本标示语言(Hypertext Markup Language),是用来描述网页的一种规范。正是这些容纳在尖括号里的简单标签,构成了如今的 Web。

HTML的第一个官方版本是由IETF (互联网工程任务组) 推出的 HTML 2.0。后来,W3C 取代 IETF 的角色,成为HTML标准制订的组织,上个世纪90年代的后半叶,HTML 的版本被频繁修改,直到1999年的HTML 4.01,至此,HTML到达了它的第一个巅峰。

HTML在HTML 4.01 之后的第一个修订版本就是 XHTML 1.0,其中X代表 “eXtensible”。 XHTML 1.0 是基于HTML 4.01 的,并没有引入任何新标签或属性,唯一的区别是语法,HTML对语法比较随便,而XHTML则要求XML般的严格语法。后来,W3C又推出了XHTML 1.1。

对 W3C 而言,到了 HTML 4已经是功德圆满,他们的下一步工作是XHTML 2.0,希望将Web带向XML的光明未来。然而,来自Opera、Apple以及 Mozilla 的代表不满意W3C的工作,他们自发组织成立了超文本应用技术工作组,这就是WHATWG,他们致力于HTML5 规范。

在WHATWG致力于HTML5的同时,W3C继续他们的XHTML 2.0。不过,W3C在XHTML 2.0方面的工作慢慢地陷入困境,后来终止了XHTML 2.0的工作,并于2007年组建了一个新的HTML工作组,他们非常明智地选择了 WHATWG 的成果作为基础,致力于制订HTML5规范。

经过多年的酝酿,HTML5的草案于2008年发布,目前W3C正在对它进行进一步完善。现在,关于HTML5何时会正式成为标准还没有一个明确的说法。好消息是,2012年HTML5可能会被接纳为候选标准。不过,可以预料的是,HTML5无论何时能成为标准,HTML5要被所有浏览器提供商所接纳肯定是一个比较长期的过程。

2211月/100

用户不上你的网站的50个原因

发布在 邵珠庆

原因如下:

1 他们不想生产内容,他们期望的是更好的生活
2 因为你能解决的问题是他们所没有的问题
3 而对于他们真正的问题你却无法解决
4 奥普拉没有提到过它
5 他们所认识的所有人都不上你的网站
6 你没有办法让他们窥视自己所喜欢的人
7 他们对自己所看见的并不在乎
8 没有哪个同事说应该上这个网站
9 它很没趣
10 它无法让人们开怀大笑
11 它没有办法帮人们省下一大笔钱
12 它没有办法帮人们节省时间
13 没有什么让他们感到激动万分的东西
14 它既不能拯救生命也不能拯救世界
15 它不像赌城那样充满刺激
16 它看上去像是花旗银行的广告,而人们憎恨它
17 没有人排队
18 他们又工作,有孩子,工作繁忙
19 因为他们和美国偶像节目的选手有约会
20 他们害怕电脑
21 他们有了足够的朋友
22 他们文笔不好
23 更多的人在用Craiglist
24  你没有告诉他们怎么去做
25  不上这个网站,没有人会认为他是白痴
26 它是为了怪人和白痴准备的
27 它肯定是为了那些“电脑高手”准备的
28 有人会盗窃他们的身份而诱拐其孩子
29 他们不明白你的专业术语
30 他们更擅长于让那些让你感到无能为力的事
31 他们出生于1985年以前
32 他们对电脑并不精通
33 他们很害羞
34 他们不像Yahoo, Amazon或者Ebay那样
35 它的主页不止一屏,不像Google那样
36 他们感觉沮丧
37 他们不想坐在电脑面前
38 他们尝试过使用它,但是结果一团糟
39 他们从来就没有听过它
40 他们有更重要的事情要做
41 周刊更吸引人
42 它上面写着什么”tag”,”RSS”,简直愚蠢透顶
43 家庭和朋友需要他们
44 他们不想过的那么沉闷
45 他们从来没有听说过Flickr和Del.icio.us
46 没有足够的人使用它,也没有成功的例子
47 没有暴露图片和名人消息
48 没有告诉他们为什么要用它
49 它不能提供给他们爱情和性
50 他们不想知道你想让他们做什么

1711月/100

解决Nginx + PHP(FastCGI)遇到的502 Bad Gateway错误

发布在 邵珠庆

由于服务器版本的不稳定,将Nginx的程序迁移到Apache执行

昨日,有朋友问我,他将Web服务器换成Nginx 0.6.31  + PHP 4.4.7(FastCGI)后,有时候访问会出现“502 Bad Gateway”错误,如何解决。
我让按照以下两个步骤去解决,最后在第2步中将FastCGI的timeout时间增加为300,问题解决:
PS:比较羡慕迅雷的Web服务器,16G内存。
1、查看当前的PHP FastCGI进程数是否够用:

netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”,那么,说明“FastCGI进程数”不够用,需要增大。


2、部分PHP程序的执行时间超过了Nginx的等待时间,可以适当增加nginx.conf配置文件中FastCGI的timeout时间,例如:

......
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......