blog de luxspes

La nueva iniciativa Datos de libre acceso del Banco Mundial, puesta en marcha el 20 de abril de 2010, pone a disposición de todos los interesados de manera gratuita una serie de datos clave, entre ellos los Indicadores del desarrollo mundial, los Indicadores del desarrollo de África, los Indicadores de las finanzas mundiales y los de Doing Business. El objetivo del Concurso de Aplicaciones para el desarrollo es reunir las ideas de los desarrolladores y de los que se ocupan del desarrollo para crear herramientas, aplicaciones y combinaciones de datos innovadoras usando la información provista por la mencionada iniciativa. De esta manera, la competencia respaldará la meta de la institución de reducir la pobreza en el mundo al poner información importante a disposición de quienes pueden contribuir significativamente con los países en desarrollo.

Mas informacion aqui.

Escribe el siguiente código:

Que se imprime? Si contestaste: 0.06, estas equivocado.

Se imprime: 0.060000000000000005

Ahora escribe:

Que imprime? 0.06.

James Gosling: Renuncia a Oracle (y a Java?)!. El autor de Java a renunciado a seguir trabajando en Oracle. Significa esto que ha renunciado a trabajar en Java? O veremos en el futuro su participación a través del proyecto Harmony o de IceTea pero a traves de otra compañia? A mi me encantaría que alguien con su peso decidiera apoyar a un proyecto como Scala o Rel. ¿Que creen ustedes que haga? ¿Por que habrá renunciado a Oracle? Se habrá enterado de que el rumbo por que Oracle llevara Java en el futuro no es bueno?

Continuando con las restricciones

En la parte II vimos que era posible efectuar un insert así (en donde el Usuario 'Rodrigo' no existe en la relvar/tabla de usuarios):

Y la base de datos no nos lo impediría... ¿como podemos evitar que este tipo de "registros huérfanos" entren en nuestra base de datos?

Es necesario establecer una “restricción” en nuestra base de datos, así: :

Digamos que se tiene un pantalla mas o menos así:

Tengo un combobox ( ) en donde selecciono el país, y abajo se rellena otro combobox, en donde aparecen los estados para ese país, y cuando selecciono un estado, me aparecen las ciudades de ese estado, y cuando selecciono la ciudad, me aparecen otro combo para seleccionar la colonia.

Hacer algo asi con Richfaces+JSF, con Tapestry, AribaWeb o Wicket no parece demasiado difícil...
Hacer lo mismo con Capucchino+DWR, o Flex+GraniteDS, tampoco es demasiado difícil...

Pero aquí viene el reto: Reducir el numero de peticiones al servidor pero sin traerme todos los datos de todos los países/estados/ciudades/colonias desde un principio, por que eso hará que mi pantalla tarde demasiado en cargar (y desperdicie memoria), pero quiero que al seleccionar un país por segunda vez, no vuelva a ir por la lista de estados... y al seleccionar un estado por segunda vez, no vuelva a ir por la lista de ciudades al servidor, y al... bueno, ya se hacen una idea.... ;-)

Un poco de Historia y teoría

En la primera parte de esta serie de “blog posts” sobre el proyecto Rel, hable acerca que de Rel era una base de datos verdaderamente relacional, pero no aclare mucho acerca de que distingue a una base de datos verdaderamente relacional de una que no lo es. Bueno, revisitemos la definición de una base de datos relacional.

Nos interesan, en este caso, particularmente 2 de las 12 las reglas que el inventor de las bases de datos relacionales (Edgar F. Codd) propuso para describir a una base de datos relacional:

Reglas de Integridad

Cuando los datos se modifican con sentencias INSERT, DELETE o UPDATE, su integridad puede perderse de muchas maneras diferentes. Pueden añadirse datos no válidos a la base de datos, tales como un pedido que especifica un producto no existente.

Pueden modificarse datos existentes tomando un valor incorrecto, como por ejemplo si se reasigna un vendedor a una oficina no existente. Los cambios pueden ser aplicados parcialmente, como por ejemplo si se añade un pedido de un producto sin ajustar la cantidad disponible para vender.

Para evitar que la integridad de los datos se pierda, se pueden definir reglas que se encargaran de protegerla. Estas reglas pueden definirse en distintos niveles del código de la aplicación:

En Swing se puede navegar de un componente a otro usando las teclas Tab o Shift-Tab. Estas teclas son las "teclas de recorrido de foco" (focus traversal keys) y pueden ser cambiadas programaticamente. Por ejemplo, tu puedes agregar la tecla Enter a la lista de teclas de recorrido de foco con el siguiente codigo:

Y eso es todo, asi de facil se puede usar Enter en ves de tab para mover el foco al siguiente elemento. Simple no? Ahora trata de hacerlo con JavaScript en una forma de HTML:

No se puede. O tal ves si, pero nadie sabe como.
Hay algunas soluciones parciales, por ejemplo, esto solo funciona en IExplorer:

El proyecto Rel es una implementación del lenguaje Tutorial D de Date y Darwen en Java.

Rel es una verdadera RDBMS (no como Oracle, SQLServer o DB2 que son solo pseudo relacionales) con un lenguaje de consultas avanzado.
Rel es gratuito y opensource

Rel implementa un conjunto extendido del lenguaje propuesto por C. J. Date y Hugh Darwen, llamado Tutorial D. Es posible que ya lo hayas visto si alguna ves leíste el libro "Introducción a los Sistemas de Base de Datos" de Date.

El objetivo principal de Rel es como una herramienta de enseñanza, para que podamos explorar los conceptos de las bases de datos relacionales, pero lo que me impresiono sobre el, es que tras conocerlo se volvió imposible para mi el considerar a SQL como una lenguaje bien diseñado. Tutorial D te hace ver que SQL es una reliquia de de los 70 de la que ya deberíamos habernos deshecho hace mucho tiempo... y sin embargo, seguimos creando lenguajes para consultas lo mas parecidos a SQL que podemos, con el objetivo de facilitarle el aprendizaje a las personas que ya saben SQL, sin darnos cuenta que el aprender SQL en si mismo es una fuerte limitación a la productividad.

Empecemos con la operación relacional proyeccion: Veamos una comparación:

En SQL, puedo escribir:
 

Con lo que obtendré una consulta con las columnas a, b, c de la tabla r.

En Tutorial D dicha consulta se escribiría (en SQL es necesario escribir DISTINCT para garantizar que la salida no tenga redundancia, en Tutorial D, la redundancia esta prohibida por default por los principios Relacionales):
 

Que es mucho mas corto, hasta el momento, parece que esta es la única ventaja, pero ahora supongamos que la tabla "r" tiene los campos: a,b,c,d,e,f,g,h,i, y que solo queremos ver los campos d,e,f,g,h,i.

En SQL escribiria:
 

Mientras que en Tutorial D escribiria:
 

Vas a construir una nueva aplicación.. si eres como yo alguien que disfruta de las ventajas de la reutilizacion que te dan los proyectos opensource, y te estan pidiendo la tipica aplicacion web que tanto se acostumbra en estos tiempos... que haces?

Pues desde el principio ya estas pensando: Spring (o Weld si queres probar algo mas nuevo) para integrarlo todo, JPA para guardar en la base de datos... JSF, Wicket o Tapestry para la interfaz... y si tengo que poner mucha interactividad con Javascript? pues DWR!

Y construyes tu aplicación... Inclusive escribes un script de Ant para poder generar el .war que subiras (de forma tambie automatizada) al servidor de produccion...

Ignoremos por un momento los problemas que hayan podido surgir durante el desarrollo, y pensemos que llego el dia de finamente entrar "en produccion":