其实 GAppProxy 很早以前就挺好用了，但是一直有一个问题，就是很多时候会显示一个空白页面。显示空白的大部分都确实是不能访问的，并非 GAppProxy 搞错了。但是我对此很不爽，因为导致空白的原因是很多的。包括各种各样的异常没有catch，包括超出了 Google App Engine 平台的限制等等。它光显示一个空白，你根本不知道发生了什么。

前不久，我对它进行了各种边界测试，把能想到、能碰到的所有错误分类开来。然后在无法代理的时候，向用户浏览器显示一条信息。告诉用户现在是什么状况，具体是什么原因。dugang 也觉得这样很好，在我的基础上进一步细化了。然后，GAppProxy 1.0beta 发布了。

但是接下来的反馈有点出我意料。很多人说 GAppProxy 不能用了啊，怎么办啊？要知道，它以前输出空白的时候甚至没人反应过。

我有点纳闷：我不是解释得很清楚么，就那么一行字，您就不能看看？
后来我意识到，我们两都是典型的 Unix 的想法。就是认为，有问题你给它暴露出来，说明白咯、别藏着掖着。

但是用户有很多是 Windows 的用户。Windows 的一贯传统就是，把问题都藏起来，我们的用户是温室里的花朵，千万别让他们见到任何风雨。在这种风格的影响下，很多 Windows 的用户只要看见跳出一串英文就觉得很怕怕，根本不会去看它到底在说些什么。

其实，之所以有这么一串字符，是因为作者已经考虑到了这种情况。他既然已经考虑到了，自然会做最优的处理。这有什么好怕的。
反倒是那些出了问题也默不做声的，很可能是因为作者的逻辑出了问题，他根本没有考虑到这一点。还有什么比这更可怕的？

有时候我很想说：Don’t panic!

其实，我对很多事情充满着兴趣。比如说某一个知识点，我常常想，哇这玩意儿太牛叉了！一定要把它搞懂了、弄透了。然后开始幻想，如果这一切都了然于胸，自己将会多么牛叉。激情也就跟着来了，为了探个究竟，可以茶饭不思、夜不安寝。

按理说，我应该有很多话题想说的。可是偏偏，我又很“喜新厌旧”。无论之前觉得多么牛叉的东西，等到回过头来，都觉得不过尔尔，真的是沧海一粟、不值一提。大概这就是我的 Blog 好几个月才有一次更新的原因吧……。

虽然我对“物”喜新厌旧，但对“情”却是很怀旧的。这个 NN 年前的 Blog 的模板，我常常想换掉，常常打算换成独立 Blog，但都一直没舍得。自从与 Blogspot 并肩作战已经过去了 5 年，虽然成功地逃过了 GFW，但我与 Google 之间脆弱的协议，早已荡然无存。啊？什么？？？^H^H^H^H^H^H^H^H^H^H…..

P.S. “最近” 参与的一些社区活动：

Firebug 简体中文化。firebug 就不用介绍了吧。值得一提的是，虽然官方只写了我一个人的名字，但其实我开始这个项目的时候，已经有一些基础，并不是从零开始。作者说，是人家给他的，不知道是谁。。

Adblock Plus 之 ChinaList 维护。更不用介绍了。。一开始是一个台湾同胞维护的，不知什么原因他“失踪”了，我就接了下来，后来又成功地引诱了两个人加入~~。ChinaList 易主之后，有了天翻地覆的变化。很遗憾的是，它居然没进 ABP 的默认列表，偏偏我又是个不喜欢争的人。希望有一天作者会发现，我们维护得是多么认真负责，ChinaList 绝对算得上是列表中的典范。

e2fsprogs 简体中文化。e2fsprogs 是 Linux 内核中操作 ext2/3/4 文件系统的一系列工具的组合。比我想象的慢了不少，但是争取每个疑点都实际测试过后再作定夺。质量优先，慢就慢点吧。

加入 GAppProxy 项目。GAppProxy 最近才热起来，但其实这个项目开始已经快一年了。

AutoProxy。是 FoxyProxy 让我产生这些想法的。当时，我一方面欣赏 FoxyProxy 的强大，一方面又对它很不满。我就在想，一个“完美“的代理扩展应该是个什么样子。后来我把想法告诉了 FoxyProxy 的作者，费了老大的劲（几千的词汇量？）。他表示很有兴趣，但是好几个月过去了根本没动手。有个说法，这个东西 scratched my itch。我猜测其实他并不需要代理，自己都不是自己作品的用户，做起来自然没多少动力。原打算给 FoxyProxy 提交几个 patch 的，但是我对它的界面跟实现都很不满意。
AutoProxy 的传播超出了我的预料，本来只是打算非常小范围地测试一下看看反馈，毕竟很多想法还没完工。好在，从各方面反馈来看，没有什么大的问题。主要是菜单设置不合理，缺乏应有功能。这本来就在我的计划之中，正是下个版本首要解决的任务。