ruby, RoR

bryon

有人玩吗？
我刚刚开始学
不妨交流

jangancari

想不到Ruby on Rail 都有人在这里谈。

几个月前有心自学， 可惜Linux 电脑已经带回国了， 目前用着win2k laptop ， 超慢。

读过几篇文章， 也读过几个编程员的comment ， RoR 开发速度快速， 单单以网页数据库程序的功能的话， 据说可以取代Java（可是没有Java 那么多元化， 可以开发mobile program） 。 可是要customize RoR程序的话就不太容易。

Ruby 是日本人创造的， RoR 能不能在中国普及化是一个问题。

但是国外， RoR 开始有如AJAX 技术， 越来越多的conference 都有这个topic 。

bryon

对啊，ror 1.2开始有rjs了
我是透过digg发现到的
虽然是读IS的，但学programming总学不好,希望能学好这个
ror甚至引发了其他language的抄袭者，如python的django等等

Mod_ruby很慢，不过现在有了mongrel
现在的问题就是还不支援unicode, ruby在ror之前很少人知道的

jangancari

Ror你懂的比我还多很多。

Ruby 已经存在很久了， 是 python derived programming language 。

目前很多language 都有rails 了， 这就是开源的威力。 不过， 不管用什么language ， 最重要是用最适合的language 作适合的工。

bryon

你说的对


会维持吗？
http://www.alexa.com/data/detail ... &url=python.org
http://www.alexa.com/data/detail ... url=rubyonrails.org

[ 本帖最后由 bryon 于 4-8-2006 01:04 AM 编辑 ]

苦瓜汤

刚接触ruby不久，觉得非常强而且简单。
看过一篇文章拿Ruby和Java来比较，很多方面都是满出色的，包括coding, memory management等等。唯一逊色的地方就是公共关系和普遍程度。
不过，以Ruby的发展速度来看，前景是乐观的。

jangancari

原帖由 bryon 于 8-7-2006 01:55 PM 发表
你说的对

http://traffic.alexa.com/graph?w ... www.rubyonrails.org
会维持吗？

会不会维持应该不太重要， python 会因为ubuntu 的成功而得到一定的支持度， 而Ruby 能不能扩大使用群就看RoR了

原帖由 SotongJiang 于 12-7-2006 12:47 PM 发表
新一代的IT生力军应该关注和学习AJAX，老一辈的IT人如我，从第一次做工到现在都是搞JAVA的，只能专心磨利JAVA宝刀。一个人的时间和精力有限，不能随波逐流乱揽最新科技。

我以前大学的女同学，专攻GRAPICS，专 ...

我同意一个人的时间和精力有限， 不能随波逐流乱揽最新科技， 但是一定要对目前的新科技有触感。

RoR 本身就建立在Ajax 上， 这个是一定要知道的。 RoR 比之Java 的优胜之处也是大家应该要知道的。

Java 本身就继承了C++ 的coding 模式， 从coding syntax方面来看， object-oriented 对于code database program 的data update/creation/delete  不是一个最好的选择。 所以才有record-oriented/table-oriented 的concept 。

RoR 在这个方面就类似了Case tools ， 对于某些特定的syntax就优于很多的电脑语言。

Ruby 和Phyton 的syntax 都是属于4GL 了， 是有一定的潜能。


不论是编程员还是support 的人员， 都不能不进修管理知识。 只有着一个技术， 在IT 界还是可以找到饭吃， 有没有钱途就看个人对薪金的要求程度了。 但是只有单纯技术， 要找新工作会比较困难。 如果中年失业的话，会有很大问题。

Java 的优势在于library 的多元化和先进化， 如果Sun 实现承诺真的在明年把Java 开源的的话， Java 应该会进入一个新的里程碑， 绝对有能力把.Net 的气势抑制下来。

苦瓜汤

除了mod_ruby，刚刚试了FastCGI也是很慢啊....
难道在Apache上面就不能像Webrick或Mongrel这样快吗？ 纳闷。。。。

bryon

原帖由 苦瓜汤 于 21-7-2006 15:31 发表
除了mod_ruby，刚刚试了FastCGI也是很慢啊....
难道在Apache上面就不能像Webrick或Mongrel这样快吗？ 纳闷。。。。

mod_proxy_balancer

exiang

其实RoR 没有什么值得大惊小怪的，只是一个提供快速开发WEB-BASE 的FRAMEWORK 而已。
AJAX 也不是他独有的， 还是要使用OPEN SOURCE 的PROTOTYPE 和 SCRIPTACULOUS.

只要是FRAMEWORK, 便必须牺牲OPTIMIZATION。执行速度慢一点是理所当然的。

至于SCAFFOLD,一开始听起来很COOL，但更本不能过哪来做什么PRODUCTION用的。最后， PROGRAMMER 还是要做回自己应该做的东西-写CODE， 偷懒不得。当然，SCARFOLD 也不是ROR 独有的，PHP 的 PEAR 很早以前便能够做这样的东西了。

把RoR 拿来和 PHP PHYTON 等比较是非常不公平的，因为一个FRAMEWORK 和一个LANGUAGE 可以比出什么来？

RoR 能够得到那么多SPOTLIGHT,我只能说到市场需要新的东西来做卖点。单单出书便有够好赚。

这个年头，你只要选一个不怎么出名的开源　language　来建立一些 platform，然后用这个PLATFORM 做一写新奇的网站，再建立一个美美的主页，HARD SALE 你的卖点，出几本书，便能够成功了。

bryon

连zend都推出framework了
http://framework.zend.com/

苦瓜汤

原帖由 bryon 于 26-7-2006 08:43 AM 发表
连zend都推出framework了
http://framework.zend.com/

不错啊，虽然没有RoR那么‘自动化’，不过整合了许多PEAR/PECL的精华。
Ruby在我的Windows里出现了很多问题，发现在我的FreeBSD里就很好，Ruby毕竟还是为Unix设计的。（发现Ruby-lang的IRC channel里竟然没有什么人用Windows开发Ruby app。）
我今天试了ZendF，目前无论是Apache，PDO等设定都没有问题出现。最重要的一点，速度快！

bryon

ror 的 setup tuts
http://www.themolehill.com/index ... n-rails-in-windows/

苦瓜汤

原帖由 bryon 于 28-7-2006 01:28 AM 发表
ror 的 setup tuts
http://www.themolehill.com/index ... n-rails-in-windows/

Rails本身透过RubyGems安装是没有问题。问题在于Ruby的一些library如dbi，tk等等，很多都是在Unix开发的，所以一些方便还没能‘惠及’Windows 用户。不过，Ruby对我来说还是一个很方便和强大的编程语言。

苦瓜汤

Ruby on RAIls 好像一直处于争论的风口浪尖。大多数争论的核心是其所宣称的令人惊异的生产力。作者 Bruce Tate 已经开始理解 Rails 并不是一个更好的工具，而是一个不同类型的工具。本文研究了使 Rails 在某个领域如此高效率的折衷和设计决策。然后思索了应该在 Java™ 社区获得更多关注的受 Rails 启发的思想。

　　Ruby on Rails(也叫做 Rails)是一个针对支持数据库的 Internet 应用程序的 Ruby 框架。我现在已经将 Rails 用于两个不同的应用程序并涉及了另外两个关联的程序。为了即将完成的新书 Java to Ruby，我已经采访了很多 Rails 开发人员(那些在该框架上既成功也失败过的人)、框架的创始人和 Rails 书籍的旗舰之作 AGILE Web Development with Rails的主要作者。我开始理解为什么 Ruby on Rails 架构如此成功。

　　炒作和怀疑论

　　在 Java 社区关于 Rails 的争论已经相当激烈并且在将来一段时间没有停止的迹象。Rails 的支持者称赞它的惊人的效率，与 Java 开发相比效率大约是 10:1。作为 Java 程序员，您下意识的反应是不相信任何宣传过高的效率，因为您可能以前听到过这些，然而实际让您很失望。Java 提倡者日益坚持 Ruby on Rails 是一个玩具，不能伸缩，会生成坏的代码，并且只能开发简单的应用程序。但是随着对 Rails 的赞扬不断出现(通常来自可信的来源)，一项更加谨慎的任务是理解 Rails 能做好什么事情，并把它的思想带回到 Java 平台。在本文中，将探究为 Rails 带来巨大效率的核心特性(即秘笈)。

　　Rails 基本原理

　　Ruby on Rails 框架不是大家所想的典型的应用程序开发框架。Rails 的创始人 David Heinemeier Hansson 通常把该框架称为固执己见的软件，并且他喜欢打破长期存在的约定。David 做出了非常有哲理性的决策并在整个框架中严格遵循这些决策。遍布于 Rails 内的核心观点有:

* 　　无缝集成:Rails 聪明地利用了 Ruby 语言的最好特性。它扩展了 Ruby，但您很难说出 Ruby 在哪里结束，Rails 从哪里开始。您也可以看到 Active RECord(Rails 的持久引擎)和模型-视图-控制器(MVC)框架之间进行了很好的集成。例如，您可以编写三行代码，创建一个表，然后立即为该模型生成用户界面。
* 　　约定优于配置:为保持良好的灵活性，Java 框架保持了大量普遍的配置文件。Rails 不采用这种策略。它为方法、类、表和列采用普通的项目目录结构和简单普通的命名约定，以推断哪些已配置在 Java 应用程序中。结果是，Rails 应用程序只需要对应 Java 应用程序的一小部分配置代码，一般是十分之一或更多。
* 　　低重复:不要重复自己(Don't Repeat Yourself，DRY)是 Rails 社区的一个常见术语。Rails 框架委员会使用通常看起来像是 Ruby 语言的扩展的方法来把重复的任务抽象出来。Rails 的元编程策略使每行代码都执行更多的任务。
* 　　即时反馈:使用 Rails，对于您所做的大多数工作都会给出即时反馈。编写一行代码并保存后，在加载下一个 Web 页面时将激活您所做的更改。更新了您的数据库以后，迁移可以向您即时显示更改。

　　专注于某个领域

　　反对其宣称的过高生产率的争论通常类似于这样:如果获得了一把好的锤子，就很难找到另外一把生产率达到两倍的锤子，更不用说把生产率提高 5 到 10 倍了，因为锤子已经发展演变几千年了。但是把 Ruby on Rails 与各种通用目的的 Java 框架相比较的人是不得要领的。通过从根本上改变工具的本质可以在某些方面提高 10 倍的生产率。现在专业的制造者使用钉子枪能够在用锤子钉入一颗钉子的时间内钉入很多钉子。像钉子枪一样，Rails 也是有专门用途的。它是一个专门编写来用于单个领域的框架:新的支持数据库的 Web 应用程序。

　　我猜想现今构建的应用程序有一半是支持数据库且基于 Web 的应用程序。所以 Rails 是明确针对某领域的产品，但是这个领域很大也很重要。专攻此领域使 Rails 具有巨大的优势，引起巨大轰动。通过专注于此领域的项目，Rails 的设计者可以选择一些其他框架不能或者不应该采用的捷径。这种专门化往往为简单性而失去灵活性。

　　新的支持数据库的应用程序建议打包方法优于映射方法。Rails 工具采用数据模型中的约定。Rails 应用程序需要 Java 应用程序中创建的一小部分模型代码。如果特别为 Rails 应用程序创建模式，此原则能工作得很好。如果试图把遗留的模式塞入 Rails 中，将变得不太平滑。

　　基于 Web 的应用程序允许一组相似的优化。当您知道一个应用程序是基于 Web 的，您就能知道应用程序的大体结构和可能需要的主要组件。因为 Rails 关注的是基于 Web 的应用程序，所以在 Rails 中增强了以下功能:

* 　　模型-视图-控制器:Rails 的 MVC 框架(称为 Action Pack)为基于 Web 的访问进行了定制并且实现了著名的被称为 Model 2的设计策略。Rails 版本已经优化了控制器和视图之间的集成(该集成能够使配置文件最小化)并且自动使控制器实例变量可供视图使用。
* 　　项目目录结构:所有 Rails 应用程序都具有相同的项目结构，其中的目录用于存储应用程序代码、数据库配置、公共的静态文件，以及用于管理 Web 服务器和进行基于 Web 的功能测试的脚本。
* 　　架构:通过提供用于生成应用程序组件(这些组件都符合普通架构目标，比如页面级和片段级缓存;两层设计;用于测试、开发和生产的环境)的开箱即用脚本，Rails 框架简化了架构。
* 　　工具:Rails 工具专门用于 Web。日志支持、breakpointer、剖析器(profiler)和测试框架都针对基于 Web 的应用程序进行了修剪并针对两层操作而被启用。

　　但是钉子枪永远不会取代锤子，我们却愚蠢地希望能完全取代。锤子总能做一些钉子枪不能做的事情。Rails 将永远不会成为用于企业集成、对象关系映射或全堆栈 Web 服务的工具。您可以对 Rails 所做的最好期望是，它是能很好满足它所针对领域的专门工具。

　　开发人员实践

　　当您开始透过表面深入研究下去时，您开始了解 Rails 开发人员实践是如此的完全不同。快速的反馈周期、每次的交互控制和约定优于配置，这些都增强了在 Java 框架中不常用的那些方面的开发人员实践。

　　反馈周期

　　影响开发人员生产率的最重要因素之一是总体反馈周期。反馈周期是从改变代码到在屏幕上看到执行应用程序的结果所用的时间。在 Rails 中，能够在编码时得到即时的反馈。当您对 Ruby 代码做出更改时，该功能十分显著。可以立即加载一个浏览器页面来查看更改以后的结果。因为在开发期间不需要编译或部署，我倾向于在重新加载浏览器或执行测试用例之前只对编程做微小的更改。几乎每个开始使用 Rails 的 Java 开发人员都以较小的程序块进行编码。

　　您可能认为对开发人员实践友好的快速反馈周期不支持生产环境。毕竟，频繁地重新加载类能够获得快速反馈周期，但是会使生产应用程序变得很慢。但是 Rails 通过为部署和开发提供不同的环境，避免了这个问题。在开发环境中以应用程序的性能为代价强制频繁地重新加载类，而生产环境则把类的重新加载减少到最低限度，以开发人员的快速反馈周期为代价，为最终用户提供快速的体验。


来源：Bruce Tate/developerWorks 中国