Rails 2.1 敏捷Web开发

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

"Agile Web Development with Rails 3nd Edition Beta" 本书主要关注的是Rails框架的第二版，尽管在印刷时，最新的稳定版本是2.1。Rails是一个强大的Ruby框架，用于构建高效、灵活的Web应用。书中代码经过了对Rails 2.1版本的测试，确保与该版本兼容。 Rails版本的重要信息：书中原始内容基于Rails 1.2.6，随着更新，部分章节已经迁移到Rails 2。章节的灰色标题和页脚表示原始的Rails 1.2.6内容，而红色标题则表示已更新至Rails 2的内容。读者需要注意，尽管内容正在逐步更新，许多章节的截图可能还没有更新，以匹配Rails 2.1产生的结果。 Rails核心团队持续开发Rails 2，期间可能会有新的发布，这些新版本可能引入与早期Rails版本不兼容的变化。为了方便开发者试验这些新特性，Rails开发者提供了EdgeRails，这是一个讨论始于第244页的实验性代码渠道。EdgeRails不会自动影响到已经存在的应用，除非用户主动安装这个实验性的代码库。在使用本书时，读者需要了解以下几个关键知识点： 1. **Rails版本管理**：了解如何在不同的Rails版本间切换，以及如何处理版本升级可能带来的兼容性问题。 2. **Gem版本**：Rails是一个Gem包，理解如何通过Gemfile和bundle命令来管理依赖版本，特别是对于特定项目需要固定某个Rails版本的情况。 3. **Rails 2的新特性**：学习Rails 2相对于1.2.6的改进和新增功能，例如ActiveRecord的更新、ActionController的变化、模板系统的改进等。 4. **应用程序迁移**：掌握将基于Rails 1.2.6的应用迁移到Rails 2的步骤，包括代码修改、数据库迁移和配置调整。 5. **EdgeRails和开发模式**：理解EdgeRails的概念，如何获取并使用它来跟踪Rails的最新进展，以及如何在开发环境中安全地尝试这些前沿特性。 6. **版本控制和版本回滚**：了解使用Git或其他版本控制系统的重要性，以便在遇到问题时能够回滚到之前的代码状态。 7. **错误调试和兼容性测试**：在应用新的Rails版本或特性时，学会如何调试代码，确保应用的稳定性和兼容性。 8. **社区和文档**：利用Rails社区资源，如Stack Overflow、Rails Guides和官方文档，解决升级过程中遇到的问题。 9. **最佳实践**：随着Rails的进化，开发最佳实践也在不断变化。书中更新的内容应反映出这些最佳实践，帮助读者提升开发效率和应用质量。 10. **持续集成和自动化测试**：学习如何使用如Rake、RSpec和Cucumber等工具进行自动化测试，确保代码质量，并适应Rails版本更新。通过本书，读者不仅可以学习到Rails 2的核心概念和技术，还能了解到如何在一个快速发展的框架环境中保持应用的更新和优化。同时，读者应密切关注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页未读，继续阅读

yuerengu

粉丝: 1
资源: 2

Rails 2.1 敏捷Web开发

Agile Web Development with Rails 3nd Edition Beta.pdf

Agile Web Development with Rails, 2nd Edition

Agile.Web.Development.with.Rails.3nd.Edition.Beta.rar

Rails 2nd Edition: Agile Web Development抢先读

ruby on rails 英文资料搜集

Rails 2.0 敏捷Web开发英文Beta版指南

Rails 2.1 敏捷Web开发实战

Rails 2.1 敏捷Web开发指南

Rails 2.1 敏捷Web开发：权威指南

潮流计算+二阶锥松弛+对偶形式的matlab源码+对偶理论说明文档.zip

最新资源