Today's the day

Nginx + Passenger 也不错

最开始把 Chito 切换到 Rails3.0 之后，发现新建项目并没有自动生成 dispatch.fcgi 文件，拿 Rails2.x 的文件来用，却不知道怎么的失败了，上网搜了一圈，没搜到什么解决办法，倒是搜到一大堆“fastcgi 的 Rails 部署模式已经过时”云云的评论，郁闷之余心想这也是个尝试新部署方法的好机会。

于是就采用了 Nginx + Passenger 这个时髦的方案。不得不说这个方案的配置方法实在是太轻松了，运行一个 passenger-install-nginx-module 命令，就可以自动帮你下载 nginx，然后自动编译进 Passenger 模块，再自动写好配置文件，只需要改一下自己的 Rails 程序的目录位置，然后就可以跑了～

什么附加的参数也不用写，默认的配置下运行的状况就非常良好。开始总觉得相比以前的 Lighttpd，响应速度有点慢，不过运行了两天下来，发现也没有那么严重。除此之外，都是优点。

首先最意外的就是内存占用了：

对比很强烈，凌晨 1 点做了切换。左边是 Lighttpd + fastcgi + ruby1.8.7 + Rails2.3.8，右边的就是 Nginx + Passenger + ruby1.9.2 + Rails3.0，打开了同样的进程数，但是后者的内存占用（绿色 apps 部分）降低了一半多。不过我估计大部分的原因是 ruby1.9.2 和 ruby 1.8.7 的差别造成的，具体的原因是什么也懒得研究了，总之感觉很爽。

使用 Passenger 的另一个好处就是有两个命令：passenger-status 和 passenger-memory-stats，可以用来查看当前 Passenger 服务的运行状况和内存占用状况，配合 Munin，可以像上面监控系统资源那样，监控 Passenger 服务的运行状况：

相比 fastcgi 要方便一些。关于 Munin 的 Passenger 监控配置，可以参考这里。

从这次切换的结果来看，ruby1.9 很稳定，尤其是前两天的 1.9.2 已经非常好用了，在新 mysql2 的配合下，所谓的字符编码问题也基本没有碰到。

Rails 3.0 似乎也没什么大问题，刚上线的时候确实出现了一些诡异的问题，不过后来都发现是第三方的 Rails 插件造成的。虽然 3.0 相对 2.x 很多的 API 写法都要改变，但是改过来后基本不会出现什么问题，对于 3.0 诸多的新特性（目前最爱的就是 ARel Query API 了）来说，这种改动非常值得，新项目也可以直接就用 3.0 了。

话说经常有人问哪里可以下载到 Chito 的源代码，目前在 Github 上：

http://github.com/galeki/chito

现在的 master 分支就是最新的 Rails3 版本，如果想使用 Rails2.x 的版本，可以用 v1.1.7-for-rails-2.x 这个 Tag。

chitolog.org 一直没管结果域名挂了，过阵子再把它恢复吧…… -_-;

Chito 构架更新

自调整作息时间以来已经过去了一个月的时间了，才发现这段时间一直没有写过 blog，不知道是不是这种正常人的作息让我有时光飞逝的感觉。

这一个月中，除了按部就班的玩模拟期货、做听力之外，还有就是开始逐渐把 Chito 迁移到 Rails3 上，原本这只是个额外的计划，因为 Rails3 的正式版还没有发布，所以慢慢修正即可，但是这两天逐渐的变成了主要工作，不仅更新了 Rails 和 Ruby，把编辑器也换了。一写起代码就一发不可收拾啊……

以下记录一下更新过程中遇到的问题：

Ruby1.9

虽说 Rails3 在 Ruby1.8.7 上也可以工作，但是既然这次有空更新就把 Ruby 也顺便一起升级了吧～通过 rvm 可以很方便的安装多个 Ruby 版本以及在它们中间自由切换，大大方便了测试～

incompatible character encodings: UTF-8 and ASCII-8BIT

恐怕升级到 Ruby 1.9 之后遇到最多的问题就是这个编码问题了。Ruby 1.9 中增加了字符编码的支持，但是这个编码支持的方式有些奇特，不像 Python 那样内部统一为 UTF-8，而是给每个字符对象一个 encoding 属性，通过这个属性来处理字符的显示与转换问题。

虽然这样很灵活，但是如果两个 encoding 属性不同的字符串对象进行相加或者拼接，就会 raise 一个 incompatible character encodings 的异常。而目前有些 Ruby 的库（比如 mysql adapter）还不能正确设置这个 encoding 属性，所以就会出现这种问题了。

目前解决的办法就是用 force_encoding('UTF-8') 强制转换，或者看看库有没有更新（比如可以把 mysql 换成 mysql2），网上的资料也不少，可以参考这里和这里。

除此之外，似乎无论字符串对象当前的 encoding 是什么，序列化后再取出后的 encoding 就变成了 ‘ASCII-8BIT’，所以取出之后还要强制转换一下。

感觉虽然 Ruby1.9 支持了多字符编码，但是却把所有的编码细节都扔给程序员来处理，相比 1.8 似乎更折腾了……

ImageMagick Segment Fault

在 Ruby1.9 下，可以正常编译 ImageMagick，也可以正常安装 RMagick 这个 gem，但是在使用 RMagick 库生成图片的时候却出现 Segment Fault，原因是 ImageMagick 的 OpenMP 和 MacOS 冲突，去掉 ImageMagick 的 OpenMP 支持重新编译一下就可以了，详细过程可以参照这里。

Rails3.0

相比之下，Rails3 的迁移工作就简单的多，只要按照 Rails3 的新特性介绍，把旧的写法改一下就可以了，网上的资料一搜一大堆，railscast 上也有不错的视频教程～

额外的插件目录

众所周知 Rails 默认的插件目录是 vendor/plugins，在 Rails2.x 中，如果把插件放到 vendor/plugins 下的子目录中，插件也可以正常加载，这样就可以方便的整理插件（比如把 Chito 的插件放到 vendor/plugins/chito_plugins 目录下），但是到了 Rails3 这样不行了。

看了下文档，有 plugins_path 这个 config 参数，但是设置之后无效，看了下 Rails 的源代码，发现插件目录在 paths.vendor.plugins 中设置，所以在设置中加入：

config.paths.vendor.plugins("vendor/plugins", "vendor/plugins/chito_plugins")

就可以载入特定目录下的插件了～

Rails.root "+"

Rails3 中 RAILS_ROOT RAILS_ENV 这些常量已经消失，转变为比较美观的 Rails.root 和 Rails.env 这样的形式。

不过 Rails.root 不再是个字符串，而是个 Pathname 的对象，大部分情况下和字符串没有区别，比如可以像原来那样拼接：

"#{Rails.root}/public/images"

但是用相加（＋）这个方法的话会出现一些问题：

> Rails.root + "public"
=> #<Pathname:/Users/galeki/works/chito/public>

> Rails.root + "/public"
=> #<Pathname:/public>

就是说如果和一个绝对路径的字符串相加的话，结果直接就变成绝对路径了，所以还是用 #{ } 来组合目录吧，用 File.join 也是不错的选择。

CKEditor

这次主要的时间都花在更新这个编辑器上了。相比 FCKeditor，CKEditor 要快速和好用得多。

其实 CKEditor 早就有了，我也早就想把 FCKeditor 换掉了，但是一直因为种种理由没有换。因为不仅仅是把新编辑器的 javascript 文件加到网页里就行了，还要重写 3 个插件（，高亮代码，TeX 公式）以及文件上传和管理系统，一直都觉得这是个大工程，迟迟都没有动手。

后来终于决定动手，却发现官方的开发文档中还没有 Plugins 的部分，于是暂时放弃了。

后来看了一下内置插件的代码，也不是很复杂，而且  插件可以直接借用 CKEditor for wordpresss 中的，所以插件的问题解决了。但是发现还没有比较好的 CKEditor for Rails 插件，如果要自己写的话，实在是太折腾，于是又暂时放弃了。

前两天忽然想到，Chito 已经有了一个文件管理界面，为毛不把这个文件管理器集成到编辑器里呢？

实践了一下，没想到如此的简单！直接在编辑器中显示文件管理器的局部模板就行了，然后在模板里面只需要判断如果是编辑器请求的就加入一些和编辑器交互的 js 内容，然后就完成了！效果比原来的好多了：