[# TFS2010] HowTo: Change the Source Control association in a project

image47dd1de4

Hi,

I will point out a scenario that is pretty casual and gives errors on more than one occasion. Occurs usually when you copy a project associated with the SC in a Team Foundation Server to another server and the client for Visual Studio 2010 makes a mess with the binding of that project. The solution is quite simple:

  1. The project must be part of a solution properly associated with a TFS Source Control Server
  2. In the IDE to open the "File > > Source Control > > Change Source Control" option
  3. Select the project with problems and press the "Unbind" option
  4. Confirm the changes, with the option "Ignore All"
  5. In the Solution Explorer pane, select the project.
  6. Display the contextual menu and select the option "Add selected projects to Source Control"
  7. Donate!

7 steps that save you an afternoon of trouble, especially if "you break one of the Builds"

Greetings @ La Finca

El Bruno

[#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, one click to manage all!

image47dd1de4

Good,

as to my you get each both administer one or more servers Team Foundation Server 2010, with their corresponding Team Project Collections but also their endless Team Projects, surely this tool you rejoice the day: Team Project Manager. It is a tool where unified common tasks such as in the administration of Team Foundation Server:

  • Management of the definitions of Builds. The best is the ability to perform bulk updates on the definitions of Builds. Very useful when changing the Drop Folder common to several Builds.
  • Management of Build Process Templates
  • Management of security groups. It is essential at the global level.
  • etc.

The documentation is fairly complete and if you want to see the capabilities, this linkhttp://teamprojectmanager.codeplex.com/documentation?referringTitle=Home help.

Greetings @ Home

The Bruno

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

[#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] Using numbers to show why Pair Programming is a good practice

Hi,

After the excellent Coding Dojo with the help of Luis Ruiz Pavón we did with the guys from MadridDotNet, because I was pending to explain mathematical because it is useful to make a practice of Pair Programming in development teams. Pair Programming or programming pair defines a scenario where program is basically a two. Here’s the definition from Wikipedia:

Pair programming (or Pair Programming in English) requires two Software engineers to participate in a combined effort of developing a job site. Each Member performs an action that the other is not currently doing: while one encodes units tests the other thinks in the class that will satisfy the test, for example.

The person is doing coding is given the name of controller while the person who is leading is called the browser. It often suggests that two partners at least every half hour change roles or after becomes a unit test.

This practice is quite useful, has many detractors because usually people think that the world of development 4 hands produce more than 2. When in reality 2 heads produce much more than a single. But well, if once you’ve found with a "head" condemn this philosophy of work, this exercise can help you to demonstrate because a practice of Pair Programming is really useful.

Ideal scenario

Suppose we have a team of 6 people consisting of 2 programmers seniors and juniors 4 programmers. In an ideal scenario of working, we can assume that a senior programmer on a daily basis pays an amount of 2 units of work (UT), while a Junior programmer pays 1 UT. If we have a 5 day standard work week because at the end of the week we will have 40 UTs. The following table shows these numbers to make them clearer

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

 

Real scenario

But of course, if you actually do software development and are aware of what does your team know that day maybe a Sr Programmer can give 100% and generate their 2 UT, but the next few days will have to help the Junior Programmers to close his work. Often this means that their personal performance will drop to the floor and will be devoted to work by 2 or 3 to be able to take work forward. Being generous with the cast of UTs, this scenario could look like the following table.

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

 

Before moving to the next stage, and that you’ve read here, ask you because it is so frequent that developers gather together among themselves to discuss a topic in particular or to show portions of code. You’ll see that many times are doing programming in pairs without even knowing it.

Scenario with pair programming

Finally let’s see what would happen if we put together a SrP and a JrP; and we let the 3rd pair of JrP will rotate with previous. Since being very amarrete with the UTs, input we already have almost 150% more than in the real scene. And of course, assuming that the JrP can not pay more with the passage of time. The following table shows this example:

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

 

Well, here you have an example completely unrealistic about how Pair Programming can help us improve the performance of our teams. Obviously that I post here is a real study nor true, since that software development is affected by many other variables; but perhaps if you together with a blunt head you can start to do recognize that you working in the stage 2 and then explain the scenario 3 is better.

Done the friki stuff ot the week … Risa

Update: I’ll put a bit of context to explain why this entry and why do not you should take seriously, is simply an exercise to demonstrate that YOU CANT put down to simple numbers the work of a team. Pair Programming is a practice that has many advantages, if you want to know because your friend google or his friend Bing, can help you. But I will recommend The Agile Samurai, a book mandatory for these days. In this particular case I have destroyed all good project management practices to reach a number that is valid for the post, for example

  • It is impossible to measure the working capacity of a person in "work units", everyone knows that the work of a developer is measured on the basis of the number of lines of code that writes per day. If you don’t know how to do it, this post can help you identify who works and who not.
  • Pair Programming is not based on join a Senior Programmer and a Junior programmer, is a little more complicated. I personally recommend make couples on the basis of the years of each person. Is scientifically demonstrated that when the sum of the years of a couple is an exact multiple of 3 or 7, performance increases in a 18%
  • Pair Programming allows us to save hardware costs. No need 2 computers, we can reduce IT costs by half. Another thing that I recommend to save costs and space to work with programming in pairs, is not have 2 chairs, but a single chair and a person hung in Mission impossible. This also helps if it hangs with a slight inclination downward, will get more blood to your head and you can write more lines of code to the day

 

Greetings @ Home

El Bruno

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

[#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

[# Event] 12 hours of Visual Studio (maybe you can with all of this!!)

image47dd1de4

Hi,

while I bite nails to tell nothing of the SDK Kinect before February 1st and did not mount any online event to tell the news, I will take advantage of the large solar storm that is happening at this very moment to promote this event in which I will participate in a few days.

12 Hours of Visual Studio

Because the title says you it all. We are going to open an instance of Visual Studio 2010 and the other Visual Studio 11 to the 0900 AM and until the 0900 PM not frenaremos. On the road you will see cracks as Luis Fraile, Iván González, Rodrigo Corral, Eduard Tomás, Alberto Díaz, David Álvarez, Jose l. Teruel, Alberto Fraj, Pedro j. Molina, Jose Bustos, Marino Posadas, etc., and obviously the undersigned Risa. We’ll see topics as diverse as Silverlight, ASP..NET, Ajax, JQuery, TDD, Kinect, Coded UI Tests, SharePoint, ASP.NET MVC, Windows Phone, testing performance, etc.

I also have to thank the guys at Microsoft Spain by giving me this opportunity and also take into account to open the meeting. It is a detallazo put first to those who are half as well as I do, so that the bar is quietly. Furthermore as there is more than 20 sessions, and surely we have a delay average 5 minutes per session, the poor secure Rodrigo Corral that begins the last session the next day Lengua fuera

That Yes at 11: 40 connect me the Kinect, I’m going to take the Robot, a pair of cats and will ride a fat fat…

Do we meet virtually, because I have commented that the event is 100% format webcast not? Or you thought you were going to throw 12 hours in front of this bunch of people live?

Greetings @ Home

The Bruno

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