Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 2 Years of Real World FP at REA
Similaire à 2 Years of Real World FP at REA (20)
Plus de kenbot
Dernier
Dernier (20)
2 Years of Real World FP at REA
- 1. 2 Years of Real World FP at REA @KenScambler Scala Developer at λ
- 2. Me 14 years 5 years 5 years when possible when bored when forced
- 3. @ Jul 13 Jan 14 Jul 14 Jan 15 - 3 teams - 17 codebases - 43K LOC
- 7. Modular, abstract, composable programs are simple programs
- 8. Modularity
- 9. Can you reason about something in isolation?
- 10. Or do you need to fit everything in your head at once?
- 11. A B C K Is the cost of replacing B with K just writing K?
- 12. A B CK Is the cost of replacing B with K just writing K?
- 13. AK B CKK …or rewriting half the program? glue glue
- 14. A pure function is just input output; no side effects You can tell what it does without Looking at surrounding context.
- 15. Consider: Let’s parse a string like “Richmond, VIC 3121” def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) }
- 16. Could be null Possible errors: 1 def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) }
- 17. def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) } Might not have enough elements Possible errors: 2
- 18. def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) } Might not have enough elements Possible errors: 3
- 19. def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) } Might not have enough elements Possible errors: 4
- 20. def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) } Might not have enough elements Possible errors: 5
- 21. def parseLocation(str: String): Location = { val parts = str.split(“,”) val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) } Might not be an int Possible errors: 6
- 22. def doSomethingElse(): Unit = { // ...Do other stuff parseLocation(“Melbourne, VIC 3000”) } Possible errors: 6 + 3 = 9 6 3
- 23. def anotherThing(): Unit = { // ...Do even more stuff doSomethingElse() } Possible errors: 9 + 4 = 13 4 9
- 24. Code inherits all the errors and side-effects of code it calls. Local reasoning becomes impossible; modularity is lost.
- 25. def parseLocation(str: String): Option[Location] = { val parts = str.split(”,") for { locality <- parts.optGet(0) theRestStr <- parts.optGet(1) theRest = theRestStr.split(" ") subdivision <- theRest.optGet(0) postcodeStr <- theRest.optGet(1) postcode <- postcodeStr.optToInt } yield Location(locality, subdivision, postcode) } Possible errors: 0
- 26. All possibilities have been elevated into the type system Local reasoning is possible! Local reasoning is possible about things that call it, etc…
- 27. Abstraction
- 28. Know as little as you need
- 29. Know as little as you need Produce as little as you can
- 30. def sumInts( list: List[Int]): Int = { var result = 0 for (x <- list) { result = result + x } return result }
- 31. def flatten[A]( list: List[List[A]]): List[A] = { var result = List() for (x <- list) { result = result ++ x } return result }
- 32. def all[A]( list: List[Boolean]): Boolean = { var result = true for (x <- list) { result = result && x } return result }
- 33. def sumInts( list: List[Int]): Int = { var result = 0 for (x <- list) { result = result + x } return result }
- 34. def flatten[A]( list: List[List[A]]): List[A] = { var result = List() for (x <- list) { result = result ++ x } return result }
- 35. def all[A]( list: List[Boolean]): Boolean = { var result = true for (x <- list) { result = result && x } return result }
- 36. trait Monoid[M] { def zero: M def append(m1: M, m2: M): M } Extract the essence!
- 37. def fold[M](list: List[M]) (implicit m: Monoid[M]): M = { var result = m.zero for (x <- list) { result = m.append(result,x) } result }
- 38. def fold[M](list: List[M]) (implicit m: Monoid[M]): M = list.foldLeft(m.zero)(m.append)
- 39. fold(List(1, 2, 3, 4)) 10 fold(List(List("a", "b"), List("c"))) List("a", "b", "c") fold(List(true, true, false, true)) false
- 40. Abstraction is always a good thing! Less repetition More reuse Less decay, because code can’t grow tumours around unnecessary detail
- 41. Composability
- 42. Functions compose. A => B B => C C => D D => E
- 43. A => E Functions compose.
- 44. Sideways too. A => E X => Y
- 45. (A,X) => (E,Y) Sideways too.
- 46. This works in the large, as well as the small! Entire systems can be composable like functions…. without side effects
- 47. Truly composable systems can accrue more and more stuff without getting more complex!
- 48. Simplicity • Modularity – Reason locally • Abstraction – say only what you need, hide everything you don’t • Composability – scale without accruing complexity
- 50. Technical excellence isn’t enough! Software development is a human process Coffee Tea Quiet time GSD Ponies Reconsider!
- 56. Xi’an offshore team • Many teams are partly based in Xi’an. • They’re very good, but… • Communication is hard! • It works, but requires great investment of time and money
- 68. GET /foo/bar PUT {"mode": "banana"} POST {"partyTime": "5:00"} GET /buzz/5/
- 72. Architect Mountain Just needs more Agile Don’t forget your velocity More meetings, but littler NO No no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no not like this. Wake up it’s a school day
- 73. Bottom-up tech decisions You have to win
- 74. Bottom-up tech decisions You have to win
- 75. Bottom-up tech decisions You have to win
- 76. Software Paleontology Everyone’s got a history…
- 77. Scriptozoic era 1995 – 2010 Mostly Perl
- 78. Monolithocene epoch 2010 – 2012 Ruby, Java Scriptozoic era 1995 – 2010 Mostly Perl
- 79. AWS Monolithocene epoch 2010 – 2012 Ruby, Java Scriptozoic era 1995 – 2010 Mostly Perl Microservices 2012 – Ruby, Scala, JS
- 80. Adoption
- 81. June, 2013
- 85. λ
- 87. λ λ
- 88. λ λ λ
- 89. λ λ λ
- 90. λ λ
- 91. λ λ
- 92. λ
- 93. Language choice Object Oriented Powerful static types Functional JVM
- 94. Object Oriented Powerful static types Functional JVM
- 95. Functional JVM
- 96. Functional JVM
- 97. Functional JVM
- 98. Functional JVM
- 99. Whatever works for you!
- 100. The journey
- 101. Jul 13 Jan 14 1
- 102. LOC Web JSON DB Dep Inj Play2 Play2 6K Squeryl / Play2 Constructors Type API #1
- 103. LOC Web JSON DB Dep Inj Play2 Play2 6K Squeryl / Play2 Constructors Type API • Mentor • Code reviews Learning Investment #1
- 104. LOC Web JSON DB Dep Inj Play2 Play2 6K Squeryl / Play2 Constructors Type API • Mentor • Code reviews Learning Investment Report card Learning curve Technical result Productivity Sentiment Steep but ok OK; slight dip Great; but FWs too heavy #1
- 105. Jul 13 Jan 14 1 2 Some infrastructure
- 106. LOC Web JSON DB Dep Inj Play2 Argonaut 3K Squeryl / Play2 Constructors Type API #2
- 107. LOC Web JSON DB Dep Inj Play2 Argonaut 3K Squeryl / Play2 Constructors Type API • Almost none Learning Investment #2
- 108. LOC Web JSON DB Dep Inj Play2 Argonaut 3K Squeryl / Play2 Constructors Type API • Almost none Learning Investment Report card Learning curve Technical result Productivity Sentiment Learning? Meh Needed rework; OK in the end #2 !!!
- 109. Lesson #1 New tech, mindset requires investment in learning Invest in your people!
- 110. λ
- 111. Another team! λ
- 112. “We’ll have some of that!” λ
- 113. Jul 13 Jan 14 1 2 4 6 5 New team; new ideas! 3
- 114. LOC Web JSON DB Dep Inj Unfinagled Argonaut 2K, 3K, 4K, 1K Slick Constructors Type Web app, libs, API x 2 • 2 x Mentor Learning Investment Report card Learning curve Technical result Productivity Sentiment Not bad Great Great #3,4, 5,6
- 115. Jul 13 Jan 14 1 2 4 6 5 3 7 Theft & innovation Jul 14
- 116. Lesson #2 Having multiple teams is great, because you can steal from each other
- 118. LOC Web JSON DB Dep Inj Unfinagled Argonaut 4K Slick Monad Transformers Type API • 2 x Mentor Learning Investment #7
- 119. LOC Web JSON DB Dep Inj Unfinagled Argonaut 4K Slick Monad Transformers Type API • 2 x Mentor Learning Investment Report card Learning curve Technical result Productivity Sentiment Vertical Great Great #7
- 120. Monad Transformers Good technical benefits, but… Only 2 people could understand the code Experienced engineers felt totally helpless Learning curve way too steep
- 122. All-rounders Gurus JS / CSS / HTML
- 125. All-rounders Scala (now) Gurus • Smooth learning curve is utterly essential • We need more all- rounders • We can’t leave people behind
- 126. Lesson #3 Familiar, but technically unsound concepts have limited value. However… if we can’t make a concept learnable, then we can’t use it.
- 127. λ A Ruby team considers its options…
- 128. λ
- 129. λ
- 130. Jul 13 Jan 14 1 2 4 6 5 3 7 A 3rd team dips its toe in the water 8 Jul 14
- 132. LOC Web JSON DB Dep Inj Play2 Play2 2K Anorm Constructors Type Web app • Trial and error • Code Katas Learning Investment #8
- 133. LOC Web JSON DB Dep Inj Play2 Play2 2K Anorm Constructors Type Web app • Trial and error • Code Katas Learning Investment Report card Learning curve Technical result Productivity Sentiment Steep Meh OK #8
- 134. Lesson #4 It’s really hard learning from scratch Be prepared for pain up front
- 135. λ
- 136. Jul 13 Jan 14 1 2 4 6 5 3 7 Latest iteration 8 Jul 14 Jan 15 17
- 137. Design trends Inheritance/mixins Static functions
- 138. Design trends Inheritance/mixins Static functions Partial functions Total functions
- 139. Design trends Inheritance/mixins Static functions Partial functions Total functions Exceptions Sum types
- 140. Design trends Inheritance/mixins Static functions Partial functions Total functions Strings/primitives Wrapper types Exceptions Sum types
- 141. FP Guild Every Thursday, in work hours 7 – 12 people each week Reading, exercises, talks, live coding
- 143. LOC Web JSON DB Dep Inj Unfiltered Argonaut 3K Slick Free Monads Type API • 2 x Mentors • Pull Requests • Code reviews • Pairing • FP Guild Learning Investment #17
- 144. LOC Web JSON DB Dep Inj Unfiltered Argonaut 3K Slick Free Monads Type API • 2 x Mentors • Pull Requests • Code reviews • Pairing • FP Guild Learning Investment Report card Learning curve Technical result Productivity Sentiment Smooth Great Brilliant #17
- 145. Pure core Routes Controllers Logic Script Interpreter Actual DB “Authenticate” “Use config” “Get from DB” “Update DB” “Log result” Web Framework Server App runtime
- 146. Pure core Routes Controllers Logic Script Pure Interpreter Pure tests Input Output Assert “Authenticate” “Use config” “Get from DB” “Update DB” “Log result”
- 147. Pure core Interpreter Actual DB Web Framework Server App runtimeWafer thin E2E tests Input Output Assert
- 148. object SearchController { def getList(uid: UserId): Script[Response] = { for { searches <- getSearches(uid) cfg <- getConfig results <- addLinks(searches, cfg) } yield Ok ~> Response(result.toJson) } }
- 149. Learning curve:
- 151. Mocks
- 152. Stubs
- 153. Flaky pretend servers just to check a response code
- 154. Flaky tests that take 30 min to run
- 156. Exceptions
- 158. You shouldn’t be dealing with all that complexity and crap! Most business software isn’t rocket science.
- 159. There is a better way FP is a tall tree But there is so much low hanging fruit!
- 160. Thank you!