Planet

He conseguido sacar tiempo en estas fechas tan complicadas (examenes+trabajo) para realizar la primera versión del esquemático de ArCan. Una vez le de el último repaso empezaré con la PCB.
Estimo que para dentro de un par de semanas colgaré fotos del primer prototipo :), y entonces empezaré con el desarrollo del firmware.

Portar Tucan a windows nos ha costado bastante por dos problemas específicos de la plataforma.

• Si ya es difícil hacer funcionar GTK con los threads de python, mas aun es hacerlo sobre windows, ya que GTK esta muy bien adaptado al interfaz X windows, no así a la winapi.

• Por otro lado, windows usa paths con espacios en algunos de sus directorios por defecto, cosa muy poco recomendable. Como Tucan guarda los plugins en el directorio del usuario, ha sido muy tedioso conseguir importarlos desde ahí. Además, tesseract tiene una particularidad, y es que no se puede ejecutar desde un directorio con espacios, así que Tucan se instalara por defecto en el directorio raíz de vuestro disco duro.

Aquí os dejo el link del instalador. Agradecedselo a Beakman, por su gran esfuerzo haciendo el exe y el instalador.
Un saludo, Crak.
      

Este es un documento informal que le he enviado al profesor para decidirnos sobre qué realmente implementar.
Como veis se sigue con la idea de user FAI pero con la opción de realizar una interfaz gráfica para el mismo o no.
Propuesta de Proyecto Desdeslin
Como curiosidad el concepto de documento de propuesta no estaba contemplado en el esquema que aprendí en la asignatura de: Iniciación a la ingenieria del software.
Sin ninguna autoridad en el ramo voy a definirlo cómo un documento que resume las conclusiones de varias iteraciones: Analisis de Requisitos, Diseño, Implementación para fijar de manera formal la dirección a tomar a medio plazo en el proyecto que se analiza.
Adrián
      

Pues que le voy a hacer si antes lo del borrado en cascada me parecía un gran riesgo para la integridad de muchos datos. Lo que sucedía es que no había encontrado ninguna aplicación realmente práctica para hacerlo y ahora me he encontrado que si las unidades en que mide las cosas mi programa están internacionalizadas la base de datos puede impedir el borrado de las mismas. Ahora el administrador de la aplicación (que no del sistema) puede crear las nuevas unidades y, si despiden al entrenador que las solicitó, puede borrarlas. Claro está que si esas unidades siguen referenciadas por otras tablas que no sean sus propias traducciones, el sistema soltará una excepción que deberemos controlar para avisar al usuario de eso no se debe de hacer
Para configurar que el borrado sea en cascada tan solo tenemos que poner estas lineas en el fichero de configuración:
Además, si por casoalidad la base de datos que usamos no cumple con la integridad referencial (no es mi caso) el propio gestor de objetos Propel gestiona esa integridad para evitar barbaridades binarias.

Symfony tiene su aquel a la hora de trabajar con el. Todos tenemos nuestra metodología más o menos particular (más o menos óptima también). Con Symfony nos vemos obligados a trabajar con un conjunto de nombres con los que podemos estar más o menos de acuerdo, pero que, cuando ves funcionar la aplicación en el Estilo Symfony, resultan favorecedores para el desarrollo limpio y sencillo de tu aplicación.
El caso es que hoy estaba creando las relaciones entre unidades para convertir unas en otras. Una persona que hoy levanta diez veces cincuenta kilos a lo largo de la semana habrá levantado 3.500 en el mes 14.000. A la hora de realizar los informes es conveniente no poner cifras exageradas así que voy a convertir, mediante una tabla de factores de conversión unas unidades en otras.
Cuando estoy introduciendo mis datos de ejemplo meto la pata (parte de las pruebas, resultados no esperados por la lógica) para luego volver a editar la relación entre kilos y toneladas.
El caso es que he visto que no se veían los antiguos valores en el formulario. ¿Que significaba esto?¿No estaban correctamente relacionadas las tablas?¿no guardaba correctamente el valor de las unidades a convertir?
Vamos por partes. Para la selección de estas unidades utilizo un desplegable con todas las posibles. En este punto no voy a usar ajax para filtrarlas teniendo cuidado con que sean del mismo tipo (tiempo, longitud, peso, cantidad incremental entera) porque dependiendo del entrenador puede ser que las mezcle.
Cuando he observado otros puntos donde uso el mismo sistema de desplegables (al seleccionar el tipo de unidad para crear una nueva, como en tipo distancia, crear milla) no sucede eso. Cuando he ido al código me he encontrado con que el fragmento que llamaba a la construcción del componente era:
<?php echo object_select_tag($unit, ‘getUnitTypeId’, array (
‘related_class’ => ‘UnitType’,
‘include_blank’ => false,
)) ?>
El principio no le di mucha importancia al Id del getUnitTypeId. Pero claro como Symfony nos echa un cable con todo lo que hacemos también tenemos el método getUnitType, que en vez de devolvernos el mismo Id nos devuelve el objeto.
La clave de todo está en que en la especificación de las clases (el fichero schema.yml) no había puesto origen_id ni destino_id, sino origen y destino. Así las cosas no podía el componente llamar correctamente al método que le devolvería el nombre porque se solapaba con el propio método.
Cambiado el nombre de la propiedad del objeto en el fichero de configuración, regenerados todos los ficheros de la librerías y cambiadas las llamadas necesarias al que lleva id, respetando las que queríamos sin el id (que por defecto, al imprimir un objeto ya he definido el método __toString() con dos barras bajas) el programa funciona correctamente con la salvedad que debido a representar una relación múltiple con una sola clase el método para obtener el objeto es getUnitRelatedByDestinyId().
Se puede hacer por facilitar el definiendo un método en la clase derivada de la Base ConversionFactor, pero por razones de documentación y especificación de Symfony, que ya hemos visto que tiene su cierto intríngulis, dejaremos el nombre del método largo.

Tras ir creando la aplicación con bastante soltura a pesar de los problemas encontrados anteriormente, nos hemos topado con un problema que es crucial en el desarrollo de nuestra aplicación.
El problema se ha encuentrado en la selección de una región de interés en una imagen. La solución que habíamos decidido adoptar era la de seleccionar la región de interés sobre una imagen y que a partir de ésta imagen se generara una nueva imagen donde solo se mostrara la región de interés, y el resto de la imagen en negro (por ejemplo).
Nos hemos encontrado que no éramos capaces de generar ésta nueva imagen, o al menos generarla para cualquier tipo de imagen, no importando, por ejemplo, el sistema de color utilizado o el número de bandas que contenga un pixel.
Viendo que los conocimientos sobre JAI y JAVA 2D no eran los adecuados, nos hemos dedicado a aprender como se almacena una imagen en JAI y como se utiliza ésta.
Al final, hemos conseguido llegar a una solución que parece factible y generalizado a cualquier imagen (falta probar esta parte de forma exhaustiva), aunque pensamos que no es lo más óptimo a lo que podemos llegar, puesto que en nuestra aplicación es bastante importante el tiempo de respuesta al usuario.
Ahora, estamos estudiando como mejorar esta parte e integrarla en el resto de la aplicación.
Os mantendremos informado con nuevas noticias.
      

He comenzado a investigar cosas para comenzar la interfaz gráfica de usuario de Unimail. Pretendo que sea una interfaz sencillita y en ningún caso sustituirá a la interfaz de consola. Ambas interfaces estarán disponibles de aquí en adelante aunque, eso sí, la más fácil de usar será la gráfica.
Lo que estoy investigando es concretamente PyGtk y Glade. PyGtk es una librería para Python que sirve para hacer interfaces gráficas y Glade es un diseñador de interfaces gráficas. Con Glade lo que se hace es crear un archivo XML que define el aspecto de la intergaz gráfica y luego se escribe en un archivo aparte código Python que utilice PyGtk para cargar el archivo XML y dibujar y ejecutar la interfaz conforme a lo que en el archivo XML se define. Aparte, en el mismo archivo Python o en otro, se escribe código para definir el funcionamiento (la lógica) de dicha interfaz gráfica. El uso de estas dos herramientas hace que la programación de interfaces gráficas en Python sea realmente elegante, ya que se separa la presentación de la lógica (ya sea la lógica de la propia interfaz o la lógica general de la aplicación).
Las interfaces gráficas que se consiguen con estas dos herramientas están diseñadas para el entorno Gnome, que es para el que está pensado Unimail. De momento, no tengo en mente realizar una interfaz gráfica alternativa para el entorno KDE u otro, pero nunca se sabe; en todo caso lo dejaría para después del concurso, ya que no es una prioridad para mí.
Os muestro un par de imágenes de lo que estoy haciendo. No dicen mucho, pero bueno, son un signo de que el proyecto va avanzando poco a poco.


      

Desde hoy está disponible la nueva versión de Unimail, la versión 0.6. Los cambios en esta versión son el arreglo del último fallo detectado y un cambio del formato de los mensajes. El cambio del formato hace que esta versión sea incompatible con las anteriores, por lo que los archivos enviados con versiones anteriores no se podrán descargar con esta nueva versión.
El nuevo formato de los mensajes hace que Unimail sea más fuerte ante posibles anomalías en la bandeja de entrada del servidor de correo.
Esta es la segunda versión que utiliza el protocolo IMAP. La primera tenía el fallo anteriormente comentado, por lo que se puede considerar a esta versión como el comienzo del protocolo IMAP en Unimail, ya que parece que ahora funciona bien.
      

Buenas,
ya con el proyecto algo más avanzado estamos a la espera de finalizar la plantilla en latex para mi proyecto fin de carrera y ya puestos y con la mentalidad de software libre para los proyectos fin de carrera para la ingeniería de telecomunicación de la universidad de granada y de cualquier parte que la quieran usar y modificar a su gusto y necesidad.
Por otra parte, hago un llamamiento a los diseñadores gráficos y gente con tiempo libre por si quieren mandarme algún boceto para los insectos o para el logo del juego, o llendo un poco más lejos si alguien colaborar en el desarrollo y/o implementación de alguna parte también está invitado a ello.
Recuerdo que el juego se llama: Hungry Insects Wars y que mi dirección de mail es ramirezversion@gmail.com. Ruego si alguien me escribe algún mail poned un asunto descriptivo por favor.
Un saludo y gracias por la futura colaboración y por leerme.
      

El boceto de implementación que ya os comenté ha sido concretado en mayor medida con:
Aproximación primera de implementación
Aqui ya se adivina que el proyecto se basará en su mayor parte en FAI: Fully Automatic Installation .
Fai proporciona instalación automatizada básicamente y el resto de requisitos se pueden suplir con otro programas de Debian, que obviamente se podrán automatizar al instalarlos en los ordenadores clientes.
Adrián