Plain Concepts patrocinador del Agile Open Spain 2009

Logo Agile OpenSiguiendo la tradición de Plain Concepts y sus profesionales de colaborar con la comunidad en todas las ocasiones que se presente, tenemos el gusto de comunicar que seremos co-organizadores y co-patrocinadores de la próxima edición de Agile Open Spain 2009, a celebrar en Madrid los días 23 y 24 de Octubre (el viernes por la tarde y el sábado).

Agile Open Spain es un evento de comunidad centrado en compartir entre los asistentes experiencias, ideas, dificultades, inquietudes y éxitos sobre metodologías ágiles de desarrollo de software. Este evento tendrá el formato de Open Space con el afán de promover la participación y sobre todo que emerja la conferencia que los asistentes diseñen. No contamos por tanto con una agenda preestablecida, sino que entre todos diseñaremos la conferencia, participando en la selección de las ponencias según su interés.

Desde Plain Concepts, entre un servidor y mi compañero Jose Luis Soria propondremos los siguientes temas:

  • Gestión de la configuración orientada a la agilidad (charla + demos + ronda preguntas / debate)
  • Control de proyectos con metodologías ágiles (charla breve + debate)
  • Dificultades frecuentes y posibles soluciones en la implantación de Scrum (introducción + debate) 
  • Gestión ágil con Team Foundation Server (charla + demos + ronda preguntas)
  • Behavior driven development (charla + demos + ronda preguntas)
  • Historias de usuario: ¿son suficiente? (charla + debate)

Aprovecho que todo aquel asistente que lo desee puede proponer una sesión. También me gustaría pediros, que si queréis que plantee alguno de los temas que sobre metodologías ágiles o Scrum he tratado en el blog, no tenéis más que pedirlo.

Las inscripciones han sido un gran éxito y el aforo está completo desde hace tiempo, me gustaría comentar que en Plain Concepts tenemos algunas invitaciones para nuestros clientes, por lo que si tienes interés en asistir, por favor ponte en contacto conmigo.

¡Espero veros en el Agile Open Spain 2009!

Software e innovación… innovación y software: ¿existe un proceso?

Reno en la carreteraMe encuentro en la Oulanka Research Station de la Universidad de Oulu en Kuusamo, un lugar perdido de Finlandia, a 25 km del círculo polar. Donde Cristo perdió el gorro, vamos. El sitio es precioso: cientos de lagos, miles de arboles, renos en medio de la carretera y una paz que invita a pensar.

En el marco del proyecto ITEI, subvencionado por la Unión Europea, un puñado de ingenieros, académicos y gente de la empresa estamos buscando desarrollar una metodología y un soporte informático abierto para la gestión de la innovación en el desarrollo de sistemas de software. Hay es nada. De este proyecto deben salir una especie de libro blanco de la innovación en el marco del desarrollo de software (SinnoBok) y el diseño de un ecosistema de software que soporte esta proceso de innovación (CyberRoom).

Mi participación, en representación de Sisteplant, es como empresa que está innovando en el desarrollo de software usando metodologías ágiles. Debo aportar que requisitos tenemos en nuestro proceso de desarrollo e innovación para que sean incorporados como parte del proyecto y actuar como caso de uso de la puesta en marcha de lo que sea que salga del proyecto.

El motivo de este mail, es comentar la esencia del proyecto. ¿Es posible definir un proceso de innovación? ¿Es la innovación algo que se puede materializar en un proceso? ¿Hay una serie de pasos que se pueden dar que faciliten la aparición de productos, servicios o vías de comercialización innovadoras en el marco del desarrollo de software? ¿Existe al menos un conjunto de patrones que podamos detectar y describir?. Yo creo que no. Pero también creo que es un camino que es interesante explorar, sobre todo por que hay mucha gente que cree que si y lógicamente yo puedo estar equivocado (es altamente probable).

Lo que quiero comentar es por que creo que no existe un proceso de innovación definible y repetible (¡como les gustaría a la gente de CMMi esto!). Mis argumentos son los siguientes:

1) No hay dos productos de software iguales, no hay dos proyectos iguales, no hay dos equipos iguales, no hay dos empresas iguales. Si tenemos en cuenta que el marco del desarrollo de software es tan diferente y cambiante, es sumamente difícil encontrar un marco que funcione en todas. Esto ocurre con las metodologías, que para funcionar necesitan un fuerte proceso de ajuste e implantación. Si añadimos a esto, que por su propia naturaleza, una innovación es radicalmente diferente de cualquier otra cosa existente, la cosa se complica aun más.

2) Viendo la historia de las innovaciones recientes: el procesador, el ratón, el compilador, las redes, el ordenador personal, la web, las listas de correo, el chat, las redes sociales, las metodologías ágiles… no hay dos que hayan surgido de una manera similar. Es imposible trazar un patrón. En cada situación se partía de unas condiciones iniciales diferentes, se siguió un proceso diferente, se llegó al final del proceso y se comercializo la idea de manera diferente. Pensad en como surge el concepto de Wiki, por poner un ejemplo, base de algo tan rompedor en la cultura moderna como Wikipedia: Ward Cunningham uno de los padres de los patrones, arto de recibir mails pidiéndole que corrija tal o cual detalle en su catálogo de patrones, decide añadir un simple botón que permita a cualquiera editar el html de la página. Una innovación radical, algo nuevo, que nadie ha hecho antes, que no era especialmente ambicioso, que podría haber concluido en un desastre de gente haciendo el vándalo en su sitio y que acaba cambiando el modelo de enciclopedia que se conocía desde la ilustración francesa. Impresionante. ¿Pero como catalogarlo? ¿Cómo sistematizar los ocurrido para facilitar que surjan nuevas innovaciones?. Imposible.

3) No hay una receta para desarrollar software, menos para desarrollar software innovador. Aunque Joel Spolsky incluso tiene un receta para hacer que tu software sea el número 1 ;).  El desarrollo de software es un arte. Generalmente detrás de cada gran innovación en este campo hay una persona que actual como un gran catalizador, un artista o un grupo de ellos: La WWW y Tim Berners-Lee, Linux y Linnus Torwalds, GNU y Stallman, C++ y Stroustroup, C# y Gunnerson, los patrones y la Gang of Four, Google y Larry Page y Sergei Brin… Ningún proceso garantiza que ese catalizador va a aparecer, más bien al contrario. Parece que la sensación general es que los procesos definidos tienden a encorsetar la creatividad necesaria para innovar. Muchos creen que Microsoft a perdido su capacidad de innovar y que Google la está perdiendo precisamente por esto.

Tom Simpson, ingeniero de IBM y uno de los padres del OS/360 escribió una algo que aplica perfectamente a lo que comento, en un excelente ensayo breve suyo, escrito en 1968, Masterpiece Engineering. Tom escribe la siguiente sátira, que he traducido muy libremente, sobre como un grupo de ingenieros de software estaba buscando los criterios a establecer para diseñar un sistema operativo:

“Estudiando el problema de como lograr establecer el diseño para producir ‘Mona Lisas’ …la Conferencia decidió que se debía establecer un Instituto para trabajar con más detalle sobre los problemas en el campo de la producción de obras maestras. Así que salieron a las calles de Roma y seleccionó unos cuantos conductores de carros, algunos luchadores y otros artesanos y los sometieron durante un período de cinco semanas (a media jornada) a un Curso de creación de obras maestras, y luego todos fueron puestos en una gran habitación y se les solicito que comenzaran con la creación de obras maestras.

Pronto se dieron cuenta de que no estaban consiguiendo los resultados esperados del Instituto, por lo que se trato de equipar a los trabajadores en la producción de obras maestras con algunas herramientas más eficaces para ayudarles a crearlas. Se inventaron cinceles a motor, pistolas de pintura y así sucesivamente, pero todo esto se limito a provocar una protesta ruidosa de los maestros: "Todas estas técnicas se dan en los pintores de técnica descuidada", dijeron.

La producción aún no estaba llegando a niveles satisfactorios por lo que se amplió la gama de técnicas de producción de obras maestras con algunas medidas adicionales. Una idea fue tener un lienzo y que pasase rápidamente de pintor a pintor. Mientras uno estaba aplicando el pincel los demás tenían tiempo para pensar.

El siguiente paso natural a tomar fue, por supuesto, duplicar el número de pintores, pero antes de tomarlo, adoptaron un mecanismo más interesante. Se decidió establecer alguna métrica adecuada de la productividad. Se emplearon dos semanas en el Instituto contando el número de pinceladas por día producidas por un grupo de pintores, y este criterio fue inmediatamente aplicado para calcular valor aportado a la empresa por el resto. Si un pintor fracasaba en lograr sus veinte pinceladas por día sería claro que se trataba de alguien claramente improductivo.

Lamentablemente ninguno de estos avances en el conocimiento parecía tener un impacto real sobre la producción de obras maestras y así, al fin, el grupo decidió que la dificultad básica era claramente un problema de gestión. Uno de los más brillantes estudiantes (con el nombre de Leonardo da Vinci) fue inmediatamente promovido a gerente del proyecto, poniéndolo a cargo de la adquisición de pinturas, lienzos y pinceles para el resto de la organización.”

Evidentemente no lograron producir una obra maestra.

Entiendo que el mensaje puede ser poco esperanzador, que sueno muy pesimista, pero si que es cierto que hay cosas que podemos hacer para mejorar la innovación. Muy generales, pero hay están. Y son precondiciones. Sin estas precondiciones, no surge la innovación. Quizás facilitar la eliminación de estas barreras de entrada a la innovación sea la innovación que debemos esperar de este proyecto. La gente del VTT y de Sirris ha propuesto unas áreas clave de la innovación que ellos han llamado, en un claro reconocimiento de la naturaleza artística del problema, El Arte de…:

… mantenerse enfocado.
… experimentar.
… optimizar el impacto de tus recursos de alto impacto (tus artistitas vamos…).
… abrirse al mundo (openness tiene una traducción difícil…).
… estimular la innovación.
… de mejorar la innovación.
… de la incubación de ideas.
… de la recolección de ideas.
… de la evaluación de ideas.

A mi me suena que Scrum puede dar una respuesta a algunas de estas preguntas 😉 ¿pero realmente si conseguimos responder estas respuesta, estamos consiguiente ser innovadores? No en vano uno de los objetivos de Scrum y de las metodologías en general es ser capaz de incorporar el cambio y la innovaciones que surgen al proceso de desarrollo. Al fin y al cabo: ¿no es toda innovación un proceso de cambio radical?.

Espero que os animéis a dar vuestra opinión, ya que todos los que estáis en el mundo del software sois innovadores por naturaleza. Con cada línea de código que escribís, estáis haciendo algo nuevo. Esto nos diferencia claramente de otras industrias.

¡Un saludo!

Instalando Ubuntu en un PowerMac G4

Algunos no somos tan afortunados como el amigo Rafael, poseedor de un flamante y nuevecito Mac. Yo me tengo que conformar con un PowerMac G4, con 512Mb de RAM, un procesador PowerPC a 400MHz un disco duro de 10Gb y una tarjeta ATI Rage de 128Mb, un equipo que tiene más de una década y que aun tiene un aspecto realmente acojonante. Es un placer abrir la caja, sin soltar un solo tornillo, simplemente accionando una palanquita de diseño perfectamente integrada en la caja, y echar un vistazo dentro. Que acabados tiene este hardware, impresionante. Antes de hacer nada tuve que limpiar las babas que se me cayeron en la placa base. Es una máquina increíble: cuando salió la mercado se catalogo como material sensible para la exportación por su potencia.

Las tripas del PowerMac G4

Se ve, nada más abrirlo, que el equipo es una gran máquina, con un sistema operativo muy antiguo, Mac OS 9.2, una reliquia de los tiempos de Windows 3.1. La pega es que no he podido instalar Windows 7, que no soporta procesadores PowerPC. Aunque la máquina soporta perfectamente Mac OS X 10.4 ‘Tiger’, no tengo los CDs de instalación. Así que me he tenido que decantar por Ubuntu 9.04. Será suficiente pues el único cometido del equipo en cuestión será pinchar MP3 en el Pub Jonh Lennon que mi amigo Javier aka Paisano tiene en Belorado.

La instalación de Ubuntu ha ido rodada. Simplemente bajarme la ISO de la versión para PowerPC, tostarla en un CD y arrancar el Open Firmware del Mac (no arranca directamente el CD) hay que hacerlo a manopla. En este equipo, no funciona arrancar pulsando C. Hay que arrancar el Open Firmware (pulsando alt + manzana + o + f) y luego ejecutar el siguiente comando:

boot cd:;installyaboot

A partir de aquí la instalación de Ubuntu va como la seda.

Una vez instalado Ubuntu he tenido algunos pequeños problemas:

1) Configurar los drivers de la tarjeta gráfica (sino solo se soportan 800×600 y Xorg consume un montón de procesador haciendo la máquina muy lenta).

La solución es simple, basta editar el archivo /etc/X11/xorg.conf:

sudo gedit /etc/X11/xorg.conf

El contenido del archivo es el siguiente (tened en cuenta que mi monitor es un Philips 107S, pero lo relativo a la tarjeta gráfica serviría para cualquier PowerMac G4 con tarjeta ATI Rage 128 AGP):

Section "Device"
        Identifier         "ATI"
        Boardname       "Ati Rage 128 M3"
        Driver               "r128"
        Screen              0
        Vendorname     "ATI"
        Option              "MergeFB"   "off"
EndSection

Section "Monitor"
        Identifier          "Configured Monitor"
        HorizSync         30.0 – 71.0
        VertRefresh      50 – 160
        Option              "DMPS"
EndSection

Section "Screen"
        Identifier          "Default Screen"
        Monitor            "Configured Monitor"
        Device              "ATI"
        DefaultDepth    24
                Subsection "Display"
                        Depth     24
                        Modes    "1024×768" "800×600" "640×480"
                EndSubsection
EndSection

2) No puedo podía escribir arrobas (@), ni pipes (|), ni sostenidos (#)…

Vamos a Sistema->Preferencias->Teclado y seleccionamos como modelo de teclado PC genérico 105 teclas (intl), en distribución seleccionamos España Macintosh. Luego pulsamos el botón Opciones de distribución… en Key to choose 3rd level, marcamos Rigth Win y listo, la manzana de la derecha pasa a ser nuestro amado Alt Gr.

3) La hibernación no funciona, aunque el equipo hiberna, luego no se despierta. Así que la he desactivado y listo.

Otro tema interesante es que, lógicamente el equipo no tiene una tarjeta Wireless, solo una conexión Ethernet. Yo en el pueblo solo tengo acceso a internet por wireless (cortesía de un vecino). Así que conecté el Mac a mi portátil mediante un cable de red cruzado, active la conexión compartida a internet en el portátil, y listo, conexión a internet en el Mac.

Una fuente espectacular de información, sin la que me hubiese costado mucho hacer andar este equipo, es la FAQ de PowerPC de Ubuntu también me ha servido enormemente un artículo sobre como hacer que Ubuntu sea más amigable en un Mac. Aquí podéis ver como el G4 arranca Ubuntu 9.04.

Ubuntu arrancando en el PowerMac G4

No es que la máquina vuele, la verdad, pero es usable para su cometido, navegar por internet, ripear CDs y reproducir MP3.

La siguiente misión es instalar OS X Tiger en este equipo, estoy removiendo Roma con Santiago para encontrar el DVD de instalación. A ver si logro dar con el.

P.D.: Como me mola lo de trastear con hardware viejuno… tengo una flamante estación SGI Indigo Impact a la que llevo metiendo mano meses y aun no he conseguido actualizar el Irix que trae. No tengo la password del root, no tiene lector de CD, y no he logrado instalar Irix por red desde Ubuntu, por mucho que lo intento… pero la historia va a cambiar, junto con el G4 han caído en mis manos dos CD externos SCSI, justo lo que necesito para revivir la Impact… :)… ya os contaré.

Lo quiero todo, todo y todo… o la triste realidad del triángulo de la gestión de proyectos

Resulta que esta mañana me he levantado graciosito y no se si como resultado del aburrimiento, de la pila de días de descanso vacacional que llevo, o de los cubatas del Cebolla Rock, me he propuesto hacer un experimento. Me he ido al concesionario de BMW más cercano, he buscado a uno de esos aseados y sonrientes y le he dicho…

Buenos días, me gustaría comprar un 750i, blanco, que le gusta a mi mujer de eso color, aunque a mi me parece un poco taxi. Taxi, un 750i, ni aunque le ponga lucecita verde hombre, ha dicho el comercial. Ya que estamos, no lo vamos a mirar, he seguido yo… póngamelo con llantas de 20’’, como no y todos los extras, lo quiero todo, todo y todo… si si el paquete M también, como no, yo soy un joven, dinámico y profesional, no puedo ir por el mundo sin el paquete M, faltarías más.

¿No sería interesante añadir también la garantía extendida? Por su tranquilidad, ya sabe. Ha dicho el comercial. Y claro, pues yo he pensado… como no se me habrá ocurrido, póngalo, póngalo. Quizás no lo use pero que le vamos a hacer, nunca se sabe lo que puede pasar.

Y la bola de caravana, ¿no la necesitará usted?… Hombre, yo no tengo caravana, pero ya que lo comentas, y como nunca se sabe, a lo peor me da por cambiar el pueblo por un camping… venga vale, total, molestar tampoco molesta.

Y claro, seguro que un profesional, joven, dinámico, con paquete M y toda la zarandaja es una avezado ciclista, de los de mountain bike molona, de esos de los de gafas Oakley, maillot, culotte, zapatillas y pedales automáticos ¿no? Seguro que necesita el exclusivo portabicicletas de BMW para pasear, digo transportar sus bicis. Pues no, he dicho yo, eso si que no, que yo hace mucho que deje la bici y soy de pelota mano y tal y cual. Hombre, recuerde que nunca se sabe, ha dicho el comercial, y se lo dejo a precio de risa, a añadido. Así que he pensado, por si acaso, con portabicis, ¿voy a saber yo más que el comercial?.

Ya solo nos quedan dos detalles menores. Empecemos por el plazo de entrega. El comercial a empezado a farfullar no se que de disponibilidad, que si las opciones retrasan no se que y no se cual. Yo he pensado, coño, aquí el cliente soy yo ¿no? y le he dicho… a ver si yo lo entiendo todo, pero me lo tienes para dentro de dos semanas, son fiestas del pueblo y tengo que fardar. El comercial no ha dicho ni mu, es más me ha dicho, que quizás lo tenga un poco antes.

El segundo tema menor, el precio. Aquí yo he tomado la iniciativa que para algo soy el cliente ¿no?. Para esto tengo treinta mil euritos, entiendo que tengo que poner otros dos cientos, por la llantas, pero esto es lo que hay. Me han dicho que en la india hay unos concesionarios que lo hacen más barato y mejor, eso sí, por evitarme el papeleo que sino te iba a comprar al ti el BMW Rita… la cantadora.

Entonces me he despertado. Claro. ¿Por qué estas cosas solo nos pasan en el mundo del software? La historia no se sostiene, claro está, pero cambiad BMW por aplicación de software, y dar sudores fríos el pensar realismo que se añade. ¿Alguno de vosotros le suena? 😉

Hace mucho, mucho tiempo, que se describió el famoso triangulo o tetraedro de hierro de la gestión de proyectos (hay gente que cree que la calidad también es un factor sobre el que podemos gestionar, yo soy de los que piensan que la calidad no es algo con lo que se pueda especular, la calidad no es opcional, y la marca el cliente, no nosotros).

Triangulo de gestión de proyectos

La idea es que de los tres aspectos: alcance, coste, y plazo, el cliente puede manejar dos grados de libertad. El otro, lo maneja la gestión del proyecto. Esta es en esencia una idea de equilibrio básico entre las partes de un proyecto. Es problema es que a menudo este equilibro se rompe. Incluso hay un antipatrón que describe esta situación. Diferentes metodologías dan diferentes respuestas a este problema, en un próximo post, comentaré la solución que propone Scrum. De hecho el propósito de este post, es comentar el dichoso triangulo de una manera un poco amena, como prolegómeno a dicho post.

Por cierto, ya tengo mi BMW, ha llegado seis meses tardes, no es blanco, y le faltan algunos detalles menores. Eso si, cuatro ruedas y volante tiene. Os dejo una fotito, para daros envidia. No es lo que esperaba, pero esa es otra historia…

 BMW

¿Qué es lo que hace que cuando se habla de software la realidad se torne tan anómala? ¿Por qué creéis vosotros que es tan difícil mantener el equilibrio descrito en el triangulo de la gestión de proyectos en la realidad? ¿Que factores hacen que salte por los aires tan a menudo en los proyectos? Y no, no vale el argumento fácil: ¡es que los comerciales…! 😉

Truco: Liberar espacio tras la actualización a Windows 7

He realizado dos actualizaciones a Windows 7, una desde Windows Vista a la RC y otra desde la RC de Windows 7 a la RTM. Las dos han sido un éxito absoluto, a pesar que el segundo camino de actualización, de RC a RTM, no esta oficialmente soportado.

En el caso de la primera, de Vista a RC, lo que más me sorprendió en su momento fue la gran cantidad de espacio de disco duro que recuperé. No tengo muy claro el por que pero el actualizar de Vista a Windows 7 me liberó 8 Gb de disco duro de manera inmediata. Evidentemente esto no ocurrió de la RC a la RTM.

Esto no es todo, el truco que os voy a contar no va a permitir liberar más espacio aun tras una actualización a Windows 7. El hecho es que una actualización a Windows 7 deja mucha ‘morralla’ tras de sí. Principalmente copias de seguridad de archivos descartados durante la migración y una gran cantidad de información de logeo de las operaciones realizadas durante la actualización.

Para recuperar ese espacio debemos ejecutar el asistente para la liberación de espacio en disco.

Clean up system files

El detalle más importante es pulsar en el botón Clean up system files, sino no podremos seleccionar la opciones que vemos en la siguiente imagen:

Clean up Windows 7 discarded files and upgrade logs

Seleccionando Files discarded by Windows upgrade y Windows upgrade log files liberaremos, en mi caso, 1,96 Gb, un cifra nada despreciable. Decir que esta cifra, según mi varia de máquina a máquina y es aun mayor cuando la actualización es desde Vista a Windows 7.

¡Espero que os sirva!

Truco: Actualizando Windows 7 RC a la versión final (RTM)

En teoría, no es una situación soportada el actualizar una instalación de Windows 7 Release Candidate (RC) a la versión final o RTM (Release To Manufacturing). Si lo intentamos encontraremos una pantalla, que impide continuar con la instalación, como esta:

W7 RC to RTM compatibility report

Gracias a dios, hay un simple truco del almendruco, lógicamente no soportado, que nos permitirá hacer la actualización. Debemos copiar el contenido del DVD de Windows 7 al nuestro disco duro. En la ubicación que hayamos copiado los contenidos del DVD, dentro de la carpeta sources encontraremos un archivo llamado cversion.ini, con el contenido que podéis ver en la siguiente imagen:

Contenido original del archivo cversion.ini

Podéis ver que en la entrada MinClient tenemos el valor 7233.0. Si ponemos en esta entrada 7000.0 y guardamos el archivo, podremos actualizar desde la RC a la versión RTM definitiva ‘sin problema alguno’. Pongo entre comillas, ‘sin problema alguno’ porque si bien es cierto que en mi caso todo ha ido de maravilla, insisto: este procedimiento no esta soportado, podéis usarlo a vuestro propio riesgo y lógicamente siempre tras haber hecho una copia de seguridad de todos vuestros datos valiosos.

¡Espero que os sirva y que os funcione tan bien como a mi!

He leído: The art of Unix programming de Eric S. Raymon

Comprálo en AmazonSupongo que lo primero que se preguntan los lectores de este blog al ver el título de este post es ¿qué hace un MVP leyendo cosas sobre Unix? o formulando la pregunta de una manera menos torticera ¿por qué un experto en entornos Microsoft está interesado en Unix?. La respuesta es compleja, pero las motivaciones que me han llevado a leer este libro son:

Unix es un gran sistema operativo, estaba seguro que aprendiendo más sobre Unix me iba a convertir en un desarrollador y arquitecto más valioso. Internet es Unix, Internet es omnipresente. Quieras o no a diario todos usamos sistemas Unix. Me gusta conocer lo que uso.

Conocer los puntos fuertes y débiles de otras plataformas de desarrollo y sistemas operativos te ayuda a detectar, prevenir y minimizar las debilidades de tus soluciones y del entorno en que te mueves, Windows y .Net en mi casos.

Es un libro enormemente citado. Casi todo el mundo que lo ha leído coincide en que es un gran libro que todo amante del desarrollo de software, por encima de afinidades a tal o cual sistema operativo, disfruta leyendo.

A pesar de lo que pueda parece por el título el libro no es un libro sobre programación. No te enseña a programar en Unix. Es un libro sobre historia, arquitectura y cultura informática en general. Es una lectura amena y llevadera, sobre todo si ya has tenido contacto con entornos Unix y te apetece saber por que las cosas son como son en esa plataforma.

La primera parte del libro, de aplicación universal, desgrana las grandes decisiones de arquitectura y circunstancias históricas que han llevado a los entornos Unix a ser como son. Muchísimas de estas decisiones de diseño, tomadas por gente de extraordinaria valía, pioneros de la computación e Internet, esconden extraordinarias lecciones prácticas de arquitectura y diseño de sistemas informáticos. Además se incluye una ‘comparativa’ entre sistemas operativos y las grandes decisiones de diseño que han marcado cada una de ellos que sin duda aporta una interesantísima cultura general sobre el tema que todo arquitecto debería tener. Lo que menos me ha gustado del libro, sin duda, es que no es del todo objetivo en su tratamiento de los sistemas operativos de Microsoft y que se nota que lleva un lustro escrito y no ha sido actualizado con los avances habidos en  esta plataforma. Por poner un simple ejemplo se critica la ausencia de una interfaz de línea de comandos potente, algo paliado ampliamente desde la aparición de PowerShell. En esta parte del libro me parecen especialmente destacables e interesantes las reglas que el autor desgrana sobre la filosofía de Unix, ¡son reglas aplicables a cualquier arquitectura!. No se puede discutir que si algo a demostrado Unix es su capacidad para adaptarse a las circunstancias, evolucionando durante cincuenta años para amoldarse y ser una plataforma puntera en todo cambio habido en la informática durante su historia. Sin duda esta capacidad de adaptación y permanencia se deriva de una excelente arquitectura, por eso conocer las reglas que han guiado esa arquitectura es sumamente valioso.

En la segunda parte del libro, se baja de nivel y pasamos de la arquitectura de Unix a su diseño, a detalles concretos de soluciones que se han tomado en el diseño de este sistema operativo y de aplicaciones significativas del mismo. Esta parte del libro es, para mí, la más interesante. Podemos extraer de los casos estudiados en el libro una gran cantidad de conocimiento práctico sobre el diseño de sistemas informáticos. Se tratan todos los temas clásicos del diseño arquitectónico: Encapsulación, ortogonalidad, capas, diseño de protocolos, transparencia, multiprocesamiento, lenguajes embebidos, generación de código, optimización, complejidad… Resumiendo, todo un tratado sobre los grandes temas del diseño de software, vistos no solo desde un punto de vista teórico sino repasando como se han aplicado en esta plataforma y en sus aplicaciones más relevantes.

El libro presenta además un repaso sumamente interesante, en su tercera parte, de las herramientas y lenguajes de programación que permiten llevar a la práctica la lecciones aprendidas sobre arquitectura y diseño. Aquí el libro se convierte en algo mucho más especifico de la plataforma Unix, y por lo tanto las lecciones que aprendemos en esta parte, aunque interesantes y valiosas, no son de universal aplicación.

La cuarta parte del libro está dedicada a la comunidad. No cabe duda que la cultura de comunidad ha sido mucho más rica y tiene una tradición mucho mayor en entornos Unix que en entornos Windows. Esto ha cambiado radicalmente en los últimos años, pero aun así hay lecciones importantes que podemos aprender y otras que aun estamos aprendiendo en el mundo Windows sobre como compartir código, trabajar en proyectos de manera abierta, documentar los proyectos que compartimos, etc… Conocer como el mundo ‘open source’ Unix lleva años haciendo esto, puede enriquecer el mundo ‘open source’ Windows, cada vez más potente y rico y sobre todo nos puede ayudar a evitar reinventar la rueda.

En resumen un libro excelente, más que recomendable, que merece la pena leer y comprar. Sin duda va a ocupar un lugar preeminente en mi biblioteca y con seguridad va a inspirar post en este blog.

¡Un saludo!

Pregunta a la comunidad: ¿Queréis un wiki en Geeks·ms?

Una de las posibilidades que tiene Community Server, la plataforma sobre la que corre Geeks·ms es contar con un Wiki. Esta posibilidad lleva ‘dormida’ mucho tiempo. No se si activar está posibilidad o no. De aquí las preguntas que hoy lanzo.

¿Os gustaría contar con una Wiki en Geeks·ms?
Los editores serían todos aquellos que tengan un blog en Geeks·ms ¿qué contenidos adicionales a vuestro blog pondríais en ese Wiki?
¿Qué sugerencias tenéis, como autores o lectores de Geeks·ms sobre este asunto?

Podemos contar con más de un Wiki, pero tal y como yo lo veo, creo que debería haber solo uno que aglutinase todo el conocimiento que pudiésemos almacenar sobre los temas que habitualmente tratamos en Geeks·ms.

Lo que quiero es valorar si la comunidad cree que un Wiki aportaría valor a Geeks·ms. La duda se me plantea por que al contrario que los blogs, los foros que tenemos disponibles desde hace mucho tiempo, no parecen tener mucho movimiento.

Esta vez, más que nunca, espero vuestros comentarios. Si no hay comentarios, supondré que la idea no despierta interés.

¡Un saludo!

Sobre gurús y telepredicadores…

Escribía hace algunos días Juan Palacio en su imprescindible blog navegapolis.net sobre la proliferación de gurus de lo ágil (antes proliferaron los gurús de la gestión del riesgo, de CMMI, de…). Gente que por cursos de dudosa útilidad, más allá de regodearse en la obviedades de lo ágil, cobran autenticas burradas. Comparto la apatía de Juan hacia este tipo de gurú (o telepredicador).

Yo siempre he estado en contra de los cursos de Scrum generalistas. En Plain Concepts no los ofrecemos. No tiene sentido dedicar dos días de tu precioso tiempo ha hablar de las generalidades Scrum, Lean, XP…, es algo que se puede aprender con la excelente bibliografía disponible sobre el tema. Los fundamentos de Scrum (y de la agilidad en general) se aprenden en diez minutos y se le pueden hasta explicar a tu abuela. Otra cosa es aplicar lo aprendido. Ahí si que puedes necesitar ayuda. La teoria es fácil, hay que conocerla pero es facil, la práctica dificil.

Aprender Scrum de verdad no puede hacerse, no tiene sentido , si no es en un marco concreto de aplicación práctica, con un equipo concreto, para un proyecto o proyectos concretos. Ahí es donde está la dificultad, Ahí es donde quizás un experto en la materia pueda hacerte falta. Alguien que de verdad se haya fajado en el barro, que se haya pegado con montar todas las practicas de ingeniería del software que rodean la agilidad, con soportar la agilidad con las herramientas adecuadas, o con temás tan simples y obvios, pero tan olvidados, como adecuar tu política de gestión de la configuración a tu metodología ágil.

Como comenté en el post de Juan, en mi opinión, lo que separa a un gurú de un telepredicador son los resultados, nada más. La puesta en escena es similar, la verborrea parecida, los powerpoints igual de deslumbrantes… pero los resultados, los resultados no. Hay mucha gente dando cursos de Scrum o Lean o XP o lo que sea, mucha más escribiendo sobre el mismo tema, bastantes más luciendo certificaciones y certificando a otros… pero no hay tanta gente que pueda enseñar un palmarés de resultados significativo. Si no funciona simpre podremos llamar al Gran Vidente Africano…

No son tantos los gurús que pueden decir, mira, por qué no te vienes a este cliente conmigo o a este otro o aquel que es de tu sector y hablamos de cómo hemos transformado la gestión de proyectos en su organización, de que resultados hemos obtenido, de que ha ido bien y que no ha ido tan bien… y también, ya que estamos, de si el resultado ha sido satifactorio y el gurú era tal.

Mucha gente puede venderte la moto de la agilidad, y enseñarte a jugar con postits, pero no tantos pueden transformar la manera en la que tu equipo de desarrollo funciona. Solo estos son gurús. Y es que en esto de la agilidad, como en todo, una cosa es predicar y otra dar trigo.

Por cierto antes de que alguien tire con dardo en los comentarios: no, no me considero un gurú, no le llego a la altura del zapato al Gran Vidente Africano (que ya me ha solucionado dos fugas de memoria y tres deadlocks con un conjuro llamado SOSEX o quizás ese fue el Maestro Sr. Doval)…

Gran vidente africano

…pero sí, tengo claro que puedo ayudarte a llevar la agilidad a tu empresa.

¡Un saludo!

¿Qué hacer si MSMQ tarda mucho en enviar el primer mensaje?

MSMQ es una de esas tecnologías que de repente reviven, y pasan de ser usadas por unos pocos a ser ampliamente utilizadas. WCF y la popularidad que las arquitecturas EDA (Event Driven Architecture) han ganado tiene que ver mucho con este renacer. WCF ha facilitado enormemente la utilización de MSMQ llevando las ventajas de las comunicaciones basada en mensajería a una infinidad de arquitecturas. Si queréis saber más sobre el tema no os perdáis un webcast muy interesante del que ya hablé hace un tiempo: Webcast: Patrones para arquitecturas orientadas a eventos y mensajes.

WCF pone una capa de abstracción sobre MSMQ que facilita enormemente su uso, pero que también dificulta en cierto modo la detección de problemas. No debemos olvidar que MSMQ esta debajo de WCF. Y todas las abstracciones fugan. Es en ese momento cuando tenemos que bajar de nivel y ver que pasa en MSMQ. Son muchos los aspectos de MSMQ que pueden penalizar el rendimiento o la estabilidad de nuestra aplicaciones, por mucho que WCF abstraiga los aspectos más truculentos. La fuente última de información sobre MSMQ una tecnología de Microsoft no muy bien documentada es un documento, de ciento y pico páginas, nada fácil del encontrar llamado Message Queuing Frequently Asked Questions. Regencia imprescindible para cualquiera que use MSMQ en sus aplicaciones.

Hoy voy a hablar de una de esas situaciones en que hay que trastear con los oscuros parámetros de MSMQ, un sniffer de red y los contadores de rendimiento para lograr que nuestra aplicación funcione como debe.

Hace unos días recibí una llamada de un cliente. Una aplicación que funcionaba perfectamente en decenas de instalaciones no se comportaba como debía. La primera vez que realizaban unas acciones (que yo sabía que implicaban el envío de un mensaje de MSMQ mediante WCF) la aplicación tardaba un motón de tiempo (alrededor de un minuto) en arrojar resultados. Esto era especialmente molesto, pues el patrón típico de uso de la aplicación era largos tiempos de inactividad seguidos de momentos en que debía responder rápidamente.

Una cosa que mucha gente desconoce de MSMQ es que trabaja mediante sesiones (ojo, no confundir con las sesiones de WCF, nada que ver). Siempre que en una arquitectura nos encontramos con ‘sesiones’ sean del tipo que sean, sabemos o podemos intuir dos cosas: que establecer esas sesiones tiene un coste y que las sesiones tienden a caducar tras ciertos periodos de inactividad para ahorrar recursos. Pues bien, esta es la clave del asunto que hoy nos preocupa: típicamente iniciar una sesión de MSMQ es un proceso que no debe llevar más de unos milisegundos. De todos modos es un proceso complejo que implica numerosos elementos de nuestra infraestructura de red y comunicaciones: consultas DNS, consultas al directorio activo, autenticación de usuarios y el intercambio de unos cuantos intercambios de información por la red. Podéis ver el proceso en la siguiente captura de red (realizada con Microsoft Network Monitor):

MSMQ Session

La parte resaltada en rojo, se corresponde con el establecimiento de la sesión de MSMQ. La parte resaltada en azul con el envío del primer mensaje. Si en alguno de los paquetes intercambiados hubiese un retardo relevante, con alta probabilidad, tendríamos un problema relacionado con la apertura de sesiones.

En esta situación, la solución pasa por ver que elementos de nuestra infraestructura subyacente está fallando. Más adelante comentaré algunas opciones para resolver esta cuestión, pero ahora voy a comentar un workarround rápido para el problema. Es evidente que una táctica que podemos usar, es evitar que las sesiones de MSMQ caduquen. Así solo pagaremos el peaje del retardo en una única ocasión. Para controlar el tiempo que tardan en caducar las sesiones de MSMQ hemos de modificar el valor CleanupInterval en la clave HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSMQParameters que controla el tiempo de caducidad de las sesiones de MSMQ. Hay que resaltar, ya que la documentación no lo dice que debemos establecer este valor tanto en el cliente como en el servidor pues prima el menor de ambos (anda que no me dio quebraderos de cabeza este tema). El valor máximo es 0xffffffff milisegundos, unos cincuenta días.

MSMQ Session Cleanup Interval

Para monitorizar el comportamiento de las sesiones de MSMQ lo mejor es usar los contadores de rendimiento de MSMQ: 

MSMQ Sessions Performance Counter

Evidentemente este ‘workarround’ tiene efectos laterales:

1) Cada sesión abierta consume una CAL de servidor. Si agotamos esas CAL, sucesivos clientes no se podrán conectar. Además hay que recordar que en un sistema operativo que no sea de servidor como máximo podremos tener diez sesiones abiertas simultáneamente.
2) Mantener sesiones, consume recursos y puede afectar a la escalabilidad.

Evidentemente lo aquí comentado solo minimiza el problema pero no los resuelve. Algunas recomendaciones para diagnosticar este tipo de problemas son:

– Usar la IP del servidor a establecer la dirección de la cola remota. Nos ahorraremos la resolución de nombres y podemos diagnosticar si el retardo de establecimiento de sesione tiene que ver con esto.
– Usar colas privadas, sin autenticación y sin transaccionacionalidad. Nos ahorraremos consultas al AD para localizar las colas, para autenticar usuarios y nos ahorraremos mensajes de ACK de MSMQ para mantener la transaccionacionalidad.

¡Espero que os resulte interesante!