Durante la última semana he estado trabajando en una tienda virtual basada en Satchmo. Satchmo es un framework para la creación de tiendas virtuales web, y que está basado a su vez en Django.

Hasta hace muy poco tiempo, preparar un entorno de desarrollo y un proyecto mínimo basado en Satchmo era una tarea titánica, que llevaba horas llenas de frustración y sufrimiento, durante las cuales la vida llegaba a no tener sentido y…en fin, ya me entendeis.

La situación ha cambiado radicalmente con la versión 0.9, liberada el pasado Octubre. Con esta nueva versión, la instalación de Satchmo se ha simplificado enormemente y la documentación ha mejorado notablemente. Todo esto ha hecho que, al menos en Ubuntu, la instalación se haya convertido en un simple proceso de 15 minutos, desde el comienzo hasta que puedes ver funcionando el proyecto mínimo para comenzar el desarrollo.

A continuación, y siguiendo con la vocación de servicio publico de este blog, detallaré los pasos para instalar un entorno de desarrollo con Satchmo. Las siguientes instrucciones se basan en Ubuntu, y han sido probadas en una máquina virtual con Ubuntu 8.04.3 LTS.

Coged papel y lápiz. Os espero.

El primer paso es instalar los paquetes necesarios para la instalación de Satchmo y todas sus dependencias.

sudo apt-get install python-setuptools python-dev build-essential python-imaging mercurial

A continuación instalaremos pip, virtualenv, virtualenvwrapper y crearemos un virtualenv para nuestro entorno de desarrollo.

sudo easy_install pip
sudo pip install virtualenv
sudo pip install virtualenvwrapper
mkdir ~/.virtualenvs
source /usr/bin/virtualenvwrapper_bashrc
mkvirtualenv satchmo


Añade la linea source /usr/bin/virtualenvwrapper_bashrc a tu .bashrc para tener virtualenvwrapper la próxima vez que te logees.

Si no conoces pip, virtualenv o virtualenvwrapper, te invito a que antes de seguir descubras que son, como funcionan, que ventajas ofrecen y por que son lo mejor desde el arroz con leche, en los siguientes articulos. Otros ya lo han explicado mejor de lo que yo lo haría.

• Entorns de treball virtuals per Python
• Working with virtualenv
• Why I like pip

Esperaré aquí hasta que acabes. En serio.

Por último, solo queda instalar las dependencias y finalmente Satchmo.

pip install -r http://bitbucket.org/chris1610/satchmo/raw/tip/scripts/requirements.txt
pip install -e hg+http://bitbucket.org/chris1610/satchmo/#egg=satchmo

Una vez terminado, solo resta crear un proyecto mínimo sobre el que comenzar a trabajar. Satchmo ya viene con un script que hace precisamente eso.

clonesatchmo.py --skel=/home/juan/.virtualenvs/satchmo/src/satchmo/satchmo/projects/skeleton

Por defecto, creará un proyecto llamado store en el directorio en el que te encuentres.

Ahora solo queda arrancar el servidor de desarrollo de Django para probar la tienda.

cd store
python manage.py runserver

Seguro que has tardado menos de 15 minutos.

Imagen © jamesjustin Some Rights Reserved.

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.