Planet

Bueno, parece que he tenido suerte y entregué el anteproyecto justo cuando la comisión académica iba a reunirse para estudiar las solicitudes.Ya tengo el anteproyecto aceptado, por lo que en teoría ya puedo ponerme con él (aunque ya estuviera puesto).[ironic]¡Ah! Estos temas burocráticos que tanto me gustan... [/ironic]

Según este diagrama que me da la forja de rediris parece que voy cumpliendo la planificación :D

Como ya comenté, compagino la elaboración de mi PFC con mi trabajo dentro del grupo ARCO, lo cual hace que, en ocasiones, pueda dedicarle menos tiempo del deseado al proyecto.Pero en otras muchas ocasiones este trabajo me permite aprender sobre herramientas que me pueden ser de muchísima utilidad en el proyecto, cómo ha ocurrido en estos días pasados con IceGrid.IceGrid es uno de los servicios avanzados que proporciona ZeroC dentro de su middleware Ice. Según el manual de Ice, IceGrid es un servicio importante para construir herramientas robustas.De una forma más coloquial, se puede decir que IceGrid es un servicio que permite desplegar aplicaciones en una serie de nodos de forma transparente, sin tenerte que preocupar nada más que de tener lista la aplicación, su configuración y poco más. Claro, decir esto es simplificar en demasía: para que esto fuera así deben entrar en juego otros "actores" como IcePatch2 (que permite enviar los ejecutables a los nodos desde un servidor) o "icegrid-gui", que es una aplicación que permite configurar el nodo "registriy" (una suerte de director de orquesta) y decidir que aplicaciones se despliegan y dónde de una forma rápida e intuitiva.De todos modos esto es un claro ejemplo que nunca se pierde el tiempo si aprovechas para aprender cosas por el camino. Está claro que para mi PFC IceGrid va a desempeñar una función principal para simplificarme la distribución de los nodos de mi sistema por la red.

Durante estos días he estado peleándome con la creación de una placa personalizada, en la que integrar los motores y los giroscopios con la idea de que sea lo más autónomo posible , para que si se produce algún tipo de problema poder mantenerse nivelado y más adelante poder incluso aterrizar, un "Sistema de seguridad".
leer más

Tras un par de semanas escribiendo el anteproyecto para presentarlo en mi facultad, ya está hecho y presentado. La solicitud de estudio del mismo la presenté el 14 de Enero.En el anteproyecto he hecho una presentación del estado general de la cuestión: la necesidad tener mejores mecanismos de interacción y comunicación entre dispositivos multimedia, debido al crecimiento que ha sufrido el mundo en este ámbito durante los últimos años (teléfonos, videoconsolas o hasta despertadores...).En el anteproyecto también he querido darle una utilidad práctica dentro del mundo de la enseñanza, ya que al fin y al cabo este documento trata sobre "vender la moto" para que valoren de forma positiva que tu "pierdas" tu tiempo en hacer ese trabajo.En el documento también explico la metodología de trabajo que voy a seguir. En principio, RUP, aunque debido a la naturaleza modular del proyecto, que estará compuesto de muchas "piezas" que funcionarán juntas, puede que en alguna de esas "piezas" se utilice alguna otra metodología (como TDD, que personalmente a mi director de proyecto y a mi nos gusta bastante, pero no es aplicable en algunos de los elementos del proyecto).Cómo ya hice en mi post sobre selección de herramientas, en el anteproyecto también he hablado de los lenguajes y herramientas que voy a utilizar.Dado que el PFC lo estoy haciendo en mi ámbito de trabajo (el grupo de investigación ARCO) voy a disponer de algunos recursos, sobre todo hardware, que me permitirán desarrollar algunas cosas interesantes, como un servidor de medios de cámaras AXIS, otro para cámaras web que usen Video For Linux... y en fin, muchos aparatitos donde implementar partes de mi sistema de cara a una buena demostración.¡Ah! Se me olvidaba. El anteproyecto está hecho usando LaTeX, y la futura documentación del PFC también lo estará...

A veces en un ordenador necesitamos tener datos que tenemos en otro y a los que vamos a modificar. Por ejemplo, en mi caso, tenía una copia de trabajo svn ...

Como os comenté en el post anterior, sigo liado aprendiendo C, para poder encriptar una contraseña que es comparada en el servidor, para comprobar la validez de los datos enviados y que no ocurra un ataque por terceras personas. Pero también he seguido trabajando con el parser, ya que el parser anterior el eje X, de cada dato, aparecía un índice que era introducido automáticamente por el programa para ordenar los datos, ahora lo que se introduce como eje X son la fecha y hora en la que se recogió el dato, he encontrado un pequeño bug, y es que no me ordena todavía las gráficas pero ya se como solucionarlo, para que veais los cambios os adjunto unas fotos. También estoy liado montando el servidor que va a anidar la pagina web, donde se podrá visualizar las gráficas creadas por el parser. Espero que pronto consiga terminar con la implementación en C, para subir de una vez la primera versión.
Antes:

Después:

Bueno, me ha dado tiempo a hacer una prueba del método que se me ocurrió para solucionar lo de OSGi y Web Services en la misma aplicación y funciona. Ahora sólo necesito un hueco para hacerlo bien hecho.
En realidad el proyecto me está volviendo loco porque poco a poco se está convirtiendo en una especie de cosa monstruosa que está devorando mi vida (menos mal que vivo solo). Ahora que llevo un tiempo con la parte hardware y triposa del proyecto se me olvidan los detalles de la parte Java. Y ahora que tengo que regresar a la parte Java no puedo porque tengo que atender a la parte documentación. Aargh.
En fin, la solución en sí es tonta de sencilla que es (en esencia, por lo menos). No puedo tener una aplicación con OSGi y Web Services al mismo tiempo que funcione sólo con el framework Felix y no con un bicharraco como GlassFish. Pues separo la parte OSGi por un lado y la parte Web Services por otro.
La cosa es mantener Oolong tal y como está ahora. Hacer un pequeño cliente de Web Services que se ejecute junto con Oolong y coja los datos publicados por la placa. Este cliente a su vez es un servidor al que se conecta Oolong por sockets (dentro de la misma máquina, se supone), y que envía objetos serializados que son recogidos por Oolong y que contienen los datos publicados por la estación. Tachán.
Por supuesto, habrá que ver la mejor forma de implementar esto, pero por lo menos ya es algo. Y funciona.

Y por fin llego el día... ya ha empezado el trabajo duro y de darse de palos con las librerías, el entorno (Eclipse), la forja con su SVN y todo lo demás pero es fácil si se intenta y hoy por fin a partir del diagrama de clases creado con Umbrello he autogenerado código, lo he editado un poco y ya se encuentra la estructura del programa en la forja.

Buenas a todos!!
Después de una espera larga, ya estoy totalmente centrada en mi proyecto y una de las primeras tareas más importantes era tener al fin instalada y montada mediaWiki. Para ello, pensé en usar como servidor mi propio sobremesa o intentar alojarlo en un servidor externo mucho más seguro (ya que a saber lo [...]