JRebel Yell

Hace cosa de un mes y pico me preguntaron en el chollo si habíamos usado JRebel para desarrollar portlets en Liferay. ¿Jotaqué? ... Y me puse a buscar en el google qué era eso. 

Resulta que JRebel es un agente Java que evita despliegues en servidores de aplicaciones Java porque permite sustituír código en caliente en toda una manada de servidores de aplicaciones como Tomcat, Jboss, WAS, Jetty, Resin, Netweaver, etc. Y tiene plugins para una buena parte de los grandes IDE para Java: Eclipse, Netbeans, InteliJ, JDeveloper, ... 

Soy un asiduo seguidor de Eclipse, y seguro que, como yo, muchos nos hemos encontrado con las limitaciones en el reemplazo de código en caliente que obliga a redesplegar las aplicaciones en el contenedor una y otra vez. Cambiar el cuerpo de método estático, añadir un método, definir una constante, modificar el contexto de Spring, ... nunca más!! JRebel al rescate!! ... o no...

JRebel es una buena herramienta con una gran campaña de marketing. ¿Marketing? Si, porque es de PAGO. Y en mayúsculas.  Desde la licencia standalone por 130$/año y usuario hasta la flotante con servidor de licencias por 350$/año y usuario. Sí, es cara. 

Pero ellos lo argumentan diciendo que te puedes ahorrar 10 minutos de despliegues por cada hora de desarrollo. 

Todo su marketing se enfoca en esto. 

Y yo no me lo acababa de creer, así que me registré en una trial de un mes y empecé a usarlo para desarrollar portlets en Liferay. Instalé el plugin de JRebel en Eclipse, añadí el plugin de maven al pom.xml , configuré el agente en el Tomcat y empecé a usarlo. 

La primera impresión fue genial. Magia. Pillaba los cambios. Así de fácil.Yo cambiaba una clase o una JSP de mi portlet y los cambios aparecían al segundo. Genial. Flipa. OyeManelmiraesto. Nomoredeploys.

El entusiasmo sólo dura un par de horas, y los defectos empiezan a notarse. Liferay tarda como el doble en arrancar. Y se ha vuelvo más gordo y lento.

El primer portlet de prueba era muy básico, pero los proyectos que solemos hacer -normalmente basados en Maven- suelen tener varios módulos con varias librerías, y los cambios sólo se aplicaban si se hacían en el proyecto web. Los cambios en superclases o interfaces tampoco funcionan. Y clases nuevas sólo se detectaban a veces. Evidentemente no funciona con SWT. Ni tampoco con GWT.

A su favor, sí que se detectan los cambios en las JSP e incluso en el contexto de Spring. Tiene plugins también para Hibernate y JSF - que no he probado - . 

El plugin se encarga de recordarte un par de veces al día todo el tiempo que has ahorrado en despliegues contabilizando como despliegue cada guardado de un fichero con el servidor levantado. Y sí, en efecto, en una jornada puede contabilizar dos o tres horas. Pero me parece algo exagerado contarlos todos. Sobre todo teniendo en cuenta que hay días que no hago ni un solo despliegue. Sólo programar.

¿Que se evitan despliegues? Pues claro. Es un ahorro considerable de tiempo. Pero no siempre estamos haciendo corrección de bugs, con lo que las fases de despliegue continuado no son la tónica general. 

Ya terminó la trial y hoy me llamó un comercial que me puso en un serio aprieto con mis habilidades con el inglés. Sorprendente que me llamasen, si. Y por eso estoy escribiendo esto. 

Se lo merecen, tienen un buen producto. Aunque no creo que mi empresa lo vaya a comprar. Como puse en el correo que mandé hace un par de semanas a la persona que me preguntó sobre él:

Es una herramienta ÚTIL, PRÁCTICA, especialmente indicada para programadores productivos para los que los despliegues en el servidor suponen una rotura de un ritmo de trabajo alto. Utilizarla requiere EXPERIENCIA en desarrollo para darse cuenta rápidamente de cuándo está desplegando automáticamente y cuándo no. Puede suponer una mejora notable en la productividad de ciertos programadores en determinados tipos de desarrollos. 

Y es CARA, cuesta 349 euros por año y programador para entornos empresariales. ¿Vale la pena ese coste para hacerlo extensible a todos los programadores? No lo creo, sobre todo teniendo en cuenta que hay otros factores como un mejor equipo informático o un monitor más grande que mejorarían en mayor medida la productividad de los programadores y que tienen un coste similar o menor.Eso si, hay una versión SOCIAL no válida para uso comercial y que yo tengo instalado en el Eclipse del equipo de mi casa.