A esto me refiero cuando digo que la ignorancia sólo sabe perpetuarse.

Viñeta creada por MEL, al que llegamos gracias a este post de Magonia.

“Más recuerdos tengo yo solo que los que habrán tenido todos los hombres desde que el mundo es mundo”

– Jorge Luis Borges, “Funes el Memorioso”

Ya no existe el olvido, y eso es algo que los políticos van a tener que empezar a entender.

Lo que hace la UDI es patético, realmente patético en estos tiempos.

Borrar un contenido de su sitio porque los puede comprometer en este momento en que las farmacias son los malos de la película.

Lo he dicho antes, no te puedes arrepentir de lo que dejaste registrado, y es mejor asumirlo.

La red es como Funes, el memorioso, el personaje del famoso cuento de Jorge Luis Borges, quien, en una curiosa sincronía, es recordado esta semana por Saramago:

[Funes] aquel hombre dotado de una memoria que lo absorbía todo, todo lo registraba, hechos, imágenes, lecturas, sensaciones, la luz de un amanecer, una onda de agua en la superficie de un lago…

La red, sufre de la maldición de Funes, no olvida, pero eso que es una maldición para un hombre, es una característica esencial de la red, y a veces, eso es bueno, sobretodo para la democracia.

Así que, si eres político, ten cuidado con lo que publicas en la red, no vaya a ser que te funes.

;)

Hoy es el día de Ada Lovelace, una iniciativa que busca destacar el rol de las mujeres en tecnología, y tal como nos habiamos comprometido, acá va mi aporte a esta conmemoración.

Ada Lovelace fue la primera programadora, hoy podrán leer mucho sobre esta extraordinaria mujer, su contribución, en la historia, y sobre muchas mujeres importantes en nuestro campo, como Grace Hopper, o Adele Goldberg, o Bárbara Liskov los invito a leer sobre ellas.

Actualmente trabajo en una empresa donde la presencia femenina en tecnología es importante, pero no siempre ha sido así, la presencia femenina de todas maneras ha ido aumentando en nuestro campo, afortunadamente.

En este primer año del Día de Ada Lovelace, creo oportuno partir con un pequeño homenaje, a una de mis maestras, del departamento de computación, de la Universidad de Chile, María Cecilia Rivara.

Maria Cecila es una de las investigadoras de alto nivel en su área, pero la recuerdo porque nos motivo a interesarnos en la computación gráfica, a fines de los ochenta, y principios de los noventa, con sus videos de SIGGRAPH, donde pudimo ver unos innovadoras animaciones, de quienes serian los reyes de este campo, como la gente de Pixar.

Pero sobretodo, era una profesora dedicada del bienestar de sus alumnos, la recuerdo especialmente, porque era directora del departamento, cuando estudié, y me ayudo y orientó en algunos momentos de mi faceta de estudiante. Al final, uno recuerda más a sus maestros por su calidad humana, más que por los conocimientos que te transmiten.

Un saludo para Maria Cecilia, y en ella a todas las colegas con las que trabajo, y con que las que he trabajado, disculpen que publique tan tarde, pero este es el primer año, esperemos que el próximo podamos tener a más gente participando de esta actividad.

¿Y ustedes, a quienes homenajearian en el día de Ada Lovelace ?

OK, hemos hablado de las APIs, sobre lo que no son, pero no mucho sobre lo qué son realmente, y que importancia tienen en el desarrollo de software.

Y para que no digan que sólo nos dedicamos a criticar, vamos a aportar con algunas ideas sobre como escribir una API.

Antes de seguir, debo decir que para mi, las interfaces REST, o las API en el contexto de la Web 2.0, es decir, las APIque permiten hacer Mashups, por ejemplo, no son estrictamente una API, pero esta distinción es más bien semántica.

Pero, eso no importa mucho. Lo que sigue sirve para las APIs más tradicionales, y también para las APIs púbicas en el contexto de aplicaciones en la nube.

La GUI es para el usuario, la API es para el programador.

Tal como nos preocupamos de la interfaz de usuario, cuando diseñamos una aplicación, de modo que esta sea “usable”, del mismo modo, si queremos que este sistema pueda expandir su funcionalidad, por parte de terceros, o si queremos que estos tengan acceso a sus servicios, entonces debemos proveer de una Interfaz para los programadores, también.

Si usted se dedica a ese esotérico arte del feng shui de la arquitectura de información, creo que va a entender la importancia del punto anterior. Una buena interfaz de usuario, es aquella que le facilita la interacción con el sistema al usuario. Del mismo modo, una buena API, es aquella que le facilita la labor al programador.

Entonces cuando diseñamos una API tenemos que ponernos desde la perspectiva del programador. De la persona que quiere usar nuestra API para extender las funcionalidades de nuestra aplicación, o quiere aprovechar los servicios de nuestra aplicación, pero para integrarlos en su propia aplicación o servicio.

¿Cuáles son los principios de diseño de una buena API?

La referencia, obligada en estos tiempos, es esta presentación de Joshua Bloch, ingeniero d

e Google, quien nos presenta muy buenos principios de diseño de interfaces de programación.

Lo que sigue es más o menos un resumen de su charla, con algo de mi cosecha.

¿Estás seguro que quieres diseñar una API?

Antes de empezar, hay que tener en cuenta que es muy importante diseñar bien nuestras APIs, por lo siguiente:

• Las APIs terminan siendo uno de los activos más importantes para la compañía.
• Los clientes invertirán fuertemente ya sea comprando tu API, escribiendo código para esta y aprendiéndo a usarla.
• Con el tiempo, el costo de dejar de usar una API se puede volver prohibitivo.
• Las APIs exitosas capturan clientes
• Una mala API resulta en una sobrecarga del área de soporte externo
• Las APIs públicas son para siempre, así que tienes sólo una oportunidad de hacerlas bien.
• Las APIs terminan convirtiéndose en uno de los grandes pasivos de la compañía.

No es que quiera asustarlos, publicar una API es una decisión que debe ser bien pensada.

Las características de una buena API

Bloch resume muy bien las característica de una buena API:

• Debe ser fácil de aprender
• Debe ser fácil de usar, incluso sin documentación
• Debe ser dificil usarla mal
• El código que la use debe ser fácil de leer y mantener
• Debe ser suficientemente poderosa para satisfacer los requerimientos
• Fácil de extender
• Apropiada para la audiencia

El proceso de diseñar una API

¿Cómo procedemos a diseñar una API?

Primero, como siempre, hay que capturar los requerimientos, siempre con un alto grado de excepticismo ;). Recuerda, que siempre pueden haber mejores soluciones. Acá es importante elaborar buenos casos de uso.

Segundo, escribir una especificación, ojalá muy breve, una página es lo ideal. Es bueno mostrar esta especificación al máximo posible de personas. Mantener una especificación corta permite modificarla fácilmente, tras el feedback de las personas que revisan tu especificación. Es importante ir ganando confianza con la especificación, y en este punto es bueno escribir algo de código, que use la API, desarrollar casos de prueba, es importante ser lo más ágil en este punto.

Tercero, hay que tener las expectativas claras. No se puede agradar a todo el mundo, y por lo mismo, tienes que aceptar que es muy probable que tu API termine desagradando a todo el mundo igualmente. Es seguro que vas a cometer errores, sólo los años terminarán borrando estos errores, así que debes pensar que tu API evolucionará.

Principios generales de una buena API

1. Una API debería hacer una cosa, y hacerla bien. La funcionalidad de una API debe ser fácil de explicar.
2. Una API debe ser lo más pequeña posible, pero no demasiado
3. La implementación no debería impactar a una API. Los detalles de implementación confunden al usuario de una API, y por supuesto impiden la libertad de cambiar la implementación. Hay que tener cuidado de sobre especificar el comportamiento de los métodos de una API. Todo parámetro que se fije para sintonizar el desempeño de una API es sospechoso.
4. Minimizar la accesibilidad de todo, que es otra forma de plantear el viejo principio de ocultamiento de la información. Recuerden a Parnas, alta cohesión, pero bajo acoplamiento.
5. Los nombres importan, la API es un pequeño lenguaje. Los nombres deben ser, en gran medida, auto explicativos. Es importante ser coherente, las mismas palabras deben ser usadas en toda la API.
6. La documentación es importante. Como dice Parnas, la reutilización requiere de un buen diseño una buena documentación.
7. Considere las consecuencias en el desempeño de las decisiones de diseño de una API. Un buen diseño, normalmente coincide con un buen desempeño.
8. Las APIs deben coexistir pacificamente con la plataforma. Es bueno obedecer las convenciones de nombres de la plataforma. También es recomendable imitar las convenciones de los lenguajes en que implementamos la API (con la excepción de PHP, por supuesto).

Otros aspectos a considerar:

• No violar el principio del mínimo estupor. El usuario de una API no debe quedar sorprendido por el comportamiento de esta.
• Falla rápido. Ya hemos h ablado de esto, las malas noticias es mejor decirlas pronto, es decir, hay que reportar los errores tan pronto ocurran.
• Cuidado con sobrecargar. Hay que tener cuidado cuando sobrecargamos el nombre de un método, sobretodo, hay que evitar las ambiguedades.
• Si no eres programador, pide ayuda a un programador para diseñar una API pública. Recuerda que las APIs son interfaces para ellos, y no se diseñan igual que las interfaces de usuario.
• El diseño de API no debe ser un trabajo de una sóla persona, aunque escribir las especificaciones, y las ideas pueden ser de una persona, es bueno que te asesores por terceros, y que pruebes con una amplia base de usuarios.

Los chistes gráficos son cortesía de Geek and Poke.

iempre que veo los hermosos productos Apple, hay una parte de mi, que prudentemente me recuerda que no es bueno comprar esos productos, y se me pasa.

(imagen tomada degeek and poke)

Christofer Hoff reclama si alguien ha redefinido los términos “abierto” e “interoperable”, sin avisarle, a propósito de la siguiente afirmación:

Singing the vcloud API standard song is very astute. It reassures all people already on board and climbing on board the VMware bandwagon that VMware is open and not looking to lock them in. Even if Microsoft doesn’t join in this standardisation effort with a whole heart, it doesn’t matter so long as VMware gets enough critical mass.

Cantar la canción del estándar de la API vcloud es muy astuto. Tranquiliza a todos los que están a bordo del vagón de VMware porque VMWare es abierto, y no está buscando encerrarlos. Aún si Microsoft no se une a este esfuerzo de estandarización con todo su corazón, no importa en cuanto VM Ware obtenga suficiente masa crítica.

¡Cómo puedes afirmar que usar la API de VMWare es no cerrarse en VMWare como proveedor (*)!

Standards are great, especially when they’re yours

– Cristofer Hoff

Hoff nuevamente:

When a vendor like VMware crafts an architecture, creates a technology platform, defines an API, gets providers to subscribe to offering it as a service and does so with the full knowledge that it REQUIRES their platform to really function, and THEN calls it “open” and “interoperable,” because an API exists, it is intellectually dishonest and about as transparent as saran wrap to call that a “standard” to imply it is available regardless of platform.

Cuando un proveedor crea una tecnología, define una API, y ofrece un servicio que REQUIERE de su plataforma para realmente operar, y luego llama abierto, e interoperable, a todo esto, sólo porque existe una API, es intelectualmente deshonesto, y poco transparente.

Ese es un caso. En estos momentos, en que se está desarrollando la industria de la nube, que no es otra cosa, que llevar a la práctica viejas ideas, que no contaban con el soporte adecuado para implementarlas, es claro que hay muchas intenciones de volverse en el principal monopolista de este negocio.

Lo que hace entonces una empresa como VMWare es vendernos una píldora roja de apertura, e interoperabilidad, cuando en realidad nos entrega una píldora azul, y lo que quiere es establecerse como el principal monopolista de este nuevo negocio.

Yo creo que VMWare quiere ser el CISCO de la nube, al final, toda la infraestructura es sostenida por él, y los demás terminan quedando atrapados en su “estándar abierto”.

¿Qué es una API?

Las API no son estándares abiertos, no son parte de los principios del código abierto. Las API no son neutrales tecnológicamente. Porque las API son herramientas, nada más.

Veamos el caso del estándar abierto IEEE 1003, conocido como POSIX (nombre sugerido por Richard Stallman).

POSIX es un estándar, que define una API, junto con un conjunto de utilitarios, e interfaces de usuario para todo software que quiera ser compatible con Unix.

La primera versión fue publicada en 1988. Uno de los grandes esfuerzos por lograr una manera unificada de interactuar con las diferentes varianes de Unix que competían en aquel tiempo. Comercialmente a todos los sistemas operativos que implementaban POSIX se les empezó a llamar sistemas operativos abiertos.

Una de las cosas interesantes, es que hasta Microsoft Windows puede configurarse para ser compatible con POSIX.

Mmm, van a pensar ustedes, si Windows es compatible con POSIX, entonces ¿Eduardo, estás insinuando que Microsoft Windows es un sistema operativo abierto?

Ese es mi punto, ¿qué significa ser abierto? ¿de qué estamos hablando?

POSIX es un estándar abierto, porque nace de un organismo neutral, como la IEEE, que pone en la mesa a todos los participantes de la industria en ese momento, y posteriormente se unen a este estándar, o deciden adaptarlo a su sistema, terceros, como Microsoft. Adoptar un estándar abierto, es algo bueno, pero en otro sentido, no hace que tu producto sea abierto.

Por otro lado, muchos proveedores de código cerrado, propietario (o privativo), entregan, o publican APIs. La famosa API de Windows, es el ejemplo clásico. Es lo mismo que está pasando con la API de VMWare.

Gracias a la API de Windows, publicada en los años 80 y 90, los programadores podíamos construir aplicaciones para Windows 3.11, NT, y XP. Microsoft garantizaba cierto nivel de compatibilidad de la API entre una versión y otra. Pero, podía, arbitrariamente por supuesto, eliminar ciertas funcionalidades de la API, porque son ellos los que contralan la API de Windows.

Esto generó mucha controversia. De hecho, siempre se ha criticado a Microsoft, porque productos como Office, tienen acceso a partes indocumentadas de esta API, lo que constituye un factor de competencia desleal con otros proveedores de aplicaciones para Windows.

Como verán, el hecho de que un proveedor de servicios, o aplicaciones, publique una API no garantiza que la mantendrá en el futuro. Al contrario, puede mejorar su posición y limitar el desarrollo de aplicaciones, porque publicará lo que le convenga, y se guardará aquellas porciones de funcionalidad que le permitan desarrollar un mejor servicio.

El tener el servicio, o acceso a la API de Facebook, o de Twitter, es bueno, y permite desarrollar un rico ecosistema de aplicaciones, pero que se ven limitadas por la flexibilidad, o ganas del proveedor de la API de brindar ciertos recursos.

(fuente de la imagen)

Por ejemplo, tenemos una gran brecha de seguridad en Twitter, producto de la manera en que está diseñada su API, y esta empresa se ha demorado en arreglar este problema, aún existiendo soluciones hace tiempo: OAuth.

El caso de OAuth es interesante. Esta es una API, abierta, que nació para solucionar un problema de un servicio, twitter, pero que puede ser aplicada en cualquier otro servicio. Al nacer desde una institución neutral, permite asegurar que nadie intente cerrarla, o limitarla posteriormente. Pero, cuando Twitter adopte OAuth, deberá modificar su actual API para que opere correctamente, y de paso cerrar los problemas de seguridad que hoy presenta. Hacer esto provocará que muchos servicios de terceros tengan que ser reescritos, para adaptarse a este nuevo estándar. Eso es costoso.

Publicar una API no es fácil, porque siempre se te queda algo en el tintero, y empiezan los problemas de compatibilidad hacia atrás, las brechas de seguridad, que hay que cerrar,

etc.

Ahora tenemos una proliferación de APIs, pero eso no hace que los servicios que publican APIs sean más abiertos. Las APIs del New York Times son grandiosas, pero son propietarias. Podrían cambiar en cualquier momento, o dejar de ser publicadas.

El que publica una API está en un dilema.

Los estándares son grandiosos, en especial cuando son tuyos, porque los puedes cambiar, limitar, en cualquier momen to. Pero hay casos en que es más facil controlar el estándar, que en otros.

En la web, si publicas una API, debes considerar que cuando seas exitoso, eventualmente tendrás que renunciar al contro de tu API.

Quizás por lo mismo, el creador de un servicio tenga que pensarlo mejor.

Los estándares surgen cuando una herramienta establecida, se hace tan vital para la comunidad, que ya no puede seguir en control del que la creó por primera vez. Una API abierta, es para el proveedor una renuncia a su anterior monopolio, una renuncia al control que alguna vez tuvo de la información, o de su servicio. Es por eso que Dios no quiere estándares :)

La apertura se va dando, no porque la gente publica sus API, es una consecuencia de esto. Pero el que publica una API no está pensando, necesariamente en los principios de apertura, como se entiende en el código abierto. Hay muchos que publican, y controlan sus API férreamente, y cuando se produce la presión de los clientes, por controlar ellos la API, deciden dar vuelta atrás, o congelar, la API, dejar de soportarla, o simplemente reinventar las reglas del juego (se me ocurre el caso de Microsoft.Net).

Entonces, no hay que confundir las causas con las consecuencias.

El código abierto nace porque no es suficiente con contar con las APIs, el código abierto es una postura más radical que la estandarización, la que habla de interoperabilidad e interfaces, el código abierto exige conocer la implementación. Porque el usuario, necesita más poder, del que le das con la API.

Siempre he dicho que lo que importa es definir las interfaces, y los niveles de servicio, y no necesitas conocer la implementación, como dicta el opensource o más radicalmente, el software libre. Da lo mismo cómo se implementa una API, si con software propietario, o con código abierto.

La proliferación de APIs no significa el triunfo del código abierto, ni nada de eso. A menos que estemos hablando de otra cosa, por eso que vuelvo a preguntar, ¿de qué estamos hablando entonces?. Al igual que Hoff, me pregunto si alguien cambió la definición de estos términos y nadie nos avisó.

(*) En el sentido del vendor lock-in.

Leo en un apunte de Micronauta la afirmación: “el triunfo total del código abierto, una tendencia en la cual la liberación de APIs que estamos observando por estos días es un eslabón fundamental.”. Esta frase es el resumen de un texto en inglés que dice:

Open Source wins. Open Source solutions and platforms will push proprietary systems to the brink simply because of the rate at which they adapt to change and innovation. Pay attention to the Big Media attempt to monetize this Open Source principle through the proliferation of news APIs, but don’t expect it to succeed unless these APIs give developers and end-users more freedom.

¿De qué estamos hablando acá?

Hay varias confusiones en estas afirmaciones.

Primero, las API, que son algo viejisimo, no hay nada innovador en este concepto, el hecho de que los usuarios periodistas las hayan descubierto hace poco, no las hace innovadoras.

Segundo, ¡las API nacieron precisamente para esconder el código, no para hacerlo abierto!.

La frase “el código abierto va a triunfar”, es linda, y puede ser que llegue a suceder, pero eso no tiene que nada que ver con la proliferación de las API.

Eso es , dirían Les Luthiers, razonar fuera del recipiente.

Las API son mecanismos de abstracción, en que publicamos una interfaz que nos permite operar con un sistema, cuya implementación no nos interesa.

Por eso que podemos distribuir una biblioteca, o un sistema, sin necesidad de publicar su codigo fuente, bastando la publicación de su interfaz pública, una API.

Un caso famoso es la API de Windows, los programadores usaron la API de Windows para desarrollar aplicaciones, sin necesidad de contar con el código fuente de Windows.

Pero publicar una API, no es y no tiene nada que ver con el código abierto.

En España: “..El Ministerio de Cultura, favoreciendo intereses privados de los lobbies de presión de la industria cultural, ha forzado un acuerdo entre entidades de gestión y algunas operadoras de ADSL, la Redtel (Telefónica, Vodafone, Orange y Ono) para impedir el libre intercambio de información y el acceso democrático a la cultura, actualmente al alcance de todos los usuarios de la red. ”

Y cuando eso pase en Chile, ¿ustedes van a dejar que su ISP les filtre el contenido P2P para informarle a las disqueras, o peor a la SCD, si están bajando música o películas pirata? ¿Que vamos a hacer cuando un político conservador decida filtrar el contenido para adultos, o que critique las creencias religiosas de algunos? O ¿cuando nos pidan que para tener un blog tengamos que pasar por un control editorial, por parte de periodistas profesionales previamente acreditados?

La industria disquera está logrando lo que ni siquiera George Orwell pudo imaginar, el total espionaje de nuestras comunicaciones. Pero hay muchos más que están a la cola, y el Estado es uno de estos, quizas el mas interesado, en saber que hacen y opinan sus ciudadanos. El sueño totalitario logrado por la tecnologia al servicio de la industria del entretenimiento, ¡quien lo hubiera imaginado! Stallin es una alpargata.

¿Empezaremos solo a quejarnos cuando el proximo gobierno, el que salga ,le pague su apoyo en la campaña electoral a los artistas, sacándoles una ley ad hoc de protección de sus derechos, tal como Sarkozy lo hizo para proteger el trabajo discográfico de su esposa?