SEO ¿tecnología o marketing?

Seguramente al leer este título se os vengan a la cabeza (sobretodo los que me conocéis) las diferentes disputas que he tenido a lo largo de los últimos 10 años con compañeros de la profesión. Para adelantar, siempre he defendido que el SEO es tecnología por una gran razón: los buscadores los programan ingenieros.

Independientemente de esto, estos días atrás tuve la oportunidad de asistir como profesor de WPO una vez más al Master SEO KSchool y fue cuando me di cuenta de que ya no tenemos porqué discutir sobre este asunto.

El Web Performance comenzó, para muchos, como una parte pequeña dentro del SEO, pero cada vez más va teniendo un peso distinto, ya que se puede aplicar WPO sin necesidad de tener que pensar en SEO. El WPO ya es una ciencia completa, de forma complementaria al SEO.

Con los alumnos al final llegamos a la conclusión de que todos los elementos del SEO más técnico se podían integrar en la parte del FEO (Front End Optimization) que, junto al SSO (Server Side Optimization) forman el WPO (Web Performance Optimization). Es decir, que el SEO hoy en día se quedaría principalmente con la parte más de marketing y contenidos y el WPO se lleva la parte más técnica. Que conste, por adelantado, que “hacer bien el HTML” para mi personalmente no es tecnología propiamente dicho, ya que eso es algo que hay que hacer bien por parte de cualquier persona que se dedique a Internet, forme parte del equipo que sea.

¿Qué significa todo esto para el sector? Pues la verdad es que creo que nos venía bien una especialización, en general, de todo. El SEO (para bien o para mal) ya no evoluciona mucho. Al final hay que acabar “haciendo las cosas bien” y sólo se detectan cambios cuando Google “toca” (algoritmos tipo Panda o Penguin) que básicamente lo que consiguen es que aquellos que hacen “trampas” o “las cosas mal” (sabiéndolo o no) se obliguen a mejorar. Pero el resto simplemente han de ir trabajando día a día. En cambio el WPO es un sector muy distinto al SEO, ya que, en paralelo a la tecnología, no deja de evolucionar. Cada vez que hay una nueva versión en un navegador, en un estándar (HTML, CSS, JavaScript…), que “fulanito” se inventa las pantallas 2K o 4K y requiere inventar un sistema para cargar imágenes con muchas resoluciones… todo este mundo cambia en pocos meses y no son muchos los que pueden seguir este ritmo ¡y sólo estoy hablando del FEO! Ya que si nos ponemos a habla de SSO hay que pensar hasta en reconfigurar el kernel de Linux si es necesario para optimizar las conexiones con el servidor.

Los alumnos del master me preguntaban que dónde se podía aprender todo esto del WPO, y la verdad es qe es algo bastante complejo… tengo la suerte de poder dedicar en mi día a día entre 1 y 2 horas a leer, documentarme y probar, en fin, a hacer un poco de I+D+I dentro de este sector y me encuentro la situación en la que es muy difícil encontrar otras personas con las que cruzar información. En España el único evento sobre WPO es precisamente el WebPerf, evento que ahora está parado porque es muy difícil encontrar ponentes que vengan a explicar alguna cosa… ¡y seguro que los hay! Así que habrá que seguir leyendo e investigando al resto del mundo para poder seguir evolucionando en esta parte más técnica.

Los DNAME en las DNS

Aunque ahora mismo es tan sólo una propuesta, creo muy acertada esta nueva posible entrada de las DNS porque, sobretodo a nivel de rendimiento de WPO podría dar un salto cualitativo en cuanto a determinadas acciones que hacemos habitualmente con los dominios, más concretamente con las redirecciones. Incluso, he de añadir, para reducir el impacto de la cantidad de líneas que puede haber en los servidores DNS.

Para situarnos estoy hablando de la propuesta del RFC 6672 (DNAME Redirection in the DNS) que propone incorporar una entrada nueva llamada DNAME.

Para no entrar en detalles muy raros, voy a intentar poner un caso para ver el sentido que tiene. Imaginad que tenemos dos dominios iguales, con las mismas entradas DNS. Por ejemplo [example.com] y [dominio.es]. Dado este caso, en que los dos dominios son exactamente iguales (a nivel DNS)… ¿tiene sentido mantener dos copias de las entradas DNS? ¿No sería más fácil decir que las entradas DNS de [dominio.es] son una copia de las de [example.com] y simplemente cambiando las del .com que se actualizase todo?

Pues básicamente este es el objetivo de la entrada DNAME. El ejemplo visual (los que tocáis mucho las DNS seguramente lo pilléis enseguida:

    QNAME            owner  DNAME   target         result
    ---------------- -------------- -------------- -----------------
    com.             example.com.   example.net.   <no match>
    example.com.     example.com.   example.net.   [0]
    a.example.com.   example.com.   example.net.   a.example.net.
    a.b.example.com. example.com.   example.net.   a.b.example.net.
    ab.example.com.  b.example.com. example.net.   <no match>
    foo.example.com. example.com.   example.net.   foo.example.net.
    a.x.example.com. x.example.com. example.net.   a.example.net.
    a.example.com.   example.com.   y.example.net. a.y.example.net.
    cyc.example.com. example.com.   example.com.   cyc.example.com.
    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
    shortloop.x.x.   x.             .              shortloop.x.
    shortloop.x.     x.             .              shortloop.

El objetivo es que el campo “target” sea como el sustituto del patrón que se le pasa. De esta forma, poniendo la tercera línea de ejemplo, tendríamos que, partiendo de la base de [a.example.com] el dominio sería [example.com] y el DNAME sería [example.net], si hacemos un “sustituir” de [example.net] por [example.com] nos quedaría [a.example.net].

El planteamiento, a nivel de similitud, es como un CNAME con esteroides, ya que no deja de ser como un alias, pero que además sustituye fragmentos de las entradas DNS por otras que pueden ser de otro dominio.

Un detalle interesante es que, aunque no se recomienda su uso, se podría a llegar a utilizar el “wildcard” (o sea, el [*.example.com] para sustituir grandes cantidades de entradas DNS por otras. No se recomienda el uso porque podría invalidar el DNSSEC, pero la verdad, teniendo en cuenta la poca penetración que tiene, tampoco tengo claro que, para la mayoría, sea un problema.

Aunque no deja de ser una propuesta (en mi opinión muy interesante) no tengo claro que sea algo que se vaya a implementar rápidamente. Seguramente dependerá más de los ISP que comiencen a implementar servidores que lo soporten, pero, tampoco es algo que creo que sea muy recomendable para la gran mayoría de los usuarios, ya que un pequeño error puede provocar la invalidación de las DNS. Así que, lo más probable es que para añadir una entrada de este tipo se tengan que hacer varias validaciones “automáticas” para controlar las posibles cagadas poniendo estas entradas.

Piensa en asíncrono

Sin duda una de las mejoras del HTML5 es la posibilidad de cargar determinados elementos de forma asíncrona en la página. Y es que si tus usuarios utilizan navegadores de versiones superiores a Firefox 3.6, IE 10, Chrome 2, Safari 5, iOS 5 o Android 3 dispones de la posibilidad de hacerlo fácil:

<script async src="http://example.com/javascript.js"></script>

La carga de los scripts se puede hacer de muchas formas… la más sencilla, por ejemplo si es de un recurso propio, se puede hacer de esta forma:

<script>
  var resource = document.createElement('script');
  resource.src = "http://example.com/javascript.js";
  var script = document.getElementsByTagName('script')[0];
  script.parentNode.insertBefore(resource, script);
</script>

O también de esta forma… ambas son similares:

<script>
  (function(d, t) {
    var g = d.createElement(t),
    s = d.getElementsByTagName(t)[0];
    g.src = 'http://example.com/javascript.js';
    s.parentNode.insertBefore(g, s);
  }(document, 'script'));
</script>

Esta es una forma que permite la carga aunque no es del todo efectiva ya que no siempre se carga asíncronamente. Para ello, sobretodo si es de scripts externos se puede usar algo más así:

<script>
  (function(){
    var a = document.createElement('script');
    a.type = 'text/javascript';
    a.async = true;
    a.src = 'http://example.com/javascript.js';
    (document.getElementsByTagName('head')[0]||document.getElementsByTagName('body')[0]).appendChild(a);
  })();
</script>

Ahora que ya sabemos cargar los scripts de forma sencilla y asíncrona… ¿por qué no cargar algunos scripts “famosos” de forma sencilla y sin que afecte negativamente a tu sitio web?

El código de Facebook:

<div id="fb-root"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
    js = d.createElement(s);
    js.id = id;
    js.src = "http://connect.facebook.net/es_ES/all.js#xfbml=1";
    fjs.parentNode.insertBefore(js, fjs);
  }(document, 'script', 'facebook-jssdk'));
</script>

El código de Twitter:

<a href="https://twitter.com/share" class="twitter-share-button">Twitear</a>
<script>
  !function(d,s,id) { 
    var js,fjs = d.getElementsByTagName(s)[0];
    if(!d.getElementById(id)) { 
      js = d.createElement(s);
      js.id = id;
      js.src = "http://platform.twitter.com/widgets.js";
      fjs.parentNode.insertBefore(js,fjs);
    }
  } (document,"script","twitter-wjs");
</script>

El código de Google+:

<g:plusone annotation="inline"></g:plusone>
<script type="text/javascript">
  (function() {
    var po = document.createElement('script');
    po.type = 'text/javascript';
    po.async = true;
    po.src = 'http://apis.google.com/js/plusone.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(po, s);
  })();
</script>

Pero… ¿no sería más sencillo mantener un único código para todo? La solución es bastante sencilla, ya que al fin y al cabo en todos los casos se carga de la misma forma…

<script>
  (function(doc, script) {
    var js, fjs = doc.getElementsByTagName(script)[0], add = function(url, id) {
      if (doc.getElementById(id)) {
        return;
      }
      js = doc.createElement(script);
      js.src = url;
      id && (js.id = id);
      fjs.parentNode.insertBefore(js, fjs);
    };
    add('http://www.google-analytics.com/ga.js', 'ga');
    add('http://apis.google.com/js/plusone.js');
    add('http://connect.facebook.net/es_ES/all.js', 'facebook-jssdk');
    add('http://platform.twitter.com/widgets.js', 'twitter-wjs');
  } (document, 'script'));
</script>

¡Ahora a reprogramar!

Adiós cookies, Hola localStorage

Sin duda las cookies han sido grandes aliadas a lo largo de la historia de la programación, y ya ni te cuento las bases de datos. Pero esto desde el lanzamiento semi oficial de HTML5 ha cambiado bastante ya que si queremos almacenar datos tenemos un nuevo aliado: el navegador.

Y es que entre las mejoras que incorporan las nuevas versiones de los navegadores nos encontramos con la posibilidad de almacenar datos en el navegador del usuario y poder recogerlos de nuevo mediante unos sencillos JavaScript.

Existen dos formas de almacenar información: la temporal y la permanente. La primera de ellas la encontramos con las funciones de sessionStorage, sólo se mantiene mientras está la misma sesión del navegador, o sea, podemos cerrar y abrir ventanas, pero no cerrar “el programa”; y la segunda con las de localStorage que, a diferencia del caso anterior, los datos se mantienen aunque el navegado se cierre, ya que la información se almacena en local siempre y cuando el usuario no la elimine.

Esto da pie a muchas mejoras sobretodo en lo que a Web Performance se refiere, ya que a diferencia de las cookies esta información no se transmite por HTTP. De todas formas, esto también tiene un inconveniente, y es que trabajar con los sistemas de cookies de los lenguajes de programación como ASP o PHP se complica.

¿Quieres ver un pequeño ejemplo del funcionamiento de esto? Pues te dejo con un par de pruebas de ambos sistemas en los que se puede ver en el código fuente el funcionamiento. El ejemplo que siempre se me viene a la cabeza es el del carrito de la compra

SEO y WPO para WordPress en Punt Multimedia

El pasado viernes tuve, una vez más, la oportunidad de colaborar con los compañeros del Punt Multimedia de Barcelona dando un par de charlas, la primera de ellas sobre SEO para WordPress y la siguiente sobre WPO para WordPress.

Cuando voy a dar este tipo de charlas soy bastante consciente de que la parte de SEO la gente la tiene bastante asumida, por lo que directamente no hablo de SEO propiamente dicho (o sea, no hablo de keywords, cabeceras y cosas de ese estilo) y me centro en mejorar el propio WordPress, que creo que es para lo que la gente va.

En cambio, con el tema del Web Performance, que ya implica un nivel técnico más elevado siempre suelo ver caras raras, algo a lo que ya me he acostumbrado, y de ahí que las presentaciones intenten ser más bien tirando a lo práctico que no a lo teórico, eso sí, siempre explicando ejemplos reales de cosas que hemos conseguido hacer con estos sistemas. Al final, así como tema recurrente, aparecen las “10.000 visitas concurrentes” de eurocopa.com conseguidas con un WordPress.

Para los asistentes, y los no asistentes, os dejo la presentación de SEO para WordPress y la presentación de WPO para WordPress para que le deis una ojeada.

#WebPerfES: Web Acceleration por Telefonica Digital Lab

Este próximo jueves estoy muy contento de poder anunciar una vez más el evento WebPerf España en el que asistirán Xiao y Eguz de Telefonica Digital Lab en Barcelona. ¿Y por qué estoy muy contento en anunciarlo? Pues por muchas razones, aunque principalmente porque Telefónica haya confiado en nosotros para explicar cómo es su sistema por dentro (tuve la oportunidad de hablar hace unas semanas con ellos y tiene buena pinta) además de ser un software que han desarrollado aquí.

¿Qué nos encontraremos? Pues nos explicarán distintas técnicas de aceleración web, CDN, soluciones y nos explicarán lo que Telefónica propone como solución. Además, se hará hincapié en la parte “pura y dura” del software que se ha creado y que hay detrás de un sistema como este.

Una vez más, el evento lo hacemos con la inconmensurable colaboración de La Salle Barcelona en el Auditorio del Edificio Sant Josep (Quatre Camins 9, 08017 Barcelona) y también dar las gracias a Telefónica por asistir como ponentes. Recuerdo que si alguien quiere presentar algún tipo de tema, sólo ha de ponerse en contacto conmigo y comentármelo.

Para acabar, recuerdo que el evento es gratuito y que tienes algo más de información sobre el próximo evento.

Resolución de sub-millisegundos en WPO

Sin duda que el WPO se haya convertido en un estándar es un gran paso, pero como ya comenté una vez y no me caso de repetir, el WPO es cómo la Fórmula 1. Y esto tiene un problema con los relojes actuales… y es que el tiempo lo miden en milisegundos.

Esto hace que la información detallada que tenemos es la cifra que ha pasado desde el 1 de enero de 1970 (hora UTC). ¿Qué ocurre con esto? Que si queremos medir, por ejemplo, los “frames por segundo” tenemos información sesgada, ya que no es 100% medible con exactitud.

Ahora se está planteando un estándar para aumentar la resolución en algunos casos (como por ejemplo la API del “performance”) llamada High Resolution Time. Con esto conseguiríamos tener 1.000 veces un milisegundo, que no es poco.

Ahora podemos conseguir los datos (en milisegundos, normales) de la siguiente forma en cada navegador… a ver a partir de qué versión disponemos de estos nuevos datos mucho mayores.

En Firefox (a partir de la versión 7.0):

  • Entrar en una página web
  • Pulsar F12 para abrir las herramientas
  • Pulsar en la pestaña de Consola
  • En la parte final tras las tres >>> escribir: performance.timing
  • Pulsar sobre la línea de resultados PerformanceTiming y desplegar los resultados.

En Chrome (a partir de la versión 6.0):

  • Entrar en una página web
  • Pulsar F12 para abrir las herramientas
  • Pulsar en la pestaña de Consola
  • En la parte final tras las tres >>> escribir: performance.timing
  • Pulsar sobre la línea de resultados PerformanceTiming y desplegar los resultados.

En Explorer (a partir de la versión 9.0):

  • Entrar en una página web
  • Pulsar F12 para abrir las herramientas
  • Pulsar en la pestaña de Consola
  • En la parte final tras las dos >> escribir: performance.timing
  • Tras algunos de los resultados de PerformanceTiming, pulsar en “Agregar para ver”.

Si quieres hacer algunas pruebas con estos datos, puedes usar la herramienta de Análisis de Datos de Performance.Timing.

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.

Evento WebPerf: DNS

Se acerca el Evento Webperf de Septiembre 2012, en esta ocasión sobre las DNS. Y es que muchas veces pensamos que las DNS son algo que está ahí, que da igual poner unas que otras, y eso no se ajusta a la realidad. Las DNS son uno de los elementos más importantes en lo que a la gestión de un sitio web se refiere, sobre todo si tenemos en cuenta que es lo que hace que un dominio acabe funcionando.

El evento será presencial en Barcelona, el 26 de septiembre de 2012 de 19:00 a 21:00, en el auditorio de La Salle Campus Barcelona (Edifici St. Josep) Quatre Camins 9, 08017 Barcelona, Barcelona (ES)

El ponente, en esta ocasión, será Sergi Morales que nos hablará entre otras cosas de Limitaciones, DNSSEC, Los registros, Anycast vs. Unicast, Proveedores… y otras tantas cosas más (algunas no las digo porque molan mucho).

Puedes apuntarte de forma gratuita.