Cuando la sincronización ha fallado, en la barra de notificaciones de Android (la barra arriba del todo) ha aparecido el correspondiente aviso. Al hacerle click me ha abierto un dialogo preguntándome por un captcha, que por su tamaño resulta muy complicado leer y con el teclado en la pantalla resulta muy sencillo equivocarse al teclear. Después de contestar el captcha debía introducir la nueva contraseña, pero no conseguía pasar del captcha.

Tras buscar un poco por la ayuda de GMail, he encontrado que si te equivocabas en repetidas ocasiones al introducir el captcha, este se bloquearía. Por el tamaño que tiene, estoy convencido que en mis primeros intentos debo haberlo bloqueado. Por suerte los captchas se pueden desbloquear desde https://www.google.com/accounts/UnlockCaptcha, y tras hacerlo he podido poner la nueva contraseña en el móvil sin ningún problema.

Así que, ya sabéis que hacer si os encontráis en la misma situación.

Desde que las conocí, las instancias spot de Amazon EC2 siempre me habían llamado la atención desde la perspectiva económica. Aunque me parecía una forma interesante de sacar provecho económico a un exceso de capacidad de la plataforma EC2 en horas valle, que de otra forma sería desperdiciada, no acababa de entender sus ventajas frente a consolidar los servidores virtuales en un menor número de hosts y apagar los ociosos para ahorrar en consumo eléctrico. Siempre había supuesto, como gran parte de la industria, que el consumo eléctrico era el principal gasto en un datacenter.

No lo entendía hasta que hace unos días tuve la oportunidad de ver la presentación “Datacenter Infrastructure Innovation” (trasparencias) que James Hamilton dió durante el Velocity 2010. En su presentación realiza un estudio de los costes mensuales de un datacenter, mensualizando el coste de los servidores y de las infraestructuras de distribución y refrigeración a lo largo de sus periodos de amortización (3 y 10 años, respectivamente). De esta manera, puede comparar esos gastos con el consumo eléctrico. Y resulta que el que yo suponía era el principal gasto realmente es el tercero, siendo los dos primeros el hardware de los servidores y las infraestructuras, en ese orden.

Como bien explica James, consolidando y apagando hosts se ahorraría en consumo eléctrico pero, al no estar sacando ningún provecho económico al servidor físico ni a la parte proporcional de las infraestructuras de distribución y refrigeración, realmente se está perdiendo dinero. Al contrario de lo que ocurre con el consumo eléctrico, la amortización de las infraestructuras no es algo que puedas ahorrarte.

Pero si tienes exceso de capacidad y apagar los servidores supone realmente un gasto, ¿qué se puede hacer? Ahí es donde encajan las instancias spot. Permiten sacarle provecho al exceso de capacidad que se produce en las horas valle, a un precio que resulta atractivo a los clientes. Mientras escribo este artículo, el precio de las instancias spot es un ~60% más barato que las on-demand. Eso sí, las aplicaciones que corran en este tipo de instancias deben estar preparadas para los apagados abruptos que se producen en cuanto la demanda de instancias “normales” aumenta.

Instancias spot, ahorro económico para los clientes y una forma de aprovechar la capacidad sobrante para Amazon.

Pero hoy, tras actualizar a la versión 2.8.1, por casualidad he lanzado un grep en un directorio que no tocaba y he descubierto el fichero wp-admin/includes/class-wp-filesystem-ssh2.php. Resulta que WordPress también puede usar SSH para realizar esas actualizaciones. Normalmente esa opción no aparece por que no disponemos de todo el software necesario para que funcione, pero es bastante sencillo conseguirlo. Veamos como hacerlo en una Debian:

$ sudo aptitude install libssh2-1 libssh2-1-dev php5-dev
$ sudo pecl install -f ssh2
$ sudo vi /etc/php5/conf.d/ssh2.ini
    extension=ssh2.so
$ sudo /etc/init.d/apache2 restart

Una vez tenemos instalada la extensión ssh2.so de PHP, podemos desinstalar los paquetes de desarrollo que instalamos en el primer paso.

$ sudo aptitude remove libssh2-1 libssh2-1-dev php5-dev

Listo, ya podemos actualizar los plugins desde la comodidad de nuestro navegador sin necesidad de tener un servidor FTP o FTPS. Seguramente también se puede usar para actualizar el propio WordPress, aunque no lo puedo confirmar ya que yo lo actualizo usando subversión.

Como se puede ver es bastante sencillo. De todas formas, os dejo un screencast que he hecho sobre la instalación (inaugurando mi cuenta de YouTube).

De todas las reglas, las más sencillas de corregir son:

• Add Expires headers
• Compress components with gzip
• Configure entity tags (ETags)

Otras reglas pueden suponer reescribir parte de la aplicación pero para solventar estas tres basta con añadir algunas líneas al final del .htaccess del directorio raíz de nuestra web. Hay que tener en cuenta que los modulos necesarios deben estar instalados y la configuración del servidor nos debe permitir establecer esta configuración (directiva AllowOverride)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Add Expires Header
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>
 
# Compress CSS files
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml application/rss+xml application/atom_xml
AddOutputFilterByType DEFLATE text/css application/javascript
</IfModule>
 
# ETag only use file time and size, but no inode
FileETag MTime Size

En las líneas 2 a 9 configuramos que las imágenes, hojas de estilo y javascripts tengan una fecha de expiración de una semana a partir del momento en que se ha visitado la página web. Esto significa que el navegador del usuario usará la copia local (fichero cacheado) durante una semana. Este comportamiento puede suponer un problema si tenemos ficheros de estos tipos que vamos modificando sin cambiarle el nombre (p.e. un banner) ya que los navegadores de algunos de los usuarios mantendran las versiones antiguas.

Desde la 12 a la 15 configuramos la compresión de las páginas HTML, feeds (text/xml, application/rss+xml y application/atom_xml), hojas de estilo y javascripts. De esta forma conseguimos ahorrar tráfico (importante si estamos en un hosting con limitaciones de tráfico)  y que el tiempo de transmisión sea menor.

Finalmente, en la última línea configuramos los ETags generados por el propio servidor Apache para los ficheros estáticos. Por defecto, Apache tiene en cuenta tres aspector para generar el ETag: el inodo, fecha de modificación y tamaño. Pero se recomienda no usar el inodo para generarlo ya que si nuestra web empieza a ser conocida y tenemos que distribuir la carga entre varios servidores, es muy poco probable que un fichero tenga el mismo inodo en todos los servidores de la granja. Entonces, el ETag variaría en funcion del servidor que lo generara por lo que no se sacaría provecho a esta cabecera. Para resolverlo, configuramos el Apache para que genere el ETag sólo considerando la fecha de modificación y el tamaño del fichero.

Con esta simple configuración yo conseguí pasar de una puntuación de 74 a 89.

A medida que pueda escribiré algún post más sobre optimización web y como resolverlo en el caso concreto de un blog que usa WordPress.

Una de estas aplicaciones, WordPress for iPhone, es la que me ha permitido publicar este post desde mi iPod Touch. Todavía le faltan algunas funcionalidades como, por ejemplo, la de un editor enriquecido que permita añadir enlaces o algo de estilo (listas, negrita, etc.) a los post, pero seguro que sólo es questión de tiempo.

Por eso, un día empecé a evaluar alternativas que se ajustaran mejor a mis necesidades. Las únicas características que me interesaban eran que pudiera organizar las fotografías en álbumes, que se pudiera mostrar los datos EXIF de las fotografías, poder etiquetarlas, valorarlas y comentarlas, que se integrara con WordPress y que fuera una herramienta libre. Finalmente encontré Zenphoto, que cumple con todas esas necesidades excepto la integración con WordPress. En su web lo definen como:

Zenphoto is an answer to lots of calls for an online gallery solution that just makes sense. After years of bloated software that does everything and your dishes, zenphoto just shows your photos, simply. It’s got all the functionality and “features” you need, and nothing you don’t. Where the old guys put in a bunch of modules and junk, we put a lot of thought. We hope you agree with our philosopy: simpler is better. Don’t get us wrong though –zenphoto really does have everything you need for your online gallery, and you’ll even stare in awe at some of the innovative innovations we innovated upon.

Con el plugin ZenphotoPress para WordPress conseguí poder añadir fotos de la galería en los posts de forma simple. Pero integrar la apariencia me lo tuve que currar yo, usando como guía este post de Steffen Rusitschka. Pero con ese método Google no indexaba las páginas de la galería, aunque se visualizaban correctamente, porque todas devolvían un status 404. Además, compartían el título (tag <title> del HTML) haciéndolo muy poco Search Engine Friendly. Para solucionarlo tuve que modificar un poco el código de Steffen. Este es el index.php de mi theme integrado con el WordPress:

<?php if (!defined('WEBPATH')) die(); normalizeColumns(3, 6); ?>
<?php require($_SERVER['DOCUMENT_ROOT'].'/wp-blog-header.php'); ?>
<?php
// set the HTTP status
status_header('200');
 
// add the zen headers to the wordpress header
function zentitle() {
  echo '&raquo; '.strip_tags(getGalleryTitle());
}
function addzen() {
  global $_zp_themeroot;
  echo '<link rel="stylesheet" type="text/css" media="screen, projection" href="'.$_zp_themeroot.'/css/master.css" />';
  zenJavascript();
  printRSSHeaderLink('Gallery','Gallery RSS');
}
add_action('wp_head', 'addzen');
add_action('wp_title', 'zentitle');
?>
<?php get_header(); ?>
 
<div class="index">
  <!-- Código original de Zenphoto -->
</div>
 
<?php get_footer(); ?>

Lo más extraño es que yo tengo las bases de datos del blog y de la galería separadas pero no he necesitado hacer lo que comenta Steffen de conectarnos a una base de datos y luego a la otra. Por eso, si comparáis mi trozo de códico con el de Steffen veréis que falta esa parte. Lo siguiente será integrar el login de las dos aplicaciones, para lo que he visto que hay plugins, pero de momento no lo he mirado.

Como las URL de los álbumes han cambiado, también he añadido reglas de redirección en el .htaccess para no perder los enlaces que pudiera haber desde otras páginas.

Al final he conseguido dejarlo bastante bien integrado y estoy muy contento, tanto del resultado como de la aplicación en sí. Tiene justo lo que necesito. Ni más, ni menos.

La verdad es que está bastante bien, pero hay determinados momentos que no me han gustado tanto. Uno de ellos es cuando aparece el router por primera vez: por la forma en que lo explican parece que el router funciona de forma transparente, mientras que en la realidad los paquetes deben ir destinados al router para que este los dirija hacia el siguiente salto. Otro de esos momentos es cuando hablan del ping de la muerte, ya que me parece un poco sensacionalista y más cuando hace algunos años que los fabricantes solucionaron la vulnerabilidad.

Pero a parte de estos detalles me parece muy interesante.

“The adventures of Ace, DBA” es el título de una tira cómica que descubrí a principios de verano cuyo protagonista es Ace, un DBA de Oracle. El aspecto es similar al de xkcd, como reconoce el autor, y hay alguna tira que es para troncharse. Eso sí, no es para el público en general ya que el humor es muy geek, y en algunos casos puede ser difícil pillar la gracia totalmente si nunca has trabajado con Oracle.

La lástima es que desde finales de Agosto no ha publicado ninguna tira nueva.

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 ), 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.

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”.