我们都知道用户在网站上的访问行为数据是一座金矿，如果能恰当地加以分析，我们便能了解到用户在网站上做了些什么、体验如何，有时还能帮助我们发现一些从未注意到的问题，比如某个错误的交互设计等。但遗憾的是，传统的 UED（用户体验设计）部门通常只负责制作页面，或者至多再参与一些原始数据的收集工作（这个工作一般需要由 UED 的前端开发工程师来完成），却很少涉及到具体的数据分析。

　　当然，现代 UED 部门一般仍然是有一些岗位负责用户体验的反馈工作的，比如用户研究员。但大部分用户研究员的工作主要是调查问卷分析、用户访谈、焦点小组等，仍然并不涉及对原始的用户访问行为数据的定量分析。一般情况下，这些用户访问行为数据通常会由数据仓库部门保存，然后由 BI 部门进行分析，再生成各种报表供各个需求方查阅，而这个分析系统或流程对 UED 的同学来讲，通常是比较难用的，很多设计师或前端开发人员甚至从没和 BI 团队打过交道，也几乎从未从用户访问行为数据中得到过有效的反馈。

　　这就造成了一个奇怪的现象：号称最注重用户体验的 UED 部门，对真实用户产生的访问行为数据却几乎视而不见。每天海量的用户行为数据产生，又被淹没了，大家都知道无数宝贵的信息藏于其中，但大多数人都不知道怎么获取这些信息，于是，设计下一个产品或版本时，很大程度上仍然只能依靠设计师的经验和灵感。

　　前段时间读了一篇叫《统计词话》的文章，里面介绍了一种很暴力但相对来说还算比较有效的统计一段文本中各个词出现的次数的方法。

　　原文中举了个例子：

　　日常开发过程中，我们经常需要修改一些放在 CDN 上的静态文件（如 JavaScript、CSS、HTML 文件等），这个过程中，我们希望能有一种方式将线上 CDN 的目录映射为本地硬盘上的某个目录，这样，当我们在本地修改了某个文件时，不需要发布，刷新后马上能看到效果。

　　比如，我们的 CDN 域名是：http://a.mycdn.com，本地对应的目录是：D:\work\assets，我们希望所有对 http://a.mycdn.com/* 的访问被映射到本地的 D:\work\assets\* 下。如访问 http://a.mycdn.com/s/atp.js 时，实际上是读取的是本地的 D:\work\assets\s\atp.js，而不需要从网上下载线上的文件。

　　《高性能网站建设指南》一书中用了整整一章来介绍压缩，在这本书的影响下，各个网站几乎都启用了 Gzip 压缩，以便让网站取得更好的性能。应该说，Gzip 压缩对大部分应用场景来说都是利大于弊的，不过凡事无绝对，最近我就遇到一个例外。

　　最近我们用 YSlow 做页面的性能分析时，发现有一个 js 不知什么原因没有被 Gzip 压缩。于是我找到负责服务器配置的相关同学咨询，这个过程中巧遇淘叔度，听了他的解释才知道这是他们有意为之。

　　自我描述的语句指这样一种语句：它的内容就是对它本身的描述。（废话……）比如下面这句句子：

　　这是一段自我描述的语句，除了标点符号外，它共包含125个字符，其中33个“个”，29个“2”，5个“3”，3个“符”，3个“5”，2个“一”，2个“它”，2个“包”，2个“的”，2个“标”，2个“了”，2个“我”，2个“外”，2个“含”，2个“中”，2个“是”，2个“1”，2个“段”，2个“点”，2个“描”，2个“9”，2个“字”，2个“这”，2个“句”，2个“除”，2个“自”，2个“语”，2个“共”，2个“述”，2个“号”，2个“其”。

　　这句话是我用一段 Python 脚本生成的，生成原理大致如下：

　　有时候，我们需要将文本转换为图片，比如发长微博，或者不想让人轻易复制我们的文本内容等时候。目前类似的工具已经有了不少，不过我觉得用得都不是很趁手，于是便自己尝试实现了一个。你可以先访问一下查看效果：txt2.im 。

　　在 Python 中，PIL (Python Imaging Library) 是最常用的绘图库，自然地，尝试从 PIL 开始。

　　1、使用 PIL 将文字转换为图片

　　说转换其实并不恰当，真实的过程是：先在内存中生成一张图片，将需要的文字绘制到这个图片上，再将图片保存到指定位置。代码如下：

　　页面加载时间（Site Speed 或 User Latency）是网站可用性的一个重要指标，指的是网站的页面从加载开始到加载完成所花费的时间。这个时间反映了网站的访问速度，有一个说法是，如果一个页面超过 8 秒还没有打开，用户就会失去耐心，从而关闭窗口或转向别的页面。关于这个时间的度量，主要有以下几种方法。

　　方法一、前后端协同度量

　　服务器端收到当前页面的请求时，记下当前时间 t0，并输出到页面上。页面加载完成时（onload 事件触发），客户端 JavaScript 脚本将当前时间与 t0 比较，得到页面加载时间。

　　这种方法的不足是需要服务器端配合，并且由于服务器端时间与客户端时间不一定完全相同，还涉及比较复杂的时间同步问题，看似简单，做起来却并不容易。

　　2011 年做了或经历了很多事，这儿是我觉得值得记录的一个摘要：

　　一、做过的事

　　1、工作上，继续捣鼓用户行为数据。

　　这个工作很有趣，但有些地方也不容易做，经常有“书到用时方恨少”的感觉，还好有老大和同事的支持，很多难题还是逐一解决或绕过了。不过，仔细想想，今年自己在这个工作上并没有很大的突破，大部分精力还是花在了一些比较基础的工作上了，深入的分析做得还太少。

　　最近几个月比较关注效率以及时间管理的主题，前段时间看到一个幻灯片“Rules of Productivity”，觉得很不错，于是抽了点时间将它翻译成了中文。

　　幻灯片中，作者先解释了什么是生产率，然后讲述了 8 个生产率的实验，每个实验之后都总结出一些经验和教训。比如，第一个实验是关于加班的，长时间工作会有什么后果？

　　最近遇到 IE 下的一个闻所未闻的 bug：如果 <a> 元素的子节点为纯文本节点（即 nodeType 为 3，innerHTML 中没有 HTML 标签），并且值包含“@”字符，则在修改该 <a> 元素的 href 属性时，它的 innerHTML 也会跟着变。

　　重现 bug 的代码类似这样：