Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009

Pragmatic Patterns
of Ruby on Rails

Yasuko OHBA( )

what I do

• developer of Rails applications
•
• Everyleaf Corporation

sponsor booth

• ﬁrst time to be a sponsor
• we serve candies

• you can play ‘Romantic Ruby’ !

my products

• home accounting web service
http://www.kozuchi.net
• http://github.com/everyleaf/kozuchi/
tree

I started
programming when I
was 14 years old

only activities
inside the company

the way to live
happily writing codes

coding patterns
with
Ruby on Rails

the target

• large & complicated applications
• team

problems of large
applications

• different coding styles
• nasty parts made

what is the ‘nice code’?

• good design
• easy to understand
• easy to ﬁnd something wrong

coding patterns work ﬁne

• make and share coding patterns
• add some DSL (not too much)

what I won’t say

• how to get the best performance
• ActiveRecord’s alternatives

still able to maintenance
when it gets complicated

many AR features in
this presentation

ﬁnd starts from
an AR object

ﬁnd a note by id

/note/3
def show
@note = Note.ﬁnd(params[:id])
end

ﬁnd a note of the current user

/note/3
@note = Note.ﬁnd_by_id_and_user_id(
params[:id], current_user.id)
raise ActiveRecord::RecordNotFound unless @note

/note/3

@note = Note.written_by(
curret_user.id).ﬁnd(params[:id])

hard to notice
the luck of condition!

@note = Note.written_by(
current_user).ﬁnd(params[:id])

starts from an object

def show
@note = current_user.notes.ﬁnd(
params[:id])
end

use the association

def show
params[:id])
end

association

class User < ActiveRecord::Base
has_many :notes
end

easy to notice problems

params[:id])


who can access

@note =
current_user.notes.ﬁnd(
params[:id])

ﬁlters to ﬁnd
the starting AR object

with the previous
pattern

most actions will
use the AR object

example;
CRUD of the speciﬁed
group’s notes

• URL

• /groups/15/notes
• /groups/15/notes/3

• Note has group_id
class Note < ActiveRecord::Base
belongs_to :group
end
class Group < ActiveRecord::Base
has_many :notes
end

def index
@group = Group.ﬁnd(params[:group_id])
@notes = @group.notes.paginate(:page =>
params[:page])
end
def show
@note = @group.notes.ﬁnd(params[:id])
end

the duplicated line


write that line
in a ﬁlter

what’s the ﬁlter?

• the separated logic which would be
called around action

• declarative

find the group in a filter

class GroupNotesController < ApplicationController
before_filter :find_group
.......actions ......
private
def find_group
end
end

DRY

def index
params[:page])
end
def show
end

example; change to allow
access to members only

def ﬁnd_group
@group = current_user.groups.ﬁnd(
params[:group_id]
end

safe if it starts from @group

def index
params[:page])
end
def show
end

ﬁlter urges developers
to use @group

you can understand
the controller’s summary
from name and ﬁlters

understand the summary
quickly

class GroupNotesController <
ApplicationController

the points

• a good controller name

• readable ﬁlters

want to write
business logics
in models

merits of writing
business logics in models

• easy to test
• easy to reuse
• readable, easy to ﬁnd the target codes

a bad example

class MyModel < ActiveRecord::Base
def do_create(params)
....
def do_destroy(params)
...
end

why is it bad ?

• it breaks MVC
• hard to reuse

let’s move codes
from controller to model
in good way

move the logic
branching on parameters
from C to M

branching on parameters

def update
@note.attributes = params[:note]
@tags = params[:auto_tagging] == '1' ?
generate_tags(@note) : []

# do saving and tagging
...
end

often written in
controller

add an attribute for
branching to the model

the condition

params[:auto_tagging] == '1'

as an attribute of the model

attr_accessor :auto_tagging

end

change parameters structure

{ :note => {.....}, :auto_tagging => '1' }

{ :note => { ....., :auto_tagging => '1' }}

change the view for it

<%= check_box_tag :auto_tagging %>

<% form_for :note, ... do |f |%>
<%= f.check_box :auto_tagging %>
<% end %>

now it’s in params[:note]

def update
@note.attributes = params[:note]
if params[:auto_tagging] == '1'
generate_tags(@note)
end
.....

can branch in the model

....
if auto_tagging
...
end
end

ﬁnished to move
branching

move the logic
processing other models
from C to M

the logic
processing other models

def update
generate_tags(@note)
end
private
def generate_tags(note)
tags = Tag.extract(note.body)
note.tag_list = tags.join(',')
end

also often written in
controller

put it into model’s callback

before_save :generate_taggings

private
def generate_taggings
return unless auto_tagging
tags = Tag.extract(body)
self.tag_list = tags.join(',')
end
end

what’s the model’s callback?

• methods called before/after save or
destroy

Rails Model You
normal method call

save
(validation)

before_save
do saving

after_save

now we’ve done it !

• easy to test
• easy to reuse
• readable, easy to ﬁnd the target codes

other patterns

• multi levels for validation

• design & coding policy for STI

• use owner object’s attributes in association

• how to make routes.rb a little readable

try to choose
the most natural style
for RoR

what is the most
natural way
in Ruby on Rails?

express business
logics as models

always think who
should do that job

Note or User ?


params[:id])

you can’t always
decide it from tables

2. follow the
principles of RoR

principles of RoR

• DRY
• CoC
• RESTful

accept RESTful
in Ruby on Rails

one controller for
a type of resources

you can ﬁnd it in URL

/companies/everyleaf/notes/3

Model Class

1
1..*

Resource

one controller should
provide one resource
type’s CRUD

might have been derailed

class BlogsController < ApplicationController
def create_comment
end
def comments
end
def destroy_comment
...

write codes in model’s
standard ﬂows

standard flows

• find
• new → save (create)
• find → save (update)
• find → destroy

new attribute = before_
build validation

before_ after_ validation
save validation

creation
after_save

write codes in
appropriate place

where, what
new attribute = before_
build validation

before_ after_ validation
save validation

creation
after_save

don’t go too far
from the basic styles

it’s normal to
Rails programmers

in developing
large & complicated
application

it’s important
to keep codes nice

be aware of coding
patterns,
and share them

coding patterns
ﬁtting Ruby on Rails

make source codes
easy to read for
general developers

Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009 (20)

More from Yasuko Ohba (15)

Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009