Des-clasificación de información

Estoy convencido de que las grandes ideas se tienen casi siempre durante el aseo personal o durante la excreción, hasta el punto de que me planteo seriamente que estaría haciendo Newton bajo el árbol cuando la manzana le dio en la cabeza.

El caso es que, siguiendo la tónica habitual, mientras me duchaba y escuchaba música (Fito & Fitipaldis, por la boca muere el pez) me he planteado la necesidad real de clasificar la información. Ha sido la música la que me ha hecho pensar en ello, ya que normalmente los ficheros MP3 tienden a estar mal clasificados. En concreto no se añade semántica a la información: los datos ID3 suelen estar mal, el autor en el campo del título, el nombre del álbum vacío, etc. Tanto que al final es más práctico realizar una búsqueda en los textos completos sin considerar la información se supuestamente contienen.

Lo fundamental es que en casos como el del ejemplo no solemos encontrarnos con problemas para encontrar la canción que buscamos, así que en definitiva el mecanismo funciona. En ocasiones añadir más mecanismos de clasificación solo complica las interfaces y los métodos de búsqueda. Los algoritmos se vuelven más complejos, pues deben ponderar entre la meta-información que disponen y la posibilidad de que dicha meta-información sea incorrecta, y deben compaginar esto con el nivel de coincidencia de los términos de búsqueda con independencia de dicha meta-información.

Además la clasificación tiende a enmascarar la información. Un ejemplo de esto puede ser aclaratorio: ésta entrada en éste blog se puede etiquetar, como un modo de clasificación, y meterla en los conjuntos de "clasificación de información", "información", "etiquetado" e incluso "web semántica". Sin embargo nadie añadiría para esta entrada etiquetas del tipo "Isaac Newton" o "música", a pesar de que contiene información sobre ambos temas.

Entonces supongamos que para responder a una búsqueda sobre un conjunto de datos tenemos en cuenta el contexto en que se realiza la búsqueda. Se trata de un usuario que está buscando el autor de la canción "por la boca muere el pez". Como esta búsqueda está en el contexto de música, acotamos los resultados a la información etiquetada como "música", "canción", etc. Por tanto este documento sería ignorado a pesar de contener exactamente la información que él busca.

Por supuesto que los ejemplos son triviales, pero la idea tiene su relevancia. De echo en la actualidad la mayor fuente de información es probablemente Internet, y en ella la clasificación es prácticamente nula (la web semántica no ha terminado de funcionar y yo apostaría a que nunca lo hará, se le ha pasado el arroz y podemos decir que ha muerto de éxito). Sin embargo eso no suele ser un problema importante. La mayoría de la información se encuentra con cierta facilidad usando buscadores que se basan única y exclusivamente en la aparición de una cadena en un texto, de la frecuencia de aparición, etc. El único modo de clasificación que aparece aquí son los "votos" que emiten otros documentos hacia uno y que por un lado destacan su relevancia y por otro colaboran con el etiquetado (un documento puede ser mostrado ante una cadena de búsqueda a pesar de que dicha cadena no aparezca en él, sino en enlaces que apuntan a él).

En definitiva ¿es tan importante la clasificación de información, o es más importante la búsqueda bruta sobre datos no clasificados?.

Lenguajes de 4ª Generación

Cuando pensamos en automatizar tareas mediante software, pensamos en un programa que haga de forma automática lo que debe hacer una persona, pero como informáticos estamos acostumbrados a hacer esto para otras personas ¿y nosotros qué?

Alguien tiene que analizar un fichero, nosotros le hacemos un parser, y le ahorramos tiempo. Alguien tiene que hacer una tarea repetitiva y nosotros le damos una herramienta que lo hace casi todo ahorrandole trabajo a la persona.

La idea de los lenguajes de 4ª generación es esa misma, pero con respecto a nosotros, es decir, muchas aplicaciones se parecen en muchas partes, ya no entre aplicaciones, sino dentro de una misma aplicación, estamos muy acostumbrados al famoso copy-paste, y ya no copiar código igual, sino similar. Esta tarea es muy repetitiva y genera cantidades ingentes de lineas de programación.

Un generador de código de 4ª Generación, nos puede ayudar a automatizar la tarea de programar, es decir, que programe la máquina. Nosotros lo que hacemos es un programa cuya salida es código fuente de otro programa, es este segundo programa el que da una solución a nuestros clientes. Parece algo extraño, pero aquellos profesionales que se dedican a programación web, están acostumbrados a implementar software cuya salida es HTML y javascript, esto al fin y al cabo, es lineas de código que se ejecutan en un navegador.

La idea es la misma, pero llevandola a nuestro software más cotidiano, si tengo 50 objetos diferentes y cada uno de ellos tiene una representación en BD, entonces seguramente tengamos que implementar 50 select, 50 deletes, 50 updates y 50 insert. Esto es muy repetitivo, así que es mejor crear un módulo en el que indicamos como se construye la select, update, delete e insert de un objeto en base a sus propiedades. De esta forma lo que conseguimos es implementar un solo objeto, pero más abstracto, al ejecutarlo nos genera el código para los 50 objetos, ahorrando mucho mucho tiempo.

Y por seguir en esta línea, estamos acostumbrados a crear una tabla en BD, y despues un objeto en nuestro código que representa a esa tabla, con los mismos campos, y si tenemos 50 tablas, eso se hace pesado. Pues volvemos a lo mismo, hacemos un módulo que tras ejecutarlo nos devuelva el código de esos 50 objetos.

Ya hay software comercial desde hace mucho tiempo que nos automatiza tareas de este estilo y podemos usarlas ahorrando mucho tiempo de programación.

Mi consejo es que os metais de lleno en esa forma de programar, ya que conseguires desarrollar software mucho más rápido, mucho más robusto (despues de muchos copy-pastes te puedes equivocar) y lo más importante, mucho más mantenible, ya que por ejemplo si hay que hacer cierta tarea adicional cuando se hace un insert, si no usamos 4GL tendríamos que modificar en 50 lugares, pero de esta forma, modificamos un solo sitio, generamos código, y ya está todo funcionando.

Ya son varios los proyectos que hemos enfocado desde este punto de vista y es genial cada vez que tienes que añadir un nuevo objeto a tu sistema, que en cuestion de segundos tienes el objeto y todos los mecanismos de acceso a datos.

Experimentadlo y entendereis lo que digo :)

Jose Carlos Calvo Tudela

Controladores de dispositivos en Linux

He colgado en la web de intelligenia un documento sobre programación de drivers (controladores) en linux que realicé junto con unas compañeras para una asignatura.

Está publicado bajo CC y creo que es interesante porque hay poco material sobre el tema en español.

El documento pretende abordar la ardua tarea de programar un manejador (también llamado controlador o driver) de dispositivos en linux. Dicha tarea se puede realizar mediante el concepto de módulo de carga dinámica. Dichos módulos son pequeños trozos de código que se pueden cargar en el kernel del SO de modo dinámico en tiempo de ejecución. Con ello se dota a linux de una gran capacidad de extensión.

La principal ventaja de usar un módulo es que éste se ejecuta como parte del núcleo. Es decir, no se trata de un módulo que se comunica con él (como sucede con los procesos) sino que se ejecuta en modo kernel y tiene por tanto total acceso a todos los dispositivos del sistema.

Junto al documento se incluyen los ficheros eddy.c, eddy.h testeddy.cpp y makefile, que permiten la compilación del manejador de ejemplo para el dispositivo que optamos por llamar EDDY (Elemental Didactic Device as Yet).

Tengo un par de documentos del estilo, cuando vaya teniendo tiempo los iré sacando por aquí.

Enlace: Programación de drivers en linux.

aptana, IDE para desarrollo javascript

Navegando por la red buscando información sobre AFLAX me he encontrado este IDE, open source, que está empezando a ver la luz, parece muy potente, ya que no se pone a cubrir todas las fases de un desarrollo Web, sino que se centra en la parte del cliente, así que ofrece herramientas potentes con todas las librerías importantes: dojo, aflax, aculo script, yahoo ui,...

Me lo estoy descargando para probarlo, así que os contaré qué me parece la plataforma

Jose Carlos Calvo Tudela

yahoo ui, aculo script y dojo

Toca investigar nuevas cosas, hasta ahora he puesto repetidas veces referencias a dojo como framework javascript. A partir de ahora me dispongo a investigar , probar y experimentar tanto con yahoo ui (yui) como con aculo script, que son otros frameworks.

Como todo en esta profesión, no hay que delimitarse a una tecnología, ya que cada una tiene sus ventajas e inconvenientes. No podemos pensar que cierta herramienta es la mejor del mundo, porque eso no será nunca cierto. Así que la mejor forma de avanzar y simplificarnos la vida, es investigar las posibilidades que existen y tener así un buen punto de vista cuando hay que declinarse por una herramienta u otra para cierto proyecto.

De esta forma dependiendo de las necesidades de un proyecto seleccionaremos el framework que mejor se adapta a nuestras necesidades y más facil nos lo ponga.

Recordad que lo bueno si es simple es dos veces bueno (adaptación útil, a nuestro mundo, del famoso dicho)

Si alguien tiene algo de experiencia en estos entornos, no dude en escribir para guiar en esta fase de prueba.

Hasta la próxima

Jose Carlos Calvo Tudela

Optimización del ancho de banda en aplicaciones Web 2.0 con AJAX

Cuando hacemos una aplicación con AJAX para una WEB 2.0, todos sabemos que ya de por sí el utilizar AJAX optimiza el ancho de banda, ya que no se está reenviando una y otra vez cosas que no cambian, así que solo se transmiten trozos de informacón útiles para cambiar cierta parte de la aplicación.

Pero en muchas aplicaciones de este tipo no hay que descuidar dos aspectos muy importantes, uno de ellos es la optimización del ancho de banda (aspecto para el usuario) y el otro es la seguridad de nuestro código (aspecto para el desarrollador)

En cuanto a optimización se refiere, durante la ejecución de la aplicación se tiene una comunicación lo más optimizada posible gracias a AJAX, pero ¿que pasa al inicio?, es decir, cuando estamos entrando en la aplicación, es el momento en el que nos descargamos toda la tecnología necesaria para que la aplicación funcione correctamente.

En estas aplicaciones tan dinámicas, la carga de javascript es muy pesada en relación al XHTML. Así que cuando accedemos a la aplicación por primera vez tenemos que descargarnos mucho javascript, en ciertas aplicaciones hablamos de unos cuantos KB (funciones nuestras), en otras de unas decenas de KB (muchas funciones y objetos nuestros) y en algunas de cientos de KB (plataformas de desarrollo javascript, pro ejemplo dojo). Descargarse cientos de KB al empezar la aplicación puede provocar que el usuario se canse, deje la aplicación y no vuelva. Así que este primer aspecto se va a dedicar a optimizar esa carga inicial.

Para conseguirlo existen herramientas que estudian tu código y devuelven un código que hace lo mismo, pero en menos espacio. Pongamos un ejemplo:

Codigo inicial:
----------------------------------------
//este fichero javascript hace........
//funcion mifuncion hace .......
mifuncion = function(param1, param2){
//multiplicamos los números
return param1*param2;
}
-------------------------------------------

Código optimizado con la misma funcionalidad
------------------------------------------------
mifuncion=function(param1,param2){return param1*param2;}
------------------------------------------------

Como puede observarse el tamaño es muchísimo menor, simplemente quitando cosas que al desarrollador le sirven, pero que al navegador del cliente no le hacen falta, así que los ficheros originales estarán en el ámbito de desarrollo y para pasarlos a explotación, se pasan por este parser que los optimiza.

En cuanto al segundo punto, cierta seguridad de nuestro código nos puede servir tanto para que el desarrollador tenga un código propio y nadie se lo robe (ya que el javascript es interpretado y hay que enviar los fuentes al navegador), como para comprimir aun más el javascript que enviamos.

Esta ocultación del código se consigue gracias a la ofuscación del mismo, esto consiste en cambiar los nombres de las variables, funciones, objetos, etc. por nombres que no dicen nada semantico, es decir, las variables podrian ser en lugar de: arbol, persona, objeto; pondríamos: v1, v2, v3, etc. Hay que fijarse que con esto además de conseguir código ilegible, necesitamos menos caracteres por variable.

Utilizando la primera idea y esta segunda, conseguimos que nuestro código inicial que tenía aproximadamente 200 caracteres pase a ser de la siguiente forma:

------------------------------------------------
f1=function(v1,v2){return v1*v2;}
------------------------------------------------

Que ocupa 33 caracteres, conseguimos un código ilegible para una persona, pero funcional para un navegador y conseguimos además disminuir el tamaño en más de 6 veces

Jose Carlos Calvo Tudela