Miguel Vilá miguel-vila

Advanced Scala:

#Chapter 1

Side effects, by definition, are not tracked in the types, and so the compiler cannot alert us if we forget to perform some action as a side effect.
In general, we'll learn how this sort of transformation can be applied to any function with side effects to push these effects to the "outer layers" of the program. Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects.
(...) a function has no observable effect on the execution of the program other than to compute a result given its inputs; we say that it has no side effects.
We can formalize this idea of pure functions using the concept of referential transparency (RT). This is a property of expressions in general and not just functions.
This is all it means for an expression to be referentially transparent—in any program, the expression can be replaced by its result without changing the meaning of the program.
This definition should give you some intuition that re

Operations describe what is computed; execution is handled separately. This frees the programmer from attending to the minutiae of setting up threads, ensuring pools and queues are sized correctly, and making sure that resources are properly reclaimed— these concerns are instead handled by our runtime library, Finagle.

(...) Many of these techniques try to achieve distribution transparency —that is, to the user of the system it appears as if there is only one system instead of a number of collaborating systems. Many systems during this time took the approach that it was better to fail the complete system than to break this transparency.
An important observation is that in larger distributed scale systems, network partitions are a given; therefore, consistency and availability cannot be achieved at the same time. This means there are two choices on what to drop: relaxing consistency will allow the system to remain highly available under the partitionable conditions; making consistency a priority means that under certain conditions the system will not be available.
Types of consistency:
- Strong consistency : After the update completes, any subsequent access will return the updated value.
Weak consistency : The system does not guarantee that subsequent accesses will

Latency: The state of being latent; delay, a period between the initiation of something and the occurrence.
Latent: From Latin latens, latentis, present participle of lateo ("lie hidden"). Existing or present but concealed or inactive.
The other key point based on this definition is that if nothing happens, there is no "latent period". A system in which data doesn't change doesn't (or shouldn't) have a latency problem.
One can often gain performance by exposing more details about the internals of the system.
Systems which hide these kinds of details are easier to understand (since they act more like single unit, with fewer details to think about), while systems that expose more real- world details may be more performant (because they correspond more closely to reality).
In the end, the ideal system meets both programmer needs (clean semantics) and business needs (availability/consistency/latency)
Only one consistency model for replication - strong consist

	import scalaz.contrib.std.FutureInstances // Dependency: scalaz-contrib
	import scalaz.{ Monad , OptionT } // Dependency: scalaz
	import scala.concurrent.ExecutionContext.Implicits.global
	import scala.concurrent.Future

	class FutureAndOptionComposition[A, B, C, D]
	extends FutureInstances
	// The FutureInstances trait has a method which creates a Monad instance
	// for Future which is used implicitly by the OptionT
	{

	trait MeasureTypeClass[A]{
	def measure(a: A) : Int
	}

	object TypeClassExample{
	def genericMeasure[A : MeasureTypeClass](value: A): Int = {
	val measurer = implicitly[MeasureTypeClass[A]]
	measurer.measure(value)
	}

	import org.scalacheck.{ Properties , Arbitrary , Gen }
	import org.scalacheck.Prop.forAll
	import play.api.libs.json._

	case class Subdocument(m: String, n: Int, list: List[Int], days: Set[WeekDay.Value])
	case class Document(id: String, n: Int, subDoc: Subdocument)

	object WeekDay extends Enumeration {
	val Mon, Tue, Wed, Thu, Fri, Sat, Sun = Value
	}