bitácora de uno

Parte de las labores en el departamento de I+D en el que desarrollamos Osmius son las de decidir hacia dónde vamos.

En nuestro caso trato de plantearlo, de forma profunda y sin permitir tabúes, al menos una vez al año. La idea es no casarnos con nosotros mismos y tampoco con ninguna tecnología, o dicho de otro modo dejar que surjan dudas y luego intentar resolverlas con argumentos.

Algunas preguntas tipo que nos hacemos son:

• ¿Tenemos que cambiar profundamente alguna parte del desarrollo?
• ¿Debemos orientarnos hacia el Software como Servicio?

Pero de igual manera trato también de que nos replanteemos la tecnología que utilizamos y no sólo el roadmap de producto, aunque es verdad que en el desarrollo de software están bastante relacionados.

En una de éstas me di cuenta de que el desarrollo de la parte Web de Osmius, era lento, pesado, poco ágil y no por la gente de equipo sino porque es algo farragoso, editando 15 xmls para hacer una pantalla de mantenimiento de toda la vida y otras lindezas imperdonables. Un salto atrás en el tiempo si pensamos que con Visual Basic 3.0 ya era fácil desarrollar pantallas hace tropocientos años (unos 10, que en TI representan eones).

En éstas contacté con Álvaro y Nacho de Escuela Groovy para que primero nos convencieran razonando para utilizar Grails y Groovy y, segundo, para contratarles un curso que nos sirviera de comienzo. Finalmente hicimos el curso y estamos trabajando para aprender e incorporar la tecnología a nuestros desarrollos.

La razones de la elección se apuntan en las siguientes líneas:

El Producto: Osmius es un software de Monitorización de Sistemas y Servicios que tiene componentes:

• Procesos del “core” para monitorizar a toda velocidad y con poca carga -> C++
• Consola Web Java + Spring + Hibernate + JQuery + Spring Security con más de 50 pantallas y Web Services.
• Más 130 tablas en el Modelo de Datos.
• Metodología de trabajo Scrum

Necesidades a cubrir:

• Aunar la agilidad que ya disfrutamos en la metodología con el desarrollo.
• Peticiones de los usuarios: Más rápido, J2EE es muuuuyyyy lento.
• Actualizar a los Dinosaurios (equipo C++) y a los Cromagnones (equipo Java)

Grails y Groovy porque:

• La sintaxis de groovy no es extraña para Dinosaurios ni Cromañones.
• Podemos integrar Scripts de groovy en la monitorización (cuando el rendimiento salvaje no sea un problema).
• Reutilizamos conocimiento de Cromagnones: Spring, Hibernate, etc.
• El rendimiento no nos preocupa porque el core es C++ y tenemos muy optimizadas las sentencias a BBDD.

Curiosidades:

• Cromagnones: Están encantados, sobretodo con no tener que tocar quince XMLS cada vez.
• Dinosaurios: Están horrorizados. “El desarrollo Web es un infierno” (Vienen de Visual Basic: Arrastro control, click, código).

Ahora estamos dos del equipo en el evento sobre Spring y Grails en Madrid 2010: Spring2GXDay

El año que viene volveremos a ponernos en duda. Ya os contaré. ¿Roo, quizás? (No creo)