Logicola

El jueves 13 de diciembre, un par de porciones de Simplelógica, tu empresa amiga, estará en Madrid. Uno de nosotros hará malabares con balones de playa en el hocico, otro presentará un hack llamado MeatMeetsMeat

MeatMeetsMeat utiliza SMSs para poner en contacto a personas que
tienen lazos en distintas redes sociales (flickr, last.fm, 11870) pero
que no necesariamente se conocen en persona. Una persona alertará de
su presencia en un determinado emplazamiento (concierto, local, etc.)
mediante un SMS a la aplicación. Ésta se encargará de notificar de
vuelta a la persona si alguno de sus contactos en redes sociales
también se encuentra en el mismo lugar o bien si uno de estos
contactos se "conecta" a su vez simultaneamente y en la misma
ubicación. La aplicación también permitirá el envio de mensajes
privados a un contacto "online", ejerciendo de proxy para mantener la
privacidad de ambos participantes.

Os ruego que me traigáis sardinas.

Contexto: esta tarde he mantenido una divertida discusión vía mail con unos cuantos amados amigos a raiz del XO-1, el también llamado simplemente olpc. La discusión fue bastante previsible, ya saben: buena idea/mala idea, prioridad/lujo, importante/trivial, cosas de iTontos (léase, en el contexto de la discusión, geeks, tecnófilos, bloggers, twitteros o cosas así) o cosas de genios; lo normal. El caso es que de las muchas tonterías que vertí en ese hilo de discusión, en el último mail me quedaron unos cuantos párrafos juntos que no me digustan y quería conservar. Así que aquí van, más o menos extractados . Y no se asusten por mi tono, no hay nada que no pueda explicarse por la placa en la cabeza. No sé si se lo había dicho alguna vez, pero sintonizo Radio Pirenaica sólo frotando los incisivos. Los mios, digo.

Dice mi amado amigo:

> > Las iChorradas estan bien, como esta bien un chupachups. Yo vi un
> > iPhone funcionando en Yemen y me encanto. Eso para empezar no quiere
> > decir que tenga la necesidad de comprarlo...

Y respondo yo:

Ahh, ¿quieres decir lo mismo que pensabas de un móvil GSM hace 10
años? Supongo que a un keniata [1] en el 95 le hubieses dicho que no se
preocupase, que eso son iTontadas. Díselo ahora, a ver que te
contesta.

Un iPhone es

• A) un dispositivo de telefonía móvil
• B) un dispositivo de acceso a internet
• C) un reproductor MP3

Dime que ni el acceso a A) ni B) tienen que ver con el desarrollo
económico de una región. Dímelo sin reirte.

Dime que un reproductor MP3 más unos altavoces no es una forma de que
un pueblo entero escuche un mp3 educativo sobre prevención del SIDA. O
que una clase escuche material educativo bajado de internet.

Un iPhone es una piruleta, mis cojones.

A mi me parece que después de haber hecho tantos viajes y leer tantos
artículos y tanta historia, no habría que cometer ese error tan iTonto
de no reflexionar sobre lo que tienes, para lo que sirve y en qué
contribuye a que seas quien eres y tengas lo que tengas.

No hay ninguna pieza de tecnología que no sea un arma en las manos
adecuadas. Una azada es un arma, igual una mosquitera, un móvil o un
OLPC. Si yo sintiese tanto África, me alegraría cuando los iTontos se
convierten en traficantes de armas baratas y de colores.

Cell Phone Use Changes Life in Africa (Volver).

Uno de las consecuencias más graves de las situaciones pobreza y la mendicidad en las sociedades del primer mundo es la destrucción de la identidad social. El mendigo pierde casi todas las características identitarias que no sean las asociadas a su condición socioeconómica. La falta de hogar se convierte, más allá de la realidad física, en la perdida del "hogar" dentro de la comunidad. Desaparecen progresivamente de la memoria de su entorno, desaparecen sus historias y por tanto desaparecen de la Historia. No queda más que su rol, asociado si acaso a su nombe y a su mote. Se convierten en personajes a costa de ser menos personas.

Dado que el mendigo en muchas ciudades está asociado por la fuerza de costumbre a una determinada localización geográfica (el de esta plaza, la de esta calle, el de este barrio) podrían utilizarse los servicios e interfaces de geolocalización en web como cimiento para contruir un proyecto de recuperación de la identidad social de las personas sin hogar. La forma menos trabajada posible de la idea sería ubicar geograficamente en un (G/Y)map a los mendigos de una comunidad, tomando ventaja de la fuerte asociación entre mendigo y zonas muy específicas. Crear desde ahí un repositorio de datos (fotos, entrevistas, videos, (auto)biografías, que sirvan para dar entidad a la persona y salvar su memoria personal y aumentar a partir de eso su peso social.

Obviamente esto es sólo un apunte de una idea, pero podría servir como base para un proyecto más articulado. Es interesante considerar que la proyección digital puede no ser sólo un divertimento para los sospechosos habituales, sino que puede utilizarse como herramienta y germen que ayude a recuperar los casos en los que la "proyección analógica" haya sufrido graves daños.

Siendo vicepresidente ejecutivo nonagésimo de Google, una de las preguntas que me hacen más a menudo es algo en la línea de 'Manuel, ahora que en Google habéis creado uno de los mayores corpus documentales conocidos en la historia de la humanidad, ¿no creéis que sería beneficioso para todos que no limitáseis el acceso a sus empleados más importantes y, por el contrario, hubiese una forma de acceder de forma sencilla, gratuita y universal a ese inmenso repositorio de datos e información?' De esta forma, me dicen, podriamos imaginar un futuro no muy lejano en el que para preguntas como '¿Qué es PHP?' o necesidades del tipo 'Desearía información sobre la usabilidad' no tendriamos que perturbar la discusión en listas de correo, foros y demas espacios de interacción, sino que, desde la comodidad de nuestro propio hogar, podriamos resolver las dudas más triviales y básicas de forma rápida, sencilla y económica.

Confieso que al principio me costaba un poco llegar a visualizar un escenario como éste, y lo he llegado a etiquetar de mera utopía transhumanista, pero en Google sabemos que el sueño de hoy es el programa de publicidad contextual del mañana y el anuncio que voy a hacer ahora viene a ejemplificar este principio de la mejor manera. ¿Estás lista, gran bola de barro a la que llamamos afectuosamente 'Planeta Madre'?

Con caracter inmediato, Google lanza su API de consulta que permite acceso universal, ilimitado y gratuito a todos los documentos web indexados en sus servidores desde su fundación.

¿Qué implicaciones tiene esto para mi, como simple usuario de foros y listas de correo, y lleno de dudas razonables sobre el mundo que me rodea?

Me alegra que me hagas esa pregunta. Google ha implementado una API (siglas de "Application Programming Interface"), un método que simplifica enormemente la búsqueda de documentos e información. A nuestra API puedes acceder en 'http://google.com/search'. Necesita como mínimo un parámetro 'q' con el valor de la cadena buscada (se lo pasaremos por GET) y te devuelve un listado de documentos en text/html.

La URL que debemos formar es de este tipo:

http://google.com/search?q=[termino_de_busqueda]

Como ejemplo, si queremos salir de dudas sobre lo que significa 'arenque', crearemos una URL del tipo

http://www.google.com/search?q=arenque

Si probamos esto con cualquier agente de usuario capaz de hacer peticiones HTTP y de aceptar el tipo mime 'text/html' como respuesta, veremos que Google devuelve una respuesta paginada con los mejores resultados para 'arenque' ordenados por el algoritmo de relevancia de Google (pagerank).

No dejes de experimentar con esta nueva API y comentar cualquier aplicación ingeniosa que se te ocurra. Y recuerda, no nos importa que no sueñes con un mundo mejor para Google. En Google soñamos con un mundo mejor para tí.

1. Isa necesitaba una cosa de Twitter.
2. Yo necesitaba otra, poder mandar un mensaje privado directamente desde la timeline.
3. Presentamos Twitter Powertoys (v.01) que nos hace felices a Isa, a mi y con un algo de suerte un poquito a tí también.

Cualquier sugerencia o comentario se agradece, como siempre. ¡Ah! Y gracias a Ani-k por asomarse a iluminar en tonos rojos este post.

Como abrazo al onceocho, he creado este grupo de flickr. Come join us.

Había olvidado cuanto me gusta hacer páginas HTML . Ni Rails, ni PHP ni Mysql. Ni CSS, ni Fireworks. Sólo un documento en blanco y una sola capa en la que centrarme, la más básica y primaria, donde reside esa cosa tan elusiva llamada "información". Me encanta el proceso de escribir algo de código, sumergirse en la lectura de artículos y el seguimiento de enlaces, para retornar muchos minutos después al código con un elemento o una clase que añadir o quitar, algunas dudas menos y mucha mas consciencia de mi ignorancia que antes.

De forma muy, muy, breve, estos son algunos de los conceptos que manejo sobre el nuevo marcado:

• DOCTYPE: ¿De verdad que hay otra opción que HTML 4.01 Strict? Zed está muerto, nena, Zed está muerto. Y XHTML también.
• Maximizar la información: Hoy en día hay muchas setas mágicas para convertir las meras cadenas de texto bidimensionales en repositorios tridimensionales de información. Microformatos, por supuesto, con rigor; y un poco más allá de los microformatos con RDFa y GRDDL
• Pulcritud: la tipografía web da asco, pero podemos ser rigurosos con lo que escribimos. De hecho, acabo de emplear — y ha sido de lo más satisfactorio.

Probablemente continuará.

Qué

theflashbackproject

Quién

the vaporteam: david arango, fernando blat, manuel gonzalez noriega, maria martinez, ramon pravia, silvia arcos

Cuándo y Dónde

¿Por qué?

Porque el presente nunca dura lo suficiente.

Hace un par de semanas llevé a la práctica mi idea de una remezcla de Flickr y 11870. Se trata de un script de usuario, desarrollado con Greasemonkey, muy simple. Si una foto de Flickr está relacionada con un establecimiento con ficha en 11870 solo tenemos taguear la foto con una machine tag de la forma onceocho:id=[id_del_establecimiento_en_11870]; el script añadirá al pie de la foto una pequeña sección con el nombre del establecimiento, su dirección y el enlace a la ficha completa en 11870.com. Puede verse un ejemplo en esta captura de pantalla, aunque lo mejor es que te instales el script.

Voy a explicar a grandes rasgos las piezas fundamentales de la creación del script. Un mashup como este, es decir, un sitio o script cuya principal funcionalidad se deriva de agregar datos de dos o más aplicaciones, puede estar basado en servidor, creando una tercera aplicación que realice la remezcla, o basado en cliente, mediante un programa javascript funcionando en la plataforma adecuada (que serían Firefox+Greasemonkey u Opera) para modificar un sitio objetivo e inyectar datos de otro u otros sitios. Esta remezcla en cuestión es del segundo tipo, y funciona inyectando en las páginas de Flickr datos obtenidos de 11870.

Los sitios de los que deseemos obtener datos reutilizables estarán situados en algún punto de una escala de transparencia. En el cero estarían sitios totalmente opacos, que podemos identificar con los realizados en Adobe Flash. A continuación aquellos realizados en muy malo, mal HTML, HTML normalillo y así hasta llegar a los realizados en POSH, donde podemos colocar el cinco. Todos estos sitios son con mayor o menos dificultad aproximables mediante técnicas de "screen scraping" gracias a las potentes herramientas disponibles como LWP o Hpricot. Rondando el nueve estarían las APIs estructuradas de recuperación de datos y acercándose al diez, las aproximaciones más innovadoras a interfaces no estructuradas de consulta, acercándose a la visión de las web como la conjunción de silos de datos, en el que el "sitio web" tradicional solo sería una de las muchas serializaciones posibles (esto ya está firmemente apuntado con la convicencia de distintas serializaciones, por ejemplo feeds, widgets, centralizadas o distribuidas)

En un punto dulce de la escala (en torno al notable) podriamos situar las interfaces HTML que usan microformatos. Los microformatos son un ejemplo de una serialización mixta, en la que el documento HTML dobla sus funciones: además de la más obvia, servir al agente de usuario para construir un DOM, un documento con microformatos embebidos permite a herramientas especializadas abstraer la recuperación de nodos de contenido. Los microformatos permiten por tanto la existencia de un ecosistema de herramientas que trivializan y amateurizan la recuperación de piezas de información. Con los microformatos, la unidad básica de información de una página se convierte en una "commodity". 11870.com utiliza microformatos en sus páginas. Concretamente la información de un establecimiento está microformateada con hCard, pensado para representar "gente, empresas, organizaciones y lugares" y por tanto idóneo para el uso que se le da en este caso.

A la hora de procesar una página microformateada tenemos dos opciones. La primera es utilizar un parseador de microformatos nativo para nuestro lenguaje; la segunda, construir un puente que traduzca la información de HTML+microformato a otra representación que consumiremos. En este caso, a pesar de encontrar un parseador Javascript de microformatos llamado Sumo y creado por Dan Webb, he optado por la segunda ópción y creado una pasarela que, dada una URL determinada microformateada con hCard, devuelve una salida en JSON, un formato ligero de intercambio de datos y que es especialmente adecuado para nuestro caso por poder evaluarse a tipos de datos nativos de Javascript, lo que nos facilita enormemente el manipulado de la información recibida.

• El código fuente de la pasarela está disponible.. Úsalo, edítalo, remézclalo o llévalo a cenar a un sitio caro, fingiendo que estás interesado en su conversación cuando en realidad sólo puedes pensar en llegar a casa, arrancarle la ropa y acostarte con él. Si a él no le importa, a mi tampoco.
• Ejemplo 1: Extrayendo mi perfil de Flickr
• Ejemplo 2: Extrayendo la información de Simplelógica en 11870.com

Las dependencias son dos: hKit, un parseador de microformatos en PHP de Drew McLellan y esta clase PEAR de codificación/descodificación JSON. En caso de haber realizado la pasarela en Ruby, los equivalentes serían la fantástica mofo y ruby/json.

Hay dos aspectos secundarios pero fundamentales que he intentado plasmar en el puente de forma correcta: las respuestas de un servicio web siempre deben ir acompañadas de un código HTTP y un tipo MIME adecuados. La interoperabilidad, que es el plasma sanguíneo de la web, depende de la predectibilidad y coherencia de los mensajes transportados. En referencia a los códigos HTTP, la pasarela maneja un subconjunto de tres condiciones y códigos correspondientes. Dos están en la clase 4xx (error del cliente) y uno en la clase 2xx (éxito de la petición):

1. El script no ha recibido el obligatorio parametro url. Respuesta con código 400 Bad Request.
2. El script no ha obtenido datos para la URL corresponiente. Respuesta con código 404 Not Found.
3. El script ha logrado recuperar la url suministrada y extraer datos marcados con hCard. Respuesta con código 200 OK.

Respecto a los tipos MIME, la pasarela maneja text/plain para los mensajes de error y application/json, el tipo recomendado, para las respuestas JSON.

Una vez recuperado los datos de la pasarela, el desenlace en el script de usuario es sencillo. Detectamos las "machine tags", que actúan de mecanismo ligero de enlace entre recursos, en este caso, entre el recurso "foto" y el recurso "establecimiento". A continuación recuperamos la información en JSON desde la pasarela e insertamos los datos en el DOM de la página. Lo único destacable es señalar como el desarrollo de scripts de usuario permite el empotrado de archivos binarios (en este caso el logo de 11870.com) mediante el uso de data URIs (una explicación de este patrón la da Mark Pilgrim). Para la creación de la data: URI para el logo de 11870 he recurrido a la utilidad data: URI kitchen de Hixie.

Como conclusión: hemos visto como los scripts de usuario permiten la remezcla de dos o más servicios para aumentar el valor añadido de un recurso determinado, en este caso proporcionar un "vista previa" de la ficha de un establecimiento en 11870.com adjunta a una fotografía de este establecimiento en Flickr. Para la creación de este tipo de aplicaciones de remezcla es fundamental disponer de fuentes de datos transparentes, cosa que los publicadores pueden asegurar de forma fácil mediante la utilización de microformatos. En los desarrollos es fundamental que aseguremos una correcta interoperabilidad mediante la utilización de códigos HTTP y tipos MIME adecuados. Finalmente, hemos un visto un tip sobre la inclusión de datos binarios en forma de texto mediante "data: URIs"

No, really.

• Simple Sharing Extensions
• Silverlight
• Distributed computing
• XML
• User scripting
• Safari
• XMLHttpRequest
• Fleck