Vos no te enteraste. Probablemente estás totalmente seguro de no habérselo dicho a nadie. Aún así, si vamos por lo más probable, es tu culpa.

Primero una corta explicación. Prometo que no va a doler.

Cuando vos entrás a tu mail, sea cual sea tu proveedor (aunque, si te ‘hackearon’, todavía estás usando Hotmail¹), les mandás dos datos: tu nombre de usuario, y tu contraseña.

Obviamente, en algún lugar está guardado todo eso; ahí entran las bases de datos. Puede ser algo tan simple como un archivo de texto con un usuario y una contraseña en cada uno, o servidores dedicados para almacenar tus datos protegidos y copiados mil veces, y en varios lugares del mundo, para que si uno se rompa, tus datos sigan ahí.

Pero esos detalles no nos importan.

Lo único que importa es que la máquina sabe si la contraseña que le pasaste es la tuya.

Pero, claro, ahora tenemos que confiar en que nadie va a conseguir una copia de ese archivo, y robar tu preciada contraseña (claro que, si se llevan el archivo, tienen tres millones más, pero por algún motivo, sólo les importa la tuya).

La versión corta, es que aunque tengan el archivo, no les sirve. (Bueno, si entraron en un servidor, probablemente se bajaron todo tu correo, no sólo tu contraseña.)

La versión larga involucra encriptación. Encriptación indescifrable.

En un sentido muy estricto, no existe tal cosa. Todo código se puede romper. Lo importante es que sea muy, muy, muy difícil.

Tu contraseña no está guardada. Tampoco, si vamos al caso, una versión encriptada de tu contraseña. Lo único que Hotmail guarda es un hash. No, no la droga. Un hash es un valor derivado de tu contraseña. Con la característica particular que éste sí es irreversible. Esto tiene una parte buena, y una mala: la buena es que no pueden adivinar tu contraseña. La mala es que, matemáticamente hablando, hay infinitos valores que devuelven el mismo hash.

Por dar un ejemplo trivial, supongamos un hash que consiste en asignar un valor (de 1 a 26 —sin la ñ—) a cada letra del alfabeto, reemplazar cada letra en la palabra por el valor, y sumarlos. Para “Tordek”, sería (20, 15, 18, 4, 5, 11), que da 73.

Entonces, el hash de Tordek es 73, pero a partir de 73 es imposible deducir “Tordek”. La suma es conmutativa, así que el orden de las letras es irrelevante. También puedo cambiar letras en grupos, de manera que el cambio se equilibre (ejemplo: T+1 = U, O – 1 = N, +1 – 1 = 0), que me da “Unrdek”, cuyo hash da igual.

Claro que, un hash de verdad (SHA-1, MD5) es un poco más complicado que eso. Pero el principio es el mismo.

Pero… con infinitas contraseñas para el mismo valor, ¿no se vuelve trivial encontrar una contraseña con el mismo hash?

No.

Incluso MD5, que ya se considera obsoleto, devuelve valores de 128 bits, 3,4 x 10^38 valores diferentes. Infinito dividido por eso, sigue dando infinito—pero no podés crear las infinitas contraseñas posibles. Y aunque pudieras, tarda mucho (si creamos cien millones cada segundo, tardamos 3 x 10^30 segundos, casi 10^23 años, y el universo solo tiene 1.4 x 10^10). La probabilidad de encontrar una contraseña que devuelva el mismo hash que otra que conocemos es 2,9 x 10^-39. Muy, muy, muy difícil.

Si somos paranóicos, podemos guardar tanto el MD5 como el SHA1 de una contraseña, y esperar que ambas coincidan, y ahí tenemos 128 + 160 bits. Eso es mucho. En serio. Si además agregamos una sal —un valor aleatorio, con el proposito de hacer el password todavía más largo (aunque sólo dentro de la base de datos)— bueno, digamos que lo más fácil es creerme que no se puede.

Por eso están desapareciendo los sitios que te mandan tu password al mail. Si pueden hacer eso, es porque se puede desencriptar (o, peor, ni siquiera se encripta). Y en ese caso sí te pueden ‘hackear’. No confíes en esos sitios.

Entonces, si no te pueden hackear, ¿cómo consiguen tu contraseña?

Ya te dije: se la diste. Ingeniería social es el nombre técnico. Mentir es más fácil.

Varios sitios ofrecen “exploits”; uno clásico es el mensaje de «(alguien) te mandó una tarjeta. Ingresá tu contraseña para abrirla.». Es tu culpa si caíste.

La otra es que tenés una “pregunta de seguridad” muy fácil. O que tu contraseña lo sea.

Mi contraseña más común tiene 12 caracteres. Algunos números. La saben, al menos, 3 personas. Nunca me robaron nada.

Y como última opción, sí, te pueden “hackear” (a vos, no a Hotmail). Mediante dos ataques, principalmente: uno es instalarte un keylogger, un programa que guarda cada tecla que apretás; el otro se llama “man in the middle”, que consiste en ocupar alguna máquina ubicada ‘en el medio’, entre vos, y el servidor, como, por ejemplo, el servidor de un cyber.

Hay formas de protegerse de cada uno de estos ataques, y eso queda para la próxima.

Los tres artículos discuten el mismo tema: Hay muchas cosas que ponemos en los diseños, que no tienen una verdadera razón para estar ahí. Y si agregamos que los navegadores modernos pueden ayudar a simplificar, y que esto ayuda con la SEO, no tenemos realmente razones para oponernos.

Citando a Ryan: “‘Mantengo que la simplicidad es el factor más importante del diseño’, es lo que digo. A lo que Tufte respondería, ‘No, no lo hacés.’”.

La simplicidad es el factor más importante del diseño, por eso mi blog tiene esa apariencia, pero el post de Tomayko me hace ver detalles importantes de cosas que son innecesarias en el blog.

Entre ellas:

• Cajas de búsqueda: Google hace un mejor trabajo que cualquier plugin.
• Links a Feeds RSS: Para eso esta el ícono en la barra de navegación.
• Links a posts anteriores y siguientes: Raramente tienen algo que ver, y además existen los tags link, con el atributo rel=prev/next
• Blogrolls, links a archivos: Igual que arriba.

Voy a ir sacando en grupos estas cosas, mientras que voy poniendo más cosas en el dominio base, como ser links a los 10 últimos posts, y algo sobre mis proyectos actuales, supongo.

Ah, eso sí, ningún argumento sobre simplicidad me va a convencer de remover mi header.

Yo adoro el IRC. Tuve muchas incursiones al mundo del Chat desde chico. Algunas malas (#chaco-corrientes), y algunas geniales (#rol, #la_guarida, #umbría, y tantas otras). Combinado con mi relativo desprecio con el MSN hace que esté casi constantemente evangelizando su uso.

El IRC es simplemente un protocolo, pero uno genial en lo que hace: Pasar mensajes de un lado a otro.

El problema principal por el que no logro convencer a demasiada gente de que entre, es que, en esta zona, el uso del chat iniciaba así:

1. Bajarse e instalar mIRC e IRcap;
2. Entrar en chat.clarin.com (ya muerto);
3. Entrar a #chaco-corrientes;
4. Ver dos segundos de líneas constantes, sin sentido, llenas de combinaciones de colores enceguecedoras, recibir mensajes privados de tres hombres (uno de los cuales sigue mandando, a pesar de explicarle que no esta buscando… algo de… ese estilo¹);
5. Odiar el IRC para siempre.

Está claro que tener esa primera impresión no es lo más conductivo a apreciar el IRC y darse cuenta de todo para lo que puede servir.

El momento en que aprendí a dejar de preocuparme y amar al IRC, fue cuando, después de un par de horas de jugar al Baldur’s Gate 2² entré a una página de soluciones, y había un documento con las reglas de AD&D 2da (el sistema en el que el BG2 estaba basado). Ahí conocí el Rol, y eventualmente entré en #rol, en el IRC-Hispano, y conocí a varias personas que lo jugaban. Entre ellas, Aixa, una chica de Corrientes, la primera que conocía de la zona.

De ahí puedo partir a dos historias: la del Rol, y la del IRC. La segunda es la más corta, y la relevante: Empecé a conocer gente en el canal, fundé uno (#rolvampiresco —es lo que nace de conocer como primer juego a Vampiro—), y empecé a entrar en muchos (entre ellos, #edad-media, #rol, #umbría, #la_guarida, #bajomontaña, #dnd-es, #linux, #c… y eso sólo en el Hispano).

Las comunidades son amplias, y con cerca de 100 personas por canal (entre los relativamente interesantes, al menos), no es difícil encontrar respuestas a cualquier pregunta que hagamos.

A cualquiera que tenga un rato para probarlo, le recomiendo encontrarse una red (el IRC-Hispano, EFnet, y Freenode —las dos últimas en inglés— son las mejores, en mi opinión), visitar un canal de un tema que nos interese, lurkear un rato (esperar en silencio, para aprender las costumbres del canal), leerse las reglas —si las hay—, y empezar a conversar. Puedo garantizar a todos los que se animen a entrar, que no se van a arrepentir.

Selectores

Para que el navegador sepa a qué elementos aplicar un estilo, tiene que saber cómo encontrarlo.

Para hacer referencia los elementos mediante sus ids, usamos el prefijo #. Un elemento con id header recibe sus estilos de reglas con el nombre #header.

Si queremos hacer referencia a todos los tags de un cierto tipo (por ejemplo, todos los links), usamos simplemente su nombre (en este caso, a).

Y para hacer referencia a todos los descendientes¹ de un elemento, separamos los selectores correspondientes con un espacio. Para elegir a todos los links del menú, usaríamos #menu a.

Y ahora podemos aplicar…

Tamaños

Un elemento de bloque, como div, por defecto, es tan ancho como pueda para llenar su contenedor (su padre), y tan alto como para que todo su contenido quepa.

Para hacer que el cuerpo de nuestro diseño sea más angosto, aplicamos una regla como

#cuerpo {
    width: 500px;
}

Si quisieramos definir la altura de un elemento, usaríamos la propiedad height.

Ahora, si quisieramos que nuestra cabecera aparezca centrada, primero le definimos un ancho como antes (el alto no es necesario, por ahora), y para centrar usamos márgenes automáticos. Agregamos las reglas margin-left: auto; margin-right: auto; a las anteriores, y, magia —excepto en IE—, ahora tenemos un lindo div centrado.

Pero aunque el div está centrado, el texto en su interior, no. Si quisiéramos eso, bastaría con text-align: center;.

Si usaste un CSS reset, como recomendé, ahora verás que las cosas están muy pegadas. La solución es fácil: márgenes.

La propiedad margin puede tomar entre 1 y 4 argumentos, aunque para hacerlo fácil, vamos con los dos casos extremos: un argumento aplica el mismo margen a los cuatro bordes, y 4 argumentos permiten especificar un valor para cada uno. Igual que antes, simplemente ponemos el selector, seguido por las reglas encerradas entre llaves.

Un par de detalles, antes de dejarlos a la espera del próximo post:

CSS significa “Hojas de Estilo en Cascada”, y lo de Cascada significa que si dos reglas se aplican dos veces a un mismo elemento, la última sobreescribe a las anteriores.

Además, hay otras unidades que podemos usar: el em, que (en teoría) es igual al ancho de una M, y a la altura de la fuente es la más común (por ejemplo, para separar los párrafos, lo normal es agregarle un margin-bottom: 1em;). El problema del em es que este depende del tamaño del texto del elemento (que definimos con font-size). Es decir, si le damos un margen de 1em a un texto de 10px de alto, este medirá el doble que un margen de 1em en un texto de 5px de alto.

Y, finalmente, la separación entre cada línea del texto definimos line-height, que no necesita una unidad (si no la tiene, su valor se multiplica por el tamaño del texto). (Valores que quedan bien son entre 1.2 y 1.5 para fuentes sans-serif —como Verdana—, y entre 1.4 y 1.7 para fuentes serif —como Times New Roman—.)

Para hacer un diseño con CSS, hay que entender la separación de contenido y presentación: HTML es para contenido. CSS es para presentación. Es obvio que es imposible que estén absolutamente separados —para algo están las classes y los ids— pero hay que empezar por separar lo que se puede.

El contenido es Rey

Empezá por imaginarte que no existe el CSS, que no existen los atributos style, y que tenes que pagar $100 cada vez que usas una tabla (no, usar tablas no está mal, pero usarlas para lo que no se debe está mal).

Tus tags: h1-h7, p, strong, em, a, ul, ol, li y opcionalmente hr.¹ Poné tus títulos en h1, subtítulos en h2, etc. Cada parrafo envuelto en <p></p>. Listas con ul/ol y li. Si querés resaltar una palabra, em o strong. Dado que un menú es una “lista de links”, obviamente, usá una lista. Y, obviamente, head y title para el título de la página, body envolviendo todo el contenido, y un html encerrando todo.

Listo. Con eso tendrías que hacer TODA tu página. Hay muy pocas excepciones para esa regla.

Obviamente que no es lo más lindo del mundo. Pero el punto, ahora mismo, no es que sea lindo; es que tenga sentido. Los títulos son títulos porque los envolviste en h1/2/lo que sea, no porque “tienen una fuente más grande”. Las cosas marcadas tienen sentido cuando las marcas así. Eso es el HTML: un lenguaje de MARCAS (Markup).

¿Y ahora? Ahora creas tu CSS.

Estructurando

El primer paso es armar tu estructura. Tu página hasta ahora no se presta demasiado para la estructura, así que te presento un nuevo elemento: div. Este elemento sirve para determinar las áreas de tu página: Envolve en divs (uno por seccion) a lo que sea tu encabezado, tu pie, el contenido principal, menúes, etc., mientras a cada uno le ponés el atributo id correspondiente a su sección.²

Con tus areas definidas, podés empezar a definir la estructura.³ Y eso queda para el próximo artículo.

Mis lectores (los dos) sabrán que hice algunos posts sobre el tema (algunos más relacionados que otros), y que soy más o menos vicioso (tengo 87 suscripciones en Google Reader).

DBT también está preparando un sitio específicamente para el proyecto: RSSDay.org

Aparte de los que me leen obligados desde CodeAr, ¿Cuantos de uds usan RSS, y publican su contenido (puntos extra si no son blogs) con RSS?

En un blog en WordPress default, esto es muy notable, porque el contenido de cada post se encuentra en varias páginas: en la principal, en la página individual de ese post, y en cada página de archivo por fecha, categoría, o tag que corresponda a ese post. Yo pongo muchos tags, y una o dos categorías por post; esos son de 6 a 10 copias del mismo contenido.

Esta repetición causa varias cosas: por un lado, los buscadores no saben cuales son las páginas más correctas, y puede mandar a cualquiera en la que aparece el post. Por el otro, algunos dicen, que el contenido se repita tanto se ve un poco spammer y la posición empeora.

Para los que pueden acceder a su hosting (mediante ftp, ssh, etc.), lo primero es hacer un robots.txt que contenga lo siguiente:

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /wp-includes/
Disallow: /category/
Disallow: /tag/
Disallow: /feed/

OJO: algunas de esas líneas pueden cambiar según el blog, según el directorio que uses para las categorías y los tags.

Esto, claro, asumiendo algo obvio: tenés activados los permalinks con un formato “lindo”. Yo uso la fecha seguida del título de post, pero en DotAteca pongo la categoría seguida del título, dándole una apariencia más jerarquizada. (Esto, para los motores, es irrelevante, pero para los usuarios es muy útil.)

También sirve modificar el archivo header.php de nuestro diseño, y agregar la línea

<? if(is_archive()) { ?><meta name="robots" content="noindex,follow" /><?} ?>

dentro del elemento head, para que las páginas de archivo no aparezcan en los buscadores (aunque sí sigan sus links).

Y una última mejora, que muchos dicen es muy importante, es acostumbrarse a usar el tag <!--more--> después de uno o dos párrafos de apertura, para que en la página principal sólo aparezcan fragmentos de los posts.

Yo tengo el blog para “hacer sociedad”, conocer gente de este mundo que nos encanta pero en el que en mi zona estoy prácticamente solo (si alguien vive en Resistencia, que me pegue un grito), y ver un blog sin comentarios es como… no sé, una PC sin disco rígido… funca, pero me limita demasiado.

Para mi, un blog tiene que tener comentario, y adoro los comentarios; me da bronca cuando no los recibo… ¿Ustedes?

P.D.: Estoy probando publicar con fechas futuras, para esos días en que la inspiración me pega y escribo más de un post…

Edit: WTF El spam me hijackea los posts… si ven en otros, avísenme.

Esposa: ¿Quién es Roy Fielding?

Ryan: Un tipo. Es inteligente.

Esposa: ¿En serio? ¿Qué hizo?

Ryan: Ayudó a escribir los primeros servidores web, y después hizo un montón de investigaciones, explicando por qué la web funciona como funciona. Su nombre aparece en la especificación del protocolo que se usa para pasar páginas de los servidores a tu navegador.

Esposa: ¿Cómo funciona?

Ryan: ¿La web?

Esposa: Sí.

Ryan: Eh… es todo bastante sorprendente, realmente. Y lo gracioso es que está muy subestimado. El protocolo del que estaba hablando, HTTP, es capaz de un montónazo de cosas que la gente ignora por algún motivo.

Esposa: ¿http como lo que escribo en la dirección en el navegador?

Ryan: Sí. La primera parte le dice al navegador qué protocolo usar. Eso que escribís ahí es uno de los descubrimientos más importantes en la historia de la computación.

Esposa: ¿Por qué?

Ryan: Porque puede describir la ubicación de algo en cualquier lugar del mundo, desde cualquier lugar del mundo. Es la base de la web. Podrías decir que son las coordenadas GPS del conocimiento y la información.

Esposa: ¿Para páginas web?

Ryan: Para cualquier cosa, realmente. Ese tipo, Roy Fielding, habla mucho acerca de a qué apuntan esas cosas en la investigación que te dije. La web está armada en un estilo arquitectural llamado REST. REST provee una definición de un recurso, que es a lo que apuntan esas cosas.

Esposa: ¿Una página web es un recurso?

Ryan: Casi. Una página es una representación de un recurso. Los recursos son solo conceptos. Las URLs—eso que escribís en el navegador…

Esposa: Sé lo que es una URL…

Ryan: Ah, cierto. Eso le dice al navegador que hay un concepto en algún lado. Un navegador puede, entonces, pedir una representación específica del concepto. Específicamente, un navegador pide la representación de página web de ese concepto.

Esposa: ¿Qué otros tipos de representación hay?

Ryan: Realmente, las representaciones son una de esas cosas que no se usan tanto. En la mayoría de los casos, un recurso tiene una única representación. Pero esperamos que las representaciones se usen más en el futuro, porque hay un montón de formatos nuevos apareciendo por todos lados.

Esposa: ¿Por ejemplo?

Ryan: Mmm… Bueno, está este concepto que la gente llama Servicios Web. Significa un montón de cosas diferentes a un montón de gente diferente, pero el concepto básico es que las máquinas pueden usar la web igual que la gente.

Esposa: ¿Esto es otra de esas cosas de robots?

Ryan: No, no realmente. No quiero decir que las máquinas se van a sentar en el escritorio y navegar la web, pero las computadoras podrían usar esos protocolos para mandarse mensajes las unas a las otras. Hemos estado haciendo eso por mucho tiempo, pero ninguna de las técnicas que usamos hoy en día funcionan bien cuando necesitas hablar a todas las computadoras en todo el mundo.

Esposa: ¿Por qué?

Ryan: Porque no fueron diseñados para usarse así. Cuando Fielding y sus amigos empezaron a armar la web, poder hablar con cualquier máquina en cualquier lugar del mundo era de suma importancia. La mayoría de las técnicas que usamos en el trabajo para hacer que las computadoras se hablen entre sí no tenían esos requerimientos; sólo necesitabas hablar con un pequeño grupo de computadoras.

Esposa: ¿Y ahora necesitas hablar con todas las máquinas?

Ryan: Sí, y más. Necesitamos ser capaces de hablar con todas las máquinas acerca de todas las cosas que están en todas las otras máquinas. Necesitamos una forma de hacer que una máquina le diga a otra acerca de un recurso que puede estar en una tercera máquina.

Esposa: ¿Qué?

Ryan: Imaginate que estás hablando con tu hermana, y ella te pide prestada tu escoba o algo, pero vos no la tenés, la tiene tu mamá. Entonces le decís a tu hermana que se la pida a ella. Esto pasa todo el tiempo en la vida real, y pasa todo el tiempo cuando las computadoras empiezan a hablar también.

Esposa: ¿Y cómo se dicen las computadoras dónde están las cosas?

Ryan: La URL, claro. Si todo sobre lo que las máquinas necesitan hablar tiene una URL asociada, creaste el equivalente para una máquina de un sustantivo. Que vos y yo y el resto del mundo nos pongamos de acuerdo en hablar sobre sustantivos de una cierta manera es bastante importante, ¿no?

Esposa: Sí.

Ryan: Las máquinas no tienen un sustantivo universal; por eso son un asco. Cada lenguaje de programación, base de datos, u otro tipo de sistemas tiene una forma distinta de hablar de sustantivos. Por eso la URL es tan importante; permite a todos estos sistemas hablar entre sí acerca de sus sustantivos.

Esposa: Pero cuando estoy navegando, no pienso en eso.

Ryan: Nadie lo hace. Excepto Fielding y un puñado de otras personas. Por eso las máquinas siguen siendo un asco.

Esposa: ¿Y qué de verbos y pronombres y adjetivos?

Ryan: Gracioso que preguntes, porque ese es otro gran aspecto del REST. Bueno, al menos los verbos.

Esposa: Era un chiste.

Ryan: Era un chiste gracioso, pero realmente no era un chiste. Los verbos son importantes. Hay un concepto poderoso en programación y la teoría ciencia de la computación llamado polimorfismo. Es una forma geek de decir que el mismo verbo se puede aplicar a diferentes sustantivos.

Esposa: No entiendo.

Ryan: Bueno… mirá la mesa. ¿Cuales son los sustantivos? Taza, bandeja, diario, control remoto. Ahora, ¿Qué son algunas de las cosas que podés hacer con todas esas cosas?

Esposa: No la agarro… [N.d.T.: Soy un capo con los juegos de palabras (?)]

Ryan: Podés agarrarlos, ¿ciero? Podes levantarlos, podés tumbarlos, podés quemarlos. Podés usar esos verbos exactamente en cualquiera de los objetos de ahí. [N.d.T: Está difícil tumbar un diario, pero... bueno.]

Esposa: Bueno… ¿y?

Ryan: Bueno, eso es importante. ¿Qué si en vez de poder pedirte “agarrá la taza” y “agarrá el diario” y “agarrá el control remoto” tuviera que usar un verbo distinto para cada sustantivo? No podría usar la palabra “agarrar” universalmente, sino que tendría que pensar en una nueva para cada combinación de verbo y sustantivo.

Esposa: ¡Guau! ¡Eso es raro!

Ryan: Sí, lo es. Nuestros cerebros son de alguna manera suficientemente inteligentes como para saber que los mismos verbos pueden aplicarse a muchos sustantivos diferentes. Por ejemplo, no puedo conducir una taza ni beber un auto, pero algunos verbos son casi universales, como GET [agarrar/pedir], PUT [poner], y DELETE [borrar].

Esposa: No podés borrar una taza…

Ryan: Bueno, claro, pero la podés tirar a la basura. ¿Ese era otro chiste, no?

Esposa: Sip.

Ryan: Entonces, HTTP —este protocolo que Fielding y sus amigos crearon— es todo acerca de aplicar verbos a sustantivos. Por ejemplo, cuando entrás en una página, el nevegador hace un HTTP GET en la URL que escribís, y lo que vuelve es una página web

Las páginas web suelen tener imágenes, ¿no? Esos son recursos separados. La página sólo especifica las URLs a las imágenes y el navegador hace más HTTP GET en ellas hasta que todos los recursos se obtienen y se muestra la página. Pero lo importante acá es que sustantivos muy diferentes pueden ser tratados de la misma manera. Sea el sustantivo una imagen, texto, video, un MP3, una presentación de diapositivas, o lo que sea, puedo obtener con GET todas esas páginas de la misma forma, dada una URL.

Esposa: Parece que GET es un verbo importante.

Ryan: Lo es. Especialmente cuando usas un navegador, porque los navegadores más que nada solo piden las cosas. No hacen muchas otras interacciones con los recursos. Esto es un problema, porque hizo que mucha gente asuma que HTTP es solo para lectura. Pero HTTP es en realidad un protocolo de propósito general para aplicar verbos a sustantivos.

Esposa: Lindo. Pero sigo sin ver cómo esto cambia nada. ¿Qué tipo de sustantivos y verbos querés?

Ryan: Bueno, los sustantivos están ahí, pero no en el formato apropiado.

Imaginate cuando estabas navegando en amazon.com buscando cosas para comprarme para navidad. Imaginate que cada producto es un sustantivo. Ahora, si estuvieran disponibles en una representación que una máquina pudiera entender, podrías hacer un montón de cosas interesantes.

Esposa: ¿Por qué una máquina no entiende una página web normal?

Ryan: Porque las páginas web están diseñadas para ser comprendidas por la gente. A una máquina no le importa la disposición y el estilo del contenido. Las máquinas básicamente sólo necesitan los datos. Idealmente, todas las URLs deberían tener una representación legible por humanos, y otra para máquinas. Cuando un navegador hace GET para pedir un recurso para un humano, pedirá la legible por humanos.

Esposa: Entonces. ¿Todos tendría que hacer formatos máquina de todas sus páginas?

Ryan: Si fuera valuable.

Mirá, estuvimos hablando de esto con un montón de abstracción. ¿Qué tal si tomamos un ejemplo real? Sos una maestra. En una escuela, me imagino que tendrás un gran sistema informático, o tres o cuatro sistemas, más seguramente, que te dejan manejar a tus estudiantes: en qué clases están, qué notas tienen, contactos de emergencia, información acerca de los libros que usás en el aula, etcétera. Si los sistemas están basados en web, probablemente hay una URL para cada uno de los sustantivos involucrados: alumno, maestro, clase, libro, aula, etcétera. Ahora mismo, pedir la URL mediante un navegador te devuelve una página web. Si hubiera una representación legible por la máquina para cada URL sería trivial agregar nuevas herramientas al sistema, porque toda esa información sería consumible de forma estándar. También haría bastante más fácil que cada sistema se hable entre sí. O, podrías construir un sistema estatal o nacional que pueda hablar con cada uno de los sistemas escolares para obtener las calificaciones de las pruebas. Las posibilidades son ilimitadas.

Cada sistema obtendría información de los demás usando un simple HTTP GET. Si un sistema necesitara agregar algo a otro, usaría HTTP POST. Si quisiera actualizar algo, usaría HTTP PUT. Lo único que falta averiguar es qué forma tienen los datos.

Esposa: ¿Entonces en esto es lo que vos y toda la gente de computadoras está trabajando? ¿Decidir la forma que los datos deberían tener?

Ryan: Desgraciadamente, no. Por el contrario, la mayoría está trabajando escribiendo capas de especificaciones complejas para hacer cosas de una forma diferente que no es ni remotamente tan útil o elocuente. Los sustantivos no son universales ni los verbos polimórficos. Estamos tirando a la basura décadas de cosas que de verdad se usan y técnicas demostradas, y empezando de nuevo con algo que se parece mucho a otros sistemas que fallaron en el pasado. Usamos HTTP, pero sólo porque nos ayuda a hablar menos con los encargados de redes y seguridad. Cambiamos simplicidad por herramientas llamativas y diseñadores automáticos.

Esposa: ¿Por qué?

Ryan: No tengo idea.

Esposa: ¿Por qué no decís algo?

Ryan: Quizá lo haga.

De paso, los N.d.T. no son “Nota del Traductor”, sino “Nota del Tordek”.

Original [Via]

Según dice, demasiado tráfico se desperdicia por el hecho de que, como la Internet es anónima, “Suscribirse” a un RSS NO ES suscribirse a un RSS. Suscribirse quiere decir que alguien te lo manda, pero al RSS se lo pide. (Hay algo para decir con respecto a los “pings” sobre esto, pero no viene al caso.)

Entonces, cada 2 minutos, alguien hace click en su botón de actualizar, y manda varios paquetes a todas las URLs donde está “suscrito”. Cada una procede, entonces, a mandarle sus últimos 10 posts, que, digamos, son de 1kB cada uno. 10kB * 10 posts * 50 URLs * 1000000 de usuarios, y se nota para donde va esto.

En uno de mis momentos de ideas repentinas (estúpidas e inútiles, casi siempre, pero repentinas), pensé: Y… ¿por qué no mandar una simple cadena: un GET del tipo ?latestpost=1190961528. Si no está, bueno, se mandan los 10 posts. No arreglamos nada, pero al menos no rompemos nada. Es compatible con lo que ya existe… ¿Y si está? y si está, simple: $query .= " WHERE date >". date("Y-m-d",$GET['latestpost']);.

Supongamos que ponemos eso en nuestro feed RSS:

Ventajas: ahorrar ancho de banda (asumiendo que alguien lo aplique).

Desventajas potenciales:

• Seguridad: el date() solo va a morirse si la cadena llega a tener algo más que números… y si no? /[^0-9]/.
• Tiempo de procesador: dos palabras: Un. If.
• Retraso en el acceso a la base de datos: Idem: Un. Where.
• Pedir una fecha demasiado vieja: Uhm… LIMIT?

¿Y del lado de los clientes RSS? Para aplicar, lo único que tienen que guardar es la fecha del último post recibido…

La verdad que esto es tan estúpido que, si no existe ya, guau… y si existe… ¿por qué el problema de “mucho ancho de banda”?