Miguel Vilá miguel-vila

I hereby claim:

I am miguel-vila on github.
I am miguel (https://keybase.io/miguel) on keybase.
I have a public key whose fingerprint is E277 3F1D 8B4A 7227 7A1A 73DF 4E0C DBF3 4810 3B2F

To claim this, I am signing this object:

CAP Twelve Years Later: How the "Rules" Have Changed

CAP prohibits only a tiny part of the design space: perfect availability and consistency in the presence of partitions, which are rare.
The modern CAP goal should be to maximize combinations of consistency and availability that make sense for the specific application.

In ACID, the C means that a transaction preserves all the database rules, such as unique keys. In contrast, the C in CAP refers only to single‐copy consistency, a strict subset of ACID consistency. ACID consistency also cannot be maintained across partitions—partition recovery will need to restore ACID consistency.
Isolation (I). Isolation is at the core of the CAP theorem: if the system requires ACID isolation, it can operate on at most one side during a partition. Serializability requires communication in general and thus fails across partitions. Weaker definitions of correctness are viable across partitions via compensation during partition recovery.

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

(...) 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

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.

#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

	set scalaVersion := "2.11.0"
	set libraryDependencies += "org.scalaz" %% "scalaz-core" % "7.1.0"
	set initialCommands += "import scalaz._, Scalaz._"
	session save
	console

	//Shapeless:
	/*
	set libraryDependencies += "com.chuusai" %% "shapeless" % "2.0.0"
	set initialCommands += "import shapeless._"

	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
	}