Planet

Nuevo sistema de plugins.

No digo que dentro de otro par de semanas el sistema de gestión de plugins me parezca una aberración y vuelva a implementarlo, sino que ya tenemos una referencia.
Como anticipaba hace unas semanas, el sistema de plugins no es el ideal por lo que estoy rediseñandolo. Antes de explicar cual va a ser el nuevo diseño voy a explicaros como funciona el actual y así resaltar sus problemas.

  • Los plugins se identifican por heredar de una de las subclases de plugin, AnonymousPlugin, UserPlugin o PremiumPlugin. A primera vista esto seria correcto porque son los tipos de acceso que dan nuestros servicios, pero la realidad es otra. Un plugin anononimo debe gestionar los slots de descarga que le permite el servicio que implementa, por el contrario un plugin premium no tiene restricción de slots pero necesita gestionar las cuentas. Los plugins de usuario pueden ser una mezcla de los anteriores.
  • Por otro lado un plugin anónimo le dice al gestor de servicios que servicio implementa y como comprobar los links de ese servicio por lo que puede haber varios plugins colisionando con el mismo servicio.
  • Finalmente cada plugin debe implementar los parsers que use, las subidas y las descargas haciendo su código largo y complejo, además de llenar el directorio de plugins de archivos que realmente no son plugins, sino clases auxiliares usadas por estos.

Todos los problemas anteriores tienen solución y ahora mismo ese sistema de plugins esta funcionando correctamente, pero es un buen momento para un nuevo diseño que no sufra de estos defectos y que simplifique bastante la creación de los plugins.

  • El directorio de plugins contendrá un subdirectorio por cada servicio que soporte Tucan y en este directorio estará cada plugin relacionado con el servicio, ademas de un archivo de conflagración que contendrá las tareas que están implementadas. Así solo sera necesario un checklink por servicio y no por plugin, además de poder separar la funcionalidad en varios plugins.
  • Además AnonymousPlugin, UserPlugin y PremiumPlugin desaparecen y su funcionalidad la implementan Slots y Accounts, de esta forma un plugin para descargar de rapidshare de forma anónima tiene que heredar de Slots y Plugin (esto se hacia en AnonymousPlugin) quitando una capa de abstracción que realmente no hacia nada.

PD: Antes de ponerme con el nuevo sistema de plugins en un branch, implemente algunas mejoras en el gui. Os dejo unas capturas para que veáis lo nuevo de la versión 0.2.1.
Ahora podemos escoger de forma individual los links que empaquetamos.
Nuevo orden de los botones del toolbox que ya funcionan a excepción de Add Uploads y ya se muestra el estado tanto en el TrayIcon como en barra de estado.
Un saludo, Crak.
      

La capa física de CAN

Sin duda, una de las principales ventajas que ofrece un red CAN, es la poca cantidad de cobre que necesita para ser implantada, con tan solo un par de cables trenzados podemos conectar todos nuestros nodos. La información por estos cables viaja en modo diferencial, dándole a nuestro sistema una gran robustez frente al ruido.
Como podemos observar en el dibujo, el CAN-H tiene una tensión de 2.75V a 5V mientras que en CAN-L es de 0V-2.25V. Como es una tensión diferencial ( CAN-H - CAN-L ) = DATO de tal forma, que para conseguir un 0 lógico a la salida 2.75V-2.25V= 0.5V y para el 1 lógico es 5V-0V=5V. Creo que esto es un dato muy importante que en un futuro cercano usaremos para verificar que el envío a través de nuestra línea se produce correctamente.
Ahora voy a contar una de las cosas más curiosas de CAN, que hace que sea el sistema más robusto que he conocido. Resulta que si en algún momento alguno de nuestros cables sufre un accidente, ya sea porque se corte o por una derivación a masa, nuestro sistema automáticamente usará la otra línea referenciada a masa para seguir transmitiendo. Por ejemplo, en caso de que el CAN-H se derivase a masa, nuestro sistema usaría el CAN-L referenciado a masa (0V - 5V) para seguir transmitiendo los mensajes a los demás nodos.
Es necesario cerrar las líneas con elementos terminadores, estos son una simples resistencias que se calculan de forma empírica dependiendo del número de nodos y la longitud del cable. Estas resistencias se ponen al final y al principio de la línea puenteando el CAN-H y el CAN-L.
Para analizar el contenido de la línea en la práctica y de forma cómoda sería necesario usar un osciloscopio digital con dos canales, memoria y un ancho de banda de 20 MHz. A continuación podemos ver una imagen real de una medida en un bus CAN, eso si, el osciloscopio usado es de 100MHz.

Aunque en este caso los niveles de tensión del CAN-H y el CAN-L son distintos de los comentados, el concepto es el mismo. En color azul podemos ver el CAN-H y en el rojo el CAN-L.

Tareas de administración creadas

Tareas de desarrollo diseñadas
Tras pensar detenidamente las tareas a ejecutar para la creación del proyecto he visto adecuado hacer la siguiente clasificación

  1. Framework: Todo lo referente a la base del conjunto de librerías que me permiten realizar realmente rápido todo el trabajo gracias a zenphp.
  2. Aplicaciones web: creación del portal, además para móviles, con los dominios y subdominios:
    + http://www.examenes.org.es
    + http://www.examen.org.es (espejo)
    + http://m.examen.org.es (móviles)
    + http://m.examenes.org.es (móviles)
    Añadir las tareas para el Diseño de las plantillas web para los sitios web…
  3. Aplicaciones de escritorio: esos sencillos pero geniales programitas para mantenernos sincronizados con las cuestiones de nuestras asignaturas de la Facultad…se hace una encuesta para conocer todos los detalles que a los usuarios les gustaría tener en los “front-end” de escritorio para Windows y GNU/Linux…
  4. Datos e Ingeniería del Software: esquemas de la minería de datos, diagramas de flujo de información y de aplicaciones,diagramas de entidad/relación, generación de documentación, etc. (Desarrollo de Software Dirigido a Objetos)

Además se crean foros para el contacto de tod@s aquell@s que quieran unirse al proyecto…

Exámenes

Como alumno,sigo teniendo exámenes, en mi caso de Diciembre, por eso estoy bastante ocupado y entre descanso (en el curro no puedo!) y descanso mientras estudio, mirad que horas son! jaja, pues diseño el sistema, escribo código, etc.
Se ha actualizado la información del proyecto, se ha añadido un miembro al grupo de programación y administración
Asi que todo marcha!

255 MB enviados con éxito

Ahora toca hacer pruebas con la nueva versión. He enviado a un amigo un archivo ZIP de 255 MB y lo ha recibido correctamente, por lo que la prueba ha sido todo un éxito.
      

Animaciones

Pienso que un videojuego tiene dos partes. Una parte es la parte visible al usuario y la otra lo que yo llamo el núcleo del juego, en donde realmente el juego se desarrolla , su representación interna.
De la representación interna hablaré mas adelante, pues todavía esta en análisis. Ahora voy a hablar  de la clase Animation la cual será capaz de mostrar  todas las disintas animaciones relacionadas con  un personaje.
¿Como es una animación? aquí en la wikipedia nos lo muestra.
Básicamente la idea fundamental es tener almacenadas todas las animaciones del personaje en un mismo fichero (.png o .bmp) en donde nuestro sistema por medio de una clase sea capaz cuando se lo pidamos de devolvernos cualquier animación almacenada en un tiempo razonable.
Para ello usaré de momento la clase Animation:
typedef SDL_Rect  Frame;
class Animation{
private:
map< string , vector > Mapa;
……
public:
Animation(const string& path);
….
};
Usará el map que es una clase estándar defina en la stl, que en  la búsqueda en su peor caso es O(log(n)), pero hay que tener cuidado, por ejemplo la clave es string por claridad, ya que si fuese un entero a lo  mejor sería más directo y más eficiente, pero sin embargo es una duda que me queda ¿extrema eficiencia o claridad?
La cuestión es que debería tenerla lista en una o dos  semanas. He estado tiempo sin escribir debido a problemas personales, pero no me derrotarán tan fácil. A trabajar y a seguir adelante.
En verdad, un viento fuerte es Zaratustra para todas las hondonadas; y este consejo da a sus enemigos y a todo lo que esputa y escupe: «¡Guardaos de escupir contra el viento!»
Así habló Zaratustra.Un libro para todos y para nadie. Friedrich Nietzshe

      

UML Capa de aplicación

Diagrama UML de la parte de aplicación(usado: argoUML).
… al final me he despertado a las 9 …
      

GUI & Scribe

Tras un primer diseño de clases para la parte de aplicación (con 3 release, xD) y usando herramientas opensource como argoUML y tras usar el repositorio SVN - mediante tortoiseSVN, también opensource - para ir almacenando las nuevas versiones con nuevos cambios y poder tener cierto control en la gran cantidad de carpetas, ficheros y demás que se van generando, me propongo a realizar el diseño de clases para la parte de la interfaz gráfica.
Esta parte me llevará bastante más tiempo pues nunca he tratado en profundidad estos temas y mi UML es bastante pobre por ahora, aunque mejor que cuando empecé. Simultáneamente, he retocado el código fuente de la biblioteca de sprites que usaré, UCIGame, con ayuda del autor via mail para poder recompilarlo y generar mi .jar a usar en mi proyecto, incluyendo las nuevas funcionalidades añadidas a la misma ventana del juego que me proporcionaba.
Por ahora estas funcionalidades no están implementadas, pues dependen del diseño de clases que haga.
Posteriormente he generado un ejemplo de SCRIBE para probar la biblioteca a fondo usando tres PCs que se unan a un grupo de distribución e intercambien datos. Esta prueba la realizaré junto con mi tutor del PFC, Juanjo Ramos, en su despacho el próximo miércoles.
Vaya dos días de trabajo que llevo, mañana me levantaré tarde seguro, xD.
      

Versión 0.3 disponible

Desde hoy está disponible una nueva versión de Unimail, la 0.3. Se trata de la primera versión estable y sus novedades son:

  • Arreglo de un fallo con bandejas de entrada de muchos mensajes. Ahora Unimail se podrá usar con cuentas de correo que tengan muchos mensajes almacenados.
  • Arreglo de un fallo con los nombres de los archivos. Antes, al enviar un archivo con un nombre largo, el archivo no se podía descargar correctamente debido a un fallo; ahora, esto queda solucionado.
  • Manejo de errores. Antes, cuando se producía un error en el programa, éste se cerraba de golpe. Ahora, se mostrará un mensaje de error y permitirá volver al menú principal sin cerrarse el programa.
  • Mejora en la interfaz de usuario. Ahora, cada vez que se busquen archivos en la bandeja de entrada, se envien archivos y se descarguen archivos, se mostrará el porcentaje del progreso, para que el usuario sepa cúanto queda más o menos para terminar dicho proceso.

La verdad es que el haber arreglado los fallos me ha motivado bastante a seguir con mi proyecto, así que me pondré a trabajar en una próxima versión e intentaré que tenga mejoras considerables. Entre dichas mejoras estará la utilización de un archivo XML para guardar la configuración de la cuenta de e-mail, para no tener que introducir siempre los datos.
      

Fallo arreglado

Acabo de arreglar el último fallo encontrado. La versión 0.3 la tengo ya acabada, así que, en breve, la publicaré en la forja de Rediris.
      

Distribuir contenido