Cuando en identity no devuelve el nombre del usuario.

He hecho una pequeñito método de la clase de seguridad (utilizando la técnica de TDD, muy maja por cierto) para que me devuelva el nombre del usuario identificado en el Directorio Activo.

/// <summary>
/// Devuelve el nombre del usuario del Directorio Activo.
/// Eliminando el dominio.
/// </summary>
/// <returns></returns>
public static string usuarioAD()
{
IPrincipal user = System.Threading.Thread.CurrentPrincipal;

string userName = user.Identity.Name;
int posicionBarraSeparacion = userName.IndexOf('\\');

userName = userName.Substring(posicionBarraSeparacion +1);

return userName;
}

Lo curioso es que cuando lanzaba el test, me daba verde. Pero al probarlo en el localhost o en el servidor de desarrollo, no me devolvía más que una cadena vacía.

Dándole una vueltas a la cabeza me acordé que el problema vendría del tipo de identificación del navegante en el IIS y, efectivamente, tenía configurado el Directorio Virtual con acceso anónimo. En cuanto lo he configurado como Autenticación de Windows, todo solucionado.

Error por una propiedad null

El mes de Marzo escribí un post sobre cómo solventar este error (que en aplicaciones de escritorio se corrige con un patrón null object) cuando trabajamos con persistencias en variables de sesión o en el viewstate.

Pero hete aquí que me encuentro que si combino una variable de sesión con una propiedad de tipo enumerador… casca. Por lo cual aquí publico otro código encontrado por las tierras de San Google para hacer lo mismo pero un poquillo más complejo y bastante más robusto.

public TipoDeLaPropiedad nombreDeLaPropiedad

{
get{
Object objeto = Session["nombreDeLaPropiedad"];
if (objeto == null)
{ return ; }
else{ return (TipoDeLaPropiedad )Session["nombreDeLaPropiedad"]; }
}
set { Session["nombreDeLaPropiedad"] = value; }
}

Error al abrir un fichero .dbml ‘no se pudo recuperar el proyecto actual’

Un error molesto, fastidios e incómodo. Un proyecto de LinQ to SQL que funciona perfectamente, de un día a otro empieza a dar un error de compilación en el modelo, señalando la causa en la línea 1 de fichero .dbml con el mensaje que es el título de este post.

Buscando en castellano en San Google no encontré ninguna respuesta mas que reinstalar el sistema operativo completo (menuda solución!!). Pero en inglés si que encontré la solución:

Devenv.exe /ResetSkipPkgs

Este comando, desde el botón de inicio, lo que realiza es el reinicio de todos los paquetes del Visual Studio que le hemos dicho que no cargue al darnos algún problema en el inicio. Típica ventanita que la quinta vez que nos alerta, dejamos de leerla y le decimos que “Yes” por defecto. Y que deshabilita el paquete de gestión de XMLA, que es el que nos permite utilizar los diseños desde un archivo .dbml.

Y voala!! Todo funcionando al 100% de nuevo.

/ResetSkipPkgs

Cómo introduje SCRUM en un equipo nobel. Cap. 3.

Cuarto sprint… y la velocidad del equipo se ha multiplicado por tres. Empezamos el sprint 1 con poco más de 80 horas planificadas y ahora estamos en más de 210 horas y, muy posiblemente, tenga que introducir nuevas tareas porque las están devorando.

Pero hay que seguir mejorando y los siguientes pasos a realizar en la conversión de horas estimadas a puntos de historia (aunque le tengo que dar un par de vueltas si tiene sentido en este equipo).

También, en el fragor de la batalla, que han sido múltiples y estruendosas, me he olvidado de la visibilidad del desarrollo para gerencia que, literalmente, están ciegos y no saben qué tal va el proyecto. El cliente si lo tiene claro, pero mi director no hace más que pedirme algún tipo de reporte que le deje tranquilo a el y a nuestros socios. Y con toda razón.

Por lo cual me he cogido otra vez el libro Scrum y XP desde las trincheras y estoy recordando cómo han hecho scrum otras personas y, en especial, reforzar lo que se me ha quedado muy descolgado en este proyecto: la planificación en el sprint 0. Por ejemplo, aún no tengo un producto backlog que describa todas las funcionalidades que el cliente me ha requerido, un planning inicial o un grupo de historias de usuario (análisis funcional) que eviten que convierta en el “héroe” del proyecto (justamente lo que se intenta evitar en esta metodología Agile).

Curioso, tan centrado en que mi equipo entendiera y asimilara la forma de trabajar con SCRUM, que he caído en antipatrones y errores metodológicos básicos.

Otra cosa que debemos mejorar y modificar es la definición de Done. Si bien estamos llegando a finales de sprint con prácticamente todas las tareas realizadas, no estamos cumpliendo de forma rigurosa el que lo obtenido sea un incremento de valor y que las funcionalidades estén listas para ser puestas en producción. Ni tan siquiera en preproducción.  Lo cual me lleva a la duda de si sería conveniente ampliar una semana los sprint. Pasando de de dos a tres.

Bueno, en la próxima entrega compartiré la resolución de estas dudas.