Planet

En un principio el programa analizaba una edición tras otra, de forma secuencial. Este sistema era bastante lento, pues había que esperar a que se terminara de comprobar una edición para saltar a la siguiente y en Wikipedia en español el ritmo de modicaciones a veces superaba al ritmo de análisis. Para evitar esto se introdujo el uso de hilos, mediante la librería thread. Con esta solución, cada vez que llegan los datos de un cambio, se llama a la función de análisis. Si llegan varias modificaciones a la vez, no se espera a que termine una para empezar con la siguiente, ya que son independientes.Otro aspecto relevante es el precompilado de expresiones. Cada vez que era analizada una edición, había que pasar la lista de expresiones (varios cientos de ellas) sobre un texto que en algunas ocasiones era bastante extenso. Este proceso requería los siguientes pasos:

1. Leer la expresión regular.
2. Compilar la expresión regular.
3. Pasar la expresión regular compilada al texto objetivo.
4. Volver al paso 1 con la siguiente expresión.

Se puede evitar la compilación continua de una misma expresión si guardamos el resultado de dicha compilación. Por ello, se implentó una mejora en el cargador de expresiones, que en vez de guardar sólamente la expresión en cruda, guarda su compilación. La mejora fue drástica. De tener que compilar entorno a 600 expresiones por cada página analizada, lo que hacía que el proceso de análisis consumiera unos 10 segundos, se pasó a menos de una milésima de segundo por análisis. Denitivamente esta fue una mejora crucial en el programa.

Ya se ha confirmado la fecha de la fase final del concurso en el que se entregarán los premios a los proyectos ganadores.
Será el 23 de Abril de 2009 en la Escuela Universitaria Politécnica de Cuenca.
Los asistentes tendrán posiblidad de asistir a varios talleres de software libre, obtener créditos de libre configuración y ganar diversos regalos.
Os recordamos que la organización pondrá a disposición de los asistentes autobuses gratuitos para asistir a la fase final desde Albacete y Ciudad Real.
Más información en http://www.celscam.com/concurso

En el anterior post se habló sobre la herramienta utilizada en el proyecto como entorno de pruebas. Ahora vamos a ver cómo funciona y qué características ofrece para las pruebas de un proyecto.
Instalación
El entorno de pruebas es un proyecto separado (pero creado a la vez que IcePick) y podemos descargarlo en:
$ svn co https://arco.esi.uclm.es/var/svn/public/prj/tester
Uso básico
Supongamos que tenemos nuestro proyecto que consiste en implementar el comando cat de GNU que, como bien sabeis, lista el contenido de ficheros. El directorio de nuestro proyecto estará en: ~/proyecto. En ese proyecto tenemos los directorios proyecto/src y proyecto/test para el código y las pruebas del proyecto, respectivamente. El directorio src tendrá un ejecutable llamado mycat.
En el directorio de pruebas debemos crear un fichero llamado DESCRIPTION que el entorno de pruebas utilizará para mostrar información relativa al directorio. En nuestro caso, un ejemplo de archivo podría ser el siguiente:
Pruebas de funcionamiento general de cat
Con lo anterior, el tester no ignorará ese directorio y tratará de buscar pruebas dentro de él para ejecutarlas.
Como nuestro proyecto está en un directorio que no se encuentra en el PATH, el entorno buscará en el directorio de pruebas un archivo llamado ENVIRON donde se declarán las variables de entorno necesarias y sus valores para realizar las pruebas cómodamente.
PATH+=~/proyecto/src
De esta forma, el entorno de pruebas tendrá podrá ejecutar nuestro programa símplemente con el comando “mycat”, mucho más cómodo que con el path hacia el directorio.
Hasta el momento, sólo hemos configurado nuestro directorio de pruebas para ya ir incluyendo comprobaciones del proyecto. Ahora vamos a realizar unas pruebas simples creando un archivo llamda test/test1.py:
# DESC: Pruebas de ejemplo
# +CMD:echo "hola" > mycat > output.txt # Cadena por la entrada estandar
# -CMD:mycat -2 # Opciones incorrectas
La primera línea sirve para describir las pruebas concretas que se encuentran en el fichero. Cada línea siguiente es una prueba que vamos a realizar sobre nuestro programa. La primera prueba (precedida por +CMD:) significa que es una prueba positiva, es decir, si el valor de retorno de la ejecución es distinto de 0 la prueba fallará. O lo que es lo mismo, nuestro programa de comportarse correctamente para el comando dado.
Por su parte, la siguiente prueba es una prueba negativa, ya que esperamos que falle al tener opciones incorrectas como argumentos. Si el código de salida del programa es 0 (es decir, funcionó correctamente) la prueba fallará.
Ejecutemos tester.py de la siguiente forma (suponiendo que tengamos el archivo en el directorio actual):
$ ./tester.py proyecto/test
Y tendremos la siguiente salida:
-- [test] Pruebas de funcionamiento general de cat -----------------------------
[ OK ] test1.py Pruebas variadas Cadena por la entrada estandar
[ OK ] test1.py Pruebas variadas Opciones incorrectas
--------------------------------------------------------------------------------
[ OK ] 2 tests
time: 0.0180 s
** All passed!! **
La salida anterior informa sobre los resultados únicamente. Podemos ver una salida más extendida sobre lo que ha hecho el entorno de pruebas si utilizamos el parámetro de verbosidad -v. De paso, en vez de proporcionarle el directorio le pasamos el archivo de pruebas directamente para ilustrar que es posible también esta opción:
$ ./tester.py -v proyecto/test/test1.py
Y la salida:
[tester:I]: exec 'echo "hola" > mycat > output.txt'
[ OK ] test1.py Pruebas variadas Cadena por la entrada estandar
[tester:I]: exec 'mycat -2'
mycat: opción inválida -- 2
Pruebe `mycat --help' para más información.
[ OK ] test1.py Pruebas variadas Opciones incorrectas
--------------------------------------------------------------------------------
[ OK ] 2 tests
time: 0.0391 s
** All passed!! **
Las etiquetas [tester:I] informan sobre lo que ha realizado el entorno de pruebas. Por cada línea de prueba que declaramos se ha ejecutado un proceso con el comando pertinente. Si nos fijamos en el segundo podemos ver que falló el comando (justo lo que esperábamos).
En el siguiente post veremos cómo utilizar los scripts setup y teardown que soporta el entorno.

El otro día tuve que dar una charla en Zaragoza sobre Pentaho y hablar de I+D+i+m+l que hacemos en mi empresa  y después de unas 2 horas de charla , llego el momento que mas me gusta que es el de ruegos y preguntas , y me toco un tío o personaje que  debía de estar metido en el mundo desde hace 50 años y o asi.
Bueno el hombre me salio  con algunas frases como:

1. Java no es multi-plataforma.
2. Todo Producto Open-Source es propietario por que te obliga a usar ese producto.
3. google es de código abierto.
4. Lo que hace Java se puede hacer en “COBOL“.
5. Java solo esta instalado en un pequeño grupo de ordenadores en el Mundo.

Y claro  yo me pregunte este de donde sale… , toda opinión es valida desde la de un experto hasta la del payaso e Micolor . Así que ahí van las mías.

1. SI java no es multiplataforma que lo es Ensamblador , Java es multiplataforma por definición la puedes ejecutar en Win2 , Unix, wherever.
2. Ostias y ¿uno propietario no? ya que si instalas una base de datos Oracle luego no intentes hacer algo en Mysql hermano .
3. Donde esta las Sources que me las bajo toas .
4. Cobol lo he visto en un museo no se ni lo que hace , pero dudo que cobol=java mas que nada por que son lenguajes de distintas generaciones.
5. Quizá en Marte si en la tierra , el porcentaje es al contrario.

Después de entrar en un agrio debate sobre el SL y toda la farándula . Digo la mejor frase que uno dice en el mundo BI.
Y fue la siguiente:
El Bi es del siglo XVII , y ya se hacia con un Ábaco.El resto no es mas que añadir tecnología.
Bueno ayer me entretuve en hacer un cubo OLAP con un ábaco y no hubo manera , y un reporting macho al ábaco le dio por no exportar las cosas a pdf por mas que le insistía y no te cuento nada con los cuadros de mando.
Hay una cosa clara el BI es una filosofia no una tecnologia , pero en mi opinion la esta tecnologia a ayudado a que las cosas vallan a mejor.
Así que ahi va mi BIconsejo el dia , hacer la declaracion con un ábaco es mas facil , mas eficiente y se le puede arrera a alguien en la cabeza con el. Las calculadoras son malas son el demonio .

Después del gran avance de la semana pasada, he dedicado estos dias a estudiar a fondo el datasheet del MCP2515. Ya aprendimos como escribir en los registros de este, sin embargo, el interfaz SPI de nuestro controlador CAN implementa 9 OpCodes distintos. Podemos verlos en la siguiente tabla:
En el ejemplo anterior el único OpCode que usamos fue WRITE (0×02), sin embargo, puede que lo correcto hubiese sido emplear el OpCode “Bit Modify” y modificar solo los bit necesarios. Por si surgiese la duda, el registro BFPCTRL es de esos registros que permiten el uso de este comando.
Como creo que es bastante interesante conocer todas las posibilidades que tenemos para manejar el controlador, deberíamos echar un pequeño vistazo a las páginas 65, 66, 67, donde vienen muy bien especificados como usar cada uno de los OpCodes, no obstante voy a sintetizar mucho la información y explicarlo uno a uno, para facilitar en la medida de lo posible el manejo a la comunidad.

1. RESET: tan solo debemos enviar 0xC0. Resetea todos los registros, y coloca al MCP2515 en “Modo Configuración”, en futuras entradas trataremos el “Modo de Configuración” más ampliamente.
2. READ: para leer un registro basta con enviar 0×03 seguido de la dirección del registro a leer, 0xaddress, y acontinuación enviamos un dummy (basura) para así recoger en SPDR el valor del registro leido.
3. READ RX BUFFER: Podríamos decir que se trata de un “acceso directo” a los registros de control de los buffers de recepción de mensajes CAN. Su uso puede resultar un poco extraño, tendríamos que enviar 0b10010nm0 donde ‘n’ y ‘m’ nos marcaría el buffer al que queremos acceder. En la siguiente tabla vemos las combinaciones posibles:
   Como en el comando READ, finalizamos enviando un dummy para poder recoger el valor del registro en SPDR.
4. WRITE: Ya lo hemos usado, pero  no está de más verlo de nuevo. Enviamos 0×02 seguido de la dirección del registro que deseamos modificar, 0xaddress,  y terminando con el dato a escribir.
5. LOAD TX BUFFER: Este comando es otro “acceso directo” a los registros que van a controlar los buffers de emisión de datos via CAN. En este caso debemos enviar 0b01000abc seguido del dato que deseamos cargar, ‘a’, ‘b’ y ‘c’ usa un mecanismo similar al de READ RX BUFFER, la tabla para acceder a los distintos BUFFER de transmisión es:
6. REQUEST-TO-SEND(RTR): Básicamente es la que da la orden de empezar la transmisión de los datos que están almacenados en los buffers. Su funcionamiento es tan simple como enviar un solo comando, 0b10000nnn donde colocando un ‘1′ en alguno de los n, daremos permiso a ese buffer para empezar la transmisión.
7. READ STATUS: Este comando nos entrega el registro de estado de nuestro controlador CAN, se envia 0xA0, y enviamos un dummy, ahora podemos recoger el resultado de la lectura del SPDR, pero tenemos que tener una pequeña cosa en cuenta, debemos enviar un dummy más, porque tal como está implementado, el comando envía por duplicado el registro de estado. En este caso puede que la forma más sencilla de tratar con este comando sea enviando 0xA0 seguido de 2 dummys, y posteriormente recoger en SPDR el registro de estado.
8. RX STATUS: Bastante similar al comando anterior con la salvedad que en este caso estamos interesados en consultar el estado de recepción. Se procede de igual forma pero en este caso el OpCode a enviar es 0xB0, y lo que recibimos es:
   
9. BIT MODIFY: Este es el comando que más envío de datos require, se procede de la siguiente forma, enviamos 0×05 seguido de la dirección del registro que queremos modificar, 0xaddress, posteriormente enviamos la máscara de bits, que es donde codificaremos cuales son los bit que deseamos modificar, por ejemplo 0×81 (0b10000001) con esta máscara solo modificamos el primer y el último bit, a continuacion enviamos el dato a modificar 0xdata.

Estos son los nueve posibles comandos que tenemos disponibles, en el archivo ArCan_def.h teneis los #defines de todos.
A partir de ahora creo que tenemos la base teórica y práctica para empezar a configurar ArCan e intentar enviar un mensaje via CAN, sin duda esto será lo que se aborde en las posteriores entradas.

Bueno, he hecho algunos avances durante todo este tiempo aunque no lo haya escrito en el blog, para empezar y lo que mas me ha gustado y costado es que mi programita ya tiene soporte para idiomas, concretamente está traducido ahora mismo al inglés, español y catalán, si alguien se anima a traducirlo a algún otro idioma se lo agradecería mucho.
Por otra parte tambien he hecho algunos cambios respecto a la captura del cubo, aunque solamente metiendole tu los datos previamente, ahora estoy trabajando en la base de datos para guardar todos los tiempos records y esas cosas, que hasta ahora vengo guardando en un misero archivo de texto. Como aun no se resuelve el cubo, no puedo considerarme en la version 1, pero espero que eso pronto cambie. Otra de las cosas que también estoy haciendo ya es empezar a usar un entorno gráfico, aquel tan feo que usaba en principio, y que seguiré usando hasta que alguien le de por hacer algo que me guste y lo cambie,
Sin mas nada que decir, les dejo, espero seguir adelante con esto, me está gustando hacer esto bastante ya que estoy aprendiendo mucho, sobre todo de mis errores
Saludos!!!

En el proyecto IcePick está siendo determinantes las pruebas para el desarrollo del mismo. Si pensamos en la funcionalidad genérica de cualquier compilador podemos darnos cuenta que un desarrollo dirigido por pruebas es ideal para su creación. Un compilador realiza operaciones muy similares a las de una prueba software: dada unas ciertas entradas se esperan unas salidas bien definidas y acotadas.
Las pruebas pueden representar los requisitos y casos de uso del compilador, por lo que si satisface todas ellas puede considerarse que el compilador cumple satisfactoriamente con los requisitos. Por ejemplo, una prueba sencilla puede ser que dado un fichero de entrada al compilador, éste genere la salida correspondiente y  que esa salida sea comprada para asegurar que es correcta. De esta manera, conforme el compilador va creciendo y adquiriendo funcionalidad las pruebas aseguran que en el proceso de construcción no haya habido efectos laterales que pasen desapercibidos. Si una prueba A comprobaba una cierta funcionalidad y, tras modificar el compilador para añadir más funcionalidad, dicha prueba falla, podemos detectar ese error rápidamente y acotarlo al ámbito de la modificación realizada.
Para que las pruebas sean realmente últiles tienen que probar funcionalidad simple y concreta. Esto no quiere decir que todas las pruebas comprueben aspectos triviales del compilador, pero sí que muchas de ellas prueben funcionalidad muy básica. De esta forma se consigue blindar el código frente a modificaciones y asegurar que las pruebas más complejas son coherentes.
En IcePick se ha desarrollado un programa para utilizarlo como tester. Implementado en Python, se trata de un programa que se puede utilizar para comprobar que una aplicación funciona correctamente. No sólo para IcePick, sino para cualquier otro propósito. Para verlo más concretamente, se expone un ejemplo de uso.
# DESC: Unas pruebas de ejemplo
# +CMD: ls -la # ls con 2 opciones
En el código anterior se especifica una prueba sencilla. Los caracteres de # iniciales de cada línea son los comentarios de Python, pero pueden utilizarse cualquiera de otros lenguajes (si en el fichero donde está la prueba está escrito en otro lenguaje). Tras la ejecución de la prueba con la utilidad:
[  OK  ] ls.txt       Unas pruebas de ejemplo                  ls con 2 opciones
--------------------------------------------------------------------------------
[  OK  ]  1 tests
time: 0.0130 s
** All passed!! **
En el siguiente post se detalla el funcionamiento completo del entorno de pruebas.

Tras los exámenes y más tranquilos, estamos ahora más centrados en la caracterización.
Hicimos un primer diseño para la caracterización, que no fue tan bueno como pensabamos, y lo tuvimos que rehacer.
Ahora mismo nos encontramos implementando el nuevo diseño para poder almacenar los datos de caracterización de las imágenes. Aunque gracias al diseño inicial del menú que realizamos para las operaciones de tratamiento de imágenes, hemos podido reutilizar practicamente todo el código (haciendo algunos cambios) para la caracterización.
Hemos intentando que el modo de trabajar con las operaciones de caracterización sea el mismo que el que usamos para las operaciones de tratamiento de imágenes, así la homogeneidad de la aplicación es mayor haciendose más fácil de usar. Como resultado, tenemos el menú de operaciones creado y la carga de operaciones, aunque todavía no tenemos ninguna operación creada.
Además, hemos realizado una vista de thumbnails que aprovechará la caracterización cuando esté terminada. En un futuro, el usuario podrá seleccionar desde esta pantalla las imágenes sobre las que quiere realizar una batería de operaciones de caracterización.
Mostramos algunas capturas de pantalla de la aplicación (también mostramos la funcionalidad de los histogramas):

Pantalla de Carga


Vista de Thumbnails


Vista de histogramas

Ya he terminado el nivel de Macrociclo al completo. Mesociclo es prácticamente igual, pero con la particularidad de que, al tener los microciclos una estructura similar entre ellos, y cada día corresponder con el mismo número de sesiones, la generación de un mesociclo implicará la automatización del proceso en microciclos y sesiones.
A partir de aquí se tendrán las mismas opciones que en el resto de tipos de periodos en la edición, borrado, etc.
También se ha avanzado en el aspecto gráfico, pues ahora dentro de cada elemento del entrenador tenemos acceso a los que están dentro: desde usuarios se accede directamente a las opciones de las sesiones de este usuario.
Para la terminación de lo que se va a presentar ante el jurado de mi universidad como proyecto de fin de carrera no queda mucho.Espero que la versión que se presente sea la 0.4 con todo el feedback de usuario desarrollado.
Aunque, en realidad, esto solo es el comienzo de un proyecto, espero que tenga una gran duración en el tiempo y, si se puede, llegar a vivir de mezclar informática y deporte, mis dos pasiones.

Hoy miércoles 4 de marzo presenté a AVBOT como Proyecto Fin de Carrera. El nombre completo es "Detector y corrector automático de ediciones maliciosas en Wikipedia".

• Documentación: Memoria, Doxygen, manual de instalación, manual de usuario, diapositivas.
• Código fuente: Rediris, Google Code.

Calificación: Matrícula de honor.