miguel-vila

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
{

miguel-vila

Advanced Scala:

Monad intros:

1. A nice intro: Scala Monads: Declutter Your Code With Monadic Design [YouTube]

Some monads:

1. Scalaz State Monad
2. Reader Monad for dependency injection

miguel-vila

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)
  }
  

miguel-vila

{
 "metadata": {
  "name": ""
 },
 "nbformat": 3,
 "nbformat_minor": 0,
 "worksheets": [
  {
   "cells": [
    {

miguel-vila

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
}

miguel-vila

#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

miguel-vila

Jessica Kerr "Functional Principles for Object Oriented Development"

Principles

• Data In, Data Out: (Most) Functions should only depend on its parameters and should do nothing but produce output.
  • Testable: No need to setup extern dependencies or tear them down after testing
  • Easier to understand: Only local context dependent
  • A good "data in, data out" function should:
    • don't access global state
    • don't modify the input
    • don't bother the rest of the world
• Inmutability

miguel-vila

"Your Server as a Function" by Marius Eriksen

• 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.

miguel-vila

"Eventually Consistent" by Werner Vogels

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

miguel-vila

Distributed systems for fun and profit

• 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