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

[#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: Soften the detection of movements in the skeleton

image

Hi,

While we await the final SDK for developers with Kinectleave in a few days, we still have to adjust quite a bit to make the SDK will allow us to make robust applications. One of these “debts” Kinect has with us is the ability to remove the “tembleque / tremor” have at each point of the skeleton when working with the same point to point or Joint to Joint. If you run the application that shows both skeletons in a Canvas of WPF, you’ll see that it works pretty well.

Now, if we modify it with a bit of the code base of this post, to add 2 worlds in each hand (I have ‘ s got the whole world in his hands!) in will see something similar to the following image. While I have not well adjusted the size of the form so that the worlds coincide 100% with each hand, when you run the application you can see that it is a flickering or tembleque a little weird when examines the detail of the skeleton.

image

As well to solve this problem to our hands comes a fabulous property of the SDK called TransformSmooth. While there is lots of documentation in this respect, using this property we can define a series of buffers for deviations that will be processed during the analysis of the skeleton. Thus if we add the following lines before subscribe to the event of detection of skeletons, we can work in a smooth way.

   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;

 

Now, to see that values have to apply to each property, it is best to go testing them to see that format is better suited to our application. In this post, is described a bit to represent each property and values by default of the same.


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.


And as always if you want to download the ´código of this post you can do from here

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

Greetings @ Home

El Bruno

Sources:

http://Channel9.msdn.com/series/KinectSDKQuickstarts/skeletal-tracking-fundamentals

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

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