Groovy y Grails por tierras danesas: GR8Conf

El día a día, Tecnología

La semana pasada un par de Virtuales hemos tenido la suerte de poder asistir a las conferencias gr8Conf en Copenhague gracias a la invitación que la organización danesa hizo a Greach, el evento español sobre Groovy y Grails. Nos juntamos unos cuantos españoles por alli, entre los vecinos Kaleiders, un par de ponentes (Jorge Franco, de Osoco y Alvaro Sanchez-Mariscal de Odobo) y Fernando ‘Pronoide’ Redondo y por parte de Virtual Software,  Alberto Vilches (alma de Greach) y yo mismo.

GR8Conf es uno de los eventos sobre el ecosistema Groovy y Grails mas veteranos. Su fundador, Søren Berg Glasius lleva ya 6 ediciones a sus espaldas, y obviamente se nota el cuidado con el que todo está preparado para hacer un evento de primera linea.

¿Sabes lo que pasa cuando publicas un enlace en Twitter?

El día a día, Tecnología

 

diy-seo-blog

 

Hace unos minutos hemos publicado una oferta de trabajo para nuestra empresa. Para tener un único punto de referencia a la hora de enviar el enlace con las condiciones de la misma, hemos creado una página en nuestro servidor web.

Hasta aquí todo normal. Hemos visto que se veía bien y hemos puesto el enlace en Twitter para empezar a dar a conocer la oferta.

Por casualidad, estaba en ese momento mirando los log del servidor. Y ¿adivinas lo que pasa prácticamente en el mismo instante en que envías una dirección a Twitter?

Una nueva Startup: Fórmula ATP

Negocio

9907_04_5_prev1

Desde hace tiempo en Virtual Software estamos buscando proyectos en los que poder participar no solo como proveedores sino como socios del mismo. Estos proyectos normalmente han sido productos para el mundo empresarial, como podéis ver en nuestra web, pero esta vez nuestro objetivo son las personas, no las empresas.

Para ello el 9 de Diciembre de 2013 se ha creado una nueva Startup: Fórmula ATP S.L., orientada a dar servicios a los conductores de todo tipo de  vehículos hasta 3.500 kilos basados en las últimas tecnologías.

Nombres de servidores

El día a día, Tecnología

 

idi_020

 

En Virtual Software tenemos una red local de uso interno y una de acceso público para servicios que damos a clientes, y lógicamente cada servidor tiene que tener un nombre. Obviamente, como cualquier buen geek que se precie, todos los nombres de las máquinas tienen que tener entre si alguna relación o tema. Ya sabía que no era el único -ni mucho menos-, pero cuando ayer en Microsiervos publicaron un enlace a hostnames, una página con series de nombres (personajes de Los Simpson, dioses romanos o griegos… ) pensé que tal vez estuviera tambien nuestra serie. Pero no 🙂

¡Arregla ese código ya!

Sin categoría

 

robots_programmer_psychiatrist_285645

 

Vale. Estas tocando código en el proyecto en el que estás metido ultimamente y de repente encuentras un mal trozo de código en una función. Las malas aproximaciónes -aunque muchas veces habituales- pueden ser del estilo “bueeeeno… ese es el código de otro y no tengo nada que ver con el” o “no tengo tiempo ahora, tengo otras tareas” o “seguro que rompo algo si toco esto”

El (gran) problema es que el mal código tiende a acumularse y crecer. Incluso si es un pequeño trozo de mal código, crecerá y en breve tendrás un nuevo proyecto heredado del que se dira que fué escrito por incompetentes y que nadie querrá mantener. ¿Te suena?.

Ese es el motivo por el que tienes que arreglar ese código inmediatamente. Cuando veas algo mal hecho, que use una mala practica, o que sea manifiestamente mejorable: mejóralo. YA. O, teniendo en cuenta que unas partes de código depende de otras, seguramente muy pronto será demasiado tarde para hacerlo y las nuevas lineas que añadas (peor aún si alguien se dedica a copiar y pegar) serán una auténtica pesadilla para mantener. Veamos como solucionar las excusas anteriores:

Bueeeeno… ese es el código de otro y no tengo nada que ver con el. ¿Cómo?. ¿Que me dices?. Tu *estas* en ese proyecto, asi que tienes el “derecho” a modificarlo. Si otro ha escrito ese código que tu consideras que no es bueno, es probable que ni siquiera se haya dado cuenta de lo malo que es, asi que no lo arreglará nunca. Seguramente no se ofenderá si lo arreglas y le cuentas porqué lo has hecho. O tal vez si, pero ese es otro problema (y no es tuyo).

No tengo tiempo ahora, tengo otras tareas . Esto tambien es una tarea. Y ademas seguramente puedes incluso anotar una nueva incidencia en tu sistema de control tipo Jira, Redmine, Bugzilla o lo que quiera que uses indicando refactorizacion de lo-que-sea y apuntar ahí las correspondientes horas. Tambien puedes simplemente anotarlo para resolver en el próximo sprint si usas metodologias ágiles. Si hay problemas con la gente de administración o gerencia puedes sugerirles que lean algo sobre ‘refactorización’. Normalmente no sirve de mucho pero al menos limpiarás tu conciencia.

Seguro que rompo algo si toco esto . Vale, seguramente si que lo vas a romper. Hmmm.. espera. Tienes test unitarios, ¿verdad?. Y test de integración, funcionales y de aceptación, ¿no?. Si no es asi, arregla eso lo primero de todo. A partir de ese momento no tendras miedo de romper nada. Las revisiones de código tambien son importantes para solucionar este problema. Si el equipo revisa el nuevo código que entra en el proyecto, las probabilidades de que entre mal código sin que nadie de se cuenta decrecen. Puede pasar, pero es mucho mas dificil.

El gran problema de esta aproximación al código es, ¿como puedes estar seguro de que ese trozo de código esta realmente mal hecho?. Bueno, al final es un tema de experiencia, conocimiento de buenas prácticas, patrones de diseño y toda la artilleria de los mejores programadores. No se puede dar una receta única para esto, pero seguramente en tu equipo debe haber un par de personas capaces de identificar mal código. Si no es asi, deberias intentar conseguir al menos una persona con ese perfil.

Resumiendo: arregla el codigo inmediatamente. Te ahorrará tiempo, dolores de cabeza y hará que estes mas orgulloso de tu proyecto. Porque si el código de tu proyecto es una basura, también es tu culpa.

Anotaciónes: No deberias cambiar algo sólo porque de repente te parezca que está mal. Enseñaselo a tus compañeros y/o líderes técnicos. Si es mas de un par de lineas, discute la mejor forma de afrontarlo y crea una histora para solucionar el problema. Pero hazlo pronto.

Estos consejos no se refieren a código complejo o dificil de leer precisamente por solucionar un problema complejo. Es bastante probable que el código sea complicado porque los requerimientos de negocio tambien lo fueran. Asi que si realmente quieres mejorarlo, investiga como y porqué se hizo de esa forma.


Esta anotación es una traducción mas o menos libre del artículo Fix That Code Immediately! en JavaCodeGeeks.

Nos encantaría decir que en Virtual Software estamos ya en un punto como para dar lecciones sobre lo que se cuenta en este articulo: tests que cubren todo el código, líderes de conocimiento, refactorización inmediata del código, revisión por parte del equipo… En realidad, estamos iniciando el camino y siempre está bien tener un punto de referencia en el horizonte para conocer el objetivo. Esa es la motivación de esta anotación.

 

Relaciones en GORM (The definitive guide to Grails 2)

Tecnología

DefiniteGuideGrails2

 

Desde que comenzamos en Virtual con Grails, uno de los puntos donde estábamos un tanto inseguros era el tema de la forma en que se manejan las relaciones con GORM. Por una parte, nunca habíamos usado Hibernate ni ningun otro ORM, y por otro, siempre habíamos diseñado la base de datos y las relaciones entre las entidades de forma manual.

En estos dias de vacaciones estoy leyendo el (muy recomendable) libro “The Definitive Guide to Grails 2”, con el que estoy afianzando algunos conceptos que ya he manejado en el ultimo año y estoy aprendiendo algunas otras técnicas que estoy seguro de que me me van a ser muy utiles en el corto plazo.

En particular, el capítulo 3 dedicado a las clases de dominio tiene un apartado sobre las relaciones entre las clases de dominio y el mapeo que se realiza en base de datos que me ha resultado especialmente claro, asi que voy a intentar resumirlo y traducirlo por aqui por si a alguien mas le puede ser de utilidad.

Partamos de las dos siguiente clases simples:

class Car {
  Engine engine
}

class Engine {
  Car car
}

Claramente tenemos una relación one-to-one simple: un coche tiene un motor y un motor tiene un coche. Ninguna de las dos clases es propietaria de la relación. Y probablemente esto no sea lo que necesitemos en nuestra aplicacion.

Si queremos (lo mas probable en el caso anterior) definir cual es la clase propietaria de la relación, deberíamos hacerlo de la siguiente forma, definiendo explicitamente que un motor pertenece a un coche:

class Car {
  Engine engine
}
class Engine {
  static belongsTo = [car:Car]
}

De esta forma decimos a Grails que el coche es la parte propietaria de la relación, que el motor pertenece al coche, y no al revés.

El parámetro [car:Car] de la propiedad belongsTo es un mapa (y podríamos incluir varios valores: [car:Car, otherClass:TheOtherClass, ….]). La clave del mapa (car) representa el nombre de la propiedad que se añadirá (y usaremos luego para recuperar datos) a la clase Engine. Con esta definición, conseguiremos tambien que cuando se realice el mapeo en base de datos, tengamos una foreign-key en la tabla CAR que referencia a la clave primaria (el ID) de la tabla ENGINE

Obviamente, en algunos casos puede ser deseable tambien disponer de la foreign-key en el otro sentido, esto es: tener la foreign-key en la tabla ENGINE referenciando a la clave primaria de CAR. La forma de hacerlo en definiendo la propiedad hasOne en la clase Car, de la siguiente forma:

class Car {
   static hasOne = [engine: Engine]
}

En algunas circunstancias podemos tener situaciones donde la relacion necesita un lado propietario de la misma, pero no se necesita tener la referencia (back-reference: el ID del propietario en la clase debil de la relación). Grails soporta este tipo de relación de forma similar al caso anterior, pero indicanto solamente el nombre de la clase en lugar de usar una mapa:

class Engine {
   static belongsTo = Car
}

Una de las aplicaciones mas claras de esta aproximación es que automatizan los borrados en cascada: cada vez que se borra un coche de la base de datos se borrará el motor asociado.

Las relaciones de uno-a-muchos se representan facilmente tambien en Grails. Supongamos que tenemos una aplicacion con Albums de música que tienen canciones (Song) y que pertenecen a un Artista. La definicion de estas tres clases podría ser algo asi:

class Artist {
  String name
  static hasMany = [albums:Album]
}

class Album {
  String title
  static hasMany = [songs:Song]
  static belongsTo = [artist:Artist]
}

class Song {
  String title
  Integer duration
  static belongsTo = Album
}

En el ejemplo anterior, un Artist tiene muchos Albums, y un Album perteneca a su Artist propietario. De la misma forma, un Album tiene muchas canciones, y cada cancion tiene su Album propietario. En cualquier caso, una canción no tiene referencia a su Album: dada una canción no podremos saber a que Album pertence, aunque desde los Albumes si que podremos obtener su lista de canciones.

Como vemos, la clase Artist tiene una propiedad, albums, que es una coleccion de objetos Album. El tipo de coleccion que Grails usa por defecto en estos casos es un java.util.Set , que es una coleccion sin orden. Si necesitas otro tipo de coleccion (por ejemplo: List o SortedSet que mantienen un orden, lo que puede penalizar el rendimiento) puedes hacerlo pero tendrás que declararlo explícitamente, por ejemplo:

class Album {
  String title
  static hasMany = [songs:Song]
  static belongsTo = [artist:Artist]
  SortedSet songs
}

Nota: para que este comportamiento funcione, la clase Song tiene que implementar el interface Comparable

No voy a entrar en la problemática del rendimiento que puede provocar el uso de estas propiedades, pero si que recomiendo echar un vistazo a estas dos entradas ( 1 y 2) de Burt Beckwith sobre las recomendaciones de usar el concepto de Bag de Hibernate para estas relaciones u otro tipo de técnicas.

Solo un año

Sin categoría

En mi memoria parece muchísimo mas. Pero sólo ha pasado un año desde que por una de esas casualidades (y por escuchar los podcast de Javahispano) un compañero y yo fuimos a Spring IO, una serie de conferencias que a priori trataban sobre el framework de desarrollo Spring MVC.

En aquella época, yo estaba dándo vueltas sobre si merecia o no la pena el cambiar nuestro sistema de desarrollo tradicional y buscando cual podia ser la alternativa. En ratos libres habia echado un vistazo a Spring MVC y GWT,  así que como una de las conferencias era la clásica de Matt Raible sobre la comparativa de frameworks basados en Java en la que se hablaría de otras alternativas al J2EE mas tradicional, parecia claro que no deberiamos perdernos el evento.

Al final, como sucede muchas veces, te encuentras con que aquello para lo que estabas preparado no era lo mas interesante que sucedió en esos dias. La charla de Matt fue impecable pero no fue lo que mas nos marcó. Muchos de los ponentes hablaron sobre un entorno de desarrollo que no habia considerado y del que ni siquiera habia oido hablar, Grails, pero del que muchos de ellos (Tomas Lin, Domingo Suarez, ) hablaban maravillas. Tambien estuvieron implicados algunos de los (en aquel momento yo ni siquiera o sabia) máximos pesos pesados creadores del framework, como Graeme Rocher o Peter Ledbrook.

Pero no sólo (que hubiera sido mas que importante) descubrí Grails. Tambien nuevos conceptos como Agilismo o Scrum. Herramientas como las de Atlassian o JRebel. Empresas que estaban haciendo cosas que me llamaron la atencion, como Salenda, los vecinos de Kaleidos o gente como el propio Alvaro Sánchez-Mariscal, Alberto Vilches o el inimitable David Bonilla. Esos dos dias de hace un año, maltraduciendo del inglés, volaron mi mente. Tuve la sensación de haber pasado los ultimos 10 años metido en una caja. Si: mi propia caja, muy cómoda pero muy limitada. Y nuestra empresa, de la que soy el responsable de tecnología (CIO o CTO, dirían algunos), conmigo.

A partir de ese momento de hace casi exáctamente un año empezó el camino que estamos recorriendo hoy en Virtual Software y en que se esta involucrando toda la empresa para reinventarnos. Un camino hacia una estructura menos jerarquizada -que no menos organizada- con menos compartimentos estancos en lo referente a tecnologia y con la mirada puesta en el futuro.

Un año después estamos preparando a toda la empresa para que todos seamos capaces de realizar desarrollos con Grails. Hemos abrazado (seria mas realista decir “estamos abrazando”) el agilismo y estamos buscando la forma de incorporarlo a nuestros métodos de trabajo diarios. Tenemos nuestro propio scrum-master certificado. Hemos cambiado nuestra obsoleta herramienta de incidencias y control de tareas (desarrollada internamente y que nos ha servido durante unos cuantos años) por Jira + Greenhopper que nos permite tener un control mas certero de lo que realmente está pasando. Estamos  integrando en nuestro método de trabajo la Integracion Continua con Bamboo. Estamos aprendiendo TDD y la realización de tests con Spock o Geb. Ha sido un año duro y cansado, pero no me cabe ninguna duda de que está mereciendo la pena

 

2925491473_ce50a0bf7a-2

Este Kanji de arriba representa el concepto crisis en japonés. Esta compuesto de los sinogramas “Peligro” y “Oportunidad”. Nuestra empresa, como tantas en España, está pasando una época de crisis que, al menos en nuestro caso, ha sido motivada en gran medida porque algunos de nuestros clientes pertenecían a sectores que han sido golpeados fuertemente. No solo ese ha sido el motivo, y tenemos que buscar, reconocer y corregir nuestro errores. Pero creemos que estamos en el mejor momento para aprovechar la segunda parte: oportunidad, y darle la vuelta a nuestra empresa a todos los niveles para comenzar, 21 años despues, un nuevo camino.

 

(Esta anotación se publica tambien simultaneamente en mi blog personal, www.jmiguel.eu)

 

Hello world!

Sin categoría

Logo-casi-transparente-1024x565

 

Asi es. La primera anotación en el blog de Virtual Software. Sinceramente, aún no tengo muy claro que escribiremos por aqui, ni quienes escribiremos, pero despues de tantos años escribiendo en blogs personales ya iba siendo hora de tener uno para la empresa.

Sin duda uno de los motivos que hacen que ahora sea el momento es el hecho de que en la empresa, tras exáctamente 21 años funcionando, ahora estemos reinventándonos. Reinventarse o morir. Y claramente estamos por la primera opcion.

Como contaba hace unos meses en mi blog personal, desde hace alrededor de un año, en mi empresa nos dimos cuenta de estábamos fallando en unas cuantas cosas: el que una empresa de programación se quede estancada en cuanto a herramientas de desarrollo y control de proyectos no es desde luego nada bueno. Pero el que se quede fosilizada en cuanto a metodologias de programación y relación con el mundo tampoco es que fuera muy bueno.

Asi que tras unas cuantas lecturas teóricas, unos cuantos preparativos, y unas cuantas charlas despues, el otro dia dimos el primer paso para intentar introducir el agilismo en la empresa:

 

 

Creemos que es el primer paso para un futuro mejor. Asi que allá vamos. A aprender. Con humildad y ganas. Con fortaleza y sencillez