La semana pasada le mandaba un correo a varios clientes, amigos, proyectos con los que me he encariñado (llamadlo como queráis) explicando algunas cosas que tenían que cambiar lo antes posible. Yo les decía que antes del 1 de mayo, pero prácticamente el jueves ya tenía que estar todo hecho. ¿Y qué decía en ese correo? Pues eso me lo reservo, a medias.

Como ya sabéis Google en los últimos años ha estado haciendo muchísimos esfuerzos para “aumentar la calidad de sus resultados”. Estos esfuerzos van muy ligados a reducir (por no decir eliminar) el peso del PageRank (el tradicional de cuantos más enlaces mejor) para llevarlo al de “sólo valen los enlaces de calidad y con sentido, y los que son malos, quitan puntos”. Por otro lado también ha habido cambios con respecto a los propios parámetros dentro de los sitios web, enfocándose principalmente en que haya “mucha chicha” en las páginas, pero que sea comestible, nada de fast food. Esto viene a una cosa sencilla… mucha gente se ha enfocado a eso del link juice (una gilipollez como cualquier otra) y lo basaba en los enlaces, y no en las páginas. Se puede hacer, pero sólo la gente inteligente lo hace bien. Para acabar también se le está comenzando a dar ese peso a la personalización que hace un año no teníamos, lo que significa que el factor tiempo también ha vuelto a resucitar, ya que lo social va ligado a la temporalidad.

¿Qué significa todo esto en términos del sitio web? Pues básicamente hay tres factores a revisar que son los que en general están molestando al G-gante. Para comenzar el tema de los enlaces hay que tener presente algo que siempre he dicho: con un enlace desde un sitio es suficiente; me explico. No sirve de nada que un sitio web te ponga el mismo enlace a la página principal desde todas sus páginas. Tener 50.000 enlaces no va a ayudarte, al revés, ahora esos que lo tienen así en general están teniendo problemas. Por otro lado eso no significa que no se puedan tener 20 enlaces a 20 páginas distintas de tu sitio web.

Siguiendo con los enlaces, aunque en este caso ya afectando propiamente al sitio, algo que tampoco quiere Google es tener mucho linking interno en tu sitio que no aporta. Como ya sabemos (y si no lo sabes, retírate), Google controla la calidad de los enlaces entre otras cosas mediante herramientas como Google Analytics. Esto significa que poner una decena de enlaces en un post, entrada, artículo, noticia (o sea, contenido) a otras partes de tu sitio web sin sentido, es decir, ponerlos de forma automatizada mediante plugins o algoritmos poco inteligentes ya no ayuda (en general he tenido siempre dudas de que hacerlo de forma automatizada tenga algún sentido).

Para acabar los pies de página. Primero, al menos siguiendo la LOPD y LSSI no es necesario tener en todas y cada una de las páginas de un sitio enlaces a la información legal, al quienes somos y esas cosas… sino que con que esté en la página principal es suficiente. Por otro lado, y siguiendo con lo que comentaba antes de los enlaces internos absurdos… ¿tiene algún sentido tener en el pie de página enlaces a todas las webs “de un grupo de sitios”? Eso en general no aporta nada más que generar enlaces sin valor.

Con respecto a los contenidos, bueno, hace unas semanas cuando volví de Lyon ya comenté la importancia de escribir bien, del léxico, la gramática… la única forma de saber si algo es de calidad es simplemente escribiendo cosas que tienen sentido, que tienen lógica y tienen relevancia… así las máquinas pueden entender qué narices estamos queriendo explicar o decir.

También hay que tener presente que, como ya pasó con Google Panda, es muy probable que Google Penguin evolucione, y que lo que estamos viendo es simplemente la punta del iceberg, ese iceberg desde donde los tan geniales pingüinos se lanzan como un tobogán hasta llegar al mar.

varias personas me han preguntado estos días sobre este nuevo cambio en el algoritmo de Google. En general en mis sitios todo va subiendo, y es que, no me cansaré de decirlo: sólo hay una forma de salir bien en los resultados de búsqueda, hacer las cosas bien.

Aunque las carreras de última hora son siempre previsibles, tengo un rato para comentar varias cosas sobre el evento que, como bien dice el título habla de WordPress, de cómo conseguir que el WordPress consiga un alto rendimiento. Os dejo con la presentación para descargar y dejo el canal en directo aunque es una prueba piloto, por lo que si hay algún problema, lo siento de ante mano, seguramente poco podré hacer, aunque intentaré que sea posible que se vea (y sobre todo, que se oiga)…

Reconozco que estoy un poco nervioso, no tanto por la charla (no es ni la primera ni la última, aunque como siempre la he preparado pero improvisaré algo) sino por el hecho de organizar un evento después de tantos años sin hacer nada. Prácticamente desde el congreso OJObuscador 2007 que no llevaba a la realidad algo como esto. Además, gente a la que aprecio mucho va a estar ahí, y, no puedo fallar :)

Hala, ¡mucha mierda!

Aunque en la página del repositorio no hay mucha información, he preparado una página interna sobre este mismo tema en el que hay algo más de información, como por ejemplo algunas funcionalidades, los idiomas a los que está traducido…

Hace unas semanas ya os comenté que estábamos preparando un servicio de Varnish para WordPress como Servicio que básicamente multiplica enormemente la velocidad de carga de las páginas (el WPO y el SEO, vamos). Y como contra prestación ha salido un bonito plugin.

Aunque ha habido varias versiones anteriores 8a lo mejor algún día las subo por tenerlas ahí almacenadas) la versión 1.0.1 funciona bien, es estable y hace lo que tiene que hacer. De todas formas en mi cabeza tengo bastante claro el roadmap hasta la versión 2.0. Además, seguramente lance otro plugin (complementario al del Varnish) para que WordPress funcione perfectamente sin problemas, ya que Varnish es un proxy y eso implica cosas…

Además, he tenido el gusto de poder presentárselo a la gente de Varnish Software y junto a ellos y otras personas lo iré evolucionando al máximo.

Si alguien tiene sugerencias, quiere probar el Varnish como Servicio o cualquier otra cosa, buscad en el menú que pone “contacto” y os aparecerá mi correo ;)

Hace unos años la patente quedó fuera de los ámbitos de uso exclusivo por parte de Larry y su compañía, lo que supone que, aunque tienen derechos de uso, el objetivo a muy corto plazo es no usar dicha estrategia ya que hoy en día ya no es totalmente suya.

Ahora en 2012 todos los buscadores utilizan el concepto de que un sitio con enlaces cobra relevancia pero no como hasta ahora lo teníamos entendido, lo que significa que algo está cambiando. Es decir, tanto Bing, como Baidu o Yandex utilizan el concepto del PageRank (adaptado a su manera) pero no con las bases propias del PageRank.

Estos días que he estado en el www2012, en el que estaba Bing, Google, Baidu, Yandex, Yahoo! y seguramente otros tantos que ni fui capaz de cruzarme, ninguno de ellos hacía referencia a ese tema de dar relevancia a los buscadores en base a los enlaces, sino que todos comentaban que su trabajo estos últimos años ha sido y sigue siendo el de dar relevancia en base a la calidad. El problema es definir qué se entiende por calidad en Internet (algo en lo que Ricardo Baeza hizo mención en varias ocasiones su charla). En general la calidad va definida por cosas muy elementales como simplemente escribir bien, tener los menores errores ortográficos, semánticos y gramaticales. Por otro lado cada vez más y más se habla de la personalización, ese elemento que hace que el SEO dependa de los usuarios y no de las máquinas.

El SEO en general es algo que los buscadores tienen presente y se premia si se hace todo correctamente. El SEO “de la antigua escuela” ya no tiene por dónde evolucionar más que no sea “hacer las cosas bien”. Si sigues las normas, generas contenidos, aportas valor a tus usuarios y, de rebote, generas un buzz suficiente en la red no necesitas más. El problema (y la solución), una vez más, es hacer las cosas bien.

En muchos proyectos en los que estoy trabajando no se aprecian los detalles, esas excepciones que los programadores intentamos tratar en el día a día de un producto (que si un if por aquí que si un if por allá). Hace poco he tenido la posibilidad de comparar un desarrollo que hice hace algunos años del que estoy más que orgulloso (en el sentido de que creé un producto que lo que hacía lo hacía bien y que desde el punto de vista SEO era genial) con el mismo producto desarrollado por otra gente que hace lo mismo pero se ha hundido en la miseria a la hora de compararlo desde el punto de vista SEO; los contenidos son los mismos, se supone que tienen ahora mejores enlaces y de más calidad que antes, pero pequeños fallos de desarrollo han impedido que eso en vez de ir para arriba vaya para abajo. Y como digo con “pequeños”, pero con gran impacto. Esa es la diferencia de “hacer las cosas bien”.

Es posible que muchos penséis que una vez más se me ha ido la cabeza (algo que, por otra parte, me la resbala bastante), o que el título del artículo es amarillista o lo que queráis, pero soy viejo, llevo muchos años trabajando por y para la red de redes y las veo venir de lejos. Otros de los pre-2000 también opinan como yo. Internet está en su plena adolescencia como red mundial, estamos en un punto de efervescencia en cuanto a proyectos, desarrollo y estándares. Hacía 10 años que no teníamos una nueva versión de HTML, que viene con muchísimos añadidos alrededor como los microdatos, los canvas, navegadores que intentan ir por delante del ritmo oficial…

Al final, como ya decía en la Guía SEO y como debería poner en la Guía WPO todo es Sentido Común, es adaptarse a las necesidades de cada proyecto, de cada cliente, tener una base bien preparada y sobre todo hacer las cosas con dos dedos de frente. La “crisis” ha hecho que mucha gente haya venido a Internet y haya entrado como un elefante en una cacharrería, haciendo mucho ruido, pero pocas nueces… Así que simplemente paciencia, todo llegará y volverá a sus cauces. Eso sí, no esperéis que los buscadores vuelvan a la tecnología de hace 10 años, porque eso es agua pasada.

El planteamiento de venir al www2012 fue básicamente por los workshops. Había asistido a otras ediciones de los que he estado (con otros nombres y otras cosas, pero básicamente años atrás) y quería seguir en la línea. Además, los que he estado (que consideraba que serían los que más me iban a aportar de todos los que había, que no eran pocos) los organizaban gente que conozco y en la que confío, así que poco podía fallar. Y así ha sido, me han servido para, una vez más, abrir mi mente “versión SEO” y poder ver ligeramente hacia dónde van los buscadores los próximos años. Sí, cuando la gente me pregunta que qué va a pasar dentro de 2-4 años en el mundillo de los buscadores en general no me equivoco porque, en eventos como estos aprender en lo que se está trabajando y se trabajará los próximos años.

Eso sí, una vez más, en algunas ocasiones me veo como el tonto de la clase. A estas charlas en general asisten los ponentes y otros cuantos “freaks” más de la temática… yo ni soy freak ni soy ponente, sino un simple espectador que no cuadra para nada en ello. Y digo esto porque los ponentes suelen ser estudiantes universitarios que exponen de forma más o menos científica trabajos interesantes. Por poner un ejemplo, en 2008-2009 asistí a un par de eventos en los que se hablaba de los microformatos cuando nadie los usaba ni sabía nada de ellos… ahora a todo el mundo se le hace la boca grande hablando de ello…

Quizá la parte negativa es el precio. No es barato asistir al www2012, aunque quizá eso le de cierto nivel, ya que la organización es simplemente gigantesca. Hay gente de todos los países, colores y gustos. A la hora de la comida debíamos de estar más de 2.000 personas tranquilamente. Simplemente espectacular. Eso sí, españoles no he visto ninguno.

Para acabar con respecto al evento propiamente dicho, me voy con una decena de ideas que no sé si podré aplicar por falta de tiempo. Esta es quizá la peor parte ya que si uno viene aquí y aprende cosas es para aplicarlas. Supongo que lo podré hacer en el momento en el que me encuentre frente a la situación, pero no podré probarlo con tiempo antes. También me voy con algunas conversaciones y ojeadas a los asistentes… hoy he podido mantener una conversación con una persona que trabaja en uno de los grandes buscadores que me ha confirmado (con silencios) mis teorías SEO. Sé que mi forma de trabajar el SEO es la correcta desde hace años, trabajando a medio-largo plazo, eso sí, y cada vez se confirma más y más. Por otro lado los gigantes de las búsquedas me dan cada vez más miedo: Microsoft Research, Google Research, Baidu y Yandex estaban por todos lados… y eso dice mucho. Sobre todo he tenido la oportunidad de darme cuenta hacia dónde va Yandex, porque han asistido la mayoría del grupo a las mismas charlas que yo, así que creo que no voy por mal camino…

Fuera del evento, me he dado cuenta de que mi inglés sigue flojo en algunos casos… para empezar hablándolo… aunque creo que casi ya hablo mejor inglés que catalán, lo que no sé si dice mucho o poco de mi (más bien lo segundo). Por otro lado he aprendido que el inglés-francés y el inglés-japonés son mucho más difícil que el inglés-afroamericano. Lo siento, pero soy incapaz de entender el francés, no consigo pillar ni una (y que nadie me diga que se parece al catalán, porque no es un tema de escritura, sino de pronunciación así con boquita de piñón que no se les entiende nada (si hay algún francés en la sala que no se lo tome a mal, es que simplemente no me empano de nada).

Y para acabar Lyon… aysh, Lyon… si no fuera por el francés (es coña…). Es un sitio que está bien… pero que en días grises no mola nada… hay mucho verde, pero las nubes lo ponen todo muy feo, y lo del viendo cerca del río es que no tiene nombre… ayer paseaba al lado de la Interpol (¡sí, señores, existe!). Hoy por suerte está haciendo un muy decente, con solecito y un poco de fresco y la verdad es que esto luce mucho mejor, y muy distinto. Además, estar cerca del Parc de la Tête d’Or, el mayor parque (dentro de una ciudad de Francia), es algo que también se agradece.

En fin, como resumen, me vuelvo con un buen sabor de boca, con la experiencia de uno de los eventos de Internet más importantes del mundo y con otro punto en el mapa en el que ya puedo situar una marca de visitado.

Para comenzar tenemos PodCastle and Songle: Crowdsourcing-Based Web Services for Retrieval and Browsing of Speech and Music Content de Masataka Goto, Jun Ogata, Kazuyoshi Yoshii, Hiromasa Fujihara, Matthias Mauch y Tomoyasu Nakano).

Existen los sitios PodCastle (para voz hablada) y Songle (para música) que se usan para el reconocimiento multimedia. El primero, por ejemplo, permite la lectura de un contenido e interpretar sus textos. Los usuarios pueden ayudar y colaborar corrigiendo las palabras que sean erróneas, eligiendo, por ejemplo, entre distintas palabras o simplemente corrigiéndolas. Entre las cosas interesantes son las interfaces que este sistema ofrece con formas alternativas. Además, tras corregir, el sistema aprende por lo que se mejora el performance del sistema.

Una de las razones por las que los usuarios entran en este sitio es por la interfaz que se propone y por el altruismo de los usuarios. Otra razón es que en algunos casos aparecen personajes famosos y los usuarios no pueden tolerar que haya errores en sus traslaciones a texto.

A diferencia de los cambios en la Wikipedia, un cambio es sólo para un contenido; en este caso un cambio implica una mejora en toda el sistema que mejora los trabajos futuros.

La otra herramienta, Songle, permite el análisis musical con un sistema visual de pistas, tempos, etc… Con este sistema se pueden detectar coros, melodía, tempos… gracias a esto es fácil encontrar partes de una canción por similitud.

La siguiente presentación es A Framework for Crowdsourced Multimedia Processing and Querying (de Alessandro Bozzon, Ilio Catallo, Eleonora Ciceri, Piero Fraternali, Davide Martinenghi y Marco Tagliasacchi)

En general las máquinas no tienen la capacidad para entender el material multimedia, lo que provocan baja fiabilidad, principalmente en vídeo. Un sistema que se ha probado es por ejemplo el de la detección de logos (marcas registradas) dentro de un vídeo, por ejemplo para detectar problemas de patentes o de usos indebidos.

Una de las cosas que se ha trabajado a nivel de inteligencia colectiva es la selección de logos dentro de una imagen, y por otra parte la separación de posibles versiones de logos.

Continuamos con An Evaluation of Search Strategies for User-Generated Video Content (de Christopher G. Harris)

Hacer búsquedas en vídeos generados y subidos por los usuarios es complejo. Por ejemplo, los tags no están penadas para la búsqueda, sólo hay 13 categorías, los comentarios son encontrables pero tienen pocas visualizaciones (0,16%, 1 de cada 600 deja un comentario) y en general no son útiles… en resumen: hay mucho ruido.

Una de las cosas que se estudian es la posibilidad de realizar una consulta y que estudiantes, usuarios en general o los resultados directos de Youtube ofrecen. Una vez esto, hay que plantearse si analizar o no los resultados también mediante inteligencia colectiva para corregir los vídeos propuestos.

Para acabar tenemos Discovering User Perceptions of Semantic Similarity in Near-duplicate Multimedia Files (de Raynor Vliegendhart, Martha Larson y Johan Pouwelse)

¿Son estas dos canciones la misma? ¿O estos dos vídeos? Dos vídeos son similares si generan el mismo propósito para un usuario. Una forma de analizarlo pdoría se poniendo a prueba a los usuarios haciendo que elijan, o si creen que varios vídeos de capítulos de series descargables por Torrent son los mismos o no en base a sus nombres.

Retomamos las charlas con Crowd Sourcing Literature Review in SUNFLOWER (de Sihem Amer-Yahia). La idea es generar contenidos de forma automática en base a resumir otros contenidos junto a la inteligencia colectiva.

La primera parte lo que intenta es encontrar contenidos y buscar contenidos relacionados, generando distintos grupos y palabras clave. La segunda parte es la de generar un resumen de los contenidos (procesar, clasificar, reescribir…). La última parte es la que afecta a las personas. La idea es que en esta parte los usuarios acaben verificando y reescribiendo la documentación.

Para sacar los documentos se buscan contenidos similares y se basa también en los autores. Gracias a distintas herramientas ya existentes (como MEAD) se pueden extraer los principales conceptos y generar un resumen. La parte más relacionada con los usuarios tiene mucho trabajo por delante, ya que se pueden ajustar mucho los puntos para conseguir mejores contenidos finales. Como ejemplo de este sistema podríamos poner una base de la Wikipedia (podemos ver datos analíticos).

Para sacar los datos primero hay que encontrar documentos bien tratados, con temas y sub-temas. Además, han de estar bien relacionados, ya sea mediante palabras clave, información de autoría, sistemas de citas u otra metainformación.

Seguimos con la siguiente charla Human Computation Must Be Reproducible (de Praveen Paritosh).

La idea de lo que se ha comentado hasta ahora es sacar si los datos que se extraen de forma colaborativa son fiables. Freebase es una especie de Wikipedia pero pensada para máquinas con 23 millones de entidades y 500 millones de relaciones. En general el mayor problema de detección es el de las entidades. Por ejemplo, hay 8 ciudades llamadas San Francisco y hay que discernir de cuál de ellas se trata.

Hoy en día ¿para qué se usan las “computadores humanas”? Para etiquetar imágenes, para determinar relevancia en buscadores, moderar contenidos ofensivos… Estas personas pueden ser gente pagada (por ejemplo Mechanical Turks) o voluntarios, gente a través de oDesk o incluso empleados de la propia compañía (lo ideal es que sea una mezcla de todos ellos).

Los problemas del Crowd son, por definición, los spammers.

Además encontramos problemas en cuanto a las especificaciones de las tareas, a las guías de estilo de cómo han de responder. Aunque el problema mayor es la fiabilidad de la inteligencia colectiva, que requiere respuestas fiables y una serie de bases representativa.

A continuación tenemos Mechanical Cheat: Spamming Schemes and Adversarial Techniques on Crowdsourcing Platforms (de Djellel Eddine Difallah, Gianluca Demartini y Philippe Cudré-Mauroux).

¿Cómo se puede saber si una respuesta generada por los usuarios es spam? Por ejemplo que se haya contestado de forma aleatoria, que se haya generado de forma artificial o que sea duplicada de otra fuente. Para verificar esto es necesario el uso de algoritmos de selección y filtrado. En general las herramientas colaborativas tienen un bajo sistema de control del spam.

Para acabar, A Model-Driven Approach for Crowdsourcing Search (de Alessandro Bozzon, Marco Brambilla y Andrea Mauri).

La idea es cómo sacar información de la gente cuando se realizan búsquedas. En general se hace una búsqueda y se va refinando hasta conseguir la respuesta. pero en algunos casos puede que la respuesta nos e ala óptima. Para esto se puede usar un sistema añadido que se basa en datos anónimos de otros usuarios.

La idea es que, tras extraer datos de distintas API, se permita enviar la consulta a tus amigos de diferentes plataformas sociales (tipo facebook) y demás que, en un tiempo limitado, decidan las respuestas para mejorar la consulta.

En los últimos años las redes sociales se han disparado, y tenemos una serie de relaciones como los intereses similares que podemos conseguir gracias a nuestros amigos o a grupos. Todo esto básicamente conseguido gracias a la llamada Web 2.0.

Una pregunta importante a hacernos es “qué es la relevancia social”. Cómo podemos relacionarla con la relevancia textual (la que usan los buscadores). Esto también va unido a la relación entre pares de documentos.

Para todo esto debemos presentar el concepto “Social-textual Query”, o sea una consulta textual que implícitamente lleve una parte social. Esta lleva una parte de relevancia textual y una parte de relevancia social (además de las acciones sociales que se pueden realizar).

Hay 3 grandes factores:

1. La relevancia de cada usuario según la búsqueda, es decir, si la temática que tiene este usuario sobre unos temas particulares son relevantes o no lo son.
2. La relevancia del usuario en el grupo, en la propia red social, que se podría medir por los seguidores, los que sigues, su importancia…
3. Por último tenemos las acciones del usuario; por ejemplo tener un vídeo en Youtube es más relevante que comentar un vídeo.

El cálculo de los valores y pesos es dinámico, es decir, variará según vaya pasando el tiempo con bastante frecuencia ya que las redes sociales evolucionan.

Los análisis “en laboratorio” dicen que si combinamos los resultados textuales con los sociales los primeros resultados de búsqueda mejorarían ligeramente pero que el resto de resultados mejoraría bastante más, lo que en general daría una calidad mayor a los resultados de búsqueda, eso sí, en determinados tipos de búsqueda y dependiendo de tu red social.

La siguiente charla es A semantically enabled architecture for crowdsourced Linked Data management (de Elena Simperl, Maribel Acosta y Barry Norton).

El Linked Data básicamente son nodos relacionados la mayoría por RDFa y su sistema de consulta es SPARQL. En general los usuarios no saben buscar de forma concreta, por lo que las consultas de búsqueda, aunque se quieran interpretar son difíciles de calcular. Para ello primero hay que corregir internamente las consultas.

La idea es la de crear un escenario híbrido en el que se tenga en cuenta las consultas y datos establecidos (con SPARQL) junto a elementos de inteligencia colectiva.

Otro de los objetivos es el análisis de la relación entre DataSets, de forma que se podría mejorar la cantidad y calidad de los contenidos de forma automática.

La última presentación es Exploiting Twitter as a Social Channel for Human Computation (de Ernesto Diaz-Aviles y Ricardo Kawase).

En general se pueden usar herramientas como Mechanical Turk para encontrar computación humana, pero ¿por qué no utilizar algo del estilo Twitter? Twitter tiene más de 300 millones de usuarios y 200 millones de tweets diarios.

Para ello lo primero que habría que crear es una especie de framework para poder trabajar con los usuarios de la plataforma.

El sistema de preguntas y respuesta se haría mediante tweets, enviando la pregunta, un identificador y las respuestas, teniendo el usuario que contestar con el identificador y la respuesta seleccionada.

Para comenzar Loretta Anania, la que era responsable de buscadores de la Unión Europea comienza explicando la importancia sobre los buscadores y sobre la innovación que han llevado a cabo. También presenta un evento llamado Search Computing: The Search Computing Project que se llevará a cabo a finales de septiembre. Es un momento de grandes cambios, venimos aquí a tomar ideas.

La primera de las charlas (en este caso como invitado) será Using the Crowd to Solve Database Problems (por Donald Kossman). Va a hablar de un concepto como CrowdDB, que básicamente es la colaboración entre máquinas y humanos en relación a las bases de datos. Podéis decargar el paper CrowdDB: Answering Queries with Crowdsourcing.

El sistema de Google es el de tener más datos y para ello añadir más sistemas de proceso. Con esto tenemos búsquedas, traducción… En cambio, el sistema del resto del mundo es el de usar la inteligencia colectiva. El objetivo es conseguir lo mejor de ambos sistemas. Con esto conseguiremos un sistema más inteligente.

Comenta la idea de J. C. R. Licklider, que básicamente hablaba de lo que ha conseguido Google pero hace muchísimos años atrás.

¿Por qué ahora?, porque se puede usar de forma sistemática y porque existen herramientas que lo permiten, como por ejemplo Mechanical Turk u oDesk. Pero debemos tener en cuenta que no podemos usar a la gente como máquinas.

Pero hay ciertas cosas buenas y cosas malas… en general las cosas en las que las máquinas son buenas, la gente es mala, y en lo que las máquinas son malas la gente es buena. Por ejemplo a la gente hay que entrenarla, hay temas legales, la posibilidad de uso depende de horarios y otros factores…

Las dudas que se generan son cómo se desarrolla un sistema para lo colectivo y, sobre todo, cómo puede ayudar esto a resolver problemas de IT. El objetivo sería hablar SQL con las personas… las aplicaciones hace consultas SQL hacia unos sistemas… pero, ¿y si en vez de haber datos almacenados por debajo hay personas que responden? Los problemas para ello son que hoy en día queremos resolver problemas que antes no se querían resolver, y el SQL se queda “corto” para ello. Hoy en día hay un problema de resolución de entidades. Por mucho que le hagamos una petición por SQL con el nombre de “IBM”, si en la base de datos tenemos “International Business Machines”, la respuesta va a ser cero. Otro problema es que no haya datos en la base de datos para responder.

El primer paso para conseguir este tipo de cosas es el de cambiar ligeramente el SQL para hacerlo más comprensible, pero no mucho. Además, hay que decidir qué parte responderá el sistema y qué parte responderá la inteligencia colectiva. La gente puede encontrar datos de una forma rápida y correcta, incluyendo comparaciones sencillas (por ejemplo encontrar un perro en una serie de fotos). En cambio ordenar contenidos, relacionar contenidos de distintas tablas… en general, todo lo que las máquinas saben hacer bien.

El CrowdSQL podría ser algo parecido a esto:

Un elemento básico es el almacenamiento de la información resultante de la inteligencia colectiva, algo básico en Google, ya que no hacerlo tiene un coste excesivamente elevado. Al fin y al cabo, si los usuarios te dan la respuesta, cuando otro usuario la consulte, ya la tienes. Pero para esto hay que añadir pesos, ya que la cantidad de veces que la inteligencia colectiva da la misma respuesta a una misma pregunta esa respuesta tiene más peso que cualquier otra respuesta.

La primera charla es Detecting Collective Attention Spam (de Kyumin Lee, James Caverlee, Krishna Kamath y Zhiyuan Cheng).

Aparecer en la página principal de Youtube, eventos como el Año Nuevo generan marketing viral y atención colectiva, consiguiendo ser “trend” (Google Trends o Twitter Trending Topic). En general los spammers van a por momentos de atención que se convierten en fenómenos.

Primero se consigue información de los temas con tendencia y se generan contenidos para twitter, afcebook, youtube, foursquare… eso genera atención por parte de los usuarios.

En general los spammers en Twitter, a diferencia de lo que se podría suponer en Social media, suelen tener 0 seguidores y siguen a 0 personas, con una media de 9 mensajes. En general, las cuentas de spam suelen tener un pico de mensajes, otro pico al cabo de un mes, y otro pico dos meses después (a los 3 meses). Es interesante un 75% de las cuentas spam son suspendidas por parte de twitter en menos de 24 horas (principalmente en las 6 primeras horas).

Los scammers suelen usar nombres de famosos para generar spam. Además, se suelen usar redirectores tipo BitLy, a los que añaden parámetros y que son utilizados a lo largo del tiempo cada vez más.

Un 75% de los mensajes de spam pueden detectarse en las primeras 2 horas según se lanzan los primeros ataques. Los falsos positivos rondan el 2 por mil.

Lo que se analiza es todos los conceptos que entran como Trending Topic como sistema de muestreo. En resumen se puede detectar los mensajes de spam al poco tiempo con una alta detección (cerca del 99% en 3 horas).

Las siguientes charla es Identifying Spam in the iOS App Store (de Rishi Chandy y Haijie Gu) en la que se analiza cómo detectar spam en las aplicaciones de la Apple Store.

Entre 2008 y 2012 se han añadido más de medio millón de aplicaciones a la App Store. Las grandes aplicaciones tienen un problema, ye s que no se sabe bien cómo gestionan los datos privados. Por ejemplo el caso Path.

Algunos spammers (desarrollaodres) pagan a usuarios para que hagan reseñas positivas en la App Store.

Por ahora lo que se analiza es el valor de las reseñas, la cantidad de las reseñas, cuántas reseñas tienen cada usuario y sus valores y cuántas reseñas tiene el desarrollador y sus valores.

La última presentación es kaPoW Plugins: Protecting Web Applications Using Reputation-based Proof-of-Work (de Akshay Dua, Wu-Chang Feng y Tien Le).

El spam funciona. En twitter, por ejemplo, funciona el doble mejor que en el caso del correo, si los comparamos. Uno de los sistemas que se usan para parar el spam son los captchas, pero cada vez tienen más problemas ya que son más sencillos de hackear. También existen los filtros antispam, pero tienen falsos positivos. Otro elemento es la opción de reporting del usuario (como por ejemplo hace Twitter) aunque puede llegar tarde.

Una opción para mejorar este sistema podría ser el imponer un coste por cada mensaje. Una opción podría ser la de jugar con puzzles. Esto reduciría la velocidad del spam. Por ejemplo a los usuarios nuevos se les pueden poner puzzles más complejos y a los que llevan tiempo cada vez más sencillos para mejorar la velocidad.

Esto se podría organizar con un sistema de plugins, por ejemplo para WordPress o phpBB. Los usuarios tendrían una puntuación que permite que la dificultad del puzzle sea mayor o menos.

En el correo sería algo más complejo de aplicar. Además, los puzzles tienen una limitación de tiempo. Lo primero que se ha de establecer es la dificultad del puzzle. La dificultad se basa en la reputación. Esto vendría de una mezcla de pesos entre puntuaciones locales y globales, por ejemplo, si la IP está en listas negras, si la cuenta es nueva o no…

Se puede ver más información sobre este sistema en kaPoW: Web-based Client Puzzles.

La primera charla es Game-theoretic Models of Web Credibility (de Thanasis Papaioannou, Katarzyna Abramczuk, Paulina Adamska, Adam Wierzbicki y Karl Aberer).

Uno de los mayores problemas hoy en día es la creciente dificultad de detectar la credibilidad de los contenidos en Internet. Puede haber factores económicos que pueden incluir en la calidad o neutralidad, por ejemplo. Los primeros acercamientos hacen referencia a estudios empíricos, a mecanismos de repitación /pero hay que tener en cuenta la información histórica, que es muy relevante) y, lo que se nos propone, que es un juego entre los contenidos producidos y los consumidos.

A la hora de tener elementos en cuenta debemos distinguir entre el contenido producido por los generadores y por los consumidores. Además hay que distinguir la calidad y presentación del mismo y finalmente la experiencia de los usuarios, además del incentivo económica. En el caso de los lectores de los contenidos hay que tener en cuenta dos opciones, que acepten o que rechacen dicho contenido.

Los generadores de contenidos han de ir a buscar la honestidad hacia los buenos contenidos y decidir entre la inversión o no en la presentación de dichos contenidos.

Hay que tener también en cuenta los usuarios… hay una gran diferencia entre los usuarios ingenuos y los expertos. Los usuarios ingenuos necesitas una gran inversión en diseño y en la presentación de los contenidos, en cambio los usuarios expertos dejan un poco de lado esto, ya que se centran más en el contenido propiamente. Los usuarios ingenuos siempre rechazan una mala apariencia y aceptan una buena apariencia.

La siguiente presentación es An Information Theoretic Approach to Sentimental Polarity Classification (de Yuming Lin, Jingwei Zhang, Wang Xiaoling y Aoying Zhou).

En la red hay muchos temas, que provocan efectos sentimentales que pueden ser positivos o negativos. En base a esto podemos hacer una clasificación. Esta información la podemos extraer de elementos que marquen detalles positivos o negativos (me gusta, no me gusta). Para ello hay que sacar y analizar frases y no palabras sueltas. Una de las formas para establecer la tendencia es la cantidad de veces que aparecen dichos elementos en el documento.

Un ejemplo de DataSet para realizar un experimento lo podemos encontrar en Multi-Domain Sentiment Dataset.

La última charla es Content-Based Trust and Bias Classification via Biclustering (de David Siklosi, Balint Daroczy y Andras A. Benczur).

La idea es la de encontrar a las instituciones a seleccionar los contenidos fiables de la red de redes. Esto también ayuda a detección del spam y a clasificar la escalabilidad según el tamaño de la Web. En este caso se han seleccionado 3 categorías para diferenciar los contenidos: credibilidad, neutralidad y parcialidad.

El biclustering es un sistema de clustering bidireccional, que analiza sitios web y los términos que incluyen los mismos. Gracias a esto se pueden encontrar sitios similares con contenidos similares y analizarlos en la misma situación y calidad. Además, con este sistema también podemos extraer dominios relacionados con temáticas relacionadas, de forma que se puedan categorizar de forma sencilla.

Comenzamos con un cambio en el programa, así que toca A Breakdown of Quality Flaws in Wikipedia (Maik Anderka y Benno Stein). La idea es investigar la calidad de la Wikipedia, ya que es muy grande: tiene cerca de 90 millones de páginas, 22 millones de artículos y es la sexta web más visitada del mundo.

Para la calidad hay algunos elementos como que cualquiera puede editarla, los autores son muy distintos y las ediciones nos e revisan antes de la publicación. Esto implica que las mejoras sean de baja calidad y que sea difícil mantener la alta calidad.

Sólo un 0,1% de los artículos de la Wikipedia en inglés son destacados… ¿qué ocurre con el otro 99,99%? Cualquiera puede marcar artículos como incompletos o completos. La idea es intentar hacer un sistema que revise las diferentes plantillas y genere un sistema de organización automático.

La reorganización se hace en base a dos tipos de limpieza: la primera es la de la reorganización por tipo, de las cuales el sistema principal es la verificabilidad.

La segunda revisión hace referencia al alcance de los contenidos, en concreto, a los defectos que tienen. En general los problemas (la mayoría) se encuentra en los artículos enciclopédicos (vamos, las páginas de consulta) aunque se pueden encontrar también muchos errores en los ficheros o incluso en las propias plantillas que se usan para los artículos.

¿Qué tipo de artículos son los que más defectos tendrían? La mitad de los artículos sobre informática contienen defectos, seguidos de los referentes a las creencias. Una cuarta parte de los que hacen referencia a cronología, matemáticas y un 20% de geografía contienen algún tipo de defecto.

¿Cuáles son los tipos de defectos más habituales? Un 20% hacen referencia a la verifiabilidad.

Si se organiza de forma correcta y nos basamos en artículos ya verificados, se podría llegar a detectar un 40% de artículos que tienen algún tipo de defecto hasta corregirlos. Se está organizando una competición para detectar la previsión de errores en la Wikipedia.

Se ha llevado a cabo un trabajo sobre la corrección. Un 25% de los artículos se han corregido, de los cuales un 70% tienen problemas de verificabilidad.

La siguiente presentación es On Measuring the Lexical Quality of the Web (por Ricardo Baeza-Yates y Luz Rello).

Medir la calidad de una página web es el mayor problema de los motores de búsqueda hoy en día, o sea, cómo rankear las páginas. Todo depende de la calidad semántica intrínseca. Para comenzar se analiza la cantidad de palabras que se usan en “el mundo real” y luego su relación con su uso en la red de redes, aunque después se han propuesto también la integración de errores tipográficos y semánticos.

Para medir la calidad del léxico debe ser independiente del tamaño del texto o de las páginas de un sitio y compararlo con cualquier otro tipo de documento y/o tamaño.

La calidad léxica depende de la relación de las palabras con faltas de ortografía y la palabra escrita correctamente. De esta forma se saca un ratio general de cómo escribe la gente. Hay varias condiciones: frecuencia, el ratio más alto de faltas de ortografía y la desambiguación (nombres, acrónimos, palabras en otros idiomas…)

Algunas de las palabras con más errores de ortografía son las siguientes:

Es curioso porque los ratios no se pueden comparar entre idiomas, ya que las curvas entre cantidades de palabras pueden variar significativamente.

La calidad del idioma inglés según Google en marzo de 2011 es de 0,047, en el caso de Yahoo! es de 0,099. Usando una colección web de 28.000 documentos se puede alcanzar una cifra de 0,037. Además, si comparamos Google y Bing con el paso del tiempo (2011 vs. 2012) podemos comprobar que la calidad léxica va empeorando (en los análisis aparece que Bing tiene el doble de peor calidad léxica que Google). Como detalle, los contenidos de la CNN son bastante malos, principalmente por los comentarios (un 50% de baja calidad léxica). En el caso de dominios .EDU o .AC.UK pasa todo lo contrario. Incluso, la Wikipedia o la ODP tienen un ratio de mejor calidad que los sitios académicos.

En el caso del español la calidad es bastante mejor que la inglesa. Aunque en el caso de las redes sociales la calidad está por debajo de la media. Un sitio que tiene una gran calidad léxica es Flickr, aunque tiene poco contenido textual.

Cuanto más acceso a Internet existe, más posibilidades de baja calidad, ya que el acceso a la red llega a todo tipo de niveles culturales y eso empeora la calidad. España está en una calidad media en estos momentos, al igual que Estados Unidos. Es decir, el nivel cultural y la cantidad de conexiones a Internet influyen en la calidad de los contenidos.

La relación, en general, de la calidad de los contenidos y los contenidos de un mismo sitio web es alta. También es básico analizar la calidad léxica de la red cada poco tiempo ya que es bastante cambiante.

La siguiente charla es Measuring the Quality of Web Content using Factual Information (de Elisabeth Lex, Michael Voelske, Marcelo Errecalde, Edgardo Ferretti, Leticia Cagnina, Christopher Horn, Benno Stein y Michael Granitzerg).

Hay que intentar tener presentes algunos puntos: sacar estadísticas simples de hechos de un texto, sacar información relacional de los hechos y buscar relaciones semánticas. Una primera aproximación es mirar las funcionalidades estadísticas del documento, cuñan informativo y qué cantidad de datos abiertos dispone.

Un detalle es que los documentos largos suelen contener mayor cantidad de hechos, y que hay que comparar documentos de una misma longitud y de distintas longitudes para extraer información, algo que en principio no es muy importante. En el caso de sacar cantidad de hechos en documentos de una misma cantidad de palabras sí que influye, ya que la aproximación es más exacta.

La última presentación es A Deformation Analysis Method for Artificial Maps Based on Geographical Accuracy and Its Applications (de Dasiuke Kitayama y Kazutoshi Sumiya). En este caso se analiza la información y fiabilidad de los mapas.

En general los mapas tienen muchas deformaciones (ejemplo claro es el de los mapas del metro) tanto en distancias como en formas, ya que no cuadran geográficamente casi ningún dato. El objetivo de este trabajo es el de extraer la información de un mapa “falso” (poco preciso) relacionarlo con un mapa real (por ejemplo un Google Maps) e intentar trasladar las coordenadas para sacar una idea correcta y precisa.

Para ello se pueden sacar informaciones por OCR (como nombres de estaciones o lugares), de ahí se sacan los datos geográficos, se busca el lugar más preciso para situarlos y finalmente se buscan lugares situados incorrectamente.

Una vez se han situado los puntos, se saca una triangulación para ver el desvío de los mapas. Para analizar el sistema, se ha hecho un proceso automático y luego uno manual que analiza (por personas) si la información situada en los mapas es correcta. Uno de los problemas mayores es la lectura de los lugares del mapa, del que sólo se pueden sacar un 61% de los datos).

En cuanto a la traslación de los lugares a puntos correctos del mapa, la información tiene una precisión del 62%, eso sí, cuando la traslación de datos es correcta, los mapas quedan con muy buenos resultados.

En un futuro, uno de los trabajos a realizar es interpretar líneas tratadas como carreteras o ríos para aumentar la credibilidad y precisión.

Y aquí estoy ya, en Lyon, sin saber una pizca de francés fuera del “wí”. Y es que, por lo que estoy viendo, a diferencia de París donde estuve hace unas semanas, aquí es mucho más complejo encontrar a alguien que hable inglés. Incluso me ha sorprendido que en los restaurantes que hay en el recinto del Centro de Convenciones los camareros y compañía ni siquiera hagan el esfuerzo de hablarlo… está visto que estos días voy a pasar hambre.

Y por si alguien se pregunta que qué hago aquí más concretamente, vengo a dos workshops que se hacen lunes y martes. En concreto he venido a WebQuality 2012 y al CrowdSearch 2012.

El primero de ellos, el WebQuality 2012 (The Anti-Social Web: Credibility and Quality Issues on the Web and Social Media) lo organiza Carlos Castillo (de Yahoo! Research), al que conozco desde hace tiempo ya que ha colaborado en los Congresos OJObuscador, además de haber asistido yo a algún que otro evento en el que él también participaba hace años. Además, entre los que supervisan este workshop se encuentra Matt Cutts (de Google), al que muchos de los que me seguís también conoceréis y entre los ponentes está Ricardo Baeza (de Yahoo! Research), otro de los grandes que ha participado en los congresos de OJObuscador y al que, personalmente, le tengo un respeto mayúsculo.

Básicamente de lo que se hablará es del análisis de contenidos, de cómo se mide la calidad del mismo, de identificar la reputación de los autores, del rol que juegan las comunidades, de la credibilidad del contenido multimedia, de reducir el web-spam, detectar abusos de publicidad, medidas contra el plagio… en fin, como veis es, en el fondo, la respuesta a “hacia dónde van los buscadores”.

El segundo de los workshops CrowdSearch 2012 (First International Workshop on Crowdsourcing Web Search) me atrajo por eso de la búsqueda “en grupo”. La verdad es que no sé cómo traducir Crowdsourcing Web Search, pero vamos, que la idea es que, como ya he comentado muchas veces, los enlaces hoy en día ya no son lo que eran y hay que darles muchos valores más, entre ellos el factor social. Este workshop lo organizan Ricardo Baeza (de Yahoo! Research) y Stefano Ceri (Politecnico di Milano) entre otros. Entre los avales se encuentra Stefano Mazzocchi, actualmente trabajando en Google pero en la parte de Freebase, de lo que en 2009 ya estaba hablando.

En este caso algunos de los temas que se van a tratar son los de la calidad de los contenidos basados en las comunidades, trabajo de extracción de datos basados en modelos grupales, herramientas para gestionar contenidos basados en redes sociales, técnicas para mitigar el spam de los elementos sociales… en resumen, cómo afectan cosas como Twitter, Facebook y similares (donde se concentra un gran número de “seres humanos”) a los contenidos.

En general me gustan este tipo de charlas porque los que las dan son profesores o estudiantes avanzados de universidades de todo el mundo, aquellos que al final son los que proponen los sistemas para que, una vez aprobados y retocados, se implanten en los buscadores poco tiempo después. Hace unos años (en 2008, 2009 y 2010) pude asistir a los FOWS que organizaba Yahoo! Research en donde entre otras cosas conocí todo el tema de los “microformatos”, o “microdatos”, cosas como Freebase y “cacharros” como Síndice.

Así que nada… mañana, si el tiempo acompaña y hay buena cobertura wifi (y un enchufe cerca) intentaré ir publicando y haciendo seguimiento del workshop.

Tal y como he prometido a los asistentes a la charla, os dejo la presentación que he hecho para descargar.

Agradecer a la organización y a los asistentes sus caras de no entender nada (cosas que pasan), las preguntas (muy interesantes), la conversación a la hora de comer y las discusiones tan interesantes que se han generado.

Por cierto, brutal la estrategia de Internet de MUNICH, tanto en la tienda como en el club y el Facebook.

El sistema es sencillo… sólo hay que subir 2 plugins: uno de ellos es para purgar (limpiar) la caché de Varnish cuando alguien publica algo, comenta, edita… así, cuando el blog cambie, se regenera la caché y los usuarios ven las cosas nuevas y actualizadas; el otro plugin es algo más genérico y hace referencia a la gestión de la IP, ya que al ser un web-proxy siempre devuelve la misma IP y eso genera problemas con el spam y similares.

Una vez configurado esto, lo bueno es que se puede probar antes de ponerlo en producción. Simplemente te cambias la IP de tu fichero de host y compruebas si todo funciona correctamente. Una vez probado, se cambian las DNS del dominio y ya está, todo listo.

Una cosa buena también que tiene este sistema es que, si por lo que sea, el Varnish empezase a hacer e tonto o quieres dejar de usar el servicio, vuelves a poner tus DNS como antes, quitas los plugins y ya está, todo vuelve a la normalidad.

¿Te gustaría probarlo? Pues si te interesa puedes escribirme (si me adelantas el dominio en que lo quieres probar, mejor que mejor) y te escribo con todos los pasos. Por ahora vamos a dar una semana de pruebas a aquellos que lo quieras testear en su sitio (ya sea por fichero de host o en producción) y a partir de ahí valdrá 120 euros/año u 80 euros/semestre.

¿Qué cosas buenas tiene usar este sistema? Primero que tu sitio estará cacheado y que soportará picos de tráfico sin problema; que cuando un robots de búsqueda te visite verá que la web va rápida y te indexará más rápido; por norma general el tráfico SEO aumenta a las 4 semanas de usar este sistema… además, sigues teniendo el control de todo en todo momento.

Y para muestra, un par de pruebas… Las he realizado desde el sitio Web Page test, primero apuntando a la IP del servidor directamente y luego apuntando a la del servidor con Varnish. El sitio desde el que se han hecho las pruebas es París con conexión de Cable.

Enlaces a los resultados de la Prueba Directa y a la Prueba con Varnish.

Como detalle, que no lo he podido capturar al 100%, el sistema hace 2 peticiones, la primera normal, luego refresca y usa la caché del navegador, y luego vuelve a repetir lo mismo. En el caso del acceso duirecto, WordPress ha de generar completamente la página, que tarda aproximadamente unos 2,5 segundos. Luego, en cualquier caso, el refresco es rápido, y tarda muy poco. Cuando estos e hace con Varnish delante, la primera ocasión tarda lo mismo, pero cuando vaciamos la caché del navegador como ya no se genera la página, tarda tan sólo 1,5 segundos.

En general, como los usuarios navegarán por las versiones de “lectura 2″ (la lectura 1 sólo se ejecutará cuando haya contenido nuevo o se vacíe la caché), los datos muestran que el blog carga entre un 60% y un 75% más rápido. Os dejo con algunos otros gráficos:

En estos datos se ven los tiempos de respuesta que han obtenido mejor valoración en las 2 pruebas realizadas…

Acceso directo:

Acceso por Varnish:

Aquí se muestra en una valoración simple los resultados que dan Google Page Speed y Yahoo! YSlow…

Acceso directo:

Acceso por Varnish:

Y finalmente un checklist de todas las peticiones que se han relalizado…

Acceso directo:

Acceso por Varnish:

En fin, creo que es bastante obvio que usar Varnish es una gran ventaja competitiva con respecto a los sitios que no lo tienen…

Otra prueba interesante es hacer un test de estrés. La idea es hacer crecer las peticiones simultáneas al sitio… el test lleva un 50% de visitas desde Dublín (IE) y un 50% de visitas desde Palo Alto (CA, US), hasta las 100 conexiones simultáneas. Las gráficas son bastante clarificadoras…

Enlaces a los resultados de la Prueba Directa y a la Prueba con Varnish. Creo que las gráficas hablan por sí solas…

Tiempos de carga por página:

Acceso directo:

Acceso por Varnish:

¿Te gustaría probarlo? Pues si te interesa puedes escribirme (si me adelantas el dominio en que lo quieres probar, mejor que mejor) y te escribo con todos los pasos. Por ahora vamos a dar una semana de pruebas a aquellos que lo quieras testear en su sitio (ya sea por fichero de host o en producción) y a partir de ahí valdrá 120 euros/año u 80 euros/semestre.

Para comenzar, Poul-Henning Kamp -@bsdphk- (si no me equivoco es el desarrollador jefe del software) explicó algunas ideas que tienen del roadmap hasta 2020, y lo curioso es que casi no explicó nada del propio sistema, sino de cómo van a ser los protocolos de Internet en los próximos años.

En 2006 Varnish simplemente era un web-caché, que permitía la propia caché, el sistema de configuración por VCL y los “baneos” (limpieza de caché desde el sistema de administración). En 2009 se introdujo el “purgado” (limpieza de caché desde fuera del panel) y la implementación de parte del estándar ESI. En 2012 con la versión 3.0 se ha implementado el sistema de VMODs (módulos, plugins… como queráis), soporte a gZip…

¿Qué cosas podría llevar Varnish en las próximas versiones? Pues parece que Virtualización de VCL (por ejemplo, distintos dominios, distintos VCL), buffering del ESI (ahora hay problemas de cabeceras) y posibilidad de soporte de otros protocolos: UNIX sockets, fastcgi, SCTP, HTTP/2.0, SPDY o SSL.

De todo lo que comentó, quizá lo que más me llamó la atención es el tema del HTTP/2.0 (también conocido como HTTPbis). En la última documentación, la información casi se ha duplicado con respecto al RFC2616, lo que significa que en vez de simplificarse se ha complicado muchísimo. hay 3 objetivos básicos en esta nueva versión: Velocidad (pipeling, multiplexion, header compression…), Confianza (privacy, integrity, identity, auth…) y Servicio (sessions…).

Un planteamiento que se ha hecho es que SPDY sea el próximo HTTP 2, pero lo malo de ello es que es un protocolo proporcionado por Google y que para ello hay que seguir la agenda del gigante de Mountain View. Además, el SSL es mandatario… así que lo que ganas por un lado lo pierdes por otro. El objetivo de SPDY es evitar que los proveedores de telecomunicaciones (o sea, el que te da la conexión) sea capaz de saber qué envías o recibes y con quién te comunicas. Otra opción sería separar el transport del semantics, y que el transporte sea por “plugins”; algo rollo HTTP sobre: TCP, SSL, UDP, SPDY, SCTP, ECMA-10… El problema será, a parte de saber qué protocolo implementar, cómo luego se comunicará Varnish con los distintos backends. En el momento en el que se de soporte a protocolos múltiples, se añadirán algunos como soporte para vídeos, etc… aunque por ahora se sigue centrando en HTTP. Aun así, se plantean que los protocolos de streaming tienden a desaparecer.

Otro tema interesante del que se habló es dónde se almacena la información… se habló del uso de disco normal, de SSD, de memoria.. y salió un tema de conversación muy interesante en torno a el uso de Varnish en modo Cluster. En principio la gente está escalando usando múltiples Varnish. Incluso se habló del uso de discos en modo NFS, para tener alta disponibilidad. A la vuelta de París se me vino a la cabeza el porqué no se usa algún sistema tipo Hadoop como almacenamiento… aunque supongo que para eso habría que acabar de adecuar el software. Como dato interesante: Varnish soporta perfectamente la gestión de 10 millones de elementos sin ninguna caída en cuanto al rendimiento.

Otra de las charlas, en este caso de Richard Zuidhof comentó varios temas aunque hubo uno que sí que me gustaría destacar (y que a mi a veces me ha dado algún que otro dolor de cabeza) y es el de los timeouts. Por ejemplo, pusieron algunos ejemplos y mucha gente dio cifras, pero me quedo con un par de ellas:

backend localhost {
	[...]
	.first_byte_timeout = 1s;
	.between_bytes_timeout = 1s;
	[...]
}

Lógicamente, estos ería para peticiones internas a la propia máquina, pero como valores “normales” se pusieron estos:

backend default {
	[...]
	.first_byte_timeout = 180s;
	.between_bytes_timeout = 120s;
	[...]
}

Personalmente yo reduciría mushísimo estos valores, porque tampoco tiene sentido tener estas cifras tan altas… y las dejaría en:

backend default {
	[...]
	.first_byte_timeout = 10s;
	.between_bytes_timeout = 5s;
	[...]
}

Creo que si una página tarda más de 10 segundos en conectar ya debe dar ese timeout y que si entre petición y petición hay más de 5 segundos de diferencia, también ha de “fallar”.

Lasse Karstensen @lkarsten estuvo comentando bastante un tema muy interesante que afecta a SEO y afecta a cosas que leía hace unos días desde Bing / Microsoft, la detección de dispositivos desde Varnish. El objetivo sería tener algo como una cabecera X-UA-Device que mediante un Vary pueda cachear cada una de las páginas resultantes según el dispositivo. Para ello existen un par de herramientas:

• varnish-devicedetect VCL
• deviceatlas-mobile-detection (dotMobi DeviceAtlas)

Como ejemplos tenemos varios directamente en la documentación sobre detección de dispositivos de Varnish.

Otro que comentó cosas interesantes fue Andreas Plesner, hablando sobre cómo evitar que Varnish pete. No voy a entrar en profundidad, pero se habló del Saint_Mode (y si no recuerdo mal existe el GOD_Mode) además del más conocido Grace_Mode. Otra cosa interesante es comenzar a diferenciar el HIT del PASS del HIT_FOR_PASS. Otro detalle interesante es el de establecer, de forma forzada, un Set-Connection: Close cuando haya conexiones “pipe”.

Uno de los ejemplos prácticos del día lo puso Lionel Touati, responsable de tecnología de Maisons du Monde, un sitio web de comercio electrónico de decoración elementos del hogar. Su sitio web está creado por ellos y cada semana hacen una actualización. Su obsesión por el SEO ahora se enfoca e el Web performance, y para ello han implementado Varnish a un nivel muy profundo. Aún así, tan sólo cachean un 30% de las peticiones. Eso sí, el hecho de reducir el tiempo de carga se ha visto directamente relacionado con el aumento de páginas vistas, como nos enseñó.

Otro que dio una charla muy interesante fue Kacper Wysocki, entusiasmado de la seguridad y que estuvo explicando cómo usar Varnish simplemente como un Web-Firewall, como lo llama él. Seguro que habéis escuchado sobre el mod_security de Apache; pues con el secure.vcl más o menos se trabaja en lo mismo, con la diferencia de que activar y desactivar elementos es muy sencillo. Una herramienta muy interesante para testear el funcionamiento es el OWASP Zed Attack Proxy Project, que incluye ataques prefabricados a distintos software para ver sus vulnerabilidades.

Como comentaba al principio, entre las cosas que lleva Varnish en esta tercera versión ha sido la incorporación de los “Varnish Modules”, los VMODs. Pues Varnish ha lanzado un directorio con algunos módulos que ya se pueden implementar en el sistema. El objetivo es hacer crecer esta lista, sobre todo con la aportación de los códigos de los usuarios.

Y para acabar, un par de sistemas interesantes que vienen de la mano de Opera Software. El primero de ellos es un sistema que estandariza el Accept-Language y otro que trabaja con el GeoIP. Para aquellos proyectos multi idioma y multi país estos ficheros serán básicos a la hora de implementarse en la configuración de la plataforma.

En medio año se llevará a cabo el VUG6, y probablemente sea en Argentina… y si es así, creo que también me acercaré, porque desde Keep It Simple Lab estamos preparando a montar varias ideas trabajando sobre Varnish y que tienen que ver con WordPress, Magento y otros proyectos que harán que, como bien dice el eslogan de Varnish, tu sitio web vuele. dar las gracias a Rubén Romero @ruben_varnish por la organización y a la espera de que en un futuro (espero que no muy lejano) participen en los eventos WebPerf de España.

Y hasta aquí la visita a París, ciudad que no pisaba desde hacía unos 18 años… cuando un chaval de 8º de EGB hacía el viaje de fin de curso a la ciudad.

La respuesta a esta pregunta siempre la hemos de buscar en la información que el organismo de crear los estándares de desarrollo web nos ofrece, y para esto existe la HTML data Guide donde nos encontramos con un resumen bastante interesante de su funcionamiento.

Antes de nada, poner los enlaces a las páginas oficiales de cada uno de estos lenguajes de marcas que os he comentado al inicio:

• Microformatos y Microformatos 2
• RDFa (y sintáxis)
• microdatos

Todos estos elementos tienen una cosa en común, y es que permiten extraer información de páginas HTML de forma sencilla, y me atrevería a decir que información inteligente y semántica.

En la actualidad, como vengo comentando, existen tres sintaxis principales:

Microformatos

Los microformatos usan @class, @rel y otros atributos para codificar datos en HTML. Además pueden usarse con cualquier lenguaje de marcas que use atributos @class. Hsta el momento los microformatos tenían varios vocabularios para hacer diferentes cosas, pero con los Microformatos 2 esto se ha estandarizado a un sistema único de proceso.

RDFa

El RDFa reutiliza código HTML existente como @href y @rel añadiéndole pequeñas partes más que permiten extraer información (como ya ocurre con el RDF). Estaba pensado originalmente para el XHTML 1.1 y es compatible con HTML 5 y SVG.

microdatos

Los microdatos añaden atributos al HTML 5, de forma que cualquier elemento pueda tener una serie de propiedades y valores. Estos están diseñados para añadir información detallada que pueda ser procesada por los usuarios.

NOTA 1: Los microdatos SÓLO funcionan con HTML 5, por lo que aunque pongas cosas como Schema, si tu web no es HTML 5 buscadores como Bing o Google no “interpretarán” la información que les has dado porque no cumplen con el estándar.

NOTA 2: Bing tiene la herramienta Markup Validator, Google el Rich Snippets Testing Tool y Yandex el Microformat validator para verificar la mayoría de estas sistaxis. Además existen herramientas como el RDFa Validator o el Living Validator, este último aceptando en principio todos los formatos y sistemas.

La forma de aplicar estos sistemas es triple también. Se puede hacer mediante la inclusión en la cabecera de la página de metadatos, como por ejemplo en elemento link con un rel=”alternate”:

<link rel="alternate" type="text/calendar" value="calendar.ics">

La otra opción es la de incrustar código dentro del propio código HTML, aún en la cabecera. Para ello se podrían usar elementos como JSON o Turtle, algo similar a esto:

<script type="text/turtle">
  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix gr: <http://purl.org/goodrelations/v1#> .
  @prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
  @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
  <#company> gr:hasPOS <#store> .
  <#store> a gr:Location ;
    gr:name "Hair Masters" ;
    vcard:adr [
      a vcard:Address ;
      vcard:country-name "USA" ;
      vcard:locality "Sebastpol" ;
      vcard:postal-code "95472" ;
      vcard:street-address "6980 Mckinley Ave" ;
    ] ;
    foaf:page <> ;
    .
</script>

Para acabar, quizá la actualmente más conocida, es la de incrustar meta información en el cuerpo de la página, a través de los atributos custom data válidos sólo en HTML 5.

<div class="spaceship" data-ship-id="92432"
     data-weapons="laser 2" data-shields="50%"
     data-x="30" data-y="10" data-z="90">
 <button class="fire"
      onclick="spaceships[this.parentNode.dataset.shipId].fire()"> Fire
 </button>
</div>

Para acabar, un poco de terminología, para entender bien las palabras que debemos usar cuando hablemos de esto:

• Formato es la combinación de Sintaxis, Tipos, Propiedades de una o más Vocabularios.
• Sintaxis son las distintas formas de organizar la información. En este caso hemos hablado de microformatos, RDFa y microdatos.
• Vocabulario es cada uno de los conjuntos que permite cada sintaxis formado por entidades. Por ejemplo el microdato “producto” o el microformato “hcard”.
• Entidad es cada uno de los pequeños elementos por las que se forma un Vocabulario. Por ejemplo el nombre de una persona, una dirección… Cada entidad tiene uno o más Tipos de datos, y estos tipos de datos tienen una serie de Propiedades con sus respectivos Valores.

A la hora de publicar información lo más sencillo es publicar y mantener tan sólo un tipo de vocabulario por página. En caso de estar utilizando HTML 5 es más que recomendable usar los microdatos, ya que son los que permiten mayor extensibilidad; en cualquier otro dato los microformatos son la opción más adecuada. El RDFa prácticamente no se utiliza.

NOTA 3: Por ahora mi experiencia personal es que Google sólo lee el primero de los vocabularios que se incluyen en una página. Hay que recordar que muchas entidades se pueden anidar, por lo que es mejor utilizar el vocabulario principal y no usar varios.

Aunque el estándar permite el cruce de distintas sintaxis en una página, hoy en día, teniendo en cuenta que la mayoría de webmasters que publicarán vocabularios en sus páginas lo hacen por un tema puro y duro de SEO, casi es mejor limitarse a uno de ellos que, como decía antes, si se dispone de HTML 5 en el sitio, es el óptimo.

Una gran diferencia entre microformatos + RDFa y los microdatos es que las propiedades de cada entidad están bastante establecidas; esto significa que los microformatos no son extensibles y han de adaptarse al 100% a lo que el estándar permite, pero, en contra, los microdatos pueden seguir el estándar y pueden tener valores no estándar, lo que permite su escalabilidad de forma infinita.

En cambio, hay una cosa en contra de los microdatos, y es que es bastante más difícil el uso de los multi idiomas en la información. Los microformatos permiten el uso de @lang como una propiedad, algo que los microdatos no permiten, por lo que se complica el uso.

Otra cosa a tener en cuenta es el diseño, el visual. Para una ficha de persona, por ejemplo, poner el nombre de la persona en negrita, en las tres sintaxis tendríamos un código tal que este:

microformatos:

.hcard .n { font-weight: bold; }

RDFa:

[typeof~="foaf:Person"] [property~="foaf:name"]

microdata:

[itemtype~="http://microformats.org/profile/hcard"] [itemprop~="n"]

Esto hace que, a nivel de uso de los CSS los microformatos sean una herramienta mucho más sencilla que el resto. Claro está, se pueden incluir clases y similares, pero sería información añadida que sólo sería útil en diseño y no en código fuente.

A la hora de gestionar fechas y horas, si queremos mezclar información y hacerla 100% compatible entre distintos formatos podríamos usar algo parecido a esto (que mezcla HTML 5 con otros elementos, haciéndolo completamente compatible; hay que tener en cuenta que el elemento abbr puede usarse para patrones de fechas).

<time itemprop="dtstart" property="startDate" content="2016-04-21T20:00:00">
  <abbr class="dtstart" title="2016-04-21T20:00:00">
    Thu, 04/21/16 8:00 p.m.
  </abbr>
</time>

En lo que respecta a relaciones de enlaces, HTML 5 incluye bastantes elementos @rel que son comprensibles, pero que no son compatibles con otros sistemas como RDFa. Lo que sí es compatible es el uso del @vocab, donde se informa del tipo de contenido que llevaría el enlace. Con esto podríamos conseguir algo similar a:

<a vocab="http://purl.org/dc/terms/"
   rel="date" href="http://reference.data.gov.uk/id/day/2011-11-15">
15th November 2011</a>

Con esto conseguiríamos que la relación del enlace fuera de tipo dc:date, es decir, que es una fecha, (basándonos en la información Dublin Core).

A la hora de publicar contenido (o información) incrustado en el HTML debemos tener muy presente que las buenas prácticas imperan sobre cualquier cosa, ya que si el lenguaje de marcas es incorrecto la extracción de información se vuelve muy compleja. Por eso hay que tener muy presente el uso de un HTML válido. Todas las sintáxis necesitan de una estructura, ya que esto se basa en los datos estructurados, así que es básico cumplir con los estándares de HTML.

Como primera recomendación, es casi básico utilizar sistemas de lectura que permitan HTML 5, es decir, navegadores de última generación. Varios ejemplos son que, Firefox (y otros) no es capaz de procesar los elementos que no se pueden dejar dentro de una tabla y los sacan fuera de ella. Incluso, hay navegadores antiguos que los elementos meta o rel no pueden ser procesados en el body y son “movidos” al head, con las consecuencias de errores de proceso que ello genera.

Otra buena práctica es la de definir la licencia de uso de dicha información. Al fin y al cabo la información que se introduce es pública pero no por ello tiene porqué permitirse la reutilización de la misma. Así que, ya que todas las sintaxis lo permiten, es más que recomendable informar de la licencia de uso.

A la hora de procesar la información que nos ofrece el HTML mediante cualquiera de la sintaxis debemos tener en cuenta que hay dos formas principales de procesarse. La primera de ellas hace referencia a los microformatos 2 y a los microdatos. En ambos casos la información puede procesarse como JSON lo que permite un manejo muy sencillo de la información estructurada. En cambio, el RDFa puede expandise en múltiples opciones. Entre ellas la más habitual es la de convertirlo a RDF/XML o a Turtle, aunque también se podría llegar a extraer vía SPARQL o RDFa API.

Y si no encuentras tu vocabulario… ¿se pueden crear o proponer? Pues la respuesta es simple: sí. Aunque hay varias formas de llegar a hacer propuestas y a distintos niveles. Por ejemplo, existe una página en la que se detalla cómo proponer un microformato, el W3C tiene su Semantic Web Interest Group para crear elementos ya más oficiales e incluso el grupo de Schema (en el que participan los principales motores de búsqueda) tiene el Extension Mechanism en el que no sólo se puede crear un nuevo schema, sino que se pueden extender los actuales, y si mucha gente lo adopta el propio sistema lo tomaría para crear el estándar. En cualquier caso, y mirando hacia el futuro, si vas a crear algo, mi recomendación es que te bases en el estándar de microdata del W3C, responsable del cuál, además, es Ian Hickson (trabajador de Google).

Y en principio todo esto es lo que hay que saber sobre el tratamiento y la incrustación de datos dentro del HTML. Por supuesto no he tratado en detalle ninguno de los vocabularios, pero eso ya depende de cada proyecto y desarrollador (e incluso usuario). Lo que sí que voy a decirte es que, si tienes información estructurada, exista ya o no un sistema estándar, asímate a utilizar el que hay y sino créatelo tú mismo siguiendo las bases que existen.

Splunk comenzó en 2004 en San Francisco y tiene más de 400 empleados en 8 países. Las principales oficinas están en Hong Kong y Londres. Tienen más de 3500 clientes de 70 países, de los cuales 48 están en el Fortune 100.

Hay muchos casos en los que Splunk está analizando más de 10 TB diarios de información. Algunas empresas como Facebook, eBay, Linkedin, Sony, BBC, Symantec y otros están utilizando esta herramienta. Con sistemas similares a MapReduce no hay limitación en cuanto a la escalabilidad de la plataforma. Cisco además de ser un cliente es un partner en cuanto en algunos casos integran en sus sistemas Splunk. Según Cisco, Splunk es el único software capaz de interpretar cualquiera de los logs que se generan en las máquinas de Cisco, y no como en otros casos que tienen muchos pequeños productos que leen una parte de la información.

Splunk además es una gran herramienta de seguridad, ya que es pro activa en analizar comportamiento extraños en los logs. Por ejemplo, si estás recibiendo un ataque desde una serie de direcciones rusas, sería capaz de detectar qué máquina o qué servicio es el que está enviando o recibiendo esta información. A parte de logs, es capaz de recibir información de bases de datos, GPS, registros de sistema, cualquier elemento que se pueda concebir como “datos IT”. Esta información, además de ser útil para los técnicos, puede ser útil para marketing o seguridad.

Otra de las funcionalidades interesantes de Splunk es la posibilidad de ser utilizado como sistema de Web Analytics, aunque es una pequeña parte del sistema, es capaz de analizar cualquiera de los elementos: páginas, vídeos, imágenes…

Splunk se divide en 3 partes: Collectors, Indexers y Search Heads (que es la web donde se ve la información). Se puede escalar horizontalmente, tienen alta disponibilidad y podría recoger unos 25 GB diarios. Cada máquina podría ser un quad-core con 8GB de RAM. El despliegue es bastante rápido y es capaz de usarse independientemente de cada lugar. Los Indexer pueden estar geolocalizados y el Search Head cercano a donde los usuarios lo van a utilizar.

El sistema es capaz de interpretar expresiones regulares para los distintos elementos que pueden encontrarse en los logs, de forma que es capaz de interpretar cualquier tipo de fichero. Es capaz de monitorizar el sistema de ficheros, registros del sistema operativo, control de hypervisores de máquinas virtuales, aplicaciones web, tablas o esquemas en bases de datos, configuraciones de red…

Splunk aparece como base como un buscador al estilo de Google en el que puedes realizar cualquier tipo de datos (buscar una IP, una dirección URL…) además de permitir generar informes personalizados en base a la información recogida. Además se puede hacer seguimiento de transacciones. Un ejemplo podría ser que un sitio web genere un identificador de una venta, se cruzan datos con que se haya enviado un correo avisando de la venta al usuario, y finalmente que el paquete (logística) se haya enviado.

Splunk tiene un sistema de geolocalización de direcciones IP, de forma que se podría analizar de una forma muy sencilla y mostrar o geolocalizar las visitas con mucho detalle (dependiendo incluso de qué sea, con datos de coordenadas GPS).

Existe un repositorio de paneles ya creados que analizan directamente los logs o datos. Muchas de estas extensiones están realizados directamente por la gente de Splunk aunque hay una gran comunidad detrás generando estos paneles.

Los que me conocéis sabéis que llevo trabajando desde hace bastante en este proyecto, en recuperar mi faceta de “montar eventos”, aunque esta vez no quiero montar un macro congreso como en otras ocasiones, sino que quiero algo más reducido y sobre todo de profesionales a profesionales del sector.

WebPerf está concebido como un evento formativo en el que más o menos en 2 horas podamos tratar algún tema concreto, de bajo o alto nivel, con un ponente que de una charla de 1 hora exponiendo su punto de vista y el resto del tiempo plantear dudas, sugerencias y que cualquiera pueda salir a la palestra a explicar lo que quiera.

Esto significa que el evento está dirigido a aquellos que se dedican, tecnológicamente hablando, en cuerpo y alma a mejorar los sitios web de Internet, ya sea mejorando el código fuente de una página concreta hasta montando la infraestructura de los centros de datos. Repito, para los que habéis preguntado ya: es un evento de tecnología, de esos en los que se dicen palabras raras.

El funcionamiento del evento será mediante una lista de correo a la que se puede apuntar cualquiera desde la que se propondrán temas y se puede hablar con el resto de asistentes o de los apuntados. En esta lista se irán proponiendo temas a modo de Call for Papers para ir sacando ponentes que quieran tratarlos.

El lugar elegido será el de La Salle, que nos ceden amablemente un aula con todo lo necesario para dar esa “clase” en la que podamos aprender. Por ahora comenzaremos en Barcelona, en abril y junio, y a partir de septiembre iremos intercalando Barcelona y Madrid.

¿Temas de los que se hablarán? Pues para comenzar en esta primera ocasión, y como avanzadilla, es probable que hagamos algo bastante accesible a todos, como es el Web Performance para WordPress, intentando ver el asunto desde el punto de vista de los plugins y hacer tunning del propio WordPress, y por otro del de montar una infraestructura como si fuera para una red de blogs, que soporte tranquilamente millones de visitas sin problema, al menos coste.

Pero esto es sólo el principio, más adelante trataremos temas como mejoras de software de comercio electrónico (como Magento o Prestashop), experiencias con Apache 2.4, cómo escalar MySQL, el uso de web-proxy como nginx o Varnish, elementos olvidados como la conectividad y mejoras como SPDY…

Y ahora unos pocos enlaces para poder estar pendiente de todo:

• WebPerf: La web donde habrá información propia del evento. Tiene secciones para Barcelona y Madrid.
• WebPerf feed: Feed de noticias y artículos del sector (las mismas que aparecen en la cuenta de twitter).
• @WebPerfES: Cuenta de twitter con noticias y artículos del sector del Web Performance.
• @WebPerfBCN: Cuenta de twitter con información y seguimiento del evento de Barcelona.
• @WebPerfMAD: Cuenta de twitter con información y seguimiento del evento de Madrid.

Así que si eres del mundillo de Internet, de los que toca la parte más técnica, un ISP, desarrollador, administrador de sistemas o similar, prepárate, que ya tenemos un evento en el que reunirnos y salir de la cueva ;) Apúntate a la lista de correo donde podrás estar informado o hacer consultas técnicas de las que tengas dudas.

Hace ya un par años, en el Search Congress de Bilbao presenté algo que aún no llamaba WPO sino “infraestructura SEO” en el que di los primeros pasos a tratar sobre todo este mundillo. Esta vez no he tenido las 3 horas que tuve la otra vez, sólo 30 minutos, así que como dicen por aquí “us faig cinc cèntims”.

Os dejo la presentación para que la descarguéis si os interesa, muy en la línea de seguir siendo un SEO Open Source.

¿Cómo solventarlo? Pues en Windows (en general funciona en XP, Vista y 7) es bastante sencillo:

1. Acceder a Inicio -> Ejecutar -> cmd (Ejecutar como Administrador)
2. Ejecutar el comando: netsh int ip reset c:\resetlog.log
3. Ejecutar el comando: netsh winsock reset
4. Reiniciar la máquina

Muy recomendable, si se quiere investigar más, una lectura a cómo usar la herramienta Netsh.

En Linux también existe un comando similar que permite hacer un reset a la pila…

1. Acceder a la consola como administrador
2. Ejecutar el comando: ifconfig eth0|grep "inet addr"|cut -d : -f 2 |cut -d " " -f 1
3. Reiniciar la máquina

Espero que con esto consigáis notar cierta mejora en vuestra conectividad. Mano de Santo, ¡oiga!

En 1999 tenía mi primer servidor dedicado, con mi propia IP, y pagando ya cada mes (o creo que cada 3) una pequeña cuota por tener un servicio decente para mis sitios… tras eso muchas idas y venidas probando alojamientos en varios proveedores del mundo hasta que acabé en mi proveedor actual, Kaos, que era el ISP que tenía Grupo ITnet por aquellos 2003 cuando comencé a trabajar en la empresa.

Desde ahí he pasado de tener servidores (sí, en plural) dedicados a tener VPS (Virtual Private Server), varios de ellos, que hoy en día me permiten escalar todas las aplicaciones. Si sumo los que tengo yo y los que tiene Keep It Simple Lab creo que debemos tener ahora mismo unas 11 máquinas, que no son pocas.

En estos últimos meses me he visto envuelto en la implementación de estrategias de infraestructura de varias empresas, empresas muy distintas pero que tienen una cosa en común: todas ganan dinero a través de Internet. Y al fin y al cabo los sitios web hoy en día son bastante similares… una base de datos (que suele necesitar una máquina con algo más de recursos que el resto), una máquina para el frontal web, a veces alguna otra máquina para cosas especiales (sitio SSL, algo que no se puede cachear y siempre ha de estar disponible, etc…) y últimamente una o muchas máquinas de web-proxy ya estén en el propio país o distribuidos por el mundo, según las necesidades del proyecto. Creo que algunos pensarán que “para qué quiero yo tantas máquinas si en una puedo meter el mySQL, el Apache, el correo y las DNS”. Sí, se puede, pero después de 15 años haciendo webs la experiencia me dice que hacer esto suele acabar mal, sobre todo si tienes proyectos “con cara y ojos”. Si tienes un simple WordPress, pues a lo mejor no te es necesario, pero si estás haciendo una tienda por la red, aunque sea pequeña, necesitas disponibilidad, alto rendimiento…

Si vamos a la parte de “hacer números” os puedo decir que aproximadamente invierto un 3% de lo que facturo en sistemas. Esta cifra porcentual es lo que mi socio Jaume dice que viene a ser que “has de invertir en infraestructura lo que ganas en un día, todo el mes, como mínimo”. Es decir, que si facturas 3.000 euros al mes, debes gastarte al menos 100 euros en servidores, que es “el coste de estar un día sin servicio”. Que conste que no es una regla de oro, pero haciendo números es bastante aproximado a lo que un jefe puede despotricar cuando una web no funciona.

Y es que me hace gracia que, gente que se gana la vida con Internet, cuando le dices de gastarse 100 euros al mes en servidores se echa las manos a la cabeza… pues, qué queréis que os diga, con 100 euros mensuales se hacen maravillas en cuanto a servidores, ya que puedes tener 2-3 máquinas más que decentes que pueden servir 1.000 visitas/segundo sin pestañear. Que sí, que poca gente tiene 1.000 visitas/segundo, pero cuando tienes 50 sitios web pequeñas en un sitio, te aseguro que estos datos te pueden parecer bajos.

Otro detalle a tener en cuenta es dónde tienes los servidores, físicamente. Si tu sitio está enfocado a vender en España, has de tener los servidores en España, por la simple razón de la conectividad. Cada país tiene su propia red “gigante” de fibra que interconecta los operadores de telefonía / Internet con los ISP o con las redes más importantes, para ser más concretos, con los Centros de Datos, a menos que tú te hagas tu propio miniISP en tu oficina y directamente uses una de las operadoras. En el momento en el que te vas a otro país, la interconexión es simplemente pésima. Las conexiones internacionales son bastante malas, y no sólo pasa aquí, pasa en general en todo el mundo.

Hoy en día parece que el tema del alojamiento web se haya convertido en un commodity. En parte sí lo es, el tema viene cuando tu sitio web tiene unas necesidades de administración de sistemas que no te va a dar tu proveedor de esos que por 1 euro te hace tu sitio web… porque, ¿sabes qué ocurre? que cuando se te rompa la web se limitarán a reiniciar tu servidor, y si sigue sin ir el problema sigues teniéndolo tú. Lo caro de los servidores web no son las máquinas… eso es más o menos barato, lo importante es tener una buena conectividad (sobre todo si tu negocio se basa en SEO, estaría bien pensar cómo llega Google a tu sitio web) y, sobre todo, tener bien configuradas las máquinas. A veces cambiar un simple número de 8M a 16M en el Apache o mySQL hace que una web funcione de muy mal a muy bien.

¿Qué te pensabas, que montar una web era algo tan sencillo como entrar por FTP y subir el sitio? Pues no, pero claro, a los administradores de sistemas que nos den… total, como ya tengo mi web funcionando ¿para qué voy a pagar a alguien que se preocupe de darme lo mejor?

NOTA: Sí, para los que no lo sepan, yo soy administrador de sistemas, que aunque no ejerzo en el día a día, sí que me preocupa el asunto. Si algún día hay huelga de SysAdmins, preparaos, porque el mundo se acabará.

La solución es bastante sencilla, pero hay que tenerlo presente. Todos estos sitios que he mencionado antes disponen de unos paneles en los que dar o quitar acceso a estas otras herramientas que acceden contra ellas. De tanto en tanto vale la pena darle una ojeada a esas páginas para eliminar accesos “extraños” o simplemente hacer un pocod e limpieza y mantener tu casa un poco ordenada.

Facebook:

Para Facebook hay que acceder a la sección de aplicaciones y una vez allí verás el listado de las mismas, la última fecha que han accedido a tu información y la posibilidad de editar los permisos o eliminar directamente la posibilidad de acceso.

Twitter:

Para twitter es quizá el sistema más sencillo, simplemente entras en la gestión de Apps y allí puedes revocar el acceso a las aplicaciones que no te interesen.

Google:

Siempre Google es de los que lo tienen más escondido para llegar, pero se puede acceder de forma directa en Acceso autorizado a tu Cuenta de Google. Aquí te aparece una lista de las aplicaciones que tienen acceso, qué tipo de acceso y la opción de revocarlo.

Linkedin:

Tienes en las opciones de Linkedin la posisibilidad de añadir aplicaciones propias y de gestionar las propias y externas. Aquí simplemente tendrás un listado con el nombre de las aplicaciones y un botón para eliminar el acceso, sin más explicaciones.

Con esto podrás mantener al día tus cuentas y tu información privada, que últimamente estamos dejando repartir por el mundo sin ton ni son, y no creo que sea lo mejor que podemos hacer…

Y digo lo de las dos horas porque en teoría es lo que dura el espectáculo… ya que el día que fui yo se puso a improvisar la primera hora y, en vez de 55 minutos hizo hora y cuarto… así que nos llevamos 20 minutos por la face.

Para haceros una idea, como la mayoría de los monólogos, todo son tópicos, y la verdad es que esa es la gracia… que te ves reflejado al 100%. Además, le da por comparar las relaciones y la vida de la pareja y la persona con la informática y, claro, eso a mi me llega al fondo. Que si USB, que si WiFi; además lo deja claro: los hombres somos PC y las mujeres son Mac. Aunque comenzar la actuación preguntando cuánta gente tiene twitter (un 20%) y cuánta gente tiene Facebook (un 90%) y cuánta tiene Tuenti (un 0%, declarado) mola.

El espectáculo se divide en dos partes… la primera está más enfocada a destapar los trapos sucios de los hombres… y cómo la evolución nos ha dejado bajo el manto de las mujeres. La segunda parte es la que desvela cómo son las mujeres, porqué actúan como actúan, una serie de trucos para que aprendamos. Además, seguro que sales con bastantes recomendaciones… una de ellas es la de ver “el Encantador de Perros” con César Millán…

Aunque sin duda, si Goyo está haciendo esta obra de teatro, o monólogo o como queráis llamarlo, es porque está buscando, de nuevo a su nueva media naranja (que sabios son los griegos). Así que, sobre todo si vas con tu pareja, ten cuidado que a lo mejor te la levanta. Más que recomendable.

NOTA: para entender algunas incongruencias de esta entrada, por favor, vé a ver la obra y luego relees que lo verás todo más claro.

No sé si puedo decirlo o no, pero os voy a adelantar algunos de los ponentes y algunos de los temas que se tratarán. Por ejemplo Miguel Pascual explicará las distintas fases de un proyecto, José Moreno hablará, entre otras cosas de reputación digital, Edgar Sánchez nos dará algunas herramientas, Aleyda Solis tratará los entresijos para conseguir enlaces, Fernando Muñoz acabará con auditorías SEO.

Por mi parte trataré temas más técnicos y hablaré un poco de WPO, que como muchos ya sabréis cada vez más está tomando fuerza todo lo que tiene que ver con la infraestructura y velocidad de carga de los sitios. A parte de hablar sobre los elementos básicos, también intentaré entrar en profundidad en cómo montar una infraestructura buena, bonita y barata tan potente como lo que “los grandes” montan, con la diferencia de que lo que yo explicaré ayuda al SEO y lo de los grandes no.

Además, todos los alumnos del master estarán invitados a asistir al III Congreso SEO Profesional que este año se hace en Madrid también a principios de Julio y donde todos los profesores del master estarán también.

Así que ya sabes, si te estás planteando ser SEO y dedicarte de forma profesional a ello apúntate al I Master SEO Profesional.