前一段时间我写过惊闻《万象》杂志出现财务危机. 很是为这本杂志惋惜．
现在有了好消息–前几天有朋友在我站点上留言, 说《万象》要复刊了. 我还有点半信半疑. 也去报刊亭问了几次，弄得被人笑．今天在天涯上看到有人转载万象杂志社小曾的邮件:
今天刚上班接到通知：《万象》杂志确定6月10日前发行第四月份刊，目前正在排版中。2006年第一季度杂志已确定不会再发行。6/7两月将陆续发行4、5、6、7共四期。
上面这个帖子的跟贴中有人讨论范旭仑老夫子的文章，说句自己的感受，我非常不喜欢《容安馆品藻录》这一系列的文章，都是寻章摘句的内容，还懒婆娘的裹脚，长得很. 《万象》上的文章大多”轻快”, 而范老先生的 “品藻” 干涩绵长, 发霉的干菜味道．
开源 RSS 聚合工具 Gregarius 一直在持续的改进. 最新的 0.5.5 版本相对于以前的老版本有了许多新功能. 升级安装已经变得非常容易. 可以选用安装界面的方式, 管理密码也可以在安装后直接创建．新的主题 UI 已经足够好(参见 OpenRSS.net). 可以配置选择中文界面(简体/繁体)．
现在插件也远比以前丰富多了．插件也有针对与 del.icio.us 等站点的交互的．这次新选用了 Google Adsense 插件．
依然存在的问题：
1) Tag 仍然不支持中文;
2) 中文子目录的 URL 重写还是有 Bug;
3) 不支持多用户;
4) Bug , 大量的 Bug !
相对于 Bloglines 等联机 Blog 阅读工具, Gregarius 的速度仍然是最大的优势．
–End.
想家不是一天两天了，这周一忙完，俺就筹备回家啦！
家在东北，来杭州这一年多，十分怀念东北那稀面的土豆、贼甜的地瓜、油汪汪的豆角、挺拔的大葱……在杭州吃到的东西都太惋约，没有老家吃东西的豪放劲儿。
这周加班完毕，我就要回家啦！
风雨无阻，如果飞机停飞，就坐火车; 没有火车，我就坐船；如果没船，就自行车; 没自行车，我就走回去。 谁也别拦着我–谁不让我回家我削谁！
Cal Henderson 是大名鼎鼎的 Flickr 网站的开发者之一．在一篇名为 Serving JavaScript Fast 的文章中，他介绍了用于 Flickr 站点应用优化的技巧，读罢感觉获益良多．”嚼一下别人的馍”，概括一下该文的主要内容．
Flickr 是 Web 2.0 的代表站点。面对的网络问题除了一般 Web 站点都会有的内容优化之外, 还有必须要灵活处理 JavaScript 与 CSS 的频繁变化后部署分发带来的复杂性。
设定文件大小的策略 首先面临的一个问题是把所有的 JavaScript 与 CSS 放到一个文件中好呢，还是分割成多个文件 ? 从减少网络请求的角度上考虑, 前者更好，后者差。但是从并行的角度考虑, IE 与 Firefox 默认情况下都只能同时从一个域请求两个资源. 这会在很多情况下给用户带来不良的使用体验–必须所有的文件都下载完毕才可以看到像样的页面. Flickr 采用了折衷的办法–在保持文件数量尽可能少的情况下，把 JavaScript 与 CSS 分成多个子文件. 这在开发上带来了复杂性，但是对性能的收益是巨大的。
压缩的优化问题 毫无疑问，对站点内容进行压缩是一个比较常用的 Web 优化手段．但是并不一定都能达到理想的效果．原因在于 mod-gzip 模块不但消耗服务器端 CPU 资源，也消耗客户端 CPU 资源. 而且, mod_gzip 压缩文件后创建的临时文件是放到磁盘上的，这也会给磁盘 IO 带来严重的问题. Flickr 采用的是 Httpd 2.x 以后支持的 mod_deflate 模块．压缩操作都在内存中进行．mod_deflate 在 Httpd 1.x 是不可用的, 不过可以通过创建 RAM 盘的方式来间接提高性能．
当然, mod_gzip 到也不是一无是处, 对于预压缩的文件, 还是有好处的. 而且, 采用压缩的时候,也要注意策略. 图片文件压缩就没什么必要了(Flickr 上图像多, 而且压缩得不到什么好处). Flickr 只对 JavaScript 和 CSS 进行压缩. mod_gzip 新一点的版本能够自动通过配置 mod_gzip_update_static 选项自动处理 预压缩的文件. Cal 也指出这个特性在一些旧版本的浏览器上会出问题.
压缩的另一个主要手段是内容的压缩. 针对 JavaScript 可以进行通过减少注释、合并空格、使用紧凑的语法等小技巧(Google 的所有脚本都非常难读，而且非常紧凑，思想类似).当然，经过这样处理的 JavaScript 可能带了很多括号不容易解析，Flickr 使用了 Dojo Compressor 来构建解析树。Dojo Compressor 开销很低，而且对于最终用户是透明的. JavaScript 的处理方法介绍过，CSS 处理则相对简单.通过简单的正则表达式替换(比如把多个空格替换为一个空格符), 最高可以获得 50% 的压缩比。
Caching 的优化 Flickr 的开发者充分利用了 Http 1.1 规范定义的 Etag 与 Last-Modified 机制 来提高 Caching 的效率. 值得注意的是，Cal 介绍了一个在负载均衡条件下的 e-Tag 小技巧. 即可以设定 Apache 通过文件调整时间与文件大小获得 E-Tag ,而默认情况下, Apache 是通过文件节点获取 e-Tag 的。当然，这也不是很完美，因为会影响 if-modified-since 。
灵活运用 mod_rewrite 据说 Flickr 网站应用是进行每日构建的(Daily Build)。 如果没有一个灵活的机制恐怕这是不可想象的。而且，在 Flickr 这样的站点, 内容的修改同步的处理都是很让人头疼的难题. 他们的利器是 mod_rewrite 的灵活运用。通过配置 URL 重写规则，很容易切换到不同的环境下。听起来很简单, 但是没有一定的 Web 技术功力谈何容易做到 ?!
通过这几个主要方法的运用，我们看到了如梦幻一般高性能的 Flickr .
BTW: 因为在 Flickr 在国内没有服务器, 大陆用户访问的速度就别提了 :(
–End.