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

Acabo de oír por la radio que Jazztel está ofreciendo conexión a Internet mediante líneas ADSL con velocidades de hasta 20Mbps en sentido descendente, de Internet al usuario (lo que no conozco es el ancho de banda de subida). Para poder ofrecer este servicio usan tecnología ADSL2+ sobre infraestructura propia, es decir, no usan la de Telefónica, por lo que la cobertura de este servicio todavía es limitada si la comparamos con la ofrecida por Telefónica u operadoras que utilizan la infraestructura de Telefónica.

Realmente, la velocidad ofrecida es la máxima que permita la línea, siendo los 20Mbps la velocidad máxima que soportada sólo disponible cuando el estado de la línea es óptimo y no hay mucha distancia entre el domicilio del cliente y la central donde está el DSLAM, que es la terminación de la ADSL en el lado del proveedor.

El interés que le veo a esta noticia es que, si un proveedor está empezando a ofrecer este servicio y a este precio (Ahh, y todo esto por 29,95€ + IVA al mes, con llamadas locales y nacionales incluidas.), tengo la esperanza de que el resto de proveedores lo imiten o, como mínimo, tomen acciones beneficiosas para los clientes para intentar igualar la oferta y evitar que los usuarios se cambien de operadora. Es decir, aprovecharnos de la competencia para que mejore el estado de las conexiones de banda ancha en este país con la esperanza de igualarnos con el resto de países europeos (bueno, y si podemos estar mejor que el resto tampoco me voy a quejar ).

No creo que la idea sea nueva en absoluto, pero el otro día se me ocurrió que podía utilizar un sintetizador Text To Speech (TTS) para ayudarme a corregir las faltas ortográficas que se me escapan cuando escribo algún post en esta web.

El Konqueror, navegador que utilizo habitualmente, tiene incorporado un corrector ortográfico y me marca las faltas en las textareas donde escribo el cuerpo del post, pero los errores que se me suelen escapar son los acentos diacríticos y estos no me los marca. Ahora bien, estos errores cantan enseguida al leer el texto, así que nada mejor que un sintetizador TTS para encontrarlos. En GNU/Linux tenemos un sintetizador libre, festival, y en la última versión de las KDE (3.4), es posible integrarlo con el Konqueror. El programa que permite esta integración es el kttsd y el plugin correspondiente para el navegador. Podemos encontrar el paquete correspondiente en el mismo repositorio donde están los de KDE 3.4:

deb http://pkg-kde.alioth.debian.org/kde-3.4.0/ ./

Ahí quedan mis 2¢.

Los desarrolladores del módulo para las tarjeta de red WiFi basadas en el chipset Intel Pro Wireless 2200, típico de los portátiles con tecnología Intel Centrino, han necesitado casi un año para incluir el soporte para el modo monitor, pero al fin ya lo tenemos (Ojo, no me estoy quejando, simplemente expongo el hecho de lo que han tardado). El anuncio oficial lo podéis leer en el apartado de noticias de la web dedicada al driver.

El modo monitor es necesario si se quiere hacer wardriving y es una de las cosas divertidas que se pueden hacer con un portátil

Ahora estoy a la espera de que actualicen el paquete correspondiente de la Debian Sid para instalarlo y poder probar el kismet. Ya os contaré…

A falta de nada mejor que comentar, hoy me he decidido por contaros los últimos “juguetitos” que me he comprado. El primero es un iPod-mini de 4GB. Es un cacharrito muy cuco y estoy bastante contento con su compra pero le encuentro algunos defectillos. El más importante es que no basta con copiar los ficheros al reproductor como en la mayoria de reproductores MP3 sino que se necesita un programa para gestionarlo (iTunes en Windows o Mac OS X, o gtkpod en GNU/Linux). Esto tiene el defecto añadido de que si quieres gestionarlo desde más de un PC, debes tener una copia de las mismas canciones en todos los PCs.

El segundo juguete es una cámara digital, en este caso me incliné por una Konica-Minolta DiMAGE X50. Es una camara de 5 Megapíxeles ultra-compacta. Tiene un gran display LCD de 2 pulgadas, el zoom óptico es interno, es decir, al hacer zoom las lentes no sobresalen sino que se mueve internamente, y la calidad de las fotos es muy buena. Por otra parte, se accede como cualquier dispositivo USB mass storage, por lo que funciona de muerte con digikam. Como mejora al respecto de otras versiones anteriores (como por ejemplo la DiMAGE Xt) es que esta camara sí guarda la información EXIF con la posición en la que se hizo la fotografía

Espero haberos puesto los dientes largos, aunque solo sea un poco.

Ese es el tráfico que tuvimos ayer en el trabajo. Tuvimos casi 11Mbps de subida de forma mantenida durante casi cuatro horas, y eso que aún no ha empezado lo fuerte, así que no me quiero imaginar hasta donde llegaremos.

Ya se que hoy en día se menosprecia bastante el ancho de banda, en el sentido en que un usuario domestico puede tener una línea de varios megas de bajada, pero el trafico al que hago referencia estaba siendo generado por nuestros servidores web respondiendo a los accesos de los usuarios.

Por otra parte, aquellos que tengan memoria histórica, recordaran que no hace mucho (unos 5 o 6 años) íbamos con modems de 56Kbps y sólo podíamos pensar en alcanzar los 10Mbps en redes locales, que además se montaban con cable coaxial.

Nada, me apetecía reseñar el día en que superamos los 10Mbps.

Más vale tarde que nunca, pero quería comentar algo sobre los RFC que se publican cada primero de abril, el “Fools’s Day”, algo así como nuestro día de los santos inocentes pero para los americanos.

Para aquellos que no lo sepáis, un RFC es un documento técnico donde se especifican recomendaciones y estándares. Para más información podéis leer la entrada de la wikipedia [inglés] [español] (recomiendo la versión inglesa por ser más completa).

Desde 1989 es tradición publicar un RFC con cierto carácter humorístico cada uno de abril. Aunque hay unos cuantos RFCs publicados antes de ese año no fue hasta el 89 que se estableció como una publicación periódica.

Algunos de estos RFCs son bastante famosos, como el RFC 1149 de 1990 titulado “Standard for the transmission of IP datagrams on Avian Carriers”, que fue implementado por el LUG de Bergen. Lo divertido es que, a parte de las fotos, hay un fichero de texto con el resultado de los pings: un 55% de paquetes perdidos y un tiempo medio de ping de 5222806.6 ms (casi hora y media), y además llegaron fuera de orden Este RFC fue actualizado con soporte para QoS en el RFC 2549 del 99.

El úlimo RFC publicado es el correspondiente al de este año, pero en lugar de uno hemos tenido dos: los RFCs 4041 y 4042, titulados “Requirements for Morality Sections in Routing Area Drafts” y “UTF-9 and UTF-18 Efficient Transformation Formats of Unicode” respectivamente. En el primero se describe como introducir valores morales en el enrutado de paquetes, mientras que en el segundo se definen las codificaciones UTF-9 y UTF-18 (como añadido a los UTF-7, UTF-8 y UTF-16), especialmente pensadas para arquitecturas que no estan basadas en palabras de 8 bits, como por ejemplo el PDP-10 que tiene una palabra de 36 bits.

En la wikipedia hay un listado con los enlaces a todos los RFCs que se han publicado el uno de abril. Os recomiendo pegarles una ojeada, hay algunos muy divertidos.

Hace tres semanas un amigo se casó y mientras me vestía me encontré con el típico problema de última hora: ¿Cómo me hago el nudo de la corbata? Hasta ese día, el nudo me lo habían hecho otras personas (mi madre, mi abuelo, conocido/a de la boda, etc) Pero en esta ocasión no tenía a nadie que me la pudiera hacer, bueno, podía ir a la boda sin corbata y que me la hicieran allí, pero no quedaría bien. Así que se me ocurrió, «hoy en día cuando no sabes algo, ¿a quién recurres?, ¿quién tiene todas las respuestas?: Google».

Así que encendí el ordenador, abrí el navegador, fui a Google y busqué “como hacer nudo de corbata”. Encontró casi 8000 resultados. Seguí uno o dos de los enlaces y tras practicar dos o tres veces, y un cuarto de hora después de haber encenddo el ordenador, ya tenía hecho un nudo de corbata (que, por cierto, la novia me dijo que estaba muy bien y más siendo el primer nudo que hacía) y estaba listo para ir a la ceremonia.

De las 8000 páginas, la que tiene el dominio más curioso es www.nudo-de-corbata.com. Como mínimo, esta web me sirvió para darme cuenta que seguramente no he sido el único al que se le ha ocurrido la idea

En este blog hay varios PNGs con el fondo transparente, pero el Internet Explorer no es capaz de mostrarlas correctamente, básicamente no hace caso a la información del canal alpha (por suerte, en la futura versión 7 del IE Microsoft “innovará” añadiendo esta característica, el problema es que desde hace tiempo está disponible en el resto de navegadores así que innovar, innovar, no innovaran mucho ). No quiero sustituir los PNGs por GIFs, tampoco quiero poner el color de fondo en el PNG para no tener que editar la imagen si algún día me da por cambiarlo. Pero por otra parte, me da rabia que la página no se vea bien con el IE.

Buscando por Google, he encontrado una solución basada en CSS que consiste en configurar los img con la propiedad behavior:

img { behavior: url("pngbehavior.htc");}

Pero la propiedad behavior no es estándar y el CSS no validaba (cosa que quería evitar)

Gracias a Suki_ me he enterado que en eGroupware tienen otro workaround. Mirando el código de la web, he visto que la solución es básicamente igual que la anterior pero esta vez no se basan en CSS sino en ejecutar una función javascript con un onLoad.

Para que el IE pueda mostrar “correctamente” nuestros PNGs con transparencias tenemos que añadir las siguientes líneas en las cabeceras HTML de nuestra web:

<!-- This solves the Internet Explorer PNG-transparency bug, but only for IE 5.5 and higher -->
<!--[if gte IE 5.5000]>
<script src="pngfix.js" type="text/javascript">
</script>
<![endif]-->

y copiar en nuestro servidor web el fichero pngfix.js.

El javascript de pngfix.js recorre todas las imágenes y sustituye las que tienen formato PNG por un span con las dimensiones y el resto de propiedades de la imagen original y utiliza un filtro CSS propio del IE (AlphaImageLoader) para mostrar la imagen aplicándole transparencias. Se tiene que sustituir la imagen original por un span porque, tal y como se puede leer en la documentación del filtro en MSDN, el AlphaImageLoader muestra una imagen con transparencia entre el fondo y el contenido del objeto. Por lo tanto, si el contenido del objeto es una imagen, el contenido taparía la imagen mostrada por el AlphaImageLoader y no veríamos el efecto de la transparencia.

Soy totalmente consciente de que es una chapucilla pero no molesta al resto de navegadores, la página y el CSS siguen validando y, por fin, la web se ve como toca en el Internet Explorer.