The document discusses considerations for teaching Ruby on Rails. It notes that students come with a wide range of experience, from true beginners to veteran developers, and the content must be tailored accordingly. Managing student expectations is important, as the hype around Rails can raise expectations that are difficult to meet for beginners. Follow-through after initial lessons is also key to student retention, such as providing a roadmap for further learning.

1. So You Want to Teach
Ruby and Rails...
Bryan Bibat

7. So You Want to Teach
Ruby and Rails...
Bryan Bibat

9. Not as easy as it looks...

10. You have to take many things into
account in order to be an
effective teacher.

11. Unfortunately, I only have 30 minutes
so I'll just cover the main points.

12. 0. Students

13. 1. Domain

14. Web Development Knowledge Layersincreasingcomplexity

15. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION

16. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION
APPLICATION

17. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION
APPLICATION
DATA

18. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE

19. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE

20. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING

21. Web Development Knowledge Layersincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

22. Rails is an intermediate-level toolincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

23. Rails is an intermediate-level toolincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

24. 1. Domain

25. 0. Students
1. Domain

26. Beginners

27. True Beginner

28. True Beginnerincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

29. True Beginnerincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

30. True Beginnerincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

31. Ruby is great for True Beginnersincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

32. Rails is notincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

33. Web Beginner

34. Web Beginnerincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

35. Web Beginnerincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

36. Veteran

37. Veteran Web

38. Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

39. Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

40. Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

41. Ninja

42. Polyglot / Full Stack Developer

43. Polyglotincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

44. Polyglotincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

45. When I started Rails...

46. me c.2009 - Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

47. me c.2009 - Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

48. me c.2009 - Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

49. me c.2009 - Veteran Webincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

50. Migrations
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :email
t.string :password
t.string :crypted_password
t.string :password_salt
t.string :persistence_token
t.timestamps
end
end
def self.down
drop_table :users
end
end

51. Migrationsincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

52. Migrationsincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

53. Migrations made sense to me.

55. Migrations
mind = blown

56. Migrations - experience overlapincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

57. now compare this with newbies'...

58. Migrationsincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

59. Migrations - WTF?!?increasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

60. Migrations

61. Migrations
Routing
ActiveRecord
Convention over Configuration
Test Driven Development

62. Migrations
Routing
ActiveRecord
Convention over Configuration
Test Driven Development
Ruby Idioms
Higher Order Functions

63. Migrations
Routing
ActiveRecord
Convention over Configuration
Test Driven Development
Ruby Idioms
Higher Order Functions
Asset Pipeline
Turbolinks
DevOps

64. Wow
such migrations
much unit tests
very omakase
railz so amaze
@doge ||= 9000
so turbolinks
so restful

65. Wow
such migrations
much unit tests
very omakase
railz so amaze
@doge ||= 9000
so turbolinks
so restful
screw this, I'm going back to
[language]

66. You have to bridge the gapincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

67. 2. Purpose

68. To understand how our students think,
we must first ask ourselves:
Why are we here?

69. To understand how our students think,
we must first ask ourselves:
Why are we here?
How did it come to this?

70. The Hype Cycle
Image: http://en.wikipedia.org/wiki/User:Jeremykemp

71. But there are other hype cycles...
original image: http://en.wikipedia.org/wiki/User:Jeremykemp

72. Also the technology is far from perfect...

73. Ruby - a multi-paradigm scripting language

74. Ruby...
●
is slow
●
is memory intensive
●
developers are hard to find
●
has all the cons of a dynamically typed language

75. Ruby on Rails - an MVC framework

76. Rails...
●
is huge and bloated
●
has magical abstractions
●
is hard to deploy

77. So why?

78. It's not the technology
but the way of thinking

79. History of Web Languages/Platforms
up to mid-00s

80. CGI/Perl scripting →

81. CGI/Perl scripting →
Compiled Language (Java, C#)
Templating Language (PHP)

82. CGI/Perl scripting →
Compiled Language (Java, C#)
Templating Language (PHP)
→ Object/Functional Scripting as an option

83. ●
is slow
●
is memory intensive
●
developers are hard to find
●
has all the cons of a dynamically typed language
BUT ALSO
●
expressive
●
functional, OO, with metaprogramming
●
developers examples of the Python Paradox
●
has all the pros of a dynamically typed language

84. History of Web Applications
up to mid-00s

85. big ball of mud →

86. big ball of mud →
over-designed frameworks

87. big ball of mud →
over-designed frameworks
→ a compromise

88. ●
is huge and bloated
●
has magical abstractions
●
is hard to deploy
BUT ALSO
●
a decent package of design patterns
●
good for prototyping ie. has a good amount of
features built-in while being extensible
●
continuously improving along recent trends

89. A way of thinking that worked

90. AND...

91. It took advantage of the hype cycle.
original image: http://en.wikipedia.org/wiki/User:Jeremykemp

92. It took advantage of the hype cycle.
original image: http://en.wikipedia.org/wiki/User:Jeremykemp
One of the first to use it successfully
to achieve critical mass

93. history lesson over...

94. 2. Purpose

95. 0. Students

96. The HYPE is what got us in...
Image: http://en.wikipedia.org/wiki/User:Jeremykemp

97. The HYPE is what got us in...
Image: http://en.wikipedia.org/wiki/User:Jeremykemp

98. The HYPE is what got us in...
Image: http://en.wikipedia.org/wiki/User:Jeremykemp

99. ...but the HYPE is also what keeps newbies out.
Image: http://en.wikipedia.org/wiki/User:Jeremykemp

100. Image: http://en.wikipedia.org/wiki/User:Jeremykemp

101. Expectations are not met.
Image: http://en.wikipedia.org/wiki/User:Jeremykemp

102. Manage Expectations

103. ●
is slow
●
is memory intensive
●
developers are hard to find
●
has all the cons of a dynamically typed language
BUT ALSO
●
expressive
●
functional, OO, with metaprogramming
●
developers examples of the Python Paradox
●
has all the pros of a dynamically typed language

104. ●
is huge and bloated
●
has magical abstractions
●
is hard to deploy
BUT ALSO
●
a decent package of design patterns
●
good for prototyping ie. has a good amount of
features built-in while being extensible
●
continuously improving along recent trends

105. Don't stop explainingincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

106. 3. Retention

107. Tailor your course according to the
students you wish to teach

108. Veterans need only a little pushincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

109. Of course, teaching beginners is hardincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

110. Especially total beginnersincreasingcomplexity
PRESENTATION
APPLICATION
DATA
INFRASTRUCTURE
ENGINEERING
PRACTICE

111. One-day workshops will not cut it.
You'll need to use some techniques for them to
continue learning on their own.

112. One technique that people often misuse:

113. rails generate scaffold

114. rails generate scaffold

115. rails generate scaffold
●
gives students a "taste of power", piquing their interest

116. rails generate scaffold
●
gives students a "taste of power", piquing their interest
●
produces good sample code (esp. tests) for future study

117. rails generate scaffold
●
gives students a "taste of power", piquing their interest
●
produces good sample code (esp. tests) for future study
●
many students (and workshops) don't go past it

118. Wow
such migrations
much unit tests
very omakase
railz so amaze
@doge ||= 9000
so turbolinks
so restful

119. rails generate scaffold
●
gives students a "taste of power", piquing their interest
●
produces good sample code (esp. tests) for future study
●
many students (and workshops) don't go past it
●
in turn, it gives others the wrong impression

120. rails generate scaffold
●
gives students a "taste of power", piquing their interest
●
produces good sample code (esp. tests) for future study
●
many students (and workshops) don't go past it
●
in turn, it gives others the wrong impression
"Rails? Oh, that's just scaffolding scripts."

121. Follow through

122. Give them a road map
http://techiferous.com/2010/07/roadmap-for-learning-rails/

123. Let them try things on their own pace

125. and this also leads us to the last point...

126. 4. Culture

127. Wow
such migrations
much unit tests
very omakase
railz so amaze
@doge ||= 9000
so turbolinks
so restful

128. original image: http://en.wikipedia.org/wiki/User:Jeremykemp

130. Polyglot / Full Stack Developer

131. Constantly Improving
http://blog.newrelic.com/2013/10/10/infographic-state-stack-ruby-edition/

132. Sharing Knowledge

137. On the other hand...

138. Myopia

139. most obvious:

140. You need to accept that most of
your trainees will be Windows
users...

142. ...so give them a clear path for migrating to *nix
ie. not just "Get a Mac!"

143. and other stuff in the culture that may turn off
interested developers...

144. and other stuff in the culture that may turn off
interested developers...

145. tl;dr:
You have to introduce them to the culture.

146. In closing...

147. 1. Domain

148. 2. Purpose

149. 3. Retention

150. 4. Culture

151. 0. Students

152. ( °□°)╯ ╯ ︵
Or you could just teach Ruby

161. Thank you for listening!
bryanbibat.net | @bry_bibat
speakerdeck.com/bryanbibat