Plantilla metodológica para TFS con gestor de fuentes únicamente

Todo proyecto, sea cual sea su dimensión y número de desarrolladores necesita tres cosas: un editor, un compilador y un gestor de fuentes. Y no el gestor de fuentes no es opcional, a no ser que quieras exponer tu proyecto a el riesgo de dañar sus fuentes y no poder recuperarte de ese problema.

Dicho esto es cierto que hay proyectos que son tan pequeños que pueden no necesitar de Work Items, informes, portal del proyecto etc… Pues bien, por eso he creado una plantilla metológica que solo proporciona gestión de fuentes. Podeís descargarla desde aquí.

Usar nuestra herramienta de comparación y mezcla favorita con Team System

Poca gente conoce la posibilidad de cambiar la herramienta de comparación y de mezcla que muestra Visual Studio Team System cuando utilizamos el menu Comparar o tenemos que corregir un conflicto en nuestro gestor de fuentes. Yo mismo descubrí recientemente esta posibilidad por pura casualidad (en realidaz buscaba el check que muestra los elementos borrados del gestor de fuentes de Team Foundation Server). Mi herramienta favorita para estos menesteres, como ya he comentado en alguna ocasión es WinMerge, por eso es la que elegido para mostraros como configurar esta interesante opción.


Tenemos que ir a las opciones de nuestro Visual Studio, Options->Source Control->Visual Stuido Team Foundation->Configure User Tools…


Luego tenemos que añadir la herramienta que queremos usar, podemos discriminar por tipo de archivo, o introducir un * para usar la misma herramienta para todos los tipos de archivo. 



Primero podemos configurar una entrada para Merge y otra para Compare…


 


A partir de este momento, WinMerge será la herramienta con la compararémos archivos y resolveremos conflictos.


 


La parte más dificil es saber que poner en la entrada Arguments, que argumentos pasar a la herramienta para que se comporte como debe. Gracias a dios, Jim Manning, ha escrito una excelente guía con los parámetros para todas las herramientas más populares: Merge configuration in Team Foundation.


Otras herramientas que podríamos usar son (extraido del post de Jim Manning):


Herramientas de comparación



































Product Command Arguments
TFS default diffmerge.exe %1 %2 %6 %7 %5 /ignorespace
WinDiff windiff.exe %1 %2
DiffDoc (for Word files) DiffDoc.exe /M%1 /S%2
WinMerge winmerge.exe /ub /dl %6 /dr %7 %1 %2
Beyond Compare bc2.exe %1 %2 /title1=%6 /title2=%7
KDiff3 kdiff3.exe %1 –fname %6 %2 –fname %7
Araxis compare.exe /wait /2 /title1:%6 /title2:%7 %1 %2

Herramientas de mezcla







































Product Command Arguments
TFS default diffmerge.exe /merge %1 %2 %3 %4 %6 %7
KDiff3 kdiff3.exe %3 –fname %8 %2 –fname %7 %1 –fname %6 -o %4
Visual SourceSafe ssexp.exe /merge %1 %2 %3 %4 %6 %7
Araxis compare.exe /wait /swap /a3 /3 /title1:%6 /title2:%7 /title3:%8 %1 %2 %3 %4
Beyond Compare (2-way merge) bc2.exe %1 %2 /savetarget=%4 /title1=%6 /title2=%7
WinMerge (2-way merge) winmerge.exe /ub /dl %6 /dr %7 %1 %2 %4
Guiffy guiffy.exe -s -h1%6 -h2%7 -hm%9 %1 %2 %3 %4
Ellie Computing guimerge.exe –mode=merge3 %3 %1 %2 –to=%4 –title0=%8 –title1=%6 –title2=%7 –to-title=%9

Sobre arquitectos…

Ha montado el amigo Bruno una interesante discursión sobre que es ser arquitecto, quienes pueden llamarse así, y si hay que tener o no una certificación de Microsoft para serlo (aunque no dice esto en ningún momento la gente que ha escrito comentarios parece que lo ha entendido así)…

Aunque en mi tarjeta pone Software Architect, sinceramente yo lo que soy es desarrollador en el sentido más amplio de la palabra, me encanta la arquitectectura si, pero no más que la gestión de proyectos, la optimización, el diseño de bases de datos, etc… Pero quizá eso sea lo que es ser arquitecto, ser alguien capaz de pensar en el software en un sentido amplio, con una visión más ‘a vista de pajaro’, mezclando aspectos técnicos con aspectos de gestión, y con la capacidad de acercarse a aquellas partes de desarrollo de software que requieren una atención especial, que sean especialmente significativas o sensibles. Creo que esto es algo ligado al instinto y la experiencia. Por que si algo tengo claro es que sin mucha experiencia, muchísima y muy variada, nadie puede pretender ser arquitecto. Y tampoco sin un instinto especial. Pero ojo, no todos tenemos que ser arquitectos. Tan valioso o más es un buen programador. Hay que defender el orgullo de ser quien escribe el código.

No es facil de definir la figura del arquitecto, pero a mi personalmente me encanta la ‘definción’ que Scott Guthrie, padre de Asp.net, daba en una entrevista publicada en el Microsoft Architecture Journal en la respuesta a dos preguntas en esa entrevista:

RJ: En Microsoft tenemos desarrolladores, directores de programa y arquitectos. La gente a menudo tiene curiosidad acerca de la función del arquitecto. ¿Cuál espera que sea la función del arquitecto en el equipo?

SG: Hay un par de responsabilidades que esperamos que los arquitectos aporten al equipo. La primera es una muy profunda y sólida experiencia en arquitectura, desarrollo y los principios de software de los que hablaba. Con ese tipo de perfil, esperamos que tenga lugar un proceso de ósmosis: que algo de estos conocimientos se transmita a otros miembros del equipo. Las conversaciones en el pasillo o las charlas informales de oficina pueden ofrecer una cantidad tremenda de liderazgo a un equipo, especialmente cuando se supervisa a los desarrolladores con mayor y menor experiencia.

Esperamos que un arquitecto prepare el terreno con respecto a lo que el producto debe hacer desde una perspectiva técnica. A menudo, los arquitectos llevan a cabo unas tareas más avanzadas de desarrollo de prototipos e investigación acerca de a dónde deberíamos llevar el producto. Esperamos que nos recomienden qué camino debemos seguir y, desde la perspectiva de la implementación, les pedimos que observen tanto el producto de la siguiente generación como el actual para identificar las áreas que debemos limpiar. Por ejemplo, ¿qué áreas debemos abordar de forma ligeramente distinta? ¿Qué prácticas podemos implementar a través de la base de código para mejorarlo?

RJ: Además de habilidades técnicas profundas y sólidas, ¿qué otros atributos piensa que contribuyen a que un arquitecto sea el adecuado?

SG: Lo más duro, al menos en Microsoft, es que las personas profundamente técnicas que quieren ascender por el camino arquitectónico deben asegurarse de que pueden fundir sus habilidades técnicas con la posibilidad de trabajar tanto en un equipo como en varios equipos de la empresa.

Algunas de esas habilidades sociales son más difíciles de adquirir, lo que significa que el arquitecto debe ser práctico, pero de manera que no asuste a los desarrolladores o al resto de equipos. También, deben evitar las conversaciones del tipo «yo tengo esto, tú tienes aquello». Los arquitectos deben poder trabajar en varios equipos de forma muy flexible. Deben hacerlo de manera que hagan que la gente sienta que los arquitectos se ocupan de los problemas más interesantes en un momento y luego huyen cuando las cosas se ponen difíciles. Los otros miembros del equipo tienen que creer que el arquitecto se dedica al equipo y forma parte de una relación a largo plazo que ofrece resultados con respecto a un problema. Ése es el tipo de habilidades que un arquitecto debe desarrollar. Los arquitectos con mucha experiencia y con mayor repercusión pueden aunar habilidades muy técnicas y de diseño con las habilidades colaboradoras y sociales.

No puedo estar mas de acuerdo con lo que dice Scott… si realmente quieres saber de que va el ser arquitecto de software, lee la entrevista completa, no tiene desperdicio.

Por último nadie negará que Juan de Vallejo, Diego de Siloe y compañia no hicierón un gran trabajo en la arquitectura de la catedral de Burgos… a veces me sale el orgullo Burgales, que le voy a hacer… jejejeje…

Participaré en: Evento sobre Team System :: Metodología y Procesos de Desarrollo


 


El próximo día 30 de Mayo tendré el placer de estar como ponente en el evento Metodología y Procesos de Desarrollo. Se celebrará en las oficinas de Microsoft en Pozuelo de Alarcón (Madrid). Os dejo la agenda y el link de inscripción por si os interesa.

Metodología y Procesos de Desarrollo


Agenda:

10.00 – 10.45 Procesos, Metodologías y Herramientas en el ciclo de vida del desarrollo.

10.45 – 11.15 Metodologías Agile y Scrum-XP

– Los “Backlogs”
– Planificación
– Comunicación
– Disposición del equipo
– Reuniones (Scrums)
– Retrospectivas
– Pruebas
– Liberación y aceptación

11.15 – 11.30 Descanso

11.30 – 12.00 Microsoft Solutions Framework (MSF) para CMMI

– Origenes e historia
– Modelos MSF
– Disciplinas

º Modelo de Equipo
º Gestión de Proyecto. Características y recomendaciones.
º Modelo de proceso
º Gestión de riesgos
º Gestión de la preparación

12.00 – 14.00 Definición y creación de una Plantilla de Proceso con Visual Studio Team System.

Inscríbase online en la sesión del Miércoles 30 de Mayo o bien en el teléfono 902 197 198

Es necesario que le confirmen telefónicamente que el registro ha sido efectivo para poder asistir al evento. Plazas limitadas.

Si tienes una subscripción MSDN… activa ahora mismo tu soporte

Estoy seguro que mucha de la gente que lee este blog tiene una subscripción a MSDN o al menos la tiene su empresa. Entre los beneficios de la subscripción MSDN esta la posibilidad de abrir hasta tres casos de soporte con Microsoft.


Ayer me veía en la necesidad, por primera vez, de utilizar uno de esos casos de soporte, así que ni corto ni perezoso llamé a soporte de Microsoft. Una señorita me atendio amablemente y me comunico que antes de usar los casos de soporte, los tenía que activar, primera noticia hasta el momento que recibía sobre esta precondición para usuarlos. Para realizar esta activación me dirigio a una url: http://support.microsoft.com/activatesupport.


Yo pense, bien dos minutos rellenando un formulario y vuelvo a llamar. Pero resulta que no, que las cosas de palacio van despacio y para activar los casos de soporte, en el mejor de los casos el proceso llevará al menos un día. De lo más normal… cuando llama a soporte está claro que es por que su problema no es urgente.


La moraleja: si teneís una subscripción MSDN, activad los casos de soporte de antemano, así cuando os veaís en la necesidad de usarlos, no tendreís que esperar.


Para que nadie se quede con la curiosidad, decir que el problema que estoy sufriendo es que svcutil.exe no es capaz de generar correctamente los proxies clientes de WCF cuando hay PageFault y DataContract un poco complejos de por medio. Si alguien está interesado en una descripción más detallada del error: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1617032&SiteID=1


Saludos!!!

Imprescindible: búsqueda libre de Work Items en TFS

 Una funcionalidad que llevo mucho tiempo echando en falta en el Team Explorer es la posibilidad de buscar Work Items a partir de un texto libre.


Noa Coad, Program Manager de Team System y anteriormente MVP de C#, un tipo muy simpático al que conocí personalmente en el Summit ha programado un interesantísimo plugin que es la respuesta a mis plegarias.


El plugin consiste en una barra de herramientas y un menu adicional en el menu Team de nuestro Visual Studio que nos permitiran introducir un texto libre a buscar.




¿No hos parece sorprendente que un Program Manager además sea un desarrollador más que decente? Conoceís algún ‘comercial’ (lo digo porque aquí los comerciales guian el desarollo del producto) que sepa algo de desarrollo de sofware aquí en España….

He leído: Facts and Fallacies of Software Engineering de Robert L. Glass

La ingeniería del software es muy diferente a otras ingenierías. En ingeniería mecánica, si tu calculas las dimensiones de una viga biapoyada para que soporte una tonelada, tu solución si es correcta será idéntica a la del resto de ingenieros de este mundo. Y cuando la viga en cuestión se construya, el resultado será prácticamente idéntico con independencia de quien realice el trabajo. La ingeniería mecánica tiene la ventaja de poder apoyarse en verdades universales, indiscutibles, en verdades matemáticas, en teoremas. Generalmente la solución a un problema es única y los métodos para llegar a ella también. Además el proceso para ‘desarrollar’ una viga de una tonelada es exactamente el mismo que para desarrollar una de diez.


Desgraciadamente en la ingeniería del software (que nombre más desafortunado) la historia es completamente diferente. Un proyecto de software tiene, virtualmente, infinitas soluciones correctas. Y además existen infinitas implementaciones que pueden funcionar correctamente. El problema es que en la ingeniería del software no contamos con teoremas y verdades matemáticas en los que basar el desarrollo de nuestros proyectos. No hay verdades absolutas en el desarrollo de software y eso complica los problemas. Cualquiera puede tener opinión, por absurda que sea, y sin embargo no existe una manera formal de rebatirla.

Pero no todo son malas noticias, en el desarrollo de software no tenemos teoremas, pero contamos con ciertos principios bien estudiados, documentados y universalmente ¿conocidos?. No, el problema principal es que estos principios no son universalmente conocidos, sino que a menudo los gestores y desarrolladores los ignoramos. Tendemos a fabricarnos los nuestros. Lo motivos son muy variados como para entrar en el porqué.

Robert L. Glass en Facts and Falacies of Software Engineering a recopilado un motón de estos principios y a documentado sus fundamentos amplísimamente. Además, consciente de que muchos de esos principios se cuestionan a menudo, a incluido una sección en la que recopila la controversia que cada uno de estos principios genera. Un libro espectacular, ameno de leer, que realiza un repaso de cabo a rabo de los fundamentos de la ingeniería del software. Si existiesen teoremas en ingeniería del software, sin duda esta sería una recopilación imprescindible de los mismos.

Otro valor añadido es la enorme cantidad de bibliografía con la que el autor a documentado el libro, parece que ha leído todo libro o documento relevante o no que se haya publicado en los últimos años sobre ingeniería del software.

Un libro que recomiendo a todo aquel mínimamente interesado en la ingeniería del software. Si ya has leído mucho sobre ingeniería del software, este libro es un recordatorio conciso y preciso de todo lo relevante que hayas leído. Si no has devorado libros sobre gestión de proyectos, arquitectura, buenas prácticas y demás y no tienes el tiempo y las ganas de hacerlo, este libro es ideal pues puedes leer un resumen de lo más relevante en un puñado de amenas páginas. De todos modos creo que después de leer este libro te picará el gusanillo para leer parte de la bibliografía que contiene.

Resumiendo: corre a comprarlo, merece la pena cada dólar que cuesta. Es el primer libro que léo de este prolifico y veterano autor, pero no será el último.

MSF vs RUP, DSL vs UML, Microsoft vs IBM

 


Indiscutiblemente, IBM y Microsoft son las dos grandes en lo que a desarrollo de software se refiere. Ambas tienen estrategias claras en este ámbito. IBM en su momento apostó claramente por UML como aproximación al modelado y como RUP como aproximación al ciclo de vida cuando compro Rational (si, si, no solo Microsoft ‘tira de talonario’).

Ni UML ni RUP se cuentan entre las herramientas favorita de mi cinturón de desarrollador de software. Sobre porqué no me gusta UML ya he escrito en variadas ocasiones. Y sobre RUP, decir que ya no me gustaba de partida por su complejidad pero menos aún después de ver como uno de sus padres y padre también de UML, Ivar Jacobson, ‘renegaba’ de sus hijos durante el Tech Ed 2006 de Barcelona. De RUP, aunque me parece que puede ser una aproximación válida, lo que menos me gusta es el concepto de ‘te doy un Ferrari y luego tu lo capas para que lo puedas manejar’

La aproximación de Microsoft me parece mucho más racional (jejeje bonito juego de palabras me ha salido). Todo hay que decirlo, la solución es mucho más tardía, pero llegar tarde tiene la ventaja de poder aprender en cabeza ajena. Y eso Microsoft ya ha demostrado que lo hace muy bien. El enfoque DSL en el que el modelado esta plenamente conectado al código y plenamente en consonancia con el dominio de la aplicación es mucho más usable que UML y MSF tiene una versión ágil para aquellos proyectos pequeños o medianos o equipos que comienzan con una metodología que no necesitan una metodología Ferrari con la que estrellarse sino una metodología Citroen C3 (¿eh Gorka?) que les lleve a algún sitio un poco más rápido, más cómodos y sin estrellarse, sobre todo sin estrellarse. Otra cosa en la que las herramientas para gestión del ciclo de vida de Microsoft son claramente superiores a las de IBM/Rational es en que son más agnósticas en cuanto a la metodología a emplear. La metodología no está condicionada por la herramienta. Si quieres saber que factores condicionan la elección de una u otra metodología puedes leer este post anterior.

Bueno al grano, toda esta parrafada solo es una ‘introducción’ para recomendaros un interesantísimo WebCast, que aunque ya tiene un tiempo he descubierto recientemente: MSDN Architecture Webcast: RUP vs. MSF? UML vs. DSLs? What’s the Difference Anyway? (Level 200).

Aunque está en inglés es fácil de seguir, espero que lo disfrutéis tanto como yo…

Lloraré con vosotros en el próximo evento de Artalde

Ven a llorar con nosotros…..sobre Arquitectura es el nombre del próximo evento del grupo de usuario del Pais Vasco, Artalde.NET.


Se celebrará el miércoles 23 de Mayo 2007 de 19:00 a 21:00 h en el lugar habitual, la sala de audiovisuales del edificio ESIDE de la universidad Deusto. 

Toda la información completa y registro aquí.

¿Quién no ha tenido una duda sobre cómo diseñar una arquitectura o quién no ha estado involugrado en discusiones sobre qué opción es mejor…….¿Cuántas capas pongo en mi aplicación?¿Devuelvo datasets a la capa de presentación o uso colecciones?¿Uso enterprise library?¿ Debo usar procedimientos almacenados o sentencias SQL? 

Pues ha llegado el momento de exponer todas las dudas y/o problemas que nos hemos tenido y entre todos los asistentes intentar dar una solución.  Con este evento buscamos involucrar a todos los númerosos asistentes que acuden a los eventos de Artalde, invitándoles a la participación y por qué no…A llorar con nosotros!!!

Dar soluciones concretas sobre un tema tan amplico es dificil. Pero tal y como hemos planteado el evento es más desde el punto de vista de comentar alternativas posibles y que la gente se familiarice con las ventajas e inconvenientes que cada aproximación tiene.

Además otra de las cuestiones que perseguimos es que no siempre seamos ‘los mismos’ los que hablemos en el club de usuarios, sino que todo el mundo tenga la oportunidad de aportar su granito de arena, planteando cuestiones y planteando posibles soluciones y contando experiencias. Se trata de compartir problemas y conocimientos. Y sobre todo de pasar un rato divertido charlando sobre desarrollo de software.

Yo creo que este evento va a ser todo un exito, así que si vives en Bilbao o alrededores no deberías perdertelo!!!

¿Quien se está saltando las políticas de mi TFS?

Las políticas de Team Foundation Server son una poderosa arma para imponer buenas prácticas en nuestros desarrollos de software. Existen políticas muy numerosas, por centrarme solo en las que Microsoft nos porporciona directamente bien como parte de la instalación base de Team Foundation Server o como parte del Check-In Policy Pack que forma parte de Team Foundation Server Power Tool contamos con las siguientes:



Pero, a mi modo de ver sabiamente, el equipo de desarrollo de Team Foundation Server a elegido dar la posibilidad de que el desarrollador pueda ‘saltarse’ estas politicas. Esto que en principio tiene poco sentido es muy necesario por que las políticas pueden ser muy restrictivas y es dificil preveer todas las situaciones que se producen durante el desarrollo y la integración del código. Tambien es cierto que es interesante saber si las politicas se están saltando por necesidades puntuales adecuadas o por simple dejadez sistemática. La mala notica es que Team Foundation Server no nos proporciona ninguna herramienta que nos permita detectar esta situación.


Por ello, he desarrollado para mi uso y como ejemplo de extensibilidad de los informes de Team Foundation Server un informe que nos permite ver quien se ha saltado las politicas y detectar aquellos miembros del equipo que ignoran sistematicamente las politicas. Os dejo, como adjunto a este post, el archivo rdl que contiene el informe Policy Violations Report y el archivo rds que debereís configurar adecuadamente con la conexión a vuestra base de datos TFSVersionControl del servidor de datos Team Foundation Server.


El proceso de instalación del informe es simple:


Subir los archivos rdl y rds al servidor:



Dar permisos de lectura al usuario TFSReports sobre la base de datos VersionControl:


Configurar el archivo rds para que apunte a la base de datos TFSVersionControl:


Ejecutar el informe:



Decir que por último que solo si hacemos una labor didáctica de porque es importante respetar las políticas y que buenas prácticas persiguen con su aplicación lograremos que los desarrolladores las respeten.