domingo, septiembre 14, 2008

¿Lego como herramienta de gestión ágil?

domingo, septiembre 14, 2008 por Martín

Hoy, repasando lecturas pendientes me he topado con una entrada muy interesante en la que probablemente es hoy por hoy mi fuente favorita de información, InfoQ. Se trata del artículo Lego is not for kids anymore en el que comentan posts de otras personas que han encontrado en Lego una forma efectiva de gestionar su tiempo y proyectos.

Comienzan con un artículo de Michael Hunger en el que habla de como ha cambiado su forma de trabajar utilizando bloques de lego. Y de manera muy interesante. En la figura de abajo se ven cinco bloques de piezas, cada uno para los diferentes días de la semana. En cada bloque hay piezas de diferentes colores representando los diferentes proyectos y finalmente hacia arriba representaría el tiempo. ¡Realmente visual!



Por otra parte Takeshi Kakeda presentaba en la conferencia Agile 2008 una presentación acerca de como utilizar bloques de lego para la gestión de proyectos y que han subido a SlideShare.

La verdad es que no sé si estoy realmente pecando de iluso pero me ha parecido que presenta ideas muy refrescantes. La propuesta sería comenzar con una base, que prácticamente vendría a sustituir a una pizarra con postits pero añadiendo alguna dimensión más. Las siguientes son algunas de las reglas, bastante simples por cierto:

- Bloques más grandes representan bugs o issues más complicados.


- A más cerca del frente, más prioridad.


- Las fichas llevan notas con pequeña explicación o referencia a la herramienta de gestión de incidencias.

- Las dependencias se representan colocando piezas unas enfrente de otras.

Durante los últimos meses he tenido la oportunidad de disfrutar de la transparencia que te proporciona el trabajar utilizando metodologías ágiles, y personalmente creo que utilizar este sistema sería también beneficioso ya que parece muy sencillo de gestionar y mantener, añade un toque divertido a la organización, y sobretodo ofrece una visión muy sencilla de los proyectos que todo el mundo puede entender, desde el programador más junior hasta el jefe pelo-pincho.

Eso sí, supongo que habría que montar una base bien grande de piezas para cuidar un poco la imagen final del proyecto y que no esté todo apelotonado...



... y lo más importante, ¿cómo evitas que algún gamberrete se ponga a jugar con tu lego?


:-)

miércoles, septiembre 10, 2008

Los programadores de Linux y la obesidad

miércoles, septiembre 10, 2008 por Martín

No me puedo resistir. Visto el drástico aumento del tamaño de las camisetas de los asistentes al Linux Symposium podríamos estar ante una epidemia de obesidad :)



Via TechCrunch.

martes, septiembre 09, 2008

Un pequeño problema informático de esos que valen millones

martes, septiembre 09, 2008 por Martín


Hoy me voya desviar un poco de la temática habitual, aunque me mantendré de cierto modo dentro del mundo del software. Una de mis aficiones es la economía. Me encanta seguir los mercados, las noticias, las inversiones y todas estas cosas.

El Lunes fue uno de esos días emocionantes en las bolsas. Las empresas financieras americanas Freddie Mac y Fannie Mae se habían desplomado en la bolsa en la pasada sesión y el gobierno de los Estados Unidos había acudido a su salvación. El Lunes se esperaba una carrera de compras como no se había vivido en meses (o años). Aún así, no fue un día muy feliz en el London Stock Exchange ya que fueron incapaces de operar durante prácticamente toda la sesión.

En la prensa se comenta que la caida duró unas siete horas, y que muchos traders se vieron forzados a moverse a sistemas de la competencia para intentar operar. Wow, siete horas de inactividad en la bolsa valen miles de millones. Parece ser que todo se debió a un fallo informático dentro de un aplicativo llamado Infolect que es el sistema de envio de datos que utilizan.

En ZDNet tienen un artículo interesante que comenta más detalles sobre este sistema. Y en CIO comentan que es un sistema lanzado hace un par de años (no sé en donde leí que lo habían actualizado este verano) basado en .NET, SQL Server y desplegado en más de 100 servidores Proliant Intel 32 bits.

Parece que hace poco que LSE ha encontrado verdadera competencia en dos exchanges alternativos, Chi-X y Turquoise que se animaron a comentar el fallo y no dudaron en recomendar a todo el mundo migrar a sus redes más modernas y más baratas.

La verdad es que independientemente de si el fallo estaba en el software, en los servidores, en la red, en lo que sea, lo cierto es que este tipo de noticias son esas que leeremos en años en los libros ya que te demuestra como pequeños fallos, o sistemas no preparados para picos de carga enormes pueden generar perdidas millonarias al tiempo que impactan enormemente en la imagen de las compañías y proporcionan jugoas oportunidades a la competencia para captar a tus clientes.

A ver si algun publicación online nos desvela un poco más sobre este fallo.

lunes, septiembre 08, 2008

El Arquitecto de Software en versión española.

lunes, septiembre 08, 2008 por Martín

En muchos países europeos, US, Japón y otros, la figura de Arquitecto de Software está realmente valorada. Ser arquitecto de software es el paso natural para muchos desarrolladores senior, y requiere sobre todo experiencia y buenas capacidades de análisis, raciocionio y abstracción. Coding de Architecture es uno de los mejores blogs existentes sobre el trabajo de Arquitecto de Software y tiene varias entradas donde se define el scope de un arquitecto o el perfil que debería tener un arquitecto.

Entre las tareas de un Arquitecto de Software destacarían:

  • Definición de la arquitectura.

  • Selección del software.

  • Selección de la infraestructura.

  • Requisitos no funcionales.

  • Liderazgo.

  • Mentoring.

  • Metodología de los proyectos.

  • Proceso de desarrollo.

  • Prácticas y estándares.

  • Análisis de las tendencias en desarrollo de software.

  • Aporte de experiencia.

  • Participar en el desarrollo.



Esta lista está recogida en este fichero PDF y es probablemente el último de los puntos que he puesto el que causa más polémica, aunque bueno más o menos está aceptado que es un bueno que un arquitecto participe de alguna forma en el desarrollo, aunque el dedicar más del 30% de su tiempo a dichas tareas indicaría que hay algo que está iendo mal.

Viendo como trabajan las empresas en el extranjero y sobre todo el reconocimiento que se le tiene a arquitectos y desarrolladores senior, a uno no le deja de sorprender el encontrarse ofertas en España buscando Arquitectos de Software con experiencia de al menos un año programando en J2EE. O mismamente la siguiente lista de requisitos para un Arquitecto J2EE en Valencia:

Descripción de la oferta
Buscamos un arquitecto en las tecnologías Java/J2EE, para proyectos de primer orden y pioneros en el ámbito de desarrollo de software. El candidato seleccionado se responsabilizará de:
-Captura y análisis de requisitos técnicos y de negocio
- Análisis y diseño funcional y técnico de proyectos de desarrollo de software
- Definición y ejecución de planes de pruebas
- Desarrollo Java/J2EE
- Realización de la documentación técnica asociada al proyecto
- Impartición de formación a usuarios y técnicos implicados en el ámbito del proyecto


Es decir en este caso Arquitecto = consultor, business analyst, tester, programador, documentador y formador. En fin, que cualquier parecido con la realidad del mundo exterior a nuestro peculiar país es mera coincidencia. Aunque está claro que en muchas empresas sí se reconocen los puestos de desarrollador senior y arquitectos, lo cierto es que todavía son la mayoría las que desconocen completamente lo que es el mundo del desarrollo de software, sus perfiles, el trabajo que se debe realizar, los roles y responsabilidades, etc. El arquitecto de software no deja ser "el que controla" o "el que nos saca las castañas del fuego".

Así nos va.

miércoles, septiembre 03, 2008

97 cosas que todo Arquitecto de Software debería conocer

miércoles, septiembre 03, 2008 por Martín


Vuelta de vacaciones y tengo que reconocer que me ha costado volver a postear, y es que como leía hace poco un blogger constante necesita tener un ego suficientemente inflado para alimentar esa situación engañosa de creer que la gente necesita realmente leer lo que escribes y no podrá vivir sin ello, y al tiempo entrar en esa inercia de posteo que te permite postear frecuentemente pero que si la abandonas por un rato te será difícil recomenzar a postear.

En fin, que dicho esto voy a continuar inflando un poco más mi ego con una entrada más, que seguro que de todos modos alguno la encontrará interesante y que pasados unos meses siempre me sirven para repasar mis ideas sobre determinados temas.

El caso es que me he encontrado con una iniciativa verdaderamente interesante de O'Reilly, y que no sé si alguno la conocería ya pero que a mi me ha sorprendido gratamente. Se trata de la creación de un libro mediante un wiki comunitario en el que puede escribir cualquier persona siempre y cuando el moderador apruebe la entradas. El libro trata sobre un tema tan interesante como la arquitectura del software y se llama 39 things that every software architect should know.

El moderador que se encarga de seleccionar las entradas más valiosas es Richard Monson-Haefel. ¿Alguien se acuerda de él? Seguro que más de uno sí. Este hombre fue durante muchos años la cara de J2EE (cuando todavía se llamaba así) y escribió lo que claramente se pueden llamar biblias sobre los EJB. Que tiempos aquellos! Si hasta le había hecho una entrevista yo mismo en el 2004 (creo que el contenido no está accesible) y recuerdo bien que aunque fue amable en contestarme sólo me respondió la mitad de las preguntas dejándome bien claro que no tenía más tiempo que perder :-) Yo creo que esa entrevista le hizo replantearse las cosas y pocos meses después abandonó el mundo de Java para shock de la "comunidad".

Volviendo al tema, la idea de O'Reilly me parece realmente buena porque de esa manera muchos autores anónimos y no tan anónimos pueden compartir sus experiencias creando un libro que seguramente se convertirá en referencia de una u otra manera. En el foro que han preparado se puede ver como se pueden sugerir nuevos axiomas y también leer los comentarios sobre los existentes.

Las entradas que hay ahora mismo son realmente interesantes, y por comentar una, la más votada de todas (No pongas tu curriculum por encima de los requisitos) me ha recordado a un Arquitecto de Software con el que coincidí y que no dudaba recomendar el utilizar WebSphere MQ y Coherence para una determinada tarea porque le apetecía aprender esas tecnologías. No cabe lugar a duda de la validez de las tecnologías, pero en este caso estas tecnologías no se escogieron, para suerte para el bolsillo del cliente y para las personas que tendrían que lidiar con éstas y disgusto de esta persona en particular.

¿Algún axioma que echéis en falta en la lista?

lunes, agosto 11, 2008

Cerrado por vacaciones

lunes, agosto 11, 2008 por Martín

Aprovecho el mismo título que los amigos de Linking Paths utilizaban hace unos días para un post sobre las vacaciones para comentar que este blog no va a ser menos.

Me marcho un par de semanas así que desafortunadamente tendré que dejar este rinconcito un poco descuidado. Será por poco porque espero llegar con las pilas muy cargadas. Mi destino no es muy paradisíaco, y además parece que está lloviendo (vaya cruz), pero ya lo echo de menos.



Hasta dentro de dos semanas.

viernes, agosto 08, 2008

Usando Google (y Yahoo) como CDN para tu código JavaScript

viernes, agosto 08, 2008 por Martín


La número dos de las trece reglas para conseguir páginas web más rápidas (según Yahoo) es utilizar una CDN (Content Delivery Network). Ahora bien, las CDN cuestan dinero y quizás con nuestro modesto presupuesto no nos podamos permitir ningún gasto extra más.

Pues bien, en High Scalability publican un truco muy interesante, que básicamente consiste en utilizar el servicio gratuito de Google de hosting de librerías JavaScript. Se trata del proyecto AJAX Libraries API y hasta el momento alojan jQuery, jQuery UI, prototype, script.aculo.us, MooTools, y dojo.

Usar este servicio en nuestras páginas web es tan sencillo como referenciar a sus ficheros JavaScript:


<script src="http://ajax.googleapis.com/ajax/libs/prototype...
.../1.6.0.2/prototype.js"/>

Por su parte, Yahoo también ofrece hosting para su propia librería, YUI, como se muestra en este artículo.

El único problema que tendremos es que si el servicio de hosting de Yahoo o Google no son accesibles, por cualuier razón, nuestra librería no estará accesible, y por consiguiente es probable que nuestra aplicación no funcione. Aunque bueno, ya se sabe que aunque caerse se caen, su disponibilidad suele ser bastante alta, por lo que parece muy útil el ahorrarnos unas cuantas peticiones HTTP en nuestros servidores y pasárselas a los peces gordos:)

miércoles, agosto 06, 2008

Programación en parejas con Eclipse ECF

miércoles, agosto 06, 2008 por Martín


Tenía pendiente mencionar esto desde que lo leí hace unos días. Ferrán Rodenas escribía hace unos días sobre dos tesoros ocultos en Ganymede (la última release de Eclipse) que merece mucho la pena leer.

Sin duda, el me ha dejado impresionado es la nueva funcionalidad de ECF (Eclipse Communication Framework) para editar un fichero simultáneamente entre varias personas. Este screencast es realmente descriptivo, y la verdad es que parece realmente útil.

Muchas veces cuando tienes que explicar algo a alguien se vuelve realmente complicado, especialmente cuando esta persona no se puede sentar a tu lado y recorrer contigo el código, y no queda otro remedio que utilizar Skype o gchat para intentar explicar como funciona todo. Con este plugin, sigue siendo necesario algún mecanismo para hablar entre las dos personas, pero vaya la edición simultánea de ficheros es espectacular.

COBOL sobre ruedas

miércoles, agosto 06, 2008 por Martín

Hoy he visto un mensaje en una de las listas de correo a las que estoy suscrito y que no me resisto a publicar porque siempre está bien un poco de ironía. Creo que fue algo que alguien preparó para el April Fools de este año, así que ya tiene algo de tiempo pero seguro que más de uno le hace bastante gracia...



... y seguro que más de uno aprecia la ironía :)

Se trata de COBOL sobre ruedas.

viernes, agosto 01, 2008

jLibrary 1.2 ve por fin la luz: Historia de una release.

viernes, agosto 01, 2008 por Martín



Ayer, hemos lanzado por fin la versión 1.2 de jLibrary. El trabajo en jLibrary 1.2 empezó hace más o menos un año cuando Dani buscaba algo que hacer y nos pusimos a trabajar en crear una aplicación web. La aplicación web fue tomando forma poco a poco. Y lo que empezó como un simple frontend para mostrar los documentos que estaban almacenados en un repositorio de jLibrary, pues como suele pasar se le van añadiendo más y más y más cosas y terminó en toda una aplicación web para visualizar y editar documentos, su contenido, sus relaciones, y personalizable mediante templates. En fin, lo que se puede ver desde hace tiempo en la página de la demo.

La web poco a poco fue recibiendo carga y eso permitió sacar a relucir unos cuantros problemas en la gestión de sesiones y de memoria. Venga. Seamos transparentes. La web no duraba más de un par de días funcionando! Aunque lo cierto es que estabamos hablando de utilizarla con 128Mb de RAM, que hoy por hoy no es nada para un servidor. Pero no es escusa. Una vez solucionados esos problemillas, hubo que dedicarse a mejorar el sistema de seguridad. Lo bueno de crear una aplicación web de este estilo sobre una aplicación de escritorio es que saca a relucir casos de uso no existentes hasta el momento, como podía ser el disponer de una área pública para la publicación de documentos en la demo al tiempo que la sección de docuemntación de la demo seguía siendo privada e intocable. Como anécdota puedo contar que algún malvado consiguió evitar los chequeos de seguridad y borrar la documentación. Que mejor estímulo para arreglar algunos bugs!!

Después de todos los arreglos, la web ya funcionaba mucho mejor. Al principio como no estaba seguro después de los problemas de memoria, le llegué a dedicar 384Mb. A medida que fue madurando y madurando lo bajé a 256, 128 y 64Mb. Estuvo funcionando durante algún tiempo con 64Mb, pero al ampliar la memoria de mi servidor a 1Gb decidí darle 128Mb constantes para olvidarme un poco del tema. Y lo cierto es que parece que las optimizaciones funcionaron, porque normalmente nunca tengo que rearrancar el servidor de jLibrary salvo cuando mi proveedor tiene que reiniciar el servidor físico. Ahora mismo lleva casi un mes funcionando y ha servido unos 7000 documentos, 12000 downloads de ficheros y 20000 visualizaciones de directorios entre otros. Eso sí, la carga es super-modesta, y siempre está sobre las 10/20 sesiones concurrentes. No es demasiado, pero bueno, tampoco está mal para 128Mb.

Durante el camino se unieron al proyecto un par de desarrolladores polacos, Ryszard y Renata Perkovski, que por curiosamente se vienen a trabajar a Dublin, y que se dedicaron en pleno al interfaz de usuario. Añadieron mejoras en la usabilidad, integraron el editor XML de WTP, adaptaron y mejoraron la build de Maven para trabajar que fuera más sencilla (jLibrary creo que es uno de los pocos casos en los que se ha sido capaz de integrar Eclipse RCP con Maven) y lo más importante es que actualizaron todo a Eclipse 3.4. Ayer lo estuve probando, y la verdad es que el rendimiento y aspecto de la aplicación ha mejorado un montón con esta nueva versión de Eclipse. Usar Eclipse RCP tiene sus desventajas, pero también tiene muchas ventajas, siendo una de ellas que cada vez que hay versión nueva de Eclipse, es como si hubiese una versión nueva de tu aplicación :)

Aún así, allá por Marzo, empezé un nuevo proyecto totalmente diferente, que me ha tenido ocupado durante todos estos meses, por lo que jLibrary quedó un poco (bastante) de lado. Y era una pena porque esta nueva versión estaba listísima, sólo hacía falta ese empujoncito de un par de semanas para que viese la luz. Al final, allá por Mayo llegó una empresa rusa, Blandware que se interesó en el proyecto y empezó a aportar parches importantes, tanto en el servidor como en el cliente. Sin duda lo más importante que han aportado ha sido el migrar el soporte que ya existía de propiedades personalizadas en los documentos al UI, es decir que ya se pueden añadir propiedades personalizadas desde el propio interfaz de usuario. Como esta gente no paraba de mandarme parches, lo que es muy bueno, al final he decidido cederles el mando de jLibrary, y han sido ellos los que se han encargado de preparar y lanzar la release, así que justo es el reconocerles el mérito.

En fin, está es más o menos la historia de jLibrary 1.2. Mucho más detallada de lo que aparece en las release notes. El proyecto por lo que a mi respecta es ahora mismo muy maduro, y aunque por ahora no continuaré desarrollándolo, espero que Blandware tire del carro. Es muy posible de todos modos que en unos meses lo recupere, ya que tengo pendiente la tarea de probar a añadir Amazon S3 como sistema de almacenamiento y aprovechar eso para desarrollar una idea que tengo en mente y que sería muy interesante para alguna startup chula. ¿Alguien interesado y con tiempo libre por ahí? Porque quizás podríamos hablarlo :)

Por cierto, que el que quiera descargarse jLibrary, pues ya sabe: jLibrary.org.

jueves, julio 31, 2008

Portabilidad: Siguiendo la especificación

jueves, julio 31, 2008 por Martín

En Coding the Architecture abrieron un debate muy interesante hace unos días. Es ese tipo de debate en el que miras hacia atrás y ves inevitablemente como tu opinión ha ido cambiado con el tiempo, ya se hacia un lado o hacia el otro. Y es que al final, cada uno contará la historia como le haya ido en la feria.

Hace ocho años, era todo acerca de la portabilidad. Acerca de la especificación. La portabilidad era la gran baza de JEE, y cualquiera que se mantuviese dentro de los límites de la especificación estaba a salvo. ¡Qué gran consuelo cuando tecnologías como EJB 1.1 te garantizaban un camino amargo y tortuoso! Con el tiempo, el debate sobre portabilidad se ha aligerado mucho, y el no seguir la especificación es como el hombre del saco, que te asusta las primeras veces pero que cuando ves que funciona y no pasa nada, pues pierde toda su importancia.

En mi caso, como el de Simon Brown, mi opinión también ha ido cambiando con el tiempo. Pero un poco al contrario. Hace años yo era partidario de no seguir la especificación si llegabas a un punto en el que te estaba restringiendo demasiado. Todavía recuerdo discusiones airadas sobre este tema con amigos y compañeros de trabajo que opinaban justamente lo contrario. El tiempo me ha enseñado que no hay una verdad única respecto a este tema, y que como casi todo, realmente dependerá en el problema que tengas que solucionar, pero que si realmente decides apartarte de la especificación, este debe ser un factor como otro cualquiera que deberás balancear y sobre el que deberás ponderar riesgos y ventajas.

Por ejemplo, hace tiempo, trabajando en un proyecto me encontré con varias partes de una gran aplicación que utilizaban threads directamente para realizar ciertas operaciones. Estas operaciones incluían escrituras en base de datos o envio de mensajes entre otras cosas. ¡Herejía! ¡Uso de threads en managed-systems! El desarrollo había continuado adelante porque era rápido y porque nunca había pasado nada. Sin embargo, a medida que la carga del sistema aumentaba, se pudo observar que se empezaban a perder mensajes, que había transacciones que no se completaban o se hacía rollback de repente, y otro número de efectos insospechados.

El problema era que se habían apartado demasiado de la especificación, y los efectos eran inesperados. Es así de fácil. No estás en la especificación, no tienes garantía de nada. ¡Si es que a veces no la tienes ni cuando sigues la especificación! La solución en este caso fue aprovechar que el servidor implementaba la specificación commonj y devolver esos Threads al contexto que le pertenecían, el contenedor. Eso solucionó todos los problemas.

Ser consciente de que te pueden pasar estas cosas es algo importante a la hora de hacer la decisión de restringirte o no a la especificación. Otro factor muy importante que he podido ver con el tiempo es el negocio al que se dedique la compañía, y como se va a vender la aplicación que se está creando. Muchas compañías que facturan productos ofrecen soluciones basadas en plataformas comunes como Oracle, WebSphere, WebLogic, a la vez que ofrecen otras soluciones de bajo coste basadas en MySQL, PostgreSQL o JBoss. En este caso, es importante mantenerse lo más cerca posible de la especificación, ya que cualquier opción especial que utilizemos la tendremos que reimplementar tanto para la plataforma premium como para la Open Source.

Otro caso con el que me encontrado es con productos que están bajo un servidor de aplicaciones en contreto y necesitan ser migradas a otro para entrar en determinado sector. Un ejemplo típico sería el entrar en la banca donde en algunos sitios te exigirán IBM WebSphere como plataforma de despliegue.

En fin, que al final, como mencionan en los comentarios, es un balance entre los planes de futuro que haya en la aplicación en cuanto a portabilidad y los problemas que nos encontremos al desarrollar. Si existe la posibilidad de despligue en múltiples plataformas, entonces es mejor ir con cuidado; en caso contrario, siempre se puede quebrantar un poco más las normas, pero siempre siendo conscientes de las posibles consecuencias en cuanto a efectos inesperados.

lunes, julio 28, 2008

Cuil, ¿amenaza para Google?

lunes, julio 28, 2008 por Martín


Comentan en SiliconRepublic que Tom Costello, un irlandés graduado por el Trinity College, y su esposa ex-empleada de Google, acaban de lanzar hoy mismo un buscador que aparentemente es una amenaza real para Google. Se trata de Cuil cuya principal vaza para amenazar la hegemonía de Google es la de indexar el contenido de las páginas web y no sólo la lista de keywords.

Como destacan en la noticia de SiliconRepublic, Cuil no es el primero en intentar amenazar a Google. Wikia ya lo intentó a principios de año pero fracasó estrepitósamente, especialmente debido a todo el hype que se había creado en torno a este buscador. Ya que no es sólo que no funcionara bien, sino que la disponibilidad era irrisoria debido al masivo número de visitas que recibían. En eso parece que han estado listos los chicos de Cuil ya que al menos yo no me he enterado de que existía, y en caso de enterarme habría sido una muy mala señal porque a mi estas noticias me llegan más bien de rebote.

Bueno, el caso es que a pesar de haber hecho bien, parece que todavía tendrán que afinar un poquillo con las búsquedas. Puestos a buscar, porque no agrandar el ego de uno mismo y buscarse en Cuil, así que me dispuse a buscar "Martin Perez". Y no sé, me da que o bien el algoritmo de enlazar imágenes con resultados no está bien, o bien lo están mostrando al azar, pero lo que está más claro que el agua (al menos para mi) es que este no soy yo:



Perdonando este lapsus, parece que la interfaz de usuario al menos es innovadora, y los chicos tienen 24 millones de dólares para mejorar, así que a ver si se crea un poquillo de competencia en la web que empieza a aburrir un poco.

sábado, julio 26, 2008

Mensajería, escalabilidad, transacciones y tolerancia a fallos

sábado, julio 26, 2008 por Martín


Uno de los principios más importantes de la escalabilidad es el procesado asíncrono de datos. En una llamada síncrona, todo punto de integración constituye un nuevo riesgo, una nueva dependencia, un nuevo riesgo de quedarse bloqueado esperando por un recurso que nunca llegará o por un hueco en ese ansiado pool de conexiones que se nos ha quedado pequeño.

Por otra parte, uno de los principios más importantes de la integridad de datos es la transaccionabilidad. Si juntamos ambos conceptos, mensajería y transaccionabilidad, entramos en un nuevo mundo de retos y problemas, que unas veces serán sencillos de solucionar y que otras veces requerirán otra serie de artimañas más avanzadas para la gestión de errores.

Es sobre esto último de lo que trata un excelente artículo de Udi Dahan publicado en la MSDN. El autor recorre los problemas más comunes que nos encontramos en la integración de sistemas utilizando mensajería y como afrontarlos y resolverlos de manera robusta. Entre los temas tratados:


  • Persistencia de mensajes: Es decir el configurar nuestro broker de mensajería para que almacene, normalmente en base de datos, los mensajes de modo que se puedan reenviar posterioremente en caso de algún problema.

  • Consistencia transaccional: ¿Qué pasa si enviamos un mensaje y avisamos a un tercer sistema de ese cambio pero de pronto se hace un rollback del mensaje? El soporte de transacciones en los brokers y el uso del commit en dos fases resuelve este problema, pero a veces es overkilling.

  • Uso de colas de errores: Enviamos un mensaje ... y falla; lo volvemos a enviar ... y falla; probamos otra vez... vuelve a fallar. ¿Qué hacemos? Podemos seguir y seguir (y en el 99.99% de los casos seguirá y seguirá fallando) lo que consumirá importantes recursos de nuestro sistema, podemos lavarnos las manos e imprimir la traza de error, o podemos enviarlo a una cola de errores, donde más tarde los revisaremos, lo cual parece una muy buena opción.

  • Tamaño de los mensajes: Aquí el autor hace un excelente análisis sobre la diferencia entre procesar miles de mensajes pequeños y unos cuantos cientos de mensajes enormes.
    TimeToProcess(BigMessage) >> N x TimeToProcess(SmallMessage) where
    Size(BigMessage) == N x Size(SmallMessage)

    Los requisitos del procesado de mensajes grandes en cuanto a validación (CPU, memoria), almacenamiento en caso de mensajería duradera(CPU, disco), o congestión de red (optimización de paquetes) son mucho más exigentes y a menudo la única solución es el partir el mensaje original en mensajes mucho más pequeños y sencillos de procesar.



En resumen, en mi opinión excelente artículo para el que le gusten los temas de mensajería, procesado asíncrono de datos y transacciones, y lectura recomendada.

miércoles, julio 23, 2008

El centro de datos y el baño de las chicas

miércoles, julio 23, 2008 por Martín



From: ---- --------
Sent: Monday, May 5, 2008 4:37 PM
To: Everyone
Subject: Server Room Access

Hi all.

As you all are aware, we have new tenants that have moved into
the 2nd floor suites. The access to the server room is now via
the women’s bathroom.

There will be a sign on the woman’s door that can be changed
from OPEN to CLOSED and vice versa.

Should you need to enter the server room, please change the sign
to CLOSED. Once you are done, please change it back to OPEN.

Once you enter the bathroom, you will be able to access the
server room via the handicapped stall. Please close the stall
door prior to entry, just in case someone doesn’t see that the
bathroom is closed.

I know this isn’t ideal, but if we adhere to this protocol, I
don’t think anyone will be disrupted.

Thanks! Let me know if you have any questions.


Via Pingdom y DailyWTF.

sábado, julio 19, 2008

Emprendedores, SeedCamp y la importancia de validar una idea

sábado, julio 19, 2008 por Martín

A través de Web 2.0 Ireland he llegado a un post realmente interesante de Saul Klein.

El artículo no deja de ser un post publicitario de SeedCamp, y de como este foro puede ser una buena herramienta para validar las ideas de potenciales emprendedores. Me quedo especialmente con una parte del mismo:

In today's environment, if you are in your 20s and you put [society's] [your parent's] economic fears aside, there has never been a better time to be a first-timer.


Y es que aunque los emprendedores ahora mismo se enfrentan al gran problema de que parece que todo esté ya inventado, de que hay una competencia enorme y de que las compañías poderosas se hacen cada vez más y más poderosas e intentan abarcar más y más, lo cierto es que nunca ha sido tan barato el montar un negocio y nunca ha habido tantos recursos disponibles ya sea en forma de librerías, frameworks y utilidades Open Source (como Java, LAMP o RoR), en forma de alojamiento de gran rendimiento y muy barato (como Amazon EC2/S3) o en forma de enormes plataformas gratuitas para ejecutar nuestros programas (como Google Apps Engine).

Una de las cosas que lamento más es el no haber intentado algo hace cinco años, cuando había tantas cosas todavía sin inventar. Ahora ya me ha pasado el arroz de los 20s, pero quien sabe si en los 30s habrá un poco más de suerte. En estos momentos en los que la recesión aprieta, y los jóvenes ya no están obligados a meterse en una hipoteca porque la vivienda siempre sube, quizás tenga más sentido que nunca el tomarse un descanso, olvidar el yugo del ladrillo y emprender.

Resulta también muy interesante que en la cena del The Accelerator Group que se comenta en el post 12 de las 15 startups que se reunieron estuvieran utilizando Amazon Web Services o probando Google App Services. Todo el mundo estaba usando LAMP, Python; Django o Ruby; y por supuesto todo el mundo estaba usando o pensaba usar f8 o OpenSocial; y parece que todos estaban pensando también en el nuevo iPhone.

En mi caso, os voy a contar un secretillo. Tengo algo. O bueno, más correctamente tenemos algo. No estamos en el grupo de RoR (aunque algunos se dediquen también a ello), si no en el de Groovy y Java. Sólo voy a dar una pista, la palabra clave es empleo. Y realmente espero que pronto (posíblemente Otoño) tengáis la oportunidad de validar nuestra idea :)

lunes, julio 14, 2008

Algunas notas sobre el proceso de desarrollo en Linkedin

lunes, julio 14, 2008 por Martín


Tenía por aquí entre las cosillas pendientes de publicar unas transparencias sobre el proceso de desarrollo en LinkedIn que presentaron en la JavaOne de este año.



A mi LinkedIn es uno de los sitios que peronalmente me gusta más, especialmente desde que le dieron el cambio de imagen hace unos meses. Entre las cosas más destacadas de la presentación:


  • Ciclos de desarrollo de 2 a 4 semanas.

  • Los requisitos se dividen en pequeñas tareas con las que se rellenan tarjetas para cada desarrollador.

  • ¡¡Minimizar las reuniones!!

  • Test Driven Development

  • Más de 6500 tests de unidad e integración. Más de 500 tests de HTMLUnit.

  • El sistema de integración continua tiene más de 20 nodos. No se trata sólo de integración continua sino que ahí también se realizan los smoke tests.

  • El testing de integración puede llevar demasiado tiempo. Aquí easymock se muestra como una mejora importante.

  • 99% Java: Spring, ActiveMQ, Quartz, HTTPClient, Lucene, Grails, Jetty, DWR, jUnit, HTMLUnit, Hudson, Eclipse+Mylyn, EHCache. - Me llama la atención la ausencia de Hibernate o cualquier otro ORM. ¿JDBC Template "a pelo"?

  • Más de un millón de líneas de código, con ¡20 branches activas! Uso intenso de genéricos.

  • 50 ingenieros, 8 equipos. - Viendo el impacto de esta red y la importancia que ha adquirido, ¿no os esperaríais más?



La presentación sigue con notas sobre la arquitectura de LinkedIn, que también son interesantes para los que no conozcan los fundamentos básicos sobre los que se sustenta, es decir el mover la integridad a un segundo plano y el mantener toda la red de contactos de todo el mundo en memoria. El año pasado ya ponía algunos comentarios sobre el tema.

martes, julio 08, 2008

¿Es Google el nuevo malo de la película?

martes, julio 08, 2008 por Martín


En este blog hay bastantes entradas sobre Google, probablemente como en la mayoría de blogs sobre informática. Esta compañía ha aportado tanto a la informática y es tan, tan, tan poderosa que es casi imposible el dejar de hablar de ella. Pero como suele pasar en estas compañías, a medida que van ganando poder, van perdiendo simpatizantes, y Google no es una excepción.

Greg Linden comenta en su blog que lo mismo pasaba con Amazon cuando él trabajaba allí, allá por el 2000, y muestra diferentes referencias a artículos de prensa atacando a Google, todos bastante recientes, incluyendo uno de hace un par de días donde en el New York Times presentan a Google como una especie de tirano más preocupado en ahorrar costes (¿qué raro en una empresa, no?) que de mantener los actuales beneficios de sus empleados.

El caso es que normalmente esto no me llamaría la atención, si no fuese que justamente este fin de semana, cuarioseando en boards.ie (que son unos foros realmente importantes en Irlanda, hasta el punto de ser referenciados en la radio o de que profesionales de diferentes tipos ofrecen consultas grauitas en los mismos ) me encontré un hilo sobre trabajo donde gente que trabaja en Google da sus impresiones, tanto positivas como negativas, aunque parece que predominan estas últimas. Como sabéis, Google tiene los cuarteles generales en Europa localizados en Dublin

Esta opinión es realmente interesante, y muestra (si asumimos que es real) las fuertes diferencias entre puestos técnicos y no técnicos en la compañía. Otros hilos hablan de la enorme competencia dentro de la empresa, la importancia de relacionarse, y en resumen muchas cosas lejos de la imagen idealizada que pudiese tener mucha gente de la compañía. Pero ojo, no os quedéis sólo con lo malo porque también hay opiniones buenas, y los beneficios que se obtienen trabajando en Google son únicos (aunque por ahora no sea más en forma de acciones).

¿Qué os parece a vosotros? "An average large company", ¿como comentan por ahí? Sea como sea seguro que merece la pena trabajar ahí aunque sólo sea un tiempo para aprender de la experiencia.

jueves, julio 03, 2008

RPC: ¿Correcto o Conveniente?

jueves, julio 03, 2008 por Martín



Pincha aquí, pincha allí, he llegado a un excepcional artículo que publica Steve Vinoski en el número de Julio/Agosto de la revista Internet Computing del IEEE. El artículo se titula Convenience over Correctness y por suerte está disponible en PDF. Este artículo es de lo mejorcito que he leido desde hace bastante tiempo, y probablemente lo mejor que ha caido este año en mis manos.

Steve Vinoski ha sido una de las referencias en cuanto a computación distribuida, muy conocido en el mundo de CORBA, escribió una de las biblias de esta plataforma. Sin embargo de un tiempo para aquí Steve reniega de todo lo que tenga que ver con RPC y se ha convertido en un acérrimo defensor de los lenguajes dinámicos y también de erlang.

La verdad es que me pongo a leer el artículo, y no sabría que quotes pegar en este post. Son tantas las verdades escritas que da pena quedarse sólo con una frase. Quizás lo fácil sea escoger la que viene resaltada en el artículo mismo:

We have a general-purpose imperative programming-language hammer, so we treat distributed computing as just another nail to bend to fit the programming models.


Steve critica enormemente en el artículo a los lenguajes tradicionales y la comoditización que se ha hecho de RPC, un paradigma que funciona enormemente bien en redes locales pero que a la hora de moverse a Internet se olvida de factores tan importantes como la latencia, la tolerancia a errores o la escalabilidad del medio de transporte, entre otros, y que asume que todo funcionará bien y sin ningún tipo de fallos.

La carencia de constructores en los lenguajes tradicionales para especificar todos estos aspectos es una de las críticas que más resalta Steve, abogando por paradigmas como REST+HTTP que permiten especificar aspectos como la cacheabilidad de un servicio de manera sencilla.

Al mismo tiempo otro de los centros gravitacionales del artículo es la computación distribuida y la necesidad de evolucionar hacia lenguajes de programación como erlang que huyen de la inocencia del modelo RPC y que al tiempo que ofrecen constructores tan simples como "Pid ! Message" (envía el mensaje al proceso especificado por el Pid) ofrecen todas las ventajas asociadas con la computación asíncrona y distribuida.

La discusión sobre el artículo en su blog resulta también extremadamente interesante y además hay varios enlaces a otras columnas similares del mismo autor.

Por cierto, al que le interese puede ver también entrevista de InfoQ.

miércoles, julio 02, 2008

Tuneando transacciones con Spring

miércoles, julio 02, 2008 por Martín



Hace unos días escribía sobre la disponibilidad de las charlas de la SpringOne 2008. Una que he leido recientemente es la de Jurgen Holler, Transaction Choices for Performance, y en la que se entra en detalle sobre los diferentes tipos de transacciones en Spring y sobre como evitar las transacciones XA en la medida de lo posible.

Muchos de los que leen este blog sabrán lo que es XA, aunque supongo que otros no. Básicamente es una especificación que define como sincronizar el acceso a recursos totalmente diferentes dentro de una misma transacción, para lo que se utilizar un gestor de transacciones global. Un ejemplo sería el realizar desde un mismo método un acceso a base de datos y enviar un mensaje a algún broker de mensajería. XA te garantiza que el método se ejecutará preservando las propiedades ACID entre las diferentes llamadas.



En el screencast de arriba( y esto es una prueba y una excusa para probar este servicio ) os muestro un caso muy típico en el que se necesitaría sincronizar una base de datos y un servidor de mensajería. El método A actualiza la base de datos, envía un mensaje a una cola, realiza un proceso y termina su ejecución. Mientras tanto, en otra parte del sistema, un consumidor lee asíncronamente el mensaje en B y consulta la base de datos. ¿Cuál es el problema? Pues que como la cola de mensajería y la base de datos tienen sus propios gestores de transacciones, resulta que es muy probable que el mensaje llegue a B cuando la transacción en A todavía no se ha persistido en la base de datos, con lo que el consumidor estaría leyendo un valor incorrecto (ver phantom reads si no se es familiar con este concepto).

Utilizar XA soluciona este problema ya que un gestor de transacciones global se encargá de sincronizar todos los recursos de forma que por ejemplo el mensaje no se envie hasta que no se haya hecho commit de la transacción (aunque en realidad dependería de la implementación del gestor transaccional). A simple vista utilizar XA parece claramente una buena idea. Sin embargo, hay un problema muy importante, XA es enormemente lento. Muchísimo más lento que utilizar transacciones simples ( o que no usar transacciones ). Jurgen desmonta unos cuantos mitos sobre las transacciones XA en su presentación:

Me permito traducir los puntos:

  • Una aplicación empresarial crítica y seria necesita transacciones XA: No es cierto, muchas aplicaciones empresariales no utilizan para nada transacciones XA.

  • Una mapeo objeto-relacional correcto requiere el uso de XA: No es cierto, los mapeadores objeto-relacional normalmente operan con JDBC más un sistema de caché propio.

  • Para combinar JDBC y JMS las transacciones XA son obligatorias: No es cierto, muchas aplicaciones empresariales utilizan JMS con transacciones nativas o ACKs.

  • Los gestores de transacciones modernos están optimizados para ofrecer el mejor rendimiento: No es cierto, las garantías que XA exige son costosas y no pueden ser optimizadas de forma tan sencilla.



Siguiendo con la presentación, la principal recomendación de Jürgen es que una de las formas para solucionar el problema planteado arriba es sincronizar de manera nativa la cola de Spring con el gestor transaccional que utiliza el DataSource de forma que el mensaje sólo se enviará cuando se termine la ejecución del primer método y se haga commit de la transacción lo que tiene la ventaja de no usar XA y tener un mayor throughput.

Es curioso además que hoy hablando con alguien, me comentaba que algunos bancos no estaba interesados en absoluto en utilizar XA, y aconsejaban a sus proveedores el no incurrir en este tipo de transacciones ya que eran demasiado costosas para sus servidores que albergan tantas y tan heterogéneas aplicaciones. No estoy muy seguro de lo que hay de cierto en esto, pero puede que tenga sentido :)

martes, julio 01, 2008

Dos productos Open Source interesantes saliendo de una tienda de viajes online

martes, julio 01, 2008 por Martín


Leyendo InfoQ he visto que Orbitz, una compañía de venta de viajes online, curiosamente ha lanzado dos frameworks como Open Source.

Uno es ERMA del que a pesar de la presentación en la JavaOne, que aunque yo no sería partidario de implementar este tipo de frameworks en una empresa teniendo cosas Hyperic, Wily o insideApps que pueden cubrir muchas de las necesidades, siempre está interesante alternativas para el procesado de eventos. En InfoQ hablan también de Esper que parece realmente interesante.

El otro es Graphite, que personalmente lo encuentro más interesante porque, su motor, whisper, supone una alternativa a RRDTool (n su página tienen una discusión sobre las diferencias entre ambos motores), y siempre está bien disponer de alternativas, especialmente Open Source. En InfoQ comentan que lo utilizan para manejar información agregada de 70000 métricas lo cual no está del todo mal, aunque tampoco especifican cuanta memoria o hardware se necesita para ello. En el wiki quizás haya más información.

Por cierto, he visto que uno de sus autores, Ray Krueger, es también el creador de un plugin para integrar memcached como caché de segundo nivel en Hibernate. Ni idea de como funcionará, pero si alguien se anima a probarlo, me encantaría oir sobre los resultados.