[#TFS2010] HowTo: Cambiar la asociación de Source Control de un proyecto

image47dd1de4

Buenas,

voy a apuntar un escenario que es bastante casual y da errores en más de una ocasión. Se da usualmente cuando copias un proyecto asociado al SC de un servidor Team Foundation hacia otro servidor y el cliente de Visual Studio 2010 se hace un lío con el binding de ese proyecto. La solución es bastante simple:

  1. El proyecto debe ser parte de una solución correctamente asociada a un servidor de Source Control de TFS
  2. En el IDE abrir la opción “File >> Source Control >> Change Source Control“
  3. Seleccionar el proyecto con problemas y presionar la opción “Unbind”
  4. Confirmar los cambios, con la opción “Ignore All”
  5. En el panel Solution Explorer, seleccionar el proyecto.
  6. Desplegar el menú contextual y seleccionar la opción “Add selected projects to Source Control”
  7. Done !!!

7 pasos que te ahorran una tarde de disgustos, especialmente si “rompes una de las Builds

Saludos @ La Finca

El Bruno

   

[#TFS2010] Team Project Manager, todo al alcance de un clic!

image47dd1de4

Buenas,

si como a mi te toca cada tanto administrar uno o más servidores Team Foundation Server 2010, con sus correspondientes Team Project Collections y además sus interminables Team Projects, seguramente esta herramienta te alegrará el día: Team Project Manager. Se trata de una herramienta donde se unifican tareas comunes en la administración de Team Foundation Server como por ejemplo:

  • Gestión de las definiciones de Builds. Lo mejor es la capacidad de realizar bulk updates en las definiciones de Builds. Muy útil cuando se cambia el Drop Folder común a varias Builds.
  • Gestión de Build Process Templates
  • Gestión de los grupos de seguridad. Imprescindible a nivel global.
  • etc.

La documentación es bastante completa y si quieres ver las capacidades, este link http://teamprojectmanager.codeplex.com/documentation?referringTitle=Home te ayudará.

 

Saludos @ Home

El Bruno

   

Project HomePage: http://teamprojectmanager.codeplex.com/

[#ALM] Demostrando con números porqué es conveniente realizar Pair Programming

Buenas,

después del excelente Coding Dojo con la ayuda de Luis Ruiz Pavón que hicimos con los chicos de MadridDotNet, pues me quedó pendiente explicar de manera matemática porque es útil realizar una práctica de Pair Programming en los equipos de desarrollo. Pair Programming o Programación en Pareja define un escenario donde básicamente se programa de a dos. He aquí la definición de la Wikipedia:

La Programación en Pareja (o Pair Programming en inglés) requiere que dos Ingenieros en Software participen en un esfuerzo combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no está haciendo actualmente: Mientras que uno codifica las pruebas de unidades el otro piensa en la clase que satisfará la prueba, por ejemplo.

La persona que está haciendo la codificación se le da el nombre de controlador mientras que a la persona que está dirigiendo se le llama el navegador. Se sugiere a menudo para que a los dos socios cambien de papeles por lo menos cada media hora o después de que se haga una prueba de unidad.

Esta práctica que es bastante útil, tiene muchos detractores ya que usualmente la gente piensa que en el mundo del desarrollo 4 manos producen más que 2. Cuando en realidad 2 cabezas producen mucho más que una sola. Pero bueno, si alguna vez te has encontrado con un “jefe” detractor de esta filosofía de trabajo, este ejercicio puede ayudarte a demostrar porque una práctica de Pair Programming es realmente útil.

Escenario Ideal

Supongamos que tenemos un equipo de trabajo de 6 personas compuesto por 2 programadores seniors y 4 programadores juniors. En un escenario ideal de trabajo, podemos asumir que diariamente un programador senior rinde una cantidad de 2 Unidades de Trabajo (UT), mientras que un programador Junior rinde 1 UT. Si tenemos una semana de 5 días de trabajo estándar pues al final de la semana tendremos 40 UTs. La siguiente tabla nos  muestra estos números para que queden más claros

Team Día 1 Día 2 Día 3 Día 4 Día 5 Total
SrP 2 2 2 2 2 10
JrP 1 1 1 1 1 5
JrP 1 1 1 1 1 5
SrP 2 2 2 2 2 10
JrP 1 1 1 1 1 5
JrP 1 1 1 1 1 5
            40

 

Escenario Real

Pero claro, si realmente te dedicas al desarrollo de software y eres consciente de lo que hace tu equipo de trabajo sabrás que el primer día tal vez un Sr Programmer pueda rendir al 100% y generar sus 2 UT, pero los días siguientes tendrá que ayudar a los Junior Programmers a que cierren su trabajo. En muchas ocasiones esto significa que su rendimiento personal bajará hasta el piso y se dedicará a trabajar por 2 o por 3 para poder sacar adelante el trabajo. Siendo generoso con el reparto de UTs, este escenario podría quedar como la siguiente tabla.

Team Día 1 Día 2 Día 3 Día 4 Día 5 Total
SrP 2         2
JrP   1   1 1 3
JrP     1   1 2
SrP 2         2
JrP   1   1 1 3
JrP     1   1 2
            14

Antes de pasar al escenario siguiente, y ya que has leído hasta aquí, pregúntate porque es tan frecuente que los programadores se junten entre sí para debatir un tema en particular o para mostrarse porciones de código. Verás que muchas veces están realizando Programación en Parejas sin siquiera saberlo.

 

Escenario de Programación en Pareja

Finalmente veamos que sucedería si juntamos a un SrP y a un JrP; y dejamos que la 3ra pareja de JrP vaya rotando con las anteriores. Pues siendo muy amarrete con los UTs, ya de entrada tenemos casi un 150% más que en el escenario real. Y claro, esto asumiendo que los JrP no pueden rendir más con el paso del tiempo. La siguiente tabla muestra este ejemplo:

Team Día 1 Día 2 Día 3 Día 4 Día 5 Total
SrP           0
JrP 1,5 1,5 1,5 1,5 1,5 7,5
JrP           0
SrP 1,5 1,5 1,5 1,5 1,5 7,5
JrP           0
JrP 1 1 1 1 1 5
            20

 

Pues bien, aquí tienes un ejemplo completamente irreal sobre como el Pair Programming puede ayudarnos a mejorar el rendimiento de nuestros equipos de trabajo. Obviamente que esto que he puesto aquí no es un estudio real ni cierto, ya que en desarrollo de software influyen muchas otras variables; pero tal vez si te juntas con un jefe obtuso puedas comenzar por hacer que reconozca que se trabaja en el escenario 2 y luego explicarle que el escenario 3 es mejor.

Completa la frikada de la semana … Risa

Update: voy a poner un poco de contexto para explicar el porqué de esta entrada y porqué no debes tomarte en serio la misma, es simplemente un ejercicio para demostrar como NO PUEDES bajar a números simples el trabajo de un equipo. Pair Programming es una práctica que aporta muchas ventajas, si las quieres conocer pues tu amigo google o su amigo Bing, te pueden ayudar. Sino volveré a recomendar The Agile Samurai, un libro obligatorio para estos días. En este caso en particular he destrozado todas las buenas prácticas de gestión de proyectos para llegar  a un número que sea válido para el post, por ejemplo

  • Es imposible medir la capacidad de trabajo de una persona en “unidades de trabajo”, todo el mundo sabe que el trabajo de un desarrollador se mide en base a la cantidad de líneas de código que escribe por día. Si no sabes como hacerlo, este post te puede ayudar a detectar quien trabaja y quien no.
  • Pair Programming no se basa en juntar a un Programador Senior y un Programador Junior, es un poquito más complicado. Yo personalmente recomiendo realizar parejas en base a los años de cada persona. Está científicamente demostrado que cuando la suma de los años de una pareja es un múltiplo exacto de 3 o de 7, el rendimiento se incrementa en un 18%.
  • Pair Programming  nos permite ahorrar costes de hardware. Al no necesitar 2 ordenadores, podemos reducir los gastos de IT a la mitad. Otra cosa que recomiendo para ahorrar costes y espacio trabajando con Programación en parejas, es no tener 2 sillas, sino una única silla y una persona colgada como en Mission Imposible. Esto también ayuda ya que si está colgada con una leve inclinación hacia abajo, llegará más sangre a su cabeza y podrá escribir más líneas de código al día.

 

Saludos @ Home

El Bruno

   

Fuentes: http://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja

[#EVENTO] 12 Horas de Visual Studio (a ver si te las aguantas !!!)

image47dd1de4

Buenas,

mientras me muerdo las uñas para no contar nada del SDK de Kinect antes del 1 de febrero y no montar ningún evento online para contar las novedades, voy a aprovechar la gran tormenta solar que está ocurriendo justo en este momento para promocionar este eventos en el que participaré dentro de unos días.

12 Horas de Visual Studio 

Pues el título te lo dice todo. Vamos a abrir una instancia de Visual Studio 2010 y otra de Visual Studio 11 a las 0900 AM y hasta las 0900 PM no frenaremos. En el camino verás a cracks como Luis Fraile, Iván González, Rodrigo Corral, Eduard Tomás, Alberto Díaz, David Álvarez, Jose L. Teruel, Alberto Fraj, Pedro J. Molina, José Bustos, Marino Posadas, etc., y obviamente el que suscribe Risa. Veremos temas tan variados como Silverlight, ASP.Net, Ajax, JQuery, TDD, Kinect, Coded UI Tests, SharePoint, ASP.Net MVC, Windows Phone, pruebas de rendimiento, etc.

Además tengo que agradecer a los chicos de Microsoft Spain por darme esta oportunidad y además por tenerme en cuenta para abrir la sesión. Es un detallazo que pongan primero a los que somos medio así como yo, de forma que el listón esté bajito. Además como hay más de 20 sesiones, y seguro que tenemos un retraso medio de 5 minutos por sesión, el pobre Rodrigo Corral seguro que comienza la última sesión el día siguiente Lengua fuera 

Eso sí a las 11:40 me permiten conectar el Kinect, me voy a llevar el Robot, un par de gatos y montaré una gorda gorda …

Nos vemos virtualmente, porque he comentado que el evento es 100% formato webcast no? O pensabas que te ibas a tirar 12 horas delante de toda esta panda de gente en vivo?

Saludos @ Home

El Bruno

   

Registro: https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032502854&amp%3bCulture=es-ES

[#KINECT] HowTo: Suavizar la detección de movimientos en el skeleton

image

Buenas,

mientras esperamos que en pocos días salga el SDK final para los desarrollos con Kinect, todavía tenemos que ajustar bastantes cosas para que el SDK nos permita hacer aplicaciones robustas. Una de estas “deudas” que Kinect posee con nosotros es la capacidad de quitar el “tembleque/temblor” que tenemos en cada punto del skeleton cuando trabajamos con el mismo punto a punto o Joint a Joint. Si ejecutas la aplicación que muestra ambos skeletons en un Canvas de WPF, verás que la misma funciona bastante bien.

Ahora bien, si modificamos la misma con un poco del código base de este post, para agregar 2 mundos en cada mano (he’s got the whole world in his hands!!!) in  veremos algo similar a la siguiente imagen. Si bien no he ajustado bien el tamaño del form para que los mundos coincidan 100% con cada mano, cuando ejecutas la aplicación puedes ver que la misma tiene un flickering o tembleque un poco raro cuando analiza el detalle del skeleton.

image

Pues bien para solucionar este problema llega a nuestras manos una fabulosa propiedad del SDK llamada TransformSmooth. Si bien no hay mucha documentación al respecto, utilizando esta propiedad podemos definir una serie de buffers de desviaciones que se procesarán durante el análisis del skeleton. De esta forma si agregamos las siguientes líneas antes de suscribirnos al evento de detección de skeletons, podremos trabajar de una forma más suave.

   1: _kinect.SkeletonEngine.TransformSmooth = true;

   2: var parameters = new TransformSmoothParameters

   3: {

   4:     Smoothing = 0.75f,

   5:     Correction = 0.1f,

   6:     Prediction = 0.0f,

   7:     JitterRadius = 0.05f,

   8:     MaxDeviationRadius = 0.08f

   9: };

  10: _kinect.SkeletonEngine.SmoothParameters = parameters;

  11: _kinect.SkeletonFrameReady += KinectSkeletonFrameReady;

 

Ahora bien, para ver que valores tenemos que aplicar en cada propiedad, lo mejor es ir probando las mismas para ver que formato se adapta mejor a nuestra aplicación.  En este post, se describe un poco que representa cada propiedad y los valores por defecto de las mismas.



Parameter Description Default Value Comments
Smoothing Specifies the amount of smoothing. 0.5 Higher values correspond to more smoothing and a value of 0 causes the raw data to be returned. Increasing smoothing tends to increase latency. Values must be in the range [0, 1.0].
Correction Specifies the amount of correction. 0.5 Lower values are slower to correct towards the raw data and appear smoother, while higher values correct toward the raw data more quickly. Values must be in the range [0, 1.0].
Prediction Specifies the number of predicted frames. 0.5  
Jitter Radius Specifies the jitter-reduction radius, in meters. 0.05 The default value of 0.05 represents 5cm. Any jitter beyond the radius is clamped to the radius.
Maximum Deviation Radius Specifies the maximum radius that filter positions can deviate from raw data, in meters. 0.04 Filtered values that would exceed the radius from the raw data are clamped at this distance, in the direction of the filtered value.

Y como siempre si quieres descargar el ´código de este post lo puedes hacer desde aqui

https://skydrive.live.com/redir.aspx?cid=bef06dffdb192125&resid=BEF06DFFDB192125!3798&parid=BEF06DFFDB192125!1932

 

 

Saludos @ Home

El Bruno

   

Fuentes:

http://channel9.msdn.com/Series/KinectSDKQuickstarts/Skeletal-Tracking-Fundamentals

http://cm-bloggers.blogspot.com/2011/07/kinect-sdk-smoothing-skeleton-data.html

[#VS2010] HowTo: Depurar un AddIn para OneNote

image47dd1de4

Buenas,

no voy a comenzar a explicar el porqué de la creación de un AddIn para OneNote. Si alguno conoce la teoría de la mala suerte, pues podrá ver que OneNote es el único elemento de la suite de Microsoft Office 2010 que no posee una plantilla para la creación de AddIns en Visual Studio 2010. Tuve que tirar de los malos recuerdos con IDTExtensibility2, de un poco de buceo por el registro para poder crear un AddIn. Eso si, una vez creado el AddIn para OneNote en Windows8 queda muy chulo, pero …. me topé la cabeza contra la pared cuando intenté depurar el mismo.

Resulta que si bien en la lista de procesos de Windows, hay activo un proceso que tiene toda la pinta de ser el de OneNote, llamado ONENOTE.EXE; pues este proceso no es el que hostea las notas de OneNote. Como un AddIn es un COM, el mismo no se ejecuta en el contexto del EXE de OneNote sino que no se ejecuta dentro de un DLLHOST (que malos recuerdos por dios !!!)

image

Pero bueno, adjuntando el proceso al dllhost correspondiente ya podremos depurar nuestros AddIns para OneNote.

Para esto tengo que agradecer a Daniel Escapa por su pos de hace unos años >> http://blogs.msdn.com/b/descapa/archive/2007/05/01/debugging-a-onenote-toolbar-addin-c.aspx

 

Saludos @ La Finca

El Bruno

   

Referencia: http://msdn.microsoft.com/en-us/library/extensibility.idtextensibility2.aspx

Thanks To http://blogs.msdn.com/b/descapa/archive/2007/05/01/debugging-a-onenote-toolbar-addin-c.aspx

[OPINION] Visual Studio Achievements, algunos logros dan miedo !!!

image47dd1de4

Buenas,

en mi post anterior comenté el lanzamiento de Visual Studio Achievements, un interesante plugin que trae el concepto de logros o puntos al mundo del desarrollo. Ahora bien, si analizamos los logros que se han puesto dentro de Channel 9, pues vemos que hay una división en 6 categorías para tipos de logros. Hay una en particular que tiene logros de cero puntos, pero que dan miedo de solo encontrar a alguien que los posea. Por ejemplo

image

De verdad queremos enseñar la sentencia goto a aquellas personas que no lo conocen?. Pero bueno, entiendo que esto es un ejemplo de una mala práctica y solo sirve como referencia. Por ejemplo, la persona que más logros posee en este momento (http://channel9.msdn.com/niners/DotNetNuzzi/achievements/visualstudio) posee este logro y yo me pregunto:

¿Habrá conseguido el logro para tener puntos en este programa o REALMENTE UTILIZA LA SENTENCIA GOTO?

Ambos escenarios son igual de peligrosos. Otros logros que asustan son los siguientes

Finalmente, Hadi Hariri se encarga de terminar de rematar la mala implementación del programa en este post (http://hadihariri.com/2011/11/25/visual-studio-achievements-who-needs-clean-code-anyway/).

Yo creo que la idea es muy buena, que se trata de llevar adelante un poco de promoción de herramientas que complementan a Visual Studio 2010, como FxCop o las herramientas de profiling. Pero como dice Hadi, no podrían haber aprovechado la ocasión y pensar en logros que realmente promuevan un desarrollo limpio y basado en buenas prácticas.

 

Saludos @ Home

El Bruno

   

Download: http://visualstudiogallery.msdn.microsoft.com/bc7a433b-b594-48d4-bba2-a2f24774d02f

References: http://hadihariri.com/2011/11/25/visual-studio-achievements-who-needs-clean-code-anyway/

[#VS2010] Visual Studio Achievements, logros para cada developer

image47dd1de4

Buenas,

estos días no he tenido tiempo para escribir, ni tampoco para probar muchas cosas nuevas. Pero la idea de Visual Studio Achievements me llamó mucho la atención (aunque cuando visto los achievements me he quedado de palo!). Pero vamos a los que vamos, esta extensión te instala un plugin en el de IDE de Visual Studio que se encarga de analizar los desarrollos que estás haciendo y te brinda logros en base  a los mismos.

Una vez autenticado contra Channel9, podemos ver como se integra dentro del IDE.

image

A partir de este momento solo es cuestión de dejar que haga su trabajo de análisis por detrás y que comience a contar los logros que vamos sumado,

image

Yo después de jugar con la herramienta un par de minutos me encontré con varios logros desbloqueados (algunos de los que no me siento especialmente orgulloso Guiño)

image

Pues bueno, la idea me parece genial, él formato también, aunque mejoraría un poco los logros que se promueven. Eso va para el próximo post.

 

 

Saludos @ Home

El Bruno

   

Home: http://channel9.msdn.com/achievements/visualstudio

Download: http://visualstudiogallery.msdn.microsoft.com/bc7a433b-b594-48d4-bba2-a2f24774d02f

[#PERSONAL] Mañana elbruno.com estará caído (you know why!)

Buenas,

hoy paso de escribir de Kinect, ALM, Team Foundation, etc.

Simplemente pongo este post para aportar mi mini grano de arena dando de baja un blog que seguro que no lee nadie durante todo un día.

Mañana elbruno.com estará dado de baja y que conste que prefiero siempre > compartir a censurar Enfadado 

image

Saludos @ Home

El Bruno

   

Image Source: http://www.zazzle.com/angry_code_monkey_tshirt-235123079804333018

[#ALM] Cada cuanto es recomendable hacer un CheckIn?

Buenas,

en navidades y año nuevo con el Javi éramos los únicos en La Finca trabajando. Nos tocaba la agradable tarea de preparar scripts de despliegue, probarlos en local, después ver como fallan en el entorno de pruebas y ni hablar en PRE y PRO. Pero bueno, como el Javi es nicotinero, yo lo acompañaba a que sacie su vicio y entre una cosa y otra nos pusimos  a hablar del interesante y recurrente tema

¿Cada cuánto es recomendable hacer CheckIn mientras modifico código compartido? (o proteger código en el repositorio)

Pero el tema era bastante más específico, ya que hablamos de lo que sucede si tomamos una gran porción de código y comenzamos a trabajar y mejorar la misma. En este caso, ¿debo proteger mi código al final del proceso de refactoring?¿o hacerlo más frecuentemente cuando aplico voy aplicando pequeños cambios? Veamos algunos ejemplos:

En el primer caso, es bastante frecuente ver cómo una persona toma una porción de código durante un par de días, se dedica a jugar con las mismas, y al cabo de 48 horas decide proteger los cambios que ha realizado. Si está trabajando en un equipo conjunto y ha modificado elementos comunes como por ejemplo la definición de un proyecto, pues es muy probable que tenga que hacer una o más acciones de MERGE. Si además ha modificado clases que estaban siendo utilizadas por otros compañeros, pues el MERGE será más delicado.

Después de presentar este ejemplo, tal vez alguien piense que la solución es proteger más frecuentemente. Supongamos que por cada modificación “leve” que aplicamos en nuestro proceso de refactoring, y realizamos un CheckIn. En este caso, debemos tener muy afinado el funcionamiento del equipo de desarrollo, pues es en ese momento cuando los demás integrantes deberán evaluar si necesitan obtener la última versión de SC y la misma pregunta deberá hacerse la persona que está realizando el refactoring.

Como vemos ninguno de los dos casos es una solución completa para este escenario. Yo desde mi humilde opinión puedo sugerir lo siguiente para este ejemplo:

  • Evalúa los cambios que realizas e intenta que los mismos sean significativos para el código. Es decir que no sea una línea de comentario, ni la destrucción y reemplazo total de 20 clases por 7 nuevos proyectos diferentes .
  • Siempre debes cumplir con las premisas básicas antes de proteger código > verificar que compile y que se pase la última versión de las pruebas unitarias.
  • Si te encuentras frecuentemente con “clases” sobre las que están trabajando 2 personas (o más), evalúa si estás cumpliendo los principios SOLID. Que 2 personas trabajen sobre la misma clases suele ser indicador de que esa clase está asumiendo demasiadas responsabilidades
  • Si cumples los principios SOLID, pero todavía te encuentras con 2 personas trabajando sobre la misma clase; pues dale un toque a la persona que reparte las tareas en el equipo ya que seguro que hay algo que no cuadra.
  • Comenta este trabajo con tus compañeros. La reunión diaria de “puesta al día” es un momento ideal para comentar este trabajo.
  • Finalmente, recuerda que en un equipo se debe respetar el principio de la propiedad compartida del código. Cada cambio que aplicas repercute en el trabajo de tus compañeros y nadie es responsable y “amo” de una única porción de código.

Y para cerrar, el clásico de cada día cuando nos pasan estas cosas … (fuente http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0162fe399bd1970d-pi)

image

Saludos @ Here

El Bruno

   

Geek And Poke : http://geekandpoke.typepad.com