Planet

Pues uno de los cambios que quería efectuar después del concurso era cambiar la web para que fuera algo más fácil la actualización de la información. Se ha cambiado la web http://proyecto-canyafote.homelinux.org, ahora es una pequeña wiki donde iré subiendo las nuevas versiones. El proyecto no está parado, lo que pasa es que con los exámenes estoy un poco saturado y no he podido seguir trabajando. Cuando acabe los exámenes espero subir dos nuevas versiones. También he colocado un pequeño foro, que lo he obtenido desde www.foroactivo.com. Estos foros te lo regalan bajo una licencia GPL. He abierto tres secciones Bugs o problemas Hardware, Bugs o problemas Software y Dudas. Si queréis más secciones o me podéis echar una mano para administrar el foro o si creéis que debo añadir más secciones en el foro, podéis poneros en contacto a partir del correo del concurso proyecto.canyafote@gmail.com
Álvaro

Acabo de sacar una nueva versión del editor de cómics para gnome TBO
Se puede descargar desde:
http://trac.danigm.net/tbo/wiki/downloads y el paquete debian está actualizado en el repositorio de sugus
Cambios desde la versión 0.95:

• Added TBO cusl4 presentation
• Added political doodles. First Zapatero
• New PKGBUILD version
• gtk 2.12 compatible
• Removed debian package versions and added librsvg
• Added bubble tool. Removed bubbles from doodle tool
• Rajoy doodle by Alfonso de Cala
• Added southpark style doodles thanks to bladecoder
• Added misc bubbles
• Added bladecoder to artist list.
• Added TBO tutorial

La siguiente versión será la 1.0 y está planificada para finales de agosto. En esta versión quiero meter el deshacer, y arreglar algunos detalles de usabilidad sobre la interfaz.

Kracker es un pequeño tracker para el protocolo Kraken escrito en Python sobre el framework Tornado. Implementa el formato de anuncio al tracker que describí en esta entrada. Esta es ...

En esta receta explicaré como poner en funcionamiento uno de los elementos de Argos: el MediaServer especializado para las cámaras IP de marca AXIS.InstalaciónComo ya comenté en otras entradas, el MediaServer está implementado como servicio IceGrid. Por ello, he distribuido un binario en forma de paquete DEB para Debian. Para poder instalarlo, añade lo siguiente en tu archivo /etc/apt/sources.list deb http://babel.esi.uclm.es/gnesis/ unstable mainUna vez hecho esto tan solo hará falta hacer lo siguiente: # aptitude update; # aptitude install libaxismediaserverDicho paquete instalará las dependencias necesarias para hacer funcionar "el invento" y, además, incluye un fichero XML con la configuración mínima para poder cargarlo en IceGrid-GUI y ver como configurarlo. Dicho fichero se encuentra en /usr/share/doc/libaxismediaserver/template.xmlPuesta en marchaPara la puesta en marcha supondré que tenemos una cámara Axis en la IP 192.168.0.5. El servicio se puede arrancar de dos formas: a mano, ejecutando icebox y pasándole un fichero de configuración con los parámetros correctos o bien utilizando IceGrid-GUI y la plantilla suministrada con el paquete.Usando icebox y dicheros de configuraciónPara arrancar el servicio "a mano" necesitaremos dos ficheros de configuración diferentes:

• El primero será en el que le especifiquemos a IceBox que librería cargar y una serie de configuraciones de administración de los servicios ejecutándose en ese IceBox.

• El segundo es el que IceBox pasará a la librería y que contendrá parámetros que utilizará el MediaServer para Axis para funcionar.

Ejemplo del primer fichero de configuración:IceBox.Service.AxisMediaServer=AxisMediaServer:createAxisMediaServer --Ice.Config=config_AxisMediaServerIceBox.InstanceName=AXIS.192.168.0.5IceBox.LoadOrder=AxisMediaServerIce.Default.Locator=IceGrid/Locator:tcp -h locator.ip -p 4061En este fichero deberíamos configurar el nombre del fichero pásado en la primera línea a nuestro servicio, si tuviera otro diferente, y el proxy del Ice.Default.Locator de la última línea. El nombre de instancia de IceBox no es problemático, pero si convendría adaptarlo a nuestro escenario.El segundo fichero de configuración contendría información relativa a nuestro entorno:AxisMediaServerAdapter.Endpoints=defaultAxisMediaServer.IP=192.168.0.5AxisMediaServer.User=userAxisMediaServer.Password=passPropertySetFactory.Proxy=PropertySetFactory @ AutoPropertyService.AdapterIce.Default.Locator=IceGrid/Locator:tcp -h locator.ip -p 4061Al igual que en el ejemplo anterior deberemos adaptar la configuración del Default Locator y, en este casi, de la propiedad "PropertySetFactory.Proxy". Para tener funcionando este servicio de propiedades podemos recurrir a la documentación del paquete libpropertyservice33.Usando IceGrid y plantillasUtilizando ZeroC Ice, existe la posibilidad de utilizar IceGrid. Esta utilidad es un servicio avanzado del middleware para la administración de grids de nodos que ejecuten diferentes servicios.En el paquete libaxismediaserver se incluye un fichero template.xml. Este fichero puede abrirse utilizando IceGrid-Gui y utilizar las plantillas en él definidas para copiarlas a una aplicación dentro de nuestro registry.La ubicación de dicha plantilla es la siguiente:/usr/share/doc/libaxismediaserver/samples/template.xml

En alguna entrada anterior comenté que la parte del servidor iba a estar conectada a los dispositivos domóticos utilizando una biblioteca desarrollada el año pasado en la UGR como un proyecto fin de carrera.
La idea era engancharla con BlueRose y olvidarme de todo el rollo a bajo nivel. Pero resulta que:

1. La biblioteca es un mojón. Tanto el diseño como la implementación son una cossa maravillosssa.
2. No funciona.
3. Hay problemillas no-funcionales.

Así que vamos a diseñar una biblioteca desde cero y que además funcione. Y sin follones feos. El objetivo principal es tener algo funcionando en condiciones antes de que acabe el curso, aunque el diseño de la biblioteca deberá llevar más tiempo. Y es que hay muchos problemas para desarrollarla:

• Hay poca documentación sobre KNX más allá de los manuales. Pero tenemos a José Manuel (que es experto en KNX) y además los manuales, aunque tenerlos en formato electrónico sería más cómodo.
• KNX es un coñazo y hay poquísima documentación aparte del manual.
• Calimero, la biblioteca libre para comunicarse con KNX está en versión 2.0alpha4 desde 2008. Es decir, que está muerta. Al menos funciona y está muy bien hecha y comprobada. La alternativa sería usar Falcon para Windows, pero es cerrada y se basa en ¡¡DCOM!!
• No hay prácticamente nada de documentación sobre Calimero más allá del Javadoc y cuatro ejemplos.
• No conseguíamos echar a andar Calimero en GNU/Linux pero esta tarde lo hemos conseguido .

En resumen, que va a haber que echarle bastante tiempo a este tema, pues es bastante complejo. Vamos a tener que hacerlo casi todo mediante ingeniería inversa.
Por ahora hemos conseguido conectar el ordenador al entrenador y cambiar los valores de algunos dispositivos, así que ya hemos avazado algo:

Seguiremos informando, ojalá pueda subir pronto un vídeo de Kora funcionando al 100%.

En el blog de Gitorius tenemos una muy buena guía de estilo del código Qt. Lo podemos tomar como una referencia a la hora de declarar funciones y métodos, objetos, variables, etc. El texto está en inglés y explicado de forma muy sencilla, pero creo que es bastante interesante y conveniente traducirlo, para evitar el "yo no sé inglés", jejejeje. Aquí tenéis la traducción (de forma resumida):
Sangrado

• Sangrar con 4 espacios en blanco.
• Usar espacios, no tabulaciones.

Declarando variables

• Declarar cada variable en una línea diferente.
• Evitar nombres cortos siempre que sea posible.
• Variables de un solo carácter se recomiendan sólo si se usan para contadores, dónde el propósito de la variable es obvio.
• No declarar una variable si no es necesaria.

// Mal
int a, b;
char *c, *d;
 
// Bien
int height;
int width;
char *nameOfThis;
char *nameOfThat;

• Las variables y funciones empiezan con letra minúscula. Cada palabra en el nombre de la variable empieza en letra mayúscula.
• Las clases siempre empiezan con una 'Q' mayúscula (QDieta).

Espacios en blanco

• Usa líneas en blanco para agrupar declaraciones.
• Usar sólo una línea en blanco.
• Siempre usar un espacio en blanco despues de un carácter, y antes de un corchete.

// Mal
if(foo){
}
 
// Bien
if (foo) {
}

• Para punteros y/o referencias, siempre usar un espacio en blanco entre el '*' o el '&', pero no usarlos entre estos y el nombre de la variable.

char *x;
const QString &myString;
const char * const y = "hello";

• Ningún espacio después de un "cast".
• Evitar los "cast" como en C, en la medida de lo posible.

// Mal
char* blockOfMemory = (char* ) malloc(data.size());
 
// Bien
char *blockOfMemory = (char *)malloc(data.size());
char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));

Corchetes

• Como regla básica, el corchete izquierdo estará en la misma linea de inicio de la declaración:

// Mal
if (codec)
{
}
 
// Bien
if (codec) {
}

• Excepción: Las implementaciones de funciones y las declaraciones de clase siempre tendrán el corchete izquierdo en una nueva línea:

static void foo(int g)
{
qDebug("foo: %i", g);
}
 
class Moo
{
};

• No usar corchetes cuando la declaración de una condición tiene una línea:

// Mal
if (address.isEmpty()) {
return false;
}
 
for (int i = 0; i < 10; ++i) {
qDebug("%i", i);
}
 
// Bien
if (address.isEmpty())
return false;
 
for (int i = 0; i < 10; ++i)
qDebug("%i", i);

• Usar corchetes cuando la declaración es vacía:

// Mal
while (a);
 
// Bien
while (a) {}

Paréntesis

• Utilizar paréntesis para agrupar expresiones:

// Mal
if (a && b || c)
 
// Bien
if ((a && b) || c)
 
// Mal
a + b & c
 
// Bien
(a + b) & c

DisSim visto a través de Gource, aprovechando que ahora usamos Git :D. Parece mentira que hayan pasado ya casi 5 meses desde el primer commit.

Mis pequeños dominobots siguen fielmente mis órdenes y juegan para mí sin descanso. Lo siguiente será que me hagan la comida, limpien la casa y cuenten chistes por mí.
Por cierto, si a alguien se le ocurre una forma ingeniosa y fácil de hacer el volteo de las fichas (cuando pasan de boca arriba a boca abajo) se le gratificará con una gratificación gratificante.
CUSL

Un apunte rápido para referencias futuras, ¿cómo convertir una cadena a mayúsculas o minúsculas? Con boost:
#include <boost/algorithm/string.hpp>
#include <string>
#include <iostream>
int main(){
std::string cadena = "HoLa SuRmAnItO";
boost::to_lower(cadena); // ó boost::to_upper(cadena);
std::cout << cadena << std::endl;
// Si no queremos modificar la cadena original, hacemos una copia
cadena = "HoLa SuRmAnItO";
std::cout << boost::to_upper_copy(cadena) << std::endl;
}

Este artículo está vilmente copipegado del blog de la OSL. Pasaos por el !BarraLibre que va a estar muy interesante. Además va a haber buen tiempo, wena hente (la créme de la créme del frikerío granaíno), buena comida y alguna sorpresilla . Echadle un ojo a la wiki y ya lo veréis.
Por cierto, aprovecho también para recordarle a los participantes y organizadores del CUSL que están más que invitados, contamos con vosotros .
El próximo 10 de Junio, en la Escuela Técnica Superior de Ingenierías Informática y Telecomunicaciones de la Universidad de Granada, se celebrará la primera !BarralibreCamp.
La !BarralibreCamp está abierta a todo el mundo, aunque se recomienda encarecidamente que te apuntes antes en el formulario creado al efecto (y, a ser posible, también en el wiki) por cuestiones de organización.
La !BarralibreCamp es una Barcamp, un evento autoorganizado en el que todos los asistentes son también participantes.
Una barcamp no se divide entre ponentes y publico, si no que todos los participantes están invitados a hablar y escuchar. Tampoco tiene programa, si no que se va organizando in situ y sobre la marcha, con una mínima preparación previa.
La idea detrás de todo esto es que la !BarralibreCamp sea un evento intenso y activo, donde se aprenda a través de la participación.
En la !BarralibreCamp, como en cualquier barcamp, hay una pizarra donde se indican las aulas o espacios disponibles y las horas, y cada cual puede incribir libremente su taller, ponencia o charla en el espacio que haya disponible. Desde ese momento, cualquier otro asistente puede decirdir inscribirse.
En la !BarraLibreCamp, el tema es el software y la cultura libres en todos sus aspectos: enseñanza, difusión, aplicaciones. Si usas, desarrollas, enseñas o quieres enseñar software libre, serás bienvenido.
Pensamos que el software es libre. Pero nos gusta aclarar que es libre como el sol cuando amanece, no como en la barra libre.
De ahí el !BarraLibre (NOT BarraLibre): No es barra libre.
Tradicionalmente, las barcamps tiene algunas reglas:

• La primera regla del Barcamp es “Todo el mundo habla del Barcamp”.
• La segunda regla del Barcamp es “Todo el Mundo postea (y twittea, y facebookea…) del barcamp”.
• La tercera regla del Barcamp es “Si vas a presentar algo, pon tu nombre y el tema del que hablarás en el tablón de anuncios”.
• La cuarta regla del Barcamp es “Introducciones de tres palabras”.
• La quinta regla del Barcamp es “Tantas presentaciones a la vez como las instalaciones permitan”.
• La sexta regla del Barcamp es “No hay presentaciones preprogramadas, no hay turistas”.
• La séptima regla del Barcamp es “Una presentración durará el tiempo que necesite, o hasta que comience la siguiente en el tablón”.
• La octava regla del Barcamp es “Si es tu primer Barcamp, DEBES presentar algo (Vale. No DEBES hacerlo, pero intenta encontrar algo que presentar o, por lo menos, haz preguntas y sé un participante activo)”.

Ven y participa.