Travis: Integración Contínua con Github

En este post (tuvimos que desempolvar el dashboard de entradas de Bonus4Code debido al parón vacacional…) vamos a comentar una forma sencilla y gratuita para llevar a cabo prácticas de integración continua(CI del inglés Continuous Integration) sin necesidad de montar vuestro propio servidor (Jenkins o similares).

Travis CI

Travis es un servicio alojado de integración continua que se integra con Github. Esto permite loguearnos con nuestra cuenta de Github e importar aquellos proyectos para los que queramos ejecutar tareas de IC.

Tiene especial soporte para los siguientes lenguajes: C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, JS (Node.js), Objective-C, Perl, PHP, Python, Ruby y por último (pero no por ello menos importante…para nada,vamos :P) Scala.

Cada vez que realizamos un push a nuestro repositorio de Github, Travis detecta dicho cambio y ejecuta las tareas que tenga planificadas.

¿Cómo lo configuramos?

• Paso 1: Entramos en travis-ci.org y nos logueamos con nuestra cuenta de Github. En este caso se mostrarán los repositorios públicos de nuestra cuenta de Github. En caso de que quisiéramos realizar la misma tarea pero para nuestros repositorios privados, el proceso sería el mismo sólo que accediendo a través de travis-ci.com.
• Paso 2: Una vez nos hemos logueado y se sincronizan los repos desde Github, accedemos a la página de nuestro perfil para proyectos open-souce o privados (dependiendo del paso anterior). A partir de aquí, podremos habilitar el service hook para aquellos repositorios de los que tenemos acceso administrativo. Cambiamos de OFF a ON aquellos repositorios que queramos habilitar
• Paso 3: Añadimos fichero de configuración .travis.yml en la raíz de nuestro proyecto en Github. En este fichero de configuración indicaremos a Travis qué tareas queremos que se ejecuten en nuestro proceso de integración continua. Para un proyecto Scala tendría el siguiente aspecto:

  language: scala
  scala:
    - "2.10.3"
  jdk:
    - oraclejdk7
  script:
    - sbt $TASKS
  env:
    - TASKS='test'
  notifications:
    email:
      - myemail@somehost.com
  

  Cómo se puede ver, la lectura es bastante sencilla: Definimos el lenguaje del proyecto (Scala), la versión que utilizaremos del compilador (Scala 2.10.3), el JDK a descargar (oraclejdk7), los scripts que se ejecutarán (en este caso sólo uno, que es ejecutar SBT), las variables de entorno y el mail donde se notificará el resultado.

• Paso 4: Comprobar que se ejecuta por primera vez. Una vez añadido el fichero .travis.yml al repositorio, realizamos un push sobre el repositorio en Github. Esto debería añadir el primer build a la cola de Travis y empezará tan pronto como haya un nodo disponible para el lenguaje de programación de tu proyecto.
  Para empezar un proceso de construcción, se puede hacer un push con cambios en el proyecto, o ir a la página de Github ‘Webhooks y servicios‘ y usar el botón Test Hook para Travis (Este método solo funciona a partir del primer build).
  Una vez ejecutado el proceso, desde la página de administración de Travis deberíamos poder ver algo del siguiente estilo:
  
  
• Paso 5: Indicar el estado de CI en el Readme.md de tu proyecto. Para indicar el estado de integración continua basta con añadir al fichero Readme.md de tu proyecto lo siguiente:

  Title1
  ======================
  
  [![Build Status](https://travis-ci.org/your-user/your-project.svg?branch=master)](https://travis-ci.org/your-user/your-project)
  
  This is some introduction text ...
  
  

Conclusiones

Si todo el proceso de configuración ha ido correctamente, veremos el estado de CI en la página principal de nuestro proyecto de Github. Por ejemplo, en el siguiente proyecto se indica que el building es correcto (Build Passing) :

Hasta el próximo post amijos 🙂

 

Can has lolcode plz ?

Cuando surgió en Internet la moda de los Lolcat (WTF), no tardaron en surgir las primeras mentes brillantes en crear un lengaje de programación para hacer honor al fenómeno de la red de redes. LOLCODE es un lenguaje de programación esotérico creado en 2007 por Adam Lindsay, investigador del Departamento de Computación de la Universidad de Lancaster.

CAN SEE AN XAMPL ? AWSUM THX

La sintaxis del lenguaje se basa en abreviaturas de palabras utilizadas en las imagenes de los Lolcat.
Un hola mundo en LOLCODE sería algo de este estilo:

HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE

PLZ, WAT IS A DSL ?

Un DSL, es un Domain Specific Language, y en este artículo vamos a mostrar como crear uno usando los mecanismos que nos ofrece Scala para embeber DSLs utilizando su libertad de sintaxis.

VISIBLE DSL XAMPL

Por tanto, si queremos crear una instrucción que represente el hecho de importar una librería, en LOLCODE sería

CAN HAS STDIO?

Usando notación infija podemos generar la primera parte de la instrucción usando un objecto CAN con un método HAS:

object CAN {
	def HAS(x:X):Y = ???
}

Como podeis comprobar, el método HAS tiene aún por definir un parámetro y el tipo devuelto. Y dado que de alguna forma hay que poder especificar la librería que se desea importar, el parámetro misterioso X (que intringulis) pasa a ser la librería a importar.

trait Library { val name: String }
object CAN { def HAS(library: Library): Y = ??? }

Y la librería estándar que queremos importar podría ser perfectamente un ‘case object’:

case object STDIO extends Library { val name = "stdio" }

Ahora,¿qué hay acerca del tipo devuelto? Dado que aún hay que poder añadir el signo de interrogación al final, es fácil pensar que el tipo misterioso ‘Y’ debe ser algo que tenga un método ‘?’ y que devuelva una instrucción. Para ello empleamos una clase auxiliar o helper:

class Can(l: Library) {
	def ?: Statement = ???
}

DIZ DOESNT RUN

Como ya hemos dicho antes, consideramos que cada instrucción es el elemento atómico de un programa. Además de instrucciones, un programa puede tener una o varias librería importadas, así como variables de entorno, un flag para indicar si la sintaxis es correcta y otro para indicar si se ha elevado una excepción.

Podríamos definir un programa en Scala de la siguiente forma:

case class Program (
  val env: Map[String, Any],
  val statements: Seq[Statement[_]],
  val imports: Set[Library] = Set(), 
  val isSyntaxOk: Boolean = false,
  val exceptionThrown: Boolean = false){
}

Donde una instrucción o Statement no es más que un transformador de estado y ejecutar dicha instrucción equivale a devolver un programa modificado además de un cierto output:

trait Statement[Output]{
  def execute(implicit context: Program):(Program,Output)
}

No obstante se ve más fácil con un ejemplo: Si deseamos implementar una instrucción que importa una librería al programa lo haríamos de la siguiente forma:

  case class ImportStatement(library: Library) extends Statement[String]{
    def execute(implicit context: Program):(Program,String) = (
    	context.copy(imports=context.imports + library),
    	s"LIBRARY $library WOZ SUCCSFLLY IMPORTED!")
  }

IT STILL DOESNT RUN 😡

…Y para ejecutar el código que hemos creado necesitamos un intérprete del lenguaje. Uno facilito de fabricación casera podría ser un actor Akka, que recibiera un programa y se mandara a sí mismo el programa modificado sin la última instrucción ejecutada.
Algo del estilo:

class Interpreter extends Actor {
  def receive = {
    case program: Program => 
      if (!program.isSyntaxOk) 
      	sender ! WrongSyntax(program)
      else program.statements.toList match {
      	case (nextStatement::restOfStatements) => 
      		val (updatedProgram,output) = nextStatement.execute(
      			program.copy(statements=restOfStatements))
      		println(output)
      		self ! updatedProgram
      	case _ => 
      		println("Finished!")
      }
  }
}

I WNT MOR PLZ …

Puedes ver el resto de implementación (para un conjunto muy reducido de instrucciones) en el siguiente enlace de Github:

https://github.com/JSantosP/lolcode-dsl

Y hasta aquí mi aportación.

Hasta la próxima 🙂

Adaptación automática de páginas web en dispositivos móviles utilizando RWD

A estas alturas toda organización o empresa que se precie tiene presencia digital, como se suele decir, si no estás en Internet no existes. Para construir una imagen de marca es necesario tener al menos una web propia y con dominio propio (los hosting gratuitos están muy bien para experimentar pero a nivel profesional daría una imagen similar a ir al trabajo en pijama). En estos últimos años han aparecido nuevos dispositivos capaces de acceder a la web (smartphones,tablets,smart tvs,etc), cada uno de ellos con distinta resolución y tamaño de pantalla.

Como es de suponer, según el dispositivo empleado variará la visualización y experiencia de usuario (aunque a priori todos sean capaces de acceder al mismo contenido), por ello es necesario que nuestra web se adapte de la mejor forma posible utilizando el llamado Responsive Web Design (RWD). En este tutorial se va a mostrar como hacer una web responsive y de paso se incluirá una librería jQuery para simular un elemento propio de plataformas móviles.

 

Responsive Web Design

El RWD o Responsive Web Design es un enfoque de diseño cuyo objetivo es que cambie dinámicamente la forma de visualización de una página según las características del dispositivo que acceda, para conseguirlo se trabaja con la capa de presentación, es decir, sólo es necesario modificar las hojas de estilo CSS, por lo tanto el propio diseñador puede realizar el trabajo sin afectar al resto de capas.

Antes de su aparición, se creaba una versión móvil para mejorar la experiencia de usuario en caso de que el acceso fuera desde un dispositivo diferente a un ordenador, entonces, ¿para qué aplicar el RWD? Las ventajas de este enfoque son varias, principalmente que no se duplica contenido (y por tanto no penaliza el SEO) y que no es necesario modificar la lógica de negocio ni la información almacenada (ya que sólo se actúa sobre la capa de presentación), en consecuencia se ahorra bastante trabajo y se simplifica el diseño, mejorando sensiblemente la mantenibilidad. Como contrapartida es necesario enviar más datos en cada petición, pero si la página está bien diseñada el incremento es perfectamente asumible.

El libro de referencia para entender este diseño es «Responsive Web Design», donde Ethan Marcotte explica su historia, los principios que se deben seguir y cómo aplicarlos. Según este libro se deben cumplir varias condiciones para que una web sea responsive:

– Debe tener una estructura flexible, donde se deben evitar los tamaños fijos (ya sea en píxeles, pulgadas,etc) usando tamaños relativos (porcentajes,em’s) en su lugar. El resultado será que el tamaño de los elementos no será siempre el mismo, sino que se adaptará a la resolución de la pantalla donde se muestra.

– Los Elementos multimedia deben ser flexibles, de forma similar al caso anterior, se pretende que las imágenes, videos y el resto de elementos multimedia sea capaz de adaptar su tamaño en función de la resolución de la pantalla donde se renderiza. Hay que tener en cuenta que algunos navegadores antiguos (principalmente versiones de IE6 y anteriores) no son compatibles con atributos que se utilizan para lograr esta flexibilidad, por lo que se deben tener alternativas si se prevé que un porcentaje considerable de visitantes usen cualquiera de esos navegadores (IE6 viene incluido por defecto con Windows XP, el cual sigue presente en muchos equipos a pesar de que Microsoft ha dejado de darle soporte desde principios de este año)

– Se usan Media Queries (las cuales están disponibles desde la especificación de CSS3) cuya función es seleccionar qué estilos se aplican a la página. Cada Media Query tiene un conjunto de estilos que se aplicarán siempre que su Media Type (el tipo de medio puede ser una impresora, tv, etc) encaje con el dispositivo y si se cumplen las condiciones que se le han asignado (como que tenga un ancho máximo, tenga una determinada orientación, etc). En la práctica el Media Type no es muy útil para los dispositivos actuales, sino que se emplean las condiciones adicionales para adaptarse a los dispositivos, por ejemplo, si queremos que se adapte a un móvil de pantalla FullHD será necesario al menos una Media Query que tenga en cuenta el ratio, mientras que si queremos adaptarnos a un móvil de gama baja deberíamos usar al menos una Media Query que filtre por una resolución baja.

Aún falta un último detalle para que la página se muestre completamente adaptada a la pantalla, y es la inclusión de la metaetiqueta viewport a las páginas donde se pretendan aplicar los estilos. Su función es encargarse de configurar a qué escala se mostrará la página y asignarle la anchura donde deberán encajar todos los elementos de la página. Fue creada por Apple para su navegador Safari a fin de mejorar la visualización de las páginas web al utilizar el iPhone, pero con el tiempo otros navegadores lo han copiado tambien le han dado soporte.

 

Ejemplos sin RWD

Ahora que ya sabemos más acerca de RWD voy a analizar algunas páginas que no lo aplican, con lo que saldrán a relucir las inconvenientes que ello conlleva si el acceso no se hace desde un ordenador (por no extenderme demasiado he obviado el problema de mostrarlo en PCs empequeñeciendo la ventana del navegador).

La primera que voy a analizar es la página de la URJC (Universidad ¿ex? Rey Juan Carlos), donde estudiamos en su dia casi todos los miembros del blog.  Su tráfico aproximado es de 700k de usuarios al mes, hay que decir que no es posible conocer información relativa a los dispositivos desde los que se ha accedido, pero es muy probable que gran parte de ellos dispongan de un smartphone y les resulte mas cómodo que hacerlo desde el ordenador (sobre todo si no se encuentran en casa). Si intentan acceder con un móvil de gama media-alta (pongamos que con pantalla 720p) verían una imagen como la que se muestra mas adelante.

Los emuladores de móviles de Chrome y Firefox muestran la web con ese aspecto, pero según el dispositivo puede mostrarse la web completa, en cualquier caso en un espacio tan pequeño es un engorro ver la información aun usando un móvil de pantalla grande (siendo estudiante, en un país en crisis y con la subida del precio de las matrículas este año lo más normal es que la pantalla que usen sea más bien pequeña).

Veamos otro ejemplo, el CPIICM, cuya página está creada con Drupal (según se puede apreciar en el código) y a priori se espera que sea de calidad, pero como en el caso anterior también es farragoso su uso en el móvil. Teniendo en cuenta que los colegiados pagan una cuota anualmente, da la sensación de un mantenimiento pobre (no tenían por qué complicarse mucho ya que existen un montón temas responsive para Drupal)

 

 

Ejemplos de páginas con RWD

Ahora voy a enseñar algunas páginas que si se han molestado en aplicar RWD. Dado que el primer ejemplo que he puesto anterior era de una universidad, en este caso voy a destacar la página de la universidad donde no llegó a graduarse el bueno de Mark Zuckerberg. En este caso el diseño es mas funcional y agradable, a diferencia de los ejemplos anteriores se puede ver toda la información sin tener que pelearse con el zoom y se tiene mejor experiencia de usuario, como resultado el visitante considerará su móvil como una alternativa viable al ordenador, con la ventaja de poder acceder desde cualquier lugar (lo que incrementa las posibilidades de que el número de visitas aumente).

Pero en España también tenemos universidades que cumplen, como la UC3M o la UEM (siendo la primera pública y la segunda privada). Luego están casos como la UCM que lo han dejado a medias (no se comporta bien con algunas resoluciones)

 

 

 

 

 

 

 

 

 

Para los que seáis poco empáticos (o directamente unos psicópatas) voy a ejemplificar gráficamente la reacción de los visitantes de vuestra web que pretendan acceder con su móvil low-cost (aka crisis-friendly). Pongamos que el visitante es Florentino Pérez (puede ser que se le haya roto su iPhone y se haya comprado un móvil barato porque tiene que ahorrar para el nuevo Bernabéu).

Sin RWD

con RWD

 

 

 

 

 

 

Si os interesa el tema, en el próximo post se enseñará una web básica que siga el RWD, siguiendo los puntos explicados para que se entienda mejor, además se usará un plugin jQuery que hará que el resultado final tenga un aspecto similar a una aplicación móvil nativa, pero eso ya otro día.

 

Strategy

Hoy voy a hablaros del patrón Strategy, un patrón de comportamiento que permite definir un algoritmo pero delegar la implementación de algunas partes de dicho algoritmo a otras clases. De esta forma se consigue mucha portabilidad, ya que permite adaptar el algoritmo al entorno en el que se ejecuta en tiempo de ejecución. Por ejemplo, si el algoritmo muestra información por pantalla, es interesante que esa parte del algoritmo pueda disponer de diferentes implementaciones, para poder imprimir tanto por consola como en un dispositivo Android.

Diagrama UML

El diagrama UML del patrón Strategy es el siguiente:

Como ejemplo podríamos definir en la clase Strategy una interfaz para algoritmos de ordenación, y en las clases concretas se implementaría con distintos métodos como QuickSort o MergeSort. El contexto sería la interfaz del programa principal que contendría una lista a ordenar y la referencia a la clase Strategy.

Ejemplo en Java

Supongamos que estamos diseñando una tienda online y queremos que acepte distintos medios de pago (tarjeta de crédito, Paypal, Bitcoin, etc). Un ejemplo de arquitectura con Strategy sería el siguiente:

En la interfaz se define el método y las subclases que implementan la interfaz definen los distintos métodos de pago. esto permite que en tiempo de ejecución se pueda elegir la clase que se ejecuta. El contexto es la clase ShoppingCart que contiene la referencia al Strategy.

El código completo en Java se encuentra en el siguiente enlace: http://www.journaldev.com/1754/strategy-design-pattern-in-java-example-tutorial

Crear un servidor web con Node.js (II)

En el anterior capítulo nos quedamos con el servidor Node montado y corriendo. Lo próximo es construir una aplicación más compleja que responda a varias URLs, para ver en movimiento algo de lo que sería REST. Evidentemente, debemos examinar la petición HTTP, extrayendo de ella la URL pedida y, ocasionalmente, sus parámetros GET/POST.

La idea es que para procesar las peticiones necesitamos una especie de router que, dependiendo de la URL, mapee a los distintos manejadores, y en un rato veremos el cómo. En este punto hace falta aclarar un pequeño detalle:

Si comparamos Node con, por ejemplo, un Apache+PHP, hay una diferencia principal: el código PHP contiene la lógica, accesos a base de datos, etc.; es decir, implementa la aplicación, pero es Apache quien se encarga de servirla y gestionar las peticiones. Node realiza las funciones de ambos, no sólo implementamos la aplicación sino también todo el servidor, de forma que la aplicación web y su servidor web son esencialmente lo mismo.

Callbacks y funciones anónimas

Bien, ya vimos la función principal en nuestro hello.js, que crea el servidor y escucha peticiones en el puerto indicado. Al crear el servidor le estamos pasando una función como parámetro, lo cual se puede hacer en JavaScript incluso sin crear anteriormente la función. Es decir, se puede asignar una función a una variable y después pasar esta como parámetro, o bien definir la función en el mismo parámetro y por tanto no hay que darle un nombre (función anónima).

Este tipo de comportamiento se debe a la naturaleza de Node.js y a que trabaja orientado al evento. De esta forma, pasando una función al método que crea el servidor, cada vez que se reciba una petición, esta función será llamada (callback). Así que manipulamos ahí mismo la petición entrante, justo donde se captura el evento.

La estructura de la URL

Por otra parte, a la función que responde al evento (manejador) se le pasan dos objetos, request y response, con cuyas propiedades podemos obtener los detalles de la petición y procesarla adecuadamente.

Repasemos por un momento la estructura de las URLs y las partes que nos pueden interesar. En esencia, una URL puede tener unas cuantas de estas cosas (algunas de ellas están siempre, aunque no las veamos en el navegador, como las meigas):

Brevemente:

• Protocolo: normalmente HTTP, pero también HTTPS, FTP, etc.
• Host/Hostname: dominio, es decir, nombre o dirección IP de la máquina.
• Puerto: puerto de red en el que escucha (por defecto 80 en HTTP).
• Path: ruta en la que se localiza el recurso.
• Query: parámetros de la petición: pares de variable=valor.

Obviamente, las partes importantes aquí son el path y la query: queremos saber a qué recurso se ha accedido, y si vienen datos con ello. Los obtenemos de la siguiente manera (usando los módulos internos url y querystring):

var url = require(‘url’);
var querystring = require(‘querystring’);

// Obtener el path o la query como cadena
var path = url.parse(request.url).pathname;  // “/hola”
var query = url.parse(request.url).query;  // “nombre=Pepito&apellido=Pérez”
// Obtener el objeto JSON a partir de la cadena query
var params = querystring.parse(query);  // { nombre: Pepito, apellido: Pérez }

A través del objeto request también podemos obtener otras cosas interesantes, como protocolo y versión, método, cabeceras…

Módulos: require y exports

Para dotar a nuestra aplicación de cierta organización, podemos separar todo el código en módulos. Esencialmente, un módulo es un fichero que agrupa ciertas funcionalidades, y que se puede usar posteriormente desde otro fichero.

Vemos en los ejemplos algunas líneas con require. Dado que ‘http’, ‘url’ o ‘querystring’ son módulos (internos de Node.js en este caso), require carga las funcionalidades que dichos módulos proporcionan (exportan).

Ahora nos queda crear nuestros propios módulos, y despues utilizarlos. Dentro de un módulo, podemos elegir qué partes queremos exportar, ya que todo lo que haya dentro es por defecto privado (variables, funciones, clases…). Y de hecho, la palabra que se usa para ello es exports.

Lo explican genial aquí, por lo que me limito a decir que lo haríamos de una de las dos formas:

a)     Exportando los componentes por separado:

var num = 35;
var sumar = function(a, b) {
    return a+b;
}
module.exports.num = num;
module.exports.sumar = sumar;
--------------------------------
var utils = require(‘./modulo);
var x = utils.num + 2;
var res = utils.sumar (4,9);

b)     Exportando todo en una función:

var miClase = function(param1, param2) {
   this.param1 = param1;
   this.param2 = param2;
}
module.exports = miClase;
--------------------------------
var clase = require(‘./miClase’);
var obj = new clase();
// O también:
var obj = new require(‘./miClase’)();

Mezclar y agitar

Muy bien, ya tenemos todos los ingredientes: callbacks y funciones anónimas, partes interesantes de la URL y nuestros propios módulos.

Ya podemos hacernos nuestro router casero, y poder decirle hola y adiós al usuario (un ejemplo muy básico para entender cómo se mapean las peticiones).

Para que no haya confusión, voy a renombrar mi hello.js a app.js (nombre más coherente), y voy a crear también router.js, que será usado en la aplicación principal.

function route(pathname, query) {
    switch (pathname) {
        case "/hola":
            return "Hello " + query["nombre"] + " " + query["apellido"]
        case "/adios":
            return "Bye bye " + query["nombre"] + " " + query["apellido"]
        default:
            return "Este recurso no existe!"
    }
}
exports.route = route;

var http = require('http');
var url = require('url');
var querystring = require('querystring');
var router = require('./router');

http.createServer(function (request, response) {
    res.writeHead(200, {"Content-Type'": "text/html"});

    var pathname = url.parse(req.url).pathname;
    var query = url.parse(req.url).query;
    var params = querystring.parse(query);

    var response = router.route(pathname, params);
    res.write(response);
    res.end();
}).listen(5555);

Claro que se podría hacer algo más elaborado, como tener en cuenta el método (GET/POST) y hacer cosas diferentes con uno y otro, pasarle al router también el objeto response y devolver una página 404 para los recursos que no existan, o bien cambiar el switch y organizar los recursos pedidos de otra manera…

Para todo esto existe una librería que veremos el próximo día: Expressjs 🙂

Saludos!

Scala: selftypes

Tal y como comentamos en entradas anteriores, hoy toca hablar de selftypes (¿cómo?¿lo qué?¿mande?).

Se ilustra muy bien su utilidad con el siguiente ejemplo.
Suponed que estamos definiendo nuestro objeto singleton que representa un mostrador de facturación de un aeropuerto:

object Facturacion{
  type Identificador = String
  var idMaletas: List[Identificador] = List()
}

hasta aquí sin problemas, ¿no? Ahora pongamos que queremos añadir un método para procesar un registro de facturación: Un señor que quiere volar quiere facturar sus maletas.

object Facturacion{
  type Identificador = String
  var idMaletas: List[Identificador] = List()

  def facturar(nombre: String, idMaletas: List[Idenntificador) = {
    println(s"Registrando maletas del señor $nombre")
    idMaletas ++= idMaletas //WTF
  }
}

Exacto. Ocurre que tenemos el mismo nombre para designar tanto a la variable como al parámetro de la función.
La primera lógica es cambiarle el nombre a uno de los dos.

…pero ocurre que no queremos XD Porque nos guste el nombre tal y como está, porque no tenga sentido que sea otro, porque si digo 3 veces ‘selftype’ frente al espejo aparece Odersky y me saca los ojos…Elegid vuestro motivo favorito

¿La otra opción? Hacer referencia a la enclosing class (enclosing object en este caso) de la siguiente forma:

object Facturacion{
  esteMostrador =>
  //...
}

de manera que ahora podemos efectuar la asignación que antes no podíamos:

object Facturacion{
  esteMostrador =>

  type Identificador = String
  var idMaletas: List[Identificador] = List()

  def facturar(nombre: String, idMaletas: List[Idenntificador) = {
    println(s"Registrando maletas del señor $nombre")
    esteMostrador.idMaletas ++= idMaletas //YOLO!
  }
}

Los motivos que normalmente aconsejan el uso de una anotación selftype suelen ser:

• Reforzar una cierta clase/trait base para asegurarse de que tu inner clase solo puede ser heredada o usada en mixin dentro de ese tipo.
• Referenciar una clase exterior cuando se implementa una inner class.

Este último es el caso que nos atañe y, tenéis que reconocer, que como poco os acabo de arrancar una sonrisa con esta ventaja de Scala.

Hasta la próxima 🙂

Scala: tipos estructurales

Esta semana os traemos la magia de los tipos estructurales en Scala.
Directa a vuestras casas, motherfu subscribers.

Suponed que estáis usando en vuestro proyecto Scala, una librería de un tercero que tiene la siguiente clase:

class Printer {
  type DocumentId = Int
  val documentMaxNumber: Int = 3
  val address: String = "192.168.1.10"
  def queue(document: java.io.File): DocumentId = {
    //queue document and return its identifier
    //...
    Int.MaxValue
  }
  def dequeue(document: DocumentId): Unit = {
    //do some operations...
    //...and let's supose I've dequeued it...
  }
}

Una bonita clase que representa una impresora … o algo.
Pongamos, además, que tenéis en vuestro proyecto esta clase, que sí habéis definido vosotros y que simula el comportamiento de una impresora, sin llegar a implementar su lógica.

class MyPrinterMock {
  val address: String = "127.0.0.1"
  def queue(document: java.io.File): Printer#DocumentId = 1
  def dequeue(document: Printer#DocumentId)
}

Si ahora queremos definirnos en nuestra aplicación un método que reciba como argumento o una clase u otra para encolar un documento a la impresora, estaría muy bien definir un trait común al que extendieran ambas, pero eso no es posible (recordad que la clase Printer no es nuestra). De modo que tenemos varias opciones.

Opción A: El dinero

Podemos usar un Either:

object MyApp extends App{
  def queueAtPrinter(printer: Either[Printer,MyPrinterMock],documentPath: String) {
    printer match{
      case Left(realPrinter) =>
        println(realPrinter.address)
        realPrinter.queue(new java.io.File(documentPath))
      case Right(fakePrinter) =>
        println(fakePrinter.address)
        fakePrinter.queue(new java.io.File(documentPath))
    }
  }
}

Engorroso, ¿verdad? Repetimos código.

Opción B: La caja misteriosa

La otra opción es utilizar un tipo estructural.

type PrinterLike = {
  val address: String
  def queue(document: java.io.File): Printer#DocumentId
}

Este tipo simboliza «algo» que tiene un valor de tipo String denominado address y un método queue que recibe un File y devuelve un DocumentId.
De esta forma podemos definir el método ‘queueAtPrinter’ de la forma que sigue:

def queueAtPrinter(printer: PrinterLike,documentPath: String) {
  println(printer.address)
  printer.queue(new java.io.File(documentPath))
}

o incluso parametrizarlo sin utilizar el tipo PrinterLike:

def queueAtPrinter[P <: {val address: String
  def queue(document:java.io.File):Printer#DocumentId }](printer: P,documentPath: String) {

  //...
}

¿Qué escoger? Bajo mi punto de vista, lo más elegante es un tipo estructural.

Piénsalo, Lois: Un barco es un barco, pero la caja puede ser cualquier cosa, ¡incluso un barco!

Lo único que, como todas las cosas buenas, es importante no abusar. Los tipos estructurales hacen uso de las reflectiveCalls, es decir, reflexividad, y en función de cuanto lo uséis y la forma en que lo hagáis, esto puede impactar en el rendimiento de vuestra aplicación.

Tipos estructurales e Inyección de dependencias

Si recordáis en la anterior entrada sobre Cake Pattern, podíamos indicar que un trait o clase abstracta era dependiente de otros componentes.
Ahora que hemos visto tipos estructurales, imaginad cómo quedaría expresar que tu trait depende de algo que tiene un valor entero y otros componentes:

trait MiTraitDependiente {
  dependeDe: { val unEntero: Int} with OtroComponente =>
}
trait OtroComponente

No os perdáis la próxima entrega para Scala: selftypes 🙂

Scala: Cake Pattern

Aunque este blog no sea ni remotamente parecido a las mañanas de Arguiñano, hoy vamos a aprender a cocinar tartas…con Scala para solventar una cuestión de inyección de dependencias (¿cómo?¿lo qué?)

Inyección de dependencias

Supongamos que trabajamos coordinando un equipo de diseño de coches Bercedes Menz. Hay varias áreas de trabajo.
Un grupo se encarga de diseñar el chasis, otro de diseñar las ruedas y otro de diseñar el motor.
¿Cómo especificarías la composición del coche?

Empecemos creando las clases para Coche, Rueda, Chasis y Motor. Y les añadimos un poco de funcionalidad (para que tengan algo de chicha).

class Coche {
  val ruedas : List[_] = ???
  val chasis = ???
  val motor = ???
}
trait Rueda {
  val coeficienteAdherencia: Float
}
trait Chasis {
  val numero_puertas: Int
}
trait Motor {
  val potencia: Int
}

Ahora es cuando, de alguna forma, debemos indicar que Coche depende de todos y cada uno del resto de componentes, pero imaginad que tenemos que usar métodos estáticos para poder implementar las distintas piezas.
¿Qué opciones tenemos? Por una parte podemos parametrizar el coche y agregar esos componentes como miembros de la clase:

class Coche[R<:Rueda,C<:Chasis,M<:Motor]{
  val ruedas: Lista[R] = List()
  val chasis: C = C.newInstance()
  val motor: M = C.newInstance()
}

Mmmm no compila,tío ¿Por qué?

Porque hasta mi abuela se daría cuenta de que esos métodos ‘newInstance’ se encuentan definidos en el companion de las clases C y M. Bueno, se podría decir, pues en vez de parametrizarlo como

R<:Rueda

lo cambiamos por

R<:Rueda.type

Vale, y ahora es cuando te das cuentas de que llevas muchas horas programando a base de café y de que entonces parametrizar esa clase es absurdo, ya que estás haciendo explícitos los parámetros.

¡A cocinar, Carmen de Toledo!

La opción que se propone es la de usar el Cake Pattern, considerada como la respuesta de Scala para el patrón de inyección de dependencias (DI). Este patrón de diseño orientado a objetos, anima a que se le suministren los objetos instanciados en vez de crearlos la propia clase. Si lo aplicamos a nuestro ejemplo, podríamos indicar en la expresión del selftype, que nuestra factoría de coches tiene dependencia de 3 componentes:

trait FactoriaCoches {
  estaFactoriaDependeDe: ComponenteRuedas, ComponenteChasis, ComponenteMotor =>

  case class Coche(val ruedas: List[Rueda], motor: Motor, chasis: Chasis)

  def fabricarCoche = Coche(
    List(new Rueda, new Rueda, new Rueda, new Rueda), //...colina abajo
    Motor("NumeroDeBastidorNoInventadoParaNadaAunqueIgualDeLargo",90),
    Chasis(3))
}

Nótese que se pueden definir miembros y métodos basándose en el hecho de que, en el momento de composición de la factoría, se utilizarán dichos componentes.
Y ahora los componentes se definirían como:

trait ComponenteRueda{
  class Rueda{
    val coeficienteAdherencia: Float = 0.85
  }
  def tiempoFrenada(velocidad: Float, rueda: Rueda): Float = {
    //Aquí van unos cálculos complicados del copón.
    rueda.coeficienteAdherencia * 0.1
    //El resultado es, por ejemplo:
    1
  }
}
trait ComponenteChasis{
  case class Chasis(val numeroPuertas: Int)
}
trait ComponenteMotor{
  case class Motor(val numeroBastidor: String, val potencia: Int)
  def calculaPotencia(numeroBastidor: String): Int= {
    //Un par de llamadas a tráfico y te dicen que la potencia es
    115
  }
}

Es de apreciar el uso de inner classes en los componentes.
Una vez definidos los componentes, ya podemos componer nuestro objeto factoría:

object MiFactoriaDeCoches extends FactoriaCoches 
  with ComponenteRueda 
  with ComponenteChasis
  with ComponenteMotor

val miCocheDeLosDomingos = MiFactoriaDeCoches.fabricarCoche

Si se quisiera añadir otro tipo de rueda o de motor, bastaría con extender al componente en cuestión y luego usarlo en la instanciación del objecto:

trait OtroTipoDeComponenteRueda extends ComponenteRueda{
  //...
}
object OtraFactoriaDeCoches extends FactoriaCoches
  with OtroTipoDeComponenteRueda
  with ComponenteChasis
  with ComponenteMotor

En la próxima entrada veremos tipos estructurales y cómo podemos expresar inyección de dependencias basándonos en dichos tipos.
Y hasta aquí nuestra tarta de hoy.
Rica, rica, … y con fundamento 😉

Mi experiencia con la OCAJP

Hola  a todos, en mi primer post quería hablaros acerca mi experiencia personal sobre la certificación OCAJP de Oracle que acabo de obtener. Esta certificación es la llave de acceso a cualquier otra certificación de programación Java que oferta Oracle, por lo que podríamos catalogarla como un «must have» para desarrolladores 🙂

Qué es la OCAJP, alias 1Z0-803

Cuando Oracle compró Sun cambió el sistema de certificaciones. Antiguamente la certificación de Java mas conocida era la SCJP (Sun Certified Java Programmer) pero ahora ese examen se ha «partido en dos» . El equivalente al SCJP se llama OCPJP (Oracle Certified Professional Java Programmer), pero es necesario tener el OCAJP (Oracle Certified Associate Java Programmer) para poder examinarse del OCPJP, ya os dije que era un must have xd

Este es el itinerario actual de certificaciones:

y este es el temario de la OCAJP:

1. Java Basics
2. Working With Java Data Types
3. Use Java operators
4. Creating and Using Arrays
5. Using Loop Constructs
6. Working with Methods and Encapsulation
7. Working with Inheritance
8. Handling Exceptions

Podéis encontrar el temario mas detallado en este enlace: http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=5001&get_params=p_exam_id:1Z0-803&p_org_id=&lang=

Como podéis observar, faltan temas como los genéricos o la concurrencia, que se han dejado para la «segunda parte», el OCPJP. Eso ayuda a que este examen sea mas fácil de aprobar, aunque también tienes que pagar dos exámenes en lugar de uno, Oracle es como la banca del casino, nunca pierde 😛

El código de examen es 1Z0-803, es importante conocerlo para no confundir este examen con otros similares, cada convocatoria cuesta 245$ así que al loro con lo que pedimos xd

El examen consta de 90 preguntas tipo test, y un tiempo de realización de 150 minutos. Algunas preguntas tienen más de una respuesta correcta, pero el enunciado indica el número de opciones a marcar, una ayudita que viene muy bien 🙂 Para aprobar es necesario conseguir un 63% de respuestas correctas, o sea, acertar 58 preguntas de las 90.

Preparación del examen

Para prepararlo existen varios libros en el mercado, en particular yo usé éste:

pero también hay otras alternativas:

Por supuesto, también existen academias que te preparan para este examen, pero suelen ser bastante caras. Lo fundamental es el software de test, que contiene preguntas similares a las del examen, y será nuestra herramienta de prácticas, porque de la teoría del libro a las preguntas reales del test hay una diferencia abismal. Sin ninguna duda recomiendo éste:

http://enthuware.com/index.php/mock-exams/oracle-certified-associate/java-programmer-certification-i

Por un precio de risa (9.95$) este software contiene mas de 1500 preguntas de distinta dificultad, organizadas por temas o en exámenes completos. cada respuesta viene explicada y si te quedan dudas se puede preguntar en el foro esa pregunta en concreto, observarás que hay muchas comentadas con enlaces que ayudan a explicar la respuesta. Sin ninguna duda es el mejor aliado para superar este examen, yo me presenté cuando me sabía casi de memoria casi todas las preguntas 😛

Notaréis que las preguntas son de dificultad alta en general y extrema en algunos casos, muy alejada de la teoría y de los casos cotidianos de programación. La verdad es que este examen te convierte en algo parecido a un compilador Java humano 🙂

El día del examen

Antes que nada, es necesario registrarse en la web de PersonVue y solicitar el lugar, fecha y hora del examen, y pagarlo por adelantado. Si todo ha salido bien Oracle te confirmará la cita y te mandará un recibo de pago muy bonito y un correo con instrucciones para que te registres en la web de CertView:

https://education.oracle.com/pls/eval-eddap-dcd/ocp_interface.ocp_candidate_login?p_include=Y&p_org_id=1001&p_lang=US

En esta web se publicará tu calificación, así que completad el registro bien y comprobadlo para evitar sorpresas desagradables 😛

El dia D a la hora H te presentas en el lugar en cuestión, firmas unos papeles, te sacan una foto… y te cachean como en la aduana del aeropuerto 🙂 ni un triste lápiz te dejan entrar, te lo proporcionan ellos ( que majos ). Una vez dentro te toca darlo todo, si lo has preparado bien te sobrará tiempo para repasar.

Unas horas después te llegará un correo avisándote de que las calificaciones ya están disponibles, así que solo te queda entrar en la web de certView y saborear tu triunfo.

Integración con WS en Scala con Akka-Camel

Hoy vamos a hablar de la integración con servicios web usando Akka. Si bien implementar dichos servicios puede o no ser un tostón (no soy muy fan de SOAP, la verdad…), la integración, dependiendo de según como estén hechos, puede resultar un tanto complicada (abrir y mantener conexiones, definir protocolos, …). Por eso vamos a plantear el uso de una herramienta con bastante comunidad de trasfondo como es Apache Camel.

Esta herramienta da soporte a la mayoría de EIPs (Enterprise Integration Patterns) que definen en su libro Gregor Hohpe y Bobby Woolf; pudiendo definir rutas estableciendo reglas que manipulan el flujo de datos en el proceso de comunicación. Por poner un ejemplo sencillo, supongamos que queremos consumir mensajes de una cola y escribirlos a fichero. Con Camel podríamos hacerlo usando su DSL de la siguiente forma:

context.addRoutes(new RouteBuilder() {
  public void configure() {
    from("test-jms:queue:test.queue")
      .to("file://test");
  }
});

Como podréis imaginar, estas rutas pueden complicarse todo lo que se quiera. En este caso, con lo que más nos interesa quedarnos de Camel, es con los conceptos de Consumidor y Productor, considerando consumidor aquel extremo del canal que se dedica a obtener mensajes de una cierta fuente, y productor al que se dedica a escribir mensajes (¬¬ … genius!).

Sin entrar muy en detalle de todos los elementos que integran Camel (rutas, endpoints, processors, …), hemos de decir que nos apoyaremos en un componente muy concreto de Camel: camel-cxf, que emplea el framework Apache CXF (nos aporta facilidades a la hora de construir o desarrollar servicios web de tipo SOAP, XML-HTTP, RESTful-HTTP, CORBA… con soporte para distintas capas de transporte como HTTP, JMS o JBI).

Pongamos como ejemplo que queremos crear un cliente para conectarse a un servicio web. Hemos escogido para ello un web-service de carácter público, que no requiere de autenticación, como es WeatherWS, que ofrece información meteorológica del área de Estados Unidos (aquí al lado). Los pasos de la receta son los siguientes:

Generando clases JAXB

Para que la transmisión de datos, que debe ser en XML, no sea la muerte a pellizcos, vamos a utilizar CXF para generar las clases JAXB (Java Architecture for XML Binding). Esta capa de abstracción nos evita trabajar con el XML crudo, pudiendo enviar instancias de estas clases y dejando que el proceso de serialización/deserialización sea transparente al desarrollador.

Para generar estas clases, usamos la herramienta wsdl2java que viene con apache-cxf, el cual podéis descargar de la web.

1. Descargarmos el fichero WSDL (http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL) que contiene la descripción del servicio y lo renombramos a Weather.wsdl
2. Ejecutamos la herramienta wsdl2java y decidimos el directorio donde se van a generar (en nuestro caso indicamos el directorio de nuestro proyecto donde van las clases java) :

    wsdl2java -client -p com.cdyne.ws -d src/main/java Weather.wsdl 

Creando el Productor

Dado que Akka dispone de la extensión Camel, podemos ahora crear un actor para enviar peticiones síncronas utilizando la template de productor.

En primer lugar creamos el tipo de mensaje que representa una petición y que va a recibir nuestro actor, ante el cual va a reaccionar.

case class WeatherMessage
  body: java.util.List[String],
  headers: java.util.Map[String, Object])

Y para hacer el código un poco más legible en el cuerpo del actor, creamos un objecto helpers y codificamos en su interior el extractor Response que hará que la respuesta obtenida al hacer la petición sea más fácil de diseccionar para extraer los campos que queremos:

object Response {
  def unapply(obj: Object): Option[List[Any]] =
    try {
      Some(obj.asInstanceOf[MessageContentsList].toArray.toList)
    } catch {
      case _: Throwable => None
    }
}

Posible pregunta suscitada:

Yooo, eehhhh, es que no entiendo el extractor este que te montas. Te has querido molar y…

Tranquilos, ahora se verá mejor en la definición del actor.

En primer lugar creamos la clase:

class MyProducerActor extends Actor

y generamos una instancia de CamelExtension (Atención: ¡Sólo una por instancia de sistema Akka!)

val camel = CamelExtension(context.system)

Luego definimos la URI del endpoint,

val uri = "cxf:http://wsf.cdyne.com/WeatherWS/Weather.asmx?" +
  "serviceClass=com.cdyne.ws.WeatherSoap"

y por último definimos el comportamiento del actor (atentos al extractor de antes :P):

def receive = {

  case WeatherMessage(body, headers) =>
    camel.template.requestBodyAndHeaders(uri, body, headers) match {

      case Response(List(awd: ArrayOfWeatherDescription)) =>
        awd.getWeatherDescription().toList map format foreach println

      case Response(List(wr: WeatherReturn)) =>
        println(format(wr))

      case Response(List(fr: ForecastReturn)) =>
        println(format(fr))

      case response => println(response)

    }

}

Luego si queremos probar nuestro cliente, bastará con crearnos un productor y enviarle un WeatherMessage con los parámetros adecuados:

val myProducer = system.actorOf(Props[MyProducerActor])
val operation = "GetWeatherInformation"
val params: java.util.List[String] = List()
val request = WeatherMessage(params, Map(
  "operationName" -> operation,
  "soapAction" -> s"http://ws.cdyne.com/WeatherWS/$operation"))

myProducer ! request

Conclusión

De esta manera, es sencillo integrar nuestro sistema de actores Akka con servicios web. Si juntamos la potencia de Scala, con la escalabilidad de Akka y nos apoyamos en herramientas de gran versatilidad como son Camel o CXF podemos generar clientes WS de una alta calidad y sin traumarnos (Dejad que los SOAP se acerquen a mí…).

Tenéis disponible el código que se ha utilizado como ejemplo en Github.

Y como diría Salvador Raya:

«Cenquiu veri mach. Suscribi plis»