我看好鲜果阅读器November 20, 2007
第一次知道 鲜果阅读器 是在今年五月底的时候。那个时候我并不怎么在意，因为我一直是 Google Reader 的忠实用户。我一直以为鲜果是 抓虾 的 Copy 而已，并没有怎么的在意它。而近期无意间关注了下鲜果阅读器，我发现发的界面有很多的改变，功能也比刚上线的时候增强了不少。
这下有好戏看了，我要看看抓虾怎么对于这个用户群完全一样的对手了。我当初在选择在线阅读器的时候在抓虾和 Google Reader 之间犹豫不决。虽然我最后选择了当初只有英文版本的 Google Reader，但是我一直很期待 Google Reader 能像抓虾一样有一个 RSS Feed 的共享社区。
曾经有一段时间我每天上抓虾看下是否有其他「更精彩」的 Blog，然后将其拉回 Google Reader。我之所以那么「执着」的使用 Google Reader 是因为它出色的兼容性和易用性。从兼容性方面来说，Google Reader 几乎可以在任何的浏览器上使用（甚至包括了移动版本的 Opera Mini）；其次从易用性方面来说，Google Reader 几乎可以不用设置，你直接将 Rss 的链接加入 Google Reader 以后就可以了。之所以依赖 Google Reader 也部分其他的原因，就是 Firefox 能直接将 Rss 扔到 Google Reader 中。要知道，使用 Google Reader 的大部分用户同时也是 Firefox 的使用者。
说道这里似乎有点离题了，我所以看好鲜果是因为它清楚的市场定位。鲜果近期推出了「博客认领」的功能，它可以将博客和其作者对应起来。这个功能意义是非常巨大的，它摆脱了以前单一的 读者 - 读者 共享方式，使 Blog 的作者 - 读者 之间有了一个直接的交流。
鲜果的「热榜」功能则能直接的给出相应分类下订阅量最多的博客。订阅者的「羊群效应」是明显的。设想一下，刚了解怎么使用 Rss 的用户保证会满天下的寻找 Rss Feed，最终他们往往「相信」的是订阅最多的 Blog。
鲜果的「雷达」软件是在线阅读器的衍生。它可以让用户在桌面端随时知道自己的 OPML （Rss 订阅列表）更新。这是一个非常不错的功能，鲜果的确是想用户所想。
说了那么多，但是我目前还是处于观望状态。对于我「这些」原本就使用某阅读器的用户来说，适应也一种过程。Rss 阅读器本身就是一种粘性非常强的产品。
目前的鲜果已经可以用「优越」两个字来形容了，但是我个人认为还有一些细节可以考虑一下。比如用户的自身的阅读趋势。这点在 Google Reader 中本人使用的非常的频繁，因为它可以迅速知道哪些频道是许久未更新哦，哪些频道是自己最常看的。其次，将推荐或收藏（Google Reader 中称为「加注星标」和「共享」）自身生成一个 Rss Feed，这样可以被 Feedsky 等进行 Rss 合烧，让更多的读者知道我们（Blogger，内容的产生者）每天在阅读那些条目。
最后，发布一张我的 Rss 订阅比例，虽然 Google Reader 还是是以「压倒性」的优势占据了大部分的 Rss 阅读器市场。不过我有理由相信，依据目前鲜果的发展态势，完全可以有更好的作为。
由于暂时使用国外的空间，在我发布 Blog 的时候发现时间总是不对。依据我以前编写程序的经验，这是时区的问题。这个问题解决起来并不难，写下我的解决途径以便日后参考。
PHP 脚本端的市区设置可以在 php.ini 下设置 date.timezone 键的值为 'Asia/Shanghai' 即可。但是通常共享虚拟主机本身没有修改 php.ini 权限。这个时候就应该在程序公共部分加入
ini_set('date.timezone','Asia/Shanghai');
动态修改 php.ini 的设置。之后可以测试一下时间是否正确：
var_dump(date());
如果服务器的本地时间是正确的，那么一般就能解决问题了。附，PHP 5.1 以上提供了专门的函数修改对应的时区：
date_default_timezone_set('Asia/Shanghai');
建议使用此函数，因为更通用一些。对应 'Asia/Shanghai' 其他可以使用的大陆时区还有：Asia/Chongqing 、Asia/Shanghai 、Asia/Urumqi （依次为重庆，上海，乌鲁木齐）；港台地区可用：Asia/Macao、Asia/Hong_Kong、Asia/Taipei（依次为澳门，香港，台北）；还有新加坡：Asia/Singapore；其他可用的值是：Etc/GMT-8、Singapore、Hongkong、PRC；老外好像把北京漏调了。
但是，在我修改成功 PHP 端的时区以后发现日期并没有正确的记录下来。这个时候我考虑是否是数据库的问题。果不其然，因为程序插入的函数并没有调用 PHP 的时间，而是直接使用 MySQL 的 CURRECT_TIMESTAMP。这个时候就要考虑是否能修改 MySQL 方面的时区。
参考了 MySQL 的文档，发现一个可行的 SQL 语句为：
SET GLOBAL time_zone = '+8:00';
其中 '+8:00' 是东八区的表示方法，其他的市区依次类推。而我在数据库模型中插入改语句发现权限不够（该死的虚拟主机提供商）。接下来我调试了很多语句，比如：
DATE_ADD(UTC_TIMESTAMP(), INTERVAL 8 HOUR);
显示时区的 SQL 语句：
SHOW VARIABLES LIKE 'system_time_zone'
等等。而由于 MySQL 权限的限制并没有彻底的解决方案。我 Google 了下，发现老外这个有 一个非常好的解决方案 。但是他需要修改每条插入数据的 SQL 语句。这样的方案并不是非常的有效，一旦数据库时区改成正常，那么相应的 SQL 语句又要改回来。
而我考虑既然 PHP 端已经可以正确的解决时间的问题了。MySQL 数据库方面虽然可以使用相应的函数解决，但是如果日后迁移到别的主机环境又要改回来。而相应的字段是一个 TIMESTAMP 类型的，默认的值为 CURRECT_TIMESTAMP，当然是可以指定时间的。
那么我的做法就是让 PHP 插入当前正确的时间，这样虽然程序方面需要做相应的修改。不过日后配置修改起来只要修改一处就可以了。最后插入数据库的时间注意一下格式：
date('Y-m-d H:i:s')
这样就可以解决问题了。附，一些非常好的参考资料：
- http://www.modwest.com/help/kb6-256.html
- http://topic.csdn.net/t/20060503/07/4728521.html
- http://www.phpchina.com/5173/viewspace_5132.html
- http://www.phpx.com/pth110355.php
更新：由此 wiLdGoose 兄说他也碰到同样的问题，但是无法解决。结果经过种种的假设和判断以后，到最后发现原来是 Zend Studio 的时区配置问题（我狂汗ing）。看来除去运行环境，开发环境也是需要注意以下的。
天气也渐渐的转冷，而我开始担心起小白它单薄的身体来（小白是谁？ 在这里 有它的一个出场介绍）。经过强烈的思想斗争，我决定将我用了多年的珍贵的毛巾奉献出来。
当当当下面是武装以后小白的样子，怎么样有气质吧？显示器前的观众请支持我们的公益活动，发送「我请手气吃饭」到本人手机，即可赢取我携小白与你的一次亲密接触（台词似乎有点老了）。
这是其「朦胧」照，我发现无论从写实的角度还是从艺术的角度这都是一张值得收藏的照片。在这里感谢 NOKIA 公司提供数码支持。再「友情」来张猛的，下面提供小白有码激情照片一张，考验各位看官的自我控制能力。
后记，小白最后因水土不符（晚上乱叫、不吃饭胃口不好）已被小蒋同志带走了。天气寒冷，但愿小白不要变成了传说中的××煲。请大家一起祝福一下（小蒋语：CAO，我是这样的人吗？！）。
