Web Application Architectures

Module 2: Ruby on Rails Module Overview

c 2011-13 G.L. Heileman

Module 2: Overview

1/2

Module 2 Overview
Rails Overview Your First Rails App The Blog App Iteration 1 Rails Philosophy Version Control Git and Rails

c 2011-13 G.L. Heileman

Module 2: Overview

2/2

Web Application Architectures

Module 2: Ruby on Rails Lecture 1: Rails Overview

c 2011-13 G.L. Heileman

Module 2, Lecture 1

1/6

Rails Background
Ruby on Rails (Rails) is a software framework for building Web applications. Features: Built using the Ruby programming language. Open source MIT License. Provides a full stack back-end data store to front-end presentation of web pages, and everything in between. Released in 2004, and has continued to evolve rapidly. Some sites built using Rails: Twitter, Hulu, GitHub,Yellow Pages and Funny or Die

c 2011-13 G.L. Heileman

Module 2, Lecture 1

2/6

Rails Whats Inside

Rails is a Ruby gem (a gem is a prepackaged Ruby application or library). Rails includes an extensive set of code generators, automated testing scripts and other features that are intended to make the job of programming a web application easier. A suite of additional tools are provided as part of the Rails ecosystem that make it easy to deploy a fully-functional web application:
Rake comes from RubyMAKE, i.e., its a utility similar to the Unix make. You use it to create and migrate databases, clear web session data, etc. WEBrick web server for hosting Rails web applications. Can also use other web servers, e.g., Apache, Thin, Unicorn, etc. SQLite a simple database engine pre-installed with Rails. Rack Middleware standardized interface for interaction between web server and web application.
c 2011-13 G.L. Heileman Module 2, Lecture 1 3/6

Model-View-Controller
The Rails framework is built around the Model-View-Controller (MVC) design pattern:
Script/ Service Web Client (Browser) 1: request Network 2: response
Connector Database

Web Server

Script/ Service Script/ Service

Connector Database

Client tier

Web tier

Presentation logic tier

Business logic tier

Data access tier

Data tier

MVC Design Pattern

c 2011-13 G.L. Heileman

Module 2, Lecture 1

4/6

Rails Criticisms
It doesnt scale High prole issues at Twitter. Its magic The framework and code generation means you really dont know whats going on under the hood. My Answer Its all a part of the natural progression:

Bits Assembly HLL OOP Frameworks

c 2011-13 G.L. Heileman

Module 2, Lecture 1

5/6

Eciency vs. Productivity

The point is that the cost per request is plummeting, but the cost of programming is not. Thus, we have to nd ways to trade eciency in the runtime for eciency in the thought time in order to make the development of applications cheaper. I believed weve long since entered an age where simplicity of development and maintenance is where the real value lies. David Heinemeier Hansson

c 2011-13 G.L. Heileman

Module 2, Lecture 1

6/6

Web Application Architectures

Module 2: Ruby on Rails Lecture 2: Your First Rails App

c 2011-13 G.L. Heileman

Module 2, Lecture 2

1/3

Its Time to Get to Work

On a machine with a working Rails installation: 1. Open up a terminal window, and at the command prompt ($) type: $ rails new my_app 2. Change to the application directory (RAILS.root): $ cd my_app 3. Start the web server: $ rails server 4. Open a browser window and navigate to: http://localhost:3000

c 2011-13 G.L. Heileman

Module 2, Lecture 2

2/3

Rails Directory Structure

RAILS.root app bin cong db Gemle lib log public test tmp vendor
c 2011-13 G.L. Heileman Module 2, Lecture 2 3/3

my_app Models, Views and Controllers code Helper scripts (bundle, rails, rake) App, database & route configuration Database schema and migrations Specify the required gems Application logging directory Webroot of the application Tests - Agile development

Web Application Architectures

Module 2: Ruby on Rails Lecture 3: The Blog App Iteration 1

c 2011-13 G.L. Heileman

Module 2, Lecture 3

1/5

Blog App Specications

Lets build a more substantial web application. The Blog Application, usage specciations:
Blog is a contraction of weblog, a discussion or information site published on the Web. There are two types of users: the blog administrator and blog users. The blog administrator should be able to enter new postings, typically in reverse chronological order. Users should be able to visit the blog site, and enter comments about particular postings. The blog administrator should be able to modify/remove any posting or comment. Users should not be able to modify postings or other users comments.

c 2011-13 G.L. Heileman

Module 2, Lecture 3

2/5

Blog App Initial Steps

First create the rails application using: $ rails new blog Next, in the blog app directory, use the scaold generator to create the MVC components needed for posts and comments:
$ rails generate scaffold post title:string \ body:text $ rails generate scaffold comment post_id:integer \ body:text

Now, create the post and comment database tables using: $ rake db:migrate
c 2011-13 G.L. Heileman Module 2, Lecture 3 3/5

Blog App Initial Steps

If you type: $ rake routes a list of all the URLs currently recognized by your application will be provided. Start the web server: $ rails server and point your browser to: http://localhost:3000

c 2011-13 G.L. Heileman

Module 2, Lecture 3

4/5

Blog App Initial Steps

At this point, Id like you to create this blog application on your own, and demonstrate that you can perform CRUD operations on posts and comments. Create Read Update Destroy

c 2011-13 G.L. Heileman

Module 2, Lecture 3

5/5

Web Application Architectures

Module 2: Ruby on Rails Lecture 4: Rails Philosophy

c 2011-13 G.L. Heileman

Module 2, Lecture 4

1/5

Rails Philosophy
The Rails philosophy is based upon three principles: Convention over Conguration Common aspects of a web application are provided (i.e., precongured) for you, so use them, rather than ght against them! Ideally, the developer should only have to specify the unconventional aspects of the application. Dont Repeat Yourself (DRY) Every piece of information should have a single, unambiguous, authoritative representation within a system. Duplication of code fragments throughout an application can lead to logical contradictions, and in general make the application more dicult to maintain. Agile Development Software development methodologies based on iterative and incremental development, where requirements and code evolve with minimal planning through self-organizing, cross-functional teams.
c 2011-13 G.L. Heileman Module 2, Lecture 4 2/5

Convention over Conguration

A massive number of conventions are built into Rails, and the real trick is learning all of them. When you create a Rails application, the full web stack is pre-wired and ready to go. Rails code generators follow specic naming conventions. E.g., if you use the scaold (MVC) generator to create a Post, you get:
A class called Post will be created for the model, along with a corresponding table in the database that will be called posts A RESTful controller called posts_controller will be created, and routes will be set up so that specic URLs will be able to perform CRUD operations on the post table in the database. A posts view will be created, consisting of a set of HTML les that can be used to render the results of the CRUD operations. Test xtures, along with unit, functional, integration and performance test suites are automatically generated.

c 2011-13 G.L. Heileman

Module 2, Lecture 4

3/5

DRY
Every piece of information should have a single, unambiguous, authoritative representation within a system. E.g., In Rails, with ActiveRecords, once a model is specied, you dont need to specify database column names theyre determined from the model. When applied successfully, a modication to a system element does not change any other logically-unrelated system element, while elements that are logically related all change predictably and uniformly, thereby keeping them in sync. This principle makes it easier to use code generators and automatic build systems. Thus, DRY code is typically created by data transformations and code generators, allowing the software developer to avoid copy and paste operations. Following the DRY principle makes it easier to maintain large software systems.
c 2011-13 G.L. Heileman Module 2, Lecture 4 4/5

Agile Development
Agile development emphasizes working software as the primary measure of progress. Rails was built with agile development in mind:
A working application is available immediately. In development mode, there are no recompile, deploy, restart cycles. I.e., Rails does not generally require you to stop the server; changes made to the application will be automatically picked up by the server. Rails has simple tools to generate code quickly. Testing is built into the Rails framework.

Extreme programming is an agile approach that that centers around test-driven development (TDD). Behavior-driven development (BDD), a second generation agile approach, extends TDD by writing test cases in natural language that non-programmers can read. BDD focuses on obtaining a clear understanding of desired software behavior through discuss with stakeholders. RSpec and Cucumber are BDD tools for Ruby that well use.
c 2011-13 G.L. Heileman Module 2, Lecture 4 5/5

Web Application Architectures

Module 2: Ruby on Rails Lecture 5: Version Control

c 2011-13 G.L. Heileman

Module 2, Lecture 5

1/9

Version Control
Midnight Train to Georgia by Gladys Knight and the Pips: Considered the signature song of legend Gladys Knight. One of the greatest R&B songs of all time. Rolling Stone lists it as one of their 500 Greatest Songs of All Time.

The original title was Midnight Plane to Houston about a plane trip from Nashville to Houston, and the author envisioned it as a country song.

c 2011-13 G.L. Heileman

Module 2, Lecture 5

2/9

Version Control

Denition (Version Control, Revision Control, Source Code Control)

The practice of tracking and providing control over the changes made to source code.

The need for managing software versions has existed as long as theres been software. Version control is commonly used by a development team to keep track of the various pieces of source code that dierent members of the project are working on, along with the various versions that they may wish to create.

c 2011-13 G.L. Heileman

Module 2, Lecture 5

3/9

Local Version Control

A single developer:

Local Computer Editor file A

checkin

Version Database Version 3

files: A, B, C

file A

checkout

Version 2
files: A, B, C

Version 1
files: A, B, C

c 2011-13 G.L. Heileman

Module 2, Lecture 5

4/9

Centralized Version Control

A development team:

Developer 1 file A
checkout

Central VCS Server Version Database Version 3

files: A, B, C

Version 2 Developer 2 file B

checkout

files: A, B, C

Version 1
files: A, B, C

c 2011-13 G.L. Heileman

Module 2, Lecture 5

5/9

Centralized Version Control

Dierences are stored:
checkins over time

Version 1 file A file B file C

Version 2

Version 3
1

Version 4
2

Version 5
3

c 2011-13 G.L. Heileman

Module 2, Lecture 5

6/9

Distributed Version Control

As software development has become more team-based, and and teams have become more distributed, the need for distributed version control systems has emerged. In distributed version control, there is no centralized repository, team members dont check out les from these systems, they check out the entire repository. This does not lock the repository other team members can also download the current version of a project. Later, when a team member check the project back in, it is marked as a dierent version in the repository. Thus, you can think of distributed version control systems as storing dierent snapshots of a project over time. It is up to the owner of the repository to merge dierent version together if he/she so chooses.
c 2011-13 G.L. Heileman Module 2, Lecture 5 7/9

Distributed Version Control

Snaphshots are stored:
checkins over time

Version 1 file A file B file C

Version 2 file A file B file C

Version 3 file A file B file C

Version 4 file A file B file C

Version 5 file A file B file C

c 2011-13 G.L. Heileman

Module 2, Lecture 5

8/9

Distributed Version Control

Distributed development:
Server Version Database Version 3
files: A, B, C

pull/push Developer 1 Editor fileA A file Version Database Version 3

files: A, B, C

pull/push Version 2
files: A, B, C

Developer 2 Version Database Version 3

files: A, B, C

Editor fileA A file

Version 1
files: A, B, C

Version 2
files: A, B, C

Version 2 pull/push
files: A, B, C

Version 1
files: A, B, C

Version 1
files: A, B, C

c 2011-13 G.L. Heileman

Module 2, Lecture 5

9/9

Web Application Architectures

Module 2: Ruby on Rails Lecture 6: Git and Rails

c 2011-13 G.L. Heileman

Module 2, Lecture 6

1/6

Distributed Version Control with Git

Git is a popular open source distributed version control system created in 2005 by the Linux development community and used extensively in the Rails community. Git provides means for comparing the dierences between the various versions of a project (think of them as project snapshots), and for merging them accordingly. You should think of these versions as forming a tree:
Main development branch = master. New versions may be created along the master branch, or new branches can be created o of it. These branches can possibly be merged back into the master branch.

c 2011-13 G.L. Heileman

Module 2, Lecture 6

2/6

Git Basics
Git tracks les, which may reside in three locations:
Working directory Staging area Git repository

Furthermore, the les in your working directory can be in one of two states:
Tracked: les that were saved to the Git repository by the last commit operation. Untracked: all other les in your working directory.

Finally, tracked les can be either:

Modied Unmodied Staged
c 2011-13 G.L. Heileman Module 2, Lecture 6 3/6

Git WorkowLocal Repository

commit -a add . commit

working directory

staging area
checkout <branch> merge <branch>

local git repository

c 2011-13 G.L. Heileman

Module 2, Lecture 6

4/6

Git WorkowRemote Repository

commit -a add . commit

push <remote> <branch>

working directory

staging area
checkout <branch>

local git repository

remote git repository

fetch merge <branch>

clone <remote> or pull <remote>

c 2011-13 G.L. Heileman

Module 2, Lecture 6

5/6

Creating a Git Repository at Bitbucket

c 2011-13 G.L. Heileman

Module 2, Lecture 6

6/6