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.
On April 9, Scala developers from Portugal, Spain and the UK gathered in Lisbon for LX Scala to discuss Scala’s present and future trends. These are my notes from the talks…
When using functional programming languages like Scala, developers spend a lot of their time composing functions and effects. One of the most common ways to express composability is to use monads. However, composing functions that return different monads can become quite messy and, without the right tools, quickly turn into a massive headache. That’s where Monad Transformers, which are the main focus of this post, come in handy!