Mostrando entradas con la etiqueta bala de plata. Mostrar todas las entradas
Mostrando entradas con la etiqueta bala de plata. Mostrar todas las entradas

jueves, septiembre 06, 2007

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

lunes, junio 25, 2007

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

martes, marzo 13, 2007

POO, el código como diseño, y más cosas



POO, el código como diseño, y más cosas en Barrapunto

jueves, diciembre 14, 2006

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

lunes, noviembre 13, 2006

Enlaces varios (IV)

En la linea de cantidad sobre calidad, ración de enlaces apresurados:
La misma entrada en BP