oldj's blog

使用Python将文本转为图片

oldj — Sun, 19 Feb 2012 19:04:43 +0800

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

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

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

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

# -*- coding: utf-8 -*-

import os
import Image, ImageFont, ImageDraw

text = u"这是一段测试文本，test 123。"

im = Image.new("RGB", (300, 50), (255, 255, 255))
dr = ImageDraw.Draw(im)
font = ImageFont.truetype(os.path.join("fonts", "msyh.ttf"), 14)

dr.text((10, 5), text, font=font, fill="#000000")

im.show()
im.save("t.png")

　　当然，要使上面的代码能正常运行，你还需要在代码目录建一个“fonts”文件夹，并将字体文件“msyh.ttf”（微软雅黑）放在里面。最终生成的图片效果如下：

　　从上面可以看到，使用 PIL 把文本转为图片是非常方便的。当然，上面还只是一个简单的例子，还没有考虑长文本换行的问题。

　　2、使用点阵字体

　　对于大多数屏幕阅读来说，较小的字号（<= 14px）使用点阵字体来说更加清晰和便于阅读，例如 Windows 中文版下的默认字体宋体在字号较小时就通常被渲染成点阵字体。那么，我们是否可以在生成的图片中使用点阵字体呢？

　　修改上面的代码的第 10 行，将字体从微软雅黑（msyh.ttf）换成了宋体（simsun.ttc），其它保持不变。

font = ImageFont.truetype(os.path.join("fonts", "simsun.ttc"), 14)

　　生成的图片如下：

　　杯具发生了，汉字没有正常显示！

　　网上搜索了一圈，发现这好像是 PIL 的一个 bug，PIL 目前的版本中，不能正确处理非 ASCII 字符的点阵字体的渲染。对于像宋体这样的字体来说，只有 >= 18px 时，才会被当作矢量字体处理，也就是说只有当字体 >= 18px 时，文字才能正常显示：

font = ImageFont.truetype(os.path.join("fonts", "simsun.ttc"), 18)

　　效果如下：

　　增大字体虽然解决了汉字不能正常显示的问题，但还是没有解决我们一开始的初衷：使用点阵字体进行渲染。但是，这个目标使用现阶段的 PIL 似乎有点难以实现了。

　　3、使用 pyGame 渲染点阵字体

　　Python 的第三方模块或组件非常多，可用来绘图的除了 PIL 之外，就还有 Pycairo、matplotlib、pyGame 等。在这儿，我使用 pyGame 来完成点阵字体的渲染工作。

　　代码如下：

# -*- coding: utf-8 -*-

import os
import pygame

pygame.init()

text = u"这是一段测试文本，test 123。"
font = pygame.font.Font(os.path.join("fonts", "simsun.ttc"), 14)
rtext = font.render(text, True, (0, 0, 0), (255, 255, 255))

pygame.image.save(rtext, "t.jpg")

　　效果如下：

　　可以看到，使用 pyGame ，点阵字体的问题终于搞定了。

　　4、结合 PIL 和 pyGame

　　pyGame 虽然可以解决点阵字体的渲染问题，但讲到对图片的处理，还是 PIL 更为强大。那么，我们为什么不把两者结合起来呢？用 pyGame 渲染点阵字体，然后用 PIL 生成整张图片。

　　代码如下：

# -*- coding: utf-8 -*-

import os
import StringIO
import Image, ImageFont, ImageDraw
import pygame

pygame.init()

text = u"这是一段测试文本，test 123。"

im = Image.new("RGB", (300, 50), (255, 255, 255))
#dr = ImageDraw.Draw(im)
#font = ImageFont.truetype(os.path.join("fonts", "simsun.ttc"), 18)
font = pygame.font.Font(os.path.join("fonts", "simsun.ttc"), 14)

#dr.text((10, 5), text, font=font, fill="#000000")
rtext = font.render(text, True, (0, 0, 0), (255, 255, 255))

#pygame.image.save(rtext, "t.gif")
sio = StringIO.StringIO()
pygame.image.save(rtext, sio)
sio.seek(0)

line = Image.open(sio)
im.paste(line, (10, 5))

im.show()
im.save("t.png")

　　原理很简单，先将文字用 pyGame 渲染为图片，将渲染结果保存在一个 StringIO 对象中，然后再用 PIL 加载它。使用 StringIO 的好处是，一切操作都是在内存中进行的，不需要先将它保存到硬盘再用 PIL 读取，因为硬盘 IO 的效率相对来说是比较低的。

　　最终效果如下：

　　到这儿，使用 Python 将文本转为图片的功能就基本实现了，用到了 PIL 和 pyGame。

　　当然，上面的代码还只解决了最基本的问题，一个真正可用的文本转图片工具，还应该解决以下问题：长文本换行问题、英文单词断字问题、标点符号换行问题等。关于这些问题的分析篇幅也不短，这一次就先略过了。下面是一个综合考虑了诸多因素之后生成的《荷塘月色》的效果图：

　　最后，欢迎试用我写的在线文本转图片工具：txt2.im 。:-)

页面加载时间度量

oldj — Mon, 09 Jan 2012 20:34:53 +0800

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

　　方法一、前后端协同度量

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

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

　　方法二、纯前端方法在当前页面度量

　　这种方法的原理为，在页面的顶部放一段 JavaScript 代码，记下当前时间 t0，然后在页面 onload 时再计算当前时间与 t0 的时间差，这个时间差即为页面加载时间。

　　示例如下：

<html>
<head>
<script type="text/javascript">

var t0 = new Date().getTime();
function onLoad() {
  var now = new Date().getTime();
  var latency = now - t0;
  alert("page loading time: " + latency);
}

</script>
</head>
<body onload="onLoad()">
<!- Main page body goes from here. -->
</body>
</html>

　　这种方法操作简单，而且使用的都是客户端时间，没有时间同步的问题。但不足是顶部记录 t0 的代码执行之前的时间（建立连接、网络延迟、接收并解析最初数据的时间）被忽略了，因此得到的时间一般比真实的页面加载时间要小。

　　方法三、前一个页面和当前页面协同度量

　　这种方法的原理为，用户在前一个页面点击到链接或在前一个页面被卸载之前（onbeforeunload），先记下当前时间 t0，然后下一个页面加载完成时（onload）计算当前时间与 t0 的时间差，这个时间差即为页面加载时间。

　　那么，用户离开前一个页面的时间 t0 保存在哪里呢？可以看看 IBM 奥斯汀研究实验室在 2001 年写的这篇论文：Measuring Client-Perceived Response Times on the WWW。里面详细地整理了各种 HTML5 之前的可用的跨页面传递信息的方法，如 cookie、独立窗口、框架等。最令人惊讶的是还提到使用 Window Name 来保存信息，几年之后，这种使用 window.name 传递信息的方法才开始在前端工程师中流传开来。

　　这种方法的优点是包含了网络延迟时间，得到的数据更真实。缺点是实现和部署较为复杂，并且访客访问的第一个页面的加载时间无法计算，因为在第一个页面之前没有哪个页面能先记下 t0。

　　另外，前面三种方法都需要添加额外的记录 t0 时间的代码，这会增加页面的计算量，从而影响到页面的交付时间，并影响最终的结果，虽然这个影响非常微小。这类似于物理学中的观察者效应。

　　方法四、使用浏览器插件或工具栏

　　比如使用 Google Toolbar 获取页面加载时间，见下面的例子：

function msSincePageLoad() {
  try {
    var t = null;
    if (window.chrome && chrome.csi)
      t = chrome.csi().pageT;
    if (t === null && window.gtbExternal)
      t = window.gtbExternal.pageT();
    if (t === null && window.external)
      t = window.external.pageT;
  } catch (e) {};
  return t;
}

　　当然，这个方法需要浏览器插件或工具栏的支持，通用性比较小，一般只能辅助使用。

　　方法五、使用 HTML5 中的 Navigation Timing 度量

　　HTML5 中引入了一个 Navigation Timing 接口，专门用于记录页面导航的时间。使用这个接口，能完美地记录页面加载时间。

　　示例代码如下：

<html>
<head>
<script type="text/javascript">
function onLoad() {
  var now = new Date().getTime();
  var page_load_time = now - performance.timing.navigationStart;
  alert("User-perceived page loading time: " + page_load_time);
}

</script>
</head>
<body onload="onLoad()">
<!- Main page body goes from here. -->
</body>
</html>

　　下面的图片展示了 Navigation Timing 接口所记录的各个时间点。

　　
　　（图片来源：W3C 网站）

　　目前，Google Analytics 的 Site Speed 功能使用了上面提到的方法四和方法五，因此现阶段还只能在安装了 Google Toolbar 或支持 HTML5 的浏览器上才能统计页面加载时间。

　　最后，有一些专门用于计算页面上各种计时的 JavaScript 框架，比如 Yahoo 的 boomerang 和 Google 的 Episodes，都可计算页面加载时间，它们综合使用了上面提到的方法三（使用 cookie 记录上一个页面离开的时间）和方法五，其中 Episodes 在不支持 Navigation Timing 的浏览器上还会尝试方法四，如果用户浏览器安装了 Google Toolbar 的话。另外，Episodes 的目标不仅仅是计算页面加载时间，它还提供了对更多的自定义计时的支持，并试图发展为一个工业标准，但似乎有段时间没有更新了。

我的2011年

oldj — Sat, 31 Dec 2011 23:13:56 +0800

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

　　一、做过的事

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

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

　　2、参与了犀牛书（《JavaScript 权威指南》）第六版的翻译及校对。

　　感谢老大及几位前辈的信任，让我这个默默无闻的三心二意的前端工程师也有机会参与这本书的翻译及校对工作。在这项工作上我累计投入了三个半月的业余时间。翻译及校对工作比原想的更难一些，不过，这个忙碌的过程也让我开始反思自己的时间管理方法，并开始尝试番茄工作法、GTD 等有趣的方法。

　　3、参与了 D2 论坛

　　在 D2 论坛上分享了我们在用户行为收集以及展现方面的一些经验。事后看视频，觉得自己讲得真烂，太羞愧了……

　　4、当爹了

　　12 月的最后几天，随着儿子的出世，我也终于步入父亲的行列了。从今以后，我就要对那个小生命负责，教他学习、教他分享、教他礼貌……，可是，好像有些东西我也还不怎么会呢！好吧，新的长征开始了。

　　二、读过的书

　　今年事情挺多，读书的速度比买书的速度还慢，年底时桌上床头还堆了若干本没来得及读的书。

　　这一年里读过的书中，我觉得对我影响最大的三本分别是：

　　1、《直面内心的恐惧》：读这本书简直是个自我剖析的过程，这本书可能会改变你对自己或他人的认识。

　　2、《失控》：一部关于复杂系统的著作，如果你之前不了解这个领域，这本书有可能会改变你的世界观。

　　3、《搞定》：这本书改变了我的任务管理习惯。

　　三、明年想做的事

　　虽然每年的明年计划都完成得不是很好，但还是写一下。明年我想做的事有：

　　1、用户行为数据的工作更深入一点（深入的具体标准会向我的老大汇报，就不在这儿写了 :-]）。

　　2、写一个自己用得着别人也用得着的开源软件。

　　3、写一个自己觉得好玩的游戏。

　　就这些了，各位 2012 年见！

生产率法则

oldj — Tue, 06 Dec 2011 21:13:35 +0800

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

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

　　上图展示了在长时间工作（加班）的情况下，生产率随着时间会如何变化。可以看到，一开始的三个星期里，生产率的确提高了，但提高的幅度在不断下降，到第四周时，已经降到和基线同一水平了，再往后，生产率将降到基线之下。长时间加班持续得越久，损失的产出其实越多。

　　下面是总的八个实验的列表：

　　1、长时间工作会有什么后果？
　　2、如果间歇性地努力工作会如何？
　　3、在知识工作者而不是工厂工人之间的实验；
　　4、有没有例外的人呢？
　　5、多大的开发团队生产率最高？
　　6、生产率最高的物质环境是什么样的？
　　7、怎么把不同专业背景的工作者组织起来？
　　8、应当按团队能力的百分之多少来安排工作日程？

　　详细内容，可以点击下面的链接下载我翻译的版本：

　　生产率法则.pdf

　　水平有限，某些地方翻译得可能不是很好，欢迎各位指正。:-)

IE下链接包含@字符时的一个问题

oldj — Wed, 30 Nov 2011 22:38:57 +0800

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

　　重现 bug 的代码类似这样：

<!DOCTYPE html>
<html>
<head>
	<meta charset="utf-8">
	<title>请用 IE6/7/8 访问本页面</title>
</head>
<body>
<a href="http://www.taobao.com" id="a-test">链接@BABY</a>

<script type="text/javascript">
	setTimeout(function () {
		var a = document.getElementById("a-test");
		a.href = "http://rate.taobao.com/";
//		a.setAttribute("href", "http://rate.taobao.com/");
	}, 3000);
</script>
</body>
</html>

　　示例可以看这儿：bug 示例。请用 IE6、IE7 或 IE8 打开，IE9 中已没有这个问题，同时，在 IE9 的兼容模式下也正常。可以看到，页面打开时，链接的内容为“链接@BABY”，一切正常，但当 js 函数执行，修改了 <a> 元素的 href 属性时，它的 innerHTML 值也变成了同样的值。除了直接给 a.href 赋值外，使用 a.setAttribute 方法也不行，甚至加上 a.setAttribute 的第三个参数也不行。

　　这个问题看起来是 IE6/7/8 的 bug。搜索了很久，与几位同事也一起研究了好久，但都没有找到有关这个问题的描述及解决办法。

　　最后，只好使出了最暴力但是有效的方法：

var a = document.getElementById("a-test"), s;
s = a.innerHTML; // 先记下 innerHTML
a.href = "http://rate.taobao.com/";
a.innerHTML = s; // 再将 innerHTML 的值写回去

　　不知道有没有更好的解决办法。

　　补充（2011-12-01）

　　上面那种先记下 innerHTML 的值，修改 href 之后再将它写回去的做法是有隐患的。比如，<a> 元素里面可能不是一段文本，而是一个 <img>，并且这个 <img> 上绑定了事件，那么，再将 innerHTML 写回去时，就会生成新的节点，原来绑定的事件也就失效了。

　　感谢 sophiasmth 提供了一个更好的方法，只需在要写入的 href 的值前面加一个半角空格即可，而现代浏览器会安全地忽略掉 href 值前后的多余的空白字符。即：

a.href = " " + "http://rate.taobao.com/";

// 或者：

a.href = " http://rate.taobao.com/"; // 注意前面的空格

　　暂时还没发现这种方式的副作用。

　　补充 2（2011-12-01）

　　进一步测试，发现如果 <a> 链接的内容以“www.”开头（如），也会有这个问题（测试页面）。看起来，凡是形如电子邮件（包含“@”字符）或网址（以“www.”开头）的字符串，在 IE6/7/8 中都有特殊行为。

　　补充 3（2011-12-05）

　　经小马的帮助，发现国外也有类似的报告，如 JavaScript modifying href changes link text as well for mailto: protocol 和 JavaScript HREF bug in IE。

学习GTD

oldj — Wed, 23 Nov 2011 22:59:26 +0800

　　GTD 是 Getting Things Done 的缩写，是一种任务管理的方法。这个概念由 David Allen 提出，并随着他的书《Getting Things Done》（中文版名为《搞定》）而广为流传。

　　我们都羡慕那些有着良好时间管理的效率达人，我们也都曾经或多或少地接触过一些时间管理方法或 todo 工具，或许你已经在使用一些感觉还不错的方法或工具了。那么，GTD 与其它方法相比有什么不同呢？

　　一、GTD 方法

　　GTD 方法分为五个步骤：搜集、处理、组织、回顾、行动。

　　搜集

　　GTD 的理念认为，我们的大脑并不擅长于记住太多的待办事项，我们每次往大脑里加入一件待办事项时，大脑的负荷就会增加一些，效率也会降低一些。因此，我们首先需要一个机制，将所有的未尽事宜从大脑中清空出去。

　　把这些未尽事宜清空的过程叫搜集。你需要将所有你想到的要处理或者可能要处理的事情全部搜集起来，放入一个妥善的收集箱之中。这些事情可能是工作上某个悬而未决的事项如新产品的发布计划，也可能是生活上某个拖了好久没处理的事情如换厨房的灯泡，甚至可以是某件暂时不太可能发生的事如设计自己梦想中的房子。搜集阶段的要点是不去考虑这个事情的重要程度与可行性，只做搜集，其它的都留到后面的步骤处理。

　　如果你第一次开始 GTD 的搜集工作，这个过程可能会花费较长的时间，比如半天甚至一两天。

　　收集箱可以是桌子上的一个真实的箱子，也可以是某种电脑或手机软件。收集箱的数目要少，可能的话一个就够了，并且要你随时可以很方便地访问，这样你才能确信，那些你所念念不忘的未尽事宜都在这里可以找到，只有你从心底确信这一点，你才能真正将一个事项从脑子里赶出去。

　　处理

　　搜集完成之后是处理，处理收集箱需要遵循一个严格的工作流程：

　　* 从最上面开始
　　* 一次处理一项
　　* 不把任何东西放回收集箱
　　* 如果一项需要采取行动，则确定它的具体的下一步行动，然后
　　　　* 马上处理（如果处理时间少于两分钟），或者
　　　　* 委托别人完成，或者
　　　　* 把它延期
　　* 否则
　　　　* 把它存档，以便将来查询，或者
　　　　* 把它扔掉，或者
　　　　* 把它放入“将来也许会”清单

　　每一个待处理事项都必须要有一个具体的可以执行的下一步行动。比如，如果收集箱中的某项内容是“整合 A 项目和 B 项目”，这就只是一个较为宽泛的目标，而不是一个切实可行的操作。此时应该将其分解，直到找到可以执行的下一步行动，比如这个目标的下一步行动可能是“召集 A 和 B 的相关人员讨论一下整合细节”，更具体的行动可能是“发起一个会议邀请给相关人员”，这时，发起会议邀请就是可以执行的下一步行动。

　　这儿有一个很重要的原则是两分钟原则，如果收集箱中某项需要处理的事件只需要两分钟就能处理完，则应该马上将它搞定，否则就将它委托或延期。

　　组织

　　接下来，我们需要将上一步中剩下的（未被丢弃和马上处理的）事项合理地组织起来。GTD 建议可以用下一步行动、项目、等待、将来也许会几个清单来管理需要采取行动的事项。

　　每个等处理事项都应该有一个具体的下一步行动，这些行动都可归入下一步行动清单。如果一个事项需要多个步骤才能完成，则应当将它列入项目清单。每个项目都应当至少有一个具体的下一步行动。

　　那些需要在指定时间或日期执行的下一步行动可以放入日程表中。

　　注意 GTD 中不赞成滥用日程表，日程表中应当只放置必须在指定时间或日期执行的行动，比如某个时间已定的会议，而不应该放置那些打算在那天做的事。在 GTD 中，日程表是一个神圣的地方，一个行动放入日程表，即表示该行动一定会在指定时间或日期得到执行或处理，而其它事项，则应当放入普通的下一步行动清单。

　　对大多数人来说，每天的工作总会有若干不确定性，比如原本计划接下来两个小时处理某项工作，但上司突然临时指派了一件紧急任务，或者突然有一个突发事件要处理。因此，那种每天早上规则好当天每一分钟的工作，然后完美地执行的愿望是极难实现的，所以我们不应该过度使用日程表来安排工作计划，日程表应该是属于天然有时间或日期属性的事务的领地，其它工作，应该放入更灵活的下一步行动清单中。

　　除了项目和下一步行动清单，我们还需要一个等待清单，用于管理那些委托他人处理的事项。你应当定期检查其中的任务是否已经可以采取行动或需要发出一个提醒。

　　回顾

　　大多数人都有这样的体验：在经过几天特别忙碌的工作之后，便对周围的工作失去了控制。回顾的作用则在于让你能够在更高的角度俯看全局，对所有的事项有一个整体的把握，同时保证你的系统中所有事项都已更新到符合最新的情况，从而可以让你决定什么是当前最重要的工作。

　　为了保持系统的完善，GTD 要求至少每周回顾一次所有悬而未决的事项清单：项目、下一步行动、等待、将来也许会。

　　行动

　　前面所有的步骤，都是为了帮助你对各类事务采取具体的行动。

　　在某个时间，应该处理哪个下一步行动呢？GTD 的回答是“靠你的直觉”。同时，GTD 也提供了一些建议，如根据当前的情境（在办公室还是在外面，在电话机前还是在电脑前）、有多少时间、有多少精力以及事务的重要性来决定，或者根据这个任务是属于预先安排好的任务、突发任务还是本身是安排任务的任务来决定，再或者，还可以从不同的层次来审视工作，根据它的重要程度到底有多高来决定。

　　以上就是 GTD 的基本内容。另外，GTD 并不建议将工作和生活分开处理，毕竟我们大部分人的工作与生活无论从时间上还是内容上都并不能完全分开，因此，应当将你需要处理的所有事务都纳入这一个系统中加以统一的管理。当然，这并不意味着工作与生活就会混杂在一起，事实上有很多技巧，例如使用“情境”，来在不同的场合过滤出相关的任务。

　　二、图示

　　GTD 方法的流程如下图所示：

　　
　　（注：图片来自互联网。）

　　三、相关资源

　　1、Doit.im 国人开发的 GTD 思想的在线时间任务管理系统；
　　2、GTDLife 时间管理达人的博客，很多 GTD 相关文章；
　　3、褪墨时间管理的博客，很多 GTD 相关文章；
　　4、一百步掌握GTD 关于 GTD 的若干要领。

发布一个快捷切换hosts的小工具：SwitchHosts!

oldj — Thu, 20 Oct 2011 21:17:51 +0800

　　日常开发工作中，我们可能经常需要切换各种 hosts 绑定，比如在本地开发时可能需要一个开发环境的 hosts 绑定方案，发布到测试环境后又有一个测试环境的 hosts 绑定方案，然后可能还有一个预发布环境，最后可能才是真实的线上环境。本地开发过程中，还可能有多组不同的 hosts 需要绑定，比如前端开发环境，数据库对应的开发环境……。其结果就是，我们经常需要在各个 hosts 绑定之间切换，这会花掉不少时间，而且这个过程毫无乐趣可言。

　　同事介绍过几个切换 hosts 方案的小工具，但看起来都不是很好，于是抽空自己动手做了一个小工具： SwitchHosts!。

　　这个工具是使用 Python + wxPython 开发的，因此在 Windows / Linux / Mac 上都可以运行。不过由于不熟悉 Linux 和 Mac 下 Python 的打包及编译，目前只提供了 Windows 下的二进制可执行文件下载，Linux 及 Mac 用户在配置好环境（Python / wxPython / chardet）后可以直接运行源码。当然，也非常欢迎熟悉 Linux 或 Mac 平台下的 Python 的大侠帮忙制作一个 Linux 或 Mac 版的可执行文件。:-)

　　程序在 Windows 下的运行截图如下：

　　程序还可以最小化到系统托盘，在托盘图标的右键菜单上也可以快速切换各 hosts 方案：

　　感谢黑三和小马勇敢地做了这个程序的小白鼠并提出了不少意见。

　　你可以在 GitHub 上查看或下载 SwitchHosts! 的源码。Windows 用户也可以直接下载下面的绿色可执行版本：

　　Windows 绿色版本下载：http://www.everbox.com/f/QTrmjdqBCMXlmG4lipbtmam6Dk。
　　如上面的下载链接失效了，也可以在 GitHub 或 CSDN 下载。

　　欢迎各位下载使用这个小工具，如果有什么问题或发现了 bug，欢迎在这儿或 GitHub 上给我留言。:-)

　　注意：请尽量不要将本程序放到中文目录下，不然可能不能运行... （感谢网友 xixi 的提醒）

关于让浏览器自动刷新

oldj — Sun, 16 Oct 2011 16:43:18 +0800

　　最近有人开发了一个叫 F5 的软件，用来监视某个目录下的文件，当文件改变时刷新浏览器。它非常适合前端开发使用，尤其是多个显示屏时。

　　我试用了一下这个软件，也大致研究了一下它的实现。它的原理很简单，在本地启动一个 HTTP 服务，将指定的目录作为根目录，开发者可以在浏览器中通过 http://127.0.0.1 访问这个目录下的文件。同时，这个程序会在访问的 html 文件中插入两个 js，如下：

<script src="/con/assets/js/jquery-1.6.3.min.js" type="text/javascript"></script>
<script src="/con/assets/js/br.js" type="text/javascript"></script>

　　服务器会监视本地目录上文件的变化，如果文件发生了变化，会通过上面的 br.js 通知页面刷新。于是，实时的刷新功能就完成了。

　　应该说，这个小软件很有创意，如果使用得当，有时的确能节省很多时间。

　　不过，由于它需要在本地自己架设一个 HTTP 服务，所有的请求都得通过这个服务，这就也给它带来一些局限，使得它（至少在目前的版本中）只适合用在纯静态页面的开发中。比如我最近经常需要调试 Django 程序的开发，在这类开发中，前端要修改的可能只是一些模板，如果没有后台的数据以及渲染，前端可能很难进行调试，这时，使用它的那个 HTTP 服务就力不从心了。所以，要是能有什么方法，能使用现有的 HTTP 服务，同时在指定目录下的文件发生改变后也能刷新浏览器就好了。

　　于是我想到了 AutoHotKey （以下简称 ahk）。其实，我们要做的无非两件事：

　　1、监视文件变化；
　　2、让浏览器刷新。

　　监视文件变化比较简单，复杂的是如何让浏览器刷新。上面介绍的软件的实现方式是自己架设 HTTP 服务，然后在页面中插入脚本与服务器通信。但如果使用 ahk 的话，我们好像可以在需要时直接向浏览器发送 F5 消息，这样一来就不需要架设 HTTP 服务了。

　　例如，下面的 ahk 脚本，即可实现让 IE 当前页面刷新的效果：

; send f5 to IE

IfWinExist, ahk_class IEFrame
{
	ControlSend, , {F5}, ahk_class IEFrame
}

　　非常简单，如果存在IE窗口（无论这个窗口当前是否获得焦点），向这个窗口发送一个 F5 消息。如果你的电脑上有 ahk 环境，并且打开了一个 IE 窗口，那么运行一下这段脚本，就能发现 IE 窗口被刷新了一次。

　　ahk 脚本也能被编译为 exe 文件，这样，在没有 ahk 环境的电脑上也能执行。上面的脚本以及它所编译出来的 exe 我在这儿（http://www.everbox.com/f/itPGwFHH5qNCguK5SLAp71mitG）放了一份，有兴趣的同学可以下载到本地试试。

　　这样，我们就有了一个新的实现文件修改后浏览器实时刷新的方案：以某种方式监视指定目录或文件，满足一定条件时使用 ahk 脚本（或者 ahk 脚本编译出的 exe）向浏览器发送刷新消息。

　　不过，这种方案也有一些问题，比如 ahk 目前只支持 Windows 平台，所以这个方案也只能在 Windows 下有效。

　　先写到这里，如果有人想到其它方案，欢迎给我留言。:-)

绿色版“python -m SimpleHTTPServer”

oldj — Fri, 23 Sep 2011 21:59:45 +0800

　　pySimpleHTTPServer 是一个简单的 HTTP 服务程序，功能与在安装了 Python 环境的机器上执行“python -m SimpleHTTPServer”一样。

　　由于经常需要临时搭建一个 HTTP 服务用于测试，在安装了 Python 环境的机器上这很简单，但有时需要在一些只有最基本的系统的测试机上做测试（比如测试页面在 IE6/7 下的表现），因此，我将 Python 的这个方便的功能做成了一个绿色 .exe 文件。

　　源码很简单：

# -*- coding: utf-8 -*-

u"""******************************************************
pySimpleHTTPServer

@about: http://oldj.net/article/py-simple-http-server/
******************************************************
"""

import sys
import BaseHTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
HandlerClass = SimpleHTTPRequestHandler
ServerClass  = BaseHTTPServer.HTTPServer
Protocol     = "HTTP/1.0"

port = int(sys.argv[1]) if sys.argv[1:] else 8000
server_address = ('127.0.0.1', port)

HandlerClass.protocol_version = Protocol
httpd = ServerClass(server_address, HandlerClass)

sa = httpd.socket.getsockname()
print(__doc__)
print("Serving HTTP on %s, port %d..." % (sa[0], sa[1]))
httpd.serve_forever()

　　然后，使用 pyInstaller 制作成 Windows 平台可执行的绿色软件，就大功告成了。

　　pySimpleHTTPServer 的用法很简单，直接双击，然后在浏览器访问 http://127.0.0.1:8000 就可以了，网站的根目录就是 pySimpleHTTPServer 程序所在的目录。也可以使用命令行运行，如：

cmd> pySimpleHTTPServer 8080

　　其中第二个参数是 HTTP 服务的端口，如果省略则为 8000，可以指定其它值。

　　最后，再贴一下下载地址：http://www.everbox.com/f/MQH4VdlA822odpKOuvkPkUUEuV。

关于黑暗森林

oldj — Sun, 21 Aug 2011 16:04:20 +0800

　　关注国内科幻小说的朋友应该对“黑暗森林”这个词不陌生，是的，这儿说的就是大名鼎鼎的刘慈欣（以下简称“大刘”，“大刘”即“大名鼎鼎的刘慈欣”）在他的《三体》三部曲第二部中提出的那个黑暗森林。虽然在《三体》第三部中作者对黑暗森林的概念做了一些延伸和补充，但总的来说，这个词的含义基本上就是第二部结尾处对它的描述：

　　“宇宙就是一座黑暗森林，每个文明都是带枪的猎人，像幽灵般潜行于林间，轻轻拨开挡路的树枝，竭力不让脚步发出一点儿声音，连呼吸都必须小心翼翼：他必须小心，因为林中到处都有与他一样潜行的猎人，如果他发现了别的生命，能做的只有一件事：开枪消灭之。在这片森林中，他人就是地狱，就是永恒的威胁，任何暴露自己存在的生命都将很快被消灭，这就是宇宙文明的图景，这就是对费米悖论的解释。”

　　这个理论的有趣之处在于，它向我们描绘了一个黑暗的宇宙图景。和我们所看的大多数科幻不同，也与我们所接受了多年的教育及幻想不同，黑暗森林告诉我们，宇宙是一个极为险恶的地方，如果存在外星文明并且他们发现了我们，他们几乎不可能对我们表现出善意，更可能的是毫不犹豫地消灭我们，同样地，如果是我们先发现了外星文明，我们所能做的最明智的选择也是立即消灭他们。在宇宙中，跨越种族的星际大同几乎不可能存在，被发现，即被毁灭！

　　对大多数人来说，这个理论可谓惊世骇俗，在看惯了各种友好的外星种族的描述之后，大刘在《三体》中告诉大家：科幻小说不是成人童话，而是充满了血与火的冒险。自从《三体》第二部出版以来，网络上关于黑暗森林的讨论数不胜数，有人赞同有人否定。对于一部小说来说，能引起这么多的思考和讨论，真是超乎寻常的成功，无论大家是否赞同大刘在著作中的观点，他至少启迪了我们的思维，给我们展示了另外一种可能。不过我看了很多讨论，发现大部分赞同的人似乎没有提到我比较认同的理由，否定的人也没有给出让我信服的论证，因此也在这儿随便写一点自己的一些理解。

　　一、宇宙中的黑暗森林

　　在《三体》中，黑暗森林其实是对“宇宙社会学”的一种简单比喻。“宇宙社会学”有两大基本公理：

　　1、生存是文明的第一需要；
　　2、文明不断增长和扩张，但宇宙中的物质总量保持不变。

　　乍一看，多像经济学中的理性人以及有限资源假设啊！

　　除了这两大公理，书中还提到两个重要概念：猜疑链、技术爆炸。

　　根据这两个公理以及两个重要概念，书中的面壁者罗辑终于推导出了黑暗森林模型，这个模型构成了《三体》第二部和第三部的理论基础，也成为三部曲最大的亮点。但接着，在合上书之后，或许很多人都和我当时有一个相同的疑问，真实情况会不会就是这样？我们的宇宙会不会真的是一个黑暗森林？

　　但是，黑暗森林太黑了，拿书中的话来说，就是：“黑，真他妈的黑啊！”因此，很多人都说，《三体》很好看，黑暗森林是作者为了情节需要假想出来的，真实的宇宙不会是这样。是啊，越先进的文明，道德水平应该越高，他们怎么可能做出这么黑暗的事呢？

　　也有一些读者接受了大刘的理论，他们发现，这个理论在逻辑上似乎是自洽的，现实真的有可能是这个样子！有一些读者还以各种方式对这个结论进行论证。

　　我属于后面一类读者，我认为大刘的设定及推导是没有问题的。（当然，小说中为了通俗易懂，他省略了大量严谨的推导步骤。）

　　我们先来看“宇宙社会学”的第一个公理：生存是文明的第一需要。

　　很多人表示不同意这个公理，认为一个文明发展到一定层次后，会追求一些更高尚的东西。其实我认为这和这个公理并不矛盾，可以参考马斯洛需求理论，把其中的人类个体替换为文明。当然可能存在舍生取义的文明，就像存在舍生取义的个体一样，但这不是主流，舍生取义的文明都死了，只有活下来的文明才能不断繁衍壮大。

　　第二个公理“文明不断增长和扩张，但宇宙中的物质总量保持不变”其实可以分为两个。关于前半句“文明不断增长的扩张”，当然可能存在非常保守的文明，就想在一个小地方呆着，并且严格控制自己的人口，完全没有扩张的野心。但这样的文明很容易被淘汰掉，想想地球人类的历史吧！后半句“宇宙中的物质总量保持不变”，就目前人类对宇宙的了解来看，的确是这样。另外，这两句合在一起之后，还有一个效果：宇宙中哪怕绝大部分文明都采取保守策略从不增长和扩张，但只要有一个文明例外，这个不断地增长和扩张的文明就终究会触及宇宙中物质总量的底线。

　　如果两个公理基本上没有问题，我们再继续往下看。光有这两个公理，其实还不足以导致黑暗森林状态，比如地球上各个国家也处于类似的状态，各个国家首先也要保证自己的安全，同时不断地发展，但地球上的总资源是有限的。虽然地球上各国之间摩擦和战争不断，但似乎从没走到像黑暗森林那样的状态。

　　因此，作者提到了两个重要概念：猜疑链和技术爆炸。

　　很多读者，甚至包括作者，都补充了很多其它信息或条件，比如宇宙空间超远的距离，以及由此而来的通讯的低效（根据相对论，信息的传递不能超过真空中的光速，比如我们向最近的恒星半人马座α发出一条消息，要 8 年多后才能收到回复，虽然可能存在根据量子纠缠态制作的可以超距通讯的智子，但第一次将智子发射到对方星系的过程还是不能超过光速），这些都将加长猜疑链。但其实，这两个重要概念中，真正重要的是技术爆炸，猜疑链只是技术爆炸的结果。而技术爆炸的背后，其实是双方无法判断对方是不是拥有能置己方于死地的能力。更确切一点来说，是双方无法判断对方现在或者在不久的将来是否具备：

　　以较低的成本彻底消灭对手的能力！

　　我们来设想一下，宇宙中两个文明相遇了，假设他们相互合作共同发展，双方都能获得最大的收益（比如收益为1），如果相互攻击，则双方都遭受损失（比如收益为-8），如果一方攻击另一方不攻击，则攻击的一方收益不变，被攻击的一方收益最小（比如为-10）。这时，两个文明就陷入了典型的囚徒博弈。

　　如果这个博弈能进行很多次（比如无限次，或虽然次数有限，但谁也不知道最后一次是什么时候），那么最终能取得优势的一定是类似一报还一报（Tit for Tat）这样的合作策略，简单来说是合作策略，文明不会主动彼此攻击，宇宙是光明的，黑暗森林不存在。但这需要一个前提，就是这个博弈能进行很多次。如果像上面说的，文明拥有低成本消灭对方的能力，那么这个博弈就将只能进行一次，囚徒博弈就沦为囚徒困境。这时，任何失误都是致命的，和谐的运动会变成了惨烈的生死决斗，每一次博弈都只有一次机会，失败者将被永远淘汰。在这样的情况下，博弈的双方如果足够理智，必然会选择背叛，剩下的，就看谁先出手了。于是，黑暗森林产生了。

　　如果双方都相信甚至只是怀疑对方具备这样的能力，那么，双方甚至不需要相隔千万个天文单位，即使是近在咫尺，两者之间也会产生足够长的猜疑链。

　　人类的文明才区区几千年，进入核能时代才区区几十年，但人类制造的核弹已经有能力毁灭地球或类似大小的行星若干次了。有理由相信，对于宇宙中其它高等文明而言，毁灭一颗恒星甚至一个恒星系也不是难事，甚至人类在不久远的未来也会具备这样的能力。对这样的文明而言，要消灭一个生活在一个恒星系中的异族，或许成本真的不太高，可能只相当于现在的我们发射一颗洲际导弹，但不消灭对方的成本却很高，可能是被对方消灭。

　　即便一个具备毁灭能力的种族遇见了另一个暂时不具备这种能力的种族，由于技术爆炸的可能性，前者也根本无法确定后者不会不“马上”（对于星际空间来说，几十年甚至几百年都可以称作马上，这段时间足够发生技术大爆炸了）具备这种能力，所以它能做的，还是只有“清理”掉后者。

　　对于《三体》中的三体文明而言，占领地球消灭人类文明就是一件有能力做到且低成本的事，对于更高级的歌者文明而言，消灭三体星系和地球更是一件简单得不能再简单的事。宇宙中可能有千亿个文明，无论你现在发展得多么强大了，总是有人比你更强大，由于有这样的可以轻易消灭己方文明的敌人的存在，所以，宇宙是黑暗的，对于文明而言，生存的最佳策略是“藏好自己，做好清理”。

　　有人可能会问，你说距离不重要，重要的是低成本消灭对方的能力，那么冷战时期的美苏两国之间为什么没干掉对方呢？它们都有核弹，都有能力消灭对方。

　　冷战的历史很复杂，不是我所能讲清楚的，不过当时的美苏两国其实并不具备“低成本”消灭对方的能力，虽然它们有核弹，但不能保证弹打击之后对手立即失去还手的能力，不能保证能彻底消灭对方，更重要的是，核打击的成本太高，倒不是说造核弹太贵，主要的是美苏两国同处于一颗行星上，核打击可能引发核冬天，最终可能导致共同灭亡，这个成本太高了。

　　类似地，宇宙中的黑暗森林状态一般也只存在于高级文明对低级文明之间，因为一般只有这样的文明差距才会让前者有低成本彻底消灭后者的能力，如果前者做不到这一点，则两者之间的博弈将演化为更为复杂的情况，或许会类似于冷战时间的美苏争霸。大刘在《三体》第三部中也提到神级文明之间的战争，那是真正的实实在在的战争，而黑暗森林，只不过是大神之间互殴时的一些小小的微不足道的插曲。

　　但这种插曲要存在必须有一个前提，即前面提到的，一方能以一种低成本的方式彻底消灭另一方。如果我们这个宇宙中，真的存在无数的文明，并且真的存在类似大刘描述的那种对高级文明而言成本非常低的质量点或二向箔攻击，如果真的存在类似的攻击武器或手段，那么，宇宙必然会成为一种黑暗森林的状态。

　　如果存在这样的攻击武器或手段，那么，即使宇宙中上千亿个文明中 99.99% 的文明都是保守的或善意的，但只要有 0.01% 甚至 0.00001% 甚至更少的文明是恶意的，黑暗森林就会出现。就像木桶能装多少水取决于它最短的那块板，宇宙的森林有多黑则取决于它最黑的角落有多黑，这大概是黑暗森林版的水桶原理吧！

　　二、IT 世界的黑暗森林

　　一定有人还是不愿意相信黑暗森林的存在，他们从心底希望这个世界是光明的，即便有黑暗也只是暂时的和局部的。但我想，在国内从事 IT 行业的人不应该抱有这样的想法，因为我们所处的行业就是一个黑暗森林。

　　看看这个表格吧：

宇宙	IT行业
生存是文明的第一需要	生存是企业的第一需要
文明不断增长和扩张，但宇宙中的物质总量保持不变	企业不断发展和扩张，但市场总大小在一段时间内相对保持不变
猜疑链	猜疑链
技术爆炸，一个落后的文明可能在短时间内赶上甚至超过先进文明	新应用爆炸，一个不知名的小应用可能在短时间内占领市场并成为主流
先进文明具备低成本彻底消灭落后文明的能力	大公司具备低成本扼杀小公司的能力

　　想一想，微软是怎么发家的？Google 是怎么崛起的？Facebook 又是怎么流行的？在这个行业，任何一个人都不知道三年甚至一年后会发生什么变化，任何一个不起眼的小网站都可能会引领下一场革命，几个在车库里敲代码的默默无闻年轻人可能在几个月后就成为了举世瞩目的明星，那个现在不可一世的大佬可能半年后就被一家不知名的新成立的公司拉下了神坛。看看这个快速变化着的世界，像不像那个遥远冷寂但随时可能发生技术爆炸的宇宙？

　　再看看 IT 世界的大佬们对那些后起之秀们做了些什么吧！每当有人想出了什么好的点子，做出了一个不错的新东西，总会至少有一位大佬将它原封不动地抄过来，然后利用自己已有的庞大的用户群及资源的优势，把原来的创新者消灭在摇篮之中（参见《狗日的腾讯》）。这像不像《三体》中神级文明对低级文明的黑暗森林打击？

　　大佬们为什么不愿意和新秀们和平共处，共同建立一个 IT 大同世界？因为新的应用爆炸随时可能发生，那些现在看起来毫无威胁的小公司，很有可能在极短的时间内崛起并取代现在大佬的位置。大佬不能允许这样的事情发生（或者说，允许这样的事情发生的大佬都已经被消灭了，自然选择的结果是只有具有“清理”基因的大佬才能存活），但只要发现及时，扼杀这些小公司对它们而言是很简单成本也很低的事，它们最有力的武器，就是抄袭，在 IT 世界，大佬们手中的这个武器就相当于《三体》中的质量点或二向箔（其实二向箔更像另一种打击，想一想饭否与新浪微博之间的前世今生），拥有完全消灭小公司的能力。

　　当然，正如同《三体》中，黑暗森林并不是宇宙的全部，其实它只是更大的宇宙战争之间的插曲，真正的宇宙战争超乎《三体》中的人类的想象，抄袭也并不是 IT 世界的所有手段，更大规模的正面战争发生在现有的诸位大佬之间，比如腾讯、百度以及阿里几大巨头之间的竞争，这一些竞争可能与黑暗森林没有直接的联系，但由于这些巨头的存在，这个行业对新创立的小公司而言，就是一片黑暗森林。

　　另外，正如很多人所期望的那样，几大巨头似乎并不是人人都热衷于打压新的小公司。但正如上面的水桶原理所说的，这个环境中，只要有一个大佬采取黑暗森林打击的做法，整个环境就会变成黑暗森林。据说很多小公司找 VC 时，VC 都会问他们一个问题：“你们做的东西，如果腾讯也做怎么办？”就算百度、阿里、盛大、网易、新浪、搜狐这些大佬都对新出现的小公司采取宽容的态度，只要有一个巨头（比如腾讯）对它们进行打击，这个环境对这些小公司来说就是一片险恶的黑暗森林。

　　不过，从公司之间的竞争上，我们似乎也看到了黑暗森林的另一个光明一点的解：收购。对于小公司而言，如果没有机会独自发展壮大，那么被收购总是比被消灭要好。当然，前提是，要有大佬认为你值得收购，并且收购你比消灭你更划算。

　　对应地，在宇宙中，不同的星际种族之间，是否可能发生类似的“收购”呢？或许新发现了一个文明后，大佬除了“清理”，还有一个“招安”的选择？也或许，不同种族之间巨大的鸿沟导致文明不可能完全融合，进而导致这种“收购”不可能发生，大佬仍然只能进行“清理”？这一切现在的我们都无从知晓，毕竟，在辽阔的宇宙中，我们还只是小小的孱弱的虫子。