重新审视 Vim
虽然号称使用 Vim 多年，但是实际上一直没有仔细研究过，平常用的也就是 Vim 的基本快捷键而已，虽然经常写 Rails 代码，但是除了自己定义了一个在 erb 文件中输入 <%= %> 代码的快捷键之外，就没有任何其他配置了，插件也只是偶尔用用 NERDCommenter 之类。
最丢人的是，目前还不习惯用 hjkl 移动，因为平常也经常用其他的普通编辑器，所以即使在 Vim 下，每次也都是用着用着就去摸箭头键了，至今没有调整过来。
不过前天看到一篇非常好的 Vim 文章：
Coming Home to Vim / Steve Losh
受其影响，开始重新审视 Vim。
文章中提到的一些 Tips 比较有启发性，比如对于不知不觉去摸箭头键而不使用 hjkl 的问题，可以用下面的配置代码，将箭头键屏蔽：
nnoremap <up> <nop> nnoremap <down> <nop> nnoremap <left> <nop> nnoremap <right> <nop> inoremap <up> <nop> inoremap <down> <nop> inoremap <left> <nop> inoremap <right> <nop>
这样每次就会被强迫去用 hjkl 了，对于 Vim 初学者来说尤其实用。
此外，对于回到命令模式用的 Esc 太远的问题，除了通过某种方法把无用的 CapsLock 键映射为 Esc 之外，还可以使用“jj”：
inoremap jj <ESC>
因为单词中很少有输入 jj 的情况，所以并不会干扰输入。映射为“,,”也可以，当然也可以使用脚踏板 :)。
此外还知道了一个可以像 TextMate 那样智能打开文件的插件 PeepOpen：
虽然要收费，但是效果比 Command-T 之类的要好多了，所以等有了资金就去买一个用。有了这个东西，NERDTree 之类的就不需要了~ :)
最后，就是再定义一些快捷键了，Vim 的快捷键定义语法 nnoremap 和 inoremap 非常直观，一直都想不出应该定义什么真是不应该啊。
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 个插件（<!--more-->，高亮代码，TeX 公式）以及文件上传和管理系统，一直都觉得这是个大工程，迟迟都没有动手。
后来终于决定动手，却发现官方的开发文档中还没有 Plugins 的部分，于是暂时放弃了。
后来看了一下内置插件的代码，也不是很复杂，而且 <!--more--> 插件可以直接借用 CKEditor for wordpresss 中的，所以插件的问题解决了。但是发现还没有比较好的 CKEditor for Rails 插件，如果要自己写的话，实在是太折腾，于是又暂时放弃了。
前两天忽然想到，Chito 已经有了一个文件管理界面，为毛不把这个文件管理器集成到编辑器里呢？
实践了一下，没想到如此的简单！直接在编辑器中显示文件管理器的局部模板就行了，然后在模板里面只需要判断如果是编辑器请求的就加入一些和编辑器交互的 js 内容，然后就完成了！效果比原来的好多了： 
原来竟然没有想到这么简单的方式……冏
接下来的工作
目前 Chito 更新的大部分工作已经搞定了，除了几个插件的诡异 bug 还没有解决，解决之后就可以等待 Rails3 正式 Release，然后就可以正式上线了～
话说最近起床的时间越来越晚，又有恢复至颠倒黑白作息时间的趋势，还是夜里写代码比较爽啊～ :D
完美的作息时间
保持颠倒黑白的作息时间，已经有两年多了，从大学一毕业就开始到现在基本没有中断过。
不过最近由于想玩玩模拟的股指期货的缘故，决定把作息时间调整回正常。
说到调整作息时间，这里还有两种调整方式：
- 向前调整：其实就是早睡。
- 向后调整：其实就是晚睡。
开始想尝试方式 1，但是很无奈的失败了，因为早早躺在床上实在是睡不着，而且有时反而会越假寐越兴奋，结果最后比平时睡得还要晚。
最终还是采用了方式 2，因为调整之前的睡眠时间已经是中午 12 点了，这样只要每次稍微晚睡几个小时，就可以慢慢调整到晚上去。最终，昨日晚上 11 点困倒，今天早上 6 点准时醒来，历时一个星期，终于把作息时间调整回正常了。
不过虽然现在白天可以如愿的玩模拟期货，但是却感觉诸多不爽，尤其是最近白天比较热，而且没机会看凌晨的球了，不过其中最不爽的是效率比原来差了很多，估计当初也是因为这些原因，才执行颠倒黑白的作息时间的吧。
现在的正常作息时间（6:00 起床 23:00 睡觉），自我感受到的效率感如下：
估计普通人也有类似的感受吧。首先早上 6 点起床，可以迅速的进入到工作状态，但是到了中午就有点疲乏，下午还可以稍微振作一下，不过一旦吃完晚饭，就啥也不想干了，临近晚上 11 点的时候，就已经困得不行了。
然而，在颠倒黑白的作息时间（中午 12:00 起床 早上 5 点睡觉），自我感受到的效率如下：
虽然起床之后要花不少时间才能进入工作状态，不过这种良好的状态可以一直持续下去，到了凌晨，还会有一段非常兴奋的时期，而且即便临近应该睡眠的时间，自我感觉也不像上面那样困得不行，只是没有那么刚才兴奋而已。
原因不明，也许因为凌晨安静的环境对工作环境有很大的帮助，睡觉的时候又是正好天亮，这样也许本能的会清醒一些。不过确实有研究说这种作息时间有些优势，这个研究的真实性虽然不清楚，但是至少比那些号称几点几点是某某器官排毒的理论要可信多了。
不过，一直觉得最完美的作息时间，应该是下午 5 点左右睡觉，然后晚上 12 点起来，为什么呢？ 因为这样的话，白天不会耽误任何事情，和正常人没什么差别，还可以享受凌晨的宁静和高效，最关键的是，把一天中网速最卡的时间段给睡了过去（咩哈哈~）。
现在由于晚上得和家人吃晚饭什么的，所以无法实行这种作息，不过以后要是有机会可以试试看。而且，如果那时候不是宅男，而是得每天朝九晚五的上班的话，应该也没什么问题，反而可以让我每天早上不用挣扎着起床。
反正不知道是因为现在年轻还是一些特殊的原因，总之现在不管什么样的作息时间都可以轻松适应，而且在很长的时间（至少是两年）内，都没看到啥不良的影响，反而更加精神和高效了。要说害处可能只有皮肤比一般人要白一点吧汗，不过这只是宅男病而已。
所以估计早晚有一天我会再把作息时间再调整回去，现在这种状态确实不能让人满意啊。
话说我现在就有点困了……-_-
准备实用化一下可怜的听力
外语是工具，可是对于我来说，这个工具在现在只是个半成品。
平常用到的地方，局限在看资料和翻译资料上面，也就是说局限在阅读上面，除此之外的听说方面，几乎为零。
虽然可以凑合听懂 Rails casts 之类的东西，但是这些东西的内容全是熟悉的术语而已，稍微牵扯点日常类词汇，比如讲座、新闻、教程、电影，我就基本废了，听这些内容的时候，几乎就相当于看 A 片的时候只听出来雅蠛蝶的程度。
之前对这种状态毫不在意，因为反正平常也用不到。
不过现在发现，很多资源不再局限于文字上面了，视频和音频的资源越来越多。
等字幕组的翻译吗？也只有美剧和动画之类可以如此，大多数资源永远都不会有字幕。
所以，在这个 2010 年下半年的第一天，正式将听力列入下半年的计划中来，期望在年底的时候，听力水平可以变成可以实用化的工具之一。
不过目前还没有决定方法，踌躇ing……
