1. Pragmatic Patterns
of Ruby on Rails
Yasuko OHBA( )

2. what I do
• developer of Rails applications
•
• Everyleaf Corporation

4. sponsor booth
• first time to be a sponsor
• we serve candies
• you can play ‘Romantic Ruby’ !

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

8. personal message

9. I started
programming when I
was 14 years old

10. school for girls

11. I was alone

12. got the job

13. find similar people

14. however

15. ‘enterprise’

16. only activities
inside the company

17. other things
mount up

18. I was lost

19. want to write codes

20. that’s when..

21. Ruby was given

22. life becomes happier

23. Ruby for enterprises

24. the way to live
happily writing codes

25. And...

26. great communities

27. many friends

28. thank you !!

29. today’s presentation

30. coding patterns
with
Ruby on Rails

31. the target
• large & complicated applications
• team

32. problems of large
applications
• different coding styles
• nasty parts made

33. becomes harder
to maintenance

34. keep your codes
nice

35. what is the ‘nice code’?
• good design
• easy to understand
• easy to find something wrong

36. coding patterns work fine
• make and share coding patterns
• add some DSL (not too much)

37. efficient, of course

38. what I won’t say
• how to get the best performance
• ActiveRecord’s alternatives

39. ActiveRecord

40. frankly speaking,

41. I love ActiveRecord

42. because

43. OOP

44. still able to maintenance
when it gets complicated

45. pragmatic

46. the heart of RoR

47. many AR features in
this presentation

48. examples

49. show permitted data

50. find starts from
an AR object

51. find a note by id
/note/3
def show
@note = Note.find(params[:id])
end

52. find a note of the current user
/note/3
@note = Note.find_by_id_and_user_id(
params[:id], current_user.id)
raise ActiveRecord::RecordNotFound unless @note

54. /note/3
@note = Note.written_by(
curret_user.id).find(params[:id])

55. hard to notice
the luck of condition!
@note = Note.find(params[:id])
@note = Note.find_by_id_and_user_id(
params[:id], current_user.id)
@note = Note.written_by(
current_user).find(params[:id])

56. so,

57. find starts from
an AR object

58. starts from an object
def show
@note = current_user.notes.find(
params[:id])
end

59. use the association
def show
@note = current_user.notes.find(
params[:id])
end

60. association
class User < ActiveRecord::Base
has_many :notes
end

61. easy to notice problems
@note = current_user.notes.find(
params[:id])
@note = Note.find(params[:id])

62. easy to see
who can access

63. who can access
@note =
current_user.notes.find(
params[:id])

64. filters to find
the starting AR object

65. with the previous
pattern

66. most actions will
use the AR object

67. example;
CRUD of the specified
group’s notes

68. • URL
• /groups/15/notes
• /groups/15/notes/3

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

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

71. the duplicated line
@group = Group.find(params[:group_id])

72. write that line
in a filter

73. what’s the filter?
• the separated logic which would be
called around action
• declarative

74. find the group in a filter
class GroupNotesController < ApplicationController
before_filter :find_group
.......actions ......
private
def find_group
@group = Group.find(params[:group_id])
end
end

75. DRY
before_filter :find_group
def index
@notes = @group.notes.paginate(:page =>
params[:page])
end
def show
@note = @group.notes.find(params[:id])
end

76. easy to change
access control

77. example; change to allow
access to members only
def find_group
@group = current_user.groups.find(
params[:group_id]
end

78. other merits

79. secure

80. safe if it starts from @group
def index
@notes = @group.notes.paginate(:page =>
params[:page])
end
def show
@note = @group.notes.find(params[:id])
end

81. filter urges developers
to use @group

82. and

83. readable

84. you can understand
the controller’s summary
from name and filters

85. understand the summary
quickly
class GroupNotesController <
ApplicationController
before_filter :find_group

86. the points
• a good controller name
• readable filters

87. complicated
business logics

88. want to write
business logics
in models

89. because

90. merits of writing
business logics in models
• easy to test
• easy to reuse
• readable, easy to find the target codes

91. however

92. ‘how’ matters a lot

93. a bad example
class MyModel < ActiveRecord::Base
def do_create(params)
....
def do_destroy(params)
...
end

94. why is it bad ?
• it breaks MVC
• hard to reuse

95. now

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

97. move the logic
branching on parameters
from C to M

98. branching on parameters
def update
@note.attributes = params[:note]
@tags = params[:auto_tagging] == '1' ?
generate_tags(@note) : []
# do saving and tagging
...
end

99. often written in
controller

100. to move to model

101. add an attribute for
branching to the model

102. the condition
params[:auto_tagging] == '1'

103. as an attribute of the model
class Note < ActiveRecord::Base
attr_accessor :auto_tagging
end

104. change parameters structure
{ :note => {.....}, :auto_tagging => '1' }
{ :note => { ....., :auto_tagging => '1' }}

105. change the view for it
<%= check_box_tag :auto_tagging %>
<% form_for :note, ... do |f |%>
<%= f.check_box :auto_tagging %>
<% end %>

106. now it’s in params[:note]
def update
@note.attributes = params[:note]
if params[:auto_tagging] == '1'
generate_tags(@note)
end
.....

107. can branch in the model
class Note < ActiveRecord::Base
....
if auto_tagging
...
end
end

108. finished to move
branching

109. move generate_tags next

110. move the logic
processing other models
from C to M

111. 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

112. also often written in
controller

113. put it into model’s callback
class Note < ActiveRecord::Base
before_save :generate_taggings
private
def generate_taggings
return unless auto_tagging
tags = Tag.extract(body)
self.tag_list = tags.join(',')
end
end

114. what’s the model’s callback?
• methods called before/after save or
destroy

115. Rails Model You
normal method call
save
(validation)
before_save
do saving
after_save

116. self-directive
models

117. now we’ve done it !
• easy to test
• easy to reuse
• readable, easy to find the target codes

118. 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

119. the last topic

120. how to find
coding patterns

121. in my case

122. try to choose
the most natural style
for RoR

123. what is the most
natural way
in Ruby on Rails?

124. 1. OOP

125. express business
logics as models

126. always think who
should do that job

127. Note or User ?
@note = Note.find_by_id_and_user_id(
params[:id], current_user.id)
@note = current_user.notes.find(
params[:id])

128. you can’t always
decide it from tables

129. decide it
in objects world

130. 2. follow the
principles of RoR

131. principles of RoR
• DRY
• CoC
• RESTful

133. accept RESTful
in Ruby on Rails

134. how to design
controllers ?

136. one controller for
a type of resources

137. what’s the resources?

138. you can find it in URL
/companies/everyleaf/notes/3

139. design of controllers

140. starts from
design of URLs

141. roughly speaking,

142. Model Class
1
1..*
Resource

143. the point is...

144. one controller should
provide one resource
type’s CRUD

145. might have been derailed
class BlogsController < ApplicationController
def create_comment
end
def comments
end
def destroy_comment
...

146. one more

147. write codes in model’s
standard flows

148. standard flows
• find
• new → save (create)
• find → save (update)
• find → destroy

149. inside of a flow

150. new attribute = before_
build validation
before_ after_ validation
save validation
creation
after_save

151. write codes in
appropriate place

152. where, what
new attribute = before_
build validation
before_ after_ validation
save validation
creation
after_save

153. try to choose
the most natural style
for RoR

154. don’t go too far
from the basic styles

155. because

156. it’s normal to
Rails programmers

157. easy to read
for everyone

158. for that purpose

159. use Ruby’s flexibility

160. summary

161. in developing
large & complicated
application

162. it’s important
to keep codes nice

163. for that purpose

164. be aware of coding
patterns,
and share them

165. coding patterns
fitting Ruby on Rails

166. make source codes
easy to read for
general developers

167. it means
easy to maintain

168. thank you !