最近开始玩Sublime Text,目前还在Evaluate阶段,逐步尝试用它替换掉原来Vim。期间实时语法检查用到了Sublime Linter这个插件,感觉还是蛮不错的。但是用于用了RVM管理Ruby版本,因此不能让Sublime Linter使用系统级的Ruby了。对此其实Sublime Linter是做了准备的,在它的README中就有这样一句:

If you are using rvm or rbenv, you will probably have to specify the full path to the ruby you are using in the "sublimelinter_executable_map" setting. See "Configuring" below for more info.

一般是要求修改sublimelinter_executable_map使之为$HOME/.rvm/bin/rvm-auto-ruby,这么做得话,显然就可以用RVM默认的Ruby版本了。但是这样对我而言还是不够的,由于工作的原因,我不同的项目都使用不同的ruby版本,而默认则是Ruby 1.8.7,当我在编写Ruby 1.9.3的代码时,老是按照Ruby 1.8.7来做语法检查,显然会出现大把大把的错误。(这个不是SublimeLinter的工作不到位,要知道以前用Vim的时候根本没得选。。)

对我这种Case而言,最好的方法是根据文件所在项目目录里的.rvmrc文件来判断这个文件该使用哪个Ruby版本。为此我写了一个shell脚本(起名叫rvm_use):

#!/usr/bin/env bash

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
for i in "${@:2}"; do
    if [[ ! "$i" =~ ^- ]]; then
        cd `dirname $i`
        break
    fi
done
$@

这个脚本接受一行完整的Shell命令,比如"ruby -wc ...",然后从第二个参数开始(第一个参数往往是ruby或是rspec这样的可执行文件),如果检测到第一个首字母不是 '-' 的参数,认为这个参数就是项目文件所在位置,用cd命令进入到这个文件所在的目录(rvm已经hack了cd命令,只要进入的目录有.rvmrc就会切换到它指定的Ruby版本),然后执行用户送入的命令。

刚才这个脚本已经适用于Sublime Build之类同样涉及到Ruby的功能,但是要给SublimeLinter用的话,还要额外加一个脚本,这是因为SublimeLinter认为解释器命令一定只有一个参数,如果我把解释器设为 'rvm_use ruby' 的话将会出错。因此额外增加一个rvm_use_ruby脚本:

#!/usr/bin/env bash

`dirname $0`/rvm_use ruby $@

让Sublime Linter使用这个脚本就行了。

本来以为这么做就足够了,但是后来发现依然不够。调试发现Sublime Linter依然没有使用到正确的Ruby版本,阅读插件的Python源码发现(感谢不久前的Python Training,多少掌握了一些Python),Sublime Linter为了尽可能实现实时检测,提供了三种检查策略,通过文件检查,通过临时文件检查,通过STDIN检查。对于C语言这样比较死板的语言来说,文件必须先被保存,然后让检查工具去检查这个被保存的文件的语法才能得到正确的结果。Java则稍微高级一点,无需等到保存,而是在检查前将当前还未保存的文件偷偷写入到一个临时文件,然后检查那个临时文件的语法。至于Ruby由于是脚本语言,支持直接用STDIN将代码输入进去,这样同样无需保存文件即可实现实时检查。但是这个做法显然就无法应用我之前的办法了。因为rvm_use命令参数中将没有一个文件名,也就无从知晓应该用的Ruby版本了。

对于这种情况,一种可行的办法是修改SublimeLinter/sublimelinter/modules/ruby.py,修改它的CONFIG中的"input_method"参数(抱歉,没找到针对User目录的修改方法,只能改源文件了),但是这并不是一种理想的办法。因为这样就彻底失去了实时检查的功能,我并不想做这样的妥协。因此既然要改SublimeLinter/sublimelinter/modules/ruby.py文件,何不改的再彻底点,针对Ruby彻底重写executable_check方法?修改后的文件是这样的:(再次感谢Python Training)

# -*- coding: utf-8 -*-
# ruby.py - sublimelint package for checking ruby files

import re
import os
import subprocess

from base_linter import BaseLinter

CONFIG = {
    'language': 'Ruby',
    'executable': 'ruby',
    'lint_args': '-wc'
}


class Linter(BaseLinter):
    def parse_errors(self, view, errors, lines, errorUnderlines, violationUnderlines, warningUnderlines, errorMessages, violationMessages, warningMessages):
        for line in errors.splitlines():
            match = re.match(r'^.+:(?P<line>\d+):\s+(?P<error>.+)', line)

            if match:
                error, line = match.group('error'), match.group('line')
                self.add_message(int(line), lines, error, errorMessages)

    def executable_check(self, view, code, filename):
        args = [self.executable]
        args.extend(self._get_lint_args(view, code, filename))
        dirname = os.path.dirname(filename)

        process = subprocess.Popen(['bash', '-c',
                               'source $HOME/.rvm/scripts/rvm && \
                                cd ' + dirname + ' && '\
                                + '  '.join(args)],
                               stdin=subprocess.PIPE,
                               stdout=subprocess.PIPE,
                               stderr=subprocess.STDOUT,
                               startupinfo=self.get_startupinfo())
        process.stdin.write(code)
        result = process.communicate()[0]

        return result.strip()

这里用bash -c启动一个独立环境,在这个环境里执行source命令后用被rvm hack过的cd命令进入项目文件所在文件夹,然后再执行检查命令。这样就可以完美解决问题了。

注意Sublime的配置文件一定要被git托管,否则一旦源码因为升级而还原的话所有修改就都丢失了。

由于我所维护的Rails项目规模很大,所以被分割成了多个项目,而其中仅Rails项目就有不下6个,而我在开发我所属的子项目的时候,通常至少同时运行4个项目才能把流程完整的运行起来。而这四个项目中就有三个在生产环境上会监听默认端口(80/443),因此,这些项目的开发者都希望当其他项目与自己的项目产生交互的时候,会采用默认的端口。也许他们在自己开发的时候就是这么做的并且没有发生什么问题,但是作为另一个项目的开发者,遇到这种情况就非常麻烦了。虽然我们有时都会留下一个配置文件供开发者配置,但是由于这个配置文件本身也被Git托管(这个做法其实很不正规),所以我一旦修改配置文件,这个文件就至始至终保持被修改的状态,非常麻烦,经常干扰到我原本华丽而流畅的Git操作(瀑布汗。。)。

所以就希望能寻找到一种办法,能够使服务器不再根据端口,而是根据域名判断请求应该送达的服务器。这个功能其实Apache,Nginx等网页服务器都具备,但是开发环境下的Rails服务器不比真正的网页服务器,没有这种功能。

当然,不能直接简单地用个网页服务器了事,因为传统网页服务器不能实现对Ruby代码的Debug(何况最近还特别迷恋pry神器),而这是我需要的基本功能。除此以外,我还需要它的路由层次必须高于/etc/hosts文件,因为我们还要时常切换到QA环境或是生产环境,而我们切换的方法就是修改/etc/hosts。所以在防火墙甚至于更底层实现都是我不能接受的。

于是我在Twitter和Ruby China发起了提问(http://ruby-china.org/topics/6102),收到了不少响应,比如RVM+Pow的手法,确实不曾听说过,感觉不错的样子。还有Passenger + Apache的办法,来自于Railscasts介绍的办法:http://railscasts.com/episodes/122-passenger-in-development。不过,我更希望的是一种更加简单的办法,不需要复杂的GUI控制,完全透明,而且最好是平台无关的,毕竟我比起Mac OS X还是更希望用Linux开发,因此不希望采用Mac Only的办法。

在反复思虑后,选择了@RainFlying提出的用Apache/Nginx做反向代理的办法,将发送到Apache/Nginx的请求通过代理转发到真正的Rails服务器上,以此实现了让多个Rails App时同时监听80端口的假象。

于是,我就在目前正在使用的Ubuntu 12.04上安装了nginx-light包,这个包比起nginx-full来说仅仅包含了最核心的nginx,不带过多的Modules,保持环境的轻量。然后在/etc/nginx/sites-available里创建了一个新文件,内容如下:

server {
        server_name test1.com;
        location / {
                proxy_pass http://localhost:3000/;
        }
}

server {
        server_name test2.com;
        location / {
                proxy_pass http://localhost:3001/;
        }
}

由于每个站点的配置仅有简单的几行,因此我把所有配置都包含在一个文件里,看上去简洁明了。

然后修改/etc/hosts文件,将域名指向本地服务器。这个步骤也暗示了我随时随地可以通过修改/etc/hosts切换环境,而不需要任何其他操作,完全和以前一样。

最后运行

sudo service nginx restart

重启Nginx。虽然网上有说用

sudo service nginx reload

也可以,但是我在尝试后发现似乎并没能成功更新配置信息,因此还是使用restart命令。

到这里,其实反向代理因此可以工作了,但是由于Nginx服务器毕竟不比为开发设计的Rails服务器,所有的连接都有超时时间。如果在连接时进入了Debug模式,我希望连接能够一直保持等待直到Debug结束,在查阅了Nginx的文档后,发现可以用proxy_read_timeout选项设置Nginx等待被代理服务器的响应时间,默认为60秒,我将这个时间设置到了36000秒,即10个小时,差不多足够了吧。

明天就把这个方法在团队中推广下,大家以后不用再抢端口了吧。