Casi 20 dias despues... nueva release :-DEste mes ha sido de aúpa, entre el trabajo y la demostración de este miércoles (que FSM nos coja confesaos...), los estudios (de los cuales todavía no tengo todos los apuntes), los compromisos sociales (aunque algunos han merecido la pena... aunque podrian haberlo merecido mas :-P ) y que los [auto-censurado] checksums se me habian atragantado no he parado quieto, pero bueno, tal y como dijo Mao "una revolución a la vez" al final esta saliendo todo adelante :-DEn primer lugar estaba el tema de los plugins. Los checksums no aportaban simplemente funcionalidad no existente como pasaba con los symlinks sino que trabajaban directamente con los datos, por lo que ya no se podia usar un simple mapeo como antes sino que habia que empezar a desarrollar el sistema de plugins, y a ser posible de una forma un poco mas consistente que como lo habia hecho antes. Por suerte fue facil y ademas el codigo ha quedado bastante limpio, pero tengo la sospecha de que en el futuro voy a tener que hacerle profundos cambios para darle mas potencia y versatilidad (conflictos entre modulos es lo primero que se me viene a la cabeza, luego vereis porque).Pero el principal problema que tenia con los checksums (y que no identifique hasta hace poco) no estaba relaccionado directamente con ellos, sino que mas bien era un pequeño fallo de diseño (mas bien de falta de planificación) que tuve cuando desarrolle el codigo de escritura y modificación de los archivos (el cual en su momento ya me dio bastante guerra hasta el punto de tener que modificar el diseño de la base de datos tres veces...). Este fallo consistia por un lado que accedia desde distintos puntos del codigo directamente a las funciones DB.Split_Chunks y a LL.Write, con lo que a la hora de generar los eventos para los plugins tendria que generarlos desde multitud de sitios distintos. Sin embargo su funcionalidad era muy parecida y de hecho el codigo era casi el mismo en muchos sitios (como ya indique en mi anterior post entre DB.truncate y DB.Split_Chunks), asi que finalmente he conseguido encarrilar a todo el ganado a través de una nueva función (File.__Split_Chunks) que se encarga efectivamente de llamar a DB.Split_Chunks y de generar el evento correspondiente en caso de que haya producido alguna división.Al menos todo este follón me ha servido para varias cosas: en primer lugar, una revisión a fondo del código de los archivos, de la base de datos y del acceso a bajo nivel (este al fin es una clase y es instanciada en FileSystem, con lo que ya no abrirá y cerrara el dispositivo en cada llamada. La ventaja es que el acceso es mucho mas rápido, el inconveniente que usara los buffers de archivo del sistema y no escribirá los datos directamente a disco y todavía no estoy usando las transacciones, que es justo una de las razones por las que decidí usar un motor de bases de datos, para aprovechar las que ya tiene... :-/ ). Esta revisión me ha permitido aplicarle muchas mejoras menores y reutilizar mucho código duplicado, con lo que ahora el tamaño y las posibilidades de error son menores, pero sobretodo he quitado "inteligencia" a la base de datos (ahora solo ejecuta sentencias SQL, apenas toma decisiones por si misma aunque lo cierto es que se podría "estupidizar" aun mas) y he eliminado la notificación de eventos desde la base de datos y el acceso a bajo nivel, con lo que por un lado permite mayor control de quien envía realmente los eventos (todo se esta perfilando a que la comunicación entre los plugins va a ser realmente sencilla... :-) ) y también permite mayor portabilidad en el futuro a otros motores de bases de datos o sistemas de almacenamiento o incluso a sacar el código SQL a archivos externos y que los parsee en el arranque en lugar de estar directamente dentro del código Python (esta idea la tengo desde hace tiempo, pero aunque permitiría un mejor mantenimiento al poder tenerlo aislado y que sea mas fácil procesarlo con un editor de texto con coloreado de sintaxis -me encantan :-D - todavía no me he planteado en serio el realizarlo porque consumiría mas memoria y seria un poco mas lento... :-/ )Ademas todos estos cambios me han hecho replantearme en serio la necesidad de hacer modulos de prueba, por lo que voy a empezar a usar PyUnit, que es el estandar en Python. Nunca he desarrollado ninguno y ademas siempre he sido reaccio a hacerlos (si funciona, ¿para que comprobarlo?) pero un proyecto tan complejo como este lo necesita. Por suerte hace tiempo cuando estaba buscando los codigos de error de los sistemas de archivos tratando de averiguar porque fallaba me encontre con esta pagina que contiene la definición de todas las funciones UNIX con sus parametros, errores y limitaciones, con lo que me vendra de perlas para desarrollar los modulos de test (espero que no me pidan comprar una licencia de POSIX o que Linux Tordvalds me preste la suya... :-D ). Tambien aprovechare a documentar todo el codigo con vistas a liberar publicamente la version 0.3 a ver si se apunta alguien a echarme una mano, y tambien aprovechare a cambiar la filosofia de la API, ya que hasta hace poco (bendito trabajo que tambien lo estoy haciendo en Python y me permite aprender de forma intensiva... :-D ) no entendia correctamente uno de los aspectos mas extraños del lenguaje: en Python no hay metodos o atributos privados, todo es publico. Sin embargo por convenio los atributos y metodos que empiezan con un guión bajo (_) no se muestran en el completado de sintaxis, aunque se sigue podiendo acceder normalmente a ellos. Aparte tambien estan los que empiezan por dos guiones bajos (__) que aqui si el lenguaje los considera como atributos especiales y su firma es distinta, haciendo por tanto que sea mucho mas dificil acceder a ellos. Hasta ahora solo usaba este ultimo metodo para emular los atributos privados, pero realmente era un engorro cuando me encontraba con que queria acceder a algo que habia ocultado demasiado hasta que descubri en que se basaba esta diferencia: la filosofia en Python es la confianza en el programador, por lo tanto no tiene sentido pensar en atributos publicos, protegidos y privados, sino en mostrar (normal), no mostrar (_) y ocultar (__), teniendo en cuenta por ambas partes que si quieres acceder a algun sitio siempre vas a poder pero que necesitas tener buenas razones para ello (por ejemplo, en los debuggers). Despues de tanto tiempo con C++ cuesta acostumbrarse, pero la posibilidad de ver el codigo de los demas para ver que es lo que esta haciendo realmente es de gran ayuda... :-DY bueno, ese es el toston de hoy. Espero que cuando este aprendiendo a usar las unidades de test y documentando el codigo no me encuentre con demasiados problemas como hasta ahora, porque entonces esto va a parecer la biblia... :-P Por el momento para mi desgracia acabo de descubrir que ZFS si tiene bloques de tamaño variable (lo que yo creia que era una feature exclusivamente mia... ¬¬) pero por otro lado tambien he descubierto que su algoritmo de compresion tiene una implementación en Python, asi que no hay mal que por bien no venga... :-DPublished with Blogger-droid v1.6.2
La creación de rutas óptimas es fundamental para este proyecto. Esta tarea es muy costosa pues es necesario disponer de mapas altamente completos detalladados. Además es necesario disponer de potentes algoritmos para la creación de estas rutas así como del equivalente en máquinas donde hacer funcionar dichos algoritmos.
Gracias a Google podemos delegar esta tarea en su servicio Google Maps. Para ello disponemos de un API con funcionalidades que nos permiten principalmente consultar rutas y dibujarlas en un mapa.
Podemos ver un ejemplo básico aquí http://cusl5-ssgl.forja.rediris.es/ejemplos/googlemaps/gmaps-basico.html
Este ejemplo consiste en ir insertando los lugares por los que quieres pasar. Los dos primeros son origen y destino respectivamente. El resto son los llamados waypoints, lugares entre la ruta por donde quieres pasar. También puede modificar la ruta arrastando tanto el camino como los puntos.
Toda ésta interactividad con el API de google es prácticamente todo lo necesario para el proyecto, aunque siempre pueden salir nuevos requerimientos.
Para continuar con la etapa de diseño del proyecto, hoy os presento el diagrama de clases de YakiTo. He profundizado sobre todo en las clases más importantes, dejando en un segundo plano –mediante un nivel de abstracción mayor– los componentes menos significativos. No se trata de algo definitivo, y más adelante puede que vuelva a él para realizar alguna pequeña modificación. Podeis visualizar el diagrama a continuación (clic sobre la imagen para verla a tamaño completo):
En el siguiente documento, explico la estructura más general que he ideado para la aplicación. Se trata de un diseño modular, estudiado pensando en posibles reutilizaciones futuras de algunos fragmentos, así como en la división de labores –ya se sabe: divide y vencerás–.
Saludos, hoy doy por inaugurado el blog. En breve iré publicando nuevas entradas explicando diferentes características del proyecto (qué es, qué se espera de él, tecnologías utilizadas, manuales how-to…)
Nos vemos!
Bienvenidos al blog de nuestro proyecto.
Nuestro proyecto “DJAD” consiste en el desarrollo de un asistente de programación, que generará automáticamente el código para una serie de acciones y funciones en distintos lenguajes de programación, para ahorrar trabajo a programadores o para ayudar a los que se inician en el mundo de la programación.
Aquí iremos informando sobre el progreso en el desarrollo de la aplicación y demás asuntos relacionados con nuestro proyecto.
Este proyecto será llevado a cabo por cuatro estudiantes de 2º de Administración de Sistemas Informáticos del I.E.S. Villablanca de Vicálvaro (Madrid).
I have finally developed the basic mathematical OpenCL functions to train the RBM in OpenCL. It has been a hard work due to the complexity of thinking in a parallel way. Now I should generate the test cases and finally verify that all of them produce the right results. I feel completely exhausted after compiling all the OpenCL sources. I hope next phases won't be has hard as this. Anyway, now I think I have enough OpenCL skills to easily detect the possible errors.Finally, I have all the sources decoupled in the project so I don't need to make any reference to an external header nor cpp source code. This should ensure compatibility between platforms (at least I hope it ;) )I think I'll have a first implementation of the two layer RBM in one or two weeks. Things are going slower than expected.
ePlanning es un proyecto que tiene su inicio en mi periodo de prácticas en el Hospital Nacional de Parapléjicos de Toledo (HNP), gracias al acuerdo establecido entre dicho hospital, la UCLM y la Escuela Superior de Informática de Ciudad Real. El proyecto se define como un sistema de información clínico que permitirá la visualización de forma interactiva e intuitiva de datos médicos del paciente en los controles de enfermería, sustituyendo al actual sistema de pizarra convencional.
ePlanning es un proyecto participante en el V Concurso de software Libre tanto a nivel estatal como a nivel universitario (Universidad de Castilla la Mancha). En este blog se mostrarán todos los resultados de las distintas etapas en la realización del proyecto, y se encontrará toda la información actualizada sobre el desarrollo de éste. Además toda esta información estará también disponible en la correspondiente forja de RedIRIS ( https://forja.rediris.es/projects/cusl5-eplanning/).
Hola, esta es la bitácora que usaré para ir informando sobre las novedades y los avances que se vayan realizando en AcoMaT. AcoMaT participará durante el curso académico 10/11 en el V Concurso de Software Libre de Castilla La Mancha, también participará en el Concurso de Software Libre a nivel estatal.
Un saludo a todos.
Todos los grandes proyectos comienzan con algo muy pequeño, y hoy sólo he abierto este blog que ahora lees, un primer paso para plasmar mis intenciones e ilusiones y por supuesto, ideas y seguimiento para conseguir que “Fútbol Es Así” vea la luz.
Animar a todos los que me leéis a enviarme cualquier tipo de sugerencia, que a buen seguro tendré en cuenta.
Un Saludo
Alberto