Recomendados
Recomendados
Mais conteĂșdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 2 Years of Real World FP at REA
Semelhante a 2 Years of Real World FP at REA (20)
Mais de kenbot
Ăltimo
Ăltimo (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!