En la web del pasado eran las organizaciones las que colgaban la mayoría de los datos. En la web de hoy cada vez somo más los que modificamos la web, ya sea en forma de comentario de un blog o una entrada del muro de Facebook o un video-mensaje a un amigo,profesor,etc., i.e., la mayoría de los datos ,alrededor del 60% lo cuelgan los usuarios y según Mark Zuckerberg, el 25% del tráfico que se realiza a través de las redes sociales, unos espacios privilegiados de intercambios y de participación.
Nosotros utilizábamos la Web 1.0 como un soporte que permitía navegar de un documento a otro con una fluidez imposible en otros medios de comunicación y sin embargo la interacción no eran del todo completa, hoy en día, todos formamos parte del nuevo juego llamado Web 2.0, rompiendo todo tipo de límites o barreras internacionales, programadores de todo el mundo contribuyen en todo tipo de proyectos con nuevos módulos usando las “API” de las aplicaciones web,i.e., la máxima expresión de la interoperabilidad y la participación.
El diseño de las herramientas modulares del proyecto PIE sigue un esquema sencillo que viene detallado así:
En lugar de simplemente recibir, producimos, publicamos, extendemos las funcionalidades, actuamos. Como usuarios activos, somos consumidores/creadores, lectores/escritores, oyentes/locutores, espectadores/productores. Tenemos incluso el poder de organizar todos esos datos (informaciones, conocimientos, creaciones) atribuyéndoles etiquetas hechas por nosotros.
Como es de esperar ,cada vez hay más usuarios que utilizan redes sociales para comunicarse y “pedir los apuntes” al compañero porque estuvo enfermo el día anterior jeje
Esta es la presentación que hice sobre agrupamientos
Clustering Agrupamientos
Ya está aquí, tanto la librería de Arduino como la de Mister House, además de una configuración inicial de una casa utilizando integramente Arduino.
La dirección de la descarga es:
http://forja.rediris.es/frs/download.php/1210/Libreria-V1.0.zip
Y podéis encontrar las siguientes carpetas:
Arduino: donde se encuentra la librería con la que se debe programar a Arduino.
MisterHouse: donde se encuentran los directorios:
bin: se encuentra mh.private.ini [...]
Actualmente estamos probando el compartamiento de la base de datos a la hora de manejar los datos. Hemos realizado una primera prueba con la letra ‘l’ para la cuál funciona, pero no aún de la manera que más nos gustaría. Adjunto una imagen del conjunto de signos que forman el abecedario:
abecedario lenguaje signos
Estamos utilizando un complemento para Firefox para gestionar la Base de Datos, SQLite, el complemento se puede encontrar aquí: https://addons.mozilla.org/es-ES/firefox/addon/5817.
Por último, comentar que al usar SQLite, no podemos definir Foreign keys como tal, si no, que deberemos utilizar un trigger para solucionar este “problema”.
En symfony cuando usamos el helper “object_select_tag($Object, ‘method’)” tenemos que usar el método que devuelve el Id y no ell objeto exterior que queremos seleccionar. Si no al guardar se producirán errores debido a que para poner los nombre busca con el id obtenido el objeto concreto y tendríamos un enlace de más.
When we use “object_select_tag($Object, ‘method’)” we must be careful to use the method that answers the id instead of the one which answers the Object. Symfon will produce an error because to obtain the names of thes elect calls to the object and the object cannot be called by himself in that way.
¿Cómo capturamos los paquetes?
Como viene explicado en el anterior post meshias se pone en funcionamiento cada vez que tenemos que mandar un paquete. En ese momento debemos capturar el paquete para averiguar hacia donde va dirigido. Una vez averiguado hacia donde va dirigido comprobamos en la tablas de rutas del kernel si sabría enrutarlo. Este proceso es bastante sencillo de entender, no ha sido igualmente facil para programarlo.
Hemos necesitado dos librerías auxiliares para hacer este trabajo. Para capturar los paquetes hemos utilizado libnetfilter-queue, a partir de ahora nfqueue. Nfqueue es una herramienta del equipo de netfilter que nos permite hacer cosas muy curiosas. Su funcionamiento la podemos dividir en dos partes. La primera es que necesitamos reglas de iptables. Iptables es el firewall de núcleo Linux, también desarrollado por el equipo de netfilter y que nos permite, entre otras muchas cosas, crear una regla para los paquetes que cumplan las condiciones necesarias, pasarlas a cola de nfqueue. Esto significa que podemos crear reglas de iptables que irán encolando los paquetes que nosotros queramos para tratarlos manualmente.
Una vez en la cola de nfqueue podemos aceptarlos, robarlos o tirarlos para que no sigan su camino. Robarlos significa que podemos mantenerlos en espera hasta que queramos aceptarlos o tirarlos posteriormente. Nosotros lo único que hacemos es mirar a qué IP están dirigidos los paquetes, para comprobar si existe una ruta para el paquete; si existe lo aceptamos sin más, y entonces el paquete es enrutado y enviado por la interfaz de red correspondiente. Si sin embargo no tenemos la ruta para la IP de destino de ese paquete y esa IP está dentro del rango de direcciones de la red mesh que está usando meshias (por ejemplo la red 192.168.1.X) lo robamos hasta averiguar la ruta. Si no la encontramos tiramos el paquete o si lo encontramos agregamos la ruta al kernel y lo aceptamos.
Manejando rutas
Hemos dicho que usamos principalmente dos librerías. Pues si la primera era nfqueue, la segunda es libnl.Esta ruta es una interfaz que nos permite comunicarnos con el kernel mediante sockets netlink, pero que nos oculta su funcionamiento interno y nos ofrece una interfaz más cómoda de usar. Como bien explican en la wikipedia, los sockets netlink son usados por muchas aplicaciones de red para comunicarse con el kernel, por ejemplo iproute los usa.
Nosotros usamos libnl para agregar o quitar rutas si se cae un enlace lo hacemos a través del libnl. Una vez conocida la ruta para una dirección ip, la añadimos a la tabla de rutas con libnl. Pero ahí no acaba nuestro trabajo: tenemos que mantener la ruta actualizada. Las redes mesh tienen un carácter más o menos dinámico, y los nodos pueden conectarse, desconectarse,y moverse de lugar con el tiempo. Por ello si no recibimos actividad por cierta ruta tras cierto intervalo de tiempo, asumimos que algún nodo de la ruta ya no está ahí, y tenemos que borrar la ruta de la tabla de rutas. El borrar de la tabla de ruta también lo hacemos con libnl.
Hay otro tipo de ocasiones en las que también necesitamos borrar rutas. Como ya contamos en la entrada anterior del blog, una ruta puede tener varios nodos intermedios por los que va saltando el paquete hasta llegar a su destino. En el párrafo anterior hemos contemplado que si una ruta deja de estar activa cierto tiempo debemos asumir que algún enlace de la cadena se ha roto y por tanto tenemos que invalidr la ruta. Bien, pues gracias a que libnl nos permite conocer el estado de los nodos que están cerca nuestra mediante la tabla de vecinos,podemos saber si un vecino ya no está ahí. Si un vecino deja de serlo, libnl nos avisará, y nosotros entonces comprobaremos si teníamos alguna que pasaba por ese vecino. En caso de que sea así, tendremos que borrar la ruta. Esto actualmente no lo tenemos implementado y en AODV es opcional (está contemplado como detalle de implementación), pero planeamos hacerlo.
La base de datos actual a sufrido diversos cambios con respecto a la inicial, de todas formas aquí les mostramos como fue nuestro primer boceto y como nos enfrentamos al problema de lograr convertir esas ideas en tablas que nos fuesen útiles.
Para realizar la conexión con la base de datos a través de Mono usamos una de sus librería en conjunto con la librería de SQLite3, la librería de Mono es “Mono.Data.Sqlite.dll” y se encuentra en la carpeta donde se instalo Mono mas concretamente en esta ruta “Mono-2.2\lib\mono\2.0″ con añadir esta última librería a las referencias de nuestro y soltar la libreria de SQLite3 en la carpeta donde estemos ejecutando nuestro programa podremos realizar la conexión la base de datos.
Al principio este blog iba a ser para comentar el desarrollo de eOPSOA y discutir decisiones de diseño, explicar como trabajo... etc. Sin embargo, y debido a que casi todo el tiempo que tengo lo dedico a diseñar y programar, apenas he escrito nada sobre el desarrollo. Eso de dejar que el código hable por uno mismo está bien, pero hay veces que uno usa herramientas o tiene truquillos que quizá sean interesantes, y que quizá sean interesantes para los demás.Como comenté antes, la metodología de trabajo que sigo es una adaptación de RUP. Tengo marcadas unas iteraciones, y en cada iteración hay una serie de tareas que tengo que realizar. Normalmente lo que suelo hacer al principio de cada iteración es realizar es modelar los requisitos funcionales y el diseño para esa etapa usando Rational Rose y Rational Requisitepro. En los directorio /management/trunk/analysis_design y /management/trunk/requirements podrás encontrarlos. Además, otra tarea que realizo es esbozar la UI, que es de lo que os quiero hablar. Luego le presento todo eso a los tutores del proyecto, y con las correcciones que me hacen vuelvo a actualizar todo y ya me pongo a programar. Hasta ahora no había subido al repositorio los esbozos de la UI, pero a partir de ahora los iré metiendo en /management/trunk/ui_sketches. Al principio usaba papel y boli, pero el problema que tiene es que al final siempre terminaba perdiendo los esbozos, y como que no tengo scanner difícilmente iba a poder enviarlos por correo. Estuve buscando herramientas de prototipado de interfaces, y la herramienta que más me gustó, y que vengo utilizando, se llama WireframeSketcher, y es otro plugin sobre Eclipse. Como nota friki decir que utiliza EMF y GMF, es curioso lo que se puede hacer con estas herramientas :-). La lástima es que es software propietario, pero el autor no tiene problemas en dar licencias a aquellos que se pongan en contacto con él y participen en un proyecto de Software Libre. Además ha comentado varias veces que en un futuro cercano tiene pensado sacar una versión gratuita más o menos funcional, y quién sabe, quizá hasta termine liberando algo. El ritmo de desarrollo es brutal, y poco a poco se van añadiendo funcionalidades que lo hacen un software muy útil.Las dos imágenes anteriores se corresponden al prototipo que hice, y a la pantalla final que resultó. Aunque quizá la paleta de controles de WireframeSketcher es un poco pequeña, al menos en mi caso es suficiente y se ajusta bastante bien a los controles que ofrece JFace/SWT. Y ya para dejar de hacer spam comentar que la ventaja principal que le veo a otras herramientas de prototipado como Pencil es que es muy sencillo y rápido de usar, y que funciona realmente bien. Además que aunque sean en blanco y negro, salen los esbozos mu bonicos si O:-)Por último, he subido en el área de documentación de la forja una serie de PDFs que usé para estudiar los prototipos de interfaz de eOPSOA que he estado haciendo.