Bibliografía: Designed for use

Desde hace meses oigo hablar sobre UX por todos lados, y venía a mi cabeza la típica pregunta, ¿qué demonios es UX?. Decir que UX puede ser la abreviatura de User Experience es como decir que al tenis se juega con una raqueta, no me aclara mucho las cosas. Así que no me quedaba otra que recurrir a las recomendaciones literarias de los expertos. Después de un instante buscando algo interesante, me decanté por Designed for use de Lukas Mathis.

La primera cosa que me gustó del libro es su organización, como en otros tantos libros de Pragmatic Programmers. Este en concreto está divido en tres grandes bloques:

• Research
• Design
• Implementation

Mucha gente creerá que estando dividido en estos bloques el libro trata el proceso de desarrollo de una aplicación de forma waterfall, nada más lejos de la realidad. La aproximación del Sr. Mathis es totalmente incremental y en todo momento hace referencia al feedback del usuario para modificar nuestro producto y hacerlo mejor. La razón de dividir el libro de esta manera (creo yo) es que así el lector puede ir colocando cada elemento en su lugar, cada práctica en el lugar que más nos ayude. Hay que recordar que no siempre se tienen porque usar absolutamente todas las técnicas que usan otras personas y que las que funcionan en unos equipos no siempre tienen que funcionar necesariamente igual en el nuestro.

El libro diferencia claramente dos tipos de capítulos, unos más teóricos y otros más prácticos. En general yo encontré bastante teoría en capítulos considerados prácticos e igualmente bastante práctica en capítulos considerados teóricos, creo que simplemente se debe a que ambas cosas van muy de la mano. Esto no afecta en absoluto a la calidad final del libro, que me parece bastante buena. Además cada capítulo es bastante corto y conciso en su mensaje, lo que facilita aún más su lectura.

Antes de empezar a leer el libro pensaba que hablaría sobre como diseñar las interfaces de usuario de la aplicación, pero a medida que iba leyendo me daba cuenta que no iba a resolver ese aspecto. Por el contrario, el libro habla más sobre prácticas que se pueden realizar junto a los usuarios, como comprobar si el diseño es usable y como ir adaptándolo poco a poco. 

Al final a mi me gustó mucho, si quieres aprender técnicas para mejorar la experiencia de los usuarios con nuestras aplicaciones esté es un buen comienzo, pero si buscas bibliografía enfocada a como diseñar interfaces de usuario exclusivamente, quizás es mejor que elijas otra opción.

Objetos valor

Vaya, he estado ojeando los borradores acumulados en mi cuenta de Blogger y parece que por aquí había una idea que no estaba mal. No se porque razón no completé este artículo y lo publique, pero como nunca es tarde si la dicha es buena, allá vamos.

Hace poco (bueno, ahora ya hace más de año y medio :-) leí un artículo de Krzysztof Adamczyk sobre la potencia de hacer uso de objetos valor en nuestro código, y he pensado que podría ser interesante que presente mi propia opinión al respecto de este tema. Para ello tomaré prestadas las ideas del propio Krzysztof Adamczyk y las expuestas por Dan Berg Johnsson en su presentación en la QCon London 2009.

*Nota al lector*

El siguiente código no es de producción, tan solo es a modo de ejemplo. Se puede descargar completo de la siguiente dirección, modificar y utilizar libremente.

https://github.com/ydarias/ValueObjects

Esta realizado en Scala, pero cualquier persona con conocimientos de Java lo puede entender de forma sencilla.

¿Qué es un objeto valor?

Lo mejor será empezar por el principio. Para todos aquellos que no sepan lo que es un objeto valor, Eric Evans define en su libro un objeto valor de la siguiente manera.

"An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object."

He preferido dejarlo en el idioma original porque es posible que yo metiese la pata al hacer la traducción, por lo que con esta definición y lo que cada uno entienda de ella, empezaré con el contenido de esta entrada.

Los detalles del dominio se hacen explícitos

Una de las ventajas de hacer uso de los objetos valor, es que en el código desaparecen los tipos como String o int por tipos como PhoneNumber o Email. Aquí muchos pensaréis que esto no es ninguna ventaja sino que añade complejidad, puede ser pero dejadme unos párrafos de ventaja por favor.

Imaginad que estamos trabajando en un nuevo y avanzadísimo sistema de gestión ... como por ejemplo, una simple una agenda. Como en cualquier agenda, tendremos un objeto de modelo que define el contacto y generalmente nos encontraríamos con algo similar al siguiente código.

class Contact(val firstName: String, val lastName: String,
 val phoneNumber: String) {
 
 override def toString(): String = {
  firstName + " " + lastName + " : " + phoneNumber
 }
}

object Agenda {
 
 def main(args: Array[String]) = {
  val contact = new Contact("Pepe", "García", "922222222")
  println(contact)
 }
 
}

Genial, muy sencillo, pero ahora imaginemos  que nuestro cliente quiere que su agenda indique de forma automática con un icono (que nosotros representaremos en el ejemplo con texto) cuando se trata de un teléfono fijo y cuando de un móvil, por poner un ejemplo. Muchas veces la opción más utilizada es la siguiente.

class Contact(val firstName: String, val lastName: String,
 val phoneNumber: String) {
 
 def phoneNumberType(): String = {
  if (phoneNumber.startsWith("6"))
   "móvil"
  else
   "fijo"
 }
 
 override def toString(): String = {
  firstName + " " + lastName + " : " + phoneNumber + 
   " (" + phoneNumberType + ")"
 }
}

object Agenda {
 
 def main(args: Array[String]) = {
  val pepe = new Contact("Pepe", "García", "922222222")
  println(pepe)
  val juan = new Contact("Juan", "Juanez", "633445566")
  println(juan)

 }
 
}

Pero ¿qué ocurriría si hiciésemos esto otro?.

class PhoneNumber(val phoneNumber: String) {

 def withType(): String = {
  phoneNumber + " (" + phoneType + ")"
 }
 
 private def phoneType(): String = {
  if (phoneNumber.startsWith("6"))
   "móvil"
  else
   "fijo"
 }
 
}

class Contact(val firstName: String, val lastName: String,
 val phoneNumber: PhoneNumber) {
 
 override def toString(): String = {
  firstName + " " + lastName + " : " + phoneNumber.withType
 }
 
}

object Agenda {
 
 def main(args: Array[String]) = {
  val pepePhone = new PhoneNumber("922222222")
  val pepe = new Contact("Pepe", "García", pepePhone)
  println(pepe)
  val juanPhone = new PhoneNumber("633445566")
  val juan = new Contact("Juan", "Juanez", juanPhone)
  println(juan)

 }
 
}

Ciertamente son bastantes más líneas de código, pero ¿qué hay de la limpieza? y aún más importante, de esta manera se cumple la regla que dice que cada elemento debe tener una única responsabilidad. Ahora la clase Contact no tiene lógica sobre la forma en la que se muestra el número de teléfono.

Al tratarse de un ejemplo hemos metido lógica de la vista en el modelo, pero en un caso real lo que haríamos es tener un método en PhoneNumber que nos indique de que tipo de dispositivo se trata, y ya se encargará la capa de la vista de representarlo.

El código se extiende más fácilmente

Sigue sin parecerte nada especial y la legibilidad del código no te importa mucho, aunque debería. Pues otra ventaja es que el código se extiende más fácilmente y de manera comprensible. Imagina que ahora queremos saber qué números de teléfono tienen errores, pues basta con que añadamos dicha funcionalidad en el propio objeto PhoneNumber, sin seguir complicando otras clases ni desperdigar la lógica por el resto de la aplicación.

Para acabar me gustaría señalar como de esta manera hemos evitado tener un modelo anémico. Es muy usual que se creen modelos como si fueran simples CRUD y luego se reparta cierta lógica en validadores y helpers, ¿no es más lógico que sea el propio objeto el que tenga la lógica que le afecta únicamente a él?

Spring I/O 2012

Ya estoy de vuelta en la isla tras la Spring I/O 2012, a la que asistimos algunos de los habituales de Agile Canarias. Y para retomar la actividad del blog, voy a hacer un resumen de lo que se pudo ver en esta edición.

La Spring I/O, gracias a la organización de JavaHispano, se ha transformado, con permiso de Greach, en la conferencia más importante del mundo Java en España. 300 asistentes, más de 30 ponentes, 2 tracks por día y 5 workshops lo demuestran. ¡Y la entrada solo cuesta 30 €!, si esto lo celebras en Londres no bajaría de 800 €.

*Disclaimer*

Esta es una conferencia muy amplia así que solo podré hablar de aquellas charlas o talleres en los que estuve presente. Pero seguro que otros asistentes también escribirán en sus blogs, y además en breve estarán disponibles los vídeos de todas las charlas.

Primer día

Application Development in the Cloud Era by Adrian Colyer

Para empezar con ganas, ni más ni menos que el CTO de SpringSource hablando sobre la evolución de las aplicaciones y las arquitecturas. Con la aparición de "la nube" las aplicaciones han cambiado radicalmente y en Spring se han dado cuenta, y han trabajado en varios productos que ayudan al desarrollador en estos aspectos.

La introducción en escena de nuevos dispositivos de visualización, como los móviles y las tablets, han cambiado radicalmente el diseño de muchas aplicaciones. JavaScript ha logrado que los clientes tengan mucha más responsabilidad, dejando que los servidores ahora oferten una serie de servicios web que cada cliente utiliza a la carta. Un mismo backend puede proveer a gran cantidad de clientes, como ocurre por ejemplo en el caso de Twitter, en donde existen infinidad de clientes ofreciendo diferentes opciones, pero todos se conectan a los servicios ofertados por Twitter.

Spring 3.1 to 3.2 in a Nutshell by Sam Brannen

En esta charla, Sam Brannen confirmó lo que ya había indicado el año pasado. La verdad es que no se habló demasiado de Spring 3.2 y se entró en más detalle en las nuevas cualidades de Spring 3.1. Habían muchas pero personalmente me quedo con algunas que me parecen más relevantes.

• En la definición de beans, podremos usar perfiles, de forma que en función del perfil indicado se utilicen unos beans u otros. Por ejemplo podría ser de utilidad para diferenciar entre los accesos a BD de producción y desarrollo,
• En los controladores MVC se mapean los argumentos anotados con @PathVariable directamente al modelo retornado por el método.

No fue una charla muy intensa, pero si no tenias mucha idea de la novedades de Spring 3.1 podías sacar algo.

Polyglot Messaging with RabbitMQ by Rob Harrop

No hay mucho que contar sobre esta charla, Rob Harrop explicó como utilizar RabbitMQ como sistema de comunicación entre diferentes aplicaciones hechas en distintos lenguajes. Utilizó desde Java hasta Haskell para mostrar las posibilidades de RabbitMQ como sistema de interconexión.

Al día siguiente Domingo Suarez nos terminaría de convencer acerca de las ventajas de usar RabbitMQ como sistema de colas, ya que no solo es muy estable sino que require muy poca administración.

Spring Data y MongoDB por David Gomez

David Gomez de Extrema Sistemas, explico de manera breve el proyecto en el que habían tenido que trabajar y porque utilizaron MongoDB como sistema de persistencia. Estuvo muy bien porque explicó las diferencias entre los diferentes sistemas NoSQL y cual fue la razón por el que seleccionaron Mongo.

Comentó también las herramientas de las que dispone la suite de Spring para hacer uso de Mongo, Spring Data y los detalles con los que se debe tener cuidado en su utilización.

Spring Roo

Para ir finalizando el primer día, un poco de Spring Roo. Debo decir que tenía ganas de verlo, porque en otras charlas lo habían utilizado y daba la impresión que en algunos casos es una herramienta muy potente.

Spring Roo permite crear proyectos Spring en pocos segundos, hacer scafolding de clases de modelo, controladores y demás artilugios. Además se integra perfectamente con Spring Tools Suite, por lo que cualquiera que esté acostumbrado a utilizar Eclipse le puede venir muy bien. Digamos que se trata de una herramienta que se sitúa entre hacer todo el proyecto a mano o utilizar un sistema tipo Grails.

Enterprise Integration - The Seriously Nasty Stuf by John Davies

Sinceramente debo decir que tras un buen rato en esta ponencia, seguía sin saber muy bien de que trataba. Tras dar una lista de formatos de intercambios de datos y ejemplos de los mismos durante 25 minutos, no tuve otro remedio que usar la regla de los dos pies, salir de la sala sin hacer ruido y a otra cosa mariposa.

La fiesta de Atlassian

Tras un día muy largo, y una agradable cena con el resto del #comandomuyayo, nos presentamos en el Moma56 para la fiesta que Atlassian había preparado. Muchas personas no lo consideran importante, ni tan siquiera interesante, pero el networking que se genera en estos eventos es importantísimo. No solo tienes la oportunidad de aprender otras cosas y puntos de vista sobre temas tratados en la conferencia con los asistentes a la misma, sino que se crean contactos muy interesantes. Además es en estos instantes de networking donde más recargas las pilas, te relacionas con la gente y tu cabeza se llena de ideas y ganas de hacer las cosas bien.

Atlassian como ya empieza a ser costumbre no defraudó y no solo por el picoteo, los copazos y las camisetas que regaló. Su embajador, David Bonilla, anunció una noticia bomba. Atlassian está contratando gente y también buscarán en España, así que si estas interesado ya sabes con quien contactar. Eso sí, es para ir a trabajar a Australia.

Segundo día

Keynote by Graeme Rocher

Como era de esperar, en el segundo día tuvimos al máximo representante de Grails explicando cuales son las novedades de este sistema en su versión 2.0. Siempre es interesante ver a Graeme haciendo un esfuerzo por hablar integramente en español, pero hay que decir que sus charlas son un poco duras porque es complicado seguir sus pasos en la consola, como ya ocurría en el día anterior con Rob Harrop.

Whoops! Where did my architecture go? by Oliver Gierke

Esta fue para mi una de las charlas más interesantes, en donde Oliver Gierke nos explicó cual es la metodología que ellos utilizan para crear sus proyectos. Desde la división por capas y dominio, hasta la modificación de la visibilidad de clases para que no se pueda estropear la arquitectura por error. Una vuelta de tuerca más a la utilización de las interfaces como contratos.

También nos mostró alguna herramientas interesantes como JDepend y SonarGraph que pueden ayudar enormemente a tener todo bajo control y que no se nos vaya de las manos. Y finalizó con algunas ideas en la creación de sistemas basados en plugins que permitan la extensibilidad sin dañar el core de nuestro proyecto.

Spring in Scala by Jan Machacek


Esta charla me pareció interesante aunque a mi en particular no me enseñó mucho porque ya había utilizado Scala con Spring. Jan Machacek introdujo Scala, aunque los ejemplo quizás eran un poco rebuscados para la gente que no había tocado el lenguaje anteriormente.

Securing your REST API with OAuth por Sergi Almar

La seguridad es uno de los temas que más flojos llevo yo personalmente, así que me decante por ir a ver que nos proponía Sergi Almar y debo decir que me gustó mucho. Durante una hora nos introdujo a las diferencias entre OAuth 1 y OAuth 2 y acabo enseñándonos como con el módulo de OAuth de Spring Security se puede gestionar la seguridad de nuestra aplicación facilmente.

Todavía es un proyecto en desarrollo y está un poco verde, pero apunta muy buenas maneras, quizás en unos meses sea una opción real para sistemas que requieren mucha integración como me pasa a mi en mi último proyecto.

Grails, opción real y escalable para sitios web de alta carga por Domingo Suarez

Al final del segundo día no habían muchas ponencias de mi interés, así que me decante por volver con mis compañeros de Agile Canarias. Que sorpresa más grata me lleve durante esta hora con Domingo Suarez, no solo por lo bien que expuso el tema, sino porque salí con algunos detalles e ideas muy interesantes que me puedo llevar a mi proyectos en Java.

Desde la confirmación de RabbitMQ como un gran sistema de colas, hasta la mención de Terracota como servidor de aplicación y JavaMelody para monitorizar el estado de la aplicación.

Aplicando elasticidad en la búsqueda con Grails por Enrique Medina Montenegro

Para finalizar la conferencia asistí a la charla de Enrique Medina. Las búsquedas no es un tema con el que trabaje muy a menudo, pero la presentación fue bastante buena. Desde las cosas a tener en cuenta hasta lo que no debemos hacer cuando utilizamos un sistema como Compass, para realizar búsquedas avanzadas en nuestra aplicación.

Networking, despedida y cierre

Como no podía ser menos, al final del día la organización nos tenía preparado un rato de ocio y networking con cervezas gratis en la cafetería de la CEU San Pablo. Pero el cansancio acumulado ya pesaba por lo que tras un rato nos volvimos al centro de Madrid a cenar y dar por finalizada la aventura de la Spring I/O 2012 hasta el próximo año.

Antes de acabar quiero agradecer a la CEU San Pablo por sus instalaciones y a los patrocinadores por su participación. Pero este evento no sería posible sin el gran trabajo de Sergi Almar y Abraham Otero, muchas gracias a ellos sobretodo.

Porque no se cancelan las operaciones en Eclipse

Ya llevamos muchos días del nuevo año y no he escrito nada en el blog, pero hoy el amigo @kinisoftware ha escrito un tweet que me ha dado la clave para escribir un artículo breve, pero curioso. Muchas gracias amigo, has venido al rescate en el momento justo :-D

¿Por qué tendrá Eclipse un botón "Cancelar" en las ventajas de acciones en ejecución que si lo pulsas te ignora? Quítalo directamente xD by @kinisoftware

Cuando leí este tweet no tuve más remedio que reírme por la razón que tiene Kini, pero también me vino a la cabeza aquellos tiempos en los que estuve trabajando en un plugin para Eclipse, que tampoco fue en la era del Jurásico, debió ser allá por la versión 3.5 de Eclipse. Mientras leía el libro que teníamos de referencia y me peleaba con el código, llegué a una interfaz llamada IProgressMonitor, ahora verás para que sirve esta interfaz tan curiosa.

La biblia del desarrollo de plugins para Eclipse

IProgressMonitor es la interfaz que deben implementar las actividades para poder aparecer en la pestaña esa tan molona que tiene el Eclipse, sí esa en la que aparece el progreso de cada actividad que esta en ejecución. Esa en la que Kini y todos nosotros apretamos el cuadradito rojo y no pasa nada de nada. Si vamos a la página de la API de Eclipse que contiene la información de IProgressMonitor, podemos leer lo siguiente.

"A request to cancel an operation can be signaled using the setCanceled method. Operations taking a progress monitor are expected to poll the monitor (using isCanceled) periodically and abort at their earliest convenience. Operation can however choose to ignore cancelation requests."

Lo que viene a decir eso es que Eclipse provee una forma para cancelar las tareas, pero se deja a elección de los desarrolladores del plugin de turno como hacerlo, intuyo que se decantan por esa parte de "Operation can however choose to ignore cancellation requests". Esta claro que la cancelación no siempre es posible o la lógica es tremendamente complicada, pero seamos serios, un gran porcentaje de plugins hacen lo siguiente.

class MiActividad ... implements IProcessMonitor { 
   ... 


   public boolean isCanceled() {} 


   public void setCanceled(boolean value) {} 


   ... 
}

Y a grandes rasgos esta es la razón por la que no funciona el botón de cancelar en Eclipse ... porque no está implementada :-)

Retrospectiva del año 2011

Otro año más David Bonilla hace su retrospectiva del año y de rebote nos mete a los demás en el embolado, y como a los amigos hay que responderles, aqui va mi entrada. Aprovecho para hacer la retrospectiva hoy, porque es mi 31 cumpleaños y nada mejor para celebrarlo que recapacitar sobre lo sucedido los 365 días anteriores.

El año pasado había planteado unos objetivos que para ser sinceros no he tenido muy en cuenta a lo largo del año, pero por suerte gran parte de ellos se han cumplido muy bien, y por "desgracia" otros no tanto.

• En el trabajo diario en AvanTIC hemos descuidado un poco el proceso Scrum, sobretodo en la parte final del año donde más presión había, pero por otro lado hemos mejorado mucho la calidad de nuestros productos, en gran medida por la adopción un poco más generalizada de TDD y la revisión "oficiosa" de código. Digamos que este objetivo no se ha cumplido, pero tampoco ha caído en saco roto. 
• Lo que sí se ha cumplido con creces es la asistencia a los dos eventos de Agile Spain, la Conferencias Agile Spain 2011 y el Agile Open Spain 2011. No solo eso, sino que asistí a la SpringIO 2011 y a la fantástica Apache Barcamp Spain 2011, un año surtido de eventos, sobretodo para mi que vivo en Canarias. Y para rematarlo pude hacer algo que tenía en la cabeza desde hacía bastante tiempo, pasé una semana con la gente de BeCode y Enrique Amodeo, una experiencia que me pareció increíble.
• Otro objetivo cumplido con creces ha sido el de aumentar el número de entradas en el blog, aunque creo que todavía queda mucho camino por recorrer hasta que sea un hábito más cotidiano.
• Y los dos grandes fracasos del año, han sido ... no he ido a Nueva York :-( y he terminado desistiendo de intentar organizar la AOS en Tenerife, todavía falta que la comunidad local crezca un poco y madure, pero Zaragoza será una anfitriona genial seguro :-)

Como toda buena retrospectiva también habrá que pensar en los objetivos para el próximo año.

• Como comenté antes he desistido de la idea de una AOS en Canarias, pero eso no quiere decir que no intentemos organizar un evento, así que preparaos para la Código Picón 2012 :-D
• Después de las lecciones aprendidas del maestro Roberto Canales en la Apache Barcamp, este año intentaré aprender y desarrollar otras cosas que aporten valor a mi trabajo diario, pero sin descuidar mis conocimientos técnicos.
• Espero poder participar activamente en la zona profesional de la Tenerife Lan Party 2012 que tan bien salió este año.
• Al final del año creo que he mejorado mucho como profesional y espero poder mantener esa evolución el próximo año, sobretodo asistiendo a eventos (que aún no he decidido) y compartiendo mi tiempo con los magnificos amigos y profesionales que suelen asistir a este tipo de reuniones.
• Para acabar espero poder hacer el maldito viaje a Nueva York de una vez, aunque parece que este no es el año más indicado :-S

Espero poder leer las retrospectivas de toda la gente a la que David Bonilla citó en su blog y algunos más.

P.D: ni que decir tiene que el objetivo de hacer más deporte en 2011 tampoco se cumplió, por eso ni lo mencionaré para 2012 :-)