specs2 has been around for 4 years now and while it tried to take the “functional route” (with immutability at least), it is actually largely using uncontrolled effects.

This talk will present a diagnosis of everything that is not “functional” in specs2, and will describe implemented or proposed solutions to remediate to this. Here’s a list of some problems:

• system properties are read directly
• the file system is accessed to get the state of previous runs and written to after execution
• some configuration is global (execution context for threads)
• text is freely emitted to the console via printlns
• an attempt at processing lazily the execution miserably failed (via Reducers)
• the code base is not easily extensible to create new reporters

The solutions (still being implemented/experimented) include:

• using a ReaderT / ErrorT / WriterT / IO stack to control effects. This actually opens very interesting possibilities in terms of flexibility for writing your specification! Question: how tedious is that to use in practice?
• using scalaz-stream to process results as they happen, even when running concurrently. This should remove some poorly performing code and simplify the code base. Question: does it work with specs2 execution model where it is possible to run only some sections of the specification concurrently, where a failed execution can stop the rest of the processing,…?
• using functions extensively instead of traits to compose functionality (who knew?). Traits will only be used to compose implicits for DSLs. Question: why not take the Cake Pattern route?

In conclusion we will talk about strategies for effectively migrating a non-functional code base to a functional one. What was learnt during this experiment?

“Make illegal state irrepresentable” – Yaron Minsky

Starting from Yaron’s quote we will see where it traditionally applies: values sanitization (escaping), data structures (NonEmptyList), CS constructs (parsers). Does it still apply to the rest of the day-to-day programming where things look… complicated?

In particular we will develop the example of executing applications which can run on single Amazon EC2 instances (for testing) or on full EMR clusters (for production) and which can take data from S3 (meaning that they need to download it and put it somewhere first) or use local data.

Can we make sure we get the right paths? Can we know when it is possible to download data efficiently (using distcopy to go directly from S3 to the cluster for example)? The answer is: create specific data types to model the different cases and tame the complexity.

The take-away: datatypes are not only for “data” but they can also encapsulate “logic” Can we make sure we get the right paths? Can we know when it is possible to download data efficiently (using distcopy to go directly from S3 to the cluster for example)?

The answer is: create specific data types to model the different cases and tame the complexity.

The take-away: datatypes are not only for “data” but they can also encapsulate “logic”

Most applications are just reading data, transforming it and writing it somewhere else. And there are great libraries in the Scala eco-system to support these use cases: Akka-Stream, fs2, Monix,... But if you look under the hood and try to understand how those libraries work you might be a bit scared by their complexity!

In this talk you will learn how to build a very minimal "streaming library" where all the difficult concerns are left to other libraries: eff for asynchronous computations and resources management, origami for extracting useful data out of the stream. Then you will decide how to spend your complexity budget and when you should pay for more powerful abstractions.

This talk presents how we use the Eff monad at Zalando to structure a REST microservice. Even when programming with functions, modules and components still matter, and I will present a new approach for dependency injection using the Reader monad (classic) and tree rewriting (what?). Then we will see how to specify more precisely several components (authentication, request to other services and database access) with the Eff monad and support additional concerns like logging or asynchronous execution.

Once you get the basic idea, the possibilities are endless! Rate limiting is just another component and another set of effects involving time and state, testing becomes really clean and easy.

Monad transformers are a neat way to compose effectful computations: pass some configuration, read/write from disk, track errors... However they can be a bit cumbersome to deal with, especially if you want to use different stacks sharing some common effects: for example a stack to interact with AWS and another one for Hadoop computations.

This talk will shortly introduce monad transformers in Scala and their drawbacks then present the Eff monad.

The Eff monad has some really interesting properties:

• effects can be developed completely independently from each other
• effects can be interpreted in different ways and the interpreters can be composed together
• it is based on an efficient "Free monad" (avoiding the issue of quadratic flatMaps)
• with the Eff monad you will never have to re-implement the Monad operations (point / flatMap) again!