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的书上，是从未提起过。三个问题，随便哪个问题解决不了，项目就完全流产了。使用新技术的整个过程中，风险依然很大。回头想想，还真是汗颜。

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

 

评论

49 楼 westdoorsiman 2007-07-02  

Rails的软件应用在哪里,IBM,google?

48 楼 gigix 2007-07-02  

shrpcn 写道

引用

整个Ruby on Rails社区说老实话就是歧视Windows用户。Windows本来就是一个糟糕的、不适合做服务器的操作系统，你为什么一定要用它做服务器？既然你要这么做，就为自己的选择付出代价吧：你会经常看到Ruby或者Rails的某个特性不支持Windows。

引用

我真的希望不要再看到类似这样信口开河胡说八道的废话
你能不能哪怕举出一个具体的论据来支持你的观点以便让别人知道你说的这句大话至少略微经过了你的大脑？

一样的问题，信口开河.

随便就给你举出例子来
比如说Mongrel的-d选项在Windows下是禁用的，因为Windows没有一个良好的daemon机制
比如说FileUtils.ln_s这个方法在Windows底下就不能用，尽管它真的很有用
比如Process.kill方法不支持Windows，因为Windows的进程管理做得完全不必要地复杂而难用

47 楼 shrpcn 2007-07-02  

引用

整个Ruby on Rails社区说老实话就是歧视Windows用户。Windows本来就是一个糟糕的、不适合做服务器的操作系统，你为什么一定要用它做服务器？既然你要这么做，就为自己的选择付出代价吧：你会经常看到Ruby或者Rails的某个特性不支持Windows。

引用

我真的希望不要再看到类似这样信口开河胡说八道的废话
你能不能哪怕举出一个具体的论据来支持你的观点以便让别人知道你说的这句大话至少略微经过了你的大脑？

一样的问题，信口开河.

46 楼 caryl 2007-07-02  

westdoorsiman 写道

rails做做小网站还可以,离做软件还差不多十万八千里

正在用rails做软件，至少从目前情况看来，还没遇到大的问题。反而一些常用的功能rails都可以很方便的解决。

45 楼 gigix 2007-07-02  

westdoorsiman 写道

rails做做小网站还可以,离做软件还差不多十万八千里

我真的希望不要再看到类似这样信口开河胡说八道的废话
你能不能哪怕举出一个具体的论据来支持你的观点以便让别人知道你说的这句大话至少略微经过了你的大脑？

44 楼 westdoorsiman 2007-07-02  

rails做做小网站还可以,离做软件还差不多十万八千里

43 楼 gigix 2007-07-01  

zb1015 写道

jack说的不错,rails不用mysql,哈哈你不用试试,问题一大堆

就我们做过的评估而言，postgresql和sqlite的支持基本上和mysql没有区别。

42 楼 zb1015 2007-06-30  

jack说的不错,rails不用mysql,哈哈你不用试试,问题一大堆

41 楼 hideto 2007-06-30  

Rails1.2.3支持的数据库：
mysql postgresql sqlite firebird sqlserver db2 oracle sybase openbase frontbase

40 楼 gigix 2007-06-30  

ltian 写道

我晕倒了，连MS  sql server这样最普通的数据库都支持不了吗，一个开发框架难道还有数据库限制

整个Ruby on Rails社区说老实话就是歧视Windows用户。Windows本来就是一个糟糕的、不适合做服务器的操作系统，你为什么一定要用它做服务器？既然你要这么做，就为自己的选择付出代价吧：你会经常看到Ruby或者Rails的某个特性不支持Windows。

39 楼 wangdong 2007-06-29  

Windows Server + SQLServer + Rails
这个方案自己没好好评估能怪谁？

38 楼 lixigua 2007-06-27  

吵架了，技术人就是爱吵架啊。
gigix 大约是看到见到听到了太多项目为一个不存在的需求去做过多考虑的事情了。大家都在学习，都走了这个弯路。以Java的配置为例，为了未来可能的需求我们在上面花了太多精力。去年跟做C的项目，发现做C的兄弟们考虑问题就是不一样啊。他们尽量去考虑做现在需要的灵活，而不是假象的灵活 （本来C要配置化，灵活也不容易）。借此精神，我今年写点东西，发现容易多了。跑题了,呵呵。
“不存在的需求”确实是我们的大敌，设计时需要谨慎考虑。具体到楼主的案例，楼主没说起客户对系统的要求，所以不好说。也许客户就是要求 win,sql server怎么办？这个方面 ，很难说服他们的。
我们公司做一个数据仓库项目据说客户还要求在win上做呢（其他分公司实施，我只在打标期间听说 ，不知道后来实际怎么做 ）。客户的这个要求很简单，他们的科技人员技能低，维护win方便，容易。而维护liuix,unix，他们有这能力的人太少。-----可知道他们还是商业银行啊，比起其他行业，总体上懂unix的人要多很多了啊。 

37 楼 yuyijq 2007-06-27  

其实这些问题不需要什么争论，正如Dave Thomas在那本经典的Agile Web。。。里所说的：作web的路子有很多，而Rails将最好的一种给你，选择Rails你就选择了Rails认为最好的路，你不想走这条路，那么也请不要选择Rails

36 楼 SteveGY 2007-06-25  

gigix 写道

jigsaw 写道

且让我跑个题。本帖通篇主旨是讲铁道上的鲁比，可我偏偏淫者见淫，满眼全是一位职业咨询师的精彩表演。

>> 合同是不是这么签的
没听说过哪单合同会因为咨询师的意见而_改_签的 所以这里轮不到你操心合同的合理性。

>>客户的数据库是不是最宝贵的
晕 这个都需要质疑？很好 你有怀疑一切的素养 可惜显然用错了地方

>>凭空说没有这些事情，是不负责任；凭空说有这些事情，同样是不负责任。
非常正确，的废话

>>至少我自己已经多次看到为了一个想当然的需求而凭空加大开发成本的例子了。
你见过，我也见过，这里大多数人都见过。说出来就很拽吗？
你这副口气，无非也就是_想当然_地把别人的产品／项目当作是_想当然_的需求。这不自己扇自己吗？

赫赫 我也就耍个贫嘴 千万别跟我一般见识

既然你都这么说了，还有什么好讲的呢，只好高呼您永远正确咯
正如我用红色标出来的，您的见多识广已经让我无话可说了。

不好意思，可能我的口气有问题，在论坛上，一开口，态度不好，就容易得罪人，呵呵。

其实，我们也可以注意到，rails确实就是规定了它自己的套路，或者是正确的套路，这种套路可以减少一些开发的规范问题，并且解决很多的实际问题，但这也一样限制了作为通用开发框架（或者规范,'specification'）的适用性，我的理解是“适用性”（或者是通用性？）在rails框架的方法论上有缺陷，也许它从出生那天起就从来没有想过要成为“通用”的框架，这是我的一厢情愿，呵呵。这也许和rails目前发展的时间还不够长有关，有些东西很难勉强的，在适当的时间点之前，没有出现合适的解决方法，有一些很好的尝试会遇到挫折，这需要时间、耐心，等待它条件成熟。我的资源不够，我只能等待。

比如，我个人比较喜欢glassfish的设计结构和某些特性，grizzly http connector 和目录deploy特性等等，但到今天为止，我仍然不能把它作为一个可选的应用服务器发布到生产环境中去，因为那该死的glassfish V2还没有结束beta，在我的应用程序中关键的cluster仍然不稳定，而V1又不支持cluster，等着，我没有选择，还在用jboss 4.0.5。同样道理，ruby的ms sqlserver的驱动似乎看不到什么希望 ，不用安慰大家，事实如此，看看python上的sqlserver驱动，还有linux上的sqlserver连通性，除了jdbc，ms几乎不给任何的支持，所以我认为这件事情是没有希望的，ms不会配合的。这也是我跟踪jRuby和grails的原因，希望他们的数据库连通性应该是完美的。不过到今天为止，我对grails基于hibernate的ORM依然失望，估计他们的ORM特征表中的项目仅完成了30%，呵呵，不行，受不了，所以我耐心等待。所以我想，不管大家喜欢还是不喜欢ruby rails，在没有足够的资源时，只能等待，资源永远是有限的，还是利用有限的资源做些有用的事情吧。

35 楼 gigix 2007-06-25  

jigsaw 写道

且让我跑个题。本帖通篇主旨是讲铁道上的鲁比，可我偏偏淫者见淫，满眼全是一位职业咨询师的精彩表演。

>> 合同是不是这么签的
没听说过哪单合同会因为咨询师的意见而_改_签的 所以这里轮不到你操心合同的合理性。

>>客户的数据库是不是最宝贵的
晕 这个都需要质疑？很好 你有怀疑一切的素养 可惜显然用错了地方

>>凭空说没有这些事情，是不负责任；凭空说有这些事情，同样是不负责任。
非常正确，的废话

>>至少我自己已经多次看到为了一个想当然的需求而凭空加大开发成本的例子了。
你见过，我也见过，这里大多数人都见过。说出来就很拽吗？
你这副口气，无非也就是_想当然_地把别人的产品／项目当作是_想当然_的需求。这不自己扇自己吗？

赫赫 我也就耍个贫嘴 千万别跟我一般见识

既然你都这么说了，还有什么好讲的呢，只好高呼您永远正确咯
正如我用红色标出来的，您的见多识广已经让我无话可说了。

34 楼 jigsaw 2007-06-24  

且让我跑个题。本帖通篇主旨是讲铁道上的鲁比，可我偏偏淫者见淫，满眼全是一位职业咨询师的精彩表演。

>> 合同是不是这么签的
没听说过哪单合同会因为咨询师的意见而_改_签的 所以这里轮不到你操心合同的合理性。

>>客户的数据库是不是最宝贵的
晕 这个都需要质疑？很好 你有怀疑一切的素养 可惜显然用错了地方

>>凭空说没有这些事情，是不负责任；凭空说有这些事情，同样是不负责任。
非常正确，的废话

>>至少我自己已经多次看到为了一个想当然的需求而凭空加大开发成本的例子了。
你见过，我也见过，这里大多数人都见过。说出来就很拽吗？
你这副口气，无非也就是_想当然_地把别人的产品／项目当作是_想当然_的需求。这不自己扇自己吗？

赫赫 我也就耍个贫嘴 千万别跟我一般见识

33 楼 gigix 2007-06-24  

SteveGY 写道

？？？深刻？？这有什么好“深刻”的？

“一定要坚持用Windows Server、用SQLServer”，很多时刻，这就是客户的实际应用环境，合同就是这么签的，你能不照做吗？客户真金白银买的操作系统和数据库，这就是理由。

“因为你把它宝贵的东西都扔掉了”，在客户看起来，他们的投资才是最宝贵的东西。

还有人提到了UTF-8的问题，听口气似乎别人用GB编码就是落后，哎~~~~，你们有用过U8编码的数据库吗？知道国内的拼音排序规则吧？在不同的操作系统上，你测试过这样的排序吗？拜托各位用windows的mysql或postgers在936编码的windows上测试一下，当数据库使用u8编码的时候的排序，再同样的测试一下，在用u8编码的linux(Debian, Ubuntu或rh，甚至solaris 10)系统上，使用u8编码的mysql或postgres的数据库中文排序的结果。试一下，看看结果，再说话。还可以了解一下GBK, GB18030和Unicode组织之间的历史关系，你会发现，我们又多了N个痛骂技术官僚的理由。要解决这个问题，还得为linux系统添加utf-8.pinyin的排序规则，这个排序目前由国内某个人在维护，也是最近才有的库。

从你自己的回帖也看得出来，合同是不是这么签的，客户的数据库是不是最宝贵的，应用程序是不是需要按拼音排序，这些都是需要去确认的。凭空说没有这些事情，是不负责任；凭空说有这些事情，同样是不负责任。如果确实有这些事情，确实它们价值很大，为了它们来加大开发成本也是合情合理的事。但我的重点是：有没有充分论证这些需求的合理性。至少我自己已经多次看到为了一个想当然的需求而凭空加大开发成本的例子了。

32 楼 SteveGY 2007-06-24  

caryl 写道

gigix 写道

steve_gu 写道

gigix 写道

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

jack是被逼的

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

相当深刻。

？？？深刻？？这有什么好“深刻”的？

“一定要坚持用Windows Server、用SQLServer”，很多时刻，这就是客户的实际应用环境，合同就是这么签的，你能不照做吗？客户真金白银买的操作系统和数据库，这就是理由。

“因为你把它宝贵的东西都扔掉了”，在客户看起来，他们的投资才是最宝贵的东西。

还有人提到了UTF-8的问题，听口气似乎别人用GB编码就是落后，哎~~~~，你们有用过U8编码的数据库吗？知道国内的拼音排序规则吧？在不同的操作系统上，你测试过这样的排序吗？拜托各位用windows的mysql或postgers在936编码的windows上测试一下，当数据库使用u8编码的时候的排序，再同样的测试一下，在用u8编码的linux(Debian, Ubuntu或rh，甚至solaris 10)系统上，使用u8编码的mysql或postgres的数据库中文排序的结果。试一下，看看结果，再说话。还可以了解一下GBK, GB18030和Unicode组织之间的历史关系，你会发现，我们又多了N个痛骂技术官僚的理由。要解决这个问题，还得为linux系统添加utf-8.pinyin的排序规则，这个排序目前由国内某个人在维护，也是最近才有的库。

31 楼 seamon 2007-06-22  

看了楼主的描述，感觉好象故意跟自己过不去似的。

30 楼 fnet 2007-06-22  

恩,Symfony效率比较差，cakePHP好一点，但是也不是太好。怎么说呢，php的开发框架国内有两款还不错，很轻量级。很好学