1. A little engineering on Rails Robert W. Hasker

2. Goals Intro to the Rails framework ▫Basic concepts: MVC, Active Record ▫A bit of Ruby Using Rails to build a website Myths and issues

3. The Rails Framework Basic goal: construct database-backed websites Multi-platform: popular OS’s, database engines Origins: ▫Instiki by David Heinemeier Hansson ▫Basecamp by 37signals ▫Rails: domain-independent core Built on the Ruby language ▫General-purpose language: scripting, applications ▫Dynamically typed, “open” classes

4. Basic Concept: MVC Issue: how to separate logic from presentation? Classic solution: Model/View/Controller ▫Model: domain-level data ▫View: how the data is presented to the user  Typically want multiple views ▫Controller: logic linking the two Rails ▫Model = tables in a relational database ▫View = web pages ▫Controller = controller

5. Basic Concepts: Active Record Relational Databases: organize large amounts of data ▫Issue: no easy mapping to object-oriented design Active Record Pattern ▫A design pattern first described by Martin Fowler ▫Object = table row w/ attributes stored as columns ▫Table = collection of objects ▫OOD = database (collection of tables)  Rails: link classes through id fields in tables

6. Active Record Example Data for a simple voting system: As tables: ▫ create table questions (id int, body text, start datetime, end datetime, primary key(id)); ▫ create table voters (id int, username text, password text, primary key(id)); ▫ create table vote_records (voter_id int, …); Benefit: can add operations as needed - active records

7. Using rails to build a voting application See http://www.uwplatt.edu/csse/tools/ruby/rails/rails-demo.htmlhttp://www.uwplatt.edu/csse/tools/ruby/rails/rails-demo.html

8. Conclusion Rails: quick OO websites ▫MVC: sound organization ▫ActiveRecord: support good OO designs  Focus on relationships, not queries  Less likely to forget a join, but supports full SQL  Not shown: does support inheritance  Navigation: keep the class diagram close at hand!

9. Conclusion… Design ▫DRY: don’t repeat yourself ▫Convention, not configuration ▫Relationships are declared explicitly ▫Scaffolding: quick data entry (prototyping only) ▫Great development environment  has full debugging support; separate dev/prod db’s ▫Supports JavaScript/Ajax/etc.  Explore Ajax support next time

10. Myths & Issues Myth: slow sites, doesn’t scale ▫Supports many web servers ▫Many optimizations probably belong elsewhere ▫Technology improving Myth: only for specific types of projects ▫Source: lots of simple examples out there ▫Can handle big problems ▫Don’t have to involve a database ▫See http://wiki.rubyonrails.org/rails/pages/RealWorldUsagePage1 http://wiki.rubyonrails.org/rails/pages/RealWorldUsagePage1 Issues ▫Active Records: should have Table classes ▫Ruby: run-time type checking requires lots of testing!  But has good built-in testing support! ▫Developers tempted to use all – pick level and stick to it

11. Resources Online tutorials Classic text: Agile Web Development with Rails Starting points: ▫http://guides.rubyonrails.org/getting_started.html ▫Beginning Rails: From Novice to Professional  In library, but based on Rails 1.x ▫Beginning Rails 3  Available soon More detail: The Rails Way