Fallo del Update con Linq to Entities

Hoy cogería al arquitecto responsable de los mensajes de error de Linq to Entities por el cuello y lo ahogaría – pero sin matarlo – por la tarde perdida siguiendo un mensaje de error que desorientaba y que me hizo recorrer los profundos vericuetos de San Google para, al final, hallar la solución en mis narices.

Compañeros: Cuando tienes una bonita entidad y le creas un método de actualización como:

public bool ModificarAsignacion(string codDeposito, int idTurno)
{
Madrid_MovilidadEntities dbv = new Madrid_MovilidadEntities();
var asig = (from asignacion in dbv.Conductores_Gruas
where asignacion.codigo_deposito == codDeposito
&& asignacion.id_turno == idTurno
&& asignacion.asignado == true
select asignacion);

if (asig.LongCount() > 0)
{
foreach (Conductores_Gruas asignados in asig)
{
asignados.asignado = false;
}
dbv.SaveChanges();
           }

Y cuando, lo lanzas se te queda tostado el servidor - si le tienes un Try Catch puesto – o te sale un mensaje espantoso que dice algo así:

“La búsqueda de no se pudo actualizar entityset 'conductores_gruas' porque tiene <definingquery> y no existe ningún elemento <updatefunction> en el elemento <modificationfunctionmapping> que admita la operación actual. no obtuvo ningún resultado.”

No te agobies buscando y buscando. Es más no te compliques la vida cambiando de tecnología e intentándolo con Linq to SQL (tampoco te va a funcionar y tampoco te va a decir porqué). La solución es mucho más sencilla.<

En tu modelo de datos hay una tabla sin clave o claves primarias
 
Lo cual lleva al ORM a avisarte (si es cierto que avisa, pero no le hice ni caso) y te crea una vista o entidad de esta tabla SOLO PARA LECTURA.

Por lo cual la solución es modificar el modelo de datos para que esa tabla tenga al menos una clave primaria. Y actualizar (yo lo borré y lo hice de nuevo) el modelo de entidades… y voala!!

Como introduje Scrum en un equipo novel.

Bueno, segunda semana con el equipo de noveles. Segunda semana de satisfacción y segunda semana de tensión para poder trabajar en el proyecto.

Después de varias instalaciones y mucha configuración tanto el servidor de SQL server 2005 como el TFS 2008 ya están funcionando ambos y con los permisos adecuados. Además, y por fin, nos  ha llegado la pizarra en donde hemos dibujado de forma inmediata un panel Scrum, olvidando –por ahora- Kanban. Ya que Scrum me es más útil tanto para la disciplina del equipo como para la visibilidad del proyecto ante los jefes y el cliente.

Como no tengo Product Owner, tengo que ejercer ese Rol y medio fusionarlo con el Scrum Master. La realidad siempre es más complicada que la teoría. Por lo cual para empezar el sprint cero defino el Product Backlog que es muy, muy corto, para así darle un ancho margen de beneficio al equipo. Ya que son bastante más nóveles de lo que me esperaba.

Una vez configurado el TFS, les explico lo que es un Sprint Planning meeting y empezamos a dividir el módulo principal para elegir las tareas del Sprint Backlog. Aún no les pido estimaciones de tiempo para no liarles mucho, pero si les empujo a realizar una subdividision de las tareas elegidas para el sprint para que miren más allá de la tarea general y descubran las actuaciones que constituyen la construcción de la misma. Así, más adelante podrán estimar con mayor seguridad y estarán acostumbrados a localizar la simplicidades y complejidades inherentes al desarrollo de una pieza del puzle.

Empezamos el sprint cero y les explico que nuestro trabajo debe generar métricas para su seguimiento y que para ello cada vez que se vaya a realizar un check-in de código, van a tener que elegir el workitem al que se va a asignar el mismo. Así obtenemos la métrica del trabajo realizado y por realizar y les muestro nuestra estrella de la métrica: el BurnDown Sprint.

Lo siguiente es un acto de fe: los Daily Meeting. Les veo emerger la duda en los ojos cuando les digo que son reuniones diarias, a la misma hora, de pie y de no más de quince minutos. Además, para reforzar su sensación de inutilidad, como están trabajando en pareja las respuestas  a las tres preguntas, ¿Que hice ayer?¿Que haré hoy?¿Que impedimentos tengo?,  son iguales.

El mejor momento llega después de la segunda reunión diaria cuando me señalan que yo no he respondido a mis tres preguntas… ya está la magia en acción !!  Al igual que en casos anteriores, las reuniones diarias se convierten en una costumbre que le encanta a los equipos y multiplica la comunicación.

El cuarto día del sprint cero la pizarra tiene un aspecto buenísimo. De un vistazo vemos el estado del sprint y, efectos de iniciar el proyecto con Kanban, se auto limitan las tareas sin que me tenga de preocupar de tener demasiadas abiertas y sin cerrar. Además, los test unitarios ya son parte del propio desarrollo y poco a poco están enseñando su gran ventaja. No los ven como el doble de trabajo, si no como un nivel más de seguridad y un reto intelectual.

La comunicación es muy buena y el ritmo, teniendo en cuenta que en mi previsión solo habíamos cogido tareas para el 50% del sprint, bastante aceptable.

La última alegría es cuando pongo mi flamante BurnDown Sprint Chart en la puerta del armario y se lo enseño a mis dos directores… los cuales lo entienden de forma inmediata. El tablero Kanban - ahora Scrum – ya lo están utilizando para saber como vamos. O sea, que todos contentos (y eso que la documentación CMMI la tengo un poquillo abandonada).

El viernes, medio sprint atrás ya, les enseño a iniciar y cerrar WorItem en el tfs. A crear nuevos, desde el Web Acess, relacionados con los demás. Y les dejo irse con un pequeño lio en la lógica de negocio pero con HAMBRE de hacer las cosas bien.

La próxima semana tengo que darle acceso a los informes del TFS/Cochango a los directores y explicarles qué están viendo. Preparar un servidor de desarrollo con acceso desde internet para publicar los desarrollos al que el cliente tenga acceso y que me dé el feedback lo antes posible y de forma continuada. Y preparar el fin del sprint, la retrospectiva, decidir la longitud del siguiente sprint, preparar la mudanza a las oficinas del cliente y vuelta a empezar.

Muy mal debe ir la cosa para que este proyecto no sea otro éxito.

Leer la conectionstring del web.config desde un proyecto asociado.

Premisa: Tenemos una solución compuesta por un proyecto del tipo Sitio web y un proyecto del tipo Biblioteca de clases en donde estamos construyendo nuestra capa de datos y que hemos llamado DAL.

Queremos, desde la DAL, recuperar la conectionstring que está almacenada en el web.config del proyecto Sitio Web.

Solución:

1. Añadir las referencias del tipo .NET:
     System.Web
    System.Configuration

2. Añadir los using, que sí son duplicados pero nos simplifican la sintaxis del código.
using System.Web;
using System.Configuration;

3. Invocar a la cadena de conexión en el web.config con el siguiente método (o la variación que se te ocurra.

/// <summary>
   /// Devuelve la cadena de conexion a la base de datos
   /// </summary>
   /// <returns></returns>
   public string cadenaConexion()
   {
       string retValue = string.Empty; ; 
       retValue = System.Web.Configuration.WebConfigurationManager.ConnectionStrings["pruebaConnectionStringSQL"].ConnectionString;

       return retValue;
   }
Listo.

Scrum vs Kanban en Castellano

He tenido el privilegio y el honor de participar en el equipo de traducción/edición de este interesantísimo libro sobre ambas metodologías. Sus ventajas e inconvenientes.

Pero para una explicación más completa y entretenida, os remito al blog del coordinador Angel Medinilla.

Y para bajarlo directamente (ojo, pesa unos 74Mb).

Que lo disfrutéis!!

Kanban, Scrum, CMMI light.

“La vida te da sorpresas” decía Rubén Blades en su canción Pedro Navaja. Y llevando casi un mes mirando las paredes en mi antigua empresa, me llegó una oferta de trabajo tan interesante como crítica en su plazo de decisión. Como “las oportunidades solo se dan una vez” y “camarón que se duerme se lo lleva la corriente”, he cerrado una etapa de casi tres años en Alten, donde he realizado de todo tipo de labores. Y empiezo en mi nueva empresa –Quadramqs- como Jefe de Proyecto . NET. Bueno, más bien líder de equipo. Es decir, sigo picando código y además hago la documentación.

Lo bueno es que al ser una empresa joven tengo capacidad de decisión sobre la metodología a utilizar y un equipo de nóveles que me acompañan en el “hambre” por probar cosas nuevas.

En el primer aterrizaje, lo primero es “levantar” el servidor de base de datos y el servidor del repositorio de código/documentación. Es decir instalar un SQL2005 y un servidor TFS. Mientras espero que entre Sistemas y yo montemos el tinglado y quede accesible a todo el dominio – revienta todo cuando a la máquina de un tfs la metes en dominio – tengo que probar el conocimiento y velocidad del equipo que, además, está habituado a la metodología ASM (A Salto de Mata @Rodrigo del Corral)  y más bien llegan justos de conocimientos.

Para ello ataco dos vertientes diferentes de modo simultáneo:

1. Técnica:  Les pongo un ejercicio de construcción de una pequeña aplicación en donde, aumentando la complejidad poquito a poco, veo cuales son sus límites y sus conocimientos. Arquitectura de dos capas, datos y representación. Acceso a los datos por Linq to Entities. Pruebas unitarias para cada método. Cargas de datos con SqlAdapter. Y construcción manual de GridView.

2. Metodología: Con el objetivo final de utilizar SCRUM en el desarrollo del proyecto real, tengo que empezar con un tablero Kanban de tres columnas: ToDo, Doing(2), Done. Y, además, este tablero será virtual en Scrumy ya que aún no tenemos el tablero físico.

Insistiendo un poquito y revisando desde internet en casa o en la calle el tablero y comentándolo al llegar a la oficina, motivo para que lo mantengan actualizado, pero observo cierta tendencia a tenerlo en segundo plano. Más como un reporte qué como seguimiento del flujo de trabajo.

A los pocos días llega nuestra flamante pizarra y plasmamos el tablero con rotulador. Y entonces si que se convierte en un punto en donde sin tener que preguntarme, el propio equipo decide qué tarea hacer y cuando. Ha llegado el momento de darle una vuelta de tuerca a la metodología y les pido estimaciones.

Esto provoca en los noveles incomodidad ya que lo entienden como fiscalización. Pero después de dos o tres previsiones fallidas, pero cada vez más cercanas, se convierte en una motivación más y se les ve como empiezan a sentirse responsables de sus actuaciones. Se implican… :)

La próxima semana empezamos a trabajar en el proyecto real. Las tareas realizadas ahora, sin que ellos lo supieran, son exactamente las mismas que vamos a realizar para construir el primer módulo que nos va a llevar el primer sprint. Y el lunes conocerán que es un planning meeting, e intentaré ser disciplinado con las daily meeting.

Mientras, en mi lado de Gestor del proyecto. Tengo mil reuniones de toma de requisitos en donde lo de las “historias de usuario” es pura ciencia ficción. De todo lo leído he puesto en práctica el recorrerme todos los puestos de los usuarios reales de la aplicación y estar con ellos horas hablando, recabando sensaciones, mejoras y problemas. También realizo actas de reuniones tipo CMMI level2, y quiero realizar análisis funcionales de cada módulo a realizar ANTES de llegar al inicio del sprint, tanto como documentación para el cliente como para el Backlog Product.

Para dar una vuelta de tuerca a la visibilidad del proyecto, además de las entregas de cada iteración, pondremos el servidor de desarrollo accesible al cliente para que nos indique las desviaciones lo antes posible.

Jo!! Que gusto volver a estar en la brecha.

Linq to Entities. Alias de columnas para un DropDownMenu

Los cambios siempre estresan. Y el cambiar de un ADO.NET en T-SQL a Linq to Entities me está produciendo algún que otro ardor de estómago.

Es el caso en el que quiero mostrar el nombre y apellidos en un DropDownMenu de ASP.net. Y en mi antigua cadena SQL lo que hacia era:

"SELECT idPersona, idNombre + " " + idApellido1 + " " + idApellido2 AS Persona FROM Personas"

Pero ahora en LinQ es una de esas cosas que buscas y rebuscas por Google y nada. ¿Porqué? Porque es tan sencillo que es muy difícil encontrarlo:

var db = new PruebasModel.PruebasEntities();
var losVehiculos = db.Vehiculo;
var resultado = from vehiculo in losVehiculos
select new{vehiculo.idVehiculo, persona = vehiculo.matricula + " " + vehiculo.matricula};

Ya solo me queda meterlo como dataSource de mi combo y voala!!.

DropDownList1.DataSource = resultado;
DropDownList1.DataValueField = "idVehiculo";
DropDownList1.DataTextField = "persona";
DropDownList1.DataBind();

¡El libro de TDD se ha publicado!

Carlos Ble, junto a un impresionante grupo de colaboradores, ha publicado el – posíblemente – primer libro de desarrollo TDD en el idioma de Cervantes.

Como soy un personaje rehacio a esta métodología (picar el test antes que el código) inmediatamente lo he leido de cabo a rabo. Y he de muy señalar que es un muy buen libro, a mi entender, por el excelente ejercicio práctico que se realiza de una super calculadora y en el que Carlos nos lleva de la mano  utilizando TDD.

Lo curioso es que, para mí, es una joya desde el punto de vista de la exquisitez de su pureza en la programación orientada a objetos siguiendo las recomendaciones SOLID y las buenas Prácticas. Provoca una apabullante sensación de calidad y de claridad tanto en la refactorización como en el análisis inmediato de qué y cómo hacer que el código sea límpio y eficiente.

Esta obra empuja al lector – apasionados del desarrollo – a mejorarse a sí mismo ante la constatación de lo mucho que  se puede seguir aprendiendo en esta profesión antes de poderse declarar medianamente satisfecho.

En resúmen, un libro para sentarse e ir practicando con detenimiento cada una de las piezas que lo componen y así asimilar los cuando y los porqué del diseño emergente que vá surgiendo. Hijo de los test y de las refactorizaciones.

A mí, ya me ha enseñado mucho.

Web del autor Carlos Ble