Planet

Hola!, después de estos días interminables, he cambiado mucho el estilo de la red, pero de momento he decidido dejar como definitivo el siguiente esquema visual:
(Si!… me ha costado pensar en como dejarlo despues de 8 versiones pre-alpha xD)
Dejo aquí una pequeña lista de cambios:
-Cambio del aspecto visual (y de momento se queda así durante un largo tiempo…)
-Corregida la visualizacion de estados
-Corregida la implementación de anotaciones
-Separacion del esquema del css para futura implementacion de temas
-Las anotaciones ahora tienen un sistema de comentarios!
Bueno, a partir de aqui, comienza realmente la labor mas dificil de vidali, ya que es hora de desarrollar el sistema de redes y amistades y el sistema multimedia (el cual me urge para poder pasar a fase alpha!). Por lo que esta semana dejaré pulida la documentacion en la forja del proyecto, actualizaré los archivos en github (que será el “sandbox” del proyecto), y pondré recursos a disposicion de los interesados en colaborar en el proyecto.
Cabe mencionar, que dado que solo estoy yo como principal administrador del proyecto, y con la proximidad de los exámenes en la universidad, mi actividad de trabajo se disminuirá considerablemente, pero trataré de tenerlo todo actualizado… y si la suerte me sigue, según lo planificado, Tendremos Vidali Alpha en Febrero!!!
Saludos!

Acabo de actualizar en la forja la lista de tareas pendientes para el próximo mes con la que si todo va bien ya se podrá publicar una primera versión de la aplicación que permita enseñar y ver lo que ha aprendido Infant. Antes eso si hay que completar la siguiente lista de tareas:Id Tarea Descripción de la Tarea 2200Knowleadge tree loading 2201Camera image loading 2202Manage and extract camera data 2203Rule generation system 2204Integrate rule generation system on tree structure 2205Recongnize single objects with cam 2206Create teaching interface 2207Create observer interfaceAdemas también os dejo el diagrama de Gantt (aunque no se por que no se muestran las dependencias entre tareas) y para más detalles os invito a visitar la forja de Infant.

Después de un mes, de lo que espero que todos  consideremos un tremendo éxito ya que:

• Más de 15 personas se han unido a contribuir
• Se han realizado una gran cantidad de tareas
• Hemos recibido nuestro primer patrocinio
• Y ya se ha creado un estupendo ambiente de trabajo colaborativo

Desde el equipo de dinamización hemos pensado que ha llegado el momento de publicar nuestro primer informe “Progreso de GeoRemindMe” con el que pretendemos ofreceros la información del estado del proyecto y donde hablaremos brevemente de:

• Miembros del equipo más activos del último mes
• Resumen de tareas realizadas  en el último mes
• Próximas tareas a realizar

Para saber más sobre por qué se hace este informe, quien lo hace y cómo se hace podéis ir a: el artículo de la Wiki de Colaboradores.
¡Empezamos!
Miembros más activos del último mes
Puntos conseguidos por cada miembro

Tareas realizadas: 21/Oct – 21/Nov

• Alta y configuración de todos los sistemas: dominio, blog, forja, cuentas en redes sociales, configuración de equipos, etc.
• Definición del la forma metodología de trabajo
• Creación de la Wiki de contribución
• Reuniones: brainstormings, definición de licencias, y tomas de contacto entre los miembros
• Investigación: definir con mayor exactitud las tecnologías a usar y la posibilidad de combinarlas
• Especificación de requisitos  funcionales (funcionalidades) de la aplicación
• Estudiar y bocetar la arquitectura de la web promocional desde donde se informará “Qué es GeoRemindMe”
• Redactar periódicamente artículos en el blog
• Empezar a programar la aplicación web: implementándose los modelos con Django (ver código)
• Empezar a programar la aplicación para Android: implementado el “Hola Mundo” (ver código)

Para ver más en detalle las tareas realizadas podéis ir a la hoja de seguimiento de las contribuciones individuales.
Próximas tareas a realizar
Desde el equipo de dinamización pensamos que el foco de trabajo del próximo mes debería focalizarser en:

• Seguir avanzado en el desarrollo de los 3 pilares principales del proyecto que son:
  • La aplicación web
  • La aplicación Android
  • La página web promocional
• Seguir aumentando el equipo, incorporando nuevas personas con diferentes perfiles, para lo que será vital la ayuda de nuestro:
  • Equipo de traducción:  ayudándonos a traducir los artículos de la wiki y el blog
  • Equipo de comunicación: ayudándonos a darnos a conocer

Como ya hemos dicho una y otra vez, por supuesto cada miembro es libre de hacer la tarea que más le apetezca dentro de la lista de tareas , esto solo es una recomendación.
¡¡Desde aquí queremos daros una vez más las gracias a todos los miembros del equipo por hacer que este proyecto sea una realidad!!

Así es, yo tampoco me lo creía cuando lo vi pero el hecho es que el creador de Ogre, nuestro amado motor de renderizado, recomendaba IberOgre a través de la red de microblogging. Por supuesto, agradecerle infinitamente su interés con este pequeño pero importantísimo gesto que proporciona al proyecto más difusión. Sigan leyendo y les

La pasada semana terminamos(al fin!) con la serie sobre el paquete data.kanji, esta semana seguimos nuestro análisis de JavaDiKt con una introspección dentro de otro de los paquetes importante del paquete data: el paquete data.dict.
En un principio, el proyecto que iba a presentar al concurso no era JavaDiKt, sino otro llamado Javadict. Javadict (con “c”, y no con “k” de “kanji”) iba a ser una librería/API de propósito general para construir diccionarios de cualquier tipo de manera rápida y sencilla en Java. Iba a proveer de una serie de clases para modelar los contenidos (como podrían haber sido las clases “Verb” o “Adverb“) con sus respectivos mecanismos de almacenaje y recuperación. Era un proceso ambicioso, quizás más que el actual, pero al final decidí hacer algo más práctico y dejé el proyecto en el tintero para el futuro. El caso es que de esta idea surgió JavaDiKt y decidí usar algunas cosas que tenía en mente sobre el proyecto anterior en éste. Así, me propuse elaborar en una pequeña biblioteca independiente del resto del programa que contuviese todo lo necesario para la recuperación de los datos. Ese paquete acabaría siendo el actual paquete data.
En el paquete data, el modelado de datos está implementado en data.kanji, del que hemos hablado las semanas anteriores, mientras que las funciones que permiten consultas estás contenidas en data.dict:
Paquete data, data.dict está a la derecha. Haz click para verlo más grande.
Como podemos ver en el diagrama, el paquete se divide a todas sus clases en el mismo paquete data.dict y en el subpaquete data.query.
La clase KanjiDatabaseManager, que extiende de DatabaseManager, es una clase que hace de interfaz entre la base de datos y la clase KanjiDict, que es la interfaz de más nivel que recubre a todas las posibles interfaces dedicadas a la consulta. KanjiDict, cuando recibe una consulta, resuelve a que base de datos debe hacerla(aunque de momento solo hay una base de datos, representada por NeodatisKanjiDatabaseManager, pero es probable que en el futuro haya más)  y realiza todos los cálculos necesarios sobre los datos extraídos antes de devolverlos. NeodatisKanjiDatabaseManager traduce las consultas de KanjiDict al lenguaje de la base de datos ( en este caso, Neodatis ODB) y realiza el trabajo sucio extrayéndolos para servirlos devolverlos de nuevo a KanjiDict.
El caso es que al implementar NeodatisKanjiDatabaseManager de DatabaseManager, KanjiDict puede usar la interfaz genérica de DatabaseManager para acceder a los datos, lo que permitirá, llegado el día, cambiar fácilmente de base datos simplemente implementando una nueva instancia de DatabaseManager, como pudiera ser, por ejemplo, MySQLDatabaseManager, SQLiteDatabaseManager o XMLDatabaseManager.
Por otro lado el paquete data.dict.query conforma mediante sus clases el mecanismo de elaboración de consultas y queries. En este paquete se diferencian 3 clases principales: la clase KanjiQuery, la clase ValueQAbout y la clase KanjiExpression. Estas tres clases representan las 3 de las 4 fases de las que está compuesta la elaboración de una query simple en lenguaje natural, que son:

1. Selección: elegir el tipo de dato que se quiere recuperar. En el caso de JavaDiKt, el dato a recuperar será siempre “Kanji”, por lo tanto no existen clases que modelen este comportamiento, todas las queries empezarán directamente en la siguiente fase. En SQL vendría dado por el comando SELECT.
2. Exclusión: En este conjunto de fases distinguimos entre los elementos que queremos seleccionar y los que no. En SQL el comienzo de estas fases vendría dado por la expresión WHERE. En data.dict.query, este proceso comienza creando una nueva instancia de la clase KanjiQuery.
   1. Atribución: en esta fase determinamos para que atributos del tipo de datos especificado en la fase de selección queremos establecer una condición. En data.dict.query, el proceso seguiría al llamar desde la instancia creada anteriormente de KanjiQuery al método con el nombre del atributo del cual queremos hacer la atribución, lo cual nos devolvería un objeto de tipo ValueQAbout que representa los tipos posibles de condicionamientos posibles que pueden hacerse sobre dicho atributo
   2. Condicionamiento: a continuación, definimos la condición que ha de cumplir la atribución anterior para que las instancias del tipo de dato elegido en la primera fase sean devueltos. En data.dict.query, elegiríamos del objeto ValueQAbout obtenido en la fase anterior el tipo del condicionamiento que queremos aplicar sobre el atributo al que se refiere, obteniendo un objeto de tipo KanjiExpression. Llegados a este punto, KanjiExpression conforma ya una expresión válida y bien formada que describe un kanji o conjunto de kanjis, y puede ser usada para hacer consultas a la base de datos (podemos ver que el método executeQuery() de Kanjidict tiene como único argumento este tipo de datos). Sin embargo, si parásemos aquí, solo podríamos hacer exclusiones basándonos en un único atributo, razón por la que existe una fase opcional.
   3. Sobrexclusión: en esta fase, iniciamos una nueva etapa de exclusión que podrá que impondrá nuevas restricciones sobre el tipo de dato elegido. En data.dict.query, la clase KanjiExpression provee de los métodos AND() y OR() que permiten iniciar de nuevo el proceso devolviendo un nuevo método KanjiQuery. La expresión no volverá a ser válida y a estar bien formada hasta que del proceso se vuelva a obtener un nuevo método KanjiExpression.

Después de esto, creo que ayudará ver varios ejemplos:
1
2
3
4
5
6
7
//Busca los kanjis cuyo código unicode sea 0x4FFF o 0x4FF1
KanjiExpression unicodeQuery = new KanjiQuery().unicode_value().equalz(0x4FFF).OR().unicode_value().equalz(0x4FF1);
 
//Busca los kanjis con número de trazos entre 3 y 5inclusive
KanjiExpression strokeQuery = new KanjiQuery().stroke_count().greatherThan(3);
//Puede hacerse también en varios pasos
strokeQuery = strokeQuery.AND().stroke_count().equalsOrLessThan(5);
Ahora para ejecutar la query tendríamos que hacer:
8
9
10
KanjiDict kanjiDB;
 
Set<KanjiTag> retrievedKanjis = kanjiDB.executeQuery(strokeQuery);
Dos últimas anotaciónes. La primera, quizás os habéis percatado que su utiliza una clase distinta para cada valor de ValueQAbout relacionado con una propiedad de cada kanji cuando eso no es realmente necesario. Podría haberse usado un ValueQAbout genérico con un campo que definiese a que propiedad del Kanji se refiere y evitar así la multiplicidad de clases. Sin embargo, lo hice de esta manera porque pienso que en futuro se podrán refinar las clases en función de las características de cada propiedad. Por ejemplo, podría definirse para KanjiGraphQAbout un nuevo tipo de condicionamiento que sea, por ejemplo, “se parece a” o “tiene el radical x“.
La segunda, es referente a aquellas propiedades del kanji que tienen más de un valor, como por ejemplo la variante, el código JIS o el significado. Veamos un trozo de código:
1
2
3
KanjiExpression ke1 = new KanjiQuery().dictionary_name.equalz("gakken");
KanjiExpression ke2 = new KanjiQuery().dictionary_reference.equalz("234");
KanjiExpression ke3 = new KanjiQuery().dictionary_name.equalz("gakken").AND().dictionary_reference().equalz("234");
Lo que definen estas tres expresiones puede ser confuso, pero en realidad es muy simple. Al ejecutar la primera de ellas, la base de datos devolverá todos los kanjis que tienen una referencia en el diccionario Gakken, es decir, todos los kanjis que aparecen listados en dicho diccionario. La segunda, todos los kanjis que en cualquiera de los diccionarios tienen la referencia 234. La tercera y última devolverá el kanji del diccionario Gakken que tiene la referencia 234. Para este tipo de consultas es donde la sobreexclusión se hace imprescindible, otorgando al sistema de elaboración de queries gran poder.
Con esto terminamos por fin con la serie referente al paquete data kanji. En las próximas entradas empezaremos a hablar de la interfaz gráfica y los paquetes subyacentes.

Acabamos de implementar el diagrama de modelos preliminar  para el servidor web, estamos construyendo el esqueleto básico de la aplicación usando Django 1.2.6 y los modelos nativos de Google App Engine.

Ya he puesto a vuestra disposición el primer prototipo de YakiTo. Consiste únicamente en una aproximación de lo que será la interfaz gráfica de usuario. Echándole un vistazo puede intuirse cómo será el funcionamiento de la aplicación una vez esté terminada.
Podeis descargar este primer prototipo haciendo clic aquí.

This blog was created for explaining the progresses that I achieved in respect with the vLearnie software. On the next post, I would explain was it is all about.

Bienvenidos al blog del proyecto Foodie. Actualizaremos el mismo en breve.

Autor: David Goehring
Ya han sido más de una persona las que en cuanto les hemos hablado de la aplicación una de sus primeras preocupaciones era la privacidad y creemos que un asunto muy importante y queremos despejar todas las dudas que puedan haber al respecto.
La aplicación no permitirá ni consultar ni compartir la localización de otras personas que no sea la que la esté usando. De hecho la aplicación podrá detectar nuestra posición actual si es lo que deseamos, y añadir un recordatorio a dicha posición.
Dicha información se enviará al servidor de manera completamente segura (usando un cifrado de llave pública) y será almacenada para que luego nosotros podamos consultarla desde un navegador web o una aplicación móvil.
De este modo los datos que se almacenarán (a falta de definirlos completamente) serán:

• Dirección física o tipo de local (obligatorio)
• Título del recordatorio (obligatorio)
• Franja horaria (opcional)
• Archivos adjuntos (opcional)
• Más detalles (opcional)
• etc.

Por tanto como podemos comprobar, en ningún momento se comunica la posición actual del usuario, esa información la aplicación solo la utiliza cuando tenemos está encendida para comprobar si entre la lista de recordatorios que tiene almacenados hay alguno que tenga que recordarte.
Por supuesto todo esto que decimos que hace la aplicación cualquier persona con conocimientos técnicos lo podrá comprobar analizando el código fuente de la aplicación que está disponible desde el repositorio.
Estaremos encantados de resolveros cualquier duda que nos planteéis a través de nuestra plataforma de soporte.