There are wonderful libraries in Scala ecosystem for resource handling. I recommend the following as a quick start.

- ZManaged from ZIO (https://github.com/zio/zio)
- cats.effect.Resource (https://github.com/typelevel/cats)

These are superior libraries to many of those in other popular* languages, though I find the comparison is mostly with java `try-with-resources.`

The simple story of this blog is, the resource management techniques that you can leverage with these libraries mentioned above is ** not just a shiny alternative** to Java

`try-with-resources`

, because some (well, many) important semantics are simply missing in `try-with-resources,`

(detailed further below). Hence, I find these libraries to be sort of a necessity when it comes to handling resource-intense usecases. That along with Fiber-based concurrency model enables us to acquire millions of resources in parallel, with well defined release strategies on interruptions and failures. These techniques are available in Scala (when it comes to JVM) 3–4 years before. …**How do you implement square (or double) using Monads?**

Quite simple: Use the monad instance of a function and then `join` on a function that returns a function.

How on earth does that work?

You know the signature of Monad join.

`join :: Monad f => f (f a) -> f a`

join ffa = ffa >>= id

Consider `data Optional a = Full a | Empty`

has a monad instance. This implies:

`>> join (Full (Full 1))`

Full 1

In this case,`f`

is `Optional`

, and `ffa`

is `Full (Full 1)`

When you replace `Optional`

to be a function `f: t -> a`

, then `ffa`

is `f: t -> ( t -> a )`

. …

For those who need to get straight into the code with explanations as comments, please feel free to jump to:

https://scastie.scala-lang.org/afsalthaj/4rTuhrx6Tw6wohdyaP73bg/2

Others, read on !

In type-driven development, it is often necessary to distinguish between different interpretations of the same underlying type. For example, for the underlying type ‘integer’, there are multiple possible Monoids — that is, multiple ways to accumulate integers. One Monoid is to sum all the values, with the ‘empty’ value being 0. Another Monoid for integer multiplies all the values, so the ‘empty’ value has to be 1. …

I hope we all are much familiar with building, compiling and running Scala applications with SBT.

Developers now write SBT plugins relatively quickly, especially to standardise builds across hundreds of applications in the organisation. For instance, packaging docker, fetching org-artifactory credentials, common entry scripts etc.

IMO, it is simple enough, because all we need to know is Scala and there isn’t actually a need of learning the entire SBT reference manual.

These days, I try to avoid a shell script / separate docker-compose.yml /other-language orchestrations alongside my Scala app. …

Stop unreadable logs……….. !!

Its good to talk about summary in an intro:

As a summary of requirements, there shouldn’t be any more separate docker related orchestrations. Everything that you do with docker are first class citizens in the project that can run along with other test cases in your project. We can see bits and pieces of code everywhere trying to achieve this, but here we strive for the best possible way of doing it.

Let’s list down our requirements first.

For certain test cases we need to run a docker-compose as the first step, which in turn depends on creating a few images, plus a few other custom steps. …

We tend to forget this quite often. An invariant functor or an exponential functor is, given `A => B`

and `B => A`

, it converts type `A`

to type`B`

in the same context `F[_].`

We call this `xmap`

.

That’s the famous `Functor`

! Covariant functor implements `xmap`

by discarding the function `B => A`

.

As expected, it discards `f: A => B`

and makes use of `contramap`

to implement `xmap`

As expected, it is `DecodeJson`

, where the type parameter in the type class comes at covariant position (method result)

If type parameters are at covariant position, that means the method return contains the type. …

Here is my gist that combines the various algebra defined in various parts of the application, using **Free Monad** with in **Scalaz**! For those who are impatient, jump straight to line number 58, that handles what Scalaz is missing !

Well, that was useless toy example.

I think , with my experience with Free (learning scalaz, learning the red book, reading Free things, Runar’s paper on Trampoling to Free and in fact implementing free things in production with Scala), I can say operations as data with Free is attractive, **but that can bring significant set of boiler plates that is strong enough to damage the entire design of the app if you are doing something non-trivial**. So you need to really consider the complexity of your app before you try to make it simple with Free and find ways to hide away boilers from business logic. …

For those who are familiar with Free Monad pattern, we know defining algebra for your operation is an intuitive process. For those who are familar with visitor pattern in Java, you know Scala has an alternative (to a great extent) using pattern matching. In this blog, we are trying to integrate the visitor pattern (forgetting Scala’s highly powerful pattern matching) with the operations which you have encoded using Free Monad algebra. We will see why we did this later on.

Let us go straight into some examples. Below given is a console operation encoded using Free Monad. …

(Work in progress, there are typos and inconsistencies, so excuse)

This is a quick deep dive into shapeless and Scalaz applicative builder pattern working together and solving a use-case for better understanding. You may well be tweaking further to get your stuff done based on what is presented here.

This is targeted for those who know type classes (Haskell type class taken to Scala), Generic Repr in shapeless, applicative functors, applicative builder pattern in Scalaz/Cats (and optionally tagged type)

A typical example of using applicative builders is when you need to validate an entity where the validation of each field in the entity returns an applicative functor. And when you have dozens of such entities (never dealt with it until yesterday as I am writing this) sharing fields across each other, you finally have a bloated boiler plate of Advanced (for some) Scala. …

About