tech talk - things i learned at scala days 2013
DESCRIPTION
Tech Talk I gave at my company for the things I learned at Scala Days 2013TRANSCRIPT
Scala Days 2013by Hung Lin @hunglin
Scala the **** out of NYC3 days event @ NYCScala Sunday @ meetup HQ: 8 talksShapeless workshop on Monday
Hot TopicsScala 2.10Style of Scala*Asynchronous Programming - akkaBig Data / Streaming Data - SparkMacroPlay
Keynote: Scala with Styleby Martin Odersky, creator of scala
What is OOP good for?Fixed APIs with unknown implementations. e.g.Simula67 for simulation, Smalltalk for GUIObjects are characterized by state, identity andbehavior - Grady Booch
OOP v.s. FP
Guideline #1 Keep it simple
Simple Made Easy - Rich Hichey
Guideline #2 Don't pack too much in one
expressionfind meaningful names for the intermediate results. It's
not easy but it's important
Guideline #3 Prefer Functional
vals v.s. varsrecursions or combinators v.s. loopsimmutable v.s. mutable collectionstransformations v.s. CRUD*
Guideline #4 But, don't diabolize local statesometimes, mutable gives better performancesometimes, mutable adds convenience
vars v.s. valsvar interfaces = parseClassHeader()...if (isAnnotation) interfaces += ClassFileAnnotation
val parsedIfaces = parseClassHeader()...val interfaces = if (isAnnotation) parsedIfaces + ClassFileAnnotation else parsedIfaces
loops v.s. combinatorsval totalPrice = items.map(_.price).sumval totalDiscount = items.map(_.discount).sum
val (totalPrice, totalDiscount) = items.foldLeft((0.0, 0.0)) { case ((tprice, tdiscount), item) => (tprice + item.price, tdiscount + item.discount) }
var totalPrice, totalDiscount = 0.0for (item <- items) { totalPrice += item.price totalDiscount += item.discount}
Guideline #5 Careful with mutable objects
val m = ArrayBuffer[Int]()
Guideline #6 Don't stop improving too early
shrink code by factor of 10 + make it more readable atthe same timeclean and elegant solutions don't come to mind at thefirst timeit is fun to find better solutions
Choice #1 Infix v.s. "."
Choice #2 Alphabetic v.s. Symbolic
val xs = List("apples", "oranges", "pears")
xs.foldLeft("")((result, i) => result + i)
("" /: xs)((result, i) => result + i)
Choice #3 Loop, recursion or combinators
try conbinators firstif it becomes too tedious, or efficiency is a big concern,try tail-recursionuse loop for simple case or for readability
Choice #4 Procedures or "="
DON'T use procedure syntax
def method: Unit = { // operations}
Choice #5 Private v.s. nested
use nested function to avoid passing parametersuse nested function for small functionsdon't nest too many levels
Choice #6 pattern matching v.s. dynamic
dispatchthe expression problem, check out
, lecture 4.5 and 4.6scala class @ coursera
Choice #7 type parameters v.s. abstract type
members
try type parameters firstavoid Animals[_]
a good article by Bill Venners
Keynote: Scala in 2018by Rod Johnson, creator of Spring
in 2018Java is still aliveEnterprise apps are using ScalaStartups are still NOT using Scala
myths / pointsReadability over cleverness, LOC, FP, ...Scala needs coding standardScala needs to move slowerEmbracing instead of hating Java
Any fool can write code that a computer can understand.Good programmers write code that human can
understand. - Martin Fowler
Debugging is twice as hard as writing the code in the firstplace. Therefore, if you write the code as cleverly aspossible, you are, by definition, not smart enough to
debug it. - Brian Kernighan
Asynchronous Programming
asynchronous v.s. parallelwhat else?who's doing it?
asynchronous v.s. batching
pitfall: thread pool?for tomcat, one thread handles one request
pitfall: back pressure
pitfall: performance v.s. scaling issue
pitfall: theory v.s. realitycost of thread context switch# of threads v.s. # of CPUswhere is the bottleneck?
Some thoughts about our system
Upgrade to scala 2.10
Use akkaasynchronous programmingfault tolerancemodular design
Use case class for data modeltreat data as map
Use finagle for service modulesplay is not for REST APIwhy pay the cost of HTTP?statisticsseparate REST and Data layermodularity
Questions?