When you work with Slick, and you want to map a table to a case class, you need to provide a couple of functions:

One that takes a tuple and returns an instance of your case class. And another that takes an instance of your case class and returns a tuple wrapped in an Option.

If the types of your case class are the same than the ones you have in your table definition, you only need to provide the tupled and unapply methods (as you can see in the Slick docs).

But, what if you need to perform some transformation because the types of your table definition don’t match the ones in your case class?

When you work on enterprise applications, TheadLocal variables are something you don’t see very often. You see them once in a while, but you never have to deal with them directly. So, in this short post I want to illustrate how ThreadLocal variables work.

DDD is not silver bullet, and in order to apply it successfully, you need to know when you will get the most out of it.

This is a checklist that I compiled based on this book that will help us to identify if DDD is a good fit for the project we are going to start.

One thing that I’m doing lately every time I read a book, is to take some notes of the salient points and store them in a private repository. These notes help me every time I forget something that I read previously.

Now, I want to try something different. Instead of keeping these notes to myself, I’m going to create a blog post with the concepts/ideas that captured my attention while reading a book.

Let’s begin!

When I was adding a feature to an existing application, I found a method that looked like this:

def logIn(username: String, password: String) = {
  var conn: Option[Connection] = None

  val user:Try[UserData]  = for {
   c <- getConnection() // returns scala.util.Try
   conn = Some(c)
   u <- findUser(username, c) // returns Try[UserData]
   _ <- checkPassword(u, c, password)
  } yield {
    c.close()
    u
  }

  // close connection in case of failure
  user.recoverWith {
    case ex =>
     conn.foreach(_.close)
     Failure(ex)
  }
}

The other day, I was making some changes to one of the projects that I’m currently working on. I realized that there weren’t unit test for the code that I was changing. I wanted to create some unit tests so I could be sure that I wasn’t breaking anything with the modifications that I was doing.

Some of the methods that I wanted to test consume a web service. My plan was to mock these HTTP calls because I was interested in testing the logic around the data returned by the web service and not in the HTTP calls. Then, I found that the way the code was structured didn’t let me mock the web service response. Let me explain why.

A couple of weeks ago, I was studying functional programming. I was working on my own implementation of the Option type. The type hierarchy that I defined was something like:

trait MyOption[+T]
case class MySome[T](value: T) extends MyOption[T]
case object MyNone extends MyOption[Nothing]

I wanted MyOption to be covariant since that allowed me to assign MyNone object to any variable that has the type MyOption; because Nothing is a subtype of everything, I can do something like val x : MyOption[String] = MyNone for example. When I tried to add the method getOrElse to MyOption trait, I got the error:

trait MyOption[+T] {
  def getOrElse(default: T): T 
  // error: covariant type T occurs in contravariant position in type T of value default
}

This post is part of a series of posts where I give more details about a particular feature of Scala that I like. Now, the turn is for pattern matching. You can see the list of features that I like here.

Coming from Java or any C-like language, the first thing you will think of when you see a match expression in Scala is that pattern matching is like switch statements in any of these languages. That’s probably an unfair comparison since pattern matching is more powerful and has a wider range of use cases. In this post, I’m going to show you the usages of this feature that I find the most interesting.

One of the features that I like the most in Scala, is for comprehensions. This feature helps us to create concise and elegant solutions for a bunch of different problems. In a nutshell, for comprehensions are syntactic sugar for the following methods: withFilter, foreach, map, and flatMap.

For comprehensions come in different flavors, and depending on how we write them, they translate to a different thing. Through this post, I’m going to cover different ways you can write a for comprehension, and what kind of problems it will help you solve.

Since I decided to create a blog, I’ve been thinking about what my first post will be about. I’ve been working with Java for more than 3 years, but a couple of months ago I started to work in a application that is built in Scala. Since Scala is mostly what I’m studying right now, I decided to start this blog with a post about the things that I like about it.