FactoryPal: New Scala framework for creating objects as test data. Say no to Fixtures and Mocks.

by @mgonto, original article can be found here

Hey everyone! First of all, if you want to read the original article please go to this link

FactoryPal is a scala framework that lets you create objects as test data. All you have to do is define the templates for each of the classes that you want FactoryPal to create objects from. After that, FactoryPal takes care of the rest.

Have you ever heard of factory_girl a super cool Ruby framework? Well, FactoryPal is factory_girl for Scala. It is pretty similar in its use. The difference is that FactoryPal is 100% type safe, which all of us Scala people love.

Here is a link to Github for the anxious https://github.com/mgonto/factory_pal

How do we use this?

FactoryPal is a singleton object where you can register all of the templates. For example, you can define a template as follows:

FactoryPal.register[Person] { person =>
    person.name.mapsTo("gonto") and
    person.age.isRandom
}

In this example, we register a new template for class model. If we try to set a value for a property that Person doesn’t has, your project won’t compile. If you try to set a value to a property that isn’t the type of that property, the project won’t compile either. Pretty cool huh? This was possible thanks to Scala Macros and Dynamic, two features added in the latest Scala 2.10 RC release.

For the time being, there are 3 supported operations on a field template.

• mapsTo: This sets a certain specific value to that property.
• isRandom: This sets a random value based on the type of the field. I’ve created some implicit randomizers for common objects (String, Long, Int, Double, etc.) but you can create your own. This is pretty similar to Ordering[T] used in List.
• isAnotherFactoryModel: You tell FactoryPal that this is an inner object that can be constructed with another template of FactoryPal. For the time being, there can only be one template for each class. I’m going to change this very soon.

After we created the template, we can instantiate objects of that template as follows:

val person = FactoryPal.create[Person]

The create method has another overload that lets you add some field overriders for certain test. For example you can do the following:

val person = FactoryPal.create[Person] { (person : ObjectBuilder[Person]) =>
    person.age.mapsTo(45) alone
}

And that’s it. That’s all you need to know to use this.

How can I add this to my project?

This is an example configuration for Build.scala for your SBT project :). There’re only snapshots for now as Scala 2.10 is not yet final. Once it’s, I’m going to make a release.

import sbt._
import sbt.Keys._
 
object ApplicationBuild extends Build {
 
  lazy val root = Project(
    id = "factory_pal_sample",
    base = file("."),
    settings = Project.defaultSettings ++ Seq(
      name := "factory_pal_sample",
      organization := "ar.com.gonto",
      version := "0.1",
      scalaVersion := "2.10.0-RC3",
      scalacOptions += "",
      licenses      := ("Apache2", new java.net.URL("http://www.apache.org/licenses/LICENSE-2.0.txt")) :: Nil,
      libraryDependencies ++= Seq(
       "org.scala-lang" % "scala-compiler" % "2.10.0-RC3",
       "ar.com.gonto" % "factory_pal_2.10" % "0.1-SNAPSHOT",
       "org.scalatest" % "scalatest_2.10.0-RC3" % "1.8-B1" % "test"
      ),
      resolvers ++= Seq(
         "Typesafe repository" at "http://repo.typesafe.com/typesafe/releases/",
         Resolver.url("Factory Pal Repository", 
          url("http://mgonto.github.com/snapshots/"))(Resolver.ivyStylePatterns)
      )
    )
  )
}

Take a look at the dependency and the repository!

What does it use internally?

Internally, this framework uses Scala Macros, Dynamic and the new Reflection library provided by Scala 2.10.

Next Steps

The next things I want to do are:

• Add the posibility to have multiple templates for one Class
• Add template inheritance
• Add helpers to use this with ScalaTest and Specs2. For the moment, you can create the templates in the before.

For more information or to take a look at the code go to Github

Play! Framework 2 (2.1) Scala with Slick made easy (With example)

by @mgonto, original article can be found here

Hi everyone!

First of all, I want to tell you that the original post is from here (Blogeek).

Today I’ve seen some videos about Slick and Play! Framework 2.1 and I got excited, so I thought, let’s code an app with Slick. What did I realize? It wasn’t that simple. Play! isn’t yet thought to work with Slick very well.

First of all, if you want to see this example complete you can go to

https://github.com/mgonto/slick-play2-example

In Slick, you create table definitions for the class you want to use. However, all of the imports for the Table, the columns, etc. are driver dependant. So, when you change the driver, you don’t want to change the import in the code. You just want to change a configuration in the application.conf from Play! Framework. That’s exactly what I did.

So, let’s see first how it’s implemented. Every Driver (H2, Postgres, etc) extends from a trait called ExtendedProfile. So, I needed my table classes to use some profile that was injected by me. Once I realized that I needed to make some DI I thought about Cake Pattern. For more information about the Cake Pattern please viisit Cake pattern

So, the first thing I implemented was a Trait Profile with an abstract Extended Profile value:

package models

import slick.driver.ExtendedProfile

trait Profile {
  val profile: ExtendedProfile
}

After this, I needed to create the Users table. That Users table needed the profile, so I’d create a UserModule which would need the Profile trait. Then, as I’d mix with a Profile trait, I’d import the things from the abstract ExtendedProfile field and everything would compile. Then I create the users table with an ID and a Name (pretty simple)

package models

case class User(id: Option[Int], name : String)

trait UserComponent {
  this: Profile =>

  import profile.simple._

  object Users extends Table[User]("users") {
    def id = column[Int]("id", O.PrimaryKey)
    def name =  column[String]("name", O.NotNull)
    def * = id.? ~ name <> (User, User.unapply _)

    def add(user: User)(implicit session: Session) = {
      this.insert(user)
    }

    def countByName(name: String)(implicit session: Session) = {
      (for {
        user <- Users
        if (user.name === name)
      } yield(user)).list.size
    }

  }
}

After this, I create a DataAccessLayer class (DAL) which would receive the ExtendedProfile as a constructor parameter and then would include the other traits (Profile and UserModule)

package models

import slick.driver.ExtendedProfile

class DAL(override val profile: ExtendedProfile) extends UserComponent with Profile {

  import profile.simple._

  def create(implicit session: Session): Unit = {
    Users.ddl.create //helper method to create all tables
  }
}

After this, I have everything to create a DAL from a given profile. However, now I needed a way to configure the profile, so I added a new property in the application.conf.

slick.db.driver=scala.slick.driver.H2Driver

Then, I created a trait that would import this driver from the conf and create the database to do the queries and the dal with the corresponding profile. It has two methods, getDb and getDal which will be then used by two other classes.

package models

import slick.session.Database
import play.api.db.DB
import play.api.Application
import slick.driver.ExtendedProfile

trait DBeable {

  val SLICK_DRIVER = "slick.db.driver"
  val DEFAULT_SLICK_DRIVER = "scala.slick.driver.H2Driver"

  def getDal(implicit app : Application) : DAL = {
    val driverClass = app.configuration.getString(SLICK_DRIVER).getOrElse(DEFAULT_SLICK_DRIVER)
    val driver = singleton[ExtendedProfile](driverClass)
    new DAL(driver)
  }

  def getDb(implicit app : Application) = {
    Database.forDataSource(DB.getDataSource())
  }

  private def singleton[T](name : String)(implicit man: Manifest[T]) : T =
    Class.forName(name + "$").getField("MODULE$").get(man.runtimeClass).asInstanceOf[T]

}

The only things left are creating the DB once the app starts and having a singleton object to be able to ask for the dal and the database to do the queries from a controller. This is done as following:

import models.{User, DBeable, AppDB}
import play.api.db.DB
import play.api.GlobalSettings
import play.api.Application
import slick.session.Session

object Global extends GlobalSettings with DBeable {

  override def onStart(app: Application) {
    implicit val application = app
    lazy val database = getDb
    lazy val dal = getDal
    database.withSession {
      implicit session: Session =>
        dal.create
    }
  }
}
package models
import play.api.Play.current
object AppDB extends DBeable {

  lazy val database = getDb
  lazy val dal = getDal

}

And that’s it :). Now you have everything configured to start coding. I’ve tried if everything was working with a test as following.

class UserSpec extends Specification {

  "User" should {

    "be saved" in {
      running(FakeApplication(additionalConfiguration = inMemoryDatabase())) {
        AppDB.database.withSession {
          implicit session: Session =>
            AppDB.dal.Users.add(User(Some(2), "hola"))
            AppDB.dal.Users.countByName("pepe") must beEqualTo(0)
            AppDB.dal.Users.countByName("hola") must beEqualTo(1)

        }
      }
    }
  }
}

And that’s it 🙂 Now you have Play! configured for running with Slick.

Cya people!

Deploying Play Framework 2 apps, with Java AND Scala, to Openshift

Let’s Play! in the cloud

A couple of weeks, Mark Atwood, Jorge Aliss, and me, Sebastián Scarano participated in Red Hat’s webinar LET’S PLAY! IN THE CLOUD: DEVELOPING JAVA WEB APPS ON OPENSHIFT

In the webinar Mark gave a neat introduction to Openshift, Red Hat’s free Platform as a Service:

Then we developed a basic contact manager web application, combining Java and Scala source code in the same Play 2 application, and deployed it on Openshift.

With this quickstart (https://github.com/opensas/play2-openshift-quickstart) you’ll be able to take any Play 2 application and deploy it on openshift. Just follow this instructions.

And here (https://github.com/opensas/play2-contacts-demo) you will find the contact demo app.

In the demo, in spite our internet connection conspiring against us, we managed to cover the following topics:

• Creating a new play 2 application
• Basic application structure
• Configuring your IDE to work with a Play application
• Routes
• Controllers
• Templates
• Models
• Persisting your data to an in-memory database with Ebean
• Adding Validations
• Working with Scala Templates
• Mixing Java and Scala source code in the same application
• Integrating twitter bootstrap
• Customizing your app cofiguration for running on Openshift
• Persisting your data to a file database when running on Openshift
• And finally, deploying your application on Openshift

You can also check this article in which we explain in detail how we took advantage of the new “do-it-yourself” application type on Openshift to achieve native support for Play Framework application on Openshift.

So, if you want to start deploying your play apps on openshift right away, just sign up at openshift.com and enter PLAY!WEBINAR as promotional code, and you’ll get 3 gears, each with 1GB ram and 512 MB data space, for free.

Have fun playing on the cloud!

Play Framework posted values revisited

This is a follow up of palamago’s original tip: how to get a single POST value?

Working with posted values with Play Framework 2.0, without defining a form mapping, might not be so obvious as it was with Play 1.x, that’s why I’m writing this quick cheatsheet.

For this quick sample, let’s define the following view:

app/views/index.scala.html

@(message: String)

message: @message <br />

<h2>Scala form</h2>

<form action="@routes.ScalaPoster.save()" method="POST">
  scala name: <input name="scala_name"> <br />
  scala surname: <input name="scala_surname"> <br />
  <input type="submit" value="save">
</form>

<h2>Java form</h2>

<form action="@routes.JavaPoster.save()" method="POST">
  java name: <input name="java_name"> <br />
  java surname: <input name="java_surname"> <br />
  <input type="submit" value="save">
</form>

And the following routes file:

conf/routes

# Home page
GET     /                         controllers.Application.index

POST    /scala                    controllers.ScalaPoster.save
POST    /java                     controllers.JavaPoster.save

With java, accesing directly the request body:

app/controllers/JavaPoster.java

package controllers;

import play.mvc.*;

import views.html.*;

import java.util.Map;

public class JavaPoster extends Controller {
  
  public static Result save() {

    final Map<String, String[]> values = request().body().asFormUrlEncoded();
    final String name = values.get("java_name")[0];
    final String surname = values.get("java_surname")[0];
    
    return ok(index.render(String.format("You are %s, %s",surname, name)));
  }
  
}

Or using a DynamicForm:

package controllers;

import play.mvc.*;

import views.html.*;

import play.data.DynamicForm;

public class JavaPoster extends Controller {
  
  public static Result save() {

    final DynamicForm form = form().bindFromRequest();
    final String name = form.get("java_name");
    final String surname = form.get("java_surname");
    return ok(index.render(String.format("You are %s, %s",surname, name)));
  }
  
}

Now the scala version, accessing the body:

app/controllers/ScalaPoster.java

package controllers

import play.api.mvc._

object ScalaPoster extends Controller {

  def save = Action { request =>

    def name = request.body.asFormUrlEncoded.get("scala_name")(0)
    def surname = request.body.asFormUrlEncoded.get("scala_surname")(0)

    Ok(views.html.index("You are %s, %s".format(surname, name))) 
  }

}

And defining a form

package controllers

import play.api.mvc._

import play.api.data.Form
import play.api.data.Forms.tuple
import play.api.data.Forms.text

object ScalaPoster extends Controller {

  val form = Form(
    tuple(
      "scala_name" -> text,
      "scala_surname" -> text
    )
  )

  def save = Action { implicit request =>
 
    def values = form.bindFromRequest.data
    def name = values("scala_name")
    def surname = values("scala_surname")

    Ok(views.html.index("You are %s, %s".format(surname, name))) 
  }

}

Notice the implict request in the above sample. You could explicitly pass it to bindFromRequest with

    def values = form.bindFromRequest()(request).data

You can also play with the tuples and issue something like

    val data = form.bindFromRequest.get
    Ok(views.html.index("You are %s, %s".format(data._2, data._1))) 

or

    val (name, surname) = form.bindFromRequest.get
    Ok(views.html.index("You are %s, %s".format(surname, name))) 

And of course, if you just want to read a single posted value you could issue:

    def name = Form("scala_name" -> text).bindFromRequest.get

There are several ways to achieve it. I hope this serves as a useful reminder.

Desplegando aplicaciones de Play Framework 2, con Java Y Scala, en Openshift

Play framework en la nube de Red Hat

Hace un par de semanas, Mark Atwood, Jorge Aliss, y quien les escribe, Sebastián Scarano participamos del webinar LET’S PLAY! IN THE CLOUD: DEVELOPING JAVA WEB APPS ON OPENSHIFT organizado por Red Hat.

En el webinar, Mark dio una completa introducción a Openshift, la plataforma de cloud computing de Red Hat:

Luego junto con Jorge desarrollamos una simple agenda de contactos, usando Play Framework 2.0, combinando en una misma aplicación código fuente en Java y en Scala, y luego la pusimos en producción en Openshift.

Con este quickstart (https://github.com/opensas/play2-openshift-quickstart) podrán desplegar cualquier aplicación de Play 2.0 en Openshift. Simplemente sigan estas instrucciones.

Y aquí (https://github.com/opensas/play2-contacts-demo) encontrarán el código fuente de la agenda de contactos.

En la demo, a pesar de que nuestra conexión a internet nos jugó una mala pasada, logramos abordar los siguientes temas:

• Crear una nueva aplicación de Play 2
• Estructura básica de una aplicación
• Configurando su IDE favorito para trabajar con Play 2.0
• Rutas HTTP
• Controladores
• Templates
• Modelos
• Persistiendo sus datos en una base de datos en memori usando Ebean
• Validaciones
• Trabajando con los templates en Scala
• Combinando código fuente de Java y Scala en una misma aplicación
• Integrando twitter bootstrap
• Personalizando la configuración de su aplicación para correr en Openshift
• Guardando sus datos en una base de datos persistente al correr en Openshift
• Y finalmente desplegando su aplicación en Openshift

También pueden consultar este artículo en el cual analizamos en detalle cómo aprovechar el nuevo tipo de aplicación “do-it-yourself” (hagalo usted mismo) de Openshift para brindar soporte nativo a las aplicaciones de Play.

Si que si desean empezar a jugar con Openshift ya mismo, regístrense en openshift.com ingresen PLAY!WEBINAR como código de promoción, y recibirán 3 gears, cada uno con 1GB de memoria ram y 512 MB de espacio de almacemiento, gratis.

¡Esperamos que les guste!

Play framework 2 quicktip: interactively play with your application from the scala console

Short version for impatients:

path_to_your_play2_app$ play console
scala> new play.core.StaticApplication(new java.io.File("."))

And don’t forget that the tab key is your friend!

---

When I first started to play with Scala, I was amazed by the Scala interactive interpreter (also known as REPL, read-evaluate-print-loop). It was one of those things that you never expected to find in a statically typed, compiled language like java or scala.

What would you say if we could have it for our play applications?… In scala OR JAVA! And yes, with tab completion and all the bells-and-whistles…

Well, thanks to Peter Hausel (@pk11) from the play dev team, I found out how to do it.

Just open a command prompt and type:

cd <path_to_your_play2_app>
play console

[info] Loading project definition from /home/sas/Dropbox/Public/devel/play/apps/play2/todo/project
[info] Set current project to todo (in build file:/home/sas/Dropbox/Public/devel/play/apps/play2/todo/)
[info] Starting scala interpreter...
[info] 
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.6.0_31).
Type in expressions to have them evaluated.
Type :help for more information.

That’s it, you are at the scala console, and what’s best, with tab completion enabled!

Right there you can start playing with scala, and also with your application, like this:

scala> val contact = models.Contact(1, "new contact", "new address")
contact: models.Contact = Contact(1,new contact,new address)

You can test your views, and of course you can also issue imports to save yourself quite a few keystrokes

scala> import models._, views.html._
import models._
import views.html._

scala> val contacts = Seq( Contact(1, "@develsas", "Buenos Aires"), Contact(2, "@pk11", "Paris") )
contacts: Seq[models.Contact] = List(Contact(1,@develsas,Buenos Aires), Contact(2,@pk11,Paris))

scala> contact.list(contacts)
res1: play.api.templates.Html = 
<!DOCTYPE html>
<html>
    <head>
        <title>Contact list</title>
        <link rel="styles
[...]
<tr>
	<td>@develsas</td>
	<td>Buenos Aires</td>
</tr>
<tr>
	<td>@pk11</td>
	<td>Paris</td>
</tr>
[...]

But when you try to access your database you’ll get the following error:

scala> val contacts = Contact.all()
java.lang.RuntimeException: There is no started application
	at scala.sys.package$.error(package.scala:27)
[...]

That’s easy, you just have to start your application

scala> import play.core._
scala> new StaticApplication(new java.io.File("."))
[info] play - database [default] connected at jdbc:h2:data/db
[info] play - Application started (Prod)
res1: play.core.StaticApplication = play.core.StaticApplication@10cdd4

And now you can play arround interactively with your running application

scala> val contacts = Contact.all
contacts: Seq[models.Contact] = List(Contact(1,Paul,Boston), Contact(3,Paolo,Roma), Contact(4,Paulain,Paris), Contact(5,Abelardo,San Justo))

scala> val newContact = Contact(6, "new contact", "new address")
newContact: models.Contact = Contact(6,new contact,new address)

scala> Contact.insert(newContact)
res2: Int = 1

scala> val contacts = Contact.all
contacts: Seq[models.Contact] = List(Contact(1,Paul,Boston), Contact(3,Paolo,Roma), Contact(4,Paulain,Paris), Contact(5,Abelardo,San Justo), Contact(6,new contact,new address))

Now go check your database, you’ll see the new contact has been persisted to your db.

One last tip. If you are working against the in-memory database, and you have defined any evolution script, you’ll receive this message when you start the application form play console:

scala> new play.core.StaticApplication(new java.io.File("."))
[info] play - database [default] connected at jdbc:h2:mem:play
[warn] play - Your production database [default] needs evolutions! 

# --- Rev:1,Ups - 74ff2d1
[...]

[warn] play - Run with -DapplyEvolutions.default=true if you want to run them automatically (be careful)
PlayException: Database 'default' needs evolution! [An SQL script need to be run on your database.]
	at play.api.db.evolutions.EvolutionsPlugin$$anonfun$onStart$1.apply(Evolutions.scala:422)
[...]

The solution is quite easy, just start play with

play -DapplyEvolutions.default=true

And your evolution scripts will be automatically applied when you start the application.

Go ahead and give it a try. Grab, for example, the computer-database java demo

$ cd <path_to_your_play2_installation>/samples/java/computer-database
$ play -DapplyEvolutions.default=true

[computer-database] $ console
[info] Starting scala interpreter...
[info] 
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.7.0_03).
Type in expressions to have them evaluated.
Type :help for more information.


scala> new play.core.StaticApplication(new java.io.File("."))
[info] play - database [default] connected at jdbc:h2:mem:play
[info] play - Application started (Prod)
res0: play.core.StaticApplication = play.core.StaticApplication@129796b

And now, just start playing around with your app

scala> val page = models.Computer.page(1, 10, "name", "asc", "")
page: com.avaje.ebean.Page[models.Computer] = com.avaje.ebeaninternal.server.query.LimitOffsetPage@d386c9

scala> val computerList = page.getList()
computerList: java.util.List[models.Computer] = BeanList size[10] hasMoreRows[true] list[models.Computer@137, models.Computer@20d, models.Computer@12e, models.Computer@1b7, models.Computer@12d, models.Computer@14a, models.Computer@14b, models.Computer@21f, models.Computer@98, models.Computer@1a2]

scala> computerList.get(0).name
res2: java.lang.String = ASCI White

Nevertheless, as soon as you start to play with the db, I faced a couple of problems. I could read from the database but I coudn’t write update nor inserts. I guess it’s the ebean voodoo magic that’s giving me troubles.

With the scala version, I could really go much further, look at this (go ahead, don’t be shy and copy-paste this code)

$ cd <path_to_your_play2_installation>/samples/scala/computer-database
$ play -DapplyEvolutions.default=true

[computer-database] $ console
[info] Starting scala interpreter...
[info] 
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.7.0_03).
Type in expressions to have them evaluated.
Type :help for more information.

scala> new play.core.StaticApplication(new java.io.File("."))
[info] play - database [default] connected at jdbc:h2:mem:play
[info] play - Application started (Prod)
res0: play.core.StaticApplication = play.core.StaticApplication@1eaf4b3

scala> import models._, anorm._, play.api.db._, play.api.Play.current, anorm.SqlParser._

import models._
import anorm._
import play.api.db._
import play.api.Play.current
import anorm.SqlParser._

scala> // clean-up everything

scala> DB.withConnection { implicit connection => 
     SQL("delete from computer").executeUpdate()
     SQL("delete from company").executeUpdate()
     }
res3: Int = 42

scala> // just checking

scala> DB.withConnection { implicit connection => SQL("select count(*) from computer").as(scalar[Long].single) }
res7: Long = 0

scala> DB.withConnection { implicit connection => SQL("select count(*) from company").as(scalar[Long].single) }
res8: Long = 0

scala> Company.options
res9: Seq[(String, String)] = List()

Ok, let’s create a couple of companies

scala> 
DB.withConnection { implicit connection => 
  Seq((1, "my Company"), (2, "my second company")).map { company =>
    SQL("insert into company values ( %s, '%s')".format(company._1, company._2) ).executeUpdate()
  }
}
res50: Seq[Int] = List(1, 1)

scala> Company.options
res51: Seq[(String, String)] = List((1,my Company), (2,my second company))

And a couple of computers

scala> val newComputer = Computer(NotAssigned, "my computer", None, None, Some(1))
newComputer: models.Computer = Computer(NotAssigned,my computer,None,None,Some(1))

scala> Computer.insert(newComputer)
res67: Int = 1

scala> Computer.insert(Computer(NotAssigned, "my second comuter", None, None, Some(2)))

scala> 
DB.withConnection { implicit connection =>
  SQL("select * from computer").as(Computer.withCompany *)
}
res8: List[(models.Computer, Option[models.Company])] = List((Computer(1000,my computer,None,None,Some(1)),None), (Computer(1001,my second comuter,None,None,Some(2)),None))

We’ll, this example is a little exagerated, but I guess you get an idea of what you can do with the play console, so keep hacking!

Primer Hackaton de Play! framework para Scala y Java en Argentina

Anotate en el primer Hackaton de Play! Framework en Argentina.

• ¿Cuándo? Sábado 5 de Mayo, a las 9:30 am
• ¿Dónde? Costa Rica 5546, Buenos Aires, Argentina

Nuestro objetivo en este primer meetup es que todos podamos conocer juntos Play! Framework 2.0, cada uno probando lo que mas le interesa de este framework, en el lenguaje que desea.

La idea es que cada uno que se anote, elija 2 de los 5 tópicos que le interesaría aprender, junto con un nivel de expertise en Play 2.0 y un lenguaje en el cual quiera realizar la experiencia. En base a esto, se crearán parejas para poder realizar Pair Programming durante todo el hackaton.

La dinámica del Hackaton será la siguiente:

1. Registración
   1. La registración comenzará a las 09:30 AM y continuará hasta las 10. Mientras nos vamos registrando vamos a poder desayunar café con medialunas
2. Charla inicial de Play! Framework
   1. Se dará una charla inicial de 30 a 45 minutos de Play! Framework 2.0 con ejemplos tanto en Scala como Java. Esta introducción nos permitirá tener a todos una idea básica de que es Play!
3. División de proyectos
   1. En base a las personas que estamos en el Hackaton y a los resultados de la encuesta, se crearán diversos proyectos pequeños que abarquen estas ideas. Se separarán a todas las personas en estos proyectos de a pares, para poder realizar Pair Programming
4. Trabajo en los equipos asignados hasta las 1730
5. Almuerzo
   1. El almuerzo estará incluido. Se proveerán Pizzas con bebidas para que todos podamos comer mientras codeamos.
6. Conclusiones
   1. Cada grupo debera preparar una mini charla de aproximadamente 10 minutos donde contarán los problemas y soluciones que se encontraron, mostrando un poco del código que hicieron

Para poder participar, es importante que traigas tu notebook y cuentes con:

• Cuenta en GitHub
• Conocimientos de Git
• Conocimientos de Java y/o Scala

Aquí tienen información que pueden ir leyendo para ir informándose del tema:

• GIT: http://progit.org/book/
• Play!: http://www.playframework.org/documentation/2.0/Home
• Scala
  • Scala for the Impatient
  • Programming in Scala (pueden descargar la primera edición)

Los esperamos 😀

¡Lanzamiento de Play 2.0!

Traducido del blog de Typesafe

¡Presentando Play 2.0!

En noviembre del año pasado anunciábamos que Play, el framework de alta productividad para Java y Scala, pasaría a formar parte del stack de Typesafe. Hoy, apenas unos meses más tarde, nos complace poder anunciar que Play 2.0 ya está disponible como parte del Stack Open Source de Typesafe en su versión 2.0, junto con el soporte comercial de la subscripción de Typesafe.

Veamos algunas de sus principales características.

Soporte nativo para Java y Scala

Mientras que la versión original de Play Framework estaba escrita principalmente en Java, ofreciendo soporte para scala a través de plug-in, Play 2.0 adopta Scala de una manera más decidida. No sólo el núcleo central de Play ha sido migrado a Scala, sino que esta nueva versión brinda un soporte de primer nivel para el desarrollo de aplicaciones web con Scala. De manera tal que la nueva versión del framework provee dos API totalmente completas: una para desarrolladores de Scala y otra para desarrolladores Java.

Un controlador hecho con Java

El mismo controlador usando Scala

Desarrollo rápido de aplicaciones

Una de las características que hacían a la “experiencia de usuario” del desarrollador Play de la serie 1.x, era la consola de desarrollo y el reporte de errores en el propio explorador web. Play 2.0 mejora estas prestaciones al permitirle al desarrollador ejecutar porciones de código, pruebas o scripts de la línea de comando interactuando directamente con el runtime de la aplicación, y también compilando muchas de las partes típicas de una aplicación web.

Interactuando con los modelos de una aplicación Play 2.0 desde la consola

Llevando la seguridad de tipos a un nuevo nivel

Una de las ventajas de utilizar un lenguaje estáticamente tipado para escribir aplicaciones de Play, es que el compilador podía verificar partes del código por usted, Es por ello que Play 2.0 utiliza por defecto un lenguaje de templates basado en Scala, incluso para aquéllos desarrolladores que usen Java como su principal lenguaje de programación. Esto no signifca que usted deba convertirse en un experto en Scala para escribir templates en Play 2.0. Pero ahí está Scala, sin que usted lo note, trabajando en su beneficio.

Play 2.0 lleva las verificaciones en tiempo de compilación y el chequeo de tipos todavía más a fondo. Las rutas (que definen los URLs y el mapeo con las acciones), los templates, e incluso los recursos de la aplicación web son compilados (utilizando LESS, CoffeScript y el compilador de Google Clousure), poniendo a su disposición un entorno de desarrollo unificado tanto para los desarrolladores del lado del cliente como para los del lado del servidor. El resultado de todo esto es que más errores serán detectados en tiempo de compilación, acelerando el proceso de desarrollo de aplicaciones web. También hará muchísimo más simple trabajar en proyectos grandes que involucren numerosos desarrolladores.

Example route compilation failure detection

Jugando limpio

Play 1.x implementaba muchas de sus originales ideas (como la implementación automática de propiedades para Java y la recarga dinámica de sus clases) utilizando técnicas que requerían un runtime específico para Play. En cambio, Play 2.0 adopta un enfoque mucho más estándar para el despliegue del runtime. Esto fue posible escribiendo parte del framework en scala, y también aprovechando prestaciones de SBT, la popular herramienta de Scala para la construcción y despliegue de aplicaciones.

Play 2.0 mantiene la misma experiencia de los usuarios de la versión 1.x acostumbrados a ejecutar “play new, run start”, al mismo tiempo que parte de una base más fácil de extender. Play 2.0 ya trae configurado un script de compilación que funcionará sin modificaciones en la mayoría de los casos, pero si usted necesita personalizar la manera en que su aplicación es construida y desplegada, tendrá las herramientas a su alcance para adapatarla a sus necesidades. Como resultado de todo esto, hallará que será mucho más simple desplegar sus aplicaciones de Play 2.0 en los escenarios más variados.

Elija tan sólo las partes que va a usar

Dado que el diseño de aplicaciones web ha evolucionado en gran medida en los últimos años, Play 2.0 está construido siguiendo un criterio modular que le dará gran flexibilidad a la hora de elegir la tecnología a usar. ¿No desea usar una base de datos? Puede simplemente deshabilitar el plugin DB. ¿Quiere usar su propio motor de templates? Simplemente agrégue el plugin. ¿No necesita un framework web con todos los chiches? Use play como una simple librería. Usted decide qué tanto de la arquitectura de Play quiere usar en sus aplicaciones.

Deshabilitando plugins en el archivo conf/application.conf

Escale su apliación con Akka

Play está basado en una arquitectura liviana, sin estado, pensada para la web, que le asegura un consumo de recursos mínimo y predecible (en términos de CPU, memoria, threads) para desarrollar aplicaciones que requieren alta escalabidad. Esto es posible en parte gracias a Akka 2.0, el middleware basado en eventos que se encuentra en el corazón de Play 2.0. Los desarrolladores tienen acceso a toda la funcionalidad provista por Akka para construir aplicaciones altamente distribuidas que puedan ser escaladas para cumplir con los más altos niveles de demanda.

En este ejemplo puede ver como el resultado de un actor encargado de realizar un cálculo complejo, puede ser mapeado a un resultado de Play de una manera no-bloqueante

En este ejemplo puede ver como el actor ChatRoom envía un mensaje en porciones al cliente utilizando Comet

Manejo avanzado de entrada/salida y de Streams

Una de las más recientes tendencias en el desarrollo de aplicaciones web es el énfasis puesto en tecnologías de tipo push y no-bloqueantes. Play 2.0 utiliza una implementación de entrada/salida basada en Iteratee, que provee soporte para tecnologías avanzadas de push y streaming, partiendo desde WebSockets y Comet hasta streaming de archivos.

Un controlador de scala que utiliza el soporte para WebSockets de Play 2.0

Listos… preparados… a jugar con Play!

Play 2.0 es el resultado de una intensa colaboración entre Typesafe (liderados por Peter Hausel), el fundador del proyecto Guillaume Bort, la comunidad Play y Zenexity, la consultora orientada a la web donde Play fue creado. Ha sido una experiencia divertida y excitante trabajar junto con un grupo tan talentoso de desarrolladores.

Estamos sumamente complacidos de que Play hoy sea parte del Stack de Typesafe, junto con Scala, Akka y el soporte comercial, mantenimiento y herramientas de despliegue y administración (como la nueva consola de Typesafe) que juntas conforman el paquete de Subscripción de Typesafe. Typesafe también ofrece cursos de capacitación y consultoría para la nueva versión 2.0, para que su equipo pueda cuanto antes comenzar a desarrollar aplicaciones con Play 2.0.

Estamos convencido de que el lanzamiento de Play 2.0 marcará un antes y un después en las comunidades de Java y Scala, poniendo al alcance de los desarrolladores una experiencia novedosa que posibilitará inéditos niveles de escalabilidad y productividad.

Para que pueda empezar ya mismo con Play 2.0, hemos provisto varias aplicaciones de ejemplo con esta nueva versión. Así que lo invitamos a verlo en acción para decidir por usted mismo, ¡y divertirse haciéndolo!

Ya que ha llegado hasta aquí, no pierda los anuncios recientes de la versión 2.0 del Stack de Typesafe, Akka 2.0, y la Consola de Typesafe.

Para más información, lean el anuncio original en el blog de Typesafe

Secure JSON Services with Play Scala and SecureSocial, by Matt Raible

Matt Raible has kindly agreed to let us publish his article on playlatam. You can find the original article at his site.

 

Last November, I traveled to Antwerp to speak at Devoxx. After my talk on HTML5 with Play Scala, Mattias Karlsson approached me and we had a chat about doing the same talk at Jfokus in Stockholm. I agreed and we began talking details after Trish and I returned to the US.

I wrote this article on a plane between Denver and Seattle and will be hopping over the North Pole to Stockholm via Iceland tonight. For the past couple of weeks, I’ve been updating my Play More! HTML5/mobile app to add some new features. Most notably, I wanted to upgrade to Play 2.0, create JSON services and add authentication.

Upgrading to Play 2.0

My attempt to upgrade to Play 2.0 involved checking out the source from GitHub, building and installing the RC1 snapshot. As I tried to upgrade my app and started getting failed imports, I turned to the internet (specifically StackOverflow) to see if it was a good idea. The first answer for that question suggested I stay with 1.x.

If it’s a critical project, to be finished before next March 2012, I would go with Play 1.x. If it’s a less important project, which could be delayed, and that in any case won’t be released before March 2012, try Play 2.0.

While I didn’t plan on releasing Play More! before Jfokus, I decided upgrading didn’t add a whole lot to the talk. Also, I couldn’t find a Play Scala 0.9.1 to Play 2.0 upgrade guide and I didn’t have enough time to create one. So I decided to stick with Play 1.2.4 and add some JSON services for my iPhone client.

JSON Servers

I found Manuel Bernhardt’s Play! Scala and JSON. This led me to Jerkson, built by the now infamous@coda. I was able to easily get things working fairly quickly and wrote the following WorkoutService.scala:

package controllers.api

import play.mvc.Controller
import models._
import com.codahale.jerkson.Json._

object WorkoutService extends Controller {

  def workouts = {
    response.setContentTypeIfNotSet("application/json")
    generate(Workout.find().list())
  }
  def edit(id: Long) = {
    generate(Workout.byIdWithAthleteAndComments(id))
  }

  def create() = {
    var workout = params.get("workout", classOf[Workout])
    Workout.create(workout)
  }

  def save(id: Option[Long]) = {
    var workout = params.get("workout", classOf[Workout])
    Workout.update(workout)
  }

  def delete(id: Long) = {
    Workout.delete("id={id}").on("id" -> id).executeUpdate()
  }
}

Next, I added routes for my new API to conf/routes:

GET     /api/workouts               api.WorkoutService.workouts
GET     /api/workout/{id}           api.WorkoutService.edit
POST    /api/workout                api.WorkoutService.create
PUT     /api/workout/{id}           api.WorkoutService.save
DELETE  /api/workout/{id}           api.WorkoutService.delete

Then I created an ApiTest.scala class that verifies the first method works as expected.

import play.test.FunctionalTest
import play.test.FunctionalTest._
import org.junit._

class ApiTests extends FunctionalTest {
  
    @Test
    def testGetWorkouts() {
        var response = GET("/api/workouts");
        assertStatus(200, response);
        assertContentType("application/json", response)
        println(response.out)
    }
}

I ran “play test”, opened my browser to http://localhost:9000/@tests and clicked ApiTests -> Start to verify it worked. All the green made me happy.

Finally, I wrote some CoffeeScript and jQuery to allow users to delete workouts and make sure delete functionality worked.

$('#delete').click ->
  $.ajax
    type: 'POST'
    url: $(this).attr('rel')
    error: ->
      alert('Delete failed, please try again.')
    success: (data) ->
      location.href = "/more"

I was very impressed with how easy Play made it to create JSON services and I smiled as my CoffeeScript skills got a refresher.

The Friday before we left for Devoxx, I saw the module registration request for SecureSocial.

SecureSocial with Play Scala
From SecureSocial’s README:

SecureSocial allows you to add an authentication UI to your app that works with services based on OAuth1, OAuth2, OpenID and OpenID+OAuth hybrid protocols.

It also provides a Username and Password mechanism for users that do not wish to use existing accounts in other networks.

The following services are supported in this release:

• Twitter (OAuth1)
• Facebook (OAuth2)
• Google (OpenID + OAuth Hybrid)
• Yahoo (OpenID + OAuth Hybrid)
• LinkedIn (OAuth1)
• Foursquare (OAuth2)
• MyOpenID (OpenID)
• WordPress (OpenID)
• Username and Password

In other words, it sounded like a dream come true and I resolved to try it once I found the time. That time found me last Monday evening and I sent a direct message to @jaliss (the module’s author) via Twitter.

Does Secure Social work with Play Scala? I’d like to use it in my Play More! project.

Jorge responded 16 minutes later saying that he hadn’t used Play Scala and he’d need to do some research. At 8 o’clock that night (1.5 hours after my original DM), Jorge had a sample working and emailed it to me. 10 minutes later I was adding a Secure trait to my project.

package controllers

import play.mvc._
import controllers.securesocial.SecureSocial

/*
 * @author Jorge Aliss <jaliss@gmail.com> of Secure Social fame.
 */
trait Secure {
  self: Controller =>

  @Before def checkAccess() {
    SecureSocial.DeadboltHelper.beforeRoleCheck()
  }

  def currentUser = {
    SecureSocial.getCurrentUser
  }
}

I configured Twitter and Username + Password as my providers by adding the following toconf/application.conf.

securesocial.providers=twitter,userpass

I also had to configure a number of securesocial.twitter.* properties. Next, I made sure my routes were aware of SecureSocial by adding the following to the top of conf/routes:

  *       /auth               module:securesocial

Then I specified it as a dependency in conf/dependencies.yml and ran “play deps”.

    - play -> securesocial 0.2.4

After adding “with Secure” to my Profile.scala controller, I tried to access its route and was prompted to login. Right off the bat, I was shown an error about a missing jQuery 1.5.2 file in my “javascripts” folder, so I added it and rejoiced when I was presented with a login screen. I had to add the app on Twitter to use its OAuth servers, but I was pumped when both username/password authentication worked (complete with signup!) as well as Twitter.

The only issue I ran into with SecureSocial was that it didn’t find the default implementation of SecureSocial’s UserService.Service when running in prod mode. I was able to workaround this by adding a SecureService.scala implementation to my project and coding it to talk to my Athlete model. I didn’t bother to hook in creating a new user when they logged in from Twitter, but that’s something I’ll want to do in the future. I was also pleased to find out customizing SecureSocial’s views was a breeze. I simply copied them from the module into my app’s views and voila!

package services

import play.db.anorm.NotAssigned
import play.libs.Codec
import collection.mutable.{SynchronizedMap, HashMap}
import models.Athlete
import securesocial.provider.{ProviderType, UserService, SocialUser, UserId}

class SecureService extends UserService.Service {
  val activations = new HashMap[String, SocialUser] with SynchronizedMap[String, SocialUser]

  def find(userId: UserId): SocialUser = {
    val user = Athlete.find("email={email}").on("email" -> userId.id).first()

    user match {
      case Some(user) => {
        val socialUser = new SocialUser
        socialUser.id = userId
        socialUser.displayName = user.firstName
        socialUser.email = user.email
        socialUser.isEmailVerified = true
        socialUser.password = user.password
        socialUser
      }
      case None => {
        if (!userId.provider.eq(ProviderType.userpass)) {
          var socialUser = new SocialUser
          socialUser.id = userId
          socialUser
        } else {
          null
        }
      }
    }
  }

  def save(user: SocialUser) {
    if (find(user.id) == null) {
      val firstName = user.displayName
      val lastName = user.displayName
      Athlete.create(Athlete(NotAssigned, user.email, user.password, firstName, lastName))
    }
  }

  def createActivation(user: SocialUser): String = {
    val uuid: String = Codec.UUID()
    activations.put(uuid, user)
    uuid
  }

  def activate(uuid: String): Boolean = {
    val user: SocialUser = activations.get(uuid).asInstanceOf[SocialUser]
    var result = false

    if (user != null) {
      user.isEmailVerified = true
      save(user)
      activations.remove(uuid)
      result = true
    }

    result
  }

  def deletePendingActivations() {
    activations.clear()
  }
}

Jorge was a great help in getting my authentication needs met and he even wrote a BasicAuth.scala trait to implement Basic Authentication on my JSON services.

package controllers

import _root_.securesocial.provider.{UserService, ProviderType, UserId}
import play._
import play.mvc._
import play.libs.Crypto

import controllers.securesocial.SecureSocial

/*
 * @author Jorge Aliss <jaliss@gmail.com> of Secure Social fame.
 */
trait BasicAuth {
  self: Controller =>

  @Before def checkAccess = {
    if (currentUser != null) {
      // this allows SecureSocial.getCurrentUser() to work.
      renderArgs.put("user", currentUser)
      Continue
    }

    val realm =
      Play.configuration.getProperty("securesocial.basicAuth.realm", "Unauthorized")

    if (request.user == null || request.password == null) {
      Unauthorized(realm)
    } else {
      val userId = new UserId
      userId.id = request.user
      userId.provider = ProviderType.userpass
      val user = UserService.find(userId)

      if (user == null ||
        !Crypto.passwordHash(request.password).equals(user.password)) {
        Unauthorized(realm)
      } else {
        // this allows SecureSocial.getCurrentUser() to work.
        renderArgs.put("user", user)
        Continue
      }
    }
  }

  def currentUser = {
    SecureSocial.getCurrentUser()
  }
}

Summary

My latest pass at developing with Scala and leveraging Play to build my app was a lot of fun. While there were issues with class reloading every-so-often and Scala versions with Scalate, I was able to add the features I wanted. I wasn’t able to upgrade to Play 2.0, but I didn’t try that hard and figured it’s best to wait until its upgrade guide has been published.

I’m excited to describe my latest experience to the developers at Jfokus this week. In addition, the conference has talks on Play 2.0, CoffeeScript, HTML5, Scala and Scalate. I hope to attend many of these and learn some new tricks to improve my skills and my app.

Update: The Delving developers have written an article on Migration to Play 2. While it doesn’t provide specific details on what they needed to change, it does have good information on how long it took and things to watch for.

Republished from Raible Designs. You can find the original article here.

First steps with Scala revisited: bash and python strikes back

I’ve received a good ammount of positive feedback on my previous article on scala.

A couple of readers prefered the bash one-liner version, and many of them argued that for such a simple task it was preferable a bash or python script. Luckily all of them understood that this was just a (maybe lousy, I admmit) excuse to give scala a try, and talk a little bit about functional programming, type inference, interacting with java, higher order functions, and, well, scala itself.

Nevertheless, to make justice to bash and scala, I took some advices from the discussion at hacer news, and even though I’m no bash nor python expert, with some googling around I managed to reproduce the funcionality of the scala script.

Bash eight-liner version

Well, here’s the bash version:

total_size=$(du --summarize *.textile --total | tail -n 1 | cut -f 1)
translated_files=$(grep -L "Esta página todavía no ha sido traducida al castellano" *.textile)
translated_size=$(echo $translated_files | tr '\n ' '\0' | xargs -0 du --summarize --total | tail -n 1 | cut -f 1)
translated_percent=$(($translated_size*100/$total_size))
echo "translated size: ${translated_size}kb/${total_size}kb ${translated_percent}% \
(pending $(($total_size-$translated_size))kb $((100-$translated_percent))%)"

total_count=$(ls *.textile | wc -l)
translated_count=$(echo $translated_files | tr ' ' '\n' | wc -l)
translated_percent=$(($translated_count*100/$total_count))
echo "translated files: ${translated_count}/${total_count} $(($translated_count*100/$total_count))% \
(pending $(($total_count-$translated_count)) $((100-$translated_percent))%)"

I just had to read a couple of man pages and struggle a little bit with tr, wc, xargs, tail, cut and that sort of stuff.

Python version

#! /usr/bin/env python
# -*- coding: utf-8 -*-

import fnmatch
import os

total_files = [file for file in os.listdir('.') if fnmatch.fnmatch(file, '*.textile')]
translated_files = [file for file in total_files if "Esta página todavía no ha sido traducida al castellano" not in open(file).read()]

total_size = sum([os.path.getsize(file) for file in total_files]) / 1000
translated_size = sum([os.path.getsize(file) for file in translated_files]) / 1000
translated_percent= translated_size * 100 / total_size

print "translated size: %dkb/%dkb %d%% (pending %dkb %d%%)" % \
      (translated_size, total_size, translated_percent, total_size-translated_size, 100-translated_percent)

total_count=len(total_files)
translated_count=len(translated_files)
translated_percent= translated_count * 100 / total_count

print "translated files: %d/%d %d%% (pending %d %d%%)" % \
      (translated_count, total_count, translated_percent, total_count-translated_count, 100-translated_percent)

What else can I say? The python version was really easy.

Scala, Bash and Python… FIGHT!

Well, now let’s see the output of each version:

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual$ ./status.scala 
translated size: 407kb/624kb 65% (pending 217kb 35%)
translated files: 37/64 57% (pending 27 43%)

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual$ ./status.sh 
translated size: 476kb/752KB 63% (pending 276kb 37%)
translated files: 37/64 57% (pending 27 43%)

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual$ ./status.py 
translated size: 407kb/624kb 65% (pending 217kb 35%)
translated files: 37/64 57% (pending 27 43%)

It seems like du rounds up the files size, but apart from that everything works as expected.

What about performance?

While the scala version do have a startup penalty, with the savecompiled option turned on, the delay is pretty bearable (without it the compiling process takes a little less than two seconds). Moreover, with long running or more complex tasks, I suspect that the benefits of having a compiled script, and the performance optimizations of the JVM, would certainly show up.

Here are some figures to compare.

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual$ time ./status.scala
translated size: 407kb/624kb 65% (pending 217kb 35%)
translated files: 37/64 57% (pending 27 43%)
real	0m0.475s
user	0m0.388s
sys	0m0.056s

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual$ time ./status.sh
translated size: 476kb/752KB 63% (pending 276kb 37%)
translated files: 37/64 57% (pending 27 43%)
real	0m0.045s
user	0m0.004s
sys	0m0.008s

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual$ time ./status.py
translated size: 407kb/624kb 65% (pending 217kb 35%)
translated files: 37/64 57% (pending 27 43%)
real	0m0.039s
user	0m0.020s
sys	0m0.012s

Conclusion

After playing a bit with all three of them, for this kind of tasks I’d definitely go with python. It’s really a joy to use, it’s got great documentation and there’s lot of interesting information at stack overflow. Moreover, like the scala version, and unlike bash, is portable across different platforms, I haven’t tried it but it should work just fine on windows.

Nevertheless I expect to keep playing with scala, for learning purposes and just to have some fun…

In the next article, I give scala another chance, and at the same time have a look at Implicit conversions, Scala’s answer to ruby’s open classes.