Presentaciones de ALM de los Techdays

Bueno, pues ya hemos subido las presentaciones de las dos charlas de ALM que di con Bruno Capuano y Rodrigo Corral en los TechDays, así que aquí las tenéis.

La verdad es que nos lo pasamos muy bien, y fue un placer dar esas charlas con esos dos máquinas.

Y como bien comenta Bruno en su post, interesante ronda de preguntas que tuvimos después de la segunda charla, y en las preguntas por los pasillos en las que se ve la cantidad de cosas y cuestiones que se plantea la gente acerca de Team System, lo cual demuestra que hay mucha gente utilizándolo, y mucha más gente deseando instalarlo y probarlo.

También fue un placer encontrarse con mucha gente que hacía tiempo que no veía, y que es frecuente encontrarse en estos eventos, la verdad es que a pesar de acabar totalmente destrozado, y además con una pequeña sorpresa, que me esperaba, por parte de la asociación con la que colaboro de voluntario que me comunicaron durante el miércoles mientras que yo estaba de fiesta en el palacio de congresos 😛

Team Foundation Server en la radio

Y no, no es que sea el nuevo hit de los 40 principales, es que Mickey GoussetMartin Woodward y Paul Hacker, MVPs de Team System, han creado hace bien poquito un “programa de radio” en forma de podcasts para llevar en vuestro iPod Zune y aprender de estos grandes expertos.

Las grabaciones actuales las tenéis en http://teamsystemrocks.com/files/30/radiotfs/default.aspx y también podéis suscribiros al feed en: http://feeds.feedburner.com/radiotfs

Por cierto, buscan tanto feedback, como preguntas que queráis hacerles para que las respondan en los postcasts, podéis escribirles a radiotfs@gmail.com

Lista de eventos disponibles en TFS

Bueno aquí estoy de vuelta del primer día de los TechDays, haciendo la “digestión” de todo lo visto hoy, de toda la gente que hacía tiempo que no veía y que he visto, y terminando de dar unos retoques a las presentaciones que doy mañana 🙂

Y bueno he visto algo interesante, muchos de los que me conocéis que entre las muuuuchas cosas raras que me gustan, una es la extensibilidad de Team Foundation Server, y uno de los puntos más sencillos de extender (que si queréis podemos tocar más adelante) es los eventos de TFS, básicamente, son determinados “anuncios” que el TFS manda ante determinadas acciones como un CheckIn, el fin de una build, o la modificación de un WorkItem, estos eventos, por si solos no hacen “nada”, pero tenemos la posibilidad de suscribir a estos eventos un web service de nuestra “cosecha” para realizar los procesos que necesitemos en nuestro entorno, o bien, simplemente suscribirnos con una dirección de correo electrónico para recibir alertas.

Y ahora viene la pregunta ¿cuales son estos eventos? para 2005 salió una lista hace tiempo en un blog, pero la verdad es que no había ninguna lista “oficial”, y bueno, hoy Charles Sterling ha publicado en su blog la lista “definitiva” de eventos disponibles en TFS, así como algunos obsoletos, los podéis consultar directamente en su blog: http://blogs.msdn.com/charles_sterling/archive/2008/02/26/definitive-list-of-events-that-are-supported-in-tfs.aspx

Y aquí os pongo la lista:

Work Item Tracking

· WorkItemChangedEvent -> Este evento se lanza cuando se crea/modifica un work item

Version Control

· CheckInEvent -> se lanza cada vez que se produce un check-in en Source Control

Team Build

· BuildCompletionEvent2 -> se lanza cuando se completa una build

· BuildStatusChangeEvent  -> cuando cambia la calidad ed una build, ojo, sólo la calidad, que cambiamos nosotros manualmente, digamos que el nombre del evento no está muy bien escogido

· BuildCompletionEvent  -> cuando se completa una build (si, tengo que revisar las diferencias con el otro)

CSS

· ProjectCreatedEvent -> se lanza cuando se termina de crear un Team Project

· ProjectDeletedEvent -> cuando nos cepillamos un Team Project 🙂

GSS/Authorization/CSS

· DataChangedEvent -> este es un nuevo tipo de evento génerico que se lanza cuando se cambian permisos (GSS), algo de estructura (areas, iteraciones, …) . PEro bueno este es nuevo y tengo que revisarlo bien.

o Type: STRUCTURE – sequence id for Services/v1.0/CommonStructureService.asmx?op=GetChangedNodes

o Type: SECURITY – sequence id for Services/v1.0/AuthorizationService.asmx?op=GetChangedAccessControlEntries

o Type: IDENTITY – sequence id for Services/v2.0/GroupSecurityService2.asmx?op=GetIdentityChanges or Services/v1.0/GroupSecurityService.asmx?op=GetChangedIdentities

Obsoleted… -> estos son los que NO deberíamos de usar

· BranchMovedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· NodeCreatedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· NodeRenamedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· NodesDeletedEvent – Fired, but also signaled with new DataChangedEvent of type STRUCTURE

· MembershipChangedEvent – Obsolete; DataChangedEvent of type IDENTITY

· IdentityDeletedEvent – Obsolete; DataChangedEvent of type IDENTITY

· IdentityCreatedEvent – Obsolete; DataChangedEvent of type IDENTITY

· IdentityChangedEvent – Obsolete; DataChangedEvent of type IDENTITY

· CommonStructureChangedEvent – Obsoleted… DataChangedEvent of type STRUCTURE

· AclChangedEvent – Obsolete; DataChangedEvent of type SECURITY

En fin, según vaya probando cositas nuevas os iré diciendo 🙂

Test Driven Development, ¿por qué hacer las pruebas antes?

Lo primero, bueno, hace mucho que no escribía, y sí, se que eso es un error a la hora de mantener un blog, pero lo cierto es que entre unas cosas y otras, andaba liado, y sin muchas ganas de escribir, pero bueno, cojo el toro por los cuernos y vuelvo a la carga.


Ayer, con mis amigos Rodrigo Corral, Bruno Capuano, y Unai Zorrilla (O Bruxo Mobile El follonero), surgió una interesante cuestión acerca del TDD, y es, la siempre puntillosa cuestión de hacer las pruebas unitarias antes siguiendo TDD al pie de a letra o después del código, que se saldría en parte de la definición de TDD.


La propia definición específica de TDD, dice que las pruebas se han de escribir siempre antes que el código, cosa que a veces es difícil de hacer entender y explicar a gente “novel” en el tema del TDD.


Si bien es cierto que en algunos sitios si que he visto gente que dice que a pesar de hacer TDD, hacen las pruebas después, y además Rodrigo ayer, nos comentó que el tenía una referencia de uno de los “grandes” que da dos aproximaciones “Test at first” (test al principio) y “Test at last” (test al final).


Tampoco escribo este post para que el follonero Unai, rodrigo, Bruno, et al. nos metamos de nuevo en una discusión jeje, sólo pretendo exponer mis ventajas, y si digo “mis”, ya que estoy hablando desde mi punto de vista subjetivo (como veis hablaré siempre en primera persona), de como me ayuda el tema de hacer la prueba al principio:



  1. Las pruebas me dan la funcionalidad, si, si empiezo diseñando la prueba, se me hace más claro que tiene que hacer exactamente el método, con lo cual, me disperso menos a la hora de la realización del método, y por tanto, menos dispersión == menos fallos.
  2. Diseño, al hilo con lo anterior, la prueba me da el diseño del método, que necesito de entrada, que voy a obtener de salida, y que tiene que pasar entre medias, esto es muy parecido a la anterior, si, pero aquí ya bajo de nivel a la parte más puramente técnica.
  3. K.I.S.S., keep it simple stupid, yo soy de los que siempre empiezan a pensar “¿y si añado este if aquí y este for aquí?”, con esto consigo que el código que haga, sea totalmente dirigido a solucionar la prueba, ni más ni menos, para futuras situaciones, casuísticas, tendré más pruebas.
  4. Cobertura de código, esto es básico, si hago todo los puntos anteriores, consigo una mayor cobertura de código.

Bueno, esta es mi pequeña aportación a porque lo hago así, además, con Visual Studio 2008 (¡¡¡¡venid al lanzamiento!!!!) todos sabemos que tenemos la posibilidad de crear el método y luego darle al botón de crear pruebas unitarias, lo cual es muy tentador, pero yo os hago la propuesta inversa, cread la prueba, y hacer la llamada al método fantasma con los parámetros (tanto de entrada como de salida) necesarios, y luego, una vez terminada de escribir la prueba, ejecutarla y recibir el puntito rojo, sobre esa línea de código de la llamada al método fantasma pulsad (con los settings de VS C#) Alt+Shift+F10, y milagro, os sale esto:


Untitled-2


Vaya, con esto, podemos generar la definición del método en la clase adecuada, y favoreciendo el TDD.


Por supuesto, y aunque yo me declare a favor de hacer la prueba siempre antes, es una opinión basada en mi propia experiencia, y aquí está el punto clave, nuestra experiencia, pero como siempre, aconsejo que empezemos (siempre que no tengamos experiencia previa) basándonos en el conocimiento de los que nos han precedido, y en este caso yo apostaría por el mantra del TDD: red, green, refactor.


PD: Unai, jeje no me odies por lo de el follonero, y de veras, fue muy divertido, y gracias por el feedback 🙂


PDII: Vale Rodrigo, me he puesto de parte de Unai, pero no me pegues muy fuerte, que eres mucho más grande que yo 🙂