La masa, el ladrillo, la bota, el bocadillo...

Serías capaz de… ¡por supuesto! o Scrum también da respuestas

Rodrigo Corral — Tue, 30 Jun 2009 06:17:00 GMT

Escribía un interesante post de Miguel Sierra, vecino de blog en Geeks.ms, sobre la implantación de CMMI que ha llevado a cabo su empresa. El post es interesante, y agradezco a Miguel que comparta su experiencias. Por mucho que para CMMI sea rara vez la elección metodológica adecuada, creo que es un marco metodológico que debemos conocer, aunque solo sea por la influencia que ha ejercido en el desarrollo de software en los últimos años. Además a mi ‘me va en el sueldo’, pues me toca apoyar técnicamente la implantación de TFS en organizaciones que han elegido CMMI como marco de trabajo.

Lo que motiva este post es el ‘reto’ que lanzaba Miguel preguntando si seríamos capaces de responder a una serie de preguntas relacionadas con el ciclo de vida de nuestros proyectos. Yo que llevo ya un tiempo viviendo en Bilbao, y se me ha pegado un poco la vena Vasca, no he podido remediar el recoger el guante y decir ‘que te apuestas a que sí"’. Es un poco como el chiste de meter cien vascos en un seiscientos… diciéndoles que no caben. Es un poco como las luchas fictícias entre superheroes tipo Lobezno contra Spiderman.

Aquí van las preguntas de Miguel y la respuesta que Scrum en particular y las metodologías ágiles en general darían, de la mano de TFS:

¿Serías capaz de ...?

Identificar las tareas y pruebas funcionales relacionadas con un requisito concreto

Tras el Sprint Planning Meeting y antes de que cualquier trabajo de desarrollo se realice, el equipo de desarrollo desglosa las historias de usuario (requisitos) en tareas. Toda historia de usuario lleva explícitamente en su definición las condiciones de aceptación (versión ágil de las pruebas de aceptación). Luego la respuesta es si.

Identificar las partes de código fuente a las que afecta un cambio de requisito

Por supuesto. Todo cambio tendrá su historia de usuario asociada. En Scrum no se hace ningún desarrollo sin que pase por el backlog y por lo tanto sin que ese trabajo este definido. Apoyándonos en TFS podemos enlazar los cambios en el código con tareas o requisitos en el momento de hacer checkin… ¿a alguien se le ocurre algo más productivo, menos intrusivo para el desarrollador?. Además para que nadie se olvido lo podemos ‘imponer’ mediante políticas de código

Decir cuando se realizó una tarea en concreto y la cantidad de esfuerzo que supuso

Lo lleva el TFS. Sin salir del su entorno natural, el IDE de desarrollo (sea VS o Eclipse) el desarrollador puede actualizar el estado de sus tareas o bug en el mismo instante en el que comienza su trabajo o lo termina. Y sin cambio de contexto alguno. Evidentemente, aunque en Scrum no nos importa demasiado, es posible responder con facilidad el tiempo que te llevo implementar una determinada tarea, bug o requisito. Otra vez, gracias a TFS con burocracia cero para el desarrollador.

Realizar una estimación precisa de una tarea que ya realizaste en algún proyecto anterior

El Product Backlog se debe estimar, las tareas que forman parte de un Sprint se estiman. Scrum no dice nada sobre como debes estimar, pero la comparación con experiencias anteriores es la técnica que explicita o implícitamente todos usamos. Los equipos ágiles suelen preferir métodos más ligeros y más llevaderos de estimación, basados en mejorar el conocimiento, la responsabilidad compartida y el consenso.

Listar las tareas que tienes pendientes en un determinado módulo de tu proyecto

En Scrum el concepto de ‘hecho’ y ‘no hecho’ es clave para gestionar el avance del proyecto. Sabemos en todo momento que elementos del Product Backlog han sido completado y cuales no. Exactamente el mismo aplica a nivel de Sprint Backlog. No solo eso, además visualizamos este estado mediante los gráficos de burndown.

Decir el tiempo restante para terminar un módulo de tu proyecto

En Scrum evitamos construir por módulos. Un módulo por si mismo no suele se capaz de hacer algo de valor para le cliente. No se trata de completar módulos, sino de liberar en cada momento lo que más valor tiene para el cliente. Tratamos de construir el software en ‘tiras verticales’ que implementan toda la funcionalidad de una determinada historia de usuario. Logramos así un continuo flujo de valor. Mirando el Burdown Chart es muy simple decir cuanto queda para completar el proyecto. Evidentemente podemos filtrar este Burdown Chart para las historias de un area (módulo) concreto.

Sacar un listado de las incidencias de un proyecto y la desviación en esfuerzo, tiempo y coste

Una vez más la respuesta es el Burdown Chart que visualiza cualquier desviación en tiempo real. El Burdown Chart refleja las desviaciones en tiempo, pero todos sabemos que tiempo y coste son magnitudes convertibles en gestión de proyectos. Por ejemplo en este Burdown Chart se aprecia claramente una desviación de 60 puntos en un proyecto de 20 unidades de tiempo.

Sacar un listado de las peticiones de cambio de un cliente

El Product Backlog recoge continuamente todas las peticiones del cliente. Todo lo solicitado por el cliente es gestionado por el Producto Owner utilzando el Product Backlog que permanece vivo a lo largo del proyecto. TFS nos proporciona informes sobre la tasa de cambio que ocurre en el Product Backlog.

Certificar que los requisitos del proyecto han sido entendidos y comprometidos por el equipo de trabajo

Evidentemente. Durante el Sprint Planning Meeting, los desarrolladores entienden los requisitos, hacen preguntas y mejoran su conocimiento. La primera parte del Sprint Planning Meeting se dedica a esto. El Sprint Planning Meeting termina con el compromiso de los desarrolladores de hacer todo lo humanamente posible para lograr implementar los requisitos comprometidos para el Sprint durante el mismo.

Identificar, si una prueba falla, que requisitos se ven afectados

TFS permite asociar pruebas de aceptación y sus resultados con cualquier tipo de work item. Si haces esto, es simple responder esta pregunta. Yo he trabajado con equipos que hacen esto y equipos que no lo hacen. Si hay un tester en el equipo, es muy recomendable.

Entregar una versión del producto, mas o menos estable, al cliente, ahora mismo

Lógicamente. Esto es un problema clásico de SCM. En cierto modo no está ligado a la metodología, sino que es una práctica de ingeniería del software más que recomendable. En Scrum todo Sprint debe terminar con un ‘incremento de funcionalidad potencialmente entregable’. Las políticas de SCM de un proyecto que use Scrum deben adecuarse a este objetivo. Una vez más, aperece aquí, el objetivo de Scrum y de las metodologías ágiles en general de ‘crear un flujo continuo del valor para le cliente’.

Decir el porcentaje de construcción del producto o proyecto y certificar el coste actual, "on the fly", del producto

Una vez más me remito al Product Backlog y a su primo visual, el Burndown Chart.

Decir los riesgos activos que hay en tu proyecto

Claro que gestionamos el riesgo, lo llamamos impedimentos y lo hacemos de una manera un poco diferente. No ponemos tanto énfasis pero todo proyecto Scrum tiene un backlog de impedimentos, que es ‘equivalente’ a la lista de riesgos. Otras metodologías ágiles, sobre todo MSF Agile, hace un gestión del riesgo mucho más explicita.

Enumerar las personas dedicadas al proyecto y el porcentaje de ocupación

Ufff… porcentaje de ocupación… es que alguien en alguna empresa no está ocupado al 100% :). Bromas a parte. En Scrum no nos importa tanto la ocupación del individuo como la del equipo. El concepto de equipo es vital. Pero lógicamente, en todo momento tratamos de ajustar la carga del equipo a su capacidad.

Decirme cuando queda liberado un recurso en concreto

Ummm… si por recursos te refieres a máquinas, servidores, fuentes de agua, y máquinas de café y refrescos… simplemente tratamos de tener los suficiente ;).

Decir las medidas correctivas que has tomado cuando has tenido desviaciones

Todo Sprint termina con una Sprint Retrospective. Se trata de saber que ha ido bien, que ha ido mal y plantear las acciones correctoras. Todas las conclusiones quedan reflejadas en TFS y las acciones correctores necesarias que impliquen un esfuerzo explicito se meten en Product Backlog para su gestión dentro de el marco de un Sprint.

Contar lo que se habló en la ante última reunión de seguimiento con el cliente

En Scrum las reuniones de seguimiento son obligatorias. Ocurren puntualmente con periodicidad predeterminada. En esta reuniones de seguimiento, Sprint Reviews en la jerga de Scrum, se muestra software que funciona mediante ‘demos’. Ocurre, sin excepción, al final de cada Sprint. El cliente puede ver el progreso, no imaginárselo en base a diagramas de Gantt o sesudos informes de seguimiento. Además puede y debe dar feedback sobre lo visto durante el Sprint Review.

Enumerar las tareas y esfuerzo que te va a suponer la puesta en producción

Los equipos ágiles tratamos de hacer de la puesta en producción una hábito. La idea es minimizar el esfuerzo de puesta en producción hasta limites tales que sea inapreciable. Para ello nos apoyamos en técnicas como la integración continua o frecuente y el testeo automatizado. Dicho esto, cualquier tarea que se realice, sea del tipo que sea, se debe meter en el marco de un Sprint.

Como podéis ver Scrum responde las mismas cuestiones que CMMI de una manera diferente, pero las responde. No podía se de otra manera, pues muchas de las cuestiones planteadas por Miguel, son cuestiones universales en la gestión de proyectos de software.

Esto me lleva a pensar… es posible usar Scrum + TFS, para cubrir CMMI Nivel 2… la respuesta es que sí. Precisamente de esto habló mi compañero Jose Luis Soria hace poco en un evento sobre CMMI, a ver si se anima y publica las ppts en Slideshare.

¡Un saludo!

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

Rodrigo Corral — Sun, 28 Jun 2009 19:16:27 GMT

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!

Exprimiendo Scrum: ¿Cuál es tu definición de equipo?

Rodrigo Corral — Thu, 25 Jun 2009 21:34:00 GMT

La problemática de la gestión de proyectos en las organizaciones que desarrollan software se deriva, simplificando el asunto, de dos situaciones: gestionar proyectos muy grandes o gestionar muchos proyectos pequeños. Todos estaremos de acuerdo en que cualquiera de estas dos situaciones es más compleja que la situación, más equilibrada, en la que tenemos un número limitado de proyectos con unas dimensiones limitadas.

De estas tres posibilidades, sin duda la más compleja es muchos proyectos pequeños. Los grandes problemas siempre se pueden dividir en problemas de tamaño medio y reducir así la complejidad, llevarlos a la categoría de ‘un numero pequeños de proyectos medianos’.

El por qué la situación más compleja se da cuando tenemos muchos pequeños proyectos es simple: tendemos a tener más cambios de contexto. Los cambios de contexto se dan al ‘pasar’ de un proyecto a otro y son tiempos perdidos. Si a un número grande de proyectos pequeños, unimos que no hay concepto de equipo, los cambios de contexto son continuos y la caída de productividad acusada. Cuando un proyecto está en manos de una persona y no de un equipo, esta persona inevitablemente es un cuello de botella. No voy ha hablar hoy de los cambios de contexto, en otra ocasión volveré sobre el tema, que ya he tratado, someramente, en alguna otra ocasión.

Cuando tratamos de implantar Scrum en una organización este problema de la gestión de proyectos también nos afecta de manera decisiva. Como hemos comentado se trata de un problema de cambios del contexto y el antídoto de Scrum para los cambios de contexto es el concepto de equipo autoorganizado y autogestionado. La idea clave es que un equipo autoorganizado y autogestionado puede elegir en que momentos introducir los cambios de contexto, y por simple sentido común elegirá los momentos idóneos. Siguiendo con esta argumentación se hace patente que es precisamente en entornos que presentan muchos pequeños proyectos en los que más dificultoso es implantar Scrum y en los que más atención se debe prestar a un tema clave: definir que es un equipo en tu organización.

En empresas con ‘muchos pequeños proyectos’, como la gran mayoría de las pequeñas y medianas consultoras, la gran dificultad pasa por encontrar que es un equipo para esa organización, en primer lugar, y en segundo lugar definir cuantos product backlogs se van manejar.

Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenemos que pasar de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Esa es la gran dificultad.

El principal problema que tenemos en la situación actual es el tiempo que se os va en cambios de contexto, insisto. Probablemente estemos en la típica situación de prioridades difusas, de atender a los fuegos, al cliente que más grita... el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo, por ahí empiezo yo toda implantación de Scrum en este tipo de situaciones, definir los equipos.

Esa definición de equipos se puede hacer atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)... Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.

Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:

1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.

Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Aunque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.

Hay una manera muy simple de saber si hemos hecho esto bien: elegimos un desarrollador al azar y le preguntamos:

¿Tu a qué equipo perteneces?
¿Dónde está vuestro product backlog?
¿Quién son vuestro Producto Owner y Scrum Master?
¿Cuáles son los objetivos de tu equipo para este sprint?

Si recibimos respuestas ambiguas, es que no tenemos un modelo de equipos. Sin un modelo claro de equipos no es posible una correcta implantación de Scrum.

El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo en lugar de algunos proyectos grandes que respondan al modelo simple de Scrum.

Este post, se inspira en una interesante conversación mantenida sobre este tema en la lista de Agile Spain, quizás queráis leer los pensamientos allí expuestos.

¡Espero vuestros comentarios!

Sobre gurús y telepredicadores…

Rodrigo Corral — Tue, 23 Jun 2009 21:45:00 GMT

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)…

…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?

Rodrigo Corral — Mon, 15 Jun 2009 16:27:00 GMT

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):

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_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters 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.

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

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!

He leído: Simple architectures for complex enterprises de Roger Sessions

Rodrigo Corral — Thu, 11 Jun 2009 17:45:00 GMT

Todos los que estamos de una manera u otra vinculados con el desarrollo de software sabemos que hay un enemigo a combatir: la complejidad. El libro que hoy comento es una oda a la simplicidad. Que entendamos las fuentes de la complejidad, sus manifestaciones y las tácticas con las que contamos a la hora de combatirla es la clara motivación que llevo a Roger Sessions.

El libro tiene, a mi modo de ver partes bien diferenciadas, que no necesariamente se corresponder con capítulos determinados.

Hay partes del libro que tratan las matemáticas subyacentes en la complejidad y que ‘prueban’ matemáticamente como las diferentes tácticas que propone para acotar esa complejidad son efectivas. Es la parte más árida del libro, para muchos lectores será prescindible, aunque yo he disfrutado con enormemente con ella. Que nadie piense en formulas matemáticas si no en un tono de divulgación matemática bastante logrado.

Otra parte del libro, lleva al mundo real, mediante fabulas, ejemplos e historias reales la teoría expuesta de manera matemática. La fabulas son en general divertidas y algunas de ellas han inspirado post en este blog: Velocidad de iteración vs Calidad de iteración y Ya, ya... Keep It Simple, Stupid… ¿pero cómo?. De especial interés me ha resultado la explicación que da el autor del enorme fallo de proyecto que se produjo con el sistema informático de la seguridad social del Reino Unido y como lo liga con la complejidad del sistema… aunque mi conclusión tras leer el tema fue que la complejidad estaba en la maraña de subcontrataciones que se transluce… además de en la propia arquitectura.

Otra parte del libro, la dedica el autor a describir de manera formal una metodología, SIP, basada en el concepto de partición (el autor a estas alturas ya ha demostrado que particionar los problemas arquitectónicos es la manera más eficaz de evitar la complejidad) y los principios descritos por las cinco leyes de las particiones:

1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.

Nada nuevo bajo el sol, si cambiamos particiones por subsistemas, y elementos por clases, algo que todo desarrollador con experiencia conoce. De hecho, en la última parte del libro, que quizás sea la más importante desde un punto de vista de pura arquitectura del software, el autor desarrolla un método de análisis, sustentado en las leyes anteriores que permite idéntica los elementos y las particiones en una arquitectura de software. Podéis introduciros en las ideas explicadas en el libro leyendo este artículo del autor: A Better Path to Enterprise Architectures.

El merito del autor, es crear una metodología formal para atajar la complejidad en las arquitecturas empresariales. Esto es algo que ningún otro framework arquitectónico anterior, como TOGAF, FEA o Zachman ha logrado. Estos framework no han ido más allá de construir taxonomías para catalogar nuestros artefactos arquitectónicos, pero sin dotarnos de ningún proceso. En el libro también encontraremos una descripción de los frameworks arquitectónicos más comunes. Podéis leer una comparción entre estos frameworks realizada por el autor en A Comparison of the Top Four Enterprise-Architecture Methodologies.

En definitiva, el libro es interesante, pero sin duda no es una obra imprescindible aunque si es interesante y novedosa. Lo que sí es cierto que la aproximación que el autor hace a la arquitectura empresarial es muy original y totalmente agnóstica de la tecnología empleada. Sea el que sea el tipo de arquitectura empresarial que quieras establecer (una intranet corporativa, un sistema de correo, un ERP…) lo expuesto en el libro es de interés. En cualquier caso, si estás interesado en la arquitectura de más alto nivel, en la arquitectura a nivel empresarial, este es un libro que sin duda debes comprar.

¡Feliz lectura!

Microsoft SDL Process Template: La seguridad, una cuestión de proceso

Rodrigo Corral — Mon, 08 Jun 2009 05:06:00 GMT

Todo comenzó con un mail de Bill Gates. La seguridad era la gran prioridad y Michael Howard ha sido el encargado de materializar, desde un punto de vista técnico, esta nueva visión. Howard enseguida se dio cuenta de que la seguridad era cuestión de dos pilares: la formación de los desarrolladores (Writing Secure Code fué el gran paso en este aspecto) y, sobre todo, una cuestión de proceso. Solo un proceso de desarrollo seguro, daría los resultado necesarios. Así surgió SDL (Security Development Lifecycle). Este proceso, sobre el que podéis saber más gracias al libro The Security Development Lifecycle, es el responsable de la mejora espectacular en seguridad que los productos de Microsoft han logrado en los últimos años. No hay más que ver por ejemplo IIS7 comparado con Apache 2.2.x, como podéis ver en estos gráficos de Secunia:

Los frutos del mail de Bill Gates, han sido muchos: mejoras en las librerías de C/C++, mejoras en el API de Windows, una guía clara a la hora de abordar la seguridad cuando desarrollamos para Windows, el excelente libro: Writing Secure Code, y así un largo etc…

Si hablamos de un proceso de desarrollo de Microsoft, parece evidente que el mejor lugar para que este proceso viva, a parte de los excelentes libros y artículos ya citado,s es en un plantilla metodológica de Team System. Pues bien, el equipo de SDL ha liberado una plantilla que facilita enormemente la implementación de SDL como complemento a nuestro proceso de desarrollo. La calidad de la plantilla es espectacular. No se trata de una de tantas plantillas 'cutres' que hay por ahí dando vueltas… Podéis descargarla y echarla un vistazo, de verdad merece la pena, aunque solo sea como ejemplo de lo que se puede hacer desde le punto de vista de incorporar procesos de desarrollo a TFS con facilidad.

Evidentemente, SDL no es un proceso que toda empresa se deba plantear implementar. Para muchos desarrollos casi con usar FxCop y la seguir las buenas prácticas de seguridad recomendadas por Microsoft es suficiente o al menos todo lo que nuestro clientes van a pagar. Pero hay muchos proyectos en los que implementar SDL nos puede proporcionar un retorno de la inversión claro: banca, administración pública, sitios que manejan datos sensibles o privados en internet, etc… En estos casos SDL y Team System son un excelente camino hacia una implementación sencilla de un proceso de desarrollo seguro, no en vano, el ‘tagline’ de esta plantilla es ‘Making secure code easier.

Siempre se dice, que en seguridad es vital no inventar, ¿qué mejor que usar un proceso de desarrollo que ha dado grandes resultados y que se apoya en nuestra herramienta favorita de gestión de proyectos?

Si este post ha despertado vuestra curiosidad tenéis más información sobre la plantilla en el blog de Brian Harry y en el blog del equipo de SDL.

¡Un saludo!

Modelos de salud: ¿Cúanto tarda una operación determinada de mi aplicación?

Rodrigo Corral — Wed, 03 Jun 2009 05:50:00 GMT

Poder reponder esta simple pregunta cuando nuestra aplicación está en producción nos puede dar un motón de información sobre la salud de la misma. Todo modelo de salud de una aplicación debería darnos la respuesta a esta simple pregunta para las operaciones más significativas que realiza la aplicación.

Evidentemente, en situaciones donde hay problemas de rendimiento, siempre podríamos responder esta cuestión utilizando un ‘profiler’. Pero esto es reactivo, ya hay problemas de rendimiento, y entonces actuamos. Sin duda no es lo más eficiente, lo más eficiente es actuar de manera proactiva, ser capaz de detectar que nuestra aplicación se está comportando de manera anómala en lo relativo a rendimiento y poder tener una pista clara de que partes de la misma están fallando. Con un modelo de salud, parte esencial de toda arquitectura de aplicaciones moderna, podemos detectar estas situaciones.

Una manera, a menudo muy adecuada, de plantear un modelo de salud, es seleccionar una serie de operaciones clave que nuestra aplicación realiza y publicar contadores de rendimiento que nos permitan monitorizar cuanto tiempo están tardando en llevarse a cabo esas operaciones y sobre todo detectar desviaciones de los parámetros normales de funcionamiento.

Supongamos, por ejemplo, que en una aplicación de banca pudiesemos monitorizar el tiempo que tardan en realizarse las operaciones sobre cuentas. Tras poner la aplicación en producción y hacer los ajustes necesarios, sabemos que la aplicación esta funcionando correctamente. Entonces establecemos una línea base para el modelo de salud de nuestra aplicación: las transferencias duran X, los cargos Y, los abonos Z, etc… A partir de este momento podemos detectar de manera temprana variaciones significativas en estos valores y por lo tanto detectar problemas de rendimiento en cuanto se producen, lo que nos da una oportunidad de actuar de manera temprana y que la calidad de servicio de nuestra aplicación no se vea resentida.

Si queréis saber más sobre modelos de salud, no os perdáis la charla que mis compañeros Iván González y Unai Zorrilla dieron en el lanzamiento de Visual Studio 2008 y que está publicada en Channel 9.

Para poder actuar como he descrito, tenemos que saber como publicar mediante contadores de rendimiento lo que dura una operación de nuestra aplicación. Para ello basta con utilizar el API de contadores de rendimento de .Net. En concreto el tipo de contador que utilizaremos en esta ocasión es PerformanceCounterType.AverageTimer32 que siempre debe apoyarse en otro contador de tipo PerformanceCounterType.AverageBase.

El procedimiento es simple. Creamos una categoría de contadores y añadimos a la misma los contadores en cuestión. Cuando termina la operación que queremos medir, llamamos al método Increment del contador de tipo PerformanceCounterType.AverageBase y, aquí es donde viene el truco del asunto, al método IncrementBy del contador de tipo AverageTimer32, pasándole el tiempo empleado por la operación en ‘ticks’. La manera más lógica de obtener este tiempo es utilizar un objeto Stopwatch en concreto la propiedad ElapsedTicks. Destacar que aunque el contador espera ‘ticks’ cuando lo recogarmos desde el monitor de rendimiento, nos informa del valor en milisegundos.

A continuación podéis ver un ejemplo:

using System;
using System.Diagnostics;
using System.Threading;
 
namespace OperationTimePerformanceCounterSample
{
    using System.Diagnostics;
 
    namespace OperationTimePerformanceCounterSample
    {
        class OperationTimePerformaceCounter
        {
            Stopwatch _sw = new Stopwatch();
            PerformanceCounter _pc;
            PerformanceCounter _pcBase;
 
            public OperationTimePerformaceCounter(string categoryName, string counterName, string counterBaseName)
            {
                _pc = new PerformanceCounter(categoryName, counterName, false);
                _pcBase = new PerformanceCounter(categoryName, counterBaseName, false);
            }
 
            public void Start()
            {
                _sw.Start();
            }
 
            public void Finish()
            {
                _sw.Stop();
                _pc.IncrementBy(_sw.ElapsedTicks);
                _pcBase.Increment();
            }
        }
    }
 
    class Program
    {
        //Constantes con los nombre de los contadores y categorias
        const string categoryName = "Operation Time Performace Counter Category";
        const string categoryHelp = "Demonstrates usage of the AverageTimer32 performance counter type.";
        const string counterTimerName = "Test Average Time Counter";
        const string counterTimerHelp = "Test Average Time Counter";
        const string counterBaseName = "Test Base Counter";
        const string counterBaseHelp = "Test Base Counter";
 
 
        static void Main(string[] args)
        {
            //Controlamos el Control + C para para la aplicación
            Console.WriteLine("Pulse Control + C para terminar...");
            Console.CancelKeyPress += new ConsoleCancelEventHandler(Console_CancelKeyPress);
 
            //Eliminamos la catergia de contadores si ya existe
            if (PerformanceCounterCategory.Exists(categoryName))
                PerformanceCounterCategory.Delete(categoryName);
 
            //Creamos los contadores necesarios
            //Necesitamos dos contadores, aunque solo se publican como uno solo
            //Uno actua de base y el otro recoge las medidas
            CounterCreationDataCollection counters = new CounterCreationDataCollection();
            CounterCreationData counterTimer = new CounterCreationData(counterTimerName, counterTimerHelp, PerformanceCounterType.AverageTimer32);
            counters.Add(counterTimer);
 
            CounterCreationData counterBase = new CounterCreationData(counterBaseName, counterBaseHelp, PerformanceCounterType.AverageBase);
            counters.Add(counterBase);
 
            //Creamos la categoria y añadimos los contadores
            PerformanceCounterCategory.Create(
                categoryName,
                categoryHelp,
                PerformanceCounterCategoryType.SingleInstance, counters);
 
            //Simulamos una operación
            while (true)
            {
                //La clase OperationTimePerformaceCounter encapsula la medición
                //de tiempo
                OperationTimePerformaceCounter pc = new OperationTimePerformaceCounter(categoryName, counterTimerName, counterBaseName);
                pc.Start();
                SimulateWork(); //Simulamos trabajo
                pc.Finish();
            }
 
        }
 
        static void Console_CancelKeyPress(object sender, ConsoleCancelEventArgs e)
        {
            if (PerformanceCounterCategory.Exists(categoryName))
                PerformanceCounterCategory.Delete(categoryName);
        }
 
        private static void SimulateWork()
        {
            Random rnd = new Random();
            Thread.Sleep(rnd.Next(0, 5000));
        }
    }
}

El código de la clase OperationTimePerformaceCounter que encapsula la medición del tiempo y la actualización de los contadores es el siguiente:

using System.Diagnostics;
 
namespace OperationTimePerformanceCounterSample
{
    class OperationTimePerformaceCounter
    {
        //Objeto Stopwatch para medir la duración de la aplicación
        Stopwatch _sw = new Stopwatch();
        //Contadores de rendimiento
        PerformanceCounter _pc;
        PerformanceCounter _pcBase;
 
        public OperationTimePerformaceCounter(string categoryName, string counterName, string counterBaseName)
        {
            //Abrimos los contadores
            _pc = new PerformanceCounter(categoryName, counterName, false);
            _pcBase = new PerformanceCounter(categoryName, counterBaseName, false);
        }
 
        /// <summary>
        /// Método que llamamos cuando comienza la operación
        /// </summary>
        public void Start()
        {
            _sw.Start(); //Inciamos el cronómetro
        }
 
        /// <summary>
        /// Método que llamamos cuando termina la operación
        /// </summary>
        public void Finish()
        {
            _sw.Stop(); //Paramos el cronómetro
            //Actualizamos los contadores
            _pc.IncrementBy(_sw.ElapsedTicks);
            _pcBase.Increment();
        }
    }
}

Si ejecutamos el código (que puedes encontrar como adjunto a esto post) el resultado será el siguiente, visto con el monitor de rendimiento de Windows:

Espero que os sea útil e incorporéis este tipo de contadores a los modelos de salud de vuestras arquitecturas.

Evento: XXIII Foro de Arquitectos – Novedades en la gestión de proyectos en Team System 2010

Rodrigo Corral — Mon, 01 Jun 2009 05:21:00 GMT

El pasado jueves estuve en el XXIII Foro de Arquitectos de Microsoft, hablando sobre las novedades en la gestión de proyectos en Team System 2010, estas novedades se pueden resumir en que todo lo relacionado con la gestión de proyectos pasa a ser mucho más ágil, tanto la propía metodología MSF, que se parece mucho a Scrum sin peder sus señas de identidad tradicionales (fuerte énfasis en la calidad y gestión explicita del riesgo), como el propio entorno, que es mucho más usable y amigable en lo relativo al trabajo con ‘work item’, informes, etc... Además se han añadido nuevas herramientas, apoyas en Excel, que facilitan muchísimo la planificiación de las iteraciones.

Los que viváis en Barcelona o alrededores, y seáis arquitectos, el próximo 16 de Junio podréis ver esta presatación en directo, junto otro puñado de presentaciones sumamente interesantes en el Foro de Arquitectos que Microsoft llevará a cabo en esta ciudad. ¡No os lo perdáis!.

Os dejo la presentación que hice donde podéis ver pantallazos de todos estos temas. Podéis descargarla desde el menú.

¿Qué os parecen estas novedades?

¡No te olvides de las pruebas unitarias! Sobre todo si tu jefe es un tirano…

Rodrigo Corral — Sat, 30 May 2009 08:38:22 GMT

Un divertido video en el que un jefe de proyecto no precisamente razonable se toma bastante mal que su equipo ‘pase’ de las pruebas unitarias… Los subtitulos están en inglés, pero se entiende…

Estoy por subcontratarle solo para las broncas… jejejeje…

Por cierto para darle un toque de seriedad a post, os recomiendo que no os perdáis la charla de Ibon Landa en Second Nug sobre pruebas unitarias, he hablado con gente que la ha visto presencialmente en Santander y me han hablado muy bien. Y pensar que no inicializaba los punteros cuando llego a Panda a currar conmigo… ;P

¡Saludos!

Subcripciones a eventos de Team Foundation Server con facilidad

Rodrigo Corral — Wed, 20 May 2009 22:03:01 GMT

Una de las múltiples vías que tenemos para extender e integrar nuestro TFS con otras aplicaciones existentes en nuestra organización es poner un servicio web a escuchar los eventos que se producen en nuestro TFS. Podemos escuchar eventos relacionados con ‘work items’, el gestor de fuentes o el servicio de builds. Básicamente lo que tenemos que hacer es crear un servicio que exponga un método con la siguiente firma:

    [WebMethod]
    [SoapDocumentMethod("http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify", RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
    public void Notify(string eventXml, string tfsIdentityXml)

Luego registraremos la url en la que el servicio escucha las notificaciones de TFS utilzando el clásico BisSuscribe.exe o, para aquellos que le tengan más miedo a la línea de comandos, usando Team Fondation Event Subscription Tool.

Nada que no podáis leer en cientos de sitios… la película se complica cuando, una vez subscrito el servicio, tenemos que acceder a la información sobre el evento que se a producido, que recibimos en ¡un string que contiene xml!. Pues bien, la buena noticia es que los esquemas de los eventos son públicos (se pueden encontrar en el directorio Web Services\Services\v1.0\Transforms dentro del directorio de instalación de nuestro TFS (tìpicamente C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\). Así podemos usar XSD.exe para crear una clase a partir del esquema, esta clase nos permitirá deserializar un objeto a partir del string XML que recibimos en los parámetros eventXml y tfsIdentityXml…

Vamos que es un proceso factible pero tedioso. Menos mal que Howard van Ronijen se ha molestado en crear una plantilla de proyecto que nos facilita la labor. Podéis descargarla desde su sitio en Codeplex.

Una vez instalada esta plantilla en nuestro Visual Studio, podemos crear el esqueleto de un nuevo proyecto orientado a consumir los diferentes eventos que TFS expone y además ¡se a molestado en crear las clases para deserializar el XML de notificación de todos las posibles notificaciones! Así es facilísimo interpretar la información que TFS nos envia en la notificación del evento, tal y como podéis ver en el siguiente ejemplo:

    [WebMethod]
    [SoapDocumentMethod("http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify", RequestNamespace = "http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")]
    public void Notify(string eventXml, string tfsIdentityXml)
    {
        BuildCompletionEvent buildCompletionEvent = this.CreateInstance<BuildCompletionEvent>(eventXml);
        TFSIdentity tfsIdentity = this.CreateInstance<TFSIdentity>(tfsIdentityXml);
    }

Por ejemplo para el evento generado cuando se completa una build contariamos con las siguientes clases para manejar la información recibida como string XML en los parámetros de evento:

Vamos, que no puede ser más simple consumir eventos de TFS. Lo que hagáis con ellos, queda a vuestra imaginación.

¡Un saludo!

Presentación: Almacenamiento de datos en la nube

Rodrigo Corral — Sun, 17 May 2009 18:48:00 GMT

El pasado día 16 de Abril participe en un evento para ISVs dentro del programa Metro de Microsoft. El programa Metro es un programa de apoyo a la adopción de nuevas tecnologías de Microsoft por parte de ISVs.

En este evento hablé sobre las posibilidades que la plataforma en la nube de Microsoft plantea a la hora de almacenar datos. Especial interés despertaron los recientes cambios en Sql Server Data Services y se plantearon bastantes preguntas sobre las diferentes opciones con las que contamos y cuando es mejor utilizar una u otra.

Os dejo la presentación que utilicé durante el evento por si es de utilidad.

¡Un saludo!

Evento: Fin de gira ALM’08 de Plain Concepts…

Rodrigo Corral — Mon, 20 Apr 2009 21:34:14 GMT

… al menos de momento.

Por fin llego el final de la función, por esta noche…
es otro día más que va sellando tu destino…

Como dice la versión de MCD de My way, titulada Entre borrachos.

Hace unos meses os contaba que mi compañero Jose Luis Soria y un servidor nos ibamos a ‘currar’ un buen puñado de eventos. Hemos visitado Bilbao, Santiago, Valencia y Zaragoza, con exito de público y espero que de crítica.

Toca cerrar la gira con un evento en Madrid, y tan magna ocasión merece un evento a la altura, así que este jueves, 23 de Abril, estaremos en las instalaciones de Microsoft España con un evento de todo el día. Vamos a hablar de metodologías ágiles y Team System (como a lo largo de toda la gira) y además, de calidad del software con Team System.

La agenda será la siguiente (si os parece interesate, podéis inscribiros aquí):

Sesión: Metodologías ágiles y Team System en el mundo real

Cada vez más empresas necesitan encontrar el equilibrio entre control de los proyectos y productividad de sus equipos de desarrollo, las metodologías ágiles proponen un marco de trabajo que nos permite gestionar los proyectos y mejorar la productividad de nuestros equipos de desarrollo sin caer en la temida burocracia. Team System es un marco de trabajo ideal que proporciona de manera integrada todas las herramientas que un equipo ágil puede necesitar. En este evento veremos cómo un equipo de desarrollo puede usar metodologías ágiles junto a Team System para dar un salto importante en su productividad.

Agenda:

09:00    Registro y bienvenida
09:30    Metodologías ágiles ¿qué son? ¿cómo nos ayudan?
10:00    Introducción a MSF Agile
10:45    Introducción a Scrum
11:00    Café
11:30    Scrum y Team System en el mundo real
12:00    Team System: la herramienta perfecta para el desarrollo ágil
13:30    Comida

Sesión: Calidad del software con Team System

La manera más rápida de desarrollador software es hacerlo con la calidad requerida desde el principio. Team System propone la calidad del software como pieza central del desarrollo de software moderno. Team System proporciona una serie de herramientas que facilitan enormemente que los desarrolladores y los testers hagan de las actividades orientadas a asegurar y mantener la calidad durante todo el ciclo de desarrollo. En este evento veremos cuáles son estas herramientas, cómo se pueden utilizar en nuestros proyectos y qué ventajas obtendremos de su uso.

Agenda:

14:30    Testeo unitario
15:00    Pruebas web y de carga
15:45    Optimización y monitorización del rendimiento de aplicaciones durante el desarrollo
16:15    Refrescos
16:45    Test de aceptación
17:15    Integración de la calidad en el proceso de desarrollo: métricas de calidad
19:00    Fin del evento

El año pasado ya hicimos un evento muy similar a este, solo que en esa ocasión me acompaño Pablo Alvarez Doval. Si queréis ver las presentaciones de aquella ocasión, muy similares a las que utilizaremos, las podéis descargar.

¡Espero veros en el evento!

SQL Server Data Services: Cambio radical en Azure

Rodrigo Corral — Sat, 04 Apr 2009 20:23:46 GMT

Que cosas tienen las tecnologías beta, oiga. De repente, de un plumazo todas las presentaciones, videos, hols, demos y demás sobre SDS resultan obsoletas, así de un plumazo. Incluido el material que yo estaba preparando para el próximo Foro de Arquitectos de Microsoft. Pero bueno, que le vamos a hacer, ya sabíamos a que nos exponíamos.

Seguro que más de uno estáis pensando ¿pero de que habla este tío? Pues hablo de que Microsoft ha decidido cepillarse de un plumazo el modelo ACE (authorities, containers, y entities) de SDS y pasar a soportar un modelo plenamente basado en TDS (el protocolo de comunicación entre cliente y servidor de SQL Server). A pesar de que me han reventado la presentación, creo que este cambio es una excelente noticia y una gran decisión.

Vamos a poder usar todas las características de SQL Server que usamos en el día a día: tablas, tipos de datos, procedimientos almacenados, triggers, índices, ADO.Net, Entity Framework… al menos en teoría, pues aun no se sabe que carácteristicas de SQL Server y del protocolo TDS se soportarán en una primera hornada. Sin duda este cambion también va a acercar otras tecnologías relacionadas con SQL Server más a la nube, como por ejemplo Reporting Services.

Poner nuestros datos en la nube va a ser mucho más sencillo. Será una decisión de despliegue y no una decisión de diseño. Podremos llevar nuestras bases de datos a la nube y que las aplicaciones clientes ni se enteren. Cualquier aplicación existente actualmente podrá subirse a la nube con muchísima más facilidad y sin necesidad de cambios profundos en su arquitectura.

Además no vamos a perder lo que la nube ofrece: alta disponibilidad, tolerancia a fallos, escalabilidad infinita… la arquitectura subyacente de SDS no cambia, es la que ya conocemos. Lo que van a hacer es poner sobre esta arquitectura una capa que entienda el protocolo TDS.

Por el lado de la seguridad, comunicación sobre SSL y autenticación de SQL Server.

En cuanto al soporte REST/HTTP la respuesta es clara: ADO.Net Data Services.

Podríamos pensar, que semejante cambio estratégico se habría anunciado en un PDC, o en el reciente MIX o en un TechEd al menos… pues no. El anuncio se ha hecho 'a la chita callando' un post en el blog del equipo de SDS y una entrada nueva en la MSDN, que describe someramente el nuevo SQL Data Services RDBMS Model .

Para los ansiosos (¡Unai quieto!), decir que hasta que no haya una nueva CTP del SDK de SDS, no podremos disfrutar de lo que va a ser la primera base de datos genuinamente relacional en la nube. Decir que me parece un excelente movimiento por parte de Microsoft: las ventajas de la nube sin tener que aprender un nuevo modelo de almacenamiento.

Además para los nostálgicos de el modelo ACE, siempre quedará Azure Storage Services, cuyo Table Storage API es muy similar a lo que ofrece el modelo ACE.

Por último como curiosidad decir que TDS es una especificación abierta, liberada como parte de la Microsoft Open Specification Promise, que originalmente nació para Sybase. Podéis ver la especificación de TDS, y además existen implementaciones de TDS para entornos Linux/Unix y para Java.

Geeks.ms: Pa’ habernos matao…

Rodrigo Corral — Fri, 03 Apr 2009 21:50:44 GMT

Debido a un fallo en un disco, Geeks.ms ha estado caído todo el día de hoy. No es la primera vez que Geeks.ms se cae, la otra fue por culpa de un huracán. Lo peor a sido el susto que se ha llevado el pobre David Carmona, que tras instalar un parche y reiniciar el servidor, vio que este no volvía a la vida. David, tranquilo, que no has sido el culpable, te has llevado el susto pero no has sido el culpable, jejejej...

Si escribo este post es más que nada para tranquilizar a todo el mundo que tiene contenidos en Geeks.ms. Os voy a contar como está protegido el servidor:

El servidor cuenta con dos discos en RAID 1, esto es lo que nos ha salvado hoy el culo. El problema se ha solucionado cuando la gente del hosting, se ha levantado de la cama y ha reiniciado el servidor desde el disco espejo. Si hemos tenido tanto ‘donwtime’ ha sido por la diferencia horaria, el hosting está en la costa oeste de los estados unidos y por querer diagnosticar cuidadosamente la situación para evitar la pérdida de datos.

Además de la protección por RAID, en caso de un desastre mayor, contamos con una política de copias de seguridad. Todos los sábados por la noche, en el momento de menos actividad se hace una copia de seguridad completa del contenido relevante del servidor y de la base de datos de Geeks.ms. Además, se hacen copias de seguridad incrementales cada seis horas. Esto nos protege de errores lógicos o ataques que puedan dañar el contenido de Geeks.ms

Por si esto fuese poco, estas copias de seguridad se mueven fuera del servidor, a un NAS de almacenamiento, semanalmente. Esto nos asegura que en caso de destrucción total del servidor aun tendríamos copias de seguridad.

Cada cierto tiempo, aproximadamente dos semanas, compruebo personalmente que la última copia de seguridad realizada es recuperable. Para ello levanto desde cero un sitio llamado beta.geeks.ms, que también uso cuando hago adaptaciones de Community Server. Puesto que el NAS y el servidor están en el mismo ‘data center’, además la copia de seguridad verificada se mueve desde el NAS a un servidor de Plain Concepts. En caso de desastre total en el ‘data center’ siempre quedaría la copia verificada almacenada en un servidor de Plain Concepts.

Así que si alguien a sufrido por su contenido durante las últimas, croe que puede estar razonablemente tranquilo. Evidentemente la seguridad absoluta no existe, pero creo que podemos dormir tranquilos.

¡Un saludo y gracias a todos, autores y lectores, por vuestra paciencia!

Ya, ya... Keep It Simple, Stupid… ¿pero cómo?

Rodrigo Corral — Mon, 23 Mar 2009 13:00:00 GMT

Que seguir el principio KISS y mantener nuestras metodologías, nuestras arquitecturas, nuestros diseños, nuestras clases etc… simples nos proporciona innumerables ventajas es algo que todos los desarrolladores de software tenemos claro desde un principio o acabamos aprendiendo a la fuerza. La simplicidad en una característica que, cuando hablamos de desarrollar o diseñar software, es buena en si misma.

La paradoja es, que si bien sabemos lo anteriormente comentados, no es menos cierto que a menudo acabamos con procesos de desarrollo o con soluciones demasiados complejas. Evidentemente hay dos aspectos claves a la hora de luchar contra la complejidad: uno, detectarla, el otro combatirla.

Hoy voy a hablar de que estrategias tenemos a la hora de combatir la complejidad. La verdad es que antes de estar leyendo Simple Architectures for Complex Enterprises de Roger Sessions, no tenía ni una idea explícita sobre este tema. Pero lo que comenta este libro sobre el tema es sumamente interesante. Aunque siempre he creído que la complejidad es uno de los mayores enemigos de los procesos de desarrollo y los sistemas de software nunca me había plantead, antes de la lectura de este libro, de manera explicita, con que tácticas contamos a la hora de atacar la complejidad. Las tres tácticas con las que contamos son: el particionado, la simplificación y las iteraciones.

El particionado consiste en dividir grupos de elementos en elementos menores. Esta táctica es quizás la más poderosa de las tres y, de manera consciente o no, la utilizamos continuamente en el desarrollo de software. Particionados nuestras arquitecturas en capas, de manera que cada una de ellas solo tenga que lidiar con las complejidades propias de su cometido. Nuestra capa de acceso a datos, solo tiene que atacar las complejidades relacionadas con la obtención o persistencia de los datos, pero no se preocupa por las complejidades de la capa de presentación. Particionar la complejidad de manera explicita nos permite atajarla de manera clara. La complejidad crece exponencialmente. Mezclar en una misma capa de la aplicación acceso a datos, e interfaz de usuario, no hace nuestra aplicación el doble de compleja sino que añade varios ordenes de magnitud. Cuando hablamos de arquitecturas SOA, dos de los pilares de SOA abogan claramente por el particionado: los límites de los servicios son explícitos y los servicios son autónomos.

El particionado también es una técnica que las metodologías usan a la hora de reducir la complejidad. Las metodologías ágiles proponer dividir la complejidad de implementar un solución completa en historias de usuario independientes, testeables y simples. Esto es claramente una estrategia de particionado que nos permite atacar la complejidad de un desarrollo en pequeñas historias de una complejidad acotada.

En el libro, Roger Sessions cuenta un caso en el que las particiones reducen la complejidad de forma clara y visual cuando estas son adecuadas. Imagináis una tienda en la que la ropa estuviese ordenada por colores ¿no sería extremadamente complejo el proceso de compra?. Sin embargo en todas las tiendas de ropa las particiones que aparecen tiene sentido: caballeros, señoras, niños…, ropa de vestir, ropa deportiva, ropa de dormir, ropa interior… XXL, XL, L, S… con estas particiones ¡la complejidad de realizar una compra es infinitamente menor que si las partición fuese por colores!.

Una vez tenemos particiones explicitas, podemos proceder a utilizar la simplificación. La táctica de simplificación mas poderosa es la eliminación. No ha táctica más poderosa de simplificación que eliminar aquellas particiones que no son relevantes. Si eliminamos completamente una historia de usuario, hemos reducido su complejidad a cero: no tenemos que diseñarla, implementarla, probarla o mantenerla. Desgraciadamente esto no siempre es posible: debemos eliminar tanto como sea posible, pero evidentemente no podemos eliminar todas las particiones, es necesario un equilibrio. Pero sin duda merece la pena observar nuestro proceso de desarrollo, nuestra arquitectura, nuestros diseños y nuestras soluciones para eliminar todos aquellos elementos, todas aquellas particiones que añadan complejidad.

A veces, si bien no es posible eliminar completamente una partición, si podemos eliminar algunos de los elementos que la componen. Por ejemplo, en un sistema de gestión de almacenes, podemos tener historias relativas a ajustes de almacenes y a informes. No podemos eliminar completamente ninguna de estas particiones sin que el sistema pierda su utilidad, pero seguro que podemos eliminar algunas historias relativas a ajustes y algunas relativas a informes.

La otra manera de combatir la complejidad es la iteración. Implementar las particiones de manera iterativa y revisar la complejidad al fin de cada iteración es un mecanismo poderoso que complementa las dos tácticas anteriores. Os remito aquí a un post anterior sobre velocidad de iteración frente a calidad de iteración.

Recordad, contra la complejidad: partición, simplificación e iteración.

MSBuild Profiler: ¿por qué mi build tarda una eternidad?

Rodrigo Corral — Mon, 16 Mar 2009 06:28:00 GMT

La cuadrillita del Debugging & Optimization Team de Plain Concepts somos bastante fanáticos de los profilers. Hay un arsenal de ellos: el profiler de Visual Studio, el CLR Profiler, el Memprofiler de SciTech, VTune de Intel, el profiler de SQL Server… cada uno con sus puentos fuertes y débiles. Todos estos profilers se centran en mejorar la velocidad de ejecución de nuestros programas.

Pues bien, hoy me he topado con un profiler, el MSBuild Profiler, radicalmente diferente, pero igualmente útil. Este profiler nos permite ‘instrumetar’ una build de MSBuild para analizar donde está fugando rendimiento. El procedimiento es bien simple, este profiler es capaz de analizar la salida de un logger a medida de MSBuild, proporcionado con el propio profiler. Basta con lanzar nuestra build con ese logger como salida para que el profiler nos de información sobre donde se pierde el tiempo en nuestra build, para ello basta con usar el parámetro /l de MSBuild que permite estarblecer el logger de salida que nos interese, en este caso: MSBuildProfilerLogger:

MSBuild.exe buildfile.proj /l:MSBuildProfileLogger,MSBuildProfiler,Version=1.0.1.0,Culture=neutral,PublicKeyToken=09544254e89d148c

Esto arranca una instancia de MSBuild Profiler de manera interactiva. Puede ser que no sea esto lo que nos interese, por ejemplo si queremos lanzar una build con TFSBuild. Para estas situaciones el MSBuildProfilerLogger admite un parámetro file que nos pemite genera un archivo .snapshot con la información de rendimeinto de la build:

MSBuild.exe buildfile.proj /l:MSBuildProfileLogger,MSBuildProfiler,Version=1.0.1.0,Culture=neutral,PublicKeyToken=09544254e89d148c,file=out.snapshot

Luego podremos cargar en el MSBuild Profiler este archivo para ver los resultados, tal y como se muestra en la pantalla siguiente:

Sin duda una herramienta excelente para acelerar nuestras builds.

Velocidad de iteración vs Calidad de iteración

Rodrigo Corral — Thu, 12 Mar 2009 21:18:00 GMT

Estoy leyendo Simple Architectures for Complex Enterprises de Roger Sessions. No me queda mucho así que en breve espero que tengáis una reseña sobre el libro aquí, pero hoy voy ha hablaros de una cuestión que el libro trata de manera muy amena: la velocidad de iteración vs la calidad de iteración.

Cuenta Roger Sessions en su libro una curiosa historia para ilustrar la diferencia que existe en el desarrollo de software entre iterar buscando la mayor velocidad de iteración o iterar buscando la mayor calidad de iteración. Este es un tema que ya he tratado con anterioridad en este blog: No persigas tu cola..., pero la historia que cuenta Roger Sessions es realmente ilustrativa.

El Coronel Jhon Boyd, uno de los grandes pilotos de la época de los primeros reactores de combate y estratega reconocido, estudio una anomalía en la luchas aéreas entre los dos grandes cazas de la década de los 50. Cito aquí la historia tal y como Roger Sessions la cita en su libro, traducida al español lo mejor que he sido capaz, además añado un video sobre el tema (en inglés), que no solo de informática vive el hombre:

"El Coronel John Boyd estaba interesado no solo en cualquier lucha aérea, sino específicamente en los combates entre el MiG-15s y el F-86s. Como ex-piloto y consumado diseñador de aeronaves, Boyd conocía estos dos aviones perfectamente. Él sabía que el MiG-15 era mejor técnicamente que el F-86. El MiG-15 podría subir más rápido que el F-86. El MiG-15 puede girar más rápidamente que el F-86. El MiG-15 tenía una mejor distancia de visibilidad. El F-86 tenía dos puntos a su favor. En primer lugar, tenía una mejor visibilidad lateral. Mientras que el piloto de MiG-15 podía ver más lejos, el piloto de F-86 podría ver un poco más por los laterales. En segundo lugar, el F-86 tenía un control de vuelo hidráulico. El MiG-15 tenía control de vuelo manual.

La hipótesis más común por parte de los diseñadores aéreos era que la maniobrabilidad era el componente clave a la hora de ganar duelos aéreos. Evidentemente, el MiG-15, con su giro más rápido y su capacidad para escalar más rápido, podía mejorar la capacidad de maniobra del F-86.

Pero hubo un pequeño problema con todo esto. A pesar de que el MiG-15 era considerado un avión superior por los diseñadores de aviones, el F-86 era preferido por los pilotos. La razón por la que era preferido por los pilotos fue simple: en los duelos uno-a-uno entre MiG-15 y F-86, el F-86 ganó nueve de cada diez veces."

¿Cómo un avión inferior puede ganar de manera consistente a un avión superior? Era la pregunta que surge rápidamente. Boyd, tenía una teoría:

"Boyd concluyo que la cuestión determinante a la hora de ganar un duelo aéreo no era observar, orientarse, planear o actuar mejor. La cuestión determinante para ganar un duelo aéreo era observar, orientarse planear y actuar más rápido. En otras palabras, como de rápido uno podía iterar. La velocidad de iteración, sugirió Boyd, bate a la calidad de iteración.

La siguiente pregunta que se realizo Boyd es esta: ¿por qué el F-86 iteraría más rápido?. La razón, concluyo, era algo que nadie había pensado que fuese particularmente importante, el hecho de que el F-86 contase con un mando de vuelo hidráulico mientras que el MiG-15 tenía un mando de vuelo manual. Sin ayuda hidráulica, costaba un poco más mover el mando de vuelo del MiG-15 que el del F-86. Aunque el MiG-15 girase más rápido (o pudiese llegar más alto) cada vez que el mando era movido, la cantidad de energía necesaria para mover el mando era mayor para el piloto del MiG-15. Con cada iteración, el piloto del MiG-15 sufría un poco más de fatiga que el piloto del F-86. Según se iba fatigando un poco más, tardaba un poco más en completar su ciclo de observar, orientarse, planear y actuar. El piloto del MiG-15 no perdía por que pilotase peor. Perdía por que completar el ciclo de lucha cada le costaba más tiempo."

De esta observación se deriva la Ley de la Iteración de Boyd: la velocidad de iteración bate a la calidad de iteración.

Hoy en día todas las metodologías de desarrollo son iterativas. No hay otra manera de desarrollar software que en iteraciones en las que se repite la secuencia de combate del desarrollo de software: conocer el problema, analizarlo, implementar la solución, construir, probar (con diferentes variantes). La diferencia es que unas metodologías ponen el peso en la calidad de iteración (CMMI, RUP) mientras que otras ponen el peso en la velocidad de iteración (XP, Scrum). ¿Alguien duda de quien está ganando más combates?. La idea es clara, si te vas a equivocar, equivócate pronto, rectifica rápido en lugar de tratar de no equivocarte por todos los medios y quedarte sin tiempo para rectificar. A veces se describe esto como dinero por flexibilidad en lugar de dinero por información. Las metodologías guiadas por un plan, consumen muchos recursos trantando de asegurar las maniobras adecuadas, las metodologías ágiles tratan de realizar las maniobras de manera rápida y razonablemente adecuada. Si hay problemas siempre se puede rectificar… si el coste de rectificar es razonable y si tienes la ágilidad necesaria para no morir en el intento.

La esencia del software es iterativa, como la esencia del combate aéreo y no deja de ser curioso como ese énfasis en la iteración rápida aparece en todas las buenas practicas de la ingeniería del software, igual que en combate aéreo. Perseguimos encontrar rápido los errores, intentamos incorporar temprano el feedback de los usuarios, intentamos construir el software de manera frecuente y minimizando el coste de construirlo, etc…

¿Qué opinión os merece esta reflexión? ¿Mejor primar la velocidad de iteración o la calidad de iteración?

He leído: More Joel on Software de Joel Spolsky

Rodrigo Corral — Wed, 11 Mar 2009 06:13:00 GMT

Hay libros que se leen y libros que devoran. Aunque no se pretenda de antemano.. Hace menos de dos semanas, llegaba mi regalo de reyes. Un pedido de libros. Entre los cinco títulos que llegaban, estaba este libro que hoy comento. No era el primero entre mis preferencias de los que componían el paquete. De hecho comencé con mi regalo de reyes leyendo otro libro. Pero de repente, un día abrí el libro de Joel y zas… ¡no pude para de leer hasta que lo devoré!. En menos de una semana lo había leído. Los habituales del este blog habréis visto que el libro que tengo entre manos suele aparecer en el ‘sidebar’ del blog, pues en este caso ¡ni siquiera me ha dado tiempo a ponerlo!.

Nada oculta que soy un gran fan de Joel. Ya antes he publicado mi impresión sobre otros de sus libros: Joel on Software y The Best Software Writing I. Muchos de los artículos de este blog están influenciados por él, muchos citan alguno de sus post. Su blog es mi blog favorito, sin duda alguna y espero sus artículos con devoción, una devoción que solo tengo por la columna de Arturo Perez Reverte, en El Semanal y por Miguel Delibes. Vamos que cuando abrí el libro no esperaba ninguna novedad, y sin embargo en cada página he encontrado un aliciente continuo que me impedía dejar de leer. Todos los artículos los había leído con anterioridad, pero leer en papel tu blog favorito no tiene precio, la verdad. Además los artículos están ordenados por temática, lo que da al libro una coherencia, una continuidad y una línea argumental que el blog no tiene.

Es una caña de libro, un libro divertido sobre una multitud de temas relacionados con el desarrollo de software: desde como contratar desarrolladores, a como fijar el precio del software o como crear una empresa de desarrollo de éxito, pasando por… por todos los temas relevantes del desarrollo de software y sus aledaños. Los temas que trata Joel: la gestión del personal en proyectos informáticos, consejos para los futuros programadores, la importancia de diseño, la gestión de grandes proyectos, consejos sobre programación, cómo comenzar un negocio de software, cómo continuar con el, como lograr liberar software y cómo revisar y mantener el software liberado. Todo salpicado de amenas historias que hacen que los temas que trata, muchos de ellos pilares de la gestión proyectos de software, se queden grabados a fuego en la memoria. Sin duda, los libros de Joel son los libros de gestión de proyectos más amenos jamás escritos. Tan amenos que es facil olvidar que estas leyendo sobre desarrollo de software.

Para muestra, un botón: Martian Headsets, en el que habla sobre la falacia de los estándares web. No existe tal cosa como los estándares web, los estándares son una buen idea, de imposible implementación. Memorable. O The Perils of JavaSchools que explica como C es el tamiz que separa el gran de la paja cuando hablamos de desarrolladores. O uno, magnifico, sobre ¿economía? Camels and Rubber Duckies, en el que trata de responder a una pregunta sin respuesta: ¿Cúanto debo cobrar por mi software?. No responde a la prengunta, pero yo al menos ahora se por qué hay cientos de ediciones de Windows… segmentación del mercado, se llama el asunto, y al final la segmentación se traduce en ¡más pasta!… que cosas oigan.

Resumiendo, si ya conoces el blog de Joel, el libro te encantará, si no conoces el blog de Joel, el libro te fascinará y seguro que correrás a comprar los otros dos libros de este autor que menciono en este blog. O mejor aun, comprate los tres de un tirón, seguro que me lo agradecerás. Una compra más que recomendable.

Estaré en SecondNug: 'Herramientas de modelado: en busca del El Dorado'

Rodrigo Corral — Tue, 10 Mar 2009 14:50:00 GMT

Los chicos de SecondNug me han invitado a dar una charla, no se si lograré estar a la altura de mi amado jefe, pero lo intentare. Me pidieron una charla sobre UML. Pero UML ¡es muy aburrido! y el modelado es un campo que está evolucionado de manera muy rápida y continua, así que he abierto un poco más la temática... espero que la charla os resulte atractiva y os animeis a asistir.

Durante décadas, lo que es tanto como una eternidad en el mundo del software, los desarrolladores hemos intentado reducir la creciente complejidad de los proyectos que construimos utilizando la abstracción. La utilización de modelos ha sido una de las técnicas que más adeptos han tenido a la hora de ganar en abstracción. Desde los lenguajes 4GL hasta Oslo, pasando por el omnipresente UML, y las todopoderosas DSL las promesas han sido muchas y los resultados… bueno han sido los que han sido.

En este charla vamos a repasar la historia del modelado, vamos a introducir UML, veremos cómo han evolucionado las herramientas de modelado en la plataforma de desarrollo de Microsoft y sobre todo, vamos a mirar al futuro de la mano de VSTS 2010 y de la de Oslo, la nueva plataforma de modelado y DSL de Microsoft.

El modelado a sido El Dorado del mundo del desarrollo de software, muchos hemos creído en el, muchos lo siguen buscando, muchos intuimos que existe, pero nadie ha encontrado la solución definitiva. Pero por supuesto, en ocasiones, y utilizado correctamente, el modelado nos puede ser de utilidad.

Por cierto el evento será grabado y lo podréis ver cuando queráis.