One of the most relevant Scala primitives for concurrency is the Future. It represents a value which is either complete or failed, and is scheduled to run outside the program main flow, in some other thread. You can learn more about it here if you are not familiar and want to understand this post.
Imagine a opera house allows reservations to a show. For each reservation two people can come: the buyer of the reservation himself and his guest.
As in any show-house, there are many types of seats; some are standing, some normal and some on VIP tribunes.
The case for statically typed languages is so that we can prove our programs are right at compile time. Although our languages are not powerful enough to achieve this all the time, we certainly not always use their full capabilities. Our intuition should guide us to reduce implementation space and improve code reuse, allowing us to focus on small parts of a big problem. We can only do this if we choose the right abstraction in the form of Types. These will act as constraints on the implementation space, bringing with them reusable and tested code.
This is a quick Scala tip on a somehow unknown feature of the Scala language, what I call self aliasing or unconstrained self type annotations. One sees that in some libraries or even in the Scala standard library itself.
It goes something like this:
I write this post as a way to consolidate my knowledge on Actions.
Most of what I write is explained on the Play Framework docs, although I believe you can benefit from my explanation. The last chapter, Chaining ActionBuilders, is the most interesting. This topic is under-explained on the docs, making it the most valuable.
In recent years the interest on test automation has increased significantly. Some of the reasons behind this growth include a greater need for faster software delivery processes, increased productivity and cost/effort reduction associated to the tests itself. This article will focus on test automation, its advantages and drawbacks and when and how the transition from manual to automatic should be made. The article will also provide some examples of test automation tools, programming languages used for test automation and continuous integration software.
There are a lot of articles around explaining functional programing and some of the theory and reasoning behind it. Most monad explanations are good if you understand the theory behind it. However, if you come from a practical standpoint, not so much. You will see the running joke that the first rule of Monads is that if once you understand the concept you lose the ability to explain it. This means you should not expect a lot from this post, because either I don’t understand the concept or the explanation is not very good. Either way, the aim here is to prescribe the monad as a good engineering tool.
The Book Functional and Reactive Domain Modeling (Debasish Ghosh) is one of the most interesting books I have read lately, in the realm of Scala.
This is not another beginner Scala book, neither a functional programming primer. It is a much needed tour on domain modeling with functional patterns and concepts, reactive systems and modern software development in Scala. If you want to know how in the world one can use Akka streams, free monads and actors interacting with each other, this book is a great starting point :).
This is the second installment in a series of articles about Shapeless.
The first post explained heterogeneous lists (HLists) and how to use them to do type-level recursion. Building on this ground, we will now talk about Generic derivation of case classes and sealed trait hierarchies. Along the way we shall cover other related subjects such as singleton-typed literals, products, coproducts (and labelled versions of those) and shapeless syntax goodies.