Para aquellos de vosotros que todavia me leeis, os dejo un cromo: un video/presentación que estoy seguro os gustará.

Espero vuestros comentarios.

Link

¿Recordáis las fotos de portátiles con las pantallas transparentes? Pues no hace mucho vi el mismo efecto pero en un vídeo y me pregunté si sería capaz de hacerlo. Bueno, aquí tenéis el resultado:

¿Quieres saber cómo lo hice?, sigue leyendo…

(more…)

Recientemente he descubierto un conjunto de utilidades libres que nos permiten juntar una serie de fotografías para crear una fotografía panorámica: hugin, enblend y autopano-sift.

Estoy preparando un articulo con mis experiencias, pero para ir abriendo boca podéis echarle una ojeada a mis primeras pruebas:

• Panorámica 180º estática
• Panorámica 360º

Actualización: He movido el applet a una página aparte para aligerar la página principal.

A finales de los ‘60, principio de los ‘70, la agencia estadounidense ARPA se propuso conectar los mainframes de varias universidades norteamericanas usando conmutación de paquetes, creando la red que se conocería como ARPANET y que sería la precursora de la Internet actual.

En un principio se propuso que fueran los propios mainframes de las universidades los que se encargasen del enrutado de paquetes, pero en aquellos tiempos la potencia de cálculo era extremadamente preciosa y los administradores de los mainframes estaban preocupados por el efecto negativo que podría tener ese trabajo extra en sus máquinas. Por eso, finalmente se decidió que el trabajo duro de enrutado lo llevase a cabo un dispositivo externo que se conoció como IMP, que era un minicomputador (supongo que en aquellos tiempos tenían un concepto diferente de lo que es mini porque, a mi, algo del tamaño de una nevera no me parece pequeño :-D), en concreto un Honeywell 516 como el que se puede ver en la foto de al lado. El desarrollo de los IMP fue llevado a cabo por la empresa BBN Technologies que, sorprendentemente, todavía existe.

Los IMP estaban conectados mediante lineas dedicadas de 50kbps fullduplex. En un momento determinado, se decidió que era necesario conectar esta red a otras como SATNET y ALOHANET, entre otras. Cada una de estas redes tenía sus protocolos y había que encontrar una forma de que todas ellas pudieran comunicarse, lo que impulso la creación del protocolo TCP, que posteriormente se partió en dos: TCP e IP.

Digo que fueron los primeros “routers” porque, hasta entonces, la conmutación de paquetes no había sido nada más que un ejercicio teórico. De hecho, ARPA le ofreció a AT&T el desarrollo de la red pero esta declinó la oferta ya que consideraba que la conmutación de paquetes no funcionaría nunca.

Todo esto y más (como por qué usamos la @ en las direcciones de correo) lo podéis encontrar en el libro “Where wizards stay up late”, lectura que os recomiendo.

Como curiosidad, el último IMP fue apagado en 1989.

Es sabido por todos que Google tiene la costumbre de alterar el logo de su página en fechas señaladas. Por ejemplo, hoy lo han cambiado para celebrar el día de Halloween. Bien, pues hoy he encontrado la galería con todos esos logos que Google ha usado desde 1999.

Mientras miraba los logos del 2004, en concreto el del 1 de abril ;-), he visto que Google quiere abrir una oficina en la luna y buscan empleados. Si os animáis, podéis enviarles un correo a lunarjobs@google.com.

Para finalizar, mientras leía esa “oferta de empleo” he encontrado un listado con mil y una formas de buscar “Britney Spears”.

En la edición del pasado Agosto de la revista online Linux Gazette, leí un artículo que explicaba como generar Audiobooks a partir de varios formatos de libros electrónicos. Después de leerlo pensé si sería capaz de adaptarlo para generar automáticamente podcasts a partir de los posts de un blog. De esta manera los lectores de ese blog podrían descargar los ficheros de audio y escucharlos con su reproductor multimedia portátil mientras van, por ejemplo, en el autobús.

La verdad es que no me ha costado mucho tener algo que funcione. He programado un plugin para Wordpress que se encarga de generar el fichero de audio al editar un post. El plugin utiliza el Festival para pasar el texto a audio, y el LAME para codificar ese audio en MP3. De momento sólo tiene soporte para castellano, ya que el idioma está hardcoded en el script que llama a Festival.

Si queréis escuchar como suena podéis usar estos ficheros de ejemplo.

Para más información, podéis ir a la página del plugin.

Supongo que todos recordaréis que ocurría cuando buscabas “conejito” o “hell” en Google. Yo acabo de descubrir una nueva, al menos para mi ;-), en un blog (WRT) que me he encontrado por casualidad: en Google, buscas failure y pulsas sobre “I’m feeling lucky”. Es para partirse. Como no creo que le haga mucha gracia a según que pez gordo, me he guardado unas capturas de pantalla que colgaré por aquí si lo quitan.

Por cierto, para aquellos que no lo recuerden, cuando buscabas “conejito” en Google, te salia un mensaje de “Quiso decir c**o”. Y al buscar “hell”, el primer enlace era a Microsoft.

Hace unas semanas descubrí la existencia de la publicación técnica de “The Internet Protocol Journal“. A pesar de ser una revista hecha por Cisco, no es una publicación publicitaria, como mínimo los números que yo he leído no lo son. La revista está disponible en su web en HTML o PDF (incluidos los números anteriores), pero podemos suscribirnos gratuitamente para que nos envíen un ejemplar en papel. Yo ya me he suscrito, pero como la publicación es trimestral, todavía no he recibido ninguno así que no os puedo contar que tal.

Para que os hagáis una idea de la temática, en los pocos ejemplares que he tenido tiempo de leer he encontrado artículos como “A pragmatic report on IPv4 address space consumption”, “Practical uses of SSH tunneling in the internetworking”, “High Availability in Routing”, “IPv6 Autoconfiguration”, etc. Tampoco penséis que se centran en una plataforma en concreto (estoy pensando en sus routers). Por ejemplo, en el artículo de túneles SSH se ve como se configura un Putty en un Windows, en el de autoconfiguración de IPv6 hablan de una RedHat.

Bueno, algo más que leer en el tiempo libre. Si alguien lo lee, que cuente lo que le ha parecido.

El problema

Como ya he contado anteriormente, recientemente he instalado el Gallery2 y lo he integrado con el Wordpress mediante el plugin WPG2. Con este plugin, además de sincronizar los usuarios de Wordpress con los de Gallery2, podemos añadir imágenes en nuestros posts simplemente con los tags <wpg2> y <wpg2id>. Con el primero añadimos la imagen mediante su path, y con el segundo, lo añadimos por su id. Por ejemplo:

<wpg2>album/foto01.jpg</wpg2>

El problema es que con estos tags no es posible enlazar a una imagen/álbum desde un enlace de texto. Es cierto que puedo poner a mano la URL de la imagen/álbum en los enlaces, pero si alguna vez cambio las reglas de reescritura del Gallery (parecido a los permalinks de Wordpress), tendré que revisarme todos esos enlaces repartidos por los posts y corregirlos uno a uno. Como no estoy dispuesto a hacerlo he pensado en crear otro pseudotag, <wpg2link> que me dé la URL. De esta manera yo podría usar algo así como

<a href="<wpg2link>album/foto01.jpg</wpg2link>">foto</a>

que se traduciría en algo como:

<a href="http://www.example.com/photos/album/foto01.jpg">foto</a>

Así, si alguna vez cambiara las reglas de reescritura de Gallery2, el enlace cambiaría automáticamente para apuntar a la dirección correcta.

La solución

Después de estudiar el código tanto del plugin WPG2 como de Gallery2 he visto que sería suficiente modificar el fichero wp-content/plugins/wp-gallery2/g2embed.php. Lo que he hecho ha sido añadir dos funciones: una que devuelve la URL de la imagen a partir de su path, y otra que se encarga de sustituir el pseudotag por la URL generada automáticamente.

Cuando ya lo tenía funcionando, he intentado averiguar como podía hacerle llegar estas modificaciones a los autores del plugin y mientras buscaba por la página de plugin y por los foros, he encontrado un post en el foro que hablaba justamente de esto. Pero allí comentaban usar <a href="wpg2link:album/foto01.jpg">foto</a>, que me ha gustado más que lo de <wpg2link></wpg2link>, y ha sido la abreviatura que finalmente he usado. Pero para justificar mi código, he de decir que la implementación del foro me parecen una chapuza

Para aquellos a los que le interese esta funcionalidad adicional, os podéis descargar mi parche y lo aplicáis con patch -p0 < g2embed-wpg2link.patch, suponiendo que estáis en el directorio wp-content/plugins/wp-gallery2/ y que el parche se encuentra en ese mismo directorio.

Por cierto, no he encontrado ninguna forma de contactar con los desarrolladores. Por no encontrar no he encontrado ni una lista de correo de desarrolladores. Supongo que podría poner un post en el foro, me imagino que alguno de los desarrolladores lo debe leer.

El otro día, no recuerdo muy bien a cuento de qué, me acordé de la exponenciación binaria, que es un algoritmo de exponenciación en aritmética modular que me explicó un profesor en el año que cursé Ingeniería de Telecomunicaciones en la UPC. Desde entonces siempre había tenido curiosidad por averiguar cual sería la diferencia en cuanto a tiempo de cálculo entre hacer la exponenciación por el método clásico o hacerla usando el algoritmo que me explicaron. Cansado de tener esta duda rondando por mi mente decidí hacer algo al respecto en un rato que tenía más o menos libre y aquí expongo mis resultados. ATENCIóN: Estos resultados son muy aproximados así que no los toméis muy en serio, sólo como orientación.

No voy a entrar en explicar que es la aritmética modular, para ello ya tenemos una página en la wikipedia, incluso hay una página dedicada a la exponenciación modular.

El método clásico se resume en ir multiplicando la base por ella misma tantas veces como indique el exponente (que es la definición de exponenciación), pero tras cada multiplicación hay que calcular el módulo del resultado para que el resultado temporal no crezca excesivamente:

t=base;
for (i=0; i<exp; i++) {
    t = (t * base) % modulo;
}
resultado = t;


Usando este algoritmo, debemos realizar tantas multiplicaciones y operaciones de módulo como indique el exponente. Es decir, si el exponente es 1000, necesitaremos 1000 multiplicaciones y 1000 divisiones (el cálculo del módulo es una división de la cual nos quedamos con el resto en lugar de con el resultado de la división).

El algoritmo de exponenciación binaria es más complejo pero permite realizar el cálculo con un menor número de operaciones. Se basa en descomponer el exponente en suma de potencias de 2. Inicializamos la variable temporal con el valor de la base. Empezando por el segundo bit más significativo del exponente mientras no lleguemos al bit menos significativo hacemos lo siguiente: multiplicamos la variable temporal por ella misma (lo elevamos al cuadrado), si el bit actual es igual a 1 multiplicamos la variable temporal por la base, y finalmente calculamos el módulo:


t=base;
for (i=numero_bits(exponente)-1; i>0; i--) {
    t = (t * t);
    if (bit(i, exponente) == 1)
        t = t * base;
    t = t % modulo;
}
resultado = t;


Con este algoritmo, el número de multiplicaciones depende del número de bits y del peso de Hamming(número de 1s) del exponente. Poniéndonos en el peor de los casos, que sería que todos los bits del exponente fueran 1, necesitaríamos tantas multiplicaciones como dos veces el número de bits del exponente. En cuanto al número de divisiones, depende sólo del número de bits.

Para simplificar, consideraremos que el coste computacional de la operación de multiplicar es el mismo que el de calcular el módulo. Entonces, si e es el exponente, con el algoritmo hemos pasado de necesitar 2e operaciones a, como máximo, necesitar 3log₂(e). Es decir, el número de operaciones pasa de crecer linealmente con el exponente a hacerlo de forma logaritmica. Por ejemplo, si el exponente fuera 1023, pasaríamos de utilizar 2046 operaciones a 30.

Vale, sabemos que hay mucha diferencia en el número de operaciones, pero todavía no hemos visto como afecta esto al tiempo de ejecución. Como tampoco tenía mucho tiempo para dedicarle, decidí hacer dos bash scripts:

• Exponenciación clásica
• Exponenciación binaria

Una primera ejecución ya pone de manifiesto la gran diferencia que hay entre los dos algoritmos:

daneel@trantor:~$ export TIMEFORMAT="Tiempo: %Rs"
daneel@trantor:~$ time ./modexp1.sh 7 513 133
77
Tiempo: 2.280s
daneel@trantor:~$ time ./modexp2.sh 7 513 133
77
Tiempo: 0.207s


Los dos scripts calculan 7⁵¹³ mod 133, pero uno necesita 2.28 segundos mientras que el otro sólo 0.20. Para tener una comparativa más amplia, he ejecutado los dos scripts cambiando el exponente entre 1 y 1024, y recogiendo el tiempo que ha tardado el script en calcular el resultado. Después, con gnuplot he hecho la gráfica:

Creo que sobran las palabras. La diferencia es asombrosa. Así y todo, el algoritmo aquí comentado no es el más rápido, en el libro “Applied Cryptography” de Bruce Schneier hay un capitulo dedicado a la aritmética modular y explican uno todavía más rápido pero más complejo.

Igual os preguntáis para que sirve esto, pues por ejemplo en el sistema de criptografía de clave asimétrica RSA se realizan operaciones de exponenciación en aritmética modular a la hora de cifrar o descifrar el mensaje. O sea que dependiendo del algoritmo de exponenciación utilizado, tardaremos más o menos en cifrar/descifrar el mensaje.

Por cierto, en la wikipedia también explican la exponenciación binaria usando un algoritmo recursivo.

Bueno, yo ya me he quitado la curiosidad y espero haberos entretenido un ratillo