凯谈Ruby on Rails项目实践
3.为什么要选择用Ruby on Rails来做JavaEye呢？
但是在这个过程当中，我其实最早考虑是用Java开发，因为PHP的话，我之前，在00年、01年的时候，也做过大概有将近两年的开发，那PHP的话，就是当整个网站规模很大，也就你的那个网站代码量很大的时候，那管理起来相当困难。而且PHPBB的话，就是PHP的话，它本身它的这个面向对象的机制、运行效率也不是特别高，那么所以后来我，后来的时候，我一直考虑用Java去做，像我学习Java的话也是从2000年，差不多从2000年开始做得，一直到06年，也做了很多年。那么我在06年就开发，06年准备在开发JavaEye新的版本网站的时候，考虑到如果用Java开发的话，它的整个开发成本会很高，当初我预计的话，如果用Java运作的话，可能大概要，乐观的估计的话，可能要三个月到五个月才能开发完，所以当时感觉到开发量很大。这也是之所以迟迟没有开发的原因。
那么大概在06年的三四月份，那个时候Ruby on Rails在国内已经起来了，在起来以后那个时候我已经在开始在用Ruby on Rails了，那么看了一段时间以后，我自己的评估呢，它是能够比Java的开发效率高很多，当时的一个传言说就是快十倍了，然后当时那我想就用Ruby on Rails做好了，那后来我们实际上只用了一个多月就开发出来了，确实应该说效率不错。
9.那在那个开发JavaEye网站的过程中，就是使用Ruby语言会碰到一些什么问题吗？那如果有的话，你是怎么去克服的呢？
那我随便举个例子，比如说，你要想把一个方法注入到你当前的类里面，你就有很多办法，你可以用Module，或者你可以用Class，你可动态地加载进来。Ruby有很多很多种方法，那么你这不同的人，你在处理同一个问题的时候，你写这段代码，你采用什么方式，那么每一个人它都会采用自己的方式，从代码风格上比较难统一。那带来一个问题就是，你写的代码，其实我大概也能看得懂，但是呢你为什么要这么做，我可能我也不是特别理解，我不太会理解你为什么要，这个代码你为什么要那么去写，它可能就是需要经常的面对面的沟通，我才能够明白，我想这是第一个问题，就是本身由Ruby语言带来的这样一个，在团队协作上，带来比较大的一个问题。
那我们面临第二个问题，我想主要还是跟我刚才说的还有关联，我们主要的开发平台还是在Windows上开发的，毕竟你要在Windows下，在IE浏览器上还要测试，还包括考虑到就是我们通过我们后台监测系统呀，通过Google Analytics监测的话，我们整个网站的访问者98%是使用Windows的，那么，那这种情况下的话，比如说你调用CSS了，你使用什么样的字体，对吧？所以这些考虑就必须使的在Windows下开发的，才能够保证你开发出来的网站浏览者看的时候应该基本是一致的。那么你在Windows下做开发，然后你在，我们是在SUSE Linux上去做部署，那么在这里，其实中间会有一些差异，包括有一些依赖于本地化库的，一些第三方的类库，比如说Magic，它就是可能会在Windows下，在Linux下，它有不同的表现，还包括也就是说你的文件存储路径啦，诸如此类的，整个操作系统之间的差异，会给你带来一些困扰。那我想这是两个问题，这个问题只要你有足够的经验还是能够克服的。
要说第三个问题，我觉得就是Ruby，它其实有很多第三方的插件，但是插件呢质量参差不齐，而且没有一个特别统一的管理。那我们说Ruby它其实有一个网站叫Rubyforge，它可以把一些第三方的类库都放在上面。你要搜索什么也好，安装什么也好，其实你都可以到统一的到这样一个代码集散地，你去获取，但是像Rails第三方插件，它不是这样的，目前没有一个。怎么说呢，没有一个这种就是专门有一个网站来搜集和索引所有第三方插件，插件就是散落在各个的作者自己的博客的地方或者，反正就散落在各个角落里面，所以你要去找插件的话，那你要搜的话，其实你也要自己去慢慢搜，而且搜出来的话，它没有一个官方的评价，你也不知道它好还是不好，然后自己去用。
用的话呢，从我们现在来看，大部分插件拿过来用，我们或多或少都会有一些自己修改，总会有一些Bug的，那么这个Bug的问题，其实更多的也跟就是我们中文的这种Rails的开源的Contributor不够有关，所以很多一些西欧的或者是美国的Contributor它本身，它背景呢就是那种Contributor背景国家嘛，所以它做开发的时候未必会考虑到我这种中文的这种多字节处理应该是个什么样子的。像这种情况中文的在Ruby社区，Rails社区Contributor不够吗，所以我们经常会碰到这样一种问题，但是你也没办法得自己来改。
12.刚才谈到Ruby语言的灵活性，然后其中有一个非常热门的话题，就是Ruby对DSL的支持，那请谈一谈就是你对这方面的一个看法。
但是呢我觉得这些所有的用来描述这种专用的，用来描述特定领域的，这样的所谓的DSL领域呢，我感觉基本上分成两类，一类就是现在Java和主流企业运用，它比较倾向的一种方式，就是我用XML语言来描述，那包括像现在的在SOA里面描述一个业务，其实都这样用的，但是呢，就是这种描述语言呢，它基于一个基础，就是说不是程序运用这种描述语言，这是用某种工具可视化的工作。但另外一种流派呢，就是另外一种方向，就是用脚本语言运用非常灵活的，描述能力很强，非常切近与这种英文的，怎么说呢，英文的这种自然语法的，就是脚本语言去描述。像这个呢，其实就是Ruby。
应该说这两种方向在Ruby做描述DSL这个领域相当的，我觉得是相当有前途的，包括Rails，其实就是Ruby DSL的它的一个应用，还比如说，这个构建工具Rake，就相当于一个Java里ANT这样的一个工具，它也是这样的，这个包括Rails包括Rake，还包括就是我看过的在日本它有一些游戏，它用的一种脚本叫RGSS，就是描述我这个在游戏里地图怎么绘制，然后东西怎么移动，规则是什么样的。就是所有的这些东西，它都是类似于一种英文的语法的方式去描述的，就是我应该做什么什么，还包括现在，我们现在那个在这个JavaEye 3.0开发里边，用的一种描述需求的方式，用RSPEC，这个RSPEC呢就是说什么呢？所谓SPEC呢，就是需求、需求规则嘛，就是你用Ruby语言来描述，我要实现一个什么样的功能，它应该具备什么什么，像这些东西，其实本身就是可以运行的Ruby代码，所以我觉得用Ruby做DSL，应该说是方兴未艾吧。
那我认为也只可能出现两种情况，一种情况就是，程序员就觉得我的项目纯粹就用Ruby写，只是把它放在Java平台上跑，那这是一种可能性，但这种可能性，它其实不是一种深层次的应用，只不过就是只说我运行平台从操作系统层面更直接，或者说CRuby转到这个JRuby而已。那更多的一种融合，它其实体现在不同的语言上，它各取所需，就是采用自己更适合的方式，我们说，打个比方吧，就是在Java平台上，以后也许啊，做一个企业应用项目还是以Java为主，就是你主要还是用Java去做的，还是用Java的组件，但是某一些，其中的某一些部分，也可能比较适合用Ruby去做，像这种情况呢，我觉得最可能出现。
比如说，我们做一个电子政务里边一个系统，或者说做一个银行的KS系统，那比如说我们做电子政务，它涉及到工作流了，涉及到工作流的话，我们现在在Java里面，我们都是用XML来描述这个工作流，这个文件很难维护的，没有特殊的工具来维护，但也许以后我们会有一种比较好的Ruby库，很方便的，我甚至可以让我们的业务人员一条一条的把他的工作流给它写下来，而Ruby的规则呀，它本身就有可运行的，工作流并不明显，这个就很有意义。它比如像一些医院的排班系统，它有很多很复杂的规则在里面，就是规则引擎，规则引擎的话像现在，你要是说如果纯粹用Java去写，那不可能了，那太复杂了，所以现在那个JBoss有个Drools的，也是一个叫JBoss Rules，它也是一个规则引擎，不过它的语法也是自己的定义的，它其实也是相当于一个很小的桌面应用，那我们以后也可以想象一下，我们如果用Ruby DSL，我们写规则也许是跟需求人员一起写，一条一条写，本身这个就是可以运行的，所以在对企业应用这个角度来说，我到是觉得Ruby DSL会是特别有前途的一个方法。
18.我想问这样一个问题，就是你对Ruby语言在今后市场前景方面是怎么样一个态度？另外对于Ruby语言本身，它还要再进行那方面的一些改进呢？
然后呢，第二个方面在企业应用。，因为Ruby它这种编码的风格是在这种大规模团队开发上还是遇到一些问题，就是你怎么样未来用一些更好的软件方法来指导它，这个目前好像没有这种更适合Ruby的软件方法学出来。所以我想在企业应用开发这一块，目前来说不会成为一个主流，至少五年之内，我想不会成为主流吧。但是呢，就是Ruby的DSL，就是成为企业应用的里面的一些粘合剂，这个我到非常非常看好，我想这个就是基本上，从市场前景上来分析。
然后另外呢，我觉得从国内的情况来说的话，有一个趋势特别值得注意，这个也是我们Java网站本身也是做招聘，就是帮企业来寻找人才，有一个趋势特别值得关注，是什么样的趋势呢？就是有越来越多的欧美的外包，它们要求国内用Ruby on Rails开发，它在国内寻找就是Ruby on Rails这方面的公司和团队。那么你要说Ruby语言本身，它自己自身需要哪些方面的改进呢，我觉得这个问题相对来说还比较……，我也不是特别在行啊，我只能说就基于我自己很浅显的一些看法。Ruby其实现在目前来说呢，还是有一些在语法上，稍微有一些小的缺陷，比如说在Ruby的那个Block的内部变量，其实相当于，如果跟那个Block外部的那个全局变量重名的话，它其实是没有办法隔离的。所以这个现在就，我们写Ruby程序它就是，就有这样一个准备，Block变量的名字，你不要跟外面的变量重名，所以像这个这方面是有一些语法上一些小的缺陷，那诸如此类，还有很多很多这种小的语法缺陷，那么我想这些语法缺陷还有待于以后的弥补。那这个的话，像我知道的啊，在Ruby下一个版本当中，这个Ruby的作者Matz它在里面也添加了很多很多新的尝试，让Ruby的语言更加动态，更加灵活。