Planet

Esta semana no ha habido muchos cambios en el SVN, pero por fin hemos subido algo de media. Asi que, pronto empezaremos a elaborar una guía para poder compilar F.O.G. del SVN.
Entonces, ¿qué hemos hecho a pesar de haber habido tan poco movimiento en el SVN?
Mucho, pero el problema es ...

Aquí empieza el semanario. Cada semana añadiré pasos a desarrollar, y al final de la semana lo que se ha conseguido. Consideraré cada semana desde miércoles hasta martes.
Por tanto, aquí empieza la primera semana dura de trabajo.
SEMANA #1: 03/12/08 a 09/12/08 - Empezando: Análisis del sistema “AsteriskNow” & Configuración Básica del Dialplan de Asterisk.
Los pasos a desarrollar en esta primera semana de trabajo son los siguientes:

• Una de las secciones que incluye el proyecto es justificar la necesidad de TUTATISK, comparando diferentes sistemas ya implementados y desarrollados, para ver las ventajas y desventajas o carencias que presentan, pretendiendo conseguir que mi sistema palie dichas deficiencias. En esta primera semana, analizaré la PBX AsteriskNow.
• Como primera parte de desarrollo, procederé a realizar una configuración básica del dialplan, sobre todo, intentándose centrar en aprender el manejo de BBDD con Asterisk y la ejecución de aplicaciones externas.

He estado haciendo unos diagramas sencillos sobre el formato HFP y los he incluído en las especificaciones que hay colgadas en la sección de documentación de Mandarina . Aun así, como el blog está para algo, colgaré aquí los diagramas para que se vea que, aunque muy poco a poco, sí que estamos avanzando.
Diagrama del formato HFP
Posted in Anuncios      

Bastantes proyectos ya han mostrado avances significativos en estos momentos, ya sea en el apartado de planificación, documentación o código ejecutable. Por desgracia, éste NO es el caso de Mandarina.
Por el momento estamos construyendo una librería dll (en C++) llamada libgajo que servirá de soporte para el manejo de paquetes y sólo hemos colgado unas especificaciones (que hace falta mejorar, en cuanto a presentación y en cuanto a información) sobre el formato HFP (HaseFroch Package).
¿Cuál es el estado de libgajo? Realmente aún está muy verde, hace dos días replanteé totalmente su estructura y volvía a empezar desde cero, hoy he eliminado todo el código antiguo del repositorio y lo he dejado en un directorio llamado deprecated por si alguien siente curiosidad por saber QUÉ es lo que me motivó a desechar el código escrito. Os aseguro que no os costará adivinarlo.
Actualmente en la librería libgajo he definido unas cuantas clases, una clase base de la que derivan otras dos HFP_DirReader y HFP_FileReader que sirven para extraer la información de ficheros y directorios contenidos en un paquete HFP, y unas cuantas clases de excepciones. Tengo que añadir las contrapartidas de HFP_DirReader y HFP_FileReader, que se encargarán de leer un arbol de directorios y empaquetarlo en un archivo. Falta, además, añadir la verificación de checksums y la capacidad de leer y añadir firmas digitales (tal y como se especifica en el documento sobre HFP). “Por último”, se tiene que añadir una clase (o varias) que sirva para manejar el compresor, de ello se está ocupando Sergi.
En realidad, libgajo no se limita a eso, pues se tendrán que añadir rutinas que extraigan la metainformación del paquete y permitan tratarla con facilidad, pero eso ya vendrá.
Más novedades, leyendo posts sobre otros proyectos he visto que nos tenemos que poner las pilas en cuanto a metodología de trabajo, veo que hay algunos proyectos que se están llevando con auténtica profesionalidad, y aunque no esperamos actuar talmente como profesionales, actuar siguiendo ciertas pautas nos resultará beneficioso. Para ello, hemos empezado por la estructuración del repositorio svn, adaptándola a una forma más estandarizada (tal y como se comenta en un post de eOPSOA).
Hemos decidido que en cuanto acabe las tareas que me he autoasignado sobre libgajo documentaré las clases que he estado programando y mejoraré las especificaciones de HFP (al menos en cuanto a presentación) para hacerlas más leíbles.
No utilizaremos gráficos gantt (de momento) ni nada parecido para planear nuestras tareas por que tenemos horarios muy irregulares y nunca sabemos si podremos acabar algo o no.
En cuanto a lo que sigue al desarrollo de libgajo: una vez acabada la libgajo tendremos que empezar a darle utilidad. El caso es que queremos avanzar lo más rápido posible, y por ello hemos decidido que inicialmente puede que hagamos los programas en Python (3k), y una vez que tengamos algo usable haremos sus hermanos “mayores” programados en c++ para conseguir mayor eficiencia.
Posted in Desarrollo   Tagged: Desarrollo   

Tras un par de días trabajando en ello, hemos ampliado la documentación del proyecto (disponible aquí).
El que nos planteáramos emplear una filosofía de trabajo para nosotros desconocida, como es el Scrum, nos ha hecho cambiar el modo de hacer las cosas. De hecho, todavía no estamos totalmente adaptados, y suponemos que nos va a llevar algunos días más.
Nos comentaron que UML y Scrum no se llevan bien, pero tras pensar un poco y tras leer algo de Internet, hemos llegado a la conclusión de que tal incompatibilidad no existe. Scrum es una filosofía de trabajo, un proceso iterativo a lo bestia. El que se emplee este método no nos impide usar UML, el cual es un lenguaje de modelado (e independiente de la filosofía usada para construir el software).
Scrum, con un poco de suerte, nos quitará de encima una buena parte de documentación inútil a la que nos hemos visto obligados a recurrir en otras circunstancias.
Para lo que sería nuestra primera iteración en Scrum, hemos definido una serie de requisitos funcionales que están en la nueva documentación. Aunque todavía no estamos aplicando de forma exacta el Scrum, pronto elaboraremos una lista detallada tanto de las tareas de esta iteración (sprint backlog) como del proyecto global (product backlog), y nos pondremos más en serio.
La nueva documentación incluye además los primeros casos de uso y el storyboard correspondiente.
      

Red de Jordan
      

Multiperceptron
      

Red de Hopfield
      

Para entender mejor como funcionan las redes CAN, es necesario comprender la estructura que componen los mensajes que se envían a través del bus. Intentaré ilustrar con la mayor claridad la estructura de un mensaje CAN.
Existen dos tipos de mensajes CAN que se distinguen únicamente por la longitud del Identificador “Identifier”. En el caso del Formato Estandar “Standard Message Format” son 11 bits, mientras que para el Formato Extendido (Extended Message Format) son 29 bits. En principio creo totalmente innecesario dotar a ArCan con el Formato Extendido, pese a ello no lo descarto, sin embargo creo que para explicar la estructura es más sencillo basarse en el Formato Estándar.
Llegado a este punto es necesario hacer un inciso, con el objetivo de clarificar para que sirve el Identificador del mensaje, pese a que en el artículo anterior di algunas pinceladas sobre el tema. En las redes CAN no se asigna a los dispositivos una dirección y tampoco ningún mecanismo que los difiera entre ellos, es una capa superior software, la capa Selección, la que se encarga de saber si el mensaje le concierne o no, y lo sabe gracias al Identificador. Esto es una característica tan curiosa como potente desde mi punto de vista, y es que en una red CAN un mismo mensaje puede ser recibido por varios dispositivos como vimos en el artículo anterior.
A continuación podemos ver en la imagen los distintos campos de un mensaje CAN.


Vamos a describir los distintos campos que componen el mensaje:

• “Start of Frame” este bit se encarga de avisar a los demás dispositivos que se va a iniciar un mensaje, y de esta forma se sincronizan. El inicio de mensaje se marca por un bit dominante ‘0′.
• “Arbitration Field” consta del identificador del mensaje, 11 bits, y un bit de control adicional (RTR). Cuanto más bajo sea el valor del Identificador más prioridad tendrá el mensaje. Durante la transmisión de este campo, el emisor comprueba en cada bit si todavía está autorizado para emitir o si esta emitiendo otro dispositivo con un mensaje de mayor prioridad. El bit RTR indica si el mensaje contiene datos (RTR=0) o si se trata de una trama remota sin datos (RTR=1). Una trama de datos siempre tiene una prioridad más alta que una trama remota. La trama remota se emplea para solicitar datos a otras unidades o bien porque se necesita para realizar un chequeo.
• “Control Field” Este campo informa sobre las características del “Data Field”, se compone por un primer bit “IDE”, que indica que tipo de mensaje es, ‘0′ para una trama estándar y ‘1′ para una trama extendida. Después un bit reservado y los cuatro últimos contienen la longitud en Bytes del campo de datos “Data Field”.
• “Data Field” en este campo se encuentra la información que puede variar entre 0 y 8 Bytes. Un mensaje de longitud 0 puede emplearse para la sincronización de procesos distribuidos.
• “CRC Field” Es un código de 15 bits para verificar posibles errores de transmisión, esta basado en una codificación Hamming con distancia 6, el último bit es siempre un ‘1′ y delimita el campo CRC.
• “Ack Field” El campo ACK esta compuesto por dos bit que son siempre trasmitidos como recesivos ‘1′. Todas los dispositivos que que verifican el CRC modifican el primer bit del campo ACK por uno dominante ‘0′, de forma que el periférico que está todavía trasmitiendo reconoce que al menos algún dispositivo ha recibido el mensaje correctamente. De no ser así, el emisor interpreta que su mensaje presenta algún error.
• “End of Frame” Este campo indica el final del mensaje con una cadena de 7 bits recesivos ‘1′. Puede ocurrir que en determinados mensajes se produzcan largas cadenas de ceros o unos, y que esto provoque una pérdida de sincronización entre los dispositivos. CAN resuelve esta situación insertando un bit de diferente polaridad cada cinco bits iguales: cada cinco ‘0′ se inserta un ‘1′ y viceversa. El dispositivo que utiliza el mensaje, descarta un bit posterior a cinco bits iguales. Estos bits reciben el nombre de bit stuffing.

 
Como podemos ver, el mensaje en Formato Estándar se compone de 130 bit, y es necesario un mecanismo para evitar el envío de mensajes erróneos, para este fin se encuentra el campo CRC, pero existe otro mecanismo que me ha parecido muy curioso, el propio emisor recibe también el mensaje a la vez que lo envía, y lo va comparando; si por alguna circunstancia no coincide, activa un flag de error y detiene la transmisión durante 12 bits. En este tiempo todos los demás dispositivos activan también el flag de error, el objetivo de esta ventana temporal es permitir la sincronización de todos los elementos. Una vez transcurridos los 12 bits, el emisor vuelve a enviar el mensaje. Esta situación nos puede llegar a plantear una pregunta, ¿Que pasa si el error en la recepción del mensaje es permanente? aparentemente la respuesta sería que el sistema se bloquearía, pero no es así, CAN ha pensado en esto, y está dotado de un mecanismo capaz de distinguir entre anomalías ocasionales y anomalías permanentes mediante una evaluación estadística de las situaciones de error.

Desde hoy está disponible una nueva versión de Unimail, la 0.2.
Las novedades son:

• Cambio en el formato de los mensajes de Unimail. Esto permite ahora que un mismo usuario envie 2 ó más veces un mismo archivo o 2 ó más archivos con el mismo nombre.
• Comprobación de la integridad de un archivo recibido. Ahora sólo se podrán descargar los archivos que se hayan recibido por completo.
• Arreglo de un fallo en la compatibilidad con Windows. Ahora, Unimail se puede ejecutar correctamente en Windows.