Estuve en el Lambda World

Escribo estas líneas volviendo en tren desde Cádiz, una ciudad enigmática que me recuerda muchísimo a mi añorada Habana, tal vez porque la segunda se construyera basándose en la primera.

Cádiz, además de ser la ciudad que acogió la firma de la primera Constitución Española en 1812, ha acogido el pasado fin de semana el primer evento internacional de programación funcional celebrado en España, el Lambda World.

En este evento, ponentes de todas partes del mundo han venido a contarnos acerca de características de la programación funcional como mónadas, funciones puras, inmutabilidad, efectos secundarios, o sobre cómo llevar conceptos de programación funcional a programación orientada a objetos.

Para ello, hemos visto ejemplos en lenguajes como F#, C#, Java, Ruby, Swift, y, sobre todo, Scala. He aprendido muchísimo y aquí resumo algunos conceptos que me han llamado la atención y que me toca seguir estudiando.

La inmutabilidad, más complicada pero menos propensa a errores.

En programación orientada a objetos definimos clases con propiedades y comportamiento. Este comportamiento suele implicar un cambio en el estado del objeto.

Sin embargo, es justamente lo que queremos evitar en programación funcional, ya que trabajamos con objetos inmutables, con lo cual una vez creados, no cambia ninguna de sus propiedades.

Esto también se aplica a colecciones, y a los miembros de la misma, con lo cual la acción de añadir un objeto a una colección, o modificar un objeto de la misma requiere crear una nueva colección.

Con estos objetos inmutables lo que conseguimos asegurarnos que su estado no va a cambiar, y que no vamos a tener “sorpresas” cuando pasemos un objeto a un método que de repente modifique alguna de sus propiedades.

Sin embargo, aunque lenguajes como Swift, Scala o F# soportan inmutables por diseño, en el mundo clásico de la orientación a objetos, tanto para Java, C# o Ruby, es justamente al contrario, y queda de nuestra mano utilizar colecciones inmutables y definir manualmente nuestros objetos.

Las funciones puras no generan efectos secundarios, o casi

Otro concepto que se repitió bastante en el evento era el de función pura, que no es más que un método que recibe una entrada y devuelve una salida.

La magia de este concepto es que cuando lo combinamos con los objetos inmutables, conseguimos que para una entrada X tenemos la absoluta seguridad de que la salida será Y, SIEMPRE.

Esto nos permite, entre otras cosas, poder probar de manera rápida nuestras funciones si el lenguaje que estamos utilizando incorpora una consola REPL (Read Evaluate Print Loop), ya que una vez definida la función solamente tenemos que ejecutarla con los valores adecuados.

Los lenguajes funcionales no son algo solamente “académico”

Aunque los conceptos que nos muestren se acerquen bastante más a las matemáticas que a ensamblador, los ejemplos mostrados en aplicaciones móviles, sistemas cliente-servidor, arquitecturas funcionales y videojuegos, me dejaron bastante claro que la programación funcional está aquí para quedarse, y que ya estamos tardando, al menos, en aprender algunos de sus conceptos.

No tengo ni idea de lo que son las monads, creo.

Uno de los conceptos de programación funcional que se me escapa es el de las monads, que al parecer son tipos de datos con propiedades específicas, y uno de los ejemplos que veíamos en el evento era el del monad Either, que tiene dos tipos, Left o Right.

Con este monad podíamos definir el resultado de nuestra función, siendo Left un resultado de éxito, y Right una definición de un error, evitando flujos como captura de excepciones.

Este concepto tiene a su vez conceptos relacionados como monoids o functors… de los cuales tendré que leer, y mucho.

Podemos usar conceptos de programación funcional con lenguajes no puramente funcionales.

Conceptos como funciones puras u objetos inmutables son relativamente fáciles de implementar aunque los lenguajes no lo refuercen nativamente, sin embargo requiere un grado de disciplina mayor.

Sin embargo lenguajes como C# o Java van aportando cada vez más características de la programación funcional a su sintaxis, como las Lambdas y las colecciones inmutables. Aunque no es el escenario ideal para utilizar programación funcional, nos permite usar lo que ya sabemos.

Tenemos muchas maneras de empezar, aunque hay dos muy interesantes:

Por una parte tenemos lenguajes como Scala, en el que podemos desarrollar de la misma manera en la que lo veníamos haciendo hasta ahora, ya que soporta tanto tipos mutables como inmutables, e ir agregando características de la programación funcional a nuestros programas.

Por otra parte tenemos lenguajes F#, que nos permite lanzarnos al vacío, con una sintaxis que nos podría recordar cuando encadenamos la salida de distintos procesos en una shell de unix, que nos permite aprender programación funcional más “pura” y su interoperabilidad con C# nos permite agregar componentes funcionales a nuestro proyecto.

En resumen

Tenemos características como la inmutabilidad y las funciones puras que nos evitan sorpresas en nuestro código, podemos empezar migrando poco a poco a funcional o tirarnos a la piscina con lenguajes que solamente implementan este paradigma, y tenemos algo de soporte en nuestros lenguajes del día a día de algunos conceptos como las lambdas. Ha sido una experiencia muy enriquecedora, y espero veros en la siguiente edición de Lambda World

Scala desde la perspectiva de C# y JavaScript, desde la Mindcamp

Este fin de semana he tenido la oportunidad de dar una charla en la Mindcamp sobre las características de Scala que he ido aprendiendo durante estas últimas semanas.

Aunque queda aún mucho por aprender, esta charla resume los temas que hemos ido viendo en los artículos anteriores de esta serie, así como algunos ejemplos donde podemos ver:

  • Hola mundo y diferencias de sintaxis con Java o C#
  • Clases, objetos, y funciones como ciudadanos de primera clase.
  • Sintaxis iterativa VS Sintaxis funcional.
  • Traits como manera de tener interfaces con implementación.
  • Case classes para realizar pattern matching y separar la interfaz de la implementación.

Los ejemplos están disponibles en este repositorio de Github: Mindcamp7-Scala.

Como parte de la charla, puse una lista de una serie de características que se quedaron fuera y que quedan como idea para futuros artículos, como son:

  • Frameworks como Play y Scalaz
  • Testing con ScalaTest
  • Integración con herramientas
  • La línea de comandos (REPL) de Scala
  • Interoperabilidad con Java.
  • La herramienta Activator de Typesafe
  • Scala Build Tool

Además, algunos recursos, muchos de los cuales ya hemos listado anteriormente en el blog, como son:

Finalmente, un par de libros que me recomendó el gran Jorge Barroso (@flipper83) sobre programación funcional:

Las diapositivas están disponibles en mi SlideShare: Scala desde C# y JavaScript

La semana próxima estaré en la LambdaWorld, un evento que reúne en Cadiz a lo mejor de la programación funcional, y habrá, por supuesto, Scala. Nos vemos allí!

Scala desde la perspectiva de C# y JavaScript, tercera parte

En los artículos anteriores de esta serie, veíamos una pequeña introducción a Scala, y hacíamos una kata para comprobar que habíamos entendido la sintaxis. En este artículo veremos dos construcciones del lenguaje que resultan bastante interesantes, llamadas traits y case classes.

Traits

Podemos entender los traits como una mezcla entre interfaces y clases abstractas, ya que podemos definir un contrato como haríamos con una interfaz, y por otra parte podemos definir también una implementación.

A diferencia de Java, Scala nos permite implementar varias traits, y podemos utilizarlas para agregar características adicionales a nuestro código. Veamos un ejemplo.

En este caso vamos a definir una clase base llamada Employee, que tiene un salario, y luego vamos a definir varios traits, algunos solamente con valores, y otros con pequeñas comprobaciones.

  • El trait Temporary calcula el mes final del contrato
  • El trait Authority nos permite saber si un empleado tiene gente a su cargo
  • El trait Remote nos permite establecer una localización y una zona horaria
  • Finalmente, el trait InOffice nos permite establecer un despacho.

Con estos cuatro traits podemos componer las clases que forman a nuestros empleados, donde tenemos a Developer, a Manager y a Intern:

Como vemos en el ejemplo, podemos utilizar los traits para definir características adicionales a nuestras clases, y podemos también agregar lógica dentro de las mismas, mezclando los conceptos de interfaz y clase abstracta.

Case classes

La otra cara de la moneda son las Case Classes, que podemos encontrar cuando definimos jerarquías, pero sobre todo las podemos encontrar cuando tenemos un número específico de entidades y lo que realmente cambia es lo que hacemos con ellas. Recuperando el mismo caso de empleados, becarios y managers, vamos a redefinirlo como Case Classes:

En este caso hemos simplificado la manera de definir los diferentes datos, y solamente utilizaremos la fecha inicial para Dev y Manager, y el tiempo total de estancia para Intern. En este caso, podemos asumir que nuestro conjunto de datos está fijo.

Sin embargo, ¿qué pasaría si necesitáramos agregar información de nóminas a nuestra aplicación? Si recurriéramos a la herencia, deberíamos implementar un método “salary” o similar, para cada una de las clases, sin embargo, como estamos usando “case classes” podemos crear un único método que las compruebe todas, y se comporte de manera consistente:

En este caso, el método nos devolverá distintos resultados en función de la clase que estemos aplicando y los datos que contenga la misma, permitiendo una separación entre las clases que contienen los datos de los métodos para manipularlos.

Este enfoque tiene sus inconvenientes, y es que si tenemos que agregar un nuevo tipo de dato (por ejemplo, External) tendremos que cambiar todos los métodos auxiliares para soportar el nuevo caso, así que se reduce a elegir en función de las necesidades de nuestro proyecto.

Conclusiones

Construcciones como Case Classes o Traits nos permiten establecer restricciones de una manera sencilla, las traits nos permiten mezclar conceptos de interfaces y clases, y las case classes nos permiten separar los datos de nuestra clase de las transformaciones que hacemos con los mismos.

En C# tenemos a nuestra disposición los métodos de extensión, con los que podemos lograr un comportamiento similar que con las case classes, y que hemos visto con anterioridad en este artículo “Clases abstractas VS interfaces + métodos de extensión“.

En el próximo artículo de la serie veremos más construcciones y, como siempre, más ejemplos.

Para más información:

Importando el calendario de nuestro evento favorito

El próximo 27 y 28 de noviembre estaré un año más en el Codemotion, un evento que se celebra en Madrid reúne comunidades de todo tipo y del que hemos hablado en otros artículos de años anteriores.

En ellas desarrolladores de .NET, Java y la JVM, Ruby, Python, JavaScript, Objective-C, Swift, PHP y otros, se reunen para enseñarnos lo mejor de todos los mundos. Yo ya tengo mi entrada, si no tienes la tuya ya estás tardando

Sin embargo hay algo que sigo sin entender. Al igual que en otros eventos, tenemos disponible la agenda completa en la web, y probablemente el primer día nos entregarán una copia EN PAPEL que acabará en una papelera varios días después del evento, si no lo perdemos antes.

No sería mucho más conveniente poder tener el calendario oficial del evento en un formato que lo pudiera entender nuestro Google Calendar, Outlook, iCal o cliente que utilicemos, y poder usar nuestro móvil para orientarnos por el evento? Pues bien, eso es lo que he hecho, y es lo que veremos en este artículo:

Primer paso, obtener los datos

Para obtener los datos originales tenemos muchas maneras. Una de ellas es utilizar un servicio como Kimono que nos permite crear una API REST a partir de una página ya existente, lo cual nos puede resultar muy útil para extraer información.

Otra opción consiste en investigar un cómo, y qué datos carga la página. En el caso de Codemotion, la agenda se carga de manera asíncrona, así que tras investigar el panel de red de Chrome podemos ver un fichero en formato JSON que contiene, para nuestro disfrute, la agenda completa a nuestra disposición, así que, misión cumplida.

Segundo paso, comprender el formato de salida

Para poder generar un fichero que sea compatible con los diferentes clientes de email, una de las opciones es utilizar el formato icalendar, que define un evento de la siguiente manera:

BEGIN:VEVENT
SUMMARY:Document like a hero using Asciidoctor
DTSTART:20151127T160000Z
DTEND:20151127T164500Z
DESCRIPTION:In 2013, the Spring team decided to migrate the Starting Guides on spring.io ...
END:VEVENT

Analicemos los diferentes componentes, dejando de lado las cabeceras begin y end del evento:

  • Summary: Título que se mostrará en la cita del calendario
  • Dtstart: Fecha y hora de inicio de la cita en la zona horaria UTC, en el siguiente formato: Año Mes Día (T) Hora Minutos Segundos (Z)
  • Dtend: Fecha y hora de fin de la cita, en el mismo formato anteriormente comentado
  • Description: Detalles del evento

Si hemos utilizado el calendario de manera corporativa echaremos de menos temas como invitados, alarmas, etc, aunque todos ellos forman parte del estándar y podemos utilizarlos sin problemas. Para reunir varios eventos en un fichero iCalendar hemos de establecer unas cabeceras y un pie de página de la siguiente manera:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
...
END:VCALENDAR

En este código, definimos nuestro fichero iCalendar, la versión del mismo, y el identificador del generador (que en este caso lo he tomado directamente del ejemplo de la wikipedia). Cerramos el fichero con el marcador End.

Con esta información, ya podemos generar nuestro calendario.

Tercer paso, generar el calendario

Para este ejemplo, como utilizaba un fichero en formato json, me pareció mucho más sencillo utilizar JavaScript y Node.js para generar el fichero ics.

Una de las cosas que nos aporta JavaScript, es que, al ser dinámicamente tipado, podemos abstraer la consola en un objeto creado por nosotros, y asignarlo o no a la consola en función de nuestra necesidad.

Como detalle a tener en cuenta está el uso de saltos de línea, ya que hemos de utilizar \n, de otra manera, se generará una nueva línea en el fichero de texto resultante y tendremos un error al importarlo.

Además, aunque parezca obvio, podemos tener más de un evento en un mismo fichero ics.

Cuarto paso, probarlo

Por último, y no por ello menos importante, es necesario confirmar que nuestro calendario se ha generado correctamente, para lo que podemos utilizar servicios como iCalendar validator. Finalmente recomiendo utilizar alguna aplicación de escritorio (como iCal en Mac) para hacer un par de importaciones y comprobar que todos los eventos se generan correctamente.

Conclusiones

Podemos generar un calendario utilizando el formato ics y teniendo una fuente de origen de datos. Si nuestra fuente está en formato json, podemos utilizar JavaScript de manera sencilla para movernos por el mismo, y generar nuestro fichero de resultado, que, por cierto, tienes disponible públicamente en Github.

Yo ya tengo mi calendario, y tú?

Enlaces adicionales:

Scala desde la perspectiva de C# y JavaScript, segunda parte

En la primera parte de esta serie vimos una primera introducción a Scala como lenguaje de programación definiendo algunas características de su sintaxis. En esta segunda parte pasaremos a la práctica utilizando una Code Kata.

En las artes marciales, se denomina kata a una representación, individual o colectiva, de un conjunto de movimientos. En disciplinas como el Karate se suelen enseñar en exhibiciones. El objetivo de las mismas es repetir los movimientos una y otra vez hasta que los mismos surjan de manera natural.

En programación, denominamos code kata a una definición de un problema relativamente simple, que resolvemos una y otra vez cuando estamos aprendiendo un lenguaje o una técnica como TDD. En este caso elegiremos una kata llamada Karate Chop, que define lo siguiente:

Dada una lista ordenada y un número, devolver la posición del mismo en la lista o -1 si no se encuentra, utilizando búsqueda binaria para ello.

El objetivo en este caso era ver si podía aprender lo mínimo necesario para poder escribir una solución a esta Kata utilizando Scala y utilizando la sintaxis de programación estructurada o orientada a objetos a la que estoy acostumbrado. Tras varias iteraciones agregando tests y condiciones, llegué al siguiente resultado:

Para hacer las pruebas se suele usar un framework como ScalaTest, o recurrir a JUnit o TestNG de Java, que, como hemos mencionado anteriormente, son compatibles. En mi caso me limité a crear una pequeña función auxiliar que simplemente comparaba el resultado de la función y escribía por pantalla si había discrepancias:

Finalmente, para comprobar que el código “funciona” he usado el siguiente conjunto de casos de prueba:

Escribiendo esta función aprendí varias cosas sobre Scala:

  • No necesitamos escribir el tipo de dato, ya que tenemos las palabras reservadas var para variables y val para objetos inmutables. Scala infiere el tipo de dato en tiempo de compilación por nosotros de la misma manera que lo hace C#, de manera que tenemos un sistema de tipos sólido y más sencillo de escribir.

  • Como curiosidades de sintaxis, el tipo de respuesta de una función lo definimos al final de la misma, en la definición de los parámetros también se declara primero el nombre y después el tipo, y el acceso a arrays se realiza mediante paréntesis en vez de corchetes.

#Conclusiones

Lo más importante que podemos ver en este ejemplo, es que no necesitamos cambiar nuestra manera de programar para comenzar a usar Scala, y que podemos ir agregando características funcionales de lenguaje a nuestro código poco a poco.

En el siguiente artículo de la serie volveremos a la teoría, retomando por donde lo habíamos dejado, viendo características como las Case Classes, el reconocimiento de patrones, y otros ejemplos de código, más funcionales que podemos encontrar en GitHub.

Mientras tanto, aquí están algunos enlaces sobre coding katas que he usado para hacer este artículo:

Scala desde la perspectiva de C# y JavaScript, primera parte

Hace unos días me estuvieron hablando de las ventajas y maravillas de Scala, un lenguaje multiparadigma con un fuerte enfoque funcional que funciona sobre la máquina virtual de Java, es 100% compatible con el mismo en ambas direcciones, y también por ello es multiplataforma.

Tras echarle un vistazo a algo de documentación me pareció suficientemente interesante como para intentar escribir algo de código, y algunos artículos, usando la perspectiva de otros lenguajes como C# o JavaScript.

Historia

Scala es un lenguaje que llegó a nosotros desde el mundo académico por parte de Martin Odersky en el año 2003. Odersky, quien había trabajado anteriormente en javac, creó el lenguaje combinando ideas de diferentes lenguajes funcionales.

Como curiosidad, destacar que en sus primeras versiones estuvo disponible tanto para la plataforma Java como para .NET, aunque el soporte para el último fue perdiendo popularidad con los años y desde 2012 no está soportado oficialmente.

No es ni mucho menos el único lenguaje funcional que nos encontramos para la JVM, ya que existen alternativas como Haskell o Clojure, pero sin duda Scala es uno de los más potentes y veteranos, usado actualmente por empresas como LinkedIn, Twitter o FourSquare.

¿Qué tiene de especial?

Sintaxis simple

Basta con echar un vistazo a un “Hola mundo” para ver que la sintaxis es algo más simple que en java:

object HelloWorld {
	def main(args: Array[String]){
		println("Hello world")
	}
}

Si guardamos este código en un fichero HelloWorld.scala, podemos compilarlo usando scalac HelloWorld.scala y ejecutarlo ejecutar utilizando el comando scala -classpath . HelloWorld, con lo cual solamente necesitamos un bloc de notas (o Sublime Text/Atom/Vim/Emacs) y una línea de comandos para empezar a jugar.

Una de las cosas que primero nos llama la atención es la palabra reservada object. Al usar esta palabra reservada definimos la clase como Singleton y el compilador nos genera una instancia con el nombre de la clase, de tal manera que podríamos llamar al método HelloWorld.main desde cualquier punto de nuestra aplicación. Usando la palabra reservada class podemos utilizar las clases a las que estamos acostumbrados en otros lenguajes como C# y Java.

Todo es un objeto

A diferencia de Java, Scala no tiene el concepto de tipos básicos, como pudieran ser enteros, floats, o booleanos, sino que todos ellos son objetos, de la misma manera que lo podemos encontrar en C#. Como objetos, se pasan por referencia y no por valor, y simplifican tanto la lectura como la escritura, ya que no tenemos que estar trabajando con conceptos como boxing o unboxing.

Sin embargo, Scala va un paso más allá, y las funciones también pueden ser objetos, con lo cual las podemos pasar por referencia a otras funciones. Si hemos trabajado anteriormente con JavaScript, esto nos sonará mucho a los callbacks de métodos asíncronos, donde podemos pasar una función por parámetro, y si venimos de C# podemos conseguir el mismo efecto utilizando Delegates.

Veamos un ejemplo:

object Timer {
	def oncePerSecond(callback: () => Unit){
		while(true) {callback(); Thread sleep 1000 }
	}

	def callback(){
		println("Ping..."))
	}

	def main(args: Array[String]){
		oncePerSecond(callback)
	}
}

En este ejemplo podemos ver cómo utilizamos un callback que ejecutamos una vez cada segundo. Como curiosidad de sintaxis podemos ver que al llamar al método sleep no usa la sintaxis Thread.sleep(1000) a la que podíamos estar acostumbrados, que también es válida, lo que se denomina sintaxis infija.

Clases y constructores.

Siguiendo con la filosofía de no escribir más código del necesario, podemos definir nuestras clases en Scala directamente con el constructor en la definición de la misma, como muestra el ejemplo:

class Complex(real: Double, imaginary: Double){
	def re() = real
	def im() = imaginary
}

En este caso en la definición de la clase definimos además dos métodos que nos permiten recuperar el resultado de los valores. En caso de que necesitemos más de un constructor, Scala lo soporta mediante el uso de “this”, como muestra el siguiente artículo: Alternate constructors in Scala

La opción de definir los parámetros del constructor era algo que originalmente estaba previsto para C# 6, pero que se retiró de la especificación por su complejidad, aunque es posible que la veamos en C# 7 como muestra el hilo en CodePlex

Es importante destacar que Scala, a diferencia de JavaScript, es estáticamente tipado, con lo cual el tipo de dato de respuesta del método re, será de tipo Double, y se calculará en tiempo de compilación. Podríamos además, quitar los paréntesis tanto a los métodos re como im, y obtendríamos propiedades como las de C#

Resumen y siguientes pasos

Scala es un lenguaje multiparadigma, esto es, que podemos seguir programando de manera orientada a objetos, o podemos incorporar alguna de las características de la programación funcional. Utiliza la JVM y es compatible con Java en ambas direcciones.

En la segunda parte de esta serie, veremos características como las Case Classes, el reconocimiento de patrones, y algunos ejemplos de proyectos reales que podemos encontrar en github. Mientras tanto, aquí están algunas fuentes que he usado para hacer los artículos de esta serie, así como algunos vídeos recomendados:

Kanwal, mi propio Trello dentro del firewall

He de reconocer que soy un gran fan de Trello, un tablero de Kanban personalizable que me permite organizar mi agenda, mis objetivos personales, los viajes, las charlas, mis proyectos y los regalos de navidad, entre otros.

Sin embargo, para uso profesional he descubierto que muchas empresas que no permiten guardar información relacionada con proyectos en servicios en la nube, y para ello he creado un pequeño clon de Trello llamado Kanwal, para poderlo utilizar de manera segura dentro el firewall.

Para poder empezar a utilizarla necesitaba, como mínimo, las siguientes características:

  • Aregar listas
  • Agregar elementos a las listas
  • Borrar elementos de las listas

Características como mover un elemento de lista o editar elementos pueden ser muy chulas, aunque entrarán en la siguiente versión.

Con esa máxima tocaba escoger armas, y en mi caso fueron dos que ya había utilizado anteriormente:

  • Knockout.JS: Un framework MVVM muy sencillo y ligero que me permite realizar data-bindings de manera rápida y fácil
  • Bootstrap: Un framework CSS que me permite dar una estructura y un aspecto básicos a la web.
  • Yeoman: Una herramienta que nos permite crear proyectos con diferentes frameworks de manera rápida y sencilla.

Con las armas escogidas, tocaba ponerse manos a la obra, y un par de horas después la aplicación (si es que podemos llamarla aplicación) tenía este aspecto: Espartano, básico, pero es todo lo que necesito para empezar a trabajar:

kanwall-v1

La arquitectura es muy simple:

Una tarea:

  • Es una cadena de texto simple

Una lista:

  • Es un Viewmodel que contiene un título y una lista de tareas.
  • Contiene un método para agregar tareas, para borrarlas y para renombrar la lista, pasando a un sencillo “modo edición”.
  • Contiene una referencia al método guardar del viewmodel global.

El viemodel global:

  • Es una lista de listas.
  • Contiene Métodos para guardar y cargar los datos de local storage.

Como curiosidad, el nombre original era Kan-Wall (de Kanban firewall), aunque gracias a la corrección de Google descubrí que el nombre (con una L) correspondía a una región de Australia, así que así se ha quedado.

Le puedes echar un vistazo a la aplicación en rlbisbe.github.io/kanwal y ver el código fuente en github.
Si estás interesado en ayudar, envíame una pull request!

Have fun!