Rails for Java Developers phần 2 pdf

RUNNING THE SAMPLES 31

It is possible to type longer blocks, such as this three-line if...end block:

irb(main):002:0> if true

irb(main):003:1> puts "tautology"

irb(main):004:1> end

tautology

=> nil

If you make as many typing mistakes as we do, you can also paste

multiple lines of code into irb. When code starts to be long enough that

it is unwieldy to enter into irb, you will want to switch to full Ruby

programs.

Running Ruby Samples

All the Ruby samples for the book are from the rails_xt/samples direc￾tory, unless otherwise noted in the text. So, if you see the following

command:

$ ruby foo.rb

you can execute the same command within the rails_xt/samples directory

after you unzip the sample code.

Running Rails Samples

The samples include a Rails application in the rails_xt directory. All Rails

commands should be run from this directory, unless otherwise noted.

When you see a command that begins with script, such as script/console

or script/server, run that command from the rails_xt directory.

The script/console command is particularly important. It gives you an

interactive Ruby shell with Rails and your application’s environment

already loaded. Try running script/console from the rails_xt directory in

the sample code.

$ script/console

Loading development environment.

>> puts "Hello"

Hello

This is just like irb, except you can also now call Rails API methods. For

example, you could ask what database Rails is using:

>> ActiveRecord::Base.connection.current_database

=> "rails4java_development"

The default prompt in script/console is >>. When you see this prompt in

the book, you should be able to run the same code using script/console

in the rails_xt directory.

RAILS ENVIRONMENTS 32

Running the Unit Tests

We wrote much of the code in this book as exploration tests. Exploration exploration tests

tests are unit tests written for the purpose of learning, teaching, and

exploring. Sample code should be tested for the same reason people

unit test anything else: It is easy for us (and you!) to quickly verify that

the code works correctly.

You don’t need to run the unit tests to follow along in the book (except

in the testing chapter!), and we typically do not clutter the prose by

including them. For example, here is the code from Section 4.8, Pre￾venting the N+1 Problem, on page 130, demonstrating a solution to the

N+1 problem in Hibernate:

Download code/hibernate_examples/src/TransactionTest.java

Criteria c = sess.createCriteria(Person.class)

.setFetchMode("quips", FetchMode.JOIN);

Set people = new HashSet(c.list());

That’s the code you will see in the book, which demonstrates the point

being made. Notice that the listing begins with the filename. If you go

to that file in the sample code, you will find the code is followed imme￾diately by assertions that prove the code works as intended:

assertEquals(2, people.size());

sess.close();

for (Iterator iterator = people.iterator(); iterator.hasNext();) {

Person p = (Person) iterator.next();

assertEquals(25, p.getQuips().size());

}

For more about exploration testing, also known as learning tests, see learning tests

“How I Learned Ruby”11 and “Test Driven Learning.”12

1.7 Rails Environments

Web applications run in three distinct environments:

• In a development environment, there is a developer present. Code

and even data schemas tend to change rapidly and interactively.

Data is often crufted up by the developer, such as John Smith at

Foo Street.

11. http://www.clarkware.com/cgi/blosxom/2005/03/18#RLT1

12. http://weblogs.java.net/blog/davidrupp/archive/2005/03/test_driven_lea.html

RAILS ENVIRONMENTS 33

• In a test environment, automated tests run against prepackaged

sample data. A developer may or may not be present. Data sche￾mas are regularly trashed and rebuilt to guarantee a consistent

starting state for the tests.

• In a production environment, code and schemas change much

more rarely. The database data is real and valuable, and develop￾ers are rarely present.

In Java web frameworks, environments have historically been ad hoc:

Each team evolves its own, using a collection of scripts and Ant tasks

to manage environments and move code and data between them.

In Rails, environments are a first-class concept. Each application starts

life with the three environments in place. Rails environments are used

to select databases, log file destinations, policies for loading code, and

more. Here are some of Rails’ environmental defaults:

Development:

• The log file is log/development.log.

• The database is {appname}_development.

• The breakpoint server is enabled.

• Web pages show error stack traces.

• Classes reload for each page.

Test:

• The log file is log/test.log.

• The database is {appname}_test.

• The breakpoint server is disabled.

• Web pages show generic error messages.

• Classes load once at start-up.

Production:

• The log file is log/production.log.

• The database is {appname}_production.

• The breakpoint server is disabled.

• Web pages show generic error messages.

• Classes load once at start-up.

You can change environmental defaults by editing the appropriate envi￾ronment file. Environment files are named for the environment they

control, such as config/environments/development.rb for the development

environment. (You can even create new environments simply by adding