Por estos lares, a lo largo de todo el tiempo que lleva online se ha discutido y tratado mucho el desarrollo web y la optimización en muchos aspectos: su estructura, php, apache, WordPress; sus módulos como mod_deflate, mod_forensics, mod_gzip, mod_security; php, mysql, estadísticas, un poco de todo.

Pero hacía tiempo que no me enseñaban alguna táctica “nueva” y tengo que reconocer que me ha hecho sonreír: optimización a lo burro. Seguro que los ingleses para eso le ponen un nombre mucho más chulo y comercial rollo extreme donkey programming o similar…

¿En qué consiste dicha optimización?

Tres son las claves a aplicar en este modelo revolucionario de programar y optimizar sitios web:

1. Ante un problema, aplicar hacks lo más rápido posible: cuánto más guarros mejor.
2. Velocidad por encima de calidad.
3. ¿Quién dijo miedo?.

EL ejemplo

El autor de semejante hazaña tiene un sitio web cuyo nivel de visitas lo hace prácticamente inaguantable para el servidor que lo aloja.

El presupuesto de su empresa para mantenimiento de ese servidor cabe en una caja de cerillas y el correspondiente a adquisición de nuevos servidores es como Dios: se habla mucho de él, muchos dicen haberlo visto pero nadie ha conseguido aportar pruebas de dicha existencia.

Así pues ante el problema (punto 1) toca aplicar una serie de hacks lo más rápido posible, que resumiré en lo que se hizo primero ante el problema del número de peticiones HTTP:

cat textstyles.css iehacks.css template.css \
innertemplate.css form.css > style.css

cat head.php.inc menu.php.inc body.php.inc \
foot.php.inc > index.php

rm printstyles.css

cp index.php index.php.backup
sed -e 's/.jpg/mini.jpg/g' index.php.backup > index.php
rm index.php.backup *.inc
gzip style.css index.php

O para los que no son muy aficionados a la consola:

Junto todos los estilos (incluidos aquellos que no son necesarios cargar en ciertas circunstancias como el “iehacks” cuando el navegador no es Internet Explorer) en un fichero, ídem con las plantillas que forman el esqueleto del diseño web.

Se cargó todo el trabajo de presentación CSS para impresión. Sustituyo todos los enlaces de imágenes para que estas cargasen directamente las miniaturas en lugar de enlazar el tamaño.

Lo dejo todo comprimido (cuando suele ser lo mejor pero no en todos los casos).

Y para rematar después de quitar todos los espacios en blanco que no eran de los textos (sacados vía base de datos) y/o necesarios con la intención de reducir al máximo el tamaño de CSS/HTML borro los ficheros originales ¿copias de seguridad para qué? ¿quién dijo miedo?.

De lo que no hay duda es que consiguió su objetivo: ahora el sitio vuela. Y lo increíble es que haya gente cobrando por estas “cosas”…

Con el poco tiempo que tengo para dedicarle al blog (se nota en la bajada de entradas últimamente) pese a la de años que llevo con el y aún llega un buen puñado de gente =P.

Así que toca hacerle mantenimiento, como de costumbre.

• Eliminado código basura que todavía pululaba por aquí. (Esto debería hacerlo cada semana).

  Si de algo estoy orgulloso de este blog, es que una de mis prioridades siempre ha sido que “cargue bien”: el mínimo javascript posible, el diseño lo más limpio posible, código HTML legible, etcétera.

• Archivos mensuales en un “dropdown box” (vamos, una lista dentro de un “select”). Esto es un cambio más bien estético pero la lista de entradas mensuales ya no ocupará tanto en el menú y volverán a ser visibles las estadísticas y el icono de “feed” sin necesidad de un scroll tan largo.

TuXeD, autor de /var/log/TuXeD y un viejo conocido de los foros HxC (una revista que salió en España que tuvo una vida corta) está realizando desde primeros de marzo una serie de entradas sobre criptografía a las que recomiendo echar un ojo para quienes gusten de estos “temas raros” (fue a hablar la tacones…):

• Cripto Serie: Introducción - Conceptos Básicos.
• Cripto Serie: Clasificación de ataques.
• Cripto Serie: Cifrados clásicos.
• Cripto Serie: Cifrado Vigenère.

Que aproveche.

Por fin una buena noticia en estas semanas de panorama realmente deprimente en cuanto a derechos de los internautas: Los internautas logran detener el Paquete Telecom.

El paquete de medidas que la Eurocámara tenía que votar hoy, que al principio sólo suponía armonizar la legislación relacionado a Internet entre los distintos miembros de la Unión Europea — y que a medio camino fue cambiado para añadir “un par de cosillas” — ha sido rechazado tal como fue planteado.

Estas “dos cosillas” de las que se habló son las que más han dado que hablar en la red durante la semana: cargarse la neutralidad de la red y permitir la desconexión del usuario sin orden judicial.

Finalmente se ha aprobado una enmienda que exige una orden judicial para que un proveedor pueda desconectar a alguien de la red. “Más o menos” como siempre vamos. Ahora falta que el paquete de medidas con esa enmienda pase por una tercera lectura, lo cual da más tiempo para evitar atropellos como los que inicialmente querían imponer.

Cargarse la neutralidad de la red crearía un preocupante precedente, verlo como una forma de salvaguardar la cultura (comercial)es una forma simplista y corta de ver los verdaderos problemas que eso puede provocar (y ya provoca). Lo que es Internet no sería posible sin la neutralidad del mismo: cualquiera puede ofrecer un servicio (una web, un protocolo, lo que sea) en las mismas condiciones.

El día que un ISP pueda cortar sin pudor alguno el acceso de sus clientes a la competencia, a servicios que compiten con él, discriminar tráfico legitimo “que no le interesa”… la cosa pintará muy mal. Mucho peor que eso de cortar Internet a “esos piratones”…

Añado un comentario de PutridCorpse dicho originalmente en EOL:

La verdad es que es irónico que en plena crísis de empleo y consumo pretenden desconectar a usuarios de un servicio que consumen y que genera empleo para alimentar una industria que acude a galas en coches de lujo y trajes de diseño.

Más razón que un santo.

Si poco escribo ya, este mes va a ser particularmente seco en entradas: cero, ni una, nothing. Bueno sí, esta para avisar ;P

Acabo de leer una resumida entrada en el blog de Dreamhost acerca de una funcionalidad de WGET.

En la entrada comentan como han decidido añadir “continue = on” al fichero /etc/wgetrc debido al uso que se hace del wget con el cronjob.

El cronjob es un “administrador de tareas” que ejecuta lo que se le dicte a la hora que se le dicte, es un programa muy usado para todo tipo de tareas automatizadas o para automatizarlas (hacer copias de seguridad tal día, pasar a limpio unos registros HTTP para los programas de estadísticas, reiniciar servidores).

Prácticamente cualquier tarea que se pueda ejecutar en uno o varios comandos se puede automatizar con cron. Wget es de sobras conocido para bajar vía interprete de comandos un fichero en una dirección HTTP.

El problema viene cuando wget por defecto si intenta guardar un fichero en un lugar que ya existe un fichero con el mismo nombre, lo creará terminado en “.1″, si este ya existe con “.2″ y así.

Es ahí donde empieza lo divertido: cuántos más ficheros crea más comprobaciones hace para ver que “fichero.1″ está cogido, “fichero.2″ también, “fichero.3″ también.

Creando problemas de rendimiento, espacio en disco duro, cientos de ficheros “basura” (normalmente) que no son usados, etcétera.

Y pensar que hace tres o cuatro años un cronjob+wget me trajo muchos dolores de cabeza en un servidor web…

Últimamente he estado recibiendo algunas consultas y/o quejas de algunos miembros que contribuyen en Planet Webdev dado que su contenido no es adecuado (offtopic).

Después de revisar cada caso por separado todos llevan a lo mismo: la persona al cargo del sitio que genera “offtopics” está suscrito en Planet Webdev con un feed personalizado que ha dejado de funcionar.

Tratan distintos y variados temas en su blog y tienen una categoría “desarrollo web”, “webdev” o una combinación de tags que devuelve como resultado entradas sólo de la temática que a ambos (yo en el planet, ellos como interesados en la promoción de sus contenidos) nos interesan.

El problema surge cuando estos bloggers pasan a utilizar FeedBurner y sin darse cuenta esos feeds “personalizados” redirigen automáticamente al feed general eliminando una de las ventajas del CMS utilizado en el sitio: crear feeds de categorías/etiquetas en particular.

El culpable seguramente sea uno de esos plugins de Wordpress que redirigen por defecto todos los feeds a FeedBurner (hay dos o tres). Desconozco si hay alguna opción para desactivar este comportamiento en los feeds personalizados.

Así pues aprovecho para comentar que en un plazo medio (tengo que mirarlo detenidamente) haré limpieza de estos feeds si no encontramos una solución los afectados.

A quienes se han quejado de este comportamiento, pido paciencia. Hay que entender que esto ha sido un efecto colateral no esperado por parte de estos bloggers. Han empezado a “bombardear” el Planet con contenido no relacionado simplemente porque escriben mucho. Culpables cero.