flatMap explained

Understanding how map works is pretty easy. It doesn’t need a second thought. In the contrary flatMap usually needs a bit of thinking to realize/remember how it works. In this post I’ll try to give a schematic explanation of the difference of flatMap & map.

Basically, map & flatMap result to the same thing. They take a monad & return a monad with transformed values.

monad transformations

The difference between them lays in the transformation function. Map’s transformation function takes a value & returns a value where flatMap takes a value & returns a monad with the transformed value.



Now you will ask me why is it called flatMap then? Well .. it’s called flatMap because if you use map on a function that returns a monad, you get a “doublemonad (see drawing below). So in that context, flatMap “flattens out” the result 🙂

issue with map

And that situation (double monad) happens quite often! For example, if you have a booking that has an optional user. And the optional user has an optional email. And you want to write a method getEmail() that gives you the email option of a booking, how would you do it with map?

booking : Booking
booking.user : Option[User]      
booking.user.email : Option[String]
def getEmail(booking: Booking) : Option[String] = ???

If you use map for it, you’ll have to do something like that (mainly because booking.user.map(_.email) returns an Option[Option[String]]):

def getEmail(booking: Booking) = booking.user.map(_.email).getOrElse(None)

This is where flatMap becomes useful. Due to the fact that flatMap’s transformation function is returning a monad, we kind of right away get the inner monad!:

def getEmail(booking: Booking) booking.user.flatMap(_.email)

And that’s it! Do you get it now why is it called flatMap? Hope this blog post helps you remember it 🙂 Have a nice day!

Advantages of Play Framework in Scala over PHP down the road

Prior to switching to Play Framework (in Scala), I was using CakePHP and Zend Framework (in PHP). It has been a great time developing with CakePHP but as the time passes I see lots of disadvantages of using PHP. Here is a list of what comes to my mind:

1. Deployment & Maintenance

The biggest issue I have right now with PHP projects is maintenance. I’m simply too scared to get software updates for my webserver! Why? Because I’m afraid that a PHP package or a PEAR package will get updated and I’ll have to modify some old code that I don’t want to touch. I had the same problem trying to run an old PHP project on my new laptop. I just couldn’t! Got a bunch of errors cause my new laptop had a newer version of PHP and some PEAR packages (Amazon AWS SDK for example) changed quite a bit and I had to modify all around the code which wouldn’t work if I would publish it on the server that uses the old PEAR package.

If the project would be still active & it would worth the time, I would spend it. But not all projects do.

When I switched to Play Framework, all these issues were gone! All the libraries I’m using are downloaded automatically by SBT (Scala Build Tool), in the correct versions and there is no need to install any extra package on the server. The only requirement is to install JVM, which is usually not a big deal.

Also, when the new version of Play Framework came out, I didn’t have to update all my projects. Some projects will just stay with the old version of the framework. And they’ll work just fine because all the libraries of the framework are contained inside the project. Even the Scala language itself! I have right now two Play Framework projects running on the same server and one is using Scala 2.9 and the other one Scala 2.10. And they work just fine because I didn’t have to install Scala on the server. It’s contained in the packaged produced by play dist (the Play Framework command that packages the code).

2. Having control over the code

CakePHP and various other PHP frameworks make it very easy to get started. You usually run a scaffolding tool (web-based or command line) that generates your model, controller & views. Then you go around and you modify them and very quickly you have a working product! Authentication works without any extra code, you have an ACL (Access-Control-List) that allows only logged in users to access some pages and other pages are restricted only to admins. Everything seems fine! But what happens further down the road?

Further down the road things get a bit trickier:

  1. The auto-generated forms will not be sufficient and you’ll have to dive deep into the framework to find how to replace them with more verbose code that allows you to change some parameters
  2. The authentication will need some extra tweaking to redirect users to different urls depending on the user’s role and you’ll wonder how to do this since there is no code for authentication in your files!
  3. You’ll need some more precise authorization mechanism to prevent user’s from accessing each other’s data. And what will you do? Do you really want to put that “if” in every action in your controllers?
  4. At some point your interaction with the database will become a bit tricky. You’ll realise that you need to speed up some queries. And you open your model’s file and you see no code in it! Then you have to dive deep into the framework to learn the database mechanisms and how to use them. And also how to switch off all that magic that loads all the other dependent models on each request, where you don’t really need them.

With frameworks like Play Framework, things are a bit different. You start with an empty project. No scaffolding, no auto-generated codeno database magic. You need to learn how to access the database to create your models, then learn how to generate forms and then how to write the authentication and authorization code. It’s quite a bit of work telling the truth and might seem unproductive at the beginning. But further down the road things are a lot better:

  1. You can do any modifications you want on your forms. All the code is there and you know where to find the documentation.
  2. You can do all the tweaks you want on your authentication. The code is all there and you wrote it. Maybe you copy-pasted it but you still know where it is in your code.
  3. You can also modify the authorization mechanism and find really elegant ways of expressing it. There is absolutely no need to add that “if” to every action!
  4. You’ll also not have any problem with the database. You wrote all the queries and all the model’s code. It’s all there. Do any changes you need and speed up those slow queries.

Ok. That’s it about having control over the code. I think you got the point.

3. Refactoring

This subject is rather lame but it’s good to mention it. You already know that Scala is a compiled language where PHP is an interpreted language. Therefore if you modify some code in Scala you’ll get a bunch of compile errors before you’ll be able to run again your website. And Play Framework will show you exactly on which files and which line the error is. It’s a bit of trouble sometimes but once you fix the errors you have a bit more peace in your mind that the code is working as it should. You should still test it of course but at least you are not afraid that your client will open a page and see a syntax error!

With PHP things are different. You change the code and then you have to go around the website and see if everything works fine. You’ll tell me now that it’s the same with Scala but it’s not. With Scala you at least know that when a function is expecting a String, it’ll receive a String and not an array. But with PHP you don’t know that. You have to do more tests to make sure of that. So watch out with PHP.

Ok. That was lame. Compiled Vs Interpreted. We heard it 1000 times.

What I really wanted to say about refactoring is that with Play Framework and Scala you can do lots of simplifications on your code. What do I mean? Let me give you some examples that come to my mind:

  • In your actions for users you want to have quick access to the user model. Then you define a method def user(implicit req:Request[AnyContent]) that implicitly takes the request and returns you the user stored in the session. Then all around your actions you can easily access your current user.
  • You can simplify your validation code and create really readable and elegant code. See this blog entry about it.
  • You can create a toJson method on your models that produces a json version of your object with the values you want to include by combining information from other models etc.
  • Simplify your models by creating a base model with methods like find, update, insert, delete etc. I know these are provided by the PHP frameworks but here you can easily modify them to optimize them whenever you want.

It’s a lot more things than what I wrote here but I can’t recall all of them right now. I hope you got the point.


Since I switched to Play Framework (in Scala) from Cake PHP a year and a half ago, I have enjoyed coding a lot more! I’m already quite efficient with Play and I can find endless way to simplify my code and make it really neat and readable. And deployment is going really well! No issues with the server updates, websites run super fast and barely having any downtime. I’m really happy with Play and Scala and I really want to see more people using it! Not only because it’s fun & very productive environment but I also want it to be easier to find people to work with on Play projects 🙂 The more people get to know Play and Scala the less arguments I’ll have to bring in to convince them to use it on a new project with me 🙂

Ok .. I wrote a quite a lot today! Need to get back to work!

Try, the new monad in Scala 2.10

Today I tried for the first time Scala’s Try monad. I used it twice already and I’m sure I’ll use a lot more times!

Here is how I used it the first time. I wanted to parse some CSV data into a sequence of case classes. And of course, with input data you never know what can go wrong. I didn’t really want to handle the error, I just wanted to know if it was parsed correctly or not. Therefore I used an Option to return either Some(result) or None.

Here is the code for the attempt with Option:

def parseCSV(csv : String) = {
  try {
    Some {
      csv.split("\n").map { line =>
        val tokens = line.split(";")
        ActivityData(tokens(0).toLong, tokens(1).toInt, tokens(2).toInt, tokens(3).toLong)
  } catch {
    case _ : Throwable => None

A bit complicated isn’t it? Using this function is cool (just as with every other Option) but actually reading it is painful. It’s just too messy with that try catch. Is there a better way of doing this?

Well, there comes the Try monad from scala.util package to save the situation!

def parseCSV(csv : String) = Try {
  csv.split("\n").map { line =>
    val tokens = line.split(";")
    ActivityData(tokens(0).toLong, tokens(1).toInt, tokens(2).toInt, tokens(3).toLong)

Look at this! Wow! This is neat! Just surround your code with Try and that’s it!

And the best part, you can use it exactly the same way as you would use the Option monad (dah .. that’s what are monads all about).

parseCSV(csvdata).map { entries =>
  //do something with the data
}.getOrElse {
  BadRequest("Invalid CSV Data")  //this is Play Framework specific (returns a 400 HTTP response with a message)

Note: For those who are wondering how does this work, the Try monad returns Success(something) if everything was calculated without any exceptions and Failure(error) if an error was thrown while executing the argument of Try().

Note (deep): Try takes its argument by-name (not by-value), therefore it can execute it within a try, catch the exception and return either Success or Failure. Isn’t Scala a super powerful awesome language? Yes it is!

How to simplify your action’s validation code in Play Framework 2 (with Scala of course)

In web development you very often want to do some checks if the data passed through parameters are valid. I’m not talking about having valid format but if for example the corresponding entry exists or if the user has the right to access that information or not. I’ll be a bit more specific by using an example and you’ll get my point. Ok, let’s consider that we want to make a web app which manages devices and users. A device has a unique id and a name. A user has a unique id, a name and a set of devices attached to him. Let’s assume we wrote all the necessary code and we want to provide an action that attaches a device to a user. How would we do that? My first approach would be something like this:

object Users extends Controllers {

  def attachDevice(user_id : Long, device_id : Long) = Action {
    models.User.getById(user_id).map { user_id =>
      models.Device.getById(device_id).map { device_id =>
        if (models.User.attach(user_id, device_id))
      }.getOrElse { BadRequest("Invalid device id") }
    }.getOrElse { BadRequest("Invalid user id") }


That’s fine! It’s not a bad approach. We do all the necessary tests. Code is more or less readable. It’s clear what we return in each case. But what happens when we want to have another action that needs to check if the user_id or device_id is valid? Would we rewrite them?

Not really! We would refactor them!

Great! Let’s create a trait Security and put our validations there.

trait Security {
  import play.api.mvc.Results._

  def withValidDevice(device_id : Long)(result : Result) = {
    if (models.Device.getById(device_id).nonEmpty)
      BadRequest( "Invalid device id" )

  def withValidUser(user_id : Long)(result : Result) = {
    if (models.User.getById(user_id).nonEmpty)
      BadRequest( "Invalid user id" )

  def IsValidUserAndDevice(user_id : Long, device_id : Long)(f: Request[AnyContent] => Result) = Action { req =>
    withValidUser(user_id) {
      withValidDevice(device_id) {

That’s it! Let’s use it now in our controller to simplify the code. Can you guess what it would be?

object Users extends Controllers with Security {

  def attachDevice(user_id : Long, device_id : Long) = IsValidUserAndDevice(user_id, device_id) {
    if (models.User.attach(user_id, device_id))

This is a lot cleaner isn’t it? But what if we want to process a POST request with form data? How would we use our validations? It turns out that it’s not so hard to do (see code below).

object Users extends Controllers {

  import play.api.data.Forms._
  import play.api.data._

  case class AttachData(user_id : Long, device_id : Long)

  val attachForm = Form(
      "user_id" -> longNumber,
      "device_id" -> longNumber

  def attachDevice(user_id : Long, device_id : Long) = Action {
      formWithErrors => BadRequest( formWithErrors.errorsAsJson ),
      data => {
        withValidUser(data.user_id) {
          withValidDevice(data.device_id) {
            if (models.User.attach(user_id, device_id))

We could for improvement define a method withValidUserAndDevice in our Security trait and then simplify the POST request code as well.


There is no very special conclusion telling the truth but I just wanted to point out this pattern with defining two validation methods:

  1. A method that returns an Action and can simplify the code of the GET requests
  2. A method that returns a Result which can simplify the POST requests and is flexible enough to be used in every action you want

As always, I hope you’ll find this blog entry useful and will help you simplify your validation code with Play Framework 2 and Scala 🙂

Play Framework and the problem with anorm executeInsert and multiple rows

I’m using Play Framework 2.0 for a few of my projects and I find it amazing. Lately I had a little problem with the executeInsert() method of Anorm. This method, executes the query and returns an Option[Long] which is the id of the inserted row. That’s all fine when you do single row inserts but what happens when you do multiple row insert?

Well .. I was getting this error:

 Execution exception[[RuntimeException: SqlMappingError(too many rows when expecting a single one)]]

This was a bit of a problem because the alternative methods (execute() and executeUpdate()) provided by the framework also didn’t return what I wanted (the ids of the new rows).

So what should I do? I decided to dive into the code of Anorm and see what’s going on. I opened the Anorm.scala on GitHub and found the code of executeInsert (link to that line of code). Immediately after I read the implementation I realised that the method was taking an implicit parameter, which happened to be the result parser that collects the inserted row ids. And that parser was by default set to scalar[Long].singleOpt.

So the solution to my problem was very simple! I just had to provide another parser as a parameter that would return me all the rows. Can you guess what would that be?

.executeInsert( scalar[Long] * )

Hope this blog post will be useful to somebody else in the future 🙂 .. that’s why I’m writing it anyway!

Have a nice day!!

Functional Programming in PHP

For the last half a year I have been coding in Scala and today I had to switch back to PHP to add some functionality to an old service. The interesting part was that it was coming more naturally to me to use filter and map to do my job instead of using foreach. Well .. here is what came out:

$keywords = array_filter( explode(" ",$keyword), function($x) { return !empty($x); } );
$keywordsQuery = implode( " AND ", array_map ( function($x) { return "body LIKE '%$x%'"; }, $keywords) );

This was the first time I was using array_filter and array_map and anonymous functions so I was very excited while writing it but the result isn’t the most readable. Also it wasn’t so easy to write it cause I had to go to the PHP website to check in which order do the arguments go (first the callback or the array?), which is something you don’t need to check when coding in a more object-oriented way. Also I noticed that PHP’s anonymous functions have a similar ugliness with Javascript. You have to write the whole word “function” which takes quite some space and makes inline anonymous functions very verbose & hard to read.

Anyway. Luckily I wont have to write too much code in PHP for this new feature and I hope there wont be many more things to write in PHP. I’m not saying that the there is something wrong with the language. I’m just saying it’s hard to go back from Scala to PHP.

So .. that’s all I wanted to share with you today. Below is the code of how I would do it in Scala (didn’t run it but more or less it should work!).

keywords = keyword.split(" ").filter(_.nonEmpty).map(x => "body LIKE '%" + x + "%'").mkString(" AND ")