Categoría: Devel

Google Gadgets para Linux

Desde que Google publicó Google Desktop para Linux, la compañía de Mountain View ha ido desarrollando casi todas las características y funcionalidades que no estaban en la versión de nuestro sistema operativo originalmente, como el soporte de 64 bits o la posibilidad de buscar aplicaciones y documentos. Casi todas, digo, porque faltaba una importante excepción: Desktop Gadgets. El soporte de gadgets no es sólo una única funcionalidad, sino más bien una completa plataforma para soporte de mini-aplicaciones. Pues bien, Google acaba de publicar una versión beta de Google Gadgets para Linux, incluyendo el código fuente . Échale un vistazo y cuéntanos qué tal te va: hay versión GTK+ y versión QT.

Signos vitales de un proyecto software

Estoy leyendo el libro «The ThoughtWorks Anthology» dentro de la colección «The Pragmatic Programmer». Son ensayos sobre tecnologías y metodologías software de autores conocidos en el mundo de la ingeniería software (Martin Fowler, por ejemplo). Aunque algunos ensayos son duros de tragar, otros me han parecido muy interesantes de cara a la gestión de proyectos software, en especial el capítulo 8, que lleva como título «Project Vital Signs» de Stelios Pantazopoulos. Comienza diciendo : «En el campo de la medicina, un doctor o enfermera puede entra en la habitación de un enfermo, mirar la gráfica del paciente y hacerse una idea rápida y general del estado y signos vitales de dicho paciente. Con esa información a mano, el médico puede formarse rápidamente una idea sobre el estado de salid del paciente y decidir si es necesario tomar alguna acción correctiva. ¿No sería genial que existieran gráficas de ese estilo para un proyecto de desarrollo software, de tal forma que, de un vistazo nos permitieran hacernos una idea rápida de los signos vitales del mismo?» Eso es precisamente lo que el capítulo desarrolla a partir de ahí. Nos propone 5 gráficas a modo de «information radiators». Es un término acuñado por Alistair Cockburn (justo cuando estaba visitando una oficina de ThoughtWorks, la empresa de M. Fowler para la que trabajan el resto de autores del libro) para nombrar aquellas gráficas que, puestas en grande para que sean visibles por cualquier miembro del equipo, informen de los signos vitales del mismo. A partir de esos signos vitales podremos deducir el estado del proyecto. Esas gráficas se pueden dibujar sobre pizarras dentro de la sala de desarrollo o construir a través de post-its y enormes cartulinas como fondo; el estado de las graicas será actualizado por todos los miembros del proyecto (algunas sólo por ciertos roles y otras por otros). Un ejemplo para aclarar todo ésto: la gráfica «Scope burn-up»:


Es una gráfica donde vemos mucha información, muchos signos vitales del proyecto. En concreto, por cada iteración vemos:
* El número de historias de usuario sin desarrollar
* El número de historias desarrolladas pero que no han pasado aún los test de calidad
* El número de historias desarrolladas que ya han pasado los test de calidad
* La fecha en la que se pretende completar el desarrollo de todas las historias de usuario
* La fecha en la que se pretende tener validadas por control de calidad todas las historias de usuario
* Deadline
Como he dicho, la gráfica muestra los puntos anteriores por cada iteración, y además, la pendiente de cada curva (amarilla, roja, verde), nos da una idea rápida de si vamos bien o mal (si llegaremos a las fechas planificadas a tiempo o no).

Aparte del «scope burn-up chart» hay otras cuatro gráficas distintas que permiten tomar otras medidas de signos vitales (calidad de los entregables, control presupuestario, estado actual de implementación y percepción del estado del proyecto por los miembros del equipo). Lo dicho, un capítulo muy interesante y práctico para todo aquel que quiera desarrollar y gestionar proyectos software y no se conforme con los artefactos clásicos… dentro de un libro muy recomendable.

HackIt! Nivel 11: backtracking

Después del dolor del nivel 10 (un nivel genial no quita que no pueda ser doloroso 😉 llegamos al nivel 11 un tanto «acongojados», porque asumimos que, como la dificultad vaya en aumento, nos pueden dar las uvas.

Sin embargo, tras leer el enunciado, yo creo que este nivel no debería de haber ocupado el puesto número 11, sino alguno inferior, pues es resoluble incluso por «fuerza bruta visual», es decir, cogemos lápiz, cogemos papel y se puede resolver (no es trivial, pero se puede hacer con algo de tiempo y paciencia). Pero me estoy adelantando; la prueba pide que, en el siguiente tablero, encontremos un camino tal que el número de baldosas de cada color que atravesemos sea el mismo. Por ejemplo, 2 verdes, 2 azules y dos amarillas. El blanco no cuenta (casillas inicial y final). Se sobreentiende que no se puede pisar 2 veces la misma casilla (no lo dice el enunciado pero es una asunción que hago):

Aquellos de vosotros que habéis estudiado algoritmos de backtracking en el pasado (y os acordáis de algo 😉 me imagino que os estaréis frotando las manos, porque efectivamente, es resoluble por backtracking. Por cierto, cómo cambia la carrera de informática… hoy en día, en mi facultad, la asignatura de «Estructuras de datos y algoritmos» en Ingenieros Técnicos en Informática (que por cierto me tocó impartir este año), no se incluía la parte de backtracking por distintas cuestiones que mejor me ahorro comentar (y no son todas por «culpa de los profesores»). No me parece bien. Así que, el año que viene (y si los hados me designan a Donostia otra vez) pienso dar la tabarra hasta que encaje, como antaño, esta parte de la asignatura en el temario. Tal vez tenga que pedir también que nos pongan una máquina de café más cerca del aula… 😉

Ahora que estamos en temporada de exámenes, sé que cualquier excusa es buena para dejar de estudiar (como dice mi blog-colega txipi, «incluso os enrolaríais en un carguero uzbeko» con tal de no hincar los codos 😉 …. esta prueba de HackIt tiene su cosita: es probable que aprendáis (aprender de verdad) más de recursividad y algoritmos de backtracking resolviéndola por vuestra cuenta que estudiando la teoría correspondiente. Os pasaré mi propuesta de solución en Java en unos días… aunque ahora que lo pienso, igual la guardo como ejercicio para el año que viene };-)

Assembla: mantén tus proyectos software bajo control

Los proyectos fin de carrera son una buena oportunidad para lanzar ideas que siempre has querido ver implementadas pero nunca has sacado tiempo para llevarlas a cabo por tu cuenta. Algunas de ellas terminan en el cajón de sastre (desastre 😉 , pero otras adquieren una dimensión mayor de la que preveías inicialmente. Es sobre uno de éstos últimos proyectos sobre lo que quiero hablar en este post. Un gran PFC que tiene como objetivo implantar un sistema para la gestión integral del desarrollo de proyectos software (la frase parece un bluf comercial, pero, IMHO, no lo es). Todo empezó cuando conocí Assembla.com, una espectular aplicación realizada sobre Ruby on Rails (con algunas partes en Python) que ofrece espacios de trabajo para los desarrolladores software, con soporte Subversion, Trac, blog, wiki, gestión de bugs y tickets (aparte de Trac), gestión de usuarios, múltiples proyectos, repositorio para documentación, git, Mercurial, time-tracking, anotación de imágenes, chat, alertas… y atención, para proyectos de desarrollo e investigación (sin ánimo de lucro), todo ello de forma gratuita (siempre que no te pases de 500MB de ocupación y algún detalle más que aún no he sufrido). En cualquier caso, si tuviera que desarrollar aplicaciones con ánimo de lucro no tendría ninguna duda en contratar los servicios de Assembla, pues hasta ahora, me ha funcionado a la perfección.

Pero, ¿dónde está el PFC? 🙂 En que Assembla distribuye el código fuente de toda su infraestructura bajo el nombre en clave Breakout. Eso sí, hay que tener en cuenta que 1) la documentación está obsoleta y 2) la construcción de Breakout es un infierno de dependencias. Una vez compilado, configurado y probado, dispondrás de los mismos servicios que ofrece Assembla, pero en local (aplicando misma condición de uso: gratuito para proyectos sin ánimo de lucro). La idea del PFC consiste en documentar el proceso de compilación, instalación y configuración de Breakout, integrarlo con el sistema LDAP de la UPV/EHU y abrir el servidor a los PFC sin ánimo de lucro de los alumnos de la Facultad de Informática: con 3 clicks de ratón cada PFC dispondrá de toda la infraestructura mencionada en el párrafo anterior. ¿Alguien dá más?

No sé si llegaremos a tiempo para dejar pulido el proyecto para junio… tal vez para obtener todos los resultados esperados, haya que trabajar un poco más en verano y presentarlo en septiembre. Lo sabremos en menos de 15 días.