Sam Ruby y Erlang

Asisto con una mezcla de envidia y escepticismo a la conversión a Erlang de Sam Ruby. Sam Ruby es un típico goleor tecnológico ™ Siempre está a la última en cuanto a estándares y lenguajes sobre la web. De hecho, algunos los hace él :) Como buen experimentador de tecnología, como buen gurú, hace sus apuestas de futuro. La última apuesta de Ruby, muy interesante, es a varias bandas: REST, Hadoop, Erlang/OTP y los Microformatos.

Asisto con envidia sobre todo por la fase de enamoramiento compulsivo por la que está pasando (muy interesante para los demás, por cierto) con Erlang, aunque resulta extraña en alguien con tanta experiencia como él. Sino no se puede explicar que diga, en su última entrada, algo tan bonito como:

Con muchos frameworks y lenguajes, tengo la sensación de que estoy trabajando con un armario de metal con capas de pintura para barcos; cuando se le hace un rasguño salen a relucir los bordes afilados. Con Erlang tengo la sensación de un armario victoriano de caoba; cuando uno raya en la madera simplemente sale a relucir más valiosa madera.

Pero este enamoramiento nos está dando a los demás la posibilidad de seguir sus pasos y disfrutar de su código, que no está nada mal... El último paso ha sido un conversor de Atom a JSON, pero anteriormente ha hecho alguna cosita más, como envíar XHTML-IM sobre TLS con Erlang y una pequeña entrada sobre Comunicación entre procesos en Erlang. A ver si dura :)

Sam Ruby y Erlang en barrapunto

AMQP ¿El nuevo Middleware universal?

Según leo en Toward a Commodity Enterprise Middleware John O'Hara en JPMorgan, harto de "el problema del Middleware" se construyó (diseñó e implementó) el suyo propio para sus sistemas: AMQP (Advanced Message Queuing Protocol)

Se basa en el paso de mensajes y su gestión, permite mensajes del tipo publicación/suscripción, guardar y reenviar o envío de ficheros, separa la capa de trasporte de la de gestión de colas, tiene un protocolo binario que lo hace menos pesado en cómputo y ancho de banda que los Servicios Web y está preparado para pasar los firewalls sin perdida de seguridad. Suena bien.

Para no cometer uno de los errores de CORBA, existe ya más de una implementación, la de referencia: OpenAMQ, otra de Apache incubator, Apache Qpid, y una última en Erlang, RabbitMQ todas ellas software libre.

Al parecer la industria está entendiendo (por fin) que el modo de hacer tecnologías interoperables es haciendo implementaciones de referencia funcionales y libres, teniendo comunidad de usuarios (y no clientes) De todos modos habrá que ver si tiene una adopción tan masiva como pretenden. Lo debería ser si efectivamente el middleware se logra convertir (ojalá) en una Comoddity

(En El auge y la caída de CORBA (y lo que podemos aprender) se comentaba que existía ICE otro prometedor middleware libre, en este caso más parecido a CORBA, según parece)

AMQP ¿El nuevo Middleware universal? en barrapunto

¿Postel o Dracón?

La primera vez que leí sobre la ley de Postel: "Sé conservador con lo que envias, liberal con lo que recibes"(*) me pareció tan filosóficamente interesante que intenté escribir una entrada al respecto, pero no supe, porque no tengo el gen gurú necesario para ello. Por eso, no está mal recurrir a los gurús de verdad, que sean ellos los que digan parte de lo que le ronda a uno por la cabeza. El caso es que en una semana dos blogstars de esto de la programación y la tecnología han comentado algo relacionado, así que les cedo la palabra, claro (cada una de las entradas da mucho más de si, pero claro, para eso está enlazadas, para que se lean ;)):

• Jeff Atwood en Coding Horror habla de en "JavaScript and HTML: Forgiveness by Default" de como siendo tolerante a fallos se crea un ecosistema más robusto. En sus palabras: "el perdón por defecto es un requisito imprescindible para una adopción a gran escala tan masiva como la de la web". Eso si, no habla del precio que hay que pagar, porque una implementación tolerante a fallos, en general es más compleja. Hay que preguntarse ¿qué hacer con los errores?
• Sam Ruby en "Different Drummer" habla del diseño de HTML5 y se pregunta si ganarán los que siguen a Dracón o a Postel. Él se decanta por Postel, claro. El resto del post muy interesante también. Muy gurú. Muy Sam Ruby :)
  Por cierto que habla de Silverlight y dice que también es Draconiano. En eso no me voy a meter, le cedo la palabra a otro que sabe más que yo (no voy a llamarle gurú porque igual no le gusta): Yogur Griego: "Silverlight ¿el imperio contraataca?"
• Hablando de gurús y aunque no es nuevo, no me resisto a enlazar otra vez "Objects Have Failed" de Richard P. Gabriel debido a que uno de sus argumentos para la irrelevancia de los objetos es (exagerando creo, tiene algún recurso literario, quizás por eso me gusta más...):

  En el viejo mundo nos centrábamos en la eficiencia, la limitación de recursos, el rendimiento, los programas monolíticos, los sistemas aislados, los programas hechos por un sólo autor y las aproximaciones matemáticas. En el nuevo mundo pasarán a primer plano la robustez, la flexibilidad, la adaptación, los sistemas distribuidos, los programas de múltiples autores y las metáforas biológicas de la computación.

(*)Otras veces nombrado como "Sé conservador con lo que haces, liberal con lo que aceptas de otros". El enunciado es susceptible de ser políticamente interpretable más aún en esta segunda encarnación del principio. En este caso yo creo que es más bien interpretable desde el punto de vista de la ética. Como referencia se puede leer lo que dice Tim Berners-Lee acerca de esto y de una frase (que fué durante un tiempo firma mía) acerca del funcionamiento descentralizado "We have no kings or presidents. We believe in rough consensus and running code". Eso si, con grandes influencias de Unitarismo universalista, una religión más o menos buenrollista, si es que eso es posible...

"¿Postel o Dracón?" en barrapunto

Una herramienta, no una religión

Entrada interesante en Adding Simplicity - An Engineering Mantra, It's a Tool, Not a Religion!. Traduciendo muy libremente:

Recientemente he estado asistiendo al debate de REST contra SOA. La última semana me vi envuelto en discusiones de C++ contra Java. Esta noche pasada me tropecé con algunos debates sobre Django contra Rails. Me parece que los ingenieros de software somos únicos en el mundo técnico: más que disfrutar con una caja de herramientas variada, discutimos contra su contenido, esperando descartar todas excepto el conjunto más pequeño posible.

[...]

¿Porque debemos trabajar tanto en reducir nuestro conjunto de herramientas hasta la herramienta definitiva? Hay una tendencia a buscar el lenguaje Navaja suiza apoyado por un framework que será la solución óptima para todos los problemas del mundo. La simple realidad es que ese lenguaje o framework no existe. ¿Por qué? Bueno, la solución de problemas informáticos es siempre acerca de adoptar compromisos que optimicen la solución en determinadas condiciones. Si tu problema cumple esas condiciones, perfecto. Si no, estarás usando una herramienta subóptima.

[...]

Es importante tener opciones para resolver los problemas de cada día. Entender las herramientas y su aplicabilidad a un problema dado debería ser nuestro trabajo

En resumen, en lugar de criticar herramientas, aprende su ámbito de aplicación...

La misma entrada en BP