rails虽好，但依然难用

    大约从06年9月正式接触rails。买ror书，按书上画瓢。开始进行实验项目开发，再到正式项目开发，已经过去了大半年了。这个大半年的应用中，最大的感触还是，rails虽然很不错，但是依然有很多地方让你痛苦不堪。

   不过这个也是大部分技术开始应用的时候经常遇到的，有些小细节上处理不好，整个项目就会被卡死。

   我所遇到的rails的最大难题，第一是。中文处理，第二：数据库，第三：部署。 这些问题在前期开发中和试验项目中实在是难以遇到，但是正式项目中却能让项目失败的几个点。对于准备热心应用rails项目的各位同学，千万要当心这点。

   做rails项目，要么就是严格按照rails最擅长的方式去处理，linux/unix运行环境，mysql数据库。在这种情况下，部署，和数据库部分问题就会很少，最多的也就是中文处理问题。中文处理的解决方法很多，基本不成为问题。

   不过由于工作环境的问题，rails的应用环境和推荐完全不同。
   中文处理问题，尝试完全用gb2312编码，问题超级多，费尽心思，虽然找到一个办法，不过并不好用。最终还是不得不采用了utf8。

   数据库：rails有说明能够支持ms sql server。 能够支持和实际应用，距离相差又是甚远。虽然都是采用utf8编码，但是非常容易出问题。
   部署： 用的是windows 2003，robbin的文章帮助很大，问题依然存在。 某些情况下，发送post指令，页面调用就会出错，这种错误开发环境下根本就从来不出现。

   上面的三个问题，从开始到最终解决，最长的有几个月那么久。（解决办法，我都在这里发帖）。而这三个问题，从开始看各位同学对rails，ruby的推崇的文字，到实验性代码中以及ror的书上，是从未提起过。三个问题，随便哪个问题解决不了，项目就完全流产了。使用新技术的整个过程中，风险依然很大。回头想想，还真是汗颜。

   论坛上有不少的同学经常想在公司里面推广新技术，新方法。我这里奉劝一句， 除非你已经用这个新技术，新方法做过好几个项目，方方面面问题都遇到过了，否则不要去推广。很多细节，只有做过，遇到过，才能够明白，理解和解决的。一些看上去不注意的细节角落，往往就是一个项目杀手隐藏在那里。当心啊当心。
   
 

 

评论

29 楼 koalant 2007-06-22  

PHP 的类 ror 框架很多，比较有名的是 CakePHP，但是比较成熟的是 Symfony (yahoo 部分采用过)。
我用Symfony 做过两个小模块，感觉还不错。它内置的国际化功能（支持UI模板和数据库的国际化）和部署（同步发布）都很强，只是有传闻性能很差。php 的框架大多很 apache 服务器邦定的很死，因为它们都要通过 mod rewrite 来实现 pretty url, 但是却造成了性能上的损失。另外，symfony 中也大量采用 helper 方法（跟 ror 学的）；默认设置优先配置（采用 yml)，只是配置文件繁多，目录深达 ６ 级；symfony 区分 project,applicaton, module 三个概念。

反正真的打算学，也够你学的。

28 楼 indexchen 2007-06-21  

有java成熟技术不用，却要去赶时髦用ror，自找苦吃。 做项目的目的得到高效、稳定的系统，不是一味追求新技术，新技术的不成熟会让你很郁闷

27 楼 hideto 2007-06-21  

CakePHP,你们这些火星人

26 楼 indexchen 2007-06-21  

有成熟的java不用，要去敢时髦用什么ror，自找苦吃。做项目的目的是得到高效、稳定的系统，不是看用了什么流行的技术

25 楼 simohayha 2007-06-21  

gigix 写道

fnet 写道

呵呵，不如找一个框架写php，快的不能再快。环境也好弄。

不过我正努力学java中

PHP有一个类似于RoR的框架，好像叫Symphony什么的，记不清了。PHP还有Pake（PHP Make），单元测试框架也有。只要有这个套路，到哪儿都行得通。我们以前还曾经总结过一套PHP的敏捷开发工具包。

php那个类ror的框架叫Cake吧？

24 楼 iamdaiyuan 2007-06-21  

言之有理

23 楼 gigix 2007-06-21  

fnet 写道

呵呵，不如找一个框架写php，快的不能再快。环境也好弄。

不过我正努力学java中

PHP有一个类似于RoR的框架，好像叫Symphony什么的，记不清了。PHP还有Pake（PHP Make），单元测试框架也有。只要有这个套路，到哪儿都行得通。我们以前还曾经总结过一套PHP的敏捷开发工具包。

22 楼 fnet 2007-06-21  

呵呵，不如找一个框架写php，快的不能再快。环境也好弄。

不过我正努力学java中

21 楼 gigix 2007-06-20  

cookoo 写道

编码和操作系统还是可以选择的，遗留数据库就没希望了。大多数open source的项目对商用数据库的支持都不太成熟，用的人少，没能力支持，不是故意不支持。

这个东西，同样是可以去做的。就拿RoR来说，Ruby在数据库驱动的层面上已经支持SQLServer和Oracle，需要做的是一些更接近应用层面的封装。如果确实有这种需求，为它做一个开源项目，成本也高不到哪里去。在RubyWorks比较远期的计划中，我们就打算做这样的事。
有问题存在，把它解决掉就行了，这是很简单的事情。

20 楼 cookoo 2007-06-20  

编码和操作系统还是可以选择的，遗留数据库就没希望了。大多数open source的项目对商用数据库的支持都不太成熟，用的人少，没能力支持，不是故意不支持。

19 楼 gigix 2007-06-20  

basicbest 写道

任何一项技术都有他自己适用的场合，jack的提醒是善意的，这也是某些自认为技术高超的激进人士经常犯的错误，盲目追崇新的技术，或者盲目听从，都是会犯错误的，这些错误也必然会在后面由自己承担，而当初那些人，却会说“看吧，我让你完全按照我说的做，你就是不听，这个不是我的观点有问题，而是你自己有问题”。

我不知道像你这种自认为经验丰富的保守人士会如何去评估一种新技术
不过至少在我看来，要评估一种新技术是否可用有一个最基本的条件
你至少花过时间去了解它
如果你花过哪怕一天时间去了解Ruby on Rails，你就应该知道
convention over configuration是它整体的设计原则
所以不遵循它的convention就无法得到它的很多好处，那也是理所当然的
请问这和你明讥暗讽说的那种情况是一回事吗？

另外还有个问题我也想不出答案：
在评估和推荐之前会去花时间了解新技术的自认为技术高超的激进人士
和
在批评之前根本不花时间去了解的自认为经验丰富的保守人士
究竟哪一个对别人会更有帮助一点。

18 楼 basicbest 2007-06-19  

任何一项技术都有他自己适用的场合，jack的提醒是善意的，这也是某些自认为技术高超的激进人士经常犯的错误，盲目追崇新的技术，或者盲目听从，都是会犯错误的，这些错误也必然会在后面由自己承担，而当初那些人，却会说“看吧，我让你完全按照我说的做，你就是不听，这个不是我的观点有问题，而是你自己有问题”。

17 楼 missall 2007-06-19  

我是用ror开发的新项目,LZ提到的问题出现不少,不过有技术牛人指导一一解决,总体来说ror还是很不错的,开发速度提升不少,只不过现在ROR的有些技术难题很少能google到书也基本上都是刚开始深入的介绍,问题是有滴,不过我看好她的前景

16 楼 hideto 2007-06-19  

楼主所说的这些问题，参考一下javaeye，就不成问题了

15 楼 testt 2007-06-19  

或许jack的公司只让他决定开发语言而不让决定开发环境。

14 楼 weiqingfei 2007-06-18  

gigix 写道

lakeeye2002 写道

自我学习以来,RAILS其快速的开发进程令人鼓舞,尽管还有很多需要完善的地方,但是我可以理解,毕竟这是一个事物发展的必经阶段,似乎到目前为止,还没有一种完善到零风险的工具.存在的,有其合理性.

Rails的快速，很大程度上是因为它缩小了你的选择空间，从而节省了作出选择的成本：它告诉你一个好的网站应该怎么做，你就照着这个套路做就是了。黑话这个就叫convention over configuration。有效缩小选择空间需要信息，这些信息就是“如何开发网站”的知识。Rails之所以快，因为它提供了更多的知识。
所以，如果你不用这些知识，它没办法让你继续快起来也就是很正常的。

这就是刀和镰刀的区别

13 楼 crazysoul 2007-06-17  

这种状况让人想起一句话：
report a bug relying on a bug

12 楼 jack 2007-06-17  

的确，经过这几个月的之后，确如gigix说的，rails必须按照它推荐的方式去做，抛弃这点，基本就等于抛弃rails本身。
而且我也犯了低级错误，测试环境同生产环境有很大的不同。有些问题前期自然难以发现。

11 楼 gigix 2007-06-16  

lakeeye2002 写道

自我学习以来,RAILS其快速的开发进程令人鼓舞,尽管还有很多需要完善的地方,但是我可以理解,毕竟这是一个事物发展的必经阶段,似乎到目前为止,还没有一种完善到零风险的工具.存在的,有其合理性.

Rails的快速，很大程度上是因为它缩小了你的选择空间，从而节省了作出选择的成本：它告诉你一个好的网站应该怎么做，你就照着这个套路做就是了。黑话这个就叫convention over configuration。有效缩小选择空间需要信息，这些信息就是“如何开发网站”的知识。Rails之所以快，因为它提供了更多的知识。
所以，如果你不用这些知识，它没办法让你继续快起来也就是很正常的。

10 楼 lakeeye2002 2007-06-16  

caryl 写道

gigix 写道

steve_gu 写道

gigix 写道

因为你把它宝贵的东西都扔掉了

jack是被逼的

我知道
但他的困境，仍然是很可讨论的。如果真的为这些问题，像他说的，卡了几个月，那是多大的成本浪费？出于什么样的考虑，可以浪费如此大的成本，而一定要坚持用Windows Server、用SQLServer、用GB2312编码？这个决策本身就是很可商榷的。

相当深刻。

自我学习以来,RAILS其快速的开发进程令人鼓舞,尽管还有很多需要完善的地方,但是我可以理解,毕竟这是一个事物发展的必经阶段,似乎到目前为止,还没有一种完善到零风险的工具.存在的,有其合理性.