morenosan

Después de bastante tiempo programando únicamente en Python y Django, hace año y medio cambié de trabajo. Desde entonces he vuelto a programar en Java, desarrollando aplicaciones y servicios web, así como coordinando a un equipo de programadores web.

Pronto me di cuenta de que el equipo seguía el siguiente ciclo a la hora de desarrollar:

• Hacer cambio.
• Compilar un WAR.
• Copiar el WAR al servidor Tomcat local.
• Reiniciar el servidor.
• Iniciar una sesión de debug desde Eclipse.
• Probar.

Esto hacia que cada prueba supusiera, en el mejor de los casos, esperar 5 minutos desde que se hacia un cambio hasta que este se podía probar. Lo cual nos dejaba con una productividad, digamos que mejorable.

Desde entonces, hemos mejorado el entorno de desarrollo, de forma que ahora podemos modificar el código fuente Java en caliente e inmediatamente ver y depurar los cambios, sin necesidad de recompilar y recargar toda la aplicación, consiguiendo un flujo de trabajo más parecido al de Django o PHP.

El "secreto" (entre comillas, por que está más que descubierto) se basa en tener el servidor de aplicaciones empotrado, de modo que este pueda arrancarse como un programa Java en modo debug, desde Eclipse. De esta manera conseguimos que desarrollar una aplicación web sea, a efectos del flujo de trabajo, como programar una aplicación Java "local", pudiendo aprovechar toda las herramientas que pone a nuestra disposición el IDE, como la compilación automática y el cambio en caliente del las clases compiladas.

Las únicas limitaciones del cambio en caliente son las propias de la especificación JPDA. Esto es, la actualización en caliente solo funciona mientras se modifique el cuerpo de las funciones. Cualquier modificación en los parámetros de un método o en la definición de una clase nos obligará a reiniciar el servidor (aunque no tendremos que recompilar nada).

En la actualidad, usamos como servidor empotrado Jetty, a través del plugin de Eclipse run-jetty-run.

A la hora de usar Run-Jetty-Run tuvimos que resolver 2 problemas:

• El plugin no soporta JNDI de serie, aunque aplicando este pequeño parche se soluciona.
• A los usuarios de Windows, Jetty les bloqueaba los ficheros estáticos (por ejemplo css o javascript) de modo que no podían modificaros mientras el servidor estuviera en marcha (gran problema). Quedó solucionado siguiendo las instrucciones de este ticket.

Únicamente en un proyecto, de características muy especiales, Jetty no fue capaz de ejecutar una aplicación. En este caso, tuvimos que usar un Tomcat empotrado. Gracias al código fuente y las instrucciones de un artículo en onJava, no tuvimos ningún problema en ejecutar un Tomcat desde Eclipse, consiguiendo el mismo efecto que con Jetty.

¿Por que usamos Jetty en lugar de Tomcat? Principalmente por que run-jetty-run es más fácil de configurar y está muy bien integrado con Eclipse. Ademas Jetty arranca casi de inmediato.

Si tu flujo de desarrollo en Java se parece al que he descrito al inicio de esta entrada, te aseguro que vale la pena que inviertas algo de tiempo en mejorarlo. No es difícil, y los beneficios son considerables.

Imagen © Extra Medium Some Rights Reserved.

En el 2004 compré una cámara de vídeo digital de esas que utilizan como almacenamiento DVDs regrabables de 8 centímetros. La mía en concreto es la Hitachi DZ-MV580.

En la tienda había visto como con el software de Windows que venia con la cámara, era posible separar los capítulos de vídeo que te interesaban, de modo que pudieras incluir en tu DVD de las vacaciones en la nieve la escena en la que bajas esquiando como un campeón, pero no aquella otra en la que te estampas contra la clase de esquí de un grupo de la tercera edad.

Así que después de llenar mi primer disco, me senté frente al ordenador, confiado de que mi Linux tendría todas las herramientas para procesar el vídeo grabado y realizar DVDs con los que deleitar (o torturar) a mi familia y amigos.

Pero mi sorpresa fue mayúscula al comprobar que los discos se grababan en un formato especial de DVD, llamado DVD-VR, que define el formato lógico de grabación de vídeo en soporte DVD. Mientras el formato utilizado para guardar el vídeo, el archivo VR_MOVIE.VRO del disco, es MPEG2 estándar, el mismo utilizado por los DVDs de toda la vida, la información sobre los capítulos y fecha de grabación, el infame fichero VR_MANGR.IFO, se almacena en un formato que ningún software open source de la época entendía.

Eventualmente encontré un método, algo laborioso, que permite separar los capítulos pero que implica separar las pista de audio y vídeo para volverlas a multiplexar de nuevo. Esto hacía que muchas veces acabase con el vídeo y el audio desincronizados, ademas de con distorsiones entre los capítulos. Así que, aunque imperfectos, acabé creando DVDs con los que deleité (y torturé) a familiares y amigos.

Aun así, de cada disco que grababa, guardaba una copia con la certeza de que algún día algún programador con mi mismo problema, pero con más talento, escribiría el software que permitiera dividir los vídeos en capítulos tal y como lo había visto hacer con el software de Windows.

Y por fin, tras tres años, hace unos días descubrí que ese programa ya existe. Su nombre es dvd-vr (elemental) y permite dividir un disco DVD- VR en capítulos automáticamente y sin errores, así como mostrar diversa información del disco. Su primera versión es de Febrero del 2007 y su creador es Pádraig Brady.

Cuento esto, primero como servicio publico, ya que mi experiencia podría servirle a otros usuarios de Linux con cámaras DVD, pero también como un ejemplo, otro más, de la capacidad que tiene el software libre de resolver problemas reales y concretos de sus usuarios (el famoso "scratch an itch"), aunque sean tan pequeños como el de dividir en capítulos tus películas caseras.

Imagen © steve-o71. Some Rights Reserved.