Ninja Team

Cuando desde Keep It Simple Lab nos llega un correo porque alguien quiere que le ayudemos con temas de SEO y WPO cada vez se esta haciendo más frecuente la pregunta de qué software se está utilizando y dónde (en casa o externalizado) está el equipo de desarrollo. Y depende mucho de esta respuesta que queramos trabajar con esa persona o empresa. ¿Por qué? La respuesta es muy sencilla: no queremos trabajar con gente inútil. Y no me entendáis mal, no quiero decir que la gente sea tonta o similar, sino que no es útil. Tanto en temas de SEO y aún más en temas de WPO es muy importante hacer las cosas exactamente como se piden. Por eso somos buenos, porque sabemos con exactitud lo que hay que hacer, pero sobretodo si se puede o no hacer. Y aquí es donde entran los “problemas”.

Pero antes de seguir me gustaría introducir varios conceptos:

  • Ninja: Los ninjas eran un grupo militar de mercenarios entrenados especialmente en formas no ortodoxas de hacer la guerra, en las que se incluía el asesinato, espionaje, sabotaje, reconocimiento y guerra de guerrillas, con el afán de desestabilizar al ejército enemigo, obtener información vital de la posición de sus tropas o lograr una ventaja importante que pudiera ser decisiva en el campo de batalla.
  • Código Spaghetti: El código spaghetti es un término peyorativo para los programas de computación que tienen una estructura de control de flujo compleja e incomprensible. Su nombre deriva del hecho que este tipo de código parece asemejarse a un plato de espaguetis, es decir, un montón de hilos intrincados y anudados.
  • Framework: Un framework para aplicaciones web es un framework diseñado para apoyar el desarrollo de sitios web dinámicos, aplicaciones web y servicios web. Este tipo de frameworks intenta aliviar el exceso de carga asociado con actividades comunes usadas en desarrollos web.

Ahora que ya sabemos lo que es un ninja, un framework y el spaghetti-code podéis haceros una idea de por dónde quiero ir. Y es que estoy muy cansado de los frameworks. Son una putas cajas negras que las cosas más sencillas de hacer en spaghetti se vuelven muy complejas. Como digo esto lo explico desde la propia experiencia, porque dos de los últimos proyectos que nos hemos encontrado hechos en Symfony o se han ido al retrete o se tienen que rehacer, y ya no os cuento cosas hechas en CodeIgniter. También he sufrido mierdas hechas con Zend que han acabado en la Papelera de Reciclaje.

Y que conste que no estoy en contra de los frameworks, estoy en contra de los programadores que no saben qué hace un framework ni cómo solventar problemas que generan. Y aunque no estoy en contra de ellos, sí que estoy en contra de los que usan uno y no saben bien bien qué configuración genera por defecto. Por ejemplo, hace unos días nos encontramos un marrón con Symfony en el que devolvía unas cabeceras HTTP/1.0 (tecnología de Internet que hace más de 10 años tiene una versión 1.1) y por otro lado unas configuraciones multiidiomas que sí, que están estandarizadas en el RFC2616 pero que cuando la “gente” te pide SEO es para tirar a la basura el proyecto porque vuelves loco a los buscadores.

Y esto me lleva al tema de la eficiencia. Está bien hacer las cosas, pero es mejor hacer las cosas perfectas. Y si a eso le sumamos la simplicidad, tenemos lo que hacemos en Kisslab. De ahí tener un equipo ninja, equipo en el que, a la hora de desarrollar, me incluyo. Y es que hay que ser resolutivos. Frente a una situación desagradable hay que poner un poco de cabeza, buscar la manera más simple de solventarla y solventarla, y, por experiencia, lo mejor en un sitio web es el spaghetti-ninja, un monstruo que llega y arraza por donde paza.

Sé que lo que voy a decir puede sonar muy nazi, pero a los programadores, por norma general, no hay que dejarlos pensar, hay que dejarlos programar. Para pensar ya hay otras cabezas que son las que en determinados proyectos tienen un medio-largo plazo y a veces piden a los programadores cosas con cierta visión. Esto no significa que un programador sólo tenga que picar teclas, porque hay otros proyectos donde se puede hacer pajas mentales y que salga lo que salga… eso sí, luego suelen llegar llorando porque el SEO y WPO no acaban de irles bien. Suelen usar tecnologías que sólo usan ellos (y que por supuesto no saben escalar cuando eso se va de madre), las últimas versiones de sus lenguajes de programación favoritos (y porque son conscientes de que las versiones alpha pueden fallar, que sino te las cuelan) y lo mismo con usar bases de datos no-relacionales. Es todo muy bonito en su cabeza, pero en la realidad de Internet eso no funciona.

Y en este sentido puedo decir que tengo un equipo que no me lo merezco. Seguramente Jaume puede opinar mucho más que ha tenido entre manos a decenas de personas de estos ámbitos y en vista a los proyectos (propios) que tenemos he de decir que a veces me dan ganas de mandar de vacaciones a parte del equipo porque cuando tienen claro lo que hay que hacer, lo hacen rápido y bien, y eso no tiene precio.

Bueno, ahora ya podéis venir a abroncarme, aunque no vais a conseguir hacer cambiarme de opinión.

VelocityConf EU + WebPerfDays 2012

Ha sido una semana un poco estresante, pero por fin ha acabado y con mucha emoción. El lunes pasado veíamos Jaume Ferré y yo a Londres para este par de eventos, el VelocityConf y el WebPerfDays que han sido sin duda más que interesantes. La verdad es que no sería capaz de hacer un resumen, porque me llevo más de 15 páginas de mi libreta llenas de anotaciones, herramientas, y sobre todo, confirmaciones.

En realidad la conclusión que saco de los eventos es que en Keep It Simple Lab tenemos una “triple A” (AAA) en lo que se refiere a conocimientos y aplicación de Web Performance, y eso es algo que me enorgullece mucho, porque ya son más de 3 años trabajando mucho en estos temas después de aquella charla en la que hablé de ello sin saber que era en realidad (por aquellos días le llamaba “infraestructura SEO”). Aún recuerdo que muchos de los presentes pensaban que me había vuelto loco e incluso algunos de los que hoy ofrecen servicios de WPO han aprendido todo lo que saben a raíz de esa presentación y de la Guía WPO que poco después acabé publicando.

Esto también va a tener un impacto directo con el evento WebPerf ya que es probable que poco a poco comencemos a tener patrocinadores y ponentes internacionales que den una visión muy distinta de lo que conocemos.

Pero, volviendo a los eventos en sí, comentarios varios que me gustaría hacer. Por un lado, estoy muy contento de haber conocido a Steve Souders en persona. Sin duda es un tío genial, muy accesible y muy trabajador, además de tener las ideas claras, participar y tener un ansia de aprender cosas nuevas que es admirable. Por otro lado también muy contento de haber conocido a decenas de personas que sigo habitualmente, entre ellos a Joshua Bixby al que espero ver pronto por Barcelona.

Propiamente sobre el evento (el VelocityConf), como decía antes, no sé por dónde empezar. Herramientas, tecnología, entender con más detalle algunas cosas, optimización para móviles, saber qué datos son importantes y cómo mostrarlos, mucha práctica y sobre todo metodología, algo que los clientes van a notar significativamente, ya que estamos en disposición de mejorar el rendimiento de los sitios web enormemente.

Además de esto, me han dado ideas para montar una serie de herramientas mucho mejor que la “breve” herramienta de medición de web performance que hice en un rato pero que me ha servido para analizar muchos sitios web. Ahora intentaré dar un gran paso adelante, aunque primero voy a poner a prueba algunos de los sitios web que controlamos y que tienen algunos detalles que corregir.

Han sido 3 días muy intensos aunque he de decir que la organización en muchas ocasiones era un poco caótica. Para empezar algunas salas estaban en una punta y el resto en la otra, lo que te hacía perder más de 5 minutos yendo de un sitio a otro. A parte las sillas no eran muy cómodas, no había dónde apoyar el portátil o una simple libreta y faltaban muchos enchufes, lo que ha hecho que no pueda retransmitir el evento como me hubiera gustado. Digamos que todo era bastante estrecho. Eso sí, los contenidos del evento, han sido muy buenos.

Cambiando de tercio, el WebPerfDays ha sido una cosa completamente distinta. Para empezar ha sido en las oficinas de Facebook Londres que nos han dejado toda una planta de su edificio para nosotros. Me recordaba mucho al estilo de las oficinas de Grupo ITnet. Además, había “barra libre” prácticamente de todo, al más puro estilo de la empresa… comida, refrescos, salas disponibles, Internet funcionando perfectamente… en fin, un lujo.

Con respecto a las charlas, me ha encantado. Ha sido en formato de unconference. Esto viene a significar que no hay ninguna agenda cuando se llega allí, sino que se hace una pequeña introducción del evento, suele haber una primera charla magistral, y luego se deja tiempo para que los asistentes pongan en una pizarra/pared los temas que les gustaría que fueran tratados. En esa lista de temas he añadido dos dudas que tenía (más bien que quería corroborar). Tras esto, el responsable del evento agrupa las preguntas por temas principales y se busca entre el público aquellos que puedan “dirigir” esa pequeña charla/debate (porque participaba muy activamente el público, algo que es de agradecer) y se abre el debate. Al final del evento las preguntas que quedan en el tintero se hacen con un panel en el que los ponentes o participantes principales dan sus respuestas, e incluso son los propios ponentes los que hacen preguntas al público.

Un detalle que sí que me ha gustado, a parte de ser un evento con un perfil técnico muy importante, es el buen rollo, las ganas de participar, las ganas de compartir y el código abierto que hay, algo que hacía mucho que no veía, principalmente en los eventos que se hacen en España en los que normalmente hay secretismo y la gente simplemente no explica nada (lástima que mi inglés no es tan fluido como para dar unas charlas, porque sino dejaba ya de hacerlas en España y me enfocaba a ir a eventos internacionales donde fluye mucha información e ingenio).

En resumen, con ganas ya de prepararme para el siguiente evento en Londres antes de final de año, y los que se vienen en 2013 alrededor del globo. Gracias Londres por una semana que será difícil olvidar.

WordPress Child Themes y WPO

Desde hace unas cuantas versiones de WordPress que está disponible la opción de los Child Themes. Este sistema una de las cosas que pide es que, la creación de este sistema tiene como base hacer un @import del CSS padre.

En este sentido, aunque los ficheros PHP sobre escriben los otros, por lo que no hay afectación directa sobre el WPO, sí que hay un detalle que no es del todo correcto, y es precisamente ese, el base para crear un hijo, el de hacer ese import.

Y es que los @import son una de las reglas “prohibidas” en cuanto a WPO. Así que… ¿qué solución tenemos para arreglar esto?. La primera de ellas es hacer un copy & paste de todo el contenido del fichero. ¿Problema? Que si hay una actualización de la plantilla padre la información de la plantilla hijo no se actualizará.

La otra opción, que es algo más elaborada, lo que viene a hacer es lo mismo pero de forma automatizada. Para empezar el fichero no será un CSS al uso, sino que será físicamente un fichero PHP. En esa carpeta tendremos que incluir un .htaccess que haga un “rewrite” del .CSS al .PHP. Con esto tenemos solventado que el sistema vea que eso es una hoja de estilos válida. El fichero .htaccess será algo tal que así:

RewriteEngine On
RewriteRule ^style.css style.php

Ahora lo siguiente es automatizar el fichero .CSS. Para ello debemos hacer un par de temas. Lo primero es pensar que es un fichero programado, de forma que hay que devolver el contenido en el formato correcto. Así, la primera línea del fichero será algo tal que:

header('Content-Type: text/css');

Lo siguiente será incluir el contenido del fichero CSS original. Por ejemplo:

$contenidocss = trim(file_get_contents('../twentyeleven/style.css'));
if($contenidocss) {
  echo $contenidocss;
}

Si lo juntamos todo, nos quedaría algo similar a esto en el fichero style.php:

<?php
header('Content-Type: text/css');
?>
/*
Theme Name:     Twenty Eleven Child
Theme URI:      http://example.com/
Description:    Child theme for the Twenty Eleven theme 
Author:         Your name here
Author URI:     http://example.com/about/
Template:       twentyeleven
Version:        0.1.0
*/
<?php
$contenidocss = trim(file_get_contents('../twentyeleven/style.css'));
if($contenidocss) {
  echo $contenidocss;
}
?>
// a partir de aquí van los cambios y nuestros retoques del CSS
body {
  font-family: Verdana;
}

Con esto conseguiremos que el waterfall del sitio web no se vea bloqueado por culpa de ese @import en el CSS, que además siempre está al principio de las peticiones y no tiene ningún sentido.