Agile Web Development with Rails A Pragmatic

Guide Second Edition Dave Thomas pdf download

https://ebookname.com/product/agile-web-development-with-rails-a-
pragmatic-guide-second-edition-dave-thomas/

Get Instant Ebook Downloads – Browse at https://ebookname.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Agile Web Development with Rails 5 1 1st Edition Sam

Ruby

https://ebookname.com/product/agile-web-development-with-
rails-5-1-1st-edition-sam-ruby/

Ruby on Rails Tutorial Learn Web Development with Rails

2nd Edition Michael Hartl

https://ebookname.com/product/ruby-on-rails-tutorial-learn-web-
development-with-rails-2nd-edition-michael-hartl/

Programming Elixir Functional Concurrent Pragmatic Fun

1st Edition Dave Thomas

https://ebookname.com/product/programming-elixir-functional-
concurrent-pragmatic-fun-1st-edition-dave-thomas/

Not Just Tacos A Journey Into the World of Authentic

Latin American Cuisine First Edition Shirley Solis

https://ebookname.com/product/not-just-tacos-a-journey-into-the-
world-of-authentic-latin-american-cuisine-first-edition-shirley-
solis/
Quality Equity Autonomy 1st Edition Lee Hwok Aun

https://ebookname.com/product/quality-equity-autonomy-1st-
edition-lee-hwok-aun/

Kidney Diseases and Hypertension Part II An Issue of

Primary Care Clinics in Office Practice The Clinics
Internal Medicine Pt 2 1st Edition Edgar V. Lerma Md
Facp Fasn Faha
https://ebookname.com/product/kidney-diseases-and-hypertension-
part-ii-an-issue-of-primary-care-clinics-in-office-practice-the-
clinics-internal-medicine-pt-2-1st-edition-edgar-v-lerma-md-facp-
fasn-faha/

PPL Book 3 Navigation 2nd edition Cae Oxford Aviation

[Cae Oxford Aviation]

https://ebookname.com/product/ppl-book-3-navigation-2nd-edition-
cae-oxford-aviation-cae-oxford-aviation/

Dungeons Dragons For Dummies 1st Edition Bill Slavicsek

https://ebookname.com/product/dungeons-dragons-for-dummies-1st-
edition-bill-slavicsek/

The Last Kingdom 3rd Edition Berry

https://ebookname.com/product/the-last-kingdom-3rd-edition-berry/
Investing in Emerging Markets The Rules of the Game 1st
Edition William Gamble

https://ebookname.com/product/investing-in-emerging-markets-the-
rules-of-the-game-1st-edition-william-gamble/
 Important Information
About Rails Versions
Rails is an evolving framework. The core Rails developers are continually
making changes, adding new features, fixing bugs, and so on. Periodically
they package up the latest version of Rails into a release. These releases are
then available to application developers as RubyGems.

This book is written for Rails 1.2.

As the book is going to press the core team have created the codebase for
Rails 1.2. However, they have not yet packaged it into a gem. This gives us a
bit of a problem. We want the book to reflect all the latest and greatest Rails
features, but we also know that it is hard for folks to jump through the hoops
required to get the so-called Edge version of Rails installed on their systems.
And until a gem is available, the 1.2 features are only available in Edge Rails.

Now, it may well be that by the time you get your hands on this book, the
Rails 1.2 gem is out. It’s easy to find out. After you’ve installed Rails (as
described in Chapter 3, Installing Rails, on page 31), bring up a command
prompt and enter rails -v. If it reports “Rails 1.2” or later, you’re fine.

If instead you see something like “Rails 1.1.6,” you’ll need to update to get
the code in this book to run. We’ve prepared a snapshot of the Rails frame-
work code that we used when writing this book. You can install it in your
own Rails applications as a temporary measure until 1.2 is released.

• Create your application normally. You’ll find that it will contain a direc-
tory called vendor

• Download http://media.pragprog.com/titles/rails2/code/rails.zip into your

application’s vendor directory and unzip it. It should create a new direc-
tory called rails

• In your application’s top-level directory, issue the command

rake rails:update

Once Rails 1.2 is released, you can install it and remove the directory tree
vendor/rails from your applications.

The version of Rails from our web site is not an official release, and should
not be used in production applications.

Dave Thomas
Agile Web Development with Rails
Second Edition

Dave Thomas
David Heinemeier Hansson

Leon Breedt
with
Mike Clark
James Duncan Davidson
Justin Gehtland
Andreas Schwarz

The Pragmatic Bookshelf

Raleigh, North Carolina Dallas, Texas
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in this book, and The Pragmatic Program-
mers, LLC was aware of a trademark claim, the designations have been printed in initial capital
letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Program-
ming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers,
LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no
responsibility for errors or omissions, or for damages that may result from the use of information
(including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better
software and have more fun. For more information, as well as the latest Pragmatic titles, please
visit us at

http://www.pragmaticprogrammer.com

Copyright © 2007 The Pragmatic Programmers LLC.

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any
form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the
prior consent of the publisher.

Printed in the United States of America.

ISBN-10: 0-9776166-3-0
ISBN-13: 978-0-9776166-3-3
Printed on acid-free paper with 85% recycled, 30% post-consumer content.
P2.00 printing, January 15, 2007
Version: 2007-1-8
 Contents
Preface to the Second Edition 12

1 Introduction 14
1.1 Rails Is Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Finding Your Way Around . . . . . . . . . . . . . . . . . . . . . 17
1.3 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Part I—Getting Started 21

2 The Architecture of Rails Applications 22

2.1 Models, Views, and Controllers . . . . . . . . . . . . . . . . . . 22
2.2 Active Record: Rails Model Support . . . . . . . . . . . . . . . . 25
2.3 Action Pack: The View and Controller . . . . . . . . . . . . . . 29

3 Installing Rails 31
3.1 Your Shopping List . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Installing on Mac OS X . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Installing on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Development Environments . . . . . . . . . . . . . . . . . . . . 36
3.6 Rails and Databases . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Keeping Up-to-Date . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.8 Rails and ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Instant Gratification 43
4.1 Creating a New Application . . . . . . . . . . . . . . . . . . . . . 43
4.2 Hello, Rails! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Linking Pages Together . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 What We Just Did . . . . . . . . . . . . . . . . . . . . . . . . . . 59
 CONTENTS 6

Part II—Building an Application 61

5 The Depot Application 62

5.1 Incremental Development . . . . . . . . . . . . . . . . . . . . . 62
5.2 What Depot Does . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Let’s Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Task A: Product Maintenance 68

6.1 Iteration A1: Get Something Running . . . . . . . . . . . . . . 68
6.2 Iteration A2: Add a Missing Column . . . . . . . . . . . . . . . 79
6.3 Iteration A3: Validate! . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4 Iteration A4: Prettier Listings . . . . . . . . . . . . . . . . . . . 85

7 Task B: Catalog Display 94

7.1 Iteration B1: Create the Catalog Listing . . . . . . . . . . . . . 94
7.2 Iteration B2: Add a Page Layout . . . . . . . . . . . . . . . . . . 98
7.3 Iteration B3: Use a Helper to Format the Price . . . . . . . . . 100
7.4 Iteration B4: Linking to the Cart . . . . . . . . . . . . . . . . . 100

8 Task C: Cart Creation 104

8.1 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.2 Iteration C1: Creating a Cart . . . . . . . . . . . . . . . . . . . . 107
8.3 Iteration C2: A Smarter Cart . . . . . . . . . . . . . . . . . . . . 110
8.4 Iteration C3: Handling Errors . . . . . . . . . . . . . . . . . . . 113
8.5 Iteration C4: Finishing the Cart . . . . . . . . . . . . . . . . . . 118

9 Task D: Add a Dash of AJAX 122

9.1 Iteration D1: Moving the Cart . . . . . . . . . . . . . . . . . . . 123
9.2 Iteration D2: An AJAX-Based Cart . . . . . . . . . . . . . . . . 128
9.3 Iteration D3: Highlighting Changes . . . . . . . . . . . . . . . . 131
9.4 Iteration D4: Hide an Empty Cart . . . . . . . . . . . . . . . . . 133
9.5 Iteration D5: Degrading If Javascript Is Disabled . . . . . . . . 137
9.6 What We Just Did . . . . . . . . . . . . . . . . . . . . . . . . . . 138

10 Task E: Check Out! 140

10.1 Iteration E1: Capturing an Order . . . . . . . . . . . . . . . . . 140

11 Task F: Administration 155

11.1 Iteration F1: Adding Users . . . . . . . . . . . . . . . . . . . . . 155
11.2 Iteration F2: Logging In . . . . . . . . . . . . . . . . . . . . . . . 163
11.3 Iteration F3: Limiting Access . . . . . . . . . . . . . . . . . . . . 166
11.4 Iteration F4: A Sidebar, More Administration . . . . . . . . . . 168
 CONTENTS 7

12 Task G: One Last Wafer-Thin Change 175

12.1 Generating the XML Feed . . . . . . . . . . . . . . . . . . . . . . 175
12.2 Finishing Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

13 Task T: Testing 185

13.1 Tests Baked Right In . . . . . . . . . . . . . . . . . . . . . . . . 185
13.2 Unit Testing of Models . . . . . . . . . . . . . . . . . . . . . . . 186
13.3 Functional Testing of Controllers . . . . . . . . . . . . . . . . . 198
13.4 Integration Testing of Applications . . . . . . . . . . . . . . . . 213
13.5 Performance Testing . . . . . . . . . . . . . . . . . . . . . . . . . 221
13.6 Using Mock Objects . . . . . . . . . . . . . . . . . . . . . . . . . 225

Part III—The Rails Framework 228

14 Rails in Depth 229

14.1 So, Where’s Rails? . . . . . . . . . . . . . . . . . . . . . . . . . . 229
14.2 Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . 229
14.3 Rails Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 238
14.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . 241
14.5 Logging in Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
14.6 Debugging Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
14.7 What’s Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

15 Active Support 248

15.1 Generally Available Extensions . . . . . . . . . . . . . . . . . . 248
15.2 Enumerations and Arrays . . . . . . . . . . . . . . . . . . . . . 249
15.3 String Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 250
15.4 Extensions to Numbers . . . . . . . . . . . . . . . . . . . . . . . 252
15.5 Time and Date Extensions . . . . . . . . . . . . . . . . . . . . . 253
15.6 An Extension to Ruby Symbols . . . . . . . . . . . . . . . . . . 255
15.7 with_options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
15.8 Unicode Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

16 Migrations 263
16.1 Creating and Running Migrations . . . . . . . . . . . . . . . . . 264
16.2 Anatomy of a Migration . . . . . . . . . . . . . . . . . . . . . . . 266
16.3 Managing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
16.4 Data Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
16.5 Advanced Migrations . . . . . . . . . . . . . . . . . . . . . . . . 278
16.6 When Migrations Go Bad . . . . . . . . . . . . . . . . . . . . . . 280
16.7 Schema Manipulation Outside Migrations . . . . . . . . . . . . 281
16.8 Managing Migrations . . . . . . . . . . . . . . . . . . . . . . . . 282
 CONTENTS 8

17 Active Record: The Basics 284

17.1 Tables and Classes . . . . . . . . . . . . . . . . . . . . . . . . . 285
17.2 Columns and Attributes . . . . . . . . . . . . . . . . . . . . . . 285
17.3 Primary Keys and IDs . . . . . . . . . . . . . . . . . . . . . . . . 289
17.4 Connecting to the Database . . . . . . . . . . . . . . . . . . . . 291
17.5 CRUD—Create, Read, Update, Delete . . . . . . . . . . . . . . . 296
17.6 Aggregation and Structured Data . . . . . . . . . . . . . . . . . 314
17.7 Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

18 Active Record: Relationships between Tables 324

18.1 Creating Foreign Keys . . . . . . . . . . . . . . . . . . . . . . . . 325
18.2 Specifying Relationships in Models . . . . . . . . . . . . . . . . 327
18.3 belongs_to and has_xxx Declarations . . . . . . . . . . . . . . . 329
18.4 Joining to Multiple Tables . . . . . . . . . . . . . . . . . . . . . 344
18.5 Self-referential Joins . . . . . . . . . . . . . . . . . . . . . . . . 354
18.6 Acts As . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
18.7 When Things Get Saved . . . . . . . . . . . . . . . . . . . . . . . 359
18.8 Preloading Child Rows . . . . . . . . . . . . . . . . . . . . . . . 361
18.9 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

19 Active Record: Object Life Cycle 364

19.1 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
19.2 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
19.3 Advanced Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 381
19.4 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

20 Action Controller: Routing and URLs 393

20.1 The Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
20.2 Routing Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 394

21 Action Controller and Rails 425

21.1 Action Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
21.2 Cookies and Sessions . . . . . . . . . . . . . . . . . . . . . . . . 436
21.3 Flash—Communicating between Actions . . . . . . . . . . . . 446
21.4 Filters and Verification . . . . . . . . . . . . . . . . . . . . . . . 448
21.5 Caching, Part One . . . . . . . . . . . . . . . . . . . . . . . . . . 456
21.6 The Problem with GET Requests . . . . . . . . . . . . . . . . . 463
 CONTENTS 9

22 Action View 466

22.1 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
22.2 Using Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
22.3 Helpers for Formatting, Linking, and Pagination . . . . . . . . 474
22.4 How Forms Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
22.5 Forms That Wrap Model Objects . . . . . . . . . . . . . . . . . 483
22.6 Custom Form Builders . . . . . . . . . . . . . . . . . . . . . . . 495
22.7 Working with Nonmodel Fields . . . . . . . . . . . . . . . . . . . 499
22.8 Uploading Files to Rails Applications . . . . . . . . . . . . . . . 502
22.9 Layouts and Components . . . . . . . . . . . . . . . . . . . . . 506
22.10 Caching, Part Two . . . . . . . . . . . . . . . . . . . . . . . . . . 514
22.11 Adding New Templating Systems . . . . . . . . . . . . . . . . . 519

23 The Web, V2.0 522

23.1 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
23.2 Script.aculo.us . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
23.3 RJS Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
23.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

24 Action Mailer 568

24.1 Sending E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
24.2 Receiving E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
24.3 Testing E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

25 Web Services on Rails 584

25.1 What AWS Is (and What It Isn’t) . . . . . . . . . . . . . . . . . . 584
25.2 The API Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 585
25.3 Dispatching Modes . . . . . . . . . . . . . . . . . . . . . . . . . 590
25.4 Using Alternate Dispatching . . . . . . . . . . . . . . . . . . . . 591
25.5 Method Invocation Interception . . . . . . . . . . . . . . . . . . 593
25.6 Testing Web Services . . . . . . . . . . . . . . . . . . . . . . . . 595
25.7 Protocol Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

Part IV—Secure and Deploy Your Application 599

26 Securing Your Rails Application 600

26.1 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
26.2 Creating Records Directly from Form Parameters . . . . . . . 602
26.3 Don’t Trust ID Parameters . . . . . . . . . . . . . . . . . . . . . 604
26.4 Don’t Expose Controller Methods . . . . . . . . . . . . . . . . . 605
26.5 Cross-Site Scripting (CSS/XSS) . . . . . . . . . . . . . . . . . . 606
26.6 Avoid Session Fixation Attacks . . . . . . . . . . . . . . . . . . 608
26.7 File Uploads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
 CONTENTS 10

26.8 Don’t Store Sensitive Information in the Clear . . . . . . . . . 610

26.9 Use SSL to Transmit Sensitive Information . . . . . . . . . . . 611
26.10 Don’t Cache Authenticated Pages . . . . . . . . . . . . . . . . . 612
26.11 Knowing That It Works . . . . . . . . . . . . . . . . . . . . . . . 612

27 Deployment and Production 614

27.1 Starting Early . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
27.2 How a Production Server Works . . . . . . . . . . . . . . . . . . 616
27.3 Comparing Front-End Web Servers . . . . . . . . . . . . . . . . 618
27.4 Repeatable Deployments with Capistrano . . . . . . . . . . . . 619
27.5 Setting Up a Deployment Environment . . . . . . . . . . . . . . 620
27.6 Checking Up on a Deployed Application . . . . . . . . . . . . . 626
27.7 Production Application Chores . . . . . . . . . . . . . . . . . . 627
27.8 Moving On to Launch and Beyond . . . . . . . . . . . . . . . . 628

Part V—Appendices 630

A Introduction to Ruby 631

A.1 Ruby Is an Object-Oriented Language . . . . . . . . . . . . . . 631
A.2 Ruby Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
A.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
A.4 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
A.5 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
A.6 Arrays and Hashes . . . . . . . . . . . . . . . . . . . . . . . . . 638
A.7 Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 639
A.8 Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 640
A.9 Blocks and Iterators . . . . . . . . . . . . . . . . . . . . . . . . . 640
A.10 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
A.11 Marshaling Objects . . . . . . . . . . . . . . . . . . . . . . . . . 642
A.12 Interactive Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
A.13 Ruby Idioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
A.14 RDoc Documentation . . . . . . . . . . . . . . . . . . . . . . . . 644

B Configuration Parameters 645

B.1 Top-Level Configuration . . . . . . . . . . . . . . . . . . . . . . 645
B.2 Active Record Configuration . . . . . . . . . . . . . . . . . . . . 647
B.3 Action Controller Configuration . . . . . . . . . . . . . . . . . . 649
B.4 Action View Configuration . . . . . . . . . . . . . . . . . . . . . 650
B.5 Action Mailer Configuration . . . . . . . . . . . . . . . . . . . . 651
B.6 Test Case Configuration . . . . . . . . . . . . . . . . . . . . . . 652
 CONTENTS 11

C Source Code 653

C.1 The Full Depot Application . . . . . . . . . . . . . . . . . . . . . 653

D Resources 684
D.1 Online Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 684
D.2 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684

Index 685
 Tous les jours, à tous les points de vue, je vais de mieux en
mieux.
Émile Coué

Preface to the Second Edition

It has been 18 months since I announced the first edition of this book. It
was clear before the book came out that Rails would be big, but I don’t think
anyone back then realized just how significant this framework would turn out
to be.

In the year that followed, Rails went from strength to strength. It was used
as the basis for any number of new, exciting web sites. Just as significantly,
large corporations (many of them household names) started to use Rails for
both inward- and outward-facing applications. Rails gained critical acclaim,
too. David Heinemeier Hansson, the creator of Rails, was named Hacker of the
Year at OSCON. Rails won a Jolt Award as best web development tool, and the
first edition of this book received a Jolt Award as best technical book.

But the Rails core team didn’t just sit still, soaking up the praise. Instead,
they’ve been heads-down adding new features and facilities. Rails 1.0, which
came out some months after the first edition hit the streets, added features
such as database migration support, as well as updated AJAX integration.
Rails 1.1, released in the spring of 2006, was a blockbuster, with more than
500 changes since the previous release. Many of these changes are deeply
significant. For example, RJS templates change the way that developers write
AJAX-enabled applications, and the integration testing framework changes the
way these applications can be tested. A lot of work has gone into extending and
enhancing Active Record, which now includes polymorphic associations, join
models, better caching, and a whole lot more.

The time had come to update the book to reflect all this goodness. And, as I
started making the changes, I realized that something else had changed. In the
time since the first book was released, we’d all gained a lot more experience
of just how to write a Rails application. Some stuff that seemed like a great
idea didn’t work so well in practice, and other features that initially seemed
peripheral turned out to be significant. And those new practices meant that
the changes to the book went far deeper than I’d expected. I was no longer
doing a cosmetic sweep through the text, adding a couple of new APIs. Instead,
I found myself rewriting the content. Some chapters from the original have
been removed, and new chapters have been added. Many of the rest have been
 P REFACE TO THE S ECOND E DITION 13

completely rewritten. So, it became clear that we were looking at a second

edition—basically a new book.

It seems strange to be releasing a second edition at a time when the first

edition is still among the best-selling programming books in the world. But
Rails has changed, and we need to change this book with it.

Enjoy!

Dave Thomas
October 2006
 Chapter 1

Introduction
Ruby on Rails is a framework 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 applications. It
isn’t just trendy among hard-core hackers: many multinational companies are
using Rails to create their web applications.

Why is that? There seem to be many reasons.

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 was 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 using modern, professional techniques. So these developers dug
into Rails and discovered it wasn’t just a tool for hacking out sites.

For example, all Rails applications 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
 C HAPTER 1. I NTRODUCTION 15

code, Rails automatically creates test stubs for that functionality. The frame-
work makes it easy to test applications, and as a result Rails applications tend
to get tested.

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

language. Ruby is concise without being unintelligibly terse—you can express
ideas naturally and cleanly in Ruby code. This leads to programs that are easy
to write and (just as importantly) are 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 programs shorter and more readable.
It also allows us to perform tasks that would normally be done in external
configuration files inside the codebase instead. This makes it far easier to see
what’s happening. The following code defines the model class for a project.
Don’t worry about the details 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 configuration. DRY stands for Don’t Repeat Yourself —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 find very little duplication in 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.

Convention over configuration is crucial, too. It means that Rails has sensi-
ble defaults for just about every aspect of knitting together your application.
Follow the conventions, and you can write a Rails application using less code
than a typical Java web application uses in XML configuration. If you need to
override the conventions, Rails 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 define them. And Rails
 R AILS I S A GILE 16

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 later on.)

Developers are worried about deployment, too. They found that with Rails you
can deploy successive releases of your application to any number of servers
with a single command (and roll them back equally easily should the release
prove to be somewhat less than perfect).

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

that the best way to create a framework is to find the central themes in a
specific application and then bottle them up in a generic foundation of code.
When you’re developing your Rails application, you’re starting with half of a
really good application already in place.

But there’s something else to Rails—something that’s hard to describe. 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...). That’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 applying agile prac-
tices X, Y, and Z to Rails coding.

The reason is both simple and subtle. Agility is part of the fabric of Rails.

Let’s look at the values expressed in the Agile Manifesto as a set of four pref-
erences.1 Agile development favors the following.

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Rails is all about individuals and interactions. There are no heavy toolsets,
no complex configurations, 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 reflected immediately in what
the customer sees. It’s an intrinsically interactive process.

Rails doesn’t denounce documentation. Rails makes it trivially easy to cre-

ate HTML documentation for your entire codebase. But the Rails development
process isn’t driven by documents. You won’t find 500-page specifications at
1. http://agilemanifesto.org/. Dave Thomas was one of the 17 authors of this document.
 F INDING Y OUR WAY A ROUND 17

the heart of a Rails project. Instead, you’ll find a group of users and develop-
ers jointly exploring their need and the possible ways of answering that need.
You’ll find solutions that change as both the developers and users become
more experienced with the problems they’re trying to solve. You’ll find a frame-
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 trust
that the team can deliver what’s required, not just what has been requested.
Confrontations are replaced by “What if?” sessions.

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 unit and functional testing, along
with support for test fixtures 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 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. As you read through the
tutorial chapters, try to imagine yourself developing web applications this way:
working alongside your customers and jointly determining priorities 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 agility and Rails: although it’s probably unprofessional
to mention this, think how much fun the coding will be.

1.2 Finding Your Way Around

The first two parts of this book are an introduction to the concepts behind
Rails and an extended example—we build a simple online store. This is the
place to start if you’re looking to get a feel for Rails programming. In fact, most
folks seem to enjoy building the application along with the book. If you don’t
want to do all that typing, you can cheat and download the source code (a
compressed tar archive or a zip file).2
2. http://www.pragmaticprogrammer.com/titles/rails2/code.html has the links for the downloads.
 F INDING Y OUR WAY A ROUND 18

The third part of the book, starting on page 229, is a detailed look at all the
functions and facilities of Rails. This is where you’ll go to find out how to
use the various Rails components and how to deploy your Rails applications
efficiently and safely.

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

Live Code
Most of the code snippets we show come from full-length, running exam-
ples, which you can download. To help you find your way, if a code listing
can be found in the download, there’ll be a bar above the snippet (just
like the one here).
Download work/demo1/app/controllers/say_controller.rb

class SayController < ApplicationController

def hello
end
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 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 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 631, is a (very) brief introduction
to the Ruby language. When we use a Ruby-specific construct for the
first time, we’ll cross-reference it to that appendix. For example, this
paragraph contains a gratuitous use of :name, a Ruby symbol. In the :name
֒→ page 633
margin, you’ll see an indication that symbols are explained on page 633.
If you don’t know Ruby, or if you need a quick refresher, you might want
to go read Appendix A, on page 631, 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 developer, sometimes pops up to ask questions about
stuff we talk about in the text. We answer these as we go along.
 A CKNOWLEDGMENTS 19

This book isn’t a reference manual for Rails. We show most of the modules and
most of their methods, either by example or narratively in the text, but we don’t
have hundreds of pages of API listings. There’s a good reason for this—you get
that documentation whenever you install Rails, and it’s guaranteed to be more
up-to-date than the material in this book. If you install Rails using RubyGems
(which we recommend), simply start the gem documentation server (using the
command gem_server), and you can access all the Rails APIs by pointing your
browser at http://localhost:8808. (The sidebar on page 39 describes another way
of installing the full API documentation.)

Rails Versions
This book documents Rails 1.2.

If you are not running Rails 1.2, then you’ll need to update before trying the
code in this book. If Rails 1.2 is not yet available (this book went to print before
the official Gem was released), you can download an interim version. See the
instructions inside the front cover.

1.3 Acknowledgments
You’d think that producing a second edition of a book would be easy. After all,
you already have all the text. It’s just a tweak to some code here and a minor
wording change there, and you’re done. You’d think....

It’s difficult to tell exactly, but my impression is that creating this second
edition of Agile Web Development with Rails took about as much effort as the
first edition. Rails was constantly evolving and, as it did, so did this book.
Parts of the Depot application were rewritten three or four times, and all of
the narrative was updated. The emphasis on REST and the addition of the
deprecation mechanism all changed the structure of the book as what was
once hot became just lukewarm.

So, this book would not exist without a massive amount of help from the
Ruby and Rails communities. As with the original, this book was released as
a beta book: early versions were posted as PDFs, and people made comments
online. And comment they did: more than 1,200 suggestions and bug reports
were posted. The vast majority ended up being incorporated, making this book
immeasurably more useful than it would have been. Thank you all, both for
supporting the beta book program and for contributing so much valuable feed-
back.

As with the first edition, the Rails core team was incredibly helpful, answering
questions, checking out code fragments, and fixing bugs. A big thank you to

Scott Barron (htonl), Jamis Buck (minam), Thomas Fuchs (madrobby),

Jeremy Kemper (bitsweat), Michael Koziarski (nzkoz),
 A CKNOWLEDGMENTS 20

Marcel Molina Jr, (noradio), Rick Olson (technoweenie),

Nicholas Seckar (Ulysses), Sam Stephenson (sam), Tobias Lütke (xal),
and Florian Weber (csshsh).

I’d like to thank the folks who contributed the specialized chapters to the
book: Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland,
and Andreas Schwarz.

I keep promising myself that each book will be the last, if for no other reason
than each takes me away from my family for months at a time. Once again:
Juliet, Zachary, and Henry—thank you for everything.

Dave Thomas
November 2006
dave@pragprog.com

“Agile Web Development with Rails...I found it

in our local bookstore and it seemed great!”
—Dave’s Mum
 Part I

Getting Started
 Chapter 2

The Architecture of Rails Applications

One of the interesting features of Rails is that it imposes some fairly serious
constraints on how you structure your web applications. Surprisingly, these
constraints make it easier to create applications—a lot easier. Let’s see why.

2.1 Models, Views, and Controllers

Back in 1979, Trygve Reenskaug came up with a new architecture for develop-
ing interactive applications. In his design, applications were broken into three
types of components: models, views, and controllers.

The model is responsible for maintaining the state of the application. Some-
times this state is transient, lasting for just a couple of interactions with the
user. Sometimes the state is permanent and will be stored outside the appli-
cation, often in a database.

A model is more than just data; it enforces all the business rules that apply
to that data. For example, if a discount shouldn’t be applied to orders of less
than $20, the model will enforce the constraint. This makes sense; by putting
the implementation of these business rules in the model, we make sure that
nothing else in the application can make our data invalid. The model acts as
both a gatekeeper and a data store.

The view is responsible for generating a user interface, normally based on

data in the model. For example, an online store will have a list of products
to be displayed on a catalog screen. This list will be accessible via the model,
but it will be a view that accesses the list from the model and formats it for
the end user. Although the view may present the user with various ways of
inputting data, the view itself never handles incoming data. The view’s work
is done once the data is displayed. There may well be many views that access
the same model data, often for different purposes. In the online store, there’ll
 M ODELS , V IEWS , AND C ONTROLLERS 23

! Browser sends request

" Controller interacts with model
# Controller invokes view
!
Controller $ View renders next browser screen

$ # "

View Model Database

Figure 2.1: The Model-View-Controller Architecture

be a view that displays product information on a catalog page and another set
of views used by administrators to add and edit products.

Controllers orchestrate the application. Controllers receive events from the

outside world (normally user input), interact with the model, and display an
appropriate view to the user.

This triumvirate—the model, view, and controller—together form an architec-

ture known as MVC. Figure 2.1 shows MVC in abstract terms.

MVC was originally intended for conventional GUI applications, where devel-
opers found the separation of concerns led to far less coupling, which in turn
made the code easier to write and maintain. Each concept or action was
expressed in just one well-known place. Using MVC was like constructing a
skyscraper with the girders already in place—it was a lot easier to hang the
rest of the pieces with a structure already there.

In the software world, we often ignore good ideas from the past as we rush
headlong to meet the future. When developers first started producing web
applications, they went back to writing monolithic programs that intermixed
presentation, database access, business logic, and event handling in one big
ball of code. But ideas from the past slowly crept back in, and folks started
experimenting with architectures for web applications that mirrored the 20-
year-old ideas in MVC. The results were frameworks such as WebObjects,
Struts, and JavaServer Faces. All are based (with varying degrees of fidelity)
on the ideas of MVC.
 M ODELS , V IEWS , AND C ONTROLLERS 24

! Routing ! http://my.url/store/add_to_cart/123
" " Routing finds Store controller
# Controller interacts with model
$ Controller invokes view
Store %&View renders next browser screen
Controller
% $ #

Display Active
Cart Record Database
View Model

Figure 2.2: Rails and MVC

Ruby on Rails is an MVC framework, too. Rails enforces a structure for your
application—you develop models, views, and controllers as separate chunks of
functionality and it knits them all together as your program executes. One of
the joys of Rails is that this knitting process is based on the use of intelligent
defaults so that you typically don’t need to write any external configuration
metadata to make it all work. This is an example of the Rails philosophy of
favoring convention over configuration.

In a Rails application, incoming requests are first sent to a router, which

works out where in the application the request should be sent and how the
request itself should be parsed. Ultimately, this phase identifies a particular
method (called an action in Rails parlance) somewhere in the controller code.
The action might look at data in the request itself, it might interact with the
model, and it might cause other actions to be invoked. Eventually the action
prepares information for the view, which renders something to the user.

Figure 2.2, shows how Rails handles an incoming request. In this example, the
application has previously displayed a product catalog page and the user has
just clicked the Add To Cart button next to one of the products. This button
links to http://my.url/store/add_to_cart/123, where add_to_cart is an action in our
application and 123 is our internal id for the selected product.1
1. We cover the format of Rails URLs later in the book. However, it’s worth pointing out here that
having URLs perform actions such as add to cart can be dangerous. See Section 21.6, The Problem
with GET Requests, on page 463 for more details.
 A CTIVE R ECORD : R AILS M ODEL S UPPOR T 25

The routing component receives the incoming request and immediately picks
it apart. In this simple case, it takes the first part of the path, store, as the
name of the controller and the second part, add_to_cart, as the name of an
action. The last part of the path, 123, is by convention extracted into an internal
parameter called id. As a result of all this analysis, the router knows it has to
invoke the add_to_cart method in the controller class StoreController (we’ll talk
about naming conventions on page 241).

The add_to_cart method handles user requests. In this case it finds the current
user’s shopping cart (which is an object managed by the model). It also asks
the model to find the information for product 123. It then tells the shopping
cart to add that product to itself. (See how the model is being used to keep
track of all the business data; the controller tells it what to do, and the model
knows how to do it.)

Now that the cart includes the new product, we can show it to the user. The
controller arranges things so that the view has access to the cart object from
the model, and it invokes the view code. In Rails, this invocation is often
implicit; again conventions help link a particular view with a given action.

That’s all there is to an MVC web application. By following a set of conven-

tions and partitioning your functionality appropriately, you’ll discover that
your code becomes easier to work with and your application becomes easier to
extend and maintain. Seems like a good trade.

If MVC is simply a question of partitioning your code a particular way, you

might be wondering why you need a framework such as Ruby on Rails. The
answer is straightforward: Rails handles all of the low-level housekeeping for
you—all those messy details that take so long to handle by yourself—and lets
you concentrate on your application’s core functionality. Let’s see how....

2.2 Active Record: Rails Model Support

In general, we’ll want our web applications to keep their information in a rela-
tional database. Order-entry systems will store orders, line items, and cus-
tomer details in database tables. Even applications that normally use unstruc-
tured text, such as weblogs and news sites, often use databases as their back-
end data store.

Although it might not be immediately apparent from the SQL2 you use to
access them, relational databases are actually designed around mathematical
set theory. Although this is good from a conceptual point of view, it makes
it difficult to combine relational databases with object-oriented programming
2. SQL, referred to by some as Structured Query Language, is the language used to query and
update relational databases.
 Another Random Document on
Scribd Without Any Related Topics
The Project Gutenberg eBook of Careers in
Atomic Energy
This ebook is for the use of anyone anywhere in the United States
and most other parts of the world at no cost and with almost no
restrictions whatsoever. You may copy it, give it away or re-use it
under the terms of the Project Gutenberg License included with this
ebook or online at www.gutenberg.org. If you are not located in the
United States, you will have to check the laws of the country where
you are located before using this eBook.

Title: Careers in Atomic Energy

Author: Loyce J. McIlhenny

Release date: May 1, 2013 [eBook #42626]

Most recently updated: October 23, 2024

Language: English

Credits: Produced by Juliet Sutherland, Matthew Wheaton and the

Online Distributed Proofreading Team at
http://www.pgdp.net

*** START OF THE PROJECT GUTENBERG EBOOK CAREERS IN

ATOMIC ENERGY ***
 Careers in Automic Energy
by Loyce J. McIlhenny
PLANNING FOR SCIENTIFIC TECHNICAL PROFESSIONS
U.S. ATOMIC ENERGY COMMISSION
Division of Technical Information
Understanding the Atom Series

The Understanding the Atom Series

Nuclear energy is playing a vital role in the life of every man,
woman, and child in the United States today. In the years ahead it
will affect increasingly all the peoples of the earth. It is essential that
all Americans gain an understanding of this vital force if they are to
discharge thoughtfully their responsibilities as citizens and if they are
to realize fully the myriad benefits that nuclear energy offers them.
The United States Atomic Energy Commission provides this
booklet to help you achieve such understanding.

Edward J. Brunenkant

Edward J. Brunenkant, Director

Division of Technical Information
UNITED STATES ATOMIC ENERGY COMMISSION

Dr. Glenn T. Seaborg, Chairman

James T. Ramey
Wilfrid E. Johnson
Dr. Theos J. Thompson
Dr. Clarence E. Larson

Careers in Atomic Energy

by Loyce J. McIlhenny
 CONTENTS
THE SCIENTIFIC MIND 3

SCIENTISTS ARE PEOPLE 3

THE TIME TO BEGIN 3

COLLEGE: IS IT A NECESSITY? 5

SCHOLARSHIPS AND OTHER FINANCIAL ASSISTANCE 6

COLLEGE: HOW MANY YEARS? 7

Physical and Biological Sciences 7
Engineering 8
Medicine 8
Veterinary Science 9
Scientific Writing 9
Supporting Fields 9

WORK OF THE ATOMIC SCIENTIST 11

Physics 11
Chemistry 13
Biology 14
Geology 15
Engineering 15
Mathematics 17
Medicine 18
Related Fields 18
 LOCATION OF THE ATOMIC SCIENTIST 20
The United States Government 20
Private Industry 20
Educational Organizations 21
Hospitals 21
State and Local Governments 21
Other Organizations 22

PROFESSIONAL SATISFACTION 22

SELECTED READING LIST 23

United States Atomic Energy Commission

Division of Technical Information

Library of Congress Catalog Card Number: 64-60275

1962; 1964(Rev.)

ABOUT THE AUTHOR

After receiving a degree in English at the University of Houston,
Mrs. McIlhenny worked for nine years in editorial capacities at the
Oak Ridge Institute of Nuclear Studies, where she prepared this
booklet. She is now a housewife in Falls Church, Virginia.
 Careers in Atomic Energy

LOYCE J. McILHENNY

TODAY virtually every aspect of science is concerned in some

way with the atom.
Physicians use radiation to treat disease. Mechanical engineers
design components for nuclear reactors. Electrical engineers convert
the energy of the atom into electricity. Botanists use radioactivity to
learn more about plants, and zoologists use it to study animals.
Chemists investigate compounds with radioisotopes. Physicists and
mathematicians work out the intricate interrelations among the tiny
particles of the atom. Agronomists use radioactive materials to
improve fertilizers and crops, and nutritionists use them to improve
animal diets.
A student—YOU—can find your career in atomic energy in any
branch of science you choose because “atomics” is not a field unto
itself divorced from the rest of the scientific world.
The best preparation for a career in nuclear energy begins with
elementary arithmetic. This preparation advances through general
science, algebra, biology, chemistry, physics, geometry, and
trigonometry. The aspiring scientist will be wise to lay the
groundwork for his future long before he reaches college by studying
as much mathematics and science as he can handle. Although many
a now-successful chemist entered college without knowing how to
balance an equation, keen competition today demands that college
freshmen have a solid foundation in mathematics and science.
Even in an age of specialization, the interrelation of the sciences
has made it necessary for a scientist to have at least a speaking
acquaintance with areas outside his own field. A chemist, for
example, may find himself involved in biology; the research interests
of a biologist may lead him into physics.
Moreover, English-speaking peoples have no monopoly on
scientific accomplishment. Proficiency in German and French, at least
a reading knowledge, has long been considered desirable and is
often required of the serious scientist. In the light of modern
developments, a reading knowledge of Russian might well be added
to the list, and, as other countries and cultures expand their
technologies, familiarity with still other languages may become
necessary. (Indeed, a number of scientists who completed doctoral
degrees years ago have recently begun to study Russian. This is not
surprising since the education of a true scientist never stops with an
academic degree, a job appointment, or a significant discovery.)
The most brilliant physicist on earth is of doubtful worth if he
can’t communicate his ideas to other people. Thus even more
important than a knowledge of foreign languages is a knowledge of
one’s own. Almost too late has come the realization that many
college graduates in the United States, although proficient in their
particular fields, cannot write a correct English sentence. Accurate
scientists cannot afford inaccurate communication. Proficient
scientists know their own language.
 The Scientific Mind
A widespread popular belief exists that the “scientific mind” is a
trait that some people inherit and others don’t, like red hair or brown
eyes. This is both true and false. Essentially, an innate “scientific
mind” does not exist. In the natural course of growing up, however,
some people acquire or develop certain characteristics that are most
commonly found in successful scientists. These characteristics
include curiosity, caution, thoroughness, patience, perseverance, and
logical reasoning power. These are general traits, and all can be
developed to some degree.
 Scientists Are People
With increased national attention focused on scientific activities,
some people have developed strange notions about the man who
wears a lab coat. Scientists have a high degree of objectivity in the
laboratory, but they usually are not different from the rest of society
in matters of religion, marriage, parenthood, or politics. Often they
don’t adhere to a strict eight-hour day, but neither does a salesman.
They may seem unusually dedicated to their profession, but so does
a master chef. They rarely are geniuses; sometimes they have
superior intelligence; but frequently they have ordinary intelligence.
Most are reasonably well balanced, some are eccentric, and a few
are downright peculiar. But these same characteristics can describe
lawyers, businessmen, and secretaries.
 The Time to Begin
If you are seriously planning a career in science and if you are
devoting your time to the study of science, mathematics, English,
and foreign languages, you are laying the foundation in school right
now for your future. You—whether you are a he or a she—can begin
now without waiting until the sixth, or ninth, or twelfth grade
introduces you to further courses.

Girls have no reason to feel that any branch of science, including

nuclear technology and engineering, is strictly a “man’s job.”

Beginning now, you can supplement your studies by exploring

science through books. You can go to your school library and to your
public library for reading material. Teachers and librarians can help
you select material.
 The doors of knowledge can open, however, only as rapidly as
you can read. The sheer bulk of scientific literature in print today is
staggering. Any student who is a slow reader should seek immediate
help from his teachers. Slow reading does not prove a slow mind,
nor does slow reading improve comprehension. Both these ideas are
false, and, if you mistakenly cling to either one, you cheat yourself.
As a matter of fact, probably not one person in a million reads as
rapidly as he can, and it would behoove even the exceptionally rapid
reader to work at improving this basic skill, which is essential to all
accomplishment.
Further, if you want to do serious scientific study, ask your
teachers to outline science projects that you can undertake after
school or during free periods. Many projects that are both
educational and fun can be undertaken without costly equipment or
a complete laboratory.
Other means of improving scientific understanding and
competence outside the classroom include science clubs, state junior
academies of science, and participation in science fairs. If these
activities do not exist in your area, perhaps you can whip up enough
interest among students, teachers, and parents to start them. If not,
you can channel your science projects through such organizations as
boys’ clubs or Scouts.
The student who is avidly studying science in school and in
extra-curricular activities sometimes sets his sights on a summer
laboratory job. Although this is certainly worthwhile, often it cannot
be realized. Many opportunities exist, however, for valuable summer
study and training in the approximately 200 special programs for
science students at colleges and universities. These programs are
sponsored by the National Science Foundation to provide
outstanding high-school students with unusual laboratory and study
experiences.
 College: Is It a Necessity?
Many intelligent and successful people never attended college,
but few of them are in the scientific ranks. If you want a career in
science, you must first select a college or university. Many factors, of
course, determine this choice.
The first question you have to ask yourself is a rather grim one:
which schools will admit me? With the rapid increase in student
population, the shortage of teachers, and the physical facilities of
universities strained to bursting, it is no longer possible for colleges
to admit everybody who wants to enter. Again, as always, this is
where hard work in elementary and in high school pays off: good
grades in “solid” subjects are master keys to university gates.
Entrance exams required by many schools are stiff, but a
background of twelve years of conscientious study usually prepares
you to deal with them.
A college education is a costly business anywhere these days,
but expenses can vary greatly from school to school. Once again the
matter of precollege achievement crops up: open to undergraduate
students with top records are scholarships and special educational
loans and other programs designed to offset or defray college
expenses.
After you consider entrance requirements and cost, you should
weigh the location of the school, course offerings in your field of
interest, faculty, and facilities. You should also evaluate the size and
type of the institution in terms of your own personality. Parents,
teachers, and local scientists can be excellent counselors in helping
you make the decision.
Inevitably some intelligent students who lack motivation fail to
achieve top grades in high school. Science careers are open even to
these students if they choose their colleges carefully. Sometimes
small, less well-known colleges will admit them because the
competition for entrance is not as great as it is in “name” colleges.
Small schools should not be dismissed as “second rate.” They are
usually staffed by fine teachers, and, even with limited laboratory
facilities, such colleges still offer excellent training.
 Scholarships and Other Financial
Assistance
A number of fellowships, scholarships, grants, and awards are
available to assist the aspiring scientist in his education.
This financial assistance is offered by colleges; local, state, and
federal government agencies; industry; private foundations; and
individuals.
Literally thousands of other educational assistance programs
exist. A list of some publications that contain information on
currently available assistance is printed in the back as a guide. Some
of the publications are in most libraries; others must be ordered
from the publisher. Since financial assistance programs are
undergoing constant change and revision, no directory can be
complete, but these books will give you an indication of the range of
the programs.
 College: How Many Years?
Although it is common for a student to change his primary
interest from one science to another during his college training, he
should have in mind from the beginning the sort of broad career he
wants and the amount of time that preparation will take.
For example, a bachelor’s degree in one of the physical or
geological sciences such as physics, chemistry, biology, geology,
archaeology, agriculture, metallurgy, or mathematics usually requires
four years. Some engineering programs require five. A medical
student, on the other hand, sometimes takes only three years of
college and then goes directly into medical school without a
bachelor’s degree but with six to eight years of training still ahead of
him.

Physical and Biological Sciences

Most scientific endeavor today is undertaken by teams
composed of individuals with doctor’s, master’s, and bachelor’s
degrees in the sciences. These teams have supporting technical and
administrative personnel to help them function efficiently.
In the physical and biological fields, scientists with doctor’s
degrees have probably spent three to six years in college after they
received their bachelor’s degrees. They are likely to head the team
and to have the responsibility for planning and directing research
and development projects.
Individuals with master’s degrees have spent about two years in
graduate school. They have some research training and undertake
scientific projects under direction, although they may also have
some responsibility for planning and supervising.
The bachelor’s degree is not a research degree, and team
members without graduate training are not likely to direct research.
They probably spend their time conducting fairly routine research
duties under the guidance of more highly trained supervisors.
The above outline is a general description of the typical
situation; work conditions may vary greatly depending on the
individual and his organization.

Engineering
Traditionally engineering has been somewhat different. Many
engineers held responsible jobs after receiving only a bachelor’s
degree. Some did earn a master’s degree, but few studied for a
doctorate.
In the last ten years, however, this trend has changed with
many more engineers receiving master’s and doctor’s degrees.
Advanced study is especially important for a career in the nuclear
field because the undergraduate years are filled mainly with basic
engineering, and most nuclear courses must be taken at the
graduate level. Moreover, the engineering sciences, as all other
fields, are becoming increasingly complex. Thus graduate study
through at least a master’s degree is advisable for the engineer.
The prospective engineering student should realize that a
bachelor’s degree will take from four to five years to complete, a
master’s degree will require an additional one to two years, and a
doctor’s degree will involve still another two to four years.

Medicine
A career in medicine is still a different story.
After three to four years in college premedical study, four years
in medical school, at least one year of internship, and possibly a
year’s medical residency, a doctor can become a general practitioner.
If he wishes to specialize, his internship may last for two years, and
his residency period from three to four years. It is this latter, longer
path that leads to a career in nuclear medicine and radiology, as well
as to more familiar specialization, such as surgery, pathology,
obstetrics, or pediatrics.

Veterinary Science
Also important in the field of nuclear medicine is the veterinary
scientist.
A veterinarian spends from two to four years in undergraduate
study and four years in veterinary school before receiving a Doctor
of Veterinary Medicine degree that permits him to practice animal
medicine. Then, if he wishes to enter nuclear veterinary medicine,
veterinary pathology, or some other specialty, he undergoes
additional training that is comparable to that of the physician who
specializes.

Scientific Writing
Valuable in all areas of science and engineering is the technical
writer.
Several years ago the typical technical writer or editor had a
background of journalism or English grammar and some
undergraduate study of one or more of the sciences. Editorial ability
still depends largely on ability to handle the English language, but
more and more frequently today the successful technical writer or
editor has a bachelor’s degree in one of the sciences. Sometimes he
has a master’s degree, and occasionally he holds a doctor’s degree.

Supporting Fields
No scientific organization can function if it is manned only by
scientists. Supporting and assisting personnel are essential to the
scientific team, and training is widely available for the nonscientist
who wants to work in a scientific installation.
 Atomic energy, like fire, is not dangerous when it is under the
control of people who know how to use it. Special instruments and
protective clothing are used by trained technicians who are
responsible for radiation control.

A nurse is a professional medical assistant. She can be certified

as a registered nurse in three years, or she can earn both an RN and
a bachelor’s degree in four to five years. Especially if she enters the
field of nuclear medicine or if she is associated with a physician or
organization engaged in the clinical use of radiation and
radioisotopes, she will need a background in physics in addition to
her study of chemistry and the life sciences.
Many colleges and universities offer two-year programs that
lead to a certificate qualifying a student as a laboratory aide. The
laboratory aide, or assistant, performs assigned duties under close
supervision. He does not conduct actual research, but he supplies
the scientist with an extra pair of hands.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookname.com