追风逐月

这几天闹心的很，到处都是关于百度Hi和Wordpress2.5的文章。
我也不能无动于衷了。
对于百度Hi,看过一些博友的介绍，感觉就是QQ，Gtalk和MSN的杂交品，并无多少出彩的地方。也就甚少兴趣试用。我想如果百度hi，使用xmpp协议的话，我可能还会关注一下，可惜没有。追风认为面对强大成那样的QQ，只有开放才能打破它的垄断地位，就像Firefox挑战ie一样。百度Hi,会不会重蹈前辈们的覆辙，追风还需要冷眼旁观。
对于Wordpress因为本人一直在使用，这次Wordpress官方一改以往拖沓的风格，26号发布RC2, 28号发布RC3，30号就发布了正式版。连其官方网站也改成了Wordpress 2.5的界面风格，这确实有点让人吃惊。看来Matt可能都有点迫不及待了。 至于Wrodpress2.5给我们带来了什么？本人播客顺利升级完毕，没有发现什么问题，除了后台管理界面变化比较大，增加了一个Media Library之外，目前还没有发现什么激动人心的改变．
PS:wordpress升级到2.5方法

下载Wordpress2.5正式版
备份你的wordpress数据库和目录
上传压缩包到你的主机空间，解压缩并直接覆盖原来的wordpress目录
当你登录你的管理后台时，会提醒你数据库需要升级，点击Continue就可以了

因为本博空间在国外，速度不是很快,一直想找一款合适的客户端编辑软件。漫步收集了10 佳免费 Blog 客户端软件,我看了一下，第一个推荐的就是Windows Live Writer,可是当我下载下来进行安装的时候，提示我
"很抱歉，Windows Live 程序不能安装在 Windows Server ,Window XP Professional x64 Edition 或早于 Windows XP Server Park 2 的windows 操作系统中"

很晕很无奈，我只有放弃，然后一个一个的继续往下查找，虽然各有特色，有些还有不错的功能，但是没有一款可以添加wordpress的post slug.
在网上继续搜索，发现有一篇帖子说到新版的Windows Live Write可以实现自动识别Blog类型，并针对Wordpress显示特殊的发布参数，当然也包括post slug了。可是我的windows 2003装不了新版的Windows Live Write啊。
再次搜索，功夫不负有心人，终于在一个德文网站找到了可以在windows 2003下安装的版本，虽然是英文版，问题也不大吧。
这篇文章就是用Windows Live Write写的，感觉很不错。

是博客就有Rss, 但是RSS Feeds应该如何发布确是个问题。这里可以看看发布Feed不同方法的比较，权衡了一下，觉得还是使用自己的域名来发布Feed比较靠谱一点。
可以考虑FeedBurner的MyBrand 或者是 FeedSky的FeedDomain。这两个服务的功能十分相似，都是把自己的域名绑定到解析到服务商指定的服务器上，然后用自己的域名代替原来使用的第三方的Feed url,从而达到既能享受第三方的统计分析功能又能保留自己feed url的控制权。一旦第三方服务出现问题，可以迅速的更换为其他服务商。
考虑到FeedBurner的在国内无法访问，最终决定使用FeedSky。
FeedSky提供的域名绑定，也称FeedDomain，可以协助拥有独立域名的用户，将自己的域名与Feed地址绑定，以通过自己的域名来访问自己在Feedsky烧制的Feed。
使用Feedsky托管的可以按照下面进行更改：

登录到你的域名解析控制后台，然后新建该子域名，如我的域名feed.chyni.com，将解析方式选为CNAME，其值为：mydomain.feedsky.com
登录Feedsky管理Feed后台,选择Feed优化-域名绑定，在域名输入框中填入您的Feed域名，如feed.chyni.com
一般来说，域名解析需要一段时间才能生效，你可以ping你设置的子域名，返回值为61.4.177.18时说明解析已成功，当然这也只是表明在你所在地区已经生效，如果Feedsky提示错误的话，说明在其他地区还没有生效，请耐心等待

因为服务器搬迁，本人的博客停止更新了很长一段时间。
虽然搬迁前已经对blog数据进行了备份，但是，很不幸当我再次想要恢复博客的时候，却找不到了。
没办法，难道就放弃以前写的文章了吗？虽然文章写的不多，但总还是自己一个字一个字码出来的。总觉得可惜。（呵呵，这已经是本人博客第4次搬迁了，有点狗熊掰玉米的味道）。
好在现在有很多在线阅读器，而我基本上也会把自己的blog订上。我依次使用过google reader, 抓虾，哪吒，鲜果等在线阅读工具。进去看了下，好像所有这些网站都把我以前的文章完整的保留了下来。呵呵，看来有戏！
我于是挨个查找了一遍，尽然都没有完整的Rss输出，my god.不会吧。于是又找了一遍，突然想到google reader可以输出共享内容的feed，我试验了下，虽然不可以直接输出单个feed的rss,但可以把整个目录(label)共享并输出feed，呵呵，这就有戏了.
赶紧开始工作:

在google reader 中新建一个label ,取名为newrss
将本博归入newrss
在setting-tags页面将newrss设为共享
view public page 查看对应的共享页面
查看这个页面的feed，内容果然输出了，呵呵不错
好像只有20条记录，不够啊，看看有没有办法输出全部呢？网上找了一下，运气还不错，google提供了api给我们（参考http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI），只要在生成的链接后面添加n=1000,就可以输出1000条记录,够了吧
生成的链接最终是这样的 http://www.google.com/reader/public/atom/user/（user-id)/label/newrss?n=1000

接下来：赶紧把这个feed保存到本地，并通过wordpress的导入功能(manage-import)，导入这个feed,找来找去好像只能通过rss导入，管他呢，试一下。
导入成功，赶紧看一下。什么？没有内容？哦，是的，没有内容。试了几次都是没有内容。
怎么回事呢？原来wordpress只支持rss格式的导入，而google只支持atom格式的输出，该死的标准之争。不知道该怨google还是怨wordpress，难道就不能多支持几种格式吗？
又得辛苦了，召唤中…
呵呵，世界这么大，总有热心人。http://atom2rss.semiologic.com/ 把atom转换成Rss2格式，把转换后的文件再次导入wp,成功。到此为止一切搞定!

厌倦了very very不爽的ms ajax.net类库，终于决定要使用jquery把它替换掉。
Jquery的好处，就不用说了，简单，方便，人见人爱，车见车载啊… …

昨天更新网站，发现”Cannot use a leading .. to exit above the top directory.”，也就是＂无法使用前导 .. 在顶级目录上退出”错误。
找了半天没发现哪里使用了..／这个设置，郁闷的很，因为昨天太晚就暂时放下了。
今天早上，继续查找，突然想到，会不会是模版文件（main.master）中存在这个东东呢？
检查了一下，原来是把
PLAIN TEXT
HTML:

<link  href=“~/css/user.css” rel=“stylesheet” type=“text/css” />

写成了

<link  href=“../css/user.css” rel=“stylesheet” type=“text/css” />

看来研究问题的时候，适当的放一下，是不错的，否则很容易陷入死胡同．

一口气装了两个php的论坛discuz,phpwind，phpwind很容易就完成了，discuz却颇费了些周折。
装完后出现了
Cache List: style_
Caches successfully created, please refresh.

但怎么刷新都进不去，郁闷的很。上官方网站，用google,baidu都搜索不到好的方法。总算有这篇文章的帮助，找到了一些方法，但是试来试去，一个方法都不行，郁闷之极。
不过最后还是仿照上面文中提到的，查找Caches successfully created, please refresh.，将common.inc.php中的//dexit(’Cache List: ‘.$cachelost.’Caches successfully created, please refresh.’);屏蔽掉，才算解决了问题。 discuz,真是想说爱你不容易啊！

今天为了安装discuz论坛，在windows2003下安装了php环境，一步一步安装完后，却发现无论什么页面，即使也简单的phpinfo页面也无法显示，表示为一片空白，尝试了网上介绍的所有方法，也没有解决。
没法子，只能找到一个以前配置好的机器，对照查看，到底哪里有问题。最后发现，原来是php.ini文件的问题默认文件里有个doc_root =选项是注释掉的，必须去掉注释才可以，后面的值留空就可以了，和我遇到相同问题的朋友可以试一下。另外网上流行的说法是修改short_open_tag = On，好像没什么用，可能只是对discuz有用吧。

一直以来都在项目中使用了UrlRewritingNet模块来实现url重定向的功能，很是方便好用。但有一个问题一直没有解决，就是当用户访问需要登陆的页面是会自动转到login页面，这时其returl参数会将原始的url暴露出来，很是不爽。
今天花了点时间研究了一下，发现

UrlRewriteModule是在BeginRequest事件中进行重写的
Form认证模块(FormsAuthenticationModule)是在AuthenticateRequest中进行权限判断的
AuthenticateRequest事件晚于BeginRequest执行，所以认证过程中产生的returl肯定是取不到原始的rawurl了
为了让returl能够保持为原始的url，需要将UrlRewriteModule的重写改在AuthorizeRequest事件中执行

UrlRewritingNet没有提供这种选项，所幸的是这是个开源的工程，于是将其代码进行了一些修改。增加了一个RewriteOnRequestBegin的配置参数，在其初始化方法中修改代码如下：
PLAIN TEXT
C#:

if (UrlRewriting.Configuration.RewriteOnRequestBegin)

{

context.BeginRequest += new EventHandler(OnBeginRequest);

}

[…]

dnscoop.com为你提供了全方面分析和评估服务．综合了搜索引擎，alexa,Pagerank,Textlinkad等元素，为你的网站做出价值分析．
这和我上次发的看看你的网志（Blog）价值几何？应该是一致的．
看看我的：

My Site is worth$80
How much is your site worth?