Hace unas semanas estuve en la edición 2007 de CaFeCONF, donde asistí a una muy buena presentación sobre desarrollo de juegos usando Python y Pygame. Afortunadamente los expositores la filmaron y publicaron en Google Video, así que hago mi parte en publicitarla, se las recomiendo!
October 29th, 2007
Anteayer sábado 5 de Junio se realizaron unas Jornadas Pythonescas organizadas por miembros del LUGLi, con ayuda de la UTN-FRSF y otros auspiciantes, incluida mi empresa LUNIX. El dictado de las charlas fue realizado por dos integrantes del grupo PyAR: Facundo Batista y Lucio Torre.
Desde mi humilde rinconcito de la blogósfera quiero felicitar a Juan José Conti, César Portela, Mariano Galán y su grupo de ayudantes, por un excelente trabajo en lo que es la organización de un evento que llenó las espectactivas de todos. Algo así es mucho trabajo, y ellos lo realizaron de manera espectacular.
No puedo también dejar de alegrarme por la buena disposición de la UTN para el armado de un evento de esta naturaleza, espero que se repitan mucho más así mostramos a los alumnos de ingeniería que no todo en la vida son los productor de Microsoft.
Actualización: Me han entregado fotos sacadas en el evento que acabo de publicar en mi galería, que las disfruten!
June 5th, 2006
Después de mucho tiempo, me puse este fin de semana a programar un poco, siguiendo la serie de mejoras de la consola PyGTK para Bacula, el servidor de backups libre que comenté hace unos días.
Estos días estuve trabajando en un feature esencial para la aceptación de la consola como herramienta útil: la capacidad de hacer un restore parcial, es decir… seleccionar archivos a restaurar de una lista de archivos que el director nos presenta.
La interfaz de consola de Bacula ofrece al usuario un pseudo-shell que permite navegar por una estructura de directorios, y marcar los archivos o directorios seleccionados para la restauración. Al principio cuando pensaba como encarar esto, me complicaba con difíciles estructuras de árbol que se suponía que debía mantener, y por eso me estaba tardando mucho en el diseño de esta parte del programa. Finalmente deseché esa idea y lo que decidí hacer es simplemente simular el comportamiento de un operador, armando métodos de cambio de directorio y pedido de listado. No guardo en ningún sitio estas estructuras complicadas, ¿para qué? si el Bacula se encarga de eso! una buena auto-lección de programación… Keep It Simple, Stupid
Quedan cosas a completar, como por ejemplo…una columna para seleccionar los archivos! je, je…bueno pero lo que estoy mostrando es lo más complicado, el resto viene casi solo.
February 13th, 2006
Para estrenar este nuevo año, les cuento del proyecto en el que estoy más activo estas últimas semanas. Hace tiempo que vengo buscando una realmente buena solución para el problema de las copias de respaldo, a.k.a.: backups.
Hace unos cuantos meses me topé (ya ni me acuerdo cómo) con Bacula, un software cliente-servidor realizar copias de respaldo que ya tiene un buen tiempo de desarrollo y su estado es muy avanzado.
El problema de los backups es bastante complejo si se lo quiere hacer de manera seria, y es por eso que manejar un software serio de backup no es algo simple. Bacula tiene varios componentes, programas que corren de manera separada y que hacen distintas tareas:
- Bacula Director (el servidor)
- Bacula File Daemon (el cliente)
- Bacula Storage Daemon (el que maneja el dispositivo de almacenamiento: cinta, disco, etc.)
- Bacula Console (consola de administración)
Cada componente se comunica con los demás a través de un protocolo de red, por lo que pueden estar corriendo en la misma máquina o en distintas, siempre y cuando tengan conectividad entre ellos.
Hace ya un par de meses comencé a moverme para hacer una consola de administración que sea gráfica, el proyecto tiene una consola de texto y dos prototipos de consolas gráficas (una hecha con las gnome-libs y otra con wx-widgets), pero todas están programadas en C++, lenguaje que prefiero evitar a toda costa. Mi idea es programar una interfaz gráfica usando Python y PyGTK+, los bindings de GTK+ para Python.
Kern Sibbald es la persona que comenzó y mantiene el proyecto. Kern fue uno de los fundadores de Autodesk, algo que me sorprendió descubrir hace relativamente poco, y es una persona extremadamente ordenada y correcta en su manera de llevar adelante el proyecto, sólo basta con leer un poco la lista bacula-devel para darnos cuenta. Hace como dos meses me puse en contacto con él para comentarle mi idea y me contestó enseguida diciendome que alguien más de Argentina estaba queriendo hacer lo mismo, y que ese alguien se llama Roberto Alsina, un amigo de Santa Fe que hace unos cuantos años se fue a Buenos Aires.
Me puse en contacto enseguida con Roberto y me comentó que estaba en la etapa de generar el binding entre las bibliotecas de bacula y Python, de manera de tener acceso desde Python a las funciones de alto nivel del protocolo de Bacula, y que su idea era utilizar Pyrex, un lenguaje muy similar a Python para generar bindings desde C hacia Python. En ese tiempo Roberto andaba con poco tiempo para ponerse así que me pasó algunos archivos que Kern le había escrito a modo de inicio de la idea, un set de pocas funciones indispensables para armar una consola, así que con eso me puse manos a la obra pero pronto vi que Pyrex no funciona (al menos no por ahora) del todo bien con C++ (casi todo Bacula está hecho en C++) así que me puse a buscar alternativas.
Después de leer un poco, me encontré con SWIG, que si bien no es una solución tan divertida como Pyrex, funciona muy bien con C++ y lo buenísimo es que exporta a varios lenguajes además de Python, muy interesante! Me puse a armar el archivo de interfaz entre C++ y Python y comencé las pruebas escribiendo una consola de texto mínima en Python que finalmente me tomó menos de 100 líneas, con comentarios incluídos…Python es una hermosura
Mandé aviso a Kern de los avances y se mostró muy entusiasmado, así que empecé a armar un esqueleto MVC (usando el módulo pygtkmvc) y migré mi consola de texto a una ventana gráfica de PyGTK. Luego fui agregandole cosas en la forma de lo que yo llamo programación evolutiva, pero siguiendo lo más estrictamente posible los patrones de Modelo-Vista-Controlador y Observer.
A medida que le iba mandando las novedades a Kern y el resto de los developers de Bacula en la lista, la gente se mostró cada vez mas entusiasmada, parece que hay una gran necesidad de algo amigable para manejar el excelente Bacula, tanto así que cuando Kern organizó una votación para ver cuales sub-proyectos pendientes deberían tener mayor prioridad, la GUI en Python recibió el 4to. lugar entre 25 candidatos! así que Kern me hizo un lugarcito en su repositorio CVS y ahi me mudé (estaba trabajando con SVN en mi server, snif!) inmediatamente.

Una de las mas fieras barreras que me encontré fue el tema de la sincronía que el software debía tener con el server del otro lado de la conexión. Al ser un programa single-threaded, si enviaba un comando al server y quedaba esperando respuesta, el resto de la interfaz quedaría congelada hasta que se recupere el control cuando la respuesta llegue. Esto era algo inadmisible ya que hay muchos comandos en Bacula que tardan varios segundos en llegar su respuesta…más aún cuando el servidor está en algún lugar remoto de Internet. Para resolver esto, primero comencé a ver los módulos de threading que trae Python en su distribución oficial y ya imaginaba el nivel de complejidad como iba aumentando de repente, hasta que un comentario de Kern me hizo cambiar de rumbo, hay una manera de registrar un callback en un file descriptor (como lo es una conexión de red, un archivo, etc.) de manera que sea ejecutado cuando algún evento suceda en ese file descriptor. Así que sabiendo esto, me armé un esquema de encolamiento de mensajes (una conexión soporta un sólo mensaje a la vez) con un sistema de callbacks y de este modo la consola gráfica no queda congelada esperando un comando. Me queda pendiente la gestión de la cola en el caso que un comando se esté tardando demasiado tiempo en responder y comandos automáticos (por ej: actualización de datos) se empiecen a encolar sin control.
Para no hacerla mas larga, estoy programando algo totalmente nuevo, un proyecto enteramente (bueno… un 99,99%) en Python, con los patrones MVC+Observer, usando mi toolkit gráfico favorito, en un proyecto que tiene 5 años de vida y una comunidad de usuarios y desarrolladores muy madura, en fin! una muy buena experiencia! 
January 1st, 2006
Entre el pasado domingo y anoche me la pasé con amigos linuxeros de Capital Federal, muchos de ellos debianitas. Tuve una grata sorpresa cuando al ver que Debian Sarge pasaba finalmente a estable, me dijeron que mi humilde paquetito de software se encontraba ahí!! emociones aparte, nunca pensé que lo vayan a dejar, al fin de cuentas…es la versión 0.3.6
En fin…ahora GWP 0.3.6 se mantendrá disponible al público durante aproximadamente 18 meses!! mientras deberé hacer backports para Sarge mientras mi querido proyecto avanza, así no dejo en pelotas a mis fanáticos usuarios (mmmh, ¿los habrá?).
Pero basta de quejarme…mi laburo de tanto tiempo está finalmente disponible para miles de usuarios de Software Libre, eso me llena de satisfacción…aunque a casi nadie le sirva 
June 9th, 2005