Mes: noviembre 2006

Leyendo el post de David Salgado contando que Bruce Lee también programa y la demanda creada por las camisetas, se me ocurrio que estaría bien hacer unas camisetas de Geeks.ms (trendré que idear como financiarlas, eso sí…), aprovechando algo del estilo Bruce Lee…. Así que estoy tratando de buscar un texto basado en el ya famoso de Bruce Lee, pero relacionado con Geeks.ms. La idea es el logo de Geeks.ms en el pecho y el texto en fuente consola en la espalda. De momento lo que tengo es:

Log on your PC!!!
Be like code, refactor it…
Be the database, normalize it…
Code the scripts…
Apply the fix…
Be like a bit…
Blog about this…
Be a geek, my friend…

Bruce Geek

A ver si entre todos lo mejoramos (no lo veo redondo del todo) y hacemos unas camisetas… pero creo que he explicado la idea.
¿Os parace buena idea?

Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente, y  que uno de los motivos por los que me gusta es porque tiene reglas claras. Creo que una buena aproximación para conocer Scrum es conocer sus reglas y por eso he decido traducirlas al castellano. La fuente de estas reglas es el libro Agile Project Management with Scrum de Ken Schwaber.

El Sprint planinng meeting es una reunión que tiene una duración fija de no más de 8 horas, divididas en dos partes iguales de 4 horas. La primera parte sirve para seleccionar el Product Backlog y la segunda para preparar el Sprint Backlog.

• Los asistentes son el ScrumMaster, el Product Owner y el Equipo. Otras partes pueden ser invitadas por cualquiera de los anteriores para proporcional información adicional sobre el dominio del negocio o la tecnología, pero saldrán una vez proporcionen esta información. No hay gallinas como observadores.
  


• El Product Owner debe preparar el Producto Backlog antes de la reunión. En ausencia del Product Owner o del Product Backlog, el ScrumMaster debe construir un Product Backlog antes de la reunión y sustituir al Producto Owner.
  


• El objetivo de la primera parte, o las primeras 4 horas, es que el Equipo seleccione aquellos elementos del Product Backlog que cree que puede comprometerse a transformar en un incremento de funcionalidad potencialmente entregable. El Equipo demostrará esta funcionalidad al Product Owner y a los stakeholders en el Sprint review meeting al final del Sprint.
  


• El Equipo puede hacer sugerencias, pero la decisión de que elementos del Product Backlog pueden formar parte del Sprint es responsabilidad del Producto Owner.
  


• El Equipo es responsable de determinar que parte del Product Backlog, seleccionado por el Product Owner para ese Sprint, va a tratar de implementar durante ese Sprint.
  


• Limitar el tiempo para la primera parte a 4 horas significa que este es todo el tiempo disponible para analizar el Product Backlog. Un análisis más profundo debe ser realizado durante el Sprint. El Producto Backlog de alta granularidad y alto nivel puede no ser entendido con suficiente profundidad durante esta parte del Sprint planning meeting, lo que puede tener como consecuencia que el equipo no sea capaz de completar todos los elementos que seleccione del Product Backlog.
  


• La segunda parte del Sprint Planning Meeting ocurre inmediatamente después de la segunda y también durará como máximo 4 horas.
  


• El Producto Owner debe estar disponible para el Equipo durante la segunda parte para responder aquellas preguntas que el Equipo pueda tener acerca del Product Backlog.
  


• Es labor del Equipo actuar solamente en su propio nombre y sin ninguna dirección externa al mismo, para encontrar durante esta segunda parte como transformar la parte seleccionada del Product Backlog en un incremento de funcionalidad potencialmente entregable. Nadie más tiene permiso para hacer nada que no sea observar o preguntar para buscar más información.
  


• El resultado de la segunda parte del Sprint planning meeting es una lista, llamada Sprint Backlog, de tareas, estimaciones de tareas y asignaciones que dará comienzo al trabajo del Equipo para desarrollar la funcionalidad. La lista de tareas puede no ser completa, pero debe ser suficientemente completa para reflejar el compromiso mutuo por parte de todos los miembros del Equipo y guiarles durante la primera parte del Sprint, durante la cual el Equipo puede encontrar más tareas a añadir en el Sprint Backlog.

He decidido dejar en inglés algunos términos centrales de la metodología porque lo habitual es citarlos en inglés (o al menos en spanglish). Las partes directamente traducidas, aparecen en cursiva. Lo que busco con esta traducción es para que os animéis a comentar estas reglas: si creeís que son buena idea, si veis posible llevarlas a la relalidad, si ya usaís alguna parecida en vuestra metodología actual etc… Me gustaría que se generase un poco de debate sobre Scrum, en definitiva.

Escribía hace unos días sobre las estimaciones y como se tienden a tratar como compromisos. Pero es evidente que los desarrolladores, en lo que a las estimaciones se refiere, nos encontramos en las dos caras de la moneda a menudo: realizamos estimaciones y tambien recibimos estimaciones. Hoy la cara de la moneda que me interesa es la de recibir estimaciones.

Generalmente cuando recibimos estimaciones es porque nos encontramos en una situación de autoridad dentro del proyecto y nunca debemos olvidar que la autoridad conlleva responsabilidad. Somos responsables de cómo tratamos estas estimaciones. Y la máxima es clara: No conviertas las estimaciones que recibes en compromisos.

Convertir las estimaciones en compromisos genera una serie de problemas que dañan a corto o medio plazo el desempeño general del proyecto. Gestionar un proyecto es en esencia un problema de manejo de información. Hemos de conseguir información veraz y actuar interprentando esa información para guiar el proyecto. Convendreís conmigo que obtener información veraz es imposible si no existe confianza.

Pues bien, cuando convertimos las estimaciones en compromisos, estamos dañando nuestra gestión del proyecto, porque precisamente estamos dañando la calidad de la información con la que contamos y la confianza de quien nos dió la estimación.

Al convertir una estimación en un compromiso no estamos haciendo otra cosa que engañarnos a nosotros mismos. Sabemos que alguien nos dio una estimación, basandose muy probablemente en información insuficiente, sin tener un conocimiento a fondo de lo que estaba estimando. No puede ser de otra manera. ¡Y sin embargo nos la tomamos como una verdad absoluta! e ¡incluso se la comunicamos a otros implicados en el proyecto, probablemente a nuestro jefe! Y entonces ya no hay marcha atrás: con una alta probabilidad estadística (ver el gráfico del anterior post sobre estimaciones) estamos manejando una estimación poco ajustada y muchos otros miembros del proyecto también. La consecuencia es clara, estamos barajando información incorrecta, luego dificilmente vamos a poder tomar decisiones correctas sobre el proyecto. Y no solo eso, haciendo de las estimaciones compromisos, renunciamos a refinar las estimaciones. ¿Para que vamos a refinarlas si ya son compromisos? Solo tenemos que limitarnos a cumplirlas. ¡Cumplir estimaciones que no son fiables! Y este el proceso de refinar las estimaciones es de gran valor, no solo porque nos lleva a ir consiguiendo estimaciones que si son realmente fiables, sino porque en ese proceso encontramos un montón de información valiosa sobre el proyecto.

El otro aspecto a tener en cuenta es que convirtiendo estimaciones en compromisos dañamos la confianza de quien nos dio la estimación. Al fin y al cabo solo estaba estimando y nosostros sin embargo ¡hemos convertido su estimación en un compromiso!. Desde luego no estamos estableciendo las bases de una relación basada en la confianza. Y sin la confianza de los implicados en el proyecto nunca lograremos encontrar información veraz en la que basar la gestión del proyecto. Una variante, aun peor, de esta situación es cuando hacemos estimaciones sin contar con la persona que va a realizar la tarea. Solo quien es el responsable de realizar una tarea puede estimarla, solo él conoce las limitaciones y ventajas con las que cuenta para enfrentarse a la tarea. La siguiente tira de Dilbert lo deja clarito:

Cada vez más desarrolladores descubren el poder de C++/CLI como lenguaje en plataforma .Net y la facilidad para migrar programas existentes en plataforma nativa, añadirles funcionalidades usando el framework de .Net o combinar componentes nativos y manejados en nuestras aplicaciones sin pagar el coste de Interop, por solo citar algunas de las ventajas de este lenguaje.

Pues bien hay una serie de recursos en castellano que nos ayudaran a introducirnos en este lenguaje:

De la mano del amigo Rafael Ontivero tenemos un excelente tutorial en PDF de introducción (y algo más) a C++/CLI.

Zephryn Xirdal y el gran Octavio Hernandez han traducido «A Design Rationale for C++/CLI«, de Herb Sutter, obra fundamental para conocer como se gesto C++/CLI y todo un tradado de ingeniería del software en lo que a diseño de lenguajes se refiere. Todo interesado en C++/CLI debe leerlo.

Por último un buen tutorial en inglés y una interesante FAQ, tambien en inglés, sobre C+/CLI mantenida por Tomás Restrepo, MVP de C++.

Espero que disfruteís estos recursos y os animeís a conocer C++/CLI, el hermano más potente de la familia de leguajes .Net.

Agile Project Management es un buen libro, no ya solo sobre metodologías ágiles sino sobre gestión de proyectos en general. Este libro no explica ninguna metodología en particular, sino más bien, la base de fundamentos y principios que se aplican a toda metodología ágil. El libro resultará útil a aquellos jefes de proyecto que vienen desde la gestión de proyectos 'clásica' pues explica a fondo los principios sobre los que se sustenta la gestión ágil de proyectos. En este mismo sentido tambien resulta el libro esclarecedor a la hora de mostrar que las metodologías ágiles tienen todo un cuerpo de conocimiento que sustenta sus prácticas y que este cuerpo de conocimiento no esta basado solo en la práctica, sino en fundamentos cientificos. Un 'ataque' común a las metodologías ágiles ha sido su falta de formalismo, este libro muestra como debajo de las metodologías ágiles existe una seríe de fundamentos ferreos y bien conocidos que deben guiar el quehacer del jefe de proyectos ágil.

La verdad es que el inicio del libro es un poco 'tostón' pero va de menos a más. Especialmente brillantes me parecen las partes dedicadas a la formación de equipos, la importancia de la información y la parte final comparando el enfoque de un jefe de proyecto guiado por un plan y uno ágil y dando indicaciones, realmente clarificadoras, para dar el salto hacia la agilidad.

Lo que menos me gusta es el tono en plan que bueno soy, que bien lo hago, que bien lo hace mi empresa y que bien os iría contratandonos que destila el libro en algunas partes.

Cuando habla de como escalar la aplicación de metodologías ágiles a proyectos muy grandes, no dice nada nuevo, básicamente propone el ya conocido enfoque de equipos con interfaces de comunicación.

En resumen, un libro interesante principalmente para quien quiera encontrar una explicación a ciertas prácticas ágiles y para quien quiera dar el salto a la agilidad desde la gestión clásica del proyectos. Tambien será de interés para todos aquellos interesados en los aspectos más relacionados con cuestiones humanas de la gestión de equipos y proyectos, como el reparto de poder, el liderazgo, los flujos de información o la construcción de una visión común. Por encima de todo es un catálogo bastante acertado de las actividades que lleva a cabo un jefe de proyectos ágil y los fundamentos que se esconden bajo estas.

Bueno, bueno… que duro es esto del Tech Ed. Sesión tras sesión y charla tras charla entre sesiones se va abriendo ante uno un nuevo mundo de técnicas y tecnologías en las que profudizar. Eso es lo malo del Tech Ed, te enteras en una semana de lo mucho que desconoces y cada sesión y cada conversación de pasillo te abre la 'necesidad' de profundizar en un montón de nuevas areas. En el Tech Ed se aprende mucho, sin duda, pero lo que más aprendes es lo que te queda por aprender…

Comenzaba el tercer día con una sesión excelente de Paul Andrew titulada Building Rules-Based Systems in Windows Worflow Foundation. En esta sesión descubría una faceta totalmente desconocida de WWF: cuánto nos ayuda para hacer sistemas basados en reglas. La principal ventaja de este tipo de sistemas es que podemos modificar el comportamiento de nuestra aplicación y cambiar sus reglas de negocio sin tener que recompilar nada. Paul Andrew habló sobre los motivos para usar reglas e hizo unas cuantas demos interesantes sobre como llevar este enfoque a la práctica la verdad es que no es complicado para nada. Destacar que hasta ahora para desarrollar un sistema basado en reglas teníamos que usar Microsoft Bussines Rules Engine que es parte de Biztalk o implementar nosotros un motor de reglas, que no es tarea trivial. Para los que esteís interesados en este tema teneís un artículo y un webcast.

Despues de esto venía una sesión de Beat Schwegler y Don Smith, Proven Practices for Implementing Services. Interesante sesión en la que nos mostraban las mejores practicas a la hora de implementar servicios con WCF. A destacar: Orientar las interfaces de nuestros servicios a mensajes y no a parámetros, usando este enfoque la clase que implementa el mensaje puede tambien contener la lógica de validación, versionado, logeo y persistencia. Además podemos usar clases parciales y atributos para separar la parte puramente de mensaje, de la parte de lógica relacionada con el mensaje.

La siguiente sesion del día era What´s new en Visual C++ "Orcas" de Steve Teixeira. De esta sesión salí con la sensación de siempre, que Microsoft seguirá trabajando en Visual C++ porque tiene una base de código de millones de millones de líneas y por tanto para ellos es vital. Que las novedades no serán muy espectaculares y vendrán sobre todo por el lado de mejorar el IDE (tendremos class designer y refactoring) y hacer un STL mucho más amigable a las clases manejadas, que seguiran poniendo empeño en que pasar de manejado a no manejado sea transparente. MFC soportará los nuevos controles y estilos de Vista. Ninguna novedad espectacular, pero todas ellas necesarias es el resumen. Van a mejorar el soporte a la construcción de MSBuild para proyectos VC++, por ejemplo paralelizando la construcción de modulos. Tambien liberarán ATL Server bajo Shared Source License. Conclusión: VC++ no esta muerto!!!!

Luego una sesión de las de pizarra sobre Team Syste Best Adoption Practices, para olvidar… 🙁 Saque en claro el consejo ya sabido de configura y no extiendas… seguido de cuatro truquitos no muy espectaculares sobre extensibilidad.

Después de esto llego en mooooomeeeeennnntaaaassssssoooo!!!!!! del Tech Ed. Me dirigia a una sesión sobre mejores prácticas en el testeo con Team System, junto a David Carmona y David Salgado (de MS), Miguel Jimenez e Ibón Landa de Panda Software, cuando se nos hacerco un personaje repartiendo octavillas y CD de Mono… se trataba del mismísimo Miguel de Icaza, personaje de grandísima relevancia en el mundo Linux, tan defendido como denostado. El caso es que el tipo nos invitaba a ir a su charla de esa misma tarde… y cuando veía que el grupo tenia algo que ver con Microsoft y sus comunidades comenzo a hablar con nosotros… Una hora larga de conversación!!! o quiza debería decir de MONOlogo… porque el tio es como Boris Izaguirre poseido por el espiritu de la tecnología… en una hora le dio tiempo a despotricar de Novell (por el acuerdo con MS), de las comunidades de Linux (por sus enfrentamientos internos), de WCF y WPF (por ser un mamotreto, ambas dos están 'sobre ingenieradas'), dejarnos claro que el tendría la razón discutiesemos de lo que discutiesemos (supongo que 20 millones de $ le inflan el ego a cualquiera) y decir que el lo que queria es pasar a la historia… por ser quien hizo el Ruby On Rails de las interfaces de usuario, o de las comunicaciones, o de las patatas bravas o de la ensaladilla rusa… que más da… se trata de pasar a la historia. La conclusión que saque del rato de conversación es que el futuro de Mono estaría mucho mejor en las manos de David Carmona, David Salgado o Miguel Jimenez que en las de ese personaje. En un rato de conversación cayo un mito… 🙁

Empezaba mi segundo día de Tech Ed con el afán de acudir a una sesión de discusión alrededor de una pizarra que realmente sonaba muy golosa: Test Driven Development: Myths and Misconceptions, pero el metro me jugó una mala pasada y llegué tarde, solo pude ver de esta sesión el cartel de "Session Full", que se está repitiendo en este Tech Ed a menudo. Aproveché la situación para responder unos cuantos correos y ocear un poco por internet. El Tech Ed es tan inteso que a veces viene bien el perderse una sesión, aunque sea involutariamente.

La siguiente sesión que tenía prevista para el día era sobre WCF, Windows Communication Foundation: Building Sercure, Reliable and Transactions Distributed Services de Shy Cohen. Sesión espectacular en el sentido de ver el gran salto que se da a la hora de crear aplicaciones distribuidas con WCF. Los que ya hemos sufrido y amado DCOM no le vimos grandes ventajas a .Net Remoting desde un punto de vista arquitectónico. Las posibilidades en estas dos tecnologías eran similares. Pero con WCF, sucesor de Remoting, el salto cualitativo es muy grande: el sistema de seguridad se ha mejorado y simplificado enormemente, es 'tirao' añadir transaccionalidad a los sistemas distribuidos algo que en los tiempos de DCOM era un auténtico dolor y además el sistema de hosting esta perfectamente preparado para soportar todos los escenarios de alta diponibilidad que se nos ocurran. Sin duda con esta sesión se me han abierto los ojos en cuanto a cuáles son los verdaderos puntos fuertes de WCF frente a tecnologías para aplicaciones distribuidas anteriores. Tenemos una puerta abierta a toda una nueva generación de aplicaciones altamente distribuidas, altamente seguras y altamente fiables. Me gustó especialmente que el enfoque 'seguro por defecto' se haya llevado a las tecnologías distribuidas. Es realmente sencillo lograr que todas las comunicaciones sean cifradas, por ejemplo, eso sí, el coste en rendimiento es importante. DCOM y Remoting eran inseguros por defecto y el modelo de seguridad era tan complejo que rara era la aplicación que lo usaba, y más rara aun la que lo usaba bien.

Luego llegaba el plato fuerte de día. Ivar Jacobson, uno de los padres de UML, RUP y Rational tenía una charla. No podía perderme una charla de una leyenda viva de la informática a pesar de mis ya conocidos recelos hacía UML y las metodologías con mayusculas tipo RUP. Lo que a priori sabia de la charla de Ivar era que estaba trabajando en una especie de versión reducida a la esencia de RUP y del proceso unificado de desarrollo de software, además integrada con Team System, llamada EssUp. La cosa prometía… hasta que empece a ver que es lo que realmente hay detrás. La cosa empezaba a pintar mal cuando antes de la charla pasaba por el stand que tenian en la zona de expositores donde ninguno de los presentes sabia nada de metodologías de desarrollo. Eso si trataron de venderme una certificación, y de que Plain Concepts se interesase en se su partner. El problema es que cuando intente intuir en que 'me iva' a certificar lo único que logré es que me dijesen que me mandarían un mail. Imposible conseguir un cd de evaluación, o documentación. Luego en la charla de Ivar descubriria el porque… no tienen nada!!! Solo tiene el interés claro de subirse a la ola de las metodologías ágiles, lo que viniendo de uno de los precursores de las herramientas y practicas más antiágiles que a visto la industria del software es un descubrimiento clarificador. Señores, ayer vi a Ivar Jabcobson adjurar de su fe, reconocer que RUP no sirve (no explicitamente claro) y presentar una metodología en la que UML no aparece para nada… bueno si, en lugar de historias sigue llamando casos de uso a los artefactos para recoger requisitos. La metodología en si esta muy muy verde, y la integración con Team System no existe, cuando alguien pregunto, no mostraron más que la descripción de la metodología que aparece en la lista de metodologías a seleccionar de Team System. Por ver algo positvo, decir que de la metodología, que se encuentra en pañales, me gusto el hecho de que estubiese totalmente orientada a buenas prácticas. Tu eres quien selecciona las prácticas que quieres usar en cada proyecto. La idea de Ivar es que existan repositorios de estas prácticas que los desarrolladores compartamos y reutilicemos, en la linea de patrones. Podemos decir que las metodologías ágiles han ganado la 'batalla'. Algo va a cambiar en esta industria en los proximos años, sin duda. Ivar, tiene el dinero y la visión necesarias para verlo antes y participar en ese cambio, siempre fue un especialista en subirse pronto a las olas, pero esta vez llega tarde.

Luego acudí a una sesión titulada Windows Vista: Tips and Tricks for Targetiig Key Native Apis from Managed Code. Toda una lección magistral de Catherine Heller sobre Interop y como hacer nuestras aplicaciones manejadas más amigables a Vista y sus nuevas características. Lo que sabe esta mujer de Vista. Me comentaba Catherine Heller durante el vino español que Microsoft ofrecia para la delegación española en el Tech Ed, que creia que había hablado demasiado rápido, pero que va, con Catherine pasa como con Kimberly Tripp, sales de la sesión con la sensación de haber aprovechado el tiempo a fondo, en una hora y pico, has aprendido 'un huevo' de cosas. Por cierto, comentaba Catherine que a corto plazo volverá a España para quedarse, un notición tener a una persona de sus conocimientos y tan accesible de nuevo aquí en España. Entre el amigo Carmona y Chatherin los Train The Trainers van a ser muy muy 'duros'…!!!

Sobre lo ocurrido entre bastidores, destacar que me encontré con Luis Gomez, Technicall Account Manager de Microsoft, y responsable de que yo fuese nominado como MVP por primera vez, Un placer verle y charla con el, después de tanto tiempo, tanto… que no le reconcí en primera instancia!!!. Tambien tome un café con Marino Posadas y me conto la gran cantidad de gente interesante que a entrevistado para dotNetMania en este Tech Ed, así que estad atentos a los próximos números….

Buento tal y como prometí comienzo la serie de 'crónicas' desde el Tech Ed. Ayer era mi primer día, pues no asistí a las 'preconferences'. Fue un día intenso.

Comezabamos la mañana con la Key Note, una especie de prefacio que le ponen todos los años al Tech Ed donde habla algún gerifalte de Microsoft. Este año le toco a Eric Rudder. La verdad es que no fue una sesión tan 'marketiniana' como esperaba.

Ponía Eric Rudder el acento en como la 'industra del software' puede y debe hacer incapíe en la creación de nuevos productos que ayuden a las empresas, en la inovación y en que el resultado sea crecimiento económico. Resaltaba, cómo sin dar la importancia adecuada a la formación, sería imposible lograr atraer y generar nuevos talentos en la industria del software que hagan esto posible. Hablaba de Imagine Cup como catalizador de este proceso. Incluso han invitado a una estudiante pakistani a hablar en la Keynote, explicando su aplicación, una calculadora. Enseño el código, y una cosa me parecio preocupante: las nuevas generaciones no ponen comentarios, ni uno ;). De todos modos está muy bien para una niña de ¡10 años! por cierto certificada como MCP!

Luego se habló sobre el lanzamiento de Office, Vista y Exchange.  Recalcando la necesidad de lograr una experiencia de usuario completa basada en conectar personas, información y procesos de negocio. Para ello propone el acceso a la información desde caulquier lugar, en cualquier momento con cualquier dispositivo. Según la visión lanzada por Eric Rudder el siguiente paso en el camino para las aplicaciones en Windows es:

 Simplificar como la gente colabora
 Ayudar a proteger y gestionar contenidos
 Reducir costes e implementar la seguridad
 Encontrar información

Todo esto apoyado sobre las posibilidades que ofrecen las nuevas extensiones para Visual Studio 2005 y el Framework 3.0 / 3.5, de las que pudimos ver alguna demo de la mano de Anders Hejlsberg, sobre el tan traido y llevado LINQ. Al amigo Eladio Rincón le hubiese puesto los pelos de punta (a mi no, porque no tengo). Basícamente se trataba de cruzar mediante 'joins' datos de una colección con datos provenientes de una base de datos. Evidentemente sin índices de por medio. No se si esto será lo más sano para el rendimiento… espero que no mucha gente se dispare en el pie usando LINQ, pero el poder de esta herramienta es innegable.

A partir de aquí empeza lo realmente técnico del día: tenía por delante tres sesiones, tres, dedicadas a SQL Server!!! La cosa prometía y las espectativas se cumplieron con creces.

La primera sesión del grupo de sesiones sobre SQL Server 2005 a las que asistí fue, Upgrade Benefits of SQL Server 2005 for Developers, de Don Vilen. La verdad es que a estas alturas no has muchas novedades en SQL Server 2005 que no conozca en mayor o menor grado, pero son tantas (mirad la fotografía adjunta de la diapositiva que las enumera) que verlas todas juntitas en una sesión es un ejercicio muy útil de recapitulación. La conclusión de esta sesión es clara: SQL Server 2005 tiene infinitas novedades, muchas de ellas realmente útiles y otras que solo son adecuadas para ciertos escenrios muy concretos. En general me parece peligroso la puerta que se abre a que la base de datos se convierta en un servidor de aplicaciones, por mucho que el ponente se esforzo en dejar claro que esta no es la filosofia.

Luego, continuaba la 'caña al SQL' con dos sesiones que ningún asistente al Tech Ed debería perderse: Kimberly L. Tripp hablando de índices en
Advanced Indexing Strategies I y II. Sesiones que he visto en los tres Tech Ed a los que he acudido. Alguien pensará: ¿a qué biene esta paranoia con los índices? o ¿Es qué Kimberly está tan buena?. El motivo de mi devoción por este tema es que en buenos índices está el 90% de las mejoras de rendimiento que se pueden obtener en SQL Server (y en cualquier otro motor de datos) y el 90% de las aplicaciones tienen detrás una base de datos, luego está claro que una de las mejores cosas que podemos hacer para asegurar que nuestras aplicaciones dan el rendimiento adecuado  es aseguranos de que comprendemos a fondo las mejores prácticas de indexación. Sobre la ponente decir que es impresionante la cantidad de información que puede transmitir esta mujer en dos sesiones. Es como un curso de una semana, exprimido y concentrado. Y nada de solo ppts, sino decenas de demos. Espectacular. Por cierto, Kimberly tiene unos webcast muy interesantes sobre este tema: Best practices in indexing  y New features in indexing and indexing manteinance best practices.

Para 'desintoxicarme' de tanto SQL y hacer honores a mi area como MVP y al lenguaje elejido por los dioses, terminé el dia con una sesión 'de pizarra' en 'petit comitee' sobre como extender las aplicaciones C++ con las posibilidades que ofrece C++/CLI y el framework de .Net. El ponente se hizo toda la charla a base de notepad, compilador y linker, un crack. En mi opnión estubo muy interesante, pero se bajo quiza demasiado a la ensencia y dejo un poco de lado casos más prácticos, que creo que era lo que esperaban el resto de asistentes.

La versión 3.0 del Framework de .Net ha sido liberada oficialmente. Puedes descargar todo lo necesario para poder empeza a usar Windows Workflow Foundation, Windows Comunication Fundation y Windows Presentation Foundation desde los siguientes links:

.NET Framework 3.0 Runtime Components, es el redistribuible necesario para correr cualquier aplicación .Net 3.0
Windows SDK for Vista and the .NET Framework 3.0, es el SDK necesario para poder hacer desarrollos con las tecnologías de .Net 3.0
Visual Studio 2005 Extensions for .NET Framework 3.0 (Windows Workflow Foundation), son los complementos necesarios para poder desarrollar para WWF con comodidad, desde Visual Studio 2005
Visual Studio 2005 Extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP, son los complementos necesarios para poder desarrollar para WCF y WPF con comodidad, desde Visual Studio 2005

Ala, !a disfrutarlo!

Por cierto, estad atentos a Campus MVP, ¡en un futuro próximo tendreís cursos para formaros en estas tecnologías punteras en español!

Me preguntaba uno de los clientes de Plain Concepts, al que asesoro en temás relativos a Team System, sobre que opciones tenía para asegurar que su Team Foundation Server daba un servicio continuado. Tras investigar el tema, he llegado a unas conclusiones que voy a compartir con vosotros. El ánimo es que comprendaís a grandes rasgos cual es el enfoque recomendado para asegurar la alta disponibilidad en Team Foundation Server y proporcionar algunos links interesantes sobre el tema.

Lo primero que hay que saber es que para lograr alta disponibilidad con Team Foundation Server no es recomendable realizar una instalación en una única máquina (Single Server Deployment). Evidentemente la razón es que si instalamos en un único equipo Team Foundation Server la capa de datos y la capa de aplicación no vamos a poder 'clusterizar' la capa de datos.

La estrategia propuesta por Microsoft para asegurar la alta disponibilidad de Team Foundation Server pasa por una doble actuación, a nivel de capa de datos y a nivel de capa de aplicación.

La capa de datos de Team Foundation Server es la parte de la aplicación encargada de almacenar los work items, la fuentes que se encuentra bajo el control de versiones, los resultados de las pruebas y otras métricas del proyecto. Está construida sobre Sql Server 2005. Para esta capa de la aplicación la alta disponibilidad se logra construyendo un cluster de Sql Server 2005. Podeís encontrar información sobre como crear un cluster de Sql Server 2005 en el documento "How to: Create a New SQL Server 2005 Failover Cluster (Setup)". Una vez tenemos el cluster de Sql Server 2005 funcionando, debemos realizar la instalación de la capa de datos de Team Foundation Server, para ello debemos seguir las instrucciones descritas en la guia de instalación de Team Foundation Server en el apartado How to: Prepare a Cluster for Data Tier Installation. Tambien teneís más información sobre este tema en Clustering the Data-Tier Server.

La capa de aplicación de Team Foundation Server es la parte de la aplicación compuesta por una serie de aplicaciones y servicios web que corren sobre IIS. Estas aplicaciones incluyen SQL Server Reporting Services, los servicios de Team Foundation Server y Windows Sharepoint Services. Tambien puede incluir el servicio de construción (Team Foundation Build) y el servicio de cache de fuentes (Team Foundation Server Proxy). Para esta capa la estrategia para soportar alta disponibilidad pasa por tener un servidor de respaldo. Este servidor de sustitución pasará a ocupar el lugar del servidor de producción si a este le sucede cualquier percance. Para poder realizar este remplazo de manera rápida y casi transparente se recomienda que los clientes solo conozcan al servidor Team Foundation Server por el nombre DNS de un servidor virtual, que apuntara en cada caso al servidor real que está funcionando en ese momento, de manera que cambiar el servidor de la capa de aplicación solo requiera actualizar la entrada en el servidor DNS para que apunte al servidor de respaldo. Teneís información sobre como realizar este proceso en el apartado How to: Configure an Application Tier as a Standby de la guia de instalación de Team Foundation Server. Evidentemente tendremos que mantener el servidor de respaldo correctamente configurado y actualizado de manera paralela a servidor de producción. Para activar el servidor de respaldo hay que seguir las instrucciones descritas en Activating a Fail-Over Application-Tier Server.

Os dejo un esquema de cómo es la solución propuesta por Microsoft para la alta disponibilidad. Una imagen vale más que mil palabras…