Se han escrito ríos de tinta sobre la muerte de Google Reader. Una de las mayores víctimas silenciosas, son los usuarios de Blackberry. Hasta el momento, yo usaba la web de iPhone; un vestigio raro ya que hay “app”, pero que era la mar de usable en mi móvil.

De entre todos los reemplazos de Google Reader que se barajan, aún no he encontrado ninguno que me solucione el uso móvil en la Blackberry- no parece haber nadie que tenga una web móvil usable [la de Netvibes ya os digo yo que no se puede usar] y de momento no se huele ninguna aplicación (y por mucho que esto me estigmatice, preferiría no pagar si es necesario [aunque en el caso del lector de feeds, podría hacer una excepción]).

Explorando alternativas, me he puesto un poco en plan hágaselo usted mismo. Feedly dice que implementará Normandy, un clon del backend de Google Reader y de momento apostaré por esta reimplementación. De hecho, Google Reader no tiene API “oficial”, pero mucha gente la ha destripado y documentado, y de hecho goza de cierta popularidad. Así pues, me he puesto a buscar librerías que implementen la API.

Dado que uno trabaja mayoritariamente Python/Django y Java, esto me ha limitado un poco la búsqueda. Para Java, el mejor candidato parece greader-unofficial, pero parece estar un poco muerto con tan solo 47 commits en su repositorio, el último de octubre de 2011. En cambio, naturalmente parece que para Python existe libgreader, con commits de anteayer y con mucha mejor pinta.

Así pues me he puesto manos a la obra y he iniciado un proyecto Django publicado en Github, GROLM (Google Reader on Lightweight Mobile). Es un proyecto Django 1.5 estándar sobre una base de datos PostgreSQL.

libgreader proporciona cuatro alternativas a la hora de manejar la autenticación contra Google Reader:

• proporcionarle el usuario/contraseña de la cuenta Google y que él mismo autentique
• OAuth
• OAuth2
• una variante de OAuth para Google App Engine

; obviamente la menos usable y/o poco segura es la de la contraseña, y tampoco quiero desarrollar sobre App Engine, así que me he decantado por OAuth2 (al ser más moderna obviamente que OAuth). El mecanismo de autenticación de OAuth2 de libgreader parece completo, pero deseaba integrarlo con el sistema de autenticación de Django para ahorrarme faena.

Para ello, he localizado django-social-auth, que integra en el sistema de autenticación de Django diversos mecanismos de login social entre los que se incluye OAuth2. La configuración de django-social-auth con OAuth2 es relativamente sencilla, simplemente tenemos que añadir el siguiente fragmento a nuestro settings.py:

INSTALLED_APPS = (
  # ...
  'social_auth',
)

AUTHENTICATION_BACKENDS = (
  'social_auth.backends.google.GoogleOAuth2Backend',
)

GOOGLE_OAUTH_EXTRA_SCOPE = [
  'https://www.googleapis.com/auth/userinfo.email',
  'https://www.googleapis.com/auth/userinfo.profile',
  'https://www.google.com/reader/api/',
 ]

LOGIN_URL = '/login/google-oauth2'
LOGIN_REDIRECT_URL = '/logged-in/'
LOGIN_ERROR_URL = '/login-error/'

GOOGLE_OAUTH2_CLIENT_ID = 'xxxx'
GOOGLE_OAUTH2_CLIENT_SECRET = 'xxxx'

, donde los dos últimos parámetros los podemos obtener de la Google API Console (donde también deberemos añadir las URLs de nuestra aplicación para validar el proceso de login)

Con esto, con anotar una vista como @login_required, al visitarla se nos redirigirá a la página de autenticación de las cuentas Google donde haremos login y se nos redirigirá de nuevo a la vista ya autenticados (se creará un usuario de Django correspondiente al usuario de Google y se vinculará a la sesión del usuario).

Finalmente, para “propagar” esta autenticación a libgreader, el mecanismo que he encontrado es extraer el token de acceso que recoge django-social-auth y almacena en una base de datos y pasárselo a libgreader, algo que he encapsulado en un módulo, pero que en realidad es bastante sencillo:

usa = UserSocialAuth.objects.get(user=user)
 auth = OAuth2Method(settings.GOOGLE_OAUTH2_CLIENT_ID, settings.GOOGLE_OAUTH2_CLIENT_SECRET)
 auth.authFromAccessToken(usa.extra_data['access_token'])
reader = GoogleReader(auth)

, donde user es el usuario (que desde una vista podemos obtener por ejemplo haciendo request.user). Una vez tenemos esto, ya obtenemos el objeto GoogleReader que constituye el punto de acceso a la API.

El resto de código implementado por el momento tan sólo obtiene la reading-list (los elementos sin leer) y muestra sus 20 primeras entradas.

(llego muy tarde a esto, disculpas)

Hace mucho mucho tiempo, Google sacó Google Apps con su edición gratuita. Nos daba una posibilidad de usar las aplicaciones de Google (GMail, Docs [ahora Drive], etc.), bajo un dominio propio y con administración centralizada de usuarios. ¡Y gratis!

Y hubo gran regocijo y cantidad de gente con dominio propio se hizo la cuenta gratuita, migró su correo y demás a Apps (perdiendo datos o con gran trabajo- yo tengo pesadillas de cuando pasé mis estrellitas de Google Reader…) y contempló maravillada la nueva realidad.

Inicialmente, Apps era gratuito hasta 25 usuarios, y a parte de ese límite, las características de la versión de pago no eran tan atractivas (si no recuerdo mal, más espacio, herramientas para migrar correo e integración con directorios, básicamente). Naturalmente, no sólo particulares se hicieron esto sino que empresas (sospecho que muchas) se pasaron a Google Apps.

Puedo entender la frustración que sintieron en Google al comprobar cómo empresas con ingresos para las que tendría todo el sentido del mundo contratar la versión de pago por un coste ínfimo (40€/usuario/año es ridiculo comparado con, pongamos, lo que cuesta el empleado- imaginad como os sentiríais si os aumentasen en 40€ el sueldo bruto anual…), utilizaban la versión gratuita (que Google vendía como para pequeñas asociaciones, familias y otras entidades no precisamente con ánimo de lucro). Obviamente no se trata de nada ilegal, e incluso si pensamos que Google es una empresa enorme con unos beneficios inimaginables, podemos defender que no se trata de algo inmoral siquiera… pero insisto, puedo comprenderles.

Así pues, fueron recortando. La versión gratuita se iba ocultando más y más, luego se redujo el límite de 25 a 10 usuarios y finalmente, se eliminó completamente.

Dos apuntes:

Uno, es posible que las empresas que “abusaron” (insisto en las comillas), hayan hecho que los verdaderos destinatarios del invento lo hayan perdido.

Dos, para los friquis que lo echamos de menos… ¿realmente aporta tanto? Lo más visible es el dominio personalizado para los emails, pero con las opciones de accounts y forwarding, se puede simular bastante bien con el GMail tradicional. La gestión centralizada de usuarios… vaya, si la necesitas es porque tienes bastantes usuarios (probablemente, más de 25).

Aunque ciertos conceptos de programación son más viejos que yo, hay ciertas técnicas muy potentes que son desconocidas o ignoradas por mucha (demasiada) gente.

A principios de los 80 (la Wikipedia cita un RFC de 1975 y, cómo no, Xerox) se hizo la formulación obvia que la comunicación entre sistemas se podía modelar como una llana y simple llamada a una función que se ejecuta en otro sistema y nos devuelve el valor.

El mecanismo que se utilice para ello debe ser irrelevante, nosotros sólo queremos ser capaces de escribir:

resultado = suma(a,b)

y que la suma se realice en el sistema remoto. A esto le llamaron llamada de procedimiento remoto o Remote Procedure Call en inglés.

Sun implementó uno de los primeros sistemas de RPC para implementar el sistema de archivos distribuido NFS, y a lo largo del tiempo han ido apareciendo diferentes mecanismos de RPC para diferentes plataformas y necesidades.

Con la popularización de la WWW, el protocolo HTTP y Javascript en los 90, pronto la gente comenzó a implementar comunicaciones entre sistema utilizándolos. Por ejemplo, una web podía exponer algunos de sus contenidos y funcionalidades en HTML para consumo humano, pero también exponerlos para consumo de otros sistemas. Mecanismos simples como poner una URL en la que si hacemos un POST http con unos argumentos, nos devuelve el resultado de una operación en un formato fácilmente parseable.

Pronto, uno de los padres fundadores del HTTP, procesó los principios fundamentales del HTTP y la WWW, en concreto que todo era una cuestión de URLs y acciones como GET/POST/PUT/DELETE que soporta el protocolo HTTP; cada URL representa un recurso y podemos expresar acciones mediante los “verbos” HTTP. A esto le llamó REST y supuso una perspectiva limpia y poderosa de lo que es la WWW.

De allí se pasó a los RESTful Web Services, maneras de exponer servicios en Internet utilizando los principios del REST.

Típicamente, los desarrolladores de servicios web utilizan técnicas similares a las del desarrollo de aplicaciones web para publicar servicios REST, y los desarrolladores de servicio ejecutan las llamadas HTTP correspondientes para utilizarlos. Los formatos se intercambian en cualquier formato de intercambio de datos; desde texto plano, a XML u otros formatos como JSON, YAML o lo que se le ocurra la persona, teniendo que codificarse en origen y decodificarse e interpretarse en destino.

Pero paralelamente, otros desarrolladores recordaron el RPC y desarrollaron sistemas de RPC sobre HTTP. Uno de los primeros fue XMLRPC, que posteriormente evolucionaría hacia el denostado SOAP. Muchas implementaciones de RPC sobre HTTP inicialmente eran malas; en parte por ser nuevas y primitivas, pero principalmente por la interoperabilidad. Mucho RPC anterior era entre sistemas muy homogénenos, con el mismo lenguaje en cliente y en servidor y desarrollados por las mismas personas, pero en el mundo de la WWW, son comunes entornos más heterogéneos, con lo que el RPC es mucho menos sencillo; diferentes modelos de datos y convenciones en cada extremo de la comunicación trae muchas dificultades y muchos RPC primitivos tenían grandes problemas de interoperabilidad.

La visión de la transparencia entre sistemas no se daba. A veces, incluso, utilizando el mismo lenguaje pero diferentes implementaciones del mismo protocolo se tenían muchos problemas.

Queda claro que una idea, por buena que sea, está limitada por sus implementaciones, y el pobre estado de los RPC sobre http ha impulsado muchísimo el uso de REST en vez de RPC. Eso es malo, porque en general REST te da más trabajo que RPC; mientras que en REST uno debe definir el formato de datos de intercambio e implementar la codificación y decodificación de estos, los mecanismos RPC realizan todo el trabajo sucio sin que el programador se tenga que preocupar de nada.

Además, para invocar un servicio REST, simplemente has de usar las librerías de HTTP y de codificación que hayas escogido (parseo de texto plano, XML, JSON, etc.); con un sistema de RPC has de aprender a usar la librería, que si bien te puede ahorrar código, es más complicada conceptualmente.

Esto llevó a que SOAP fuese condenado por gran parte del mercado (la interoperabilidad era siempre problemática, las librerías complejas, etc.) y el REST se popularizase mucho e incluso fuese en la práctica la mejor opción en muchos casos.

Sin embargo, el RPC ha avanzado mucho. Disponemos de librerías decentes de SOAP, XML-RPC y otros protocolos como JSON-RPC para la mayoría de lenguajes, y hoy en día ya no me sorprende consumir un servicio implementado en un lenguaje desde otro sin ningún problema.

Por otra parte, gente como Facebook y Google han inventado protocolos nuevos que son decididamente interoperables y multilenguaje, como Thrift de Facebook (ahora Apache) y los protobuf, que resuelven el RPC de una manera limpia y eficiente.

Con RPC nos podemos ahorrar mucho código repetitivo de comunicación que supone REST, con el consiguiente aumento de productividad.

¿Deja de tener sentido REST y sólo debemos comunicarnos mediante mecanismos RPC, por tanto?

No, desde luego que no. Aún pueden existir problemas de interoperabilidad entre algunas plataformas poco populares, o los mecanismos de RPC puede que no sean buenos. REST es siempre un mínimo común denominador y la verdadera manera de asegurarnos que nuestros servicios pueden ser utilizados universalmente- incluso yo recomendaría que aunque implementemos RPC, ofrezcamos también REST para quien no pueda utilizarlo (recordemos igualmente que puede ser sencillo exponer un mismo servicio tanto con XML-RPC, como con JSON-RPC simultáneamente sin mucho esfuerzo, ampliando horizontes), y REST sigue siendo útil para exploración y “descubribilidad”.

Pero, cuando sea posible y adecuado, ahorrémonos escribir código de más.

Marvel tenía (o tiene, estoy tremendamente desactualizado) un cómic titulado “What if…?” que trataba de qué pasaría en los universos Marvel si algún acontecimiento clave hubiese seguido otro curso. Así pues, podíamos leer cosas como qué hubiese pasado si Spider-Man hubiese sucumbido al simbionte o Gwen Stacy no hubiera muerto.

Yo, la verdad, prefería “What the…?”, que trataba de situaciones absurdas, pero bueno.

El ejercicio que me propongo hoy es “What if… PHP y MySQL nunca hubieran existido?”

PHP y MySQL fueron en su momento las estrellas del desarrollo web. PHP surgió de un proyecto personal de Rasmus Lerdorf inicialmente publicado en 1995, que según el TIOBE, comenzó a dispararse en popularidad allá por 2002 y gozó de su mejor momento entre 2005 y 2010, donde inició un aparente declive (seguramente por el ascenso de otros lenguajes/frameworks para la web menos demenciales). MySQL empezó como proyecto en 1994 y su primera publicación fue (la Wikipedia no es muy específica en este asunto) entre 1995 y 1998—no encuentro buenas fuentes sobre su ascenso a la fama, pero yo lo situaría aproximadamente por la misma época que el de PHP, y sin que se atisbe una caída en su popularidad (si no contamos su adquisición por parte de Oracle en 2010 y la relativa proliferación de forks).

No es casual, claro, que la web explotara justo en ese momento, entre 1996 y 1998, y que los dos estuvieran en el sitio exacto, en el momento exacto para formar la MP de LAMP. En un momento en el que no había una abundancia de herramientas de desarrollo web decentes (Perl era probablemente la alternativa abierta más popular; los servlets de Java son del 97, pero por ejemplo hasta 1999 no existió Tomcat; ASP de Microsoft data de 1998… no había muchas más cosas y por supuesto, gran parte de lo que hoy está de moda en aquella época ni existía), PHP/MySQL era una tupla muy accesible para desarrollo web —fácil de instalar, fácil de comenzar y fácil de obtener resultados rápidos— y sin mucha competencia que hiciese destacar sus defectos. Esto llevó a que prácticamente todo el segmento “no profesional” y una parte importante del profesional se volcasen en esta plataforma (las “MS Shops”, por supuesto, apostaron por ASP y mucha gran empresa se fue a Java) y posteriormente, como suele suceder, el sector no profesional arrastrase al profesional.

Sin embargo, hoy en día PHP está bastante denostado. Se le sigue reconociendo como vía “rápida y sucia” y goza de una inercia considerable (sobre todo, por la abundancia de mano de obra y código existente a mantener), pero puede decirse que ha pasado de moda y que sus abundantes defectos le están pasando factura; prácticamente podría decirse que Facebook es su único usuario de gran perfil (y con importantes peros). MySQL, en cambio, sigue relativamente saludable, sigue siendo extremadamente popular y, pese a que el sector crítico parece crecer día a día, no parece que vaya a ser eclipsado en breve.

¿Qué hubiera pasado si Rasmus Lerdorf se hubiera avergonzado de su pequeño monstruo y hubiese decidido mantenerlo en el sótano oscuro y lúgubre que nunca debió abandonar? ¿Y si MySQL no hubiese tenido su vertiginosa aceptación, quizás por una mala fama alimentada por alguna deflagración especialmente notable?

Probablemente, el mundo web hubiese sufrido algún retraso. Perl, Java o ASP no eran suficientemente accesibles en ese momento como para tomar el relevo (por diversos motivos: de coste en el caso de ASP, de accesibilidad para Java y Perl). Lo más probable es que Perl hubiese ganado bastante terreno y  hoy en día gozase de más popularidad, incluso entre los imberbes. ¿Se hubiese adelantado algún framework como el popular Ruby on Rails? Yo creo que no; Rails surge ya en 2005 y no creo que se hubiese acelerado mucho su aparición en caso de haber existido un vacío. Simplemente, hubiésemos visto otros frameworks nuevos sobre algún lenguaje existente, o quizás algún framework que el tiempo olvidó habría sido adoptado masivamente. Apostaría por que Python, que explotó en popularidad en 2004, hubiera cubierto el vacío de PHP con algún framework.

¿Consecuencias? Sí, la web retrasada 2-3 años. Probablemente los titubeos propios de PHP se hubiesen trasladado a su sustituto (algún framework sucio y bizantino de Python se habría impuesto), o quizás (Dios no lo quiera) Perl hubiese arrasado y hoy en día estaríamos condenados a prefijar todo con sigilos (pero seguramente con un framework elegante). La versión optimista (para mí) es que la web como plataforma de aplicaciones no hubiese tenido su auge y nos hubiéramos quedado mayormente en la web de contenidos y el modelo de aplicaciones de escritorio… y con toda probabilidad esto habría supuesto un buen bofetón para Linux y en menor medida para Apple (las aplicaciones web son prácticamente automáticamente multiplataforma). ¿Sería esto positivo? Por una parte, uno es de los que suscribe que nunca debimos apostar por la web para aplicaciones (sí, desde luego, para contenidos) y que quizás buen número de informáticos no tendrían que haber lidiado con los problemas de la web para este propósito y destinado su tiempo a cosas más útiles: siendo optimistas, quizá hoy tendríamos aplicaciones de escritorio multiplataforma de despliegue indoloro (e.g. Java y Web Start, pero bien) y todo sería más de color de rosa. El reverso de la moneda sería un monocultivo Microsoft y todos estaríamos desarrollando en Visual Basic (y no, no el .NET), claro está.

A un nivel más elevado y más del mundo real, igual las burbujas web y sociales no hubieran nacido ni estallado nunca. Habría más desarrollo informático empresarial tradicional con el aburrimiento y la solidez consiguientes.

Por otra parte, creo que la historia no habría cambiado sustancialmente sin MySQL. PostgreSQL seguramente ocuparía su lugar, llevándonos a un mundo con más integridad referencial y donde nuestros datos serían un pelín menos volátiles. Defiendo que el movimiento NoSQL hubiera dado un pequeño paso atrás. Sí: con o sin web de aplicaciones y todo eso, Google hubiera existido y hubiese necesitado BigTable/MapReduce (es el contenido lo que es difícil de indexar). Pero parte de la necesidad de NoSQL viene de las deficiencias de MySQL y no del modelo relacional (adicionalmente, este no estaría tan desprestigiado y probablemente serían más de cuatro gatos los que sabrían sacarle partido). Y es que resulta difícil encontrar una implementación peor de SQL que MySQL (si no contamos SQLite, claro, pero ese juega en otra liga).

Cuesta imaginar un efecto real de la no existencia de MySQL: quizás eso quiera decir que pese a que PHP haya caído antes, quizás éste haya sido más instrumental y relevante en el mundo real. MySQL simplemente ofrecía “funciona en Windows y no hay otro popular” (lo de la velocidad son historias); PHP era “tu web, ahora y sin complicaciones”. Uno pensaría también que los deméritos de PHP son menores que los de MySQL: pese a que ambos son sucios y volátiles, opino que PHP es más sucio que volátil, mientras que MySQL es más volátil que sucio… y en informática, lo sucio es doloroso pero inevitable, mientras que lo volátil puede causar daños corporales permanentes.

(correcciones, ediciones y sugerencias del de siempre)

Me he abierto un Tumblr en koalillo.tumblr.com. Sustituirá a mi uso de Google Plus para compartir cosas cortas (principalmente del Google Reader). Crosspostea a mi @koalillo, Facebook y el lateral de este blog.

Si estáis hasta las narices de que no podáis usar el botón de la ruedecita para abrir ofertas de trabajo en una ventana nueva en infojobs.net, el siguiente script de Greasemonkey os puede ser útil:

// ==UserScript==
// @name       Open in new tab in Infojobs
// @namespace  http://use.i.E.your.homepage/
// @version    0.1
// @description  enter something useful
// @include    http://www.infojobs.net/jobsearch/search-results/list.xhtml
// @include    https://www.infojobs.net/jobsearch/search-results/list.xhtml
// @copyright  2011+, You
// ==/UserScript==

window.setInterval(function() {
    unsafeWindow.jQuery("[id^='table_results_offer']").each(function() { this.onclick = null; })
}, 1000);

Yo lo uso en Chrome con Tampermonkey. Es cutre y nada correcto, pero funciona.

actualización: pongo la URL https:// en el @include para que también funcione si te has identificado en Infojobs.

Google ha sacado hoy Dart.

El apunte rápido (que seguro que otros mejoran) es que es un verdadero Javascript. Es un lenguaje muy muy Java que compila a Javascript. Las diferencias con Java van por dos lados:

• Adecuaciones para funcionar bien cuando se compila a Javascript- i.e. no hay threads, hay “isolates”, etc.
• Esas mejoras puntuales de Java que llevamos pidiendo a gritos desde hace siglos

Las mejoras de Java son de ovación cerrada:

• Las clases en Dart generan un interfaz equivalente a su parte pública
• Constructores con inicializadores concisos
• Declaraciones anónimas y concisas de funciones
• getters y setters transparentes. De bonus, se integran con los interfaces
• Literales para listas y mapas
• “==” es equals y “===” es “==”. Ver “===” me produce grima por traumas varios, pero creo que es la solución correcta.

Tras más de 300.000 entradas de RSS leídas, he decidido migrar mis datos de Google Reader de @gmail.com a mi cuenta de Google Apps.

A parte de sacrificar tan bonito número y perder un buen montón de datos, migrar las estrellas y elementos compartidos es duro (2500+ pulsaciones de shift+s, k lo atestiguan).

En los inicios, había muy poquitos ordenadores- grandes como habitaciones e increíblemente caros. Muchos de estos ordenadores tenían múltiples pantallas y teclados para que los pudiesen utilizar simultáneamente muchas personas y que se rentabilizasen mejor. Cada ordenador era un mundo en sí mismo. Algunos de estos ordenadores permitían la comunicación entre personas sentadas en diferentes terminales.

Pronto, comenzaron a aparecer más y más ordenadores en el mundo. Algunos entes privilegiados podían disponer de varios ordenadores, y pronto surgió la necesidad de comunicarlos ente ellos; la capacidad de una máquina siempre nos es insuficiente y queremos realizar operaciones que aprovechen la capacidad de varios ordenadores.

Éste es un problema de fácil solución; los ordenadores trabajan con impulsos eléctricos y con compartir un medio conductor (léase, un hilo de cobre conectado a dos ordenadores), estos pueden enviarse datos codificándolos como descargas eléctricas de una manera muy similar a como funciona un solo ordenador internamente.

Este sistema ha funcionado perfectamente hasta el día de hoy- con no tantas evoluciones, existen hoy infinidad de redes con cientos de ordenadores comunicados a grandes velocidades entre sí mediante lo que es en esencia un hilo de cobre que pasa por todos ellos.

El análogo humano es una habitación llena de personas hablando a viva voz. Todo el mundo puede oír a todo el mundo y se pueden realizar todo tipo de conversaciones- un profesor puede dar clase a cientos de alumnos que le escuchan; un montón de parejas pueden estar en una sala de baile hablando entre ellas y grupos de conversación pueden formarse y deshacerse fácilmente.

Este esquema sencillo, lamentablemente, no funciona bien a gran escala. Intuitivamente vemos que compartir un solo cable de cobre entre una gran cantidad de ordenadores puede ser problemático. Nuestra sala con gente hablando deja de funcionar cuando las distancias son suficientes como para no oir- y si hay demasiada gente hablando, nace la confusión.

Los genios de ARPANET no se aturullaron delante de estos problemas y encontraron una solución simple y efectiva para este problema. Las redes locales de unos cuantos ordenadores funcionan maravillosamente bien, dijeron; no hace falta abandonar ni complicar este modelo. Sencillamente, interconectemos las redes entre sí.

Las comunicaciones locales pueden funcionar como hasta ahora. Lo único que tenemos que hacer es introducir unos dispositivos que tengan un pie en una red, y otro pie en otra. Cuando un ordenador en una red quiera comunicarse con otro ordenador en otra red, se dirigirá al dispositivo de su red que se comunica con otras redes y le entregará la información que quiere transmitir. Si el destinatario está en la otra red, el dispositivo no tiene más que entregárselo. Si no, lo único que tiene que buscar es otro dispositivo de este tipo que esté conectado con otra red que esté más cerca del destinatario y entregarle la información- así la información irá saltando de red en red hasta llegar a su destino.

Esto, en esencia, es internet. El “inter” es de interconexión de redes. El modelo se completa con un sistema de direcciones universales, las famosas IP con las que se identifica a cada dispositivo que vive en Internet- y el sistema de puertos, que identifica en cada dispositivo varios puntos de envío y recepción de datos (un puerto para el correo electrónico, un puerto para el tráfico web, etc.). Encima de esto, el sistema DNS que hace que los humanos podamos usar nombres en vez de IPs numéricas para referirnos a los dispositivos que viven en Internet y los diferentes protocolos que rigen los diferentes servicios que funcionan sobre internet.

Pese a que internet y su ecosistema asociado es infinitamente complejo, la gran virtud es que se basa en un modelo sencillo y elegante- simples redes locales interconectadas.

Próximas entregas:

• Hazañas informáticas II: el modelo de datos relacional
• Hazañas informáticas III: La criptografía asimétrica
• Hazañas informáticas IV: Las funciones hash
• Hazañas informáticas V: Las máquinas de Turing y Von Neumann
• Hazañas informáticas VI: el sistema UNIX

Me hallo en la enésima reorganización de mi preciado correo electrónico. Nada, abrirme un Google Apps Standard bajo un dominio propio mío, para poder gozar de algunas de las cosas de Google Apps (¿cuáles? No estoy seguro). Por supuesto, estoy aprovechando para reclasificar y agrupar correo, de manera que todos los preciosos mensajes estén almacenados centralizadamente (y duplicados).

Para ello, estoy recogiendo el correo de todas mis cuentas de correo activas- que sin incluir una o dos direcciones que desaparecieron en el olvido, son:

• La cuenta de correo de mi universidad, de la cuál no soy alumno desde hace más de 5 años, pero ahí sigue abierta
• Mi cuenta personal, alex-arroba-corcoles-punto-net, en un alojamiento familiar compartido
• Mi cuenta “secundaria” en fastmail.fm, que recién fueron comprados por Opera y siguen siendo uno de los pocos proveedores que dan cuentas IMAP gratuitas- si no podéis usar GMail por algún motivo o queréis una cuenta IMAP menos especial, los recomiendo
• Mi cuenta en mi compañía de móvil- la cuál prometía push al móvil, pero que nunca he conseguido hacer funcionar
• Mi cuenta de GMail, que utilizo para muchos servicios de Google, pero curiosamente uso relativamente poco para correo (en realidad, tenía mi cuenta de correo personal redirigida a GMail como archivo y para usar GMail de webmail donde no tengo Thunderbird)
• Una cuenta alternativa de GMail

Es interesante comprobar cosas como que apostar por IMAP desde el principio fue complicado, pero me ha permitido conservar correo casi sin esfuerzo- he recuperado correo hasta del 99, unos 11.000 mensajes de correo totalizando 685 megas (63kb por email). Lamentablemente, he podido cuantificar bastante correo enviado perdido- sólo conservo 2400 correos escritos por mi mismo. Los números están aquí, pequeña gráfica:

Puede apreciarse que, tras conseguir mi cuenta de Gmail (el 15/4/2004)… conservo bastante más correo y recibo más correo, in crescendo hasta hoy donde estoy de media en 6 emails diarios. En cambio desde 2004, parece ser que escribo menos; de 1,2 al día en 2004 hasta 0,8 en 2010.