Planet

Leo:
Sun y Pentaho darán soporte BI a OpenOffice.org April 23rd, 2007 Sun Microsystems, creador de la suite ofimática StarOffice y su versión FLOSS OpenOffice.org, se ha aliado a Pentaho, compañía que desarrolla tecnología de Business Intelligent (BI) bajo licencias FLOSS. Esta alianza permitirá incluir en la próxima versión de OpenOffice.org y StarOffice un motor generador de reportes. Sun busca que OpenOffice.org mejore su posicionamiento en el mercado corporativo ayudando a las compañías a extraer información valiosa a través del BI. Esta integración permitirá por ejemplo que un usuario desde OpenOffice.org Writer embeba en documentos reportes creados con el motor de BI de Pentaho. El soporte BI en FLOSS todavía recién se está iniciando aunque este tipo de alianzas o proyectos de competidores de Pentaho como JasperSoft, están llevando estas tecnologías a compañías que confíen en FLOSS en sus infraestructuras. En Flozer, nuestra unidad de negocio FLOSS, realizamos servicios de soporte y migración de Microsoft Office a OpenOffice.org, con lo cual esta noticia nos llena de orgullo.
Creo que es una formula acertada ya que nos guste o no en las empresas OpenOfice tiene poca acogida ,  creo a ver comentado esto en algún post  sino   lo are, pero es un paso acertado.El siguiente es que Pentaho utilice Birt
Con esto Sun se ratifica como la empresa puntera en SL , despues de adquirir  Mysql.

La versión 0.3.5-win32 ha tardado bastante en salir por problemas particulares de Windows, he tenido que crear un plugin especifico para esta plataforma ya que me ha sido imposible portar el genérico. La versión previa que se colgó en la forja da problemas dependiendo de si se ejecuta desde un enlace o desde la aplicación, así que recomiendo usar esta nueva versión.
Disculpad las molestias.
La base de datos online tiene ya casi 10 000 captchas. ¡Seguid así!
Un saludo, Crak.

Después de alrededor de 4 meses de desarrollo, estoy orgulloso de publicar la versión 0.1.1 de eOPSOA. Esta release no se puede considerar para producción, porque carece de la mayoría de características que pueden hacer eOPSOA útil para el analista. Sin embargo la intención es que se testee, para corregir los pequeños fallos que pueda haber de los cuales no sea consciente.Para descargar eOPSOA tienes tres opciones:

1. La opción recomendada, que es usar el Update Site para Eclipse. Te gestionará él solo las (pocas) dependencias que tiene el proyecto de forma automática y no dolorosa.
2. Desde un fichero con un update site fuera de línea. Lo podrás encontrar en el área de descarga de la forja de Molinux.
3. Si eres desarrollador, o valiente, descargar la última versión del repositorio SVN.

Las características de la versión 0.1.1 son las siguientes:

• Soporte para la caracterización de los programas a certificar, permitiendo la edición, guardado y recuperación de los documentos checklist, glosario y de visión. Estos documentos se cargan desde plantillas XML, de tal forma que la adaptación a nuevas revisiones de estos documentos sería inmediata.
• Soporte para la descripción de los actores del sistema.
• Soporte para la especificación completa de Casos de Uso. Permite especificar los actores involucrados en el UC, las precondiciones/postcondiciones, los flujos básico y alternativos, y las relaciones entre los distintos UC.

Una característica que no se había planteado originalmente, y que creemos que puede ser interesante, es la forma en la que definimos los flujos básicos y alternativos de cada UC. Los flujos están compuestos por pasos, y estos a su vez pueden estar compuestos por pasos. Los pasos se pueden marcar como de entrada o de salida, y asignarles variables.Para la siguiente iteración se va a trabajar en el soporte de pruebas: definición de escenarios, integración con algunas herramientas de testeo funcional y de calidad de código... etc. Si alguna vez habéis trabajado testeando funcionalmente una aplicación, estaréis de acuerdo conmigo en que definir los escenarios y todas las combinaciones de variables es un auténtico rollo. Aquí entra lo que he comentado antes de la decisión de diseño que se ha tomado al implementar el soporte de UC. Vamos a intentar que hasta cierto punto la generación de escenarios sea automática, utilizando la información "extra" que hemos pedido al realizar la definición de los UC.De cómo se implemente el soporte para los Tests de Pruebas va a ser crucial para la utilidad (o inutilidad) de eOPSOA. Próximamente escribiré de cómo estoy realizando esta tarea y de los problemas que estaré encontrando :-)

Durante esta semana he realizado un avance bastante grande, si bien quería haber comenzado con el desarrollo del cliente de escritorio, lo he pospuesto para dejar prácticamente listo el cliente web, con toda la funcionalidad que debiera tener.
Así pues esta semana he implementado la posibilidad de exportar todas las contraseñas para después importarlas en otro servidor o como copia de seguridad.
La exportación es un simple volcado de las contraseñas del usuario tal y como se almacenan en la base de datos. Las contraseñas están cifradas, por lo tanto el fichero en teoría es seguro. El formato elegido ha sido lo más simple posible, un fichero de texto en el cual por cada línea hay una contraseña y los campos están separados por barras verticales.
En este proceso he tenido algunos problemas con las codificaciones pero parece que lo he acabado solventando.
La importación funciona a modo de mezcla, comparando por fecha de actualización si una contraseña ya existe, y en tal caso prevalece la que tenga fecha de actualización posterior. En ningún momento se borran contraseñas durante la importación, eso lo dejaré para otro proceso similar que será una importación con preferencia.
Esta nueva funcionalidad la he implementado en los dos clientes que llevo por el momento, que son el cliente de terminal y el cliente web.
Cambios en el cliente web
Para dar soporte a esta funcionalidad he añadido una nueva página al cliente. Esta página es la de "Opciones". Además ya que he creado una nueva página he añadido la funcionalidad de cambiar la contraseña del usuario de GECO y la posibilidad de borrar la cuenta del servidor, que ya estaban implementadas en gecolib y en el cliente de terminal.

Además, dado que tenía que hacer que estas páginas sean accesibles he añadido un pequeño menú.
Por otra parte, había otro tema que tenía pendiente en el cliente web, y es que no controlaba los errores debidamente. Así que hoy he añadido una página de error para que cuando pase algo inesperado no salga un mensaje feo, sino una página más o menos bonita.

Aún así se puede ver que la página está muy bien, pero no muestra nada de información, así que cuando ocurra un error habrá que investigar el por qué desde el lado del servidor y no del cliente :P

Hoy ha llegado un comentario al blog preguntando lo siguiente:
Buenas, estoy muy interesado en aprender sobre domotiica, pero no se por donde empezar se que linux tiene muchas aplicaciones de domotica y conozco de oidas alduino. Ahora bien ¿no seria mejor Arduclema o ardabasto para una instalacion electrica?
¿de ser un si donde lo consigo? ¿Es [...]

Heyu es un programa completamente libre y escrito en C, utiliza el convertidor serie que permite hacer una interfaz entre la aplicación y los módulos X10, de tal forma que es posible enviar señales de apagado y encendido de aparatos electrónicos, aumento de brillo en caso de lámparas, todo esto enviando señalizaciones a traves de [...]

En post anteriores vimos que para IcePick se utilizaba un entorno de pruebas desarrollado como herramienta auxiliar durante el proyecto. También se vio un ejemplo de uso básico donde se mostraban las principales características del entorno de pruebas.
Ahora se expondrán las posibilidades que ofrece el entorno de pruebas para realizar tareas justo antes de ejecutar las pruebas y justo después de ejecutarlas.
La filosofía es similar a muchos entornos de pruebas actuales como JUnit. La clase CUT de Junit (Class Under Test) puede implementar 2 métodos especiales:

• setUp(): se realizarán las operaciones incluidas en ese método antes de ejecutar cada método de prueba.
• tearDown(): las sentencias incluidas en este método se ejecutarán tras ejecutar cada método de prueba

Nuestro entorno de pruebas ofrece algo muy similar pero no a nivel de clase. Los métodos de prueba de Junit se pueden ver como un fichero de nuestro entorno de pruebas, por ejemplo, con varias líneas del tipo +CMD. De esta forma, se definen 4 ficheros especiales para nuestro entorno de pruebas:

• _setup: se ejecutará antes de cada fichero de prueba.
• _teardown: se ejecutará después de cada fichero de prueba.
• _global_setup: se ejecutará antes de ejecutar las pruebas del directorio que lo contiene.
• _global_teardown: se ejecutará despueś de ejecutar todas las pruebas del directorio que lo contiene.

Retomando el ejemplo de mycat podemos hacer que antes y después de la prueba se borre el archivo output.txt para asegurar que la prueba no genera un fichero que no sea el esperado.
Para ello creamos un fichero llamado _setup en el directorio proyecto/test/:
# +CMD: python _teardown
Y, ahora, un fichero llamado _teardown para borrarlo al terminar la prueba:
# +CMD: python $file
 
import commands
commands.getoutput("rm -f output.txt")
Como vemos por el contenido de _setup, al comenzar cada prueba se ejecutará _teardown (que borrará el fichero output.txt si existe). Y, tras cada prueba, se ejecutará _teardown que volverá a borrar el archivo. Es una forma posible, se puede hacer de otras muchas.
Esta manera nos permite presentar el argumento especial $file en el comando de _teardown. $file representa el nombre del archivo en el que se encuentra la prueba, es decir, _teardown. De esta forma, la cadena de prueba quiere decir que “hay que ejecutar esperando un resultado correcto (+CMD) el comando “python _teardown”. Con ello, si cambia el nombre del fichero, no haría falta cambiar el argumento de la prueba ya que el tester se encargará de poner el nombre correspondiente.
Si ejecutamos todo ello con el entorno de pruebas con el comando:
$ ./tester.py -v proyecto/test
Obtenemos la siguiente salida:
[tester:I]: exec 'python _teardown'
[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
[tester:I]: exec 'python _teardown'
--------------------------------------------------------------------------------
[ OK ] 2 tests
time: 0.0527 s
** All passed!! **
Vemos que al principio de la prueba se ejecuta exec ‘python _teardown’, correspondiente al _setup y, al final de la misma vuelve a ejecutarse exec ‘python _teardown’ (o python $file de _teardown).
En el siguiente post se hará una ejemplo completo, utilizando todas las características del entorno de pruebas, sobre el compilador.

Después de varios meses trabajando en la sombra volvemos a resurgir, eso sí, públicamente hablando, porque durante estos tres meses hemos estado intensamente dedicados al proyecto (la justificación de nuestro silencio). Os preguntareis, y no sin razón, qué hemos estado haciendo durante tanto tiempo (desde la entrada del nuevo año) en los que no hemos [...]

Hace poco terminé la carrera de ingenieria técnica y empecé un master en software libre. Para colmo también estoy metido en otro proyecto de software libre que me come un poco de tiempo. Hace días que tengo la memoria por aquí y ahora ya la he subido.
Tengo que mejorar unos scripts (añadir la licencia GPLv3 que me olvidé) y los subiré. (Son los scripts de los que hablo en la memoria).
Yo resumo la memoria como una documentación práctica del uso e instalación de Fully Automatic Installation aunque se le pueden dar más interpretaciones. No sé habla nada de la interfaz gráfica que es en lo que tendría que trabajar ahora. No sé qué cuánto podré conseguir.
Lo dicho, dentro de poco subiré los scripts… quería desempolvar el proyecto y de cara a los últimos meses del concurso eso es muy importante.
Memoria de Desdeslin
Adrián Gibanel

Se detallan a continuación algunos de los logros alcanzados:

• Más de 5000 horas de trabajo.
• Funcionamiento ininterrumpido comprobado durante más de 7 días (del 26 de noviembre al 2 de diciembre). Lo que dice mucho de su estabilidad.
• Más de 200 mil ediciones hasta la fecha. En torno a la mitad de ellas han sido reparaciones a páginas, el resto avisos a usuarios.
• Tasa de acierto del 99,5% según datos de diciembre de 2008. Primero fue mejorado con las puntuaciones, posteriormente con los contrapesos.
• Ningún bloqueo por malfuncionamiento.

Algunos de los usuarios de Wikipedia también han expresado su satisfacción con el trabajo del bot. También pasó la autorización para poder ejecutarse con 19 votos a favor y 0 en contra. Un signo de que la comunidad quiere que el bot continue trabajando lo constrituye la página de sugerencias, desde donde se pueden pedir nuevas funcionalidades para el programa.