Planet

He aprovechado hoy para hacer un vídeo demostrativo del funcionamiento de mi proyecto para ayudar a los evaluadores. Soy consciente de que, debido al estado de desarrollo actual, muchas de las herramientas que permiten utilizar de forma sencilla mi proyecto aún no están hechas, por lo que he pensado que sería un buen material de apoyo.Enlace al vídeo en más calidadflowplayer("argos", "http://arco.esi.uclm.es/flowplayer/flowplayer-3.1.5.swf", { clip: { autoPlay: false, autoBuffering: true } });En el transcurso del vídeo, primero se observa el canal de anunciamientos, dónde tanto un sumidero como una fuente están enviando sus mensajes de anuncio.Tras ello, se utiliza la propia herramienta como sumidero de vídeo para conectarse con la fuente que está funcionando. Por último, el vídeo muestra como conectar la fuente a otro sumidero, que se está ejecutando en la misma máquina, representando el flujo de vídeo en una ventana independiente.En el vídeo se puede observar que se utiliza una herramienta gráfica, llamada Twinpanel, para inspeccionar el canal de eventos y como sumidero multimedia. Esta herramienta ha sido fruto de varios años de trabajo de varios miembros del laboratorio ARCO entre los que me incluyo.

Justo para la evaluación del concurso ha llegado la primera versión del "configurador" de flujos de Argos. Desde luego, no es ni mucho menos lo que espero que llegue a ser (por ahora solo es un programa en terminal), pero es el primer paso.El programa permite, dados los proxies de dos objetos MMDevice (un "source" y un "sink", como por ejemplo el Media Server y el Media Render), que ambos se conecten y tener el objeto de control de dicho flujo fuera de ambos extremos...Aunque bueno, quizá me he metido a detalles muy "profundos". Espero que, si me seleccionan para la fase final, pueda llevar algo menos "tedioso" de utilizar que esta primera aproximación para poder realizar una demo "in situ" en condiciones.P.S. Mañana es la evaluación de los proyectos en el concurso de Castilla-la Mancha. ¡Deseadme suerte!

aunque se me ha olvidado comentarlo, de forma paralela al desarrollo del Media Server se ha realizado el del Media Render.Las diferencias entre ambos son pocas, ya que según el estándar de OMG AVStreams que estoy utilizando, los dos extremos de un flujo tienen las mismas interfaces y, a grandes rasgos, se comportan de forma muy parecida.Para el Media Render una de las cosas que he debido tener en cuenta ha sido, ante todo, la posibilidad de tener diferentes "Renderers" que hagan diferentes cosas (representar el vídeo, guardar a fichero...).Por ahora he implementado un Media Render que utiliza Gstreamer para representar el flujo recibido, pero he dotado al sistema de una especie de sistemas de plugins (usando el patrón factory method) para tener más fácil el desarrollo futuro de otros Media Renders diferentes.Otra cosa a tener muy en cuenta es el tema de despliegue; en la entrada anterior comenté que el despliegue del Media Server lo realizo gracias a IceGrid y IceGrid-Gui. Por desgracia, el MediaRender es muy dependiente del usuario que lo ejecuta, por lo que la automatización de la puesta en marcha del Media Render habrá que estudiarla un poco más despacio.

Como ya comenté hace algunas entradas, gracias a mi trabajo descubrí algunas herramientas avanzadas de Ice. Entre ellas está IceGrid, que permite realizar despliegues de aplicaciones de una forma sencilla. Además, aporta transparencia de localización y la activación automática de servidores.Gracias a IceGrid, el Media Server se puede lanzar en un nodo del sistema, configurándolo todo de forma remota desde el editor gráfico Icegrid-Gui.IceGrid además permite tener plantillas para las aplicaciones, por lo que he podido definir un servicio IceBox para mi Media Server configurable a través de unos pocos parámetros, lo que permite su rápido despliegue en cualquier entorno.

Desde hace un tiempo estoy probando la  beta de Ubuntu Lucid, y aunque por lo general parece que está bien, hay un detalle estético que me molesta bastante. Después de tantos años usando GNOME me había acostumbrado a que los expansores fuesen un pequeño triángulo tal que así y así , sin embargo en esta última versión los han cambiado por éste y éste otro , que además de feos son más grandes.En principio esto que comento no parece grave, pero la diferencia entre ambos es en algunos casos brutal. Por poner un ejemplo, en la vista Package Explorer de Eclipse:El responsable de este comportamiento es la versión del paquete gtk2-engines-murrine que se distribuye en Ubuntu Lucid (al día de hoy la 0.90.3+git20100323-0ubuntu2). El problema no es del paquete de Ubuntu, sino que es un cambio upstream. De hecho se rumorea que quizá la próxima versión de Clearlooks copie esta feature... ¬¬. Como comentaba hacía un tiempo que estaba bastante molesto con ésto, pero por casualidad he encontrado una entrada en un blog que comentaba cómo resolver este problema.La solución es sencilla, y consiste en obligar a GTK que utilice un motor distinto de Murrine para mostrar los expansores. Para ello se debe crear el fichero ~/.gtkrc-2.0 con el siguiente contenido:style "expander-fix" = "default" { engine "" {}}class "GtkExpander" style "expander-fix"class "GtkTreeView" style "expander-fix"class "GtkCTree" style "expander-fix"Afortunadamente no soy el único molesto con esto, y está reportado en Launchpad en el  bug #527789 y en el bugzilla de GNOME en el  bug #611159. A ver si hubiera suerte y Cimi se enrollara y diera opción para usar uno u otro en Murrine.HTH!

Durante las últimas semanas he estado haciendo algunas optimizaciones en el código de AVBOT que han permitido que se reduzca el tiempo que tarda en reparar los vandalismos. Antes tardaba una media de cinco segundos, habiéndose reducido a tres en la versión actual (cálculos grosso modo, ya haré una gráfica). Ha sido posible, de nuevo, al empleo de hilos.Además, AVBOT está siendo probado en la versión inglesa de Wikipedia, y hay un usuario interesado en llevarlo a Wikipedia en portugués. Por todo ello, estoy haciendo algunos avances en cuanto a la versatilidad del código. Pero aun no está internacionalizado, ¡eso será más adelante!Más información sobre todo esto en sucesivas entradas.

Principalmente, uno de los indicadores del estado de un proyecto es la actividad de su blog. Éste bien puede ser el caso de eOPSOA, que por unas razones u otras no está teniendo la progresión que Luismi y yo esperábamos cuando nos apuntamos al CUSL. Desgraciadamente ambos estamos trabajando, y por muchas ganas que tengamos los días siguen teniendo 24 horas :-(Quien estaba haciendo el grueso del trabajo era Luismi, que como comenté al principio del proyecto estaba intentando integrar la herramienta Marathon en eOPSOA. Por desgracia la cosa no ha ido tan bien como nos esperábamos, y no han surgido más que problemas: escasa documentación técnica, código muy acoplado con la UI, problemas para depurar (principalmente RMI)... etc. Es muy muy frustrante porque le ha echado muchísimas horas y un montón de esfuerzo, pero hay veces que las cosas no salen aún a golpes de corazón, y lo ha tenido que abandonar. Además la decisión es dura porque se trataba de su Proyecto Fin de Carrera, y parte de ese trabajo lo ha perdido. Afortunadamente aún existe la posibilidad de integrar SWTBot, que aunque es bastante menos potente que Marathon parece que nos puede dar mejor resultado.Respecto a mí, tampoco he podido avanzar demasiado con el tema de BIRT. No es excusa, pero entre Máster, trabajo y lo poquito que podía ayudar a Luismi, apenas he tenido tiempo de nada.Pero no todo van a ser malas noticias para el proyecto. Desde el verano pasado se han certificado varias herramientas con OPSOA, y gracias a la paciencia de Estela y Laura estamos obteniendo un feedback muy bueno. Estamos madurando algunas ideas para mejorar tanto OPSOA como eOPSOA, y sólo es cuestión de sacar tiempo de algún sitio para poder realizarlas. Además, mi contrato se me acaba a fin de mes, y es posible que al menos durante un tiempo pueda dedicar algo de atención al proyecto. Más adelante intentaré escribir sobre estas ideas, pero está relacionado principalmente a mejorar el cuestionario, e intentar extraer conclusiones de él automáticamente.Por último, sólo pedir un poco de paciencia; las cosas de palacio van despacio, y aunque sea lentamente vamos avanzando poco a poco ;-)

AVBOT is a project that aims to build an anti-vandalism bot for Wikipedia projects (although it would be useful for all MediaWiki sites).Its main developer is emijrp, a veteran user of Spanish Wikipedia. This project is in an advanced status, and it is used in Spanish Wikipedia under the nickname AVBOT with great results. You can see it running 24/7. I has reverted more than 200,000 vandalisms.You can download the source code from Google Code, it is published under GPL v3 license. It uses the pywikipediabot and python-irclib libraries.

Para todos aquellos que creen que doxygen es algo difícil o feo , cuando vean lo fácil que es y lo divertido que es generar documentación , seguro que cambiarán de opinión.
En GNU Xfree Fighter se genera dos documentaciones una en el directorio
gnu_xff/trunk/proyecto.cfg  para el funcionamiento del juego
y otra en
gnu_xff/trunk/library para el funcionamiento del motor gráfico de eventos, etc….
Empecemos con el  mini-tutorial:
lo 1º instalar doxygen http://www.stack.nl/~dimitri/doxygen/ ( en ubuntu sudo apt-get install doxygen )
2º para que te aparezcan los grafos de las clases tienes que tener instalado esta aplicación:http://www.graphviz.org/   ( sudo apt-get install graphviz
Yo siempre uso un fichero con las opciones más básicas ( hay miles de opciones pa aburrirte )
—————————————- proyecto.cfg para un código php
PROJECT_NAME = OLDLASTPHP_FRAMEWORK
PROJECT_NUMER = 2.1
OUTPUT_DIRECTORY = doc
OUTPUT_LANGUAGE = Spanish
EXTRACT_ALL = YES
FILE_PATTERNS = *.php *.html
RECURSIVE = YES
PDF_HYPERLINKS = YES
USE_PDFLATEX   = YES
HAVE_DOT = YES
——————————-
otro ejemplo de fichero de doxygen esta vez de mi proyecto fin de carrera en donde yo selecciono que ficheros
documetnar en vez de todos y que sean recursivos.
PROJECT_NAME = GNU XFREE FIGHTER
PROJECT_NUMER = 0.6
OUTPUT_DIRECTORY = doc
OUTPUT_LANGUAGE = Spanish
EXTRACT_ALL = YES
INPUT = clases/ia/ia.h clases/jugador/jugador.h clases/efectos/efectos.h clases/animacion/animacion.h clases/colision/colision.h clases/colision/T_colision.h clases/manager/manager.h  clases/acciones/acciones.h clases/combate/combate.h clases/tipo_juego/T_juego.h clases/input/input.h clases/menu/menu.h clases/magia/magia.h clases/special_mov/special_mov.h clases/Combate/Combate.cpp clases/luchador/luchador.h clases/escenario/escenario.h
RECURSIVE = NO
PDF_HYPERLINKS = YES
USE_PDFLATEX   = YES
HAVE_DOT = YES
————————-
como documentar
lo más facil
///@brief esta clase esta guay puedo meter html
clase A{
public:
///@brief constructor
///@param x un entero
// @param y otro entero
A(int x,int y);
///@brief funcion absurda
///@return un entero
int dev_nada();
}
Espero que os  sirva de ayuda este manual si queréis generar la documentación del proyecto.
Un saludo a tod@s.
Resistir es Vencer.

Ahora mismo me encuentro quitando fallos de compatibilidad entre plataformas y mejorando compatibilidades así que en las versiones del código a partir de las 169 puede que no funcionen las magias por que estoy mejorando el algoritmo y la forma de recoger del buffer. Las llaves tampoco estarán disponibles por la misma razón.
Estas serán las plataformas en donde estoy probando mi videojuego y garantizo compatibilidad:

¿ Tendré  una versión decente lista para Junio ?
Solo el tiempo lo dirá……..
CUALQUIER PROBLEMA ES UNA OPORTUNIDAD DISFRAZADA.
Abraham Lincoln