Agile Web Development with Rails 翻译(一)

Agile Web Development with Rails 翻译(一)

第一章 前言

 

Ruby on Rails 是个更易于开发，配置，和管理Web应用程序的框架。

当然，所有的Web框架都会这么说。但Rails与它们的区别是什么呢？我们可以从技术做些回答。

一种途径是查看它的体系。过去，很多开发者已迁到MVC体系来开发Web应用程序。他们发现MVC可帮助它们更清晰地构造它们应用程序。(我们在下一章更祥细地讨论MVC。)Java框架如Tapestry和Structs就是基于MVC的。Rails也是个MVC框架。当你在Rails内开发时，你的每个代码，应用程序的每个部分都遵循标准的方式。也就是说，你在一个被事先准备好的框架内开始的。

回答这个问题的另一个途径是看程序语言。Rails应用程序是由模块化的，面向对象的脚本语言Ruby写成的。Ruby相当简练—你可自动地，清晰地用Ruby代码来表达你的思想。这让程序更易写并在日后也可以容易地阅读。

Ruby也有与Lisp代码类似的程序风格。它可容易地创建像表达式一样的方法。有些人使用元程序，但我们只关心对我们有用的部分。它使我们的程序简短并更易于阅读。它也允许我们完成在外部配置文件内的代码的任务。可更方便地看到运行的工作情况。下面代码为个工程定义了模块类。现在不要关心细节。相反，只要想下面代码行表达的信息就可以了。

class Project < ActiveRecord::Base

belongs_to :portfolio

has_one :project_manager

has_many :milestones

has_and_belongs_to_many :categories

validates_presence_of :name, :description

validates_acceptance_of :non_disclosure_agreement

validates_uniqueness_of :key

end

或者我们可以思考地观察它。Rails的设计由一组关键的概念来驱动着：DRY与配置约定(Convention over configuration)。DRV—系统内每个部分应该只在一个地方被表达。Rails使用强大的Ruby开始自己的生命。你会发现在Rails应用程序中少有重复；你在一个地方说你需要什么—这个地方通常由MVC体系来暗示。

配置约定也是至关重要的。它意味着Rails能判断出你的应用程序交织在一起的每个部分的缺省值。下面是约定，并且你可以用比使用XML配置的，典型的Java Web应用程序更少的代码来写一个Rails应用程序。如果你想覆写这些约定，Rails也可很容易地做到。

我们也要提一下Rails包括完整的支持Web服务的材料，接受邮件，AJAX(高级交互式Web应用程序)，完整的单元测试框架(包括对mock对象的透明支持)，和对开发，测试，生产环境的隔离。

或者我们谈论Rails具有的代码产生器。它们产生Ruby代码框架，然后由你填充应用程序的逻辑部分。

最后，Rails的区别是源于它的起源—Rails是被精选出来的商业应用程序。它倾向于创建一个框架的最好途径是找到特定应用程序的中心主题，然后在平常的代码基础内使用它们。当你开发你的Rails应用程序时，你是在现有的一个很不错的应用程序上开始的。

但是有关Rails的有些事情描述起来很困难。不会知道原因，只是感觉到这是对的。当然，你必须接受我们说话，直到你可以自己写一些Rails应用程序之前(应该是下个45分种或更多…)。这就是本书能谈的所有东西。

 

-----------------------------------------------------------------------------------

Dave喜欢Rails的十个主要原因

------------------------------------------------------------------------------------------

1. 可敏捷地进行Web开发。

2. 可以创建干净，整洁的Web页面。

3. 只关注于创建应用程序，而不是框架的什么东西。

4. 方便地管理应用程序的增长。

5. 可更大限度地满足客户的要求。

6. 内建的测试容易使用。

7. 立即反应：在浏览器上可编辑代码，及时刷新所有的更改。

8. 元程序(Metaprogramming)意味着我可以在真正的高级别上编程。

9. 代码产生器可让我们事半功倍。

10. 不需要XML!

-------------------------------------------------------------------------------

 

1.1 Rails 是敏捷的

 

本书的标题是Agile Web Development with Rails。那么你可能会惊讶，我们没有明确地将Rails代码区分成X,Y,和Z部分。

这是因为两者即简单又微秒。Rails构造的一部分就是敏捷。

让我们看看在Agile Manifesto网页上，有一组四个参数的状态值，就是下面敏捷开发的好处。

1、单独地和交互式的处理过程及工具。

2、开发软件有全面的，广泛的文档。

3、合约协议上的消费者合作。

4、Responding to change over following a plan

Rails的所有部分都是单独的和可交互的。没有笨重的工具集，没有复杂的配置，也没有难懂的程序。只有少数开发者，它们喜爱的编辑器，和一组Ruby代码。这会产生这样的透明度，开发者做的事情会立即被反射，并使用户看到所做的事情。这是根本的交互式过程。

Rails的文档无可指责。Rails使它可轻易地为你代码创建HTML文档。但是Rails开发处理并不受文档驱动。在Rails的工程中，你几乎找不到500页以上说明书。相反，你会发现一组用户和开发者会共同地探究它们的需要，以及对这个需要的可能的处理方式。你也会发现开发者和用户会变得对解决它们曾试着解决的问题更有经验。你可以在开发周期内找到早期的软件框架。这个软件可能粗糙但实用，它让用户一接触它就知道你拿来的是什么。

Rails以这种方式鼓励消费者协作。当消费者看到Rails工程如何快速地响应修改时，他们开始相信我们可以完成他们想要的东西，而不只是它们要求的东西。Confrontations are replaced by “What if?” sessions.

That’s all tied back to the idea of being able to respond to change. The strong, almost obsessive, way that Rails honors the DRY principle means that changes to Rails applications impact a lot less code than the same changes would in other frameworks. And since Rails applications are written in Ruby, where concepts can be expressed accurately and concisely, changes tend to be localized and easy to write. The deep emphasis on both unit and functional testing, along with support for test fixtures and mock objects, gives developers the safety net they need when making those changes. With a good set of tests in place, changes are less nerve-wracking.

Rather than constantly trying to tie Rails processes to the agile principles, we’ve decided to let the framework speak for itself. 就像在此书读到的那样，在你脑中想像以这种方式开发你自己的Web应用程序：与你的客户工作在一起，并共同决定应该优先解决的问题。然后，你回过头来看参考资料，看Rails的基础结构如何可使你快速地解决你客户的问题。

One last point about agility and Rails: although it’s probably unprofessional to mention this, think how much fun the coding will be.

 

1.2 寻找你自己的学习方式

 

本书比我们想像的要厚一些。回过头看看，它比我们曾写的两本书要清晰得多：一个教程和一个Rails的细节指南。

本书的前两部分是对Rails背后概念的一些介绍，并还有个例子—我们构建了一个简单的在线商店。如果你想更多地感觉Rails程序，可从个地方开始。事实上，大多数人更喜欢依照书上来构建应用程序。如果你不想输入所有东西，你可以下载源码。

本书173页开始的第三部分，是Rails的所有工具和函数的细节。在哪里你可以找到Rails各种组成的用法以及如何有效地，安全地配置你的Rails应用程序。

依据这种方式，你会看到我们采用的各种约定。

活动代码：

我们提供大多数完整的代码片断，你可下载并运行的例子。如果列出代码可下载，我们会在页边缘标记它。

class SayController < ApplicationController

end

Turn to the cross-reference starting on page 512, look up the corresponding number, and you’ll find the name of the file containing that piece of code. If you’re reading the PDF version of this book, and if your PDF viewer supports hyperlinks, you can click on the marker in the margin and the code should appear in a browser window. Some browsers (such as Safari) will mistakenly try to interpret some of the templates as HTML. If this happens, view the source of the page to see the real source code.

Ruby 提示：

虽然你需要知道用于写Rails应用程序的Ruby，我们认识到，读这本书的很多将同时即学Ruby也学Rails。467页的附录A是对Ruby语言的个简短介绍。当我们第一次使用特定的Ruby结构时，我们将交叉引用附录内的东西。例如，这一段包含了使用:name，一个Ruby符号的理由。按页边缘的指示你可以469页找到有关符号说明。如果你不了解Ruby，或者如果你需要一个快速参考，你可能想在接触更多的特性之前读467页附录A。那儿有本书的大量代码…

David 说...

现在和以后你会经常遇到David说…注释。David Heinemeier Hansson会给你一些Rails的具体特征的解说—基本原理，技巧，推荐，等等。

Joe 问...

Joe, 是个虚构的开发者，有时候会提出文章内我们谈到东西的一些问题，我们会试着回答这些问题。

本书不是Rails的参考手册。我们在文章中通过例子显示它的大多数模型和方法，但我们不能在上百页中列出API。我们这么做的理由是—你安装Rails时，你就在哪儿得到了文档，它生成文档比本书的更详细。如果你使用RubyGems(我们推荐你用它)来安装Rails，简单地启动Gem文档服务(使用命令gem_server)，然后你就可以通过在浏览器中输入http://localhost:8808来访问Rails的API了。

 

Rails 的版本

 

本书的文档是Rails1.0，它是在2005年中旬才可用的。尽管本书第一次开印是2005年六月。为了更及时，本书的API多用于Rails1.0。代码在0.13和1.0上测试过。

 

1.3 感谢

 

This book turned out to be a massive undertaking. It would never have happened without an enormous amount of help from the Ruby and the Rails communities. It’s hard to list everyone who contributed, so if you helped out but your name doesn’t appear here, please know that it’s a simple oversight.

This book had an incredible group of reviewers—between them, they generated over 6 megabytes of comments. So, heartfelt thanks to

Alan Francis, Amy Hoy, Andreas Schwarz, Ben Galbraith, Bill Katz,

Carl Dearmin, Chad Fowler, Curt Micol, David Rupp, David Vincelli,

Dion Almaer, Duane Johnson, Erik Hatcher, Glenn Vanderburg,

Gunther Schmidl, Henri ter Steeg, James Duncan Davidson,

Johannes Brodwall, John Harechmak, John Johnson, Justin Forder,

Justin Gehtland, Kim Shrier, Krishna Dole, Leon Breedt,

Marcel Molina Jr., Michael Koziarski, Mike Clark, Miles K. Forrest,

Raymond Brigleb, Robert Rasmussen, Ryan Lowe, Sam Stephenson,

Scott Barron, Stefan Arentz, Steven Baker, Stian Grytøyr,

Tait Stevens, Thomas Fuchs, Tom Moertel, and Will Schenk.

Rails was evolving as the book was coming together. As a result, the good folks in the Rails core team spent many hours answering Dave’s questions and generally sympathizing. (They also spent many hours tormenting me by changing stuff I’d just documented, but we won’t go into that here.) A big thank you to

Jamis Buck (minam), Jeremy Kemper (bitsweat),

Marcel Molina Jr, (noradio), Nicholas Seckar (Ulysses),

Sam Stephenson (sam), Scott Barron (htonl),

Thomas Fuchs (madrobby), and Tobias Lütke (xal).

Nathan Colgate Clark responded to a plea on the Rails mailing list and produced the wonderful image we use for the David Says... boxes.

Justin Forder did a great job of fixing up Dave’s anemic style sheets for the Depot application.

Thousands of people participated in the beta program for this book. Thank you all for taking the chance. Hundreds of these people took time to enter comments and errata on what they read. This book is better for it.

Last, but by no means least, we’d like to thank the folks who contributed the specialized chapters to the book: Leon Breedt, Mike Clark, Thomas Fuchs, and Andreas Schwarz.

 

From Dave Thomas

 

My family hasn’t seen me for the last eight months. For their patience, support, and love, I’m forever grateful. Thank you Juliet, Zachary, and Henry.