[#SCRUM] Y el delicado camino a la incompetencia

Hola!

Todos sabemos que Scrum es la solución a todos los problemas. En la página 12 de la guía de Scrum hay una frase que dice lo siguiente:

Scrum Hoch bIquv qay’ taS

Que traducido del Klingon viene a significar

Scrum es la solución para todo tipo de problemas

Y listo! Ahora bien, si analizamos los 3 pilares de Scrum: Transparencia, Inspección y Adaptación; los mismos nos indican que un equipo a medida que utiliza Scrum, aprende a ser más eficiente. La base de esta teoría es que el equipo sea independiente y tenga capacidad de autogestión.

Sin embargo, esto último también puede terminar con un efecto boomerang: Un equipo puede ir a peor ejecutando Scrum. Y es que, no todos las personas que trabajan en nuestro rubro cumplen con la premisa de “Scrum no es para aficionados”.

Es normal que un equipo, cuando comienza a gestionarse, los resultados no sean los esperados. Es ese punto donde la inspección y adaptación ayudan a que el equipo pueda comenzar a mejorar. Sin embargo, también existe la posibilidad de que un equipo nunca mejore. Que siempre el listón este muy bajo y que no exista un análisis interno de inspección y adaptacion. (Aclaración: en estos casos la transparencia suele estar cercana al 95% de opacidad)

¿Y qué hacer en estos casos? Una opción es volver a dar soporte al equipo, que popularmente lo comparo con criar niños de 3 años. Ayudar en cada paso, ser el facilitador, etc. Un poco de Scrum Master con el rol de padre. Y hasta aquí debes llegar, luego de un par de Sprints es momento de volver a evaluar si el equipo es autosuficiente. En caso contrario … pues cambia el equipo.

Es una pena, sin embargo la motivación con la que algunas personas llevan adelante su trabajo no es la misma que la que tienen otras. Y en el caso de los trabajos con tecnología esta motivación suele ser intrínseca, con lo que los “premios a corto plazo” son una tapadera muy poco productiva.

Una forma de explicar esto es la práctica de “El que rompe la build pone 1€ en un frasco”. El objetivo de práctica no es asustar para que los developers se desangren poniendo miles de €uros (yo lo he hecho), ni tampoco es recaudar para las cervezas de los jueves (también lo he hecho). Esta práctica implica un trabajo de fondo, donde cada persona es suficientemente consciente de que la calidad no es opcional y de que romper la build es detener el equipo en marcha. Y esto es suficiente, muchas personas lo entienden, otras lo ven como una gracia.

Asi que bien, Scrum puede servir para que los equipos aprendan a autogestionarse y a mejorar sprint a sprint; y también sirve para detectar equipos que no poseen ganas de mejorar y .. bueno que tal vez sea necesario cambiar.

 

Scrum Guide: https://www.scrum.org/Scrum-Guide

Scrum no es para aficionados: http://elbruno.com/2013/12/24/scrum-scrum-no-es-para-aficionados/

Saludos @ Home

El Bruno

image image image Google

[#SIGNALR] Error: Html client does not raise OnConnected() method on Server Hub

Hola!

And nor more SignalR stuff. Today is an issue, a tricky one. When in an HTML app the signalR html client does not raise the OnConnected() event on the hub. Sometime ago I wrote a post with a patter to deliver different set of messages to different groups of clients in the same hub..

Inside this code, the main approach is to add some work in the OnConnected(). And at this point this event became more important, because is the first contact of a client with the hub. If you think in the Hub code, can be something like this.

So in the other side, we can create a very simple Html app. This app will connect to the hub and when the connection is established, it will call the JoinToArea() function

So far the code is good. But if you add some trace and debug you’ll see that, even if the call goes fine to the JoinToArea() function in the hub, it never get registered in the OnConnected() event hub. The main issue is because the client is never initialized in the page.

So, to fix this, let´s call a dummy function before we invoke the JoinToArea(). Line 7 and it’s done

Easy Open-mouthed smile

Saludos @ Home

El Bruno

image image image Google

[#SIGNALR] Error: Html client does not raise OnConnected() method on Server Hub

Hola!

Y seguimos con SignalR, en este caso para denunciar a clientes HTML que no entran en el evento OnConnected() del Hub. Hace varios meses que escribí un post donde explicaba una opción para poder definir diferentes canales o grupos de mensajes dentro de un mismo hub.

La base de este patrón es una vez iniciada la sesion, invocar a una funcíón en el server que separa lso grupos en una colección particular. Es en este punto donde el evento OnConnected() toma relevancia porque es un momento muy bueno para poder tener una primera identificación de un cliente conectado al Hub.

Ahora bien, veamos un ejemplo simple de un cliente HTML que se conecta a un hub y cuando la función start() del hub ha terminado invoca la función JoinToArea

A primera vista el código está bien, si activas las trazas, la llamada a JoinToArea() en el hub se realiza correctamente. El problema está en que no se lanza el OnConnected() del hub, ya que no hay ningún requerimiento contra el cliente del hub.

La forma de forzar la llamada al OnConnected es invocar una función dummy del cliente del hub antes de llamar al JoinToArea(). El ejemplo anterior se completa con la línea  7

Fácil Open-mouthed smile

Saludos @ Home

El Bruno

image image image Google

[#VS2013] NuGet Packager, plantilla para crear paquetes NuGet

Hola!

Seguro que casi todos al día de hoy, hemos tenido que crear un paquete NuGet. En mi caso son de uso interno, y siempre lo hacía a mano con algún tool visual.

Hoy, con el laptop limpio, me he encontrado con esta extensión para Visual Studio que permite crear un paquete en los siguientes pasos.

1. Crea un proyecto del tipo NuGet Packager

image

2. Edito la información, a mano del archivo package.nuspec

image

3. Dentro de la carpeta “lib” agrego mis dlls o ensamblados

4. En la carpeta “content” agrego ficheros adicionales, y además en “tools” puedo agregar algún script, por ejemplo de powershell.

5. Luego queda compilar en Release, y definir nuestra api Key para Nuget.org

image

6. Y listo!

En mi caso para el un repo privado, lo que hago es compilar el Debug y luego publico a mano al Repo Winking smile

La mejor opción sería modificar el archivo “NuGet.Config” y en el mismo poner las APIKeys y la url de publicación, aunque para un modelo con una seguridad complicada como el mio, prefiero el modo debug.

image

 

 

Saludos @ Home

El Bruno

image image image Google

[#SIGNALR] FIX: #WindowsPhone and the delayed messages (goes slow slow slow the delivery of messages in WP)

Hello!

SignalR is a platform to real time communications. When you begin creating apps go like a shot, and the truth is that the level of abstraction that gives you is great. Customers .net having to WPF, Win8 and Html work seamlessly, however (isn’t a but) If you think app Windows Phone (8.1 for example), you can find with the strange situation in which the emulator everything is perfect and in the device, not so much.

Note, is not not work but that messages are quite slow in coming (from 5 seconds up to minutes). The test scenario also includes complex authentication methods, is a Website of Azure, which plays the role of SignalRHub.

If we activate the trace in the WP client we can see that the pattern of behavior of the connection is

Connecting, Connected, Reconnecting, Connected, Reconnecting, Connected,…

In few seconds the client connects and disconnected several times. This leads us to think that management of connections (ping that bad say you) it may be wrong, and that the solution is to change the type of transport.

If we look at the problem from a perspective more ampluica, we can find troubleshooting (link), the next solution for Silverlight apps in SignalR :

Messages are delayed when using server sent events on Silverlight. To force long polling to be used instead, use the following when starting the connection:

connection.Start(new LongPollingTransport());

Luckily this solution works also for Windows Phone apps. Now, if you see why this type of transport if works, intuition leads you to MSDN. The amazing thing is that this class is not documented or anything like that (link)

image

So now using touch using LongPollingTransport() , wait for the friends of MSDN to complete documentation or view within the code of SignalR operation of this kind.

Those options or… use a debugger such as Fiddler to make differences there are between the transport by default and LongPollingTransportBut that is for another post Winking smile

Resources: http://www.asp.net/signalr/overview/signalr-20/troubleshooting-and-debugging/troubleshooting#azure

Greetings @ Somewhere around

The Bruno

image image image Google

[#SIGNALR] Fix: #WindowsPhone y los delayed messages (va lento lento lento el delivery de mensajes en WP)

Hola!

SignalR es una plataforma increíble para real time communications. Cuando comienzas ha crear apps vas como un tiro, y la verdad es que el nivel de abstracción que te da es grandioso. Los clientes .Net que tiene para WPF, Win8 y Html funcionan a la perfección, sin embargo (no es un pero)  si creas un app Windows Phone (8.1 por ejemplo), te puedes encontrar con la extraña situación en la que en el emulador todo va perfecto y en el device, no tanto.

Ojo!, no es que no funcione sino que los mensajes tardan bastante en llegar (desde 5 segundos hasta minutos). El escenario de prueba tampoco incluye complejos métodos de autenticación, es un Website de Azure que cumple el papel de SignalR Hub.

Si activamos las trazas en el cliente de WP podemos ver que el patrón de comportamiento de la conexión es

Connecting, Connected, Reconnecting, Connected, Reconnecting, Connected, …

En pocos segundos el cliente, se conecta y desconecta varias veces. Esto nos lleva a pensar en que la gestion de conexiones (el ping que mal le decimos) puede estar mal, y que la solución es cambiar el tipo de transporte.

Si vemos el problema con una perspectiva más ampluica, podemos encontrar en SignalR troubleshooting (link), la siguiente solución para apps Silverlight:

Messages are delayed when using server sent events on Silverlight. To force long polling to be used instead, use the following when starting the connection:

connection.Start(new LongPollingTransport());

Por suerte esta solución funciona también para apps Windows Phone. Ahora, si se te da por ver porqué este tipo de transporte SI FUNCIONA, la intuición te lleva hacia MSDN. Lo increíble es que esta clase no está documentada ni nada parecido (link)

image

Asi que a usar ahora toca usar LongPollingTransport() , esperar que los amigos de MSDN completen la documentación o ver dentro del código de SignalR que funcionamiento de esta clase.

Esas opciones o … usar un debugger como Fiddler para que diferencias hay entre el transporte por defecto y el LongPollingTransport. Aunque eso va para otro post Winking smile

Recursos: http://www.asp.net/signalr/overview/signalr-20/troubleshooting-and-debugging/troubleshooting#azure

Saludos @ Somewhere around

El Bruno

image image image Google