Rails之道
基本信息
- 原书名: The Rails Way
- 原出版社: Addison-Wesley Professional
- 作者: (美)Obie Fernandez [作译者介绍]
- 译者: Ruby on Rails中文社区
- 出版社:人民邮电出版社
- ISBN:9787115220721
- 上架时间:2010-3-26
- 出版日期:2010 年4月
- 开本:16开
- 页码:504
- 版次:1-1
- 所属分类:
计算机 > 软件与程序设计 > Rails/Ruby
编辑推荐
Ruby on Rails经典参考用书
Jolt年度技术图书大奖获得者
深入讲解Ruby on Rails框架中的各种知识点和应用新特性
Rails各种API函数参考大全
Ruby on Rails中文社区倾情奉献
一本书,让你参透Ruby on Rails的世界
推荐阅读
内容简介回到顶部↑
本书按照rails的各个子系统进行组织编排,分别介绍了rails的环境、初始过程、配置和日志记录,rails的分配器、控制器、页面生成和路由,rest、资源和rails,activerecord的基础、关联、验证和高级技巧,actionview的模板、缓存和帮助器,ajax、prototype和scriptaculous等javascript代码库和rjs,session管理、用户登录和认证系统,xml和activeresource,后台处理和actionmaile,测试和specs(包括rspec on rails和selenium),安装、管理、编写插件,rails的生产部署、配置和capistrano等内容。
本书详细讨论了rails的程序代码并通过分析rails中的代码片段来深入解释它的功能,同时,本书部分章节也摘录了一些api文档中的内容,使读者能够快速地找到对应的api文档、相关的示例代码以及深入的解析说明。
本书是rails的权威参考书,适合对rails已经有一定了解的开发人员学习和使用。
本书详细讨论了rails的程序代码并通过分析rails中的代码片段来深入解释它的功能,同时,本书部分章节也摘录了一些api文档中的内容,使读者能够快速地找到对应的api文档、相关的示例代码以及深入的解析说明。
本书是rails的权威参考书,适合对rails已经有一定了解的开发人员学习和使用。
作译者回到顶部↑
本书提供作译者介绍
Obie Fernandez是一位广为人知的技术行业领袖和独立咨询师。从20世纪80年代获得第一台Commodore VIC-20开始,他就一直在从事各种黑客工作。20世纪90年代中期,他终于找到了自己的位置,成为第一代Java企业项目的编程师。他于1998年移居到美国乔治亚州亚特兰大市,并作为当地新兴企业MediaOcean的首席架构师而闻名。他还成立了Extreme Programming(后改名为Agile Atlanta)用户社团,并在该社团担任了几年的主席和组织人。2004年,他又回归企业,为世界著名的咨询公司Thought Works处理那些具有很大.. << 查看详细
目录回到顶部↑
第1章 rails环境与配置 1
1.1 启动 1
1.1.1 默认环境设置 1
1.1.2 引导 2
1.1.3 rubygems 3
1.1.4 初始化 4
1.1.5 默认加载路径 4
1.1.6 rails模组及代码自动加载 5
1.1.7 内置的rails信息 5
1.1.8 配置 6
1.1.9 附加配置 8
1.2 开发模式 8
1.2.1 类文件自动化重新加载 9
1.2.2 rails类加载器 9
1.3 测试模式 10
1.4 生产模式 11
1.5 日志器 11
1.5.1 rails日志文件 12
1.5.2 日志分析 13
1.5.3 syslog 15
1.1 启动 1
1.1.1 默认环境设置 1
1.1.2 引导 2
1.1.3 rubygems 3
1.1.4 初始化 4
1.1.5 默认加载路径 4
1.1.6 rails模组及代码自动加载 5
1.1.7 内置的rails信息 5
1.1.8 配置 6
1.1.9 附加配置 8
1.2 开发模式 8
1.2.1 类文件自动化重新加载 9
1.2.2 rails类加载器 9
1.3 测试模式 10
1.4 生产模式 11
1.5 日志器 11
1.5.1 rails日志文件 12
1.5.2 日志分析 13
1.5.3 syslog 15
前言回到顶部↑
在2004年末,我正在为一家大型美国汽车制造公司做咨询服务。当时和我一起工作的还有我的好朋友Aslak Hellesoy。我们所接手的那个项目很具挑战性,不仅面临困难的公司政治矛盾、技术障碍,而且工期很紧。这个项目的工期还不是一般意义上的紧张,在当时的项目情况下,如果我们每拖延一天完工,我们的客户就得被罚100万美元。因此压力可想而知!
在那个项目中我们曾面临一个具有争议的抉择,不过最后我们的团队决定将我们的连续整合系统构建在Aslak的一个业余项目Damage Control的基础上。Damage Control是老旧的Cruise Control服务器的Ruby版本,是由我们的雇主公司Thought Works开发的。
问题是Damage Control当时还是一个半成品,而且和其他许多Ruby事物一样,它在Windows系统中兼容性不是很好。我已经记不得是什么原因,不过当时我们必须将它部署到一个陈旧的Windows 2000服务器上,而且那个服务器上还跑着一个StarTeam代码版本库(折腾!)。
Aslak需要帮助——在这之后的几个星期,我们没日没夜地进行结对编程的工作。对DamageControl的程序代码和Ruby的Win32程序代码库的C代码进行了大量改造。当时的我具有八年正规行业的Java开发经验,而且当时我特别喜欢使用IntelliJ IDE;但在那段时间,我对Ruby的痛恨不禁溢于言表。
当这个倍具压力的项目上线之后,我接手了另一个相对轻松的任务并转去ThoughtWorks的伦敦办公室工作。过了大概一个月的时间,Ruby再一次吸引了我的注意。当时我在很多朋友的博客上看到他们激动地讨论一个即将发布的网络程序框架,叫做Ruby on Rails。于是我决定再来试试Ruby,或许它并非那么糟糕吧。我很快就创新地为ThoughtWorks建立起一个供内部使用的社区网络系统。
在2005年初的那几周中,我的Rails第一次亲密接触让我完全转变了看法。经年累月以来我所学到的那些用于构建网络应用程序的经验和技巧已经全部被浓缩到了这么一个程序框架中,更何况这个框架是用我所见过的最优雅而简练的编程语言编写的。我对Java的兴趣戛然而止(虽然之后我还差不多用了一年的IntelliJ)。我开始热心地在我的博客上撰写有关Ruby和Rails的文章,并且不遗余力地在ThoughtWorks的里里外外宣传它们。结果,正如他们所说的,Ruby on Rails是件影响网络应用程序开发的大事记。
当我在2007年撰写这本书的时候,ThoughtWorks全球收入中的近一半来自于我所推荐的Rails的项目生意。他们特别成立了一个很大的部门专门从事基于Ruby的商业软件开发工作。他们的产品中包括CruiseControl.rb,它很荣幸地成为Ruby on Rails核心团队所选择的连续式整合服务系统。我猜CruiseControl.rb就是Aslak一直以来都想编写的系统。
Ruby on Rails
为什么有那么多深具企业经验的开发者爱上Ruby on Rails呢?在项目实施中,采用Java或者Microsoft技术的解决方案的复杂程度都难以让人接受。过度的复杂程度使个人失去对于项目的理解,同时大幅增加了团队间的沟通需求。此外,一味强调遵循设计模式加上对性能的执迷都使得使用那些平台的开发者很快失去了对于开发应用程序的兴趣。
Rails社区不存在此类压力。DHH(David Heinemeier Hansson)选择了一个让他感觉舒畅的语言。Rails的产生是因为他追求代码完美。类似这样的事情定下了Rails社区的基调。关于Rails的种种都充斥着主观成分。大家要么能“分享”这种愉悦要么便无法体会。只是选择了Rails和不选择的人之间没有恶意的寻衅,所有的只是温文尔雅的鼓励。
——Pat Maddox
Ruby很美妙,编写Ruby代码更是件美妙的事。我认识每一个选择Ruby语言的人都告诉我他们的工作比以前轻松开心了很多。就冲着这一点,Ruby和Rails正在不断动摇那些安于维持现状的程序员们,特别是在企业应用方面。在接触Rails之前,我习惯于从事那些要求反复而又和真实世界没什么关系的项目。我受够了在各种相似的代码框架中挑来选去进行整合,也受够了编写丑陋的代码。
相反,Ruby是一门美妙动态的高级语言。Ruby代码易读易写,因为它的代码类似人类语言的方式,更贴近于我们所要解决的问题。这种特别强的可读性带来了许多长期和短期的好处,因为程序代码迟早要被转入生产环境并且必须被维护人员彻底理解。
我的经验告诉我,和Java或者C#比起来,处理相同的问题,使用Ruby来编写程序代码量要少得多。从程序的长期维护角度来看,较小的代码库更易于维护。更重要的是长期维护被广泛认为是成功的软件项目中最大的成本。此外当出现问题时,较小的代码库更便于迅速找出问题所在,甚至是在不借助花哨的调试工具的情况下就能解决。
Rails的兴起和被主流软件世界的接受程度
和敏捷开发原则的出现一样,Rails所注重的是我们作为程序开发者的需求,而不是作为软件工程师的需求,更不是作为计算机科学家的需求。Rails通过竭力减少和程序开发无关的复杂性以便开发者紧紧把握住项目成功这个终极目标。使用Rails进行编程不仅让人享受到开发的乐趣,更增强人想要成功的信心!
Rails提供非常完整的平台性的工具和技巧,从而鼓励我们将精力全部放在实现项目的商业价值上。Ruby所秉持的“最少意外(Least Surprise)”原则已被完美地诠释在Rails那简单而优雅的设计之中。而且最好的是,Rails是一个完全免费的程序,这意味着当遇到其他程序框架都无法胜任的问题时,你可以自由地在Rails的源代码中找到解决问题的答案。
David曾偶尔表示出他对于Rails被主流软件世界的接受程度并不是特别感兴趣,因为那可能会伤害到早期用户所热爱的竞争势态。那些早期用户主要是从事网站设计和开发的个人和小团体,其中有很多来自于PHP世界。
被企业所采用
你尽可以称我为一个理想主义者,因为我始终相信即便是大型而保守的企业中的开发者,当他们有机会用到这样的工具时,也绝对会积极地希望让他们自己的动作变得更高效而且更具创新性。这就是为什么几年来越来越多的这类开发者转而投入Rails世界。
在那个项目中我们曾面临一个具有争议的抉择,不过最后我们的团队决定将我们的连续整合系统构建在Aslak的一个业余项目Damage Control的基础上。Damage Control是老旧的Cruise Control服务器的Ruby版本,是由我们的雇主公司Thought Works开发的。
问题是Damage Control当时还是一个半成品,而且和其他许多Ruby事物一样,它在Windows系统中兼容性不是很好。我已经记不得是什么原因,不过当时我们必须将它部署到一个陈旧的Windows 2000服务器上,而且那个服务器上还跑着一个StarTeam代码版本库(折腾!)。
Aslak需要帮助——在这之后的几个星期,我们没日没夜地进行结对编程的工作。对DamageControl的程序代码和Ruby的Win32程序代码库的C代码进行了大量改造。当时的我具有八年正规行业的Java开发经验,而且当时我特别喜欢使用IntelliJ IDE;但在那段时间,我对Ruby的痛恨不禁溢于言表。
当这个倍具压力的项目上线之后,我接手了另一个相对轻松的任务并转去ThoughtWorks的伦敦办公室工作。过了大概一个月的时间,Ruby再一次吸引了我的注意。当时我在很多朋友的博客上看到他们激动地讨论一个即将发布的网络程序框架,叫做Ruby on Rails。于是我决定再来试试Ruby,或许它并非那么糟糕吧。我很快就创新地为ThoughtWorks建立起一个供内部使用的社区网络系统。
在2005年初的那几周中,我的Rails第一次亲密接触让我完全转变了看法。经年累月以来我所学到的那些用于构建网络应用程序的经验和技巧已经全部被浓缩到了这么一个程序框架中,更何况这个框架是用我所见过的最优雅而简练的编程语言编写的。我对Java的兴趣戛然而止(虽然之后我还差不多用了一年的IntelliJ)。我开始热心地在我的博客上撰写有关Ruby和Rails的文章,并且不遗余力地在ThoughtWorks的里里外外宣传它们。结果,正如他们所说的,Ruby on Rails是件影响网络应用程序开发的大事记。
当我在2007年撰写这本书的时候,ThoughtWorks全球收入中的近一半来自于我所推荐的Rails的项目生意。他们特别成立了一个很大的部门专门从事基于Ruby的商业软件开发工作。他们的产品中包括CruiseControl.rb,它很荣幸地成为Ruby on Rails核心团队所选择的连续式整合服务系统。我猜CruiseControl.rb就是Aslak一直以来都想编写的系统。
Ruby on Rails
为什么有那么多深具企业经验的开发者爱上Ruby on Rails呢?在项目实施中,采用Java或者Microsoft技术的解决方案的复杂程度都难以让人接受。过度的复杂程度使个人失去对于项目的理解,同时大幅增加了团队间的沟通需求。此外,一味强调遵循设计模式加上对性能的执迷都使得使用那些平台的开发者很快失去了对于开发应用程序的兴趣。
Rails社区不存在此类压力。DHH(David Heinemeier Hansson)选择了一个让他感觉舒畅的语言。Rails的产生是因为他追求代码完美。类似这样的事情定下了Rails社区的基调。关于Rails的种种都充斥着主观成分。大家要么能“分享”这种愉悦要么便无法体会。只是选择了Rails和不选择的人之间没有恶意的寻衅,所有的只是温文尔雅的鼓励。
——Pat Maddox
Ruby很美妙,编写Ruby代码更是件美妙的事。我认识每一个选择Ruby语言的人都告诉我他们的工作比以前轻松开心了很多。就冲着这一点,Ruby和Rails正在不断动摇那些安于维持现状的程序员们,特别是在企业应用方面。在接触Rails之前,我习惯于从事那些要求反复而又和真实世界没什么关系的项目。我受够了在各种相似的代码框架中挑来选去进行整合,也受够了编写丑陋的代码。
相反,Ruby是一门美妙动态的高级语言。Ruby代码易读易写,因为它的代码类似人类语言的方式,更贴近于我们所要解决的问题。这种特别强的可读性带来了许多长期和短期的好处,因为程序代码迟早要被转入生产环境并且必须被维护人员彻底理解。
我的经验告诉我,和Java或者C#比起来,处理相同的问题,使用Ruby来编写程序代码量要少得多。从程序的长期维护角度来看,较小的代码库更易于维护。更重要的是长期维护被广泛认为是成功的软件项目中最大的成本。此外当出现问题时,较小的代码库更便于迅速找出问题所在,甚至是在不借助花哨的调试工具的情况下就能解决。
Rails的兴起和被主流软件世界的接受程度
和敏捷开发原则的出现一样,Rails所注重的是我们作为程序开发者的需求,而不是作为软件工程师的需求,更不是作为计算机科学家的需求。Rails通过竭力减少和程序开发无关的复杂性以便开发者紧紧把握住项目成功这个终极目标。使用Rails进行编程不仅让人享受到开发的乐趣,更增强人想要成功的信心!
Rails提供非常完整的平台性的工具和技巧,从而鼓励我们将精力全部放在实现项目的商业价值上。Ruby所秉持的“最少意外(Least Surprise)”原则已被完美地诠释在Rails那简单而优雅的设计之中。而且最好的是,Rails是一个完全免费的程序,这意味着当遇到其他程序框架都无法胜任的问题时,你可以自由地在Rails的源代码中找到解决问题的答案。
David曾偶尔表示出他对于Rails被主流软件世界的接受程度并不是特别感兴趣,因为那可能会伤害到早期用户所热爱的竞争势态。那些早期用户主要是从事网站设计和开发的个人和小团体,其中有很多来自于PHP世界。
被企业所采用
你尽可以称我为一个理想主义者,因为我始终相信即便是大型而保守的企业中的开发者,当他们有机会用到这样的工具时,也绝对会积极地希望让他们自己的动作变得更高效而且更具创新性。这就是为什么几年来越来越多的这类开发者转而投入Rails世界。
序言回到顶部↑
Rails不只是一个用于创建网络应用程序的编程代码框架,更是一个帮助思考网络应用程序的框架。Rails并不是力图面面俱到而平淡无奇的软件,相反它牺牲了面面俱到的灵活性以换得解决“大多数人花费大多数时间去做的大多数事情”——便捷。对于软件的设计者们而言,Rails就像一件紧身衣,它帮助你把全部精力投入到核心业务上去,并为你处理那些与业务无关的琐事。
要接受这种工作方式,不仅需要知道如何在Rails中做这些事情,而且更需要了解Rails为何如此为之。当理解这些“为什么”之后,你便能顺畅地使用这个程序框架进行工作而不是抗拒它。这并不意味着你必须接受某些选择,而是说你需要同意“采用约定”的这个原则。为了获得出众的开发效率,有些人可能不得不放弃一些工作中的个人癖好,开始学会放松并遵循Rails中的约定。
这是一本真正能够帮助你做到这些的书。不仅是因为本书是一部全面介绍Rails各功能的工具书,同时它为你开启一扇可以了解Rails的思想和灵魂的窗户——为什么我们会选择这些约定的方法来做事?又为什么我们不苟同一些已经被广泛使用的方式?本书还将讲述直接从帮助Rails成长的社区成员口中得知的Rails之所以能成为今天的Rails的故事。
学习如何在Rails中编写“Hello World”是一件每个人都能自己完成的易事,但是要了解和掌握Rails的全面形态可要困难得多。我衷心感谢Obie的工作,他使这本书成为读者学习和应用Rails的旅程中的好伙伴。愿你能喜欢此书。
——David Heinemeier Hansson
Ruby on Rails的创造者
要接受这种工作方式,不仅需要知道如何在Rails中做这些事情,而且更需要了解Rails为何如此为之。当理解这些“为什么”之后,你便能顺畅地使用这个程序框架进行工作而不是抗拒它。这并不意味着你必须接受某些选择,而是说你需要同意“采用约定”的这个原则。为了获得出众的开发效率,有些人可能不得不放弃一些工作中的个人癖好,开始学会放松并遵循Rails中的约定。
这是一本真正能够帮助你做到这些的书。不仅是因为本书是一部全面介绍Rails各功能的工具书,同时它为你开启一扇可以了解Rails的思想和灵魂的窗户——为什么我们会选择这些约定的方法来做事?又为什么我们不苟同一些已经被广泛使用的方式?本书还将讲述直接从帮助Rails成长的社区成员口中得知的Rails之所以能成为今天的Rails的故事。
学习如何在Rails中编写“Hello World”是一件每个人都能自己完成的易事,但是要了解和掌握Rails的全面形态可要困难得多。我衷心感谢Obie的工作,他使这本书成为读者学习和应用Rails的旅程中的好伙伴。愿你能喜欢此书。
——David Heinemeier Hansson
Ruby on Rails的创造者
【插图】
评论交流
共有5人开贴评论 6人参与评论 3人参与打分 查看
评价等级:



发表于:2010-5-6 17:25:00
不得不说这本书的翻译实在是太差了,翻译的人应该并不具备多少RoR的知识。我举个例子,49页第7行,
“具名路由的具体方法是使用名字(自定义的)调用映射对象方法,并用它取代通常的链接。”
原文是:
“The way you name a route is by calling a method on your mapper object with the name you want to use, instead of the usual connect”
意思是定义命名路由的时候应该用自己的名字取代通常的connect方法。其中map和connect都是程序里面的专有名词,居然也翻译了,要不是对照英文原文,真是很难看懂。
本来觉得看中文书会省力一些,看来还是要对照原文才好理解一些。
唉,又是不负责任的译者。
“具名路由的具体方法是使用名字(自定义的)调用映射对象方法,并用它取代通常的链接。”
原文是:
“The way you name a route is by calling a method on your mapper object with the name you want to use, instead of the usual connect”
意思是定义命名路由的时候应该用自己的名字取代通常的connect方法。其中map和connect都是程序里面的专有名词,居然也翻译了,要不是对照英文原文,真是很难看懂。
本来觉得看中文书会省力一些,看来还是要对照原文才好理解一些。
唉,又是不负责任的译者。
| 我要写评论 |
| 查看所有评论交流(共5条) |

点击看大图





加载中...