Ruby on Rails is a web application framework written in Ruby that emphasizes convention over configuration and rapid development. It includes modules for modeling data with ActiveRecord, handling requests and responses with ActionController and ActionView, and additional features like routing and internationalization. The document then provides more details on the history, philosophy, main components, and features of Rails.

1. Ruby on Rails
Rapid, solid, flexible application
development

2. I am ...
Bálint Érdi
(Budapest, Hungary)
blog: http://bucionrails.com
email: balint@bucionrails.com
My evolution :)
java web developer
python web developer
(freelance) ruby web developer and consultant
(with occasional non-web works)

3. Hungary

4. Legend
Facts: (Wisdom :) )
Ruby is object oriented
Code:
5.times { print "Hello Fluidtime!" }

5. Outline
1. Ruby basic concepts
2. Rails
History & philosophy
Basic modules
Introducing each module
Other features (a selection of them)
Who uses Rails?
3. Demo app
Questions are welcome anytime

6. Ruby: History
created by Yukihiro Matsumoto ~1995
it is a blend of his favorite languages (Smalltalk, Lisp, Perl,
ADA)
open source [RUBY]
now at 1.9

7. Ruby is object oriented
But it really is
Everything is an object
Every object has a class
Classes are objects, too
5.times { print "Hello, Fluidtime!" }
3 + 2 # => 5
3.+(2) # => 5
3.send(:+, 2) # => 5

8. Ruby is duck-typed (dynamically typed)
behavior is more important than type ("if it walks like a duck
and talks like a duck, it is a duck")
no type declarations are needed
a = 3
a + 2 # => 5
a + " jeff" # => TypeError
a = "hello"
a + 2 # => TypeError
a + " jeff" # =>"hello
jeff"

9. Ruby is functional programming like
Functional programming
methods are first-class citizens of the language
lets you concentrate on what you want instead of how you
want to do it (because "for" loops are ugly)
Helps keep the code cleaner, more elegant and less error-
prone.
e.g Lisp
[119, 43, 982, 266].select { |n| n % 7 == 0 }
["voodoo", "kayak", "light"].find { |w| w
=~ /^(.).*1$/ }
(1..4).map { |n| n**2 }

10. Ruby has strong metaprogramming
features
define methods at runtime, on the fly (define_method)
evaluate code in the context of an instance or a class
(instance_eval, class_eval)
get in control when the object does not have a certain
method (method_missing)
... or when a name is not found(const_missing)

11. Ruby has open classes, all of them
Any class can be reopened, "core" classes, too
you can define new methods, override new ones, etc.
class definitions can thus span files
class Numeric
def plus(n)
self.+(n)
end
end
3.plus(2) # => 5

12. Rails résumé
Rails is a powerful yet simple web framework written in Ruby
History
Philosophy
Introducing the main building blocks
Other included features
Extending Rails functionality
Who uses Rails?

13. History
created by David Heinemeier Hansson, ~2003 [ROR]
extracted framework from a project called Basecamp
open source, community driven, ~1400 contributors during
its history
now at 2.3, going for 3.0

14. Rails basic ideology
Very opinionated: encourages "best practices"
"Convention over configuration" to avoid bloatware and
keep things simple in most cases
Possibility to change default behavior in special cases
Sugar and vinegar: easy to do what is encouraged, possible
(but probably not simple) to do "unrecommended" things.
Test Driven Development (TDD) is extremely important
(writing tests first, so an automated test suit that can be
easily -and quickly- run is needed)
The framework has to stay small and lean but provide a
mechanism for easy expansion.

15. Rails: Consequences of the ideology
Why is all this important?
enables you to be more productive by following the
"guidelines"
enables you to concentrate on the business logic without
worrying about the technical details
you will feel happy because it is so elegant and and feeling
good!
you will feel good because it is so efficient

16. Rails main building blocks
Model - View - Controller (MVC) framework
Model: ActiveRecord
Controller: ActionController
View: ActionView
Clear separation of concerns
Additional modules
ActionSupport for supporting libs
ActiveResource for REST compliance
ActionMailer for sending emails

17. The model: ActiveRecord
Database engine agnosticism
Database migrations
Associations between models
Validations
Callbacks

18. ActiveRecord: database agnosticism
it is an ORM (Object Relational Mapping)
you should not have to worry about what lies underneath
you should not have to write SQL
Adapters exist for sqlite, mysql, postgresql
Post.find(:all, :conditions => [ "created_at >
?", 2.days.ago ])

19. ActiveRecord: Database migrations
to make sure
... not just the code, but the database schema is tracked,
too
... all developers work with the same schema
... you don't have to write raw SQL
.. you are able to jump to any version, just like with a SCM
... deployment stays simple: you just run the migrations
Examples of what a migration could do:
creating a posts table
adding a user_id to the posts table
changing column type from boolean to string

20. ActiveRecord: Associations 1.
class Blog < ActiveRecord::Base
has_many :posts
end
class Post < ActiveRecord::Base
belongs_to :blog
has_many :comments
end
* using the control that Ruby gives for finding names
(const_missing)

21. ActiveRecord: Associations 2.
reaching associated object(s):
blog.posts.find(:first, :conditions =>
["updated_at > 1.week.ago])
creating associated object(s):
post.comments.create(:user => me, :body =>
"That's a great post, congratulations!")
* leveraging Ruby metaprogramming capabilities

22. ActiveRecord: Validations
validation is business logic so it belongs to the model
use the provided validators which cover most of the cases
validates_presence_of :login
validates_format_of :zip_code, :with =>
/^d{5}$/
roll your own for the special cases

23. ActiveRecord: Callbacks
Entry points (hooks) that implement business logic at
different during the lifecycle of the object
lifecycle events: create, save, update, validate, destroy
provided methods: before_save, after_create, ...
good for setting default values, set calculated attributes,
send out emails, etc.

24. ActionController: Résumé
Basic buildup
Filters
Rendering from controller actions

25. ActionController: Basic buildup
The controller should be thin and should only contain:
... actions (methods) that compose the API
... filter calls
... the actual filter implementations
Actions
new
create
edit
destroy
...

26. ActionController: Filters
Filters are
... methods that run before, after or around actions
... prevalently used for checking authorization to resources
... used to set variables for templates in a DRY way

27. ActionController: Rendering
The controller sets the variables that the view template will use
and does the actual rendering
By default, the view with the name of the action is rendered
But it can also render
any action by name
a text (mainly for debugging purposes)
other representations of resources (e.g js, json, xml, etc.)
nothing (just returning something to the caller)

28. ActionView: Résumé
Basics
Partials & content blocks

29. ActionView: Basics
The view:
... is a representation
... should contain the least possible amount of business
logic
... is rendered by the ERB template language which can be
changed with plugins (check out haml! [HAML])
Lots of view helpers are provided for generating html
some helpers (e.g form_for) are context-sensitive so
views can be reused without cluttering them with conditions

30. ActionView: Partials & Content blocks
Partials
chunks of reusable code you can render from other views
Content blocks
separate definition of the building blocks of a page and
actually generating them.
make it possible to break the link between the order of html
in the template and their order on the generated page
are ideal for setting a subsection in the html title of a page
injecting per-page javascripts

31. A selection of Rails' features
Sending emails with ActionMailer
Context-dependent configurations
Routing
RESTful applications
Internationalization & Localization
Generators
Caching
Extending core functionality
Handling dependencies

32. Sending emails with ActionMailer
mailers are models
one email template (a view template) for each email type
one method in the mailer model for each email type that
sets the variables for rendering the email
sending out an email is calling a method on the mailer
there is convention for finding the template name from the
method's name

33. Context dependent configurations
(environments)
Development: used for development with throwaway data
Test: used for automated testing, records are created and
destroyed by each test run.
Production: used by the live application. Handle with care.
Common configuration file + each env. has its own config
which overwrites the values set in the common one.
Additional environments can easily be set up
Example: emails should be sent out in production, examined
but not sent out when testing and it is up to you in
development

34. Router
generates user-friendly names you can use in your code (e.
g dashboard_path and dashboard_url)
makes your routes DRY. You don't have to put hardwired
routes into your application
makes dangling links nearly impossible
routes incoming requests to the appropriate action
it is a SEO tool
map.dashboard '/', :controller => 'dashboard',
:action => 'show'
map.search '/search/:term', :controller =>
"search", :action => "index", :term => /w*/

35. RESTful applications
"HTTP is actually a general purpose protocol for applying
verbs to nouns" [REST]
encouraged as best practice
declaring a resource generates the RESTful routes
map.resources :users
verb path generated path name
GET /users/new new_user_path
POST /users users_path
GET /users/:id/edit edit_user_path(id)
PUT /users/:id user_path(id)
GET /users users_path
DELETE /users/:id user_path(id)

36. Internationalization (I18n) &
Localization
Internationalization:
Turns a one-language site into a international one
Has translations for built-in messages (e.g for validation
errors) for most languages
Translations can easily be added in sep. "locale" files
Localization:
localizes displayed data to the actual language/country
date, time, month names, day names, currency, etc.

37. Generators
Generates files and content for common tasks
Available from the command line
Because laziness is a virtue in a programmer :)
Models, controllers, resources, migrations,
Plugins can easily add their generators

38. Caching
Granular:
page caching
Static pages that do not need Rails to enter the
picture (e.g about us, terms & conditions)
action caching
Pages that rarely change but that need certain filters
to run (e.g pages that can only viewed once logged
in)
fragment caching
only cache certain parts of a page (e.g sidebar)

39. Consistent core, dead simple extension
User authentication, pagination, attaching files, etc. to
models are not part of Rails
Possible extensions:
plugins are bundled with the application
gems can be bundled with the application (which is good
practice to do) or installed system-wide

40. Handling dependencies
vendor directory for dependencies:
vendor/gems
vendor/plugins
vendor/rails
and automated tasks to manage them
Examples:
$ rake rails:freeze:edge
$ rake gems:unpack:dependencies

41. Who uses Rails?
twitter.com
yellowpages.com
github.com - social coding
lighthouseapp.com - issue tracker app
shopify.com - webshop generation and hosting
...
from small-scaled applications to high-traffic ones
for really simple stuff it could be an overkill (in these cases
use Sinatra, another ruby framework :) [SIN])

42. Time for a demo app!
http://github.
com/balinterdi/par_avion/tree/maste
r

43. Questions?
Bálint Érdi
blog: http://bucionrails.com
email: balint@bucionrails.com
twitter: http://twitter.com/baaz

44. References
[HAML] http://haml.hamptoncatlin.com/
[RUBY] http://ruby-lang.org/
[ROR] http://rubyonrails.org/
[REST] http://tomayko.com/writings/rest-to-my-wife
[SIN] http://www.sinatrarb.com/