Rails 2.1 开发：敏捷Web开发与Rails第三版Beta

需积分: 3 73 浏览量更新于2024-08-02 收藏 8.4MB PDF 举报

"敏捷Web开发与Rails 3rd Edition Beta版" 《敏捷Web开发与Rails 3rd Edition Beta》是一本专为Rails 2框架编写的书籍，旨在帮助开发者利用敏捷方法构建高效、灵活的Web应用。该书在印刷时基于Rails 2.1版本进行了测试，确保代码兼容性。然而，值得注意的是，Rails的核心团队持续对Rails 2进行改进，这意味着在本书编写过程中，可能会有新的更新或不兼容性出现在后期的Rails版本中。书中的内容分为两个阶段：原有的Rails 1.2.6覆盖的内容和已迁移至Rails 2的内容。原始文本页面以灰色的页眉和页脚作为标记，而随着内容逐渐迁移到Rails 2，页眉颜色会变为红色。读者可以通过章节开头的更新状态表格了解哪些章节已经完成了向Rails 2的更新，特别是注意，很多章节的屏幕截图可能尚未更新，以反映Rails 2.1产生的结果。书中提到了EdgeRails，这是Rails开发者为了试验新功能和变化而提供的一种实验性代码版本。除非你主动安装EdgeRails，否则这些实验性的变更不会影响到你的应用。这使得开发者可以在正式版本发布之前，提前尝试和适应Rails的新特性。对于想要利用敏捷方法进行Web开发的读者，这本书将详细介绍如何利用Rails框架实现敏捷开发的原则和实践，包括快速迭代、用户反馈集成以及代码的可维护性。书中可能会涵盖模型-视图-控制器（MVC）架构、数据库设计、路由、控制器、视图、测试、部署等多个关键主题，并结合实际示例来帮助读者理解和应用这些概念。此外，读者还将了解到如何利用Rails的插件和gem扩展功能，提升开发效率。书中可能还会涉及TDD（测试驱动开发）和BDD（行为驱动开发）的实践，以及如何利用自动化测试确保代码质量和应用程序的稳定性。《敏捷Web开发与Rails 3rd Edition Beta》是Rails 2开发者的重要参考资料，它不仅提供了详尽的Rails框架知识，还展示了如何在不断变化的技术环境中采用敏捷方法进行高效开发。尽管书中的一些内容可能尚未完全更新到Rails 2.1，但它仍然为读者提供了宝贵的指导，帮助他们跟上Rails的发展步伐。

Chapter 1

Introd uction

Ruby on Rails i s a framewor k that makes it easier to develop, deploy, and

maintain web applications. During the months that followed its initial release,

Rails went from being an unknown toy to being a worldwide phenomenon. It

has won awards, and, more important, it has become the framework of choice

for the implementation of a wide range of so-called Web 2.0 ap plications. It

isn’t just trendy among hard-core hackers: many multinational companies a re

using Rails to create their web applications.

Why is that? There seem to be many rea sons.

First, there seemed to be a large number of developers who were frustrated

with the technologies they were using to create web applications. It didn’t seem

to matter whether they were using Java, PHP, or .NET—there w as a growing

sense that their job was just too damn hard. And then, suddenly, along came

Rails, and Rails is easier.

But easy on its own doesn’t cut it. We’re talking about professional developers

writing real-world web sites. They wanted to feel that the applications they

were developing would stand the test of time—that they were designed and

implemented usi ng modern, professional techniques. So these developers du g

into Rails and discovered it wasn’t just a tool for hacking out sites.

For example, all Rails a p p lications are implemented using the Model-View-

Controller (MVC) architecture. Java developers are used to frameworks such

as Tapestry and Struts, which are based on MVC. But Rails takes MVC further:

when you develop in Rails, there’s a place for each piece of code, and all the

pieces of your application interact in a standard way. It’s as if you start out

with the skeleton of an application already prepared.

Professional programmers write tests. And again, Rails delivers. All Rails appli-

cations have testing support baked right in. As you add functionality to the

Prepared exclusively for Vanilton

CHAPTER 1. INTRODUCTION 17

code, Rails automatically creates test st ubs for that functionality. The frame-

work makes it easy to test applications, a nd as a result Rails applications tend

to get tested.

Rails applications are written in Ruby, a modern, object-oriented scripting

language. Ruby is concise withou t being unintelligibly terse—you can express

ideas naturally and cleanly in Ruby code. This l eads to programs that are easy

to write and (just as importantly) ar e easy to read months later.

Rails takes Ruby to the limit, extending it in novel ways that make a pro-

grammer’s life easier. This makes our progra ms shorter and more readable.

It also allows us to perform tasks t hat would normally be done in exter nal

conﬁguration ﬁles inside the codebase instead. Thi s makes it far easier to see

what’s happening. The following code deﬁnes the model class for a project.

Don’t worry about the detai ls for now. Instead, just think about how much

information is being expressed in a few lines of code.

class Project < ActiveRecord::Base

belongs_to :portfolio

has_one :project_manager

has_many :milestones

has_many :deliverables, :through => :milestones

validates_presence_of :name, :description

validates_acceptance_of :non_disclosure_agreement

validates_uniqueness_of :short_name

end

Developers who came to Rails also found a strong philosophical underpinning.

The design of Rails was driven by a couple of key concepts: DRY and conven-

tion over conﬁguration. DRY stands for Don’t Repeat Yo u rself —every piece of

knowledge in a system should be expressed in just one place. Rails uses the

power of Ruby to bring that to life. You’ll ﬁnd very little duplication i n a Rails

application; you say what you need to say in one place—a place often sug-

gested by the conventions of the MVC architecture—and then move on. For

programmers used to other web frameworks, where a simple change to the

schema could involve them in half a dozen or more code changes, this was a

revelation.

Conventio n over conﬁguration is crucial, too. It means that Rail s has sensi-

ble defaults for just about every aspect of knitting together your application.

Follow the conventions, and you can wri te a Rails application using less code

than a ty p ical Java web application uses i n XML conﬁguration. If you need to

override the conventions, Ra ils makes that easy, too.

Developers coming to Rails found something else, too. Rails is new, and the

core team of developers understands the new Web. Rails isn’t playing catch-

up with the new de facto web standards: it’s helping deﬁne them. And Rails

Report erratum

this copy is (B1.3 printing, June 4, 2008)

Prepared exclusively for Vanilton

RAILS IS AGILE 18

makes it easy for developers to integrate features such as AJAX and RESTful

interfaces into their code: support is built in. (And if you’re not familar with

AJAX and REST interfaces, never fear—we’ll explain them la ter on.)

Developers are worried about deployment, too. They found that with Rails you

can depl oy successive releases of your application to any number of server s

with a single command (and roll them back equally easily should the rel ease

prove to be somewhat less than p erfect).

Rails was extracted from a real-world, commercial application. It turns out

that the best way to create a framework is to ﬁnd the central themes in a

speciﬁc application and then bottle them up in a generic foundation of code.

When you’re developing your Rails app lication, you’re starting with half of a

really good application already in place.

But there’s something el se to Rails—something that’s hard to descr ibe. Some-

how, it just feels right. Of course you’ll have to take our word for that until

you write some Rails applications for yourself (which should be in the next 45

minutes or so...). T hat’s what this book is all about.

1.1 Rails Is Agile

The title of this book is Agile Web Development with Rails. You may be sur-

prised to discover that we don’t have explicit sections on app lying agile pr ac-

tices X, Y, and Z to Rails coding.

The reason is both simple and subtle. Ag ility is part of the fabric of Rai ls.

Let’s look at the values expressed in the Agile M anifesto as a set of four pref-

erences.

Agile development favors the following.

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contra ct negotiation

• Responding to change over following a plan

Rails is all about individuals and interactions. There are no heavy toolsets,

no complex conﬁgurati ons, and no elaborate processes. There are just small

groups of developers, their favorite editors, and chunks of Ruby code. This

leads to transparency; what the developers do is reﬂected immediately in what

the customer sees. It’s an intrinsically interactive p rocess.

Rails doesn’t d enou nce documentati on. Rails makes it trivially easy to cre-

ate HTML documentation for your entir e codebase. But the Rails development

process isn’t driven by documents. You won’t ﬁnd 500-page speciﬁcations at

1. http://agilemanifesto.org/. Dave Thomas was one of the 17 authors of t his document.

Report erratum

this copy is (B1.3 printing, June 4, 2008)

Prepared exclusively for Vanilton

FINDING YOUR WAY AROUND 19

the heart of a Rails project. Instead, you’ll ﬁnd a group of users and develop-

ers jointly explor ing their need and the possible ways of answering that need.

You’ll ﬁ nd solutions that change as both the developers and users become

more experienced with the problems they’re tr ying to solve. You’ll ﬁnd a fra me-

work that delivers working software early in the development cycle. This soft-

ware may be rough around the edges, but it lets the users start to get a glimpse

of what you’ll be delivering.

In this way, Rails encourages customer collaboration. When customers see

just how quickly a Rails project can respond to change, they start to tr ust

that the team can deliver what’s required, not just what has been requested.

Confrontations are replaced by “What if?” sessi ons.

That’s all tied 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 uni t and functional testing, along

with support for test ﬁxtures and stubs during testing, gives developers the

safety net they need when making those changes. With a good set of tests in

place, changes are l ess nerve-wracking.

Rather than constantly trying to tie Rails processes to the agile principles,

we’ve decided to let the framework speak for itself. As you read through the

tutorial chapters, try to imagine you rself developing web applications this way:

working alongside your customers and jointly determining prioriti es and solu-

tions to problems. Then, as you read the deeper reference material in the back,

see how the underlying structure of Rails can enable you to meet your cus-

tomers’ needs faster and with less ceremony.

One last point about ag ility and Rails: although it’s probably unpr ofessional

to mention this, think how much fun the coding will be.

1.2 Finding Your Way Around

The ﬁrst two parts of this book are an i ntroduction to the concepts behind

Rails and an extended example—we build a simple online store. This is the

place to start if y ou’re looking to get a feel for Rai ls programming. In fact, most

folks seem to enjoy building the application along with the book. If you don’t

want to do a ll that typing, you can cheat and download the source code (a

compressed tar archive or a zip ﬁle).

2. http://www.pragprog.com/titles/rails3/code.html has the links for the downloads.

Report erratum

this copy is (B1.3 printing, June 4, 2008)

Prepared exclusively for Vanilton

FINDING YOUR WAY AROUND 20

The third part of the book, starting on page 237, is a detailed look at all the

functions and facilities of Rails. This is where you’ll go to ﬁnd out how to

use the various Ra ils components and how to deploy your Rails a p p lications

efﬁciently and safely.

Along the wa y, you’ll see various conventions we’ve adopted.

Live Code

Most of the code snippets we show come from full-length, r unning exam-

ples, which you can download. To help you ﬁnd your way, if a code listing

can be found in the download, there’ll be a bar above the snip p et (just

like the one here).

Download work/demo1/app/controller s/say_controller.rb

class SayController < ApplicationController

def hello

end

This contains the path to the code within the download. If you’re reading

the PDF version of this book and your PDF viewer supports hyperlinks,

you can click the bar, and the code should appear i n a browser window.

Some browsers (such as Safari) will mistakenly try to interpret some of

the templates as HTML. If this ha ppens, view the source of the page to

see the real source code.

Ruby Tips

Although you need to know Ruby to write Rails applications, we realize

that many folks reading this book will be learning both Ruby and Rails

at the same time. Appendix

A, on page 647, is a (very) brief introduction

to the Ruby language. When we use a Ruby-speciﬁc construct for the

ﬁrst time, we’ll cross-reference it to that appendix. For example, this

paragraph contains a gratuitous use of

:name, a Ruby symbol. I n the :name

֒→ page

649

margin, you’ll see an indication that symbols are explained on page 649.

If you don’t know Ruby, or if you need a quick refresher, you might want

to go read Appendix A, on page 647, before you go too much further.

There’s a lot of code in this book....

David Says...

Every now and then you’ll come across a David Says... sidebar. Here’s

where David Heinemeier Hansson gives you the real scoop on some par-

ticular aspect of Rails—rationales, tricks, recommendations, and more.

Because he’s the fellow who invented Rails, these are the sections to read

if you want to become a Rails pro.

Joe Asks...

Joe, the mythical devel oper, sometimes pops up to ask questions abou t

stuf f we talk about in the text. We answer these as we go along.

Report erratum

this copy is (B1.3 printing, June 4, 2008)

Prepared exclusively for Vanilton

剩余730页未读，继续阅读

j2ee2000

粉丝: 0
资源: 6

Rails 2.1 开发：敏捷Web开发与Rails第三版Beta

Agile Web Development With Rails 3rdEdition

Agile Web Development with Rails 3nd Edition Beta

Agile Web Development with Rails 3nd Edition Beta.pdf

agile web development with rails 3 edition

Agile Web Development with Rails 3nd 下载

Agile Web Development with Rails

Agile Web Development with Rails 3nd Edition .pdf

Agile Web Development with Rails for Rails 3.2

Agile Web Development with Rails 翻译

Agile Web Development with Rails 2nd

最新资源