RVZ

Una de las cosas que siempre me ha gustado de KDE es la cantidad de opciones de configuración que tiene. Virtualmente todo es configurable.

Por otro lado, Chrome, a pesar de parecerme un gran navegador, hasta hoy tenía un handycap importante. No podía cambiarlo de escritorio virtual. La forma en la que se crea la ventana de chrome hace imposible acceder a los menús propios de kde.

Navengando un poco, hoy encontré la solución. Es tan simple como ir a Preferencias del sistema / Comportamiento de las ventanas / Especificas de la ventana y  crear un nuevo comportamiento para las ventanas de la clase "chromium Chromium". Para este nuevo comportamiento hay que establecer que queremos forzarla a que funcione sin borde. Luego vamos a la ventana de Chrome, botón derecho y seleccionamos "Utilizar bordes y titulos". Tachan! Ahora mi ventana de chrome tiene una barra de ventana como el resto de mis aplicaciones de kde y puedo controlar mejor el comportamiento.

Hoy me he visto gratamente sorprendido por un juego hecho en HTML5. Soporta sonidos, entrada desde teclado, gráficos con tiles en múltiples niveles.

Yo no se si es que uno es viejo, o que llevo mucho tiempo en la red. Probablemente las dos cosas, pero cuando veo cosas como esta recuerdo cuando en HTML solo se podían poner hiperenlaces e imagenes. O cuando javascript salio a la luz para "poder hacer ese efecto tan chulo". Incluso cuando por primera vez flash nos rompía los esquemas de como y para que se podía utilizar la web. 

Y es que la red ha evolucionado y se ha hecho mayor. De sus orígenes, en los que pretendía ser solo un entramado de información interrelacionada, al punto actual, en el que juegos, y aplicaciones que antes solo eran pensables para ser instaladas se ejecutan con toda naturalidad.

Aún creo que nos quedan muchas cosas por ver, y que la red seguirá avanzando pasito a pasito, pero por ahora HTML 5 promete bastante.

A raíz de mi post sobre Wpkg, un compañero me recomendo que probase nLite (gracias Carlos).

Para quien no sepa de que va la historia, nLite es una herramienta que te permite, a golpe de ratón, personalizar tu disco de instalación de Windows. De está manera podemos preparar instalaciones desatendidas, con los service packs y las actualizaciones que queramos.

El problema es que hay que tener las actualizaciones descargadas para poderlas integrar en el cd, y por si alguien no lo ha notado ya, despues del Service Pack 3 hay como unas 50 actualizaciones. Además Microsoft, siguiendo su "politica de estandars", tiene como 5 de esas actualizaciones en un formato diferente y por lo tanto no son integrables a golpe de ratón.

Para este tipo de actualizaciones hay que preparar lo que la gente de nLite llama un Addon. Un Addon es simplemente un fichero comprimido que contiene, además de los ficheros de la actualización, un fichero ini en el que se describe que es lo que debe de hacer para instalar esa actualización. Actualmente estoy peleando con este tema, pero prometo que en cuanto tenga los ficheros listos para el nLite lo colgaré por aquí para que todo el mundo se pueda hacer su CD de instalación con sp3+actualizaciones basandose en su cd original de Windows.

Today I've tried to make my QLineF3d class, but I find something that don't let me finish it.

I tried to make this class reading the code of QLineF that comes with the Qt distribution but one more time the math part kill me. When I tried to convert to 3d all the methods (or almost the main methods of the two dimensional class) I realised that I don't know how to build a line in 3d in polar cordinates... Should be Spherical coordinates? Or Cilindrical coordinates? (I mean, two angles an the lenght of the line or one angle, one height and one lenght?).

The problems appears again with the angles, I have clear how to define angles between two dimensional lines but... in 3d? two angles? the 3d angle between the lines? If I use the last approach should I give the plane that holds the lines?

Reading the Qt code I found things that I don't want to do. Some referent to the style, like define the function with variables named diferent than the ones in the implemention and something like that ( maybe I'll send a patch to the Qt guys) . And some releated to speed of the maths, I found that they use a function from graphics gems III to make intersection between a segment and a point. I'm not really sure but I thing that I've read somewhere better ways to do that (I have to search in my books, in codepixel list , in google....)

I have also some things that I should use. Some friends talk me every day about tests. I know that are usefull, I had the oportunity to "test the test" in work and its great to catch the bugs. I'm not using any test but I should do it. For the math parts will be really usefull, so propably I'll spend part of the weekend looking for testing tools for C++, learning how to use them, and reading details about math problems. I'll try to have on monday a the QLineF3d class finished. Then probably I'll try to make my camera class and start studing what I'll use to store the data.

Like in AC/DC the song.... "It's a long way to the top if you wanna rock and roll" :D

I always wan't to make my own raytracer. I have the oportunity in the university, but the raytracer that I want to do then was bigger than the one that I need to do for the university so I get out of time (and didn't pass that assignment). So after reading a lot about realtime raytracers in Codepixel and in Jon Valdes blog I decided to make a really small raytracer.

The first step was remember all about math. I ned to remember what I have to do to know if a ray intersects a triangle. There a lot of methods about it, and a lot of changes to make it faster using sse instructions and stuff like that. But I need the earlier and easiest way. So I get my "Collision detection in interactive 3d enviroments" and I read the easy way to do that. The easy way use Cramer's method to solve an ecuations system. And I didn't remember how It works. So I spend one full night to understand all of this. If someone wants more information about the other methods you can take a look to Codepixel Wiki entry about it. I'll probably talk about all the math stuff when I'll do it in code but today I only wan't to give an overview of what I have now.

I also need more information on how to transform the screen positions into world positions to calculate the ray, after some time trying to figure how to do that. I asked to Jon Valdes and he send me to an old post in codepixel mailing list where he ask the same thing. I've read Alex Méndez answer and I get the solution.

The next thing to solve was a technological problem, what to use? OpenGL? Qt? in which language? C? C++? Ruby? Other? Finally I'm quite sure to do it in C++ with Qt. So I start again to make some test to remember how Qt works. (You know hello world tutorial and something like that).

Ok when I thougth that I can begin with the math part in code, and make appear a white plane on my screen, I found another problem. Qt don't have a 3 dimensional point into their classes. So using the code of QPointF I'll start to make a QPointF3d. And that's my actual state.

I'll try to do something every day (at least a few lines and a post) tomorrow (or even tonight) I'll try to make another class QLineF3d to hold ray's informations.

Quién mas y quien menos todos hemos sufrido una instalación de Windows. El problema viene en que no es solo instalar el windows, también es el instalame el firefox, el plugin de flash, el acrobat reader, el winamp y si me apuras hasta el programa especifico de hace 50 años.

Para automatizar todo esto y no tener que currar una y otra vez con los 1500 clicks en pantalla aparece Wpkg. La idea es bastante simple, ya que windows trae un interprete de JScript (o sea lo que microsoft entiende por JavaScript), hagamos uso de él. La gente de wpkg se han currado un script que permite arrancar los instaladores de las aplicaciones remotamente. Además permite definir diferentes perfiles según las máquinas, con ello conseguimos que en una instalación multitudinaria de máquinas, sea tan fácil (o casi) como llegar enchufar la máquina a la red y a correr.

En la parte del servidor todo muy simple, una máquina con un recurso compartido (ya sea samba o active directory) con los scripts de wpkg y los instaladores de los programas que queremos meter.

En la parte del cliente más fácil aún.

• Opción A: Nada, simplemente arrancando el script con cscsript desde una consola de windows la magia se hace sola.
• Opción B: Instalar el cliente de Wpkg. Está opción nos permite automatizar el proceso de sincronización y arrancarlo a determinada hora o ante ciertos eventos (apagado, encendido...).

Además una opción bastante curiosa, wpkg también se puede meter en un cdrom. Si a esto le sumamos un autorun simpático, conseguimos tener un cd que nada más meterlo en el ordenador en cuestión instale todo el software que le hemos programado sin que el usuario tenga que hacer absolutamente nada.

Como no todo podía ser bonito hay una parte "dura" en todo este proceso, preparar los scripts para cada instalador. No es que sea especialmente complicado, de hecho muchos de ellos con 5 lineas están más que listos para funcionar. Pero el problema está en que en windows, por norma general, no hay dos programas que se instalen igual, así que hay que estar trasteando con los instaladores para ver que parámetros hay que pasarle para instalarlo desatendidamente. Y aunque con los instaladores en formato MSI se solventa en gran parte está problemática, siempre hay que andar que tocando algo para que el script cuadre con nuestras necesidades. Además siempre podemos utilizar como base la lista de scripts que se encuentran en la página de wpkg. Pero aviso a navegantes, al menos yo he tenido que tocar todos los scripts que he cogido de ahí por una u otra razón.

Como comentaba en el post anterior, en este artículo voy a hablar sobre la solución que estamos adoptando y porque hemos descartado algunas de las alternativas.

El modelo de datos

Lo primero que consideramos fue como modelar la realidad que tenemos. Pensamos, inicialmente, en un modelo como el que se muestra a continuación:

Inicialmente nos centramos en modelar los cálculos. Los cálculos deberían tener una magnitud a medir, las unidades en las que se mide esta magnitud, y el valor calculado. Así mismo, podría tener uno o varios valores de entrada o condiciones iniciales. Y además debería de tener un origen para identificar de donde proviene ese calculo.

Lo siguiente en ser modelado fueron los valores de entrada o condiciones iniciales, ya que queríamos que el sistema fuera bastante dinámico pensamos en condiciones iniciales como una magnitud, con la unidad correspondiente y su valor. Esto nos permitiría meter valores de entrada bastante complejos, pero tendríamos que crear unidades ficticias para aquellos valores de entrada que no tengan unidades de medida, como por ejemplo la configuración electrónica.

Teniendo ya los cálculos y los valores de entrada, lo siguiente a modelar fueron las unidades. Cada unidad podía tener un símbolo y un valor que contendrá una descripción más detallada de la unidad.

Finalmente modelamos las magnitudes que contendrán un valor con una descripción de la magnitud, y las fuentes con  una descripción del origen como valor.

Implementación

Para implementar el modelo descrito decidimos usar CouchDB, como ya hemos comentado anteriormente, ya que nos permite trasladar fácilmente el modelo dinámico que hemos explicado.

Pensamos en usar vistas para generar las posibles búsquedas sobre los diferentes parámetros, pero nos dimos cuenta de que la forma de filtrar y realizar búsquedas se nos quedaba muy corta para nuestras necesidades. Así que finalmente optamos por usar CouchDB-Lucene para generar indices de los documentos y poder realizar búsquedas más complejas.

Luego pensamos en donde colocar la aplicación. Primero pensamos que sería una idea genial aprovechar las ventajas de CouchDB e intentar que la aplicación migrase como mismo lo hacen los datos. Pero esta solución no nos era válida, ya que queríamos ofrecer una interfaz REST y al almacenar la aplicación como un documento en CouchDB siempre tendríamos que hacer un GET. La alternativa era tener un servidor web que se encargase de recibir la petición REST y generase las llamadas a CouchDB. Con esto obtendríamos varias ventajas de una sola vez, tendríamos la interfaz REST, podríamos definir un API mucho más cercano a nuestro problema en vez de atacar a CouchDB directamente, y además tendríamos autenticación web. Además podríamos programar la aplicación en el lenguaje que quisiéramos y no nos veríamos atados a JavaScript. Así que finalmente optamos por esta opción, programando la aplicación en Ruby con Sinatra (aún en desarrollo), pero no hemos abandonado del todo la idea de que la aplicación migre.

Arquitectura Calculus

En los próximos post hablaré de todo el desarrollo en concreto, como generamos los indices con CouchDB-Lucene, como usamos Sinatra y demás. Prometo que serán mucho más técnicos.

Parece ser que la gente del grupo Khronos al fín se han puesto las pilas y están empezando a cumplir las promesas. En el Sigraph de este año ya han anunciado la release 3.2 de OpenGL! Y como siempre nVidia detrás lanzando su driver OpenGL 3.2.

Como novedades más funciones antiguas retiradas,formato bgra, y al fin geometry shaders! Parece que la gente de Khronos ha decidido hacer la competencia de verdad a DirectX copiandoles las cosas que funcionan... Con un poco de suerte volveremos a traernos a la comunidad de programadores de juegos (o eso espero)
Especificaciones OpenGL 3.2:

http://www.opengl.org/registry/doc/glspec32.core.20090803.pdf

Hace tiempo que estamos trabajando en un software sobre CouchDB y va siendo hora de que contemos algo sobre él.

Lo primero va a ser explicar el problema, y en los posts siguientes hablaremos de la solución que estamos adoptando y el porqué decidimos seguir ese camino.

El problema

El departamento de física de la Universidad de Las Palmas de Gran Canaria (en adelante ULPGC), nos comentó que ellos realizaban muchos de sus cálculos apoyándose en resultados de otros departamentos de física. Pero que no existía ningún sitio donde residieran, ni los resultados en los que ellos se apoyaban, ni los que ellos mismos generaban de forma unificada. Para complicar aún más la cosa, los cálculos realizados por un departamento se pueden apoyar en resultados experimentales, en resultados calculados matemáticamente o en una combinación de ambos.

Además nos contaban que los congresos de física los utilizan, entre otras cosas, para comparar resultados de los mismos experimentos y comprobar que los software que están desarrollando o los resultados experimentales que han obtenido son correctos.

Así que había que buscar una solución y propusimos un sistema que permita tener almacenados todos estos cálculos de forma distribuida y sincronizada. De manera que todas las máquinas que decidan unirse a está red puedan aportar sus cáculos y recibir los de los demás automágicamente. Ademas debería tener una interfaz REST para poder interactuar con la base de datos. Los calculos deberían permitir diferentes condiciones iniciales, o datos de entrada, o incluso diferentes aproximaciones para un mismo cálculo.

Este sistema permitiría, teóricamente, almacenar resultados de cualquier tipo de cálculo, sin importar el cálculo en si mismo, el número de condiciones o la magnitud que se esté midiendo.

Con todas estas precondiciones, nos dimos cuenta que necesitabamos un sistema bastante dinámico. Se podría hacer con una base de datos clásica, pero implicaría un modelo mucho mas forzado y complejo, y mucho más trabajo a la hora de intercomunicar las bases de datos para sincronizarlas.

Así que la decisión fué CouchDB.

En el siguiente post contaré un poco más de la arquitectura que hemos adoptado por el momento.

Usando CouchDB-Lucene

CouchDB-Lucene es una interfaz entre CouchDB y Lucene, un indexador de documentos. Gracias a esta interfaz podremos hacer consultas bastante complejas.

Configurando CouchDB-Lucene

Lo primero que debemos hacer para configurar CouchDB-Lucene, es informar a CouchDB que queremos que lance el proceso adecuado tanto cuando se arranca CouchDB como cuando se actualiza un documento. Además queremos que ante determinada URL, http://url_del_servidor:5984/base_de_datos/_fti, también se lance el proceso de CouchDB-Lucene. Para ello, editaremos el fichero de configuración de CouchDB, local.ini, y añadiremos las siguientes líneas.

[external]
fti = /usr/bin/java -jar /path-couchdb-lucene/couchdb-lucene-0.3-SNAPSHOT-jar-with-dependencies.jar -search

[update_notification]
indexer = /usr/bin/java -jar /path-couchdb-lucene/couchdb-lucene-0.3-SNAPSHOT-jar-with-dependencies.jar -index

[httpd_db_handlers]
_fti = {couch_httpd_external, handle_external_req, <<"fti">>}

 

Además de estas líneas hemos de aumentar el tiempo de espera, ya que entre arrancar la máquina virtual de Java y hacer la busqueda podemos tener un parón importante. Así que también añadiremos lo siguiente para establecer un timeout de 6 segundos:

[couchdb]

     os_process_timeout = 60000

 

Con esto ya tendremos configurado CouchDB-Lucene, ahora habrá que crear los documentos apropiados para configurar la indexación. Hay que tener en cuenta que el proceso que acabamos de seguir para configurar CouchDB-Lucene se puede utilizar para lanzar cualquier otro proceso cuando se produzca una consulta y/o una actualización en CouchDB.

Estableciendo los documentos de indexación

Para poder utilizar CouchDB-Lucene, debemos crear, al menos, un documento de diseño que nos permita especificar que campos y como queremos indexar nuestros documentos. Este documento tiene que tener un campo llamado fulltext, que contendrá un vector con el nombre de nuestro indice. Dentro de este vector tendremos un vector para especificar los parámetros a nuestro indice, y una entrada, index , donde estará la función para indicar que campos indexar. Está función se ejecutará una vez por cada documento que añadamos, mofiquemos o eliminemos. Es más claro verlo con un ejemplo:

{
  "_id": "_design/lucene",
  "fulltext": {
    "by_everything": {
    "defaults": {
      "store": "yes"
    },
    "index": "function(doc){
    var ret=new Document();
    function idx(previous,obj) {
     if (previous!='') previous+='.';
     for (var key in obj){
      switch (typeof obj[key]){
       case 'object':
        idx(previous+key, obj[key]);
       break;
       case 'function':
       break;
       default:
        ret.add(obj[key],{'field':previous+key});break;}}};
        idx('',doc);
        return ret;
   }"
    }
  }
}

Como podemos observar, hemos establecido un valor por defecto a la propiedad store, ya que si no la ponemos a true nuestros indices serán temporales en lugar de almacenarse en disco.

Además podemos ver el código de la función index que comentabamos antes. Esta función debe devolver un objeto de tipo Document al que se le han añadido los campos que queremos indexar . Para añadir un campo a index hemos de hacer uso del método add , pasandole como primer parámetro el valor que queremos indexar y como segundo parámetro un array con las opciones. El segundo parámetro es opcional pero lo vamos a utilizar para personalizar el nombre del campo.

En la función del ejemplo indexamos recursivamente todos los campos, de manera que si se trata de un vector se guarde bajo el campo "vector.campo: valor", esto nos resultará muy útil a la hora de lanzar las busquedas complejas.

Realizando busquedas complejas

Como veiamos anteriormente, para hacer busquedas usando CouchDB-Lucene simplemente tendremos que acceder a través de un documento especial, y le pasaremos como parámetros en la URL los parámetros de la busqueda que queramos realizar. Por ejemplo:

http://localhost:5984/base_de_datos/_fti/lucene/by_everything/?q=Configuration.Value:[3 TO 9] AND Element.Value:Fe&sort=\Score&include_docs=true

Está url buscará todos los elementos que tengan un vector Configuration con una propiedad Value entre 3 y 9, y que además tengan un vector Element con una propiedad Value igual a Fe (q=Configuration.Value:[3 TO 9] AND Element.Value:Fe). Además tenemos dos parámetros más, sort=\Score, que ordena los resultados inversamente por la propiedad Score e include_docs, que nos devolverá el documento entero y no solo su identificador . Para ordenar de forma normal, simplemente hay que omitir el simbolo \ o sustituirlo por /.

A continuación...

En principio, doy está serie de artículos por acabados. Aún queda ver la forma de formatear la salida de las vistas, pero es un API que actualmente se está cambiando así que lo dejaré hasta que se estabilice un poco. Los siguientes artículos relacionados con CouchDB hablaran sobre el proyecto que estamos desarrollando con CouchDB. Empieza lo interesante.