Offtopic: Fox Splitter

Durante este año he tenido que estar escribiendo mucho en inglés, y no es que se me dé mal tampoco, pero hace mucho que no estudio gramática y en ocasiones no estoy muy seguro de si escribo bien. Desde hace un tiempo me he dado cuenta que cuando tengo que escribir en inglés casi siempre tengo las Google Language Tools abiertas en dos pestañas de Firefox: la primera con español-inglés y la segunda con inglés-español. Mi forma de trabajar es sencilla y voy escribiendo en una y en otra, pero cuando llega un momento en el que termino cansando de estar cambiando de pestañas continuamente.

El caso es que esta tarde estaba buscando una extensión para el Firefox cuando me he encontrado otra que sin duda me va a ser útil: Fox Splitter. Esta extensión hace algo que llevo queriendo hacer desde hace mucho tiempo, y es poder poner dos pestañas de Firefox una al lado de la otra. Mirad que bien queda para el caso que comentaba de las Language Tools:

Parece útil ¿verdad?

HTH!

Offtopic: devolver el triángulo en el expansor en Murrine

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!

Estado del proyecto: problemas con Marathon, y desarrollo futuro

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 ;-)

Incorporación de Marathon a eOPSOA

Tras unas semanas de aunar y aclarar ideas con mis tutores (y cotutores!!) de proyecto, y determinar así los objetivos en relación a la idea que tenemos de como mejorar eOPSOA, llegó el momento de realizar la primera aportación a este blog.

Como bien ha comentado David, con objetivo de poder terminar mi PFC y poder aportar así mi granito de arena a eOPSOA, me voy a ocupar de investigar cómo integrar la herramienta de testeo funcional Marathon al proyecto comentado.

Para quién a Marathon le suene a la famosa trilogía de videojuegos, o simplemente a la conocida prueba atlética de resistencia, comentar que Marathon es una herramienta de libre distribución, la cual podemos extender fácilmente y que nos ayuda en el desarrollo de conjuntos de pruebas automatizadas para aplicaciones Java / Swing . Marathon nos ofrece un entorno integrado en el que puede crear conjuntos de pruebas. Además, incluye un grabador, un reproductor y un editor de scripts para facilitar la automatización de pruebas. Marathon se utiliza principalmente para la automatización de pruebas funcionales, aunque también puede ser utilizado para crear conjuntos de pruebas para desarrolladores.

Cuando se lleva tiempo realizando pruebas en los diferentes proyectos entregados, nos damos cuenta que hay cosas que son particularmente difíciles de probar de forma automática y otras donde ocurre todo lo contrario, al existir medios suficientes para abordar la prueba automática. Un ejemplo claro son las interfaces gráficas de usuario.

Para la ejecución de pruebas de forma automática existen numerosas herramientas. No ocurre lo mismo para la generación de los casos de prueba, por ello intentaremos con esta herramienta abordar los objetivos que no se pudieron completar el año pasado (debido a que la herramienta elegida no cumplió las expectativas creadas), con la incorporación de automatización de pruebas, en la parte de Generación y Ejecución de pruebas de eOPSOA. Más adelante, iremos ampliando con más detalle la idea que perseguimos en el proyecto.

Finalmente, no quería terminar este primer cometario, sin dar las gracias a todas las personas que me están ayudando en el desarrollo de mi propósito. Especialmente quería agradecer a mi compañero David Castellanos, la ayuda, disposición y paciencia mostrada, desde el primer día (23 de octubre) que se enteró de mi incorporación al equipo.

Gracias deivis!!

Preparando el III CUSL de CLM y el IV CUSL

Después de unos cuantos meses sin actualizar el blog y sin dar apenas señales de vida, volvemos a la acción en eOPSOA con muchas ganas de trabajar y de hacer cosas interesantes.

Algunas cosas han cambiado respecto al año pasado. Para empezar, este septiembre pude presentar mi PFC y ya soy oficialmente Ingenierete en Informática. Como parece que no tuve bastante, este año me he matriculado en el Máster Universitario de Tecnologías Informáticas Avanzadas de la UCLM (los antiguos cursos de [pre]doctorado) así que sigo siendo universitario, y por tanto puedo volver a participar en el CUSL. Pero la principal novedad de este año es que se incorpora al proyecto Luis Miguel Bastante, estudiante también de Ingeniería Informática en la UCLM, y que está realizando su PFC.

Aún faltan algunas cosas por decidir, pero parece que la participación de este año va a ir en línea a la del año pasado, e intentaremos realizar algunos de los objetivos que se quedaron pendientes del año pasado. Por ejemplo Luismi va a investigar cómo integrar la herramienta de testeo funcional Marathon en eOPSOA, y en mi caso, voy intentar generar reportes usando para ello el framework BIRT.

Aunque todavía no ha comenzado oficialmente el período de participación ya estamos adelantando algo de trabajo, por ejemplo hemos cambiado el tema del blog a uno un poco menos funky, y en el trunk del SVN se está trabajando en la refactorización del modelo Ecore del proyecto.

Happy hacking!! :-)