1. RAILS IS FROM MARS
RUBY IS FROM VENUS
Relationship Advice For Rails Developers

2. WHO AM I?
• My name is Rein Henrichs.
• That’s pronounced like “rain”.
• But spelled differently.
•I work at
•I blog at reinh.com
•I twitter @reinh
•I like candlelit dinners and long walks on the beach.

3. insert logo
here
:(
YOU KNOW RAILS

4. BUT DO YOU KNOW RUBY?

5. How many people here use Rails?

6. How many of you think you know
Ruby as well as you know Rails?

7. How many of you have
contributed to an open-source
Ruby project?

8. How many of you have
written your own gem?

9. How many of you would be
comfortable writing an HTTP
client library in Ruby?

10. How many of you could write
your own web framework?

11. WHY SHOULD I LEARN RUBY?
• It’s easy.
• It’s fun.
• It will make you better at Rails.
• It will make you a better person.

12. HOW DO I LEARN RUBY?
Some resources

13. Free stuff

14. WHY’S POIGNANT GUIDE
It has cartoon foxes. Foxen? It has cartoon foxen.

15. PROGRAMMING RUBY
a.k.a. The Pickaxe

16. MR. NEIGHBORLY’S
HUMBLE LITTLE
RUBY BOOK
Pragmatically chunky bacon

17. Not so free stuff
(but still really good)

18. RUBY IN A
NUTSHELL
Come on. Matz wrote it.

19. RUBY IN
PRACTICE
Look at that funny looking guy
on the cover. At least it’s not a
nasty monkey. Sorry, O’Reilly

20. THE RUBY
WAY

21. RUBY FOR
RAILS

22. THE WELL-
GROUNDED
RUBYIST

23. RAILS HAS OPINIONS
And Ruby Likes To Talk

24. Rails is opinionated software

25. Ruby is a communicative language

26. Sometimes, Ruby just wants
someone to listen to it.

27. If you’re programming along, doing nicely, and
all of a sudden your program gets balky, makes
things hard for you, it’s talking. It’s telling you
there is something important missing.
– Kent Beck, Smalltalk Best Practice Patterns

28. It is your responsibility to
listen to your code and be
considerate of its needs.

29. Write Ruby code that
communicates well but be
respectful of Rails’ opinions

30. Other people who use your code
(including six-months-later you)
will thank you.

31. Ruby makes it easy to write
simply, clearly and expressively

32. Rails has powerful idioms
and conventions

33. Combining the two makes for a
happy, fulfilling relationship

34. RUBY LOVES YOU
But Sometimes You Drive Her Crazy

35. These are some of the things you
do that drive Ruby crazy.

36. You’re welcome.

37. # Bad
i = 0; while i < array.size do
puts array[i]
i += 1
end
# Better
for item in array
puts item
end
# Best
array.each do |item|
puts item
end

38. WHY?
• Ruby has powerful iterators.
• You don’t need to write your own.
... in ... just calls #each internally.
• for

39. # Bad
value = value ? value : quot;defaultquot;
# Better
value = value || quot;defaultquot;
# Best
value ||= quot;defaultquot;

40. WHY?
• Ternaries (the ? : thing) are ugly.
• Ruby has pretty assignment with operators like += and ||=

41. # Bad
array << 42 unless array.include?(42)
array = array + [42] unless array.include?(42)
# Better
array = array | [42]
# Best
array |= [42]

42. WHY?
• Sometimes it just helps to know what set union is.

43. # Bad
if value != nil && value != false
# Good
if value

44. WHY?
• Ruby has a sane notion of truthiness

45. # Bad
if value == 1 || value == 12 || value == 42
# Good
if [1,12,42].include? value

46. WHY?
• Brevity is not the goal
• Readability is the goal
• But if it is more readable and also shorter, go for it.

47. # Bad
def request
begin
perform_request
rescue RequestError => e
log_error e
end
end
# Good
def request
perform_request
rescue RequestError => e
log_error e
end

48. WHY?
• Method definitions are an implied begin block.

49. # Bad
!!value
# Good
value

50. WHY?
• Ruby does not not like clarity.
• What you lose in readability you gain in nothing.

51. # Bad
ActiveRecord::Base
# Good
ActiveRecord::Model

52. WHY?
• Naming things is important.
• Base? What does that even mean?
• Sorry Rails, you got this one wrong. Better luck next time.

53. # Bad
class PostsController < ApplicationController
def recent
Post.find :all,
:conditions => ['posts.created_at > ?',
1.week.ago]
end
end

54. # Good
class PostsController < ApplicationController
def recent
Post.within 1.week
end
end

55. class Post < ActiveRecord::Base
named_scope :within,
lambda {|seconds| :conditions => ['posts.created_at > ?',
seconds.ago]}
end

56. WHY?
• Make your code more expressive
• And more intention revealing.
• In other words, say what you mean to say.

57. url_for(:blog, :posts, @post.id, :comments, :replies => true)
# => http://example.com/blog/posts/19/comments?replies=true

58. # Bad
def url_for(*args)
root + args.map{|arg| parse_arg(arg)}.join('/').
gsub('/?', '?')
end
def parse_arg(arg)
case arg
when Array: arg.join('/')
when Hash
ret = []
each{|k,v| ret << quot;#{k}=#{v}quot;}
ret = ret.join('&')
'?' + ret
else: arg.to_s
end
end

59. # Good
def url_for(*args)
root + args.to_params
end

60. class Array
def to_params
map{|a| a.to_params}.join('/').
gsub('/?', '?')
end
end

61. # Array
%w(foo bar bazz).to_params # quot;/foo/bar/bazzquot;
# Hash
{:foo => :bar}.to_params # quot;?foo=barquot;

62. WHY?
• Ruby uses coercion in many places
• 1.to_s
• (1..10).to_a
• Writingyour own coercion method can help you use Ruby’s
ducktyping.
• Separation of concerns.

63. RAILS PERFORMANCE
Insert your “scaling” and “premature optimization” jokes here.

64. Yes, I went there.

65. Slow is only meaningful
in comparison.

66. Ruby is slow? Compared to what?

67. Is your database slow?

68. Are your views slow?

69. Is your app server slow?

70. Are you using HTTP
via carrier pigeon?

71. If you don’t know where the slow
is, you’re not ready to optimize.

72. Don’t optimize prematurely, but
don’t pessimize either.

73. Don’t write code you know will
never, ever be fast.

74. # Really Bad (Optimally Pessimum)
class Ballot < ActiveRecord::Base
def <=>(other)
votes.count <=> other.votes.count
end
end
# Good (Potentially Optimum)
class Ballot < ActiveRecord::Base
# With a counter_cache on votes
default_scope :order => :votes_count
end

75. IN OTHER WORDS
• Don’t worry about speed until you know where the slow is.
• Worry about writing simply and expressively.
• Well written code is easy to optimize for performance later.
• Don’t write something you know will never, ever be fast.

76. IN CONCLUSION
• Ruby is fun and easy (and friendly!).
• Ruby will make you happy.
• Be more thoughtful in the way you treat Ruby.
• The more Ruby you know, the better you can become at Rails.
• If you love Rails, you should love Ruby too.
• Also, don’t be premature. No one likes that.

77. WHO AM I?
• My name is Rein Henrichs.
• That’s pronounced like “rain”.
• But spelled differently.
•I work at
•I blog at reinh.com
•I twitter @reinh
•I like candlelit dinners and long walks on the beach.