Planet

Siguiendo con lo previsto, se ha terminado la implementación del test inicial que comprobará el funcionamiento de la parte implementada en el ciclo 2 del desarrollo.
Tal y como se contó en este blog hace más o menos una semana, en el ciclo 2 del desarrollo se comenzará con la previsualización de archivos. En este paso, se probará la visualización de un único archivo introducido por línea de comandos. Una ejecución válida sería algo como:
$ tp foto.jpg
El resultado de la ejecución del programa de esta manera será la aparición de una ventana en el escritorio que muestre la vista previa del archivo introducido. Esta vista previa desaparecerá al pulsar cualquier tecla o al pasar un tiempo determinado (5 segundos por defecto, configurable con el argumento  -t, –time).
El conjunto de archivos que se utilizarán para probar el funcionamiento correcto del programa se encuentra en la forja del proyecto. Se incluyen archivos de tipos muy variados que intentan cubrir en gran parte el abanico de tipos que está previsto que sean previsualizables.
Una vez definido este test, se comenzará con la implementación de la parte más importante del proyecto.

Al parecer una nueva vulnerabilidad RFI ha sido descubierta en el componente com_jfupload del CMS Joomla, dicho componente es el encargado de permitirnos la carga remota de ficheros.Un atacante podría tratar de burlar el sistema e incrustar código malicioso para que fuese interpretado al acceder al recurso desde la parte del servidor.Un google dorks que funcione y nos arroje resultados válidos podría ser: inurl:option=com_jfuploaderY los pasos a seguir para llevar a cabo la explotación de la vulnerabilidad:

• Regístrate en el sistema.
• Comprueba si se puede acceder a la siguiente url: http://xxx/index.php?option=com_jfuploader&Itemid=[Itemid]
• Descarga una imagen cualquiera.
• Abre la imagen con el Notepad++ y sin tocar nada del código relacionado con esta, inserta a partir de la última línea todo el código PHP que quieras que se ejecute.
• Guarda el fichero con la extensión .php.gif
• Sube el fichero desde la URL indicada en el paso 2 y accede al recurso desde la siguiente dirección: http://xxx/files/TuNombreDeUsuario/NombreFichero.gif.php

Algunos ejemplos:Mostramos el /etc/passwd, a través del siguiente código PHP.Y si no quedas satisfecho, aquí no te devolvemos el dinero, pero te avisamos de que también puedes cargar una shell:

Asentado un poco más el proyecto, ya están establecidos los canales de comunicación del proyecto.
Forja de RedIRIS: utilizaré el repositorio de la forja de redIris para este proyecto. Puedes consultar en la sección “Descargas” cómo conseguir el código del proyecto desde el repositorio. Además, utilizaré la gestión de tareas de la forja, (próximamente incluiré un enlace al diagrama de Gantt de las tareas).
Blog: este blog es la principal forma de comunicación acerca del transcurso del proyecto. Publicaré entradas tanto para comentar cómo se encuentra el desarrollo del proyecto, como para hacer comentarios acerca de nuevas propuestas, incluir documentación, o incluso hacer encuestas sobre determinados temas.
Identi.ca: paralelamente a este blog, publicaré entradas en identi.ca para pequeños anuncios. He elegido este sistema frente a otros por su caracter libre y otras funcionalidades que me han parecido interesantes.

En la entrada anterior hablamos en general sobre el paquete data, donde implementan todas las clases y métodos necesarios para el modelado, almacenaje y recuperación de datos de JavaDiKt. En esta entrada hablaremos más específicamente sobre el subpaquete data.kanji, que modela lo forma de almacenar los datos en JavaDiKt
El otro día, hablando sobre el paquete data, publiqué una fotografía con el diagrama de clases que serviría de guía para el diseño del paquete. En realidad, terminé el desarrollo del paquete data.kanji hace poco, así que utilizaremos a partir de ahora el diagrama de clases actual, con sus nombres de métodos y campos actualizados además de algún cambio extra. La imagen es bastante grande, pincha en ella para verla más en detalle:
Paquete data.kanji
La clase principal del paquete es la clase Kanji, que hereda de KanjiTag, mientras que el resto de clases representan características de un kanji. El motivo por el cual se se definen estas dos clases es porque la clase Kanji está pensada para ser mutable, y, por lo tanto, ser modificable mientras que la clase KanjiTag está pensada para ser inmutable y sirva únicamente para consulta.
La clase Kanji representa toda la información existente en KANJIDICT asociada a un kanji representado por su código unicode, que hará las veces de clave primaria. Esta será la única propiedad en la que se aseguraremos que será siempre distinta para dos kanjis distintos e igual para dos kanjis iguales. Esto afecta en muchos sentidos a la implementación de Kanji:

• Los constructores admitidos aceptan un entero y la representación de un carácter. Los caracteres representan igualmente por su código unicode.
• Los métodos equals() y compareTo(), que sirven específicamente para comprobar si dos kanjis son iguales o para establecer un orden entre kanjis, usan únicamente para establecer la comparación el código unicode.
• Se añade un método estático de utilidad, isKanji(), que dado un código unicode de un carácter cualquiera, comprueba si corresponde al de un kanji. Todos los constructores usan éste método para impedir que se construyan objetos Kanji de caracteres no kanji.
• Todas las clases que representan características de Kanji contienen un método getUnicodeRef() que devuelve el código unicode del kanji al que pertenecen. Esto se consigue haciendo que todas estas clases implementen la interfaz KanjiReference. El motivo de esta decisión será explicado más adelante cuando hablemos del motor de base datos que vamos a usar, el gestor neodatis.

A propósito de las características de un kanji, podréis ver que no todas ellas estan representadas por una clase propia. En realidad todas las propiedades se representan de cuatro maneras:

1. Mediante un entero: estas propiedades se definen simplemente como enteros en los campos de la clase KanjiTag. Son el código unicode mediante unicode, el radical clásico mediante classicRadical, el radical nelson mediante nelsonRadical, el grado del kanji en las listas Kyouiku, Jouyou y Jinmeiyou mediante grade, el número de trazos mediante strokeCount,  el número de orden en la lista de frecuencia de aparación del kanji en textos escritos mediante frequency y el nivel en el cual se exige el conocimiento de kanji en el examen de japonés para extranjeros JLPT mediante JLPTLevel. Un contenedor de tipo set puede contener además errores típicos cometidos por personas a la hora de contar los trazos mediante strokeMiscounts.
2. Mediante una pareja de cadenas: representan a todas aquellas propiedades que necesitan de dos elementos para ser definidas. Todas ellas heredan de KanjiStringPair, que no es más que una clase que contiene dos cadenas.
   Se defiinen tres clases de este tipo, la clase JISPair donde la primera cadena representa la tabla de códigos JIS a la que pertenece el código alojado en la segunda cadena, la clase DicReferencePair que aloja en la primera cadena el nombre del diccionario al que pertenece el índice alojado en la segunda cadena y la clase VariantPair, que aloja en la primera cadena el nombre del recurso al que pertenece el índice alojado en la segunda cadena. Las clases representan el código JIS de un kanji, una referencia en un diccionario de un kanji y una referencia a otro kanji que por diversos motivos puede sustituirse por el kanji actual respectivamente. La clase KanjiTag puede contener varias instancias de DicReferencePair mediante el campo dicReferences y de Variant mediante variants, pero solo puede contener una instancia de JISPair mediante el campo jisCode.
3. Mediante una lista de cadenas asociada a una clave: representan a todas aquellas propiedades que bajo el mismo nombre aúnan a una serie de propiedades. Todas ellas heredan de la clase KanjiStringListEntry, que contiene a una cadena clave y a una lista de cadenas.
   Se definen dos clases que usan esta metodología, que clase MeaningEntry que agrupa varios significados bajo una cadena y la clase ReadingEntry, que agrupa varias lecturas bajo una misma cadena. Representan los significados de un kanji en el idioma determinado por la cadena clave y las lecturas de un kanji del tipo determinado por la cadena clave respectivamente. La clase Kanji puede contener varias instancias de ReadingEntry correspondientes a distintos tipos de lecturas mediante el campo readings y varias instancias de MeaningEntry correspondientes a significados en distintos idiomas mediante el campo meanings.
4. Mediante clases específicas: representan a todas aquellas propiedades que necesitan de métodos de definición más avanzados y se construyen para ello clases específicas. Existen cuatro clases de éste tipo en data.kanji, la clase KanjiQueryCodes que almacena los códigos SKIP, De Roo, cuatro esquinas y Spahn-Hadamitky del kanji referido, y las clases KanjiGraph, KanjiStroke y KanjiStrokeClue que representan características del grafo de un kanji. Hablaremos más en profundidad de estas clases más adelante.

Hasta ahora lo único que hemos hecho es describir qué es cada clase y cuál es su función. En la próximas entradas entraremos más en detalle acerca de la base de datos Neodatis y como esta ha condicionado el diseño del paquete data.kanji.

Buenas a todos,
Ahora mismo me encuentro buscando información de todo tipo: tipos de bateria, circuitos de protección y cargadores para aquellas;  estoy viendo algo de programación evolutiva o genética, cosa que me he quedado realmente anonadado por su utilidad en la robótica; el hecho de tener que montar un hexápodo implica a estudiar algo de mecánica, como cinemática inversa, y buscar en tiendas online el material necesario para poder construir en un principio las patas para poder empezar a hacer pequeños programas de control y estabilidad.
Ésto es más difícil de lo que esperaba: no encuentro un distribuidor de piezas y perfiles de aluminio decente para poder empezar a montar las patas. Tiraré de momento de la ferretería del barrio o de un todo a cien para poder ponerme con el software y tener una base donde empezar, y cuando encuentre algo mejor lo reemplazaré.
Sobre las patas, estuve estudiando dos modelos de patas. Los bocetos de los modelos son estos:


El modelo que más me convence es el modelo 2, es mucho más robusto y espero que alargue la vida de los servos, el problema es que el hardware “extra” debe ser muy ligero, de aquí el problema que tenía con los distribuidores.
Próximamente más y mejor.
PD – Perdón por la calidad de los bocetos, eran ideas rápidas que tenía que plasmar en papel para una primera aproximación del proyecto. Más adelante empezaré la documentación “oficial”.

Después de mucho trabajo y pruebas, la primera versión de la aplicación estará disponible en pocos días, queda ultimar algunos detalles, incluir algunas explicaciones de las funciones que hemos desarrollado y terminar de ajustar la parte gráfica para que sea cómoda a la vista y al usuario.
En esta primera versión, estarán disponibles seis funciones en lenguaje C, que serán las de: mostrar en pantalla, recoger un carácter, crear un vector, recorrer un vector, crear una tabla y recorrer una tabla, para cada una de ellas se solicitaran los datos necesarios para crear el código como puede ser el nombre de las variables, la cantidad de elementos, etc.
Cuando publiquemos la primera versión, incluiremos un enlace en el blog para que podáis probarla y comentar vuestras impresiones que servirán de ayuda al equipo para el desarrollo de las siguientes versiones, en las cuales ya estamos trabajando.

Estas semanas tocan examenes parciales. Así que dejaré un poco parado el comienzo de este proyecto, aunque intentaré sacar un rato para ir definiendo más ideas, principalmente, tener un modelo relacional de la base de datos : )

Bienvenido a WordPress. Esta es tu primera entrada. Edítala o bórrala, ¡y comienza a publicar!.

Para los que quieran estar informados en directo sobre el proyecto, ideas, problemas que surgan, y otras noticias importantes sobre el avance del proyecto (y alguna que otra tontería) he creado la cuenta @ProjectInfant en Twitter . Follow Me!

Nuestra apuesta se centra en el desarrollo de un sistema domótico, capaz de satisfacer todas las posibles necesidades de un hogar para mejorar la calidad de vida de cuantos la habiten.
Utilizando la plataforma arduino, una tecnología de open-hardware, basado en microcontroladores Atmega, que se correspondera con nuestros Controladores siendo una tecnología sencilla y barata, con una gran variedad de placas, como el basado en los estándars Zigbee para la comunicación inalámbrica, reduciendo las obras para su instalación en hogares ya construidos y aumentando las prestaciones de la plataforma por tener un gran alcance y un bajo consumo.
Seguidamente, para realizar la recogida de datos, se utilizará una red de sensores de diferentes tipos, humedad, temperatura, luminosidad, movimiento entre otros ubicados en diferentes puntos del domicilio. Que debido a sus pequeñas dimensiones no habrá problemas visuales en el domicilio, ni de problemas de cables.
Luego, para realizar las acciones según los datos recogidos usaremos los diferentes actuadores instalados en el domicilio.
Y por último, usaremos los datos recogidos para que el usuario a través de una interfaz web pueda saber el estado de su hogar y además pueda realizar cualquier tipo de acción sobre ella, desde cualquier dispositivo.