La masa, el ladrillo, la bota, el bocadillo…

Os dejo un script que elimina todos los índices que siguen un determinado patrón. Yo lo suelo utilizar para eliminar todos los índices que he creado tras usar el Index Tunning Wizard y seleccionar aquellos que realmente me resulta útiles o para poder volver a la línea base que tenía antes de utilizarlo. Podéis cambiar el LIKE ‘_dta_%’ por el patrón que deseéis.

También suelo utilizar este script en sesiones de optimización. Voy añadiendo índices con diferentes prefijos según el escenario que estoy optimizando, veo su impacto sobre el servidor y si quiero eliminar una serie de índices que he añadido para optimizar un determinado escenario lo puedo hacer con suma facilidad.

/* OJO: Este script es peligroso */
/* Comprobar que la select devuelve los índices que realmente deseamos borrar */

DECLARE @Index VARCHAR(128)
DECLARE @Table VARCHAR(128)

SELECT OBJECT_NAME(id) AS [table], name AS [index]
INTO #Indexes
FROM sysindexes
WHERE name LIKE '_dta_%' --Índices y estadísticas creados por el DTA

WHILE (SELECT COUNT(*) FROM #Indexes) > 0
BEGIN
   SET @Index = (SELECT TOP 1 [Index] FROM #Indexes)
   SET @Table = (SELECT TOP 1 [Table] FROM #Indexes)

   IF (@Index LIKE '_dta_stat_%')
       BEGIN
           PRINT 'DROP STATISTICS ' + @Table + '.' + @Index + CHAR(13)
           EXEC ('DROP STATISTICS ' + @Table + '.' + @Index )
       END
   ELSE
       BEGIN
           PRINT 'DROP INDEX [' + @Index + '] On [' + @Table + ']' + CHAR(13)
           EXEC ('DROP INDEX [' + @Index + '] On [' + @Table + ']')
       END 

   DELETE FROM #Indexes WHERE [Index] = @Index AND [Table] = @Table
END

DROP TABLE #Indexes

¡Quizás os sirva a vosotros también!

Un año más Microsoft ha tenido a bien distinguirme en una ocasión más como MVP en la categoría de Team System. Es la séptima vez que soy MVP, tres veces en la categoria de C++ y cuatro más en la de Team System, y no por ser la séptima vez la ilusión es menor. Ilusión que nace de poder compartir un año más de eventos y buenos ratos con el resto de MVPs y la comunidad, que es lo que realmente hace importante este reconocimiento.

Quiero aprovechar para agradecer a la comunidad la excelente acogida que han dado a todos mis eventos, artículos, participaciones en grupos de usuarios, a mi blog y a Geeks.ms. Sin esta excelente acogida, el reconocimiento, el apoyo y el ánimo que la comunidad me brinda, yo no sería MVP. En especial quiero mencionar a la gente de Artalde, dotNetMania y mis compañeros de Plain Concepts y de Sisteplant.

También quiero agradecer todo lo que de la comunidad aprendo que es mucho más valioso que el reconocimiento como MVP, a pesar del valor que le doy.

Espero estar a la altura del reconocimiento que Microsoft me ha otorgado.

Pido disculpas por el autobombo, pero ¡la ocasión lo merece!

Que no parametrizar las consultas es fuente de problemas es algo que cada vez más desarrolladores conocen. Se ha hecho mucha labor didáctica sobre este tema en los últimos tiempos. Pero nunca esta de más recordar estos problemas. A raíz de un caso que hemos tenido recientemente en el Debuging & Optimization Team de Plain Concepts, me he decidido a hablar de este tema.

Si no usamos consultas parametrizadas los problemas principalmente son dos:

Uno de seguridad, puesto que nuestras consultas serán susceptibles de sufrir ataques por inyección de SQL. Este no es el que me ocupa hoy. Aunque es un tema que ya traté con anterioridad.

Otro de rendimiento, puesto que nuestras consultas no serán capaces de reutilizar el plan de ejecución de consultas similares. Este es el problema que hoy me ocupa. Si no se reutilizan los planes de ejecución al coste de ejecutar una consulta habrá que sumar siempre el coste de buscar el plan de ejecución adecuado.

Si bien es cierto que gracias a dios cada vez es menos frecuente, no es menos cierto que millones de aplicaciones, muchas de ellas desarrolladas antes de que tomásemos consciencia del problema, sufren problemas relacionados con las consultas no parametrizadas.

¿Qué diferencia una consulta parametrizada de una no parametrizada?

Cuando usamos consultas no parametrizadas, típicamente, usamos la concatenación de cadenas para variar la consulta que enviamos a SQL Server desde nuestro programa. Podéis ver esta técnica en la siguiente porción de pseudo código. En este caso SQL Server no puede saber que realmente estamos ejecutando la misma consulta.

Sin embargo cuando usamos consultas parametrizadas, en lugar de concatenar el valor de variables como cadenas, escribimos nuestras sentencias utilizando parámetros y luego ejecutamos la consultas asignando previamente valores a los parámetros. SQL Server siempre verá la misma consulta, podrá detectar la situación y reutilizar el plan de ejecución. El código en este caso sería algo similar a:

int ContactID = 100;

 

string sql =

    «SELECT FirstName, EmailAddress FROM Person.Contact « +

    «WHERE ContactID = @ContactID»;

 

using (SqlConnection cn = new SqlConnection(connectionString))

using (SqlCommand cmd = new SqlCommand(sql, cn))

{

    cn.Open();

    SqlParameter param = new SqlParameter(«@ContactID», ContactID);

    cmd.Parameters.Add(param);

    cmd.ExecuteNonQuery();

}

SQL Server asocia los planes de ejecución con la cadena SQL que debe asociar en cada caso, si para consultas similares, que solo se diferencian en parámetros, utilizamos sentencias diferentes fruto de la concatenación de cadenas, SQL Server no será capaz de saber que puede reutilizar el plan de ejecución.

¿Cómo detectar que nuestro SQL Server está sufriendo por culpa de las consultas no parametrizadas?

Tenemos varias técnicas y hay varias pistas que nos pueden llevar a concluir que tenemos este problema en nuestro servidor y que el rendimiento del mismo se está viendo penalizado.

 

 

Podemos usar los contadores de rendimiento de SQL Server:

Fijaros en la situación que podemos ver en la pantalla anterior. Mirando el contador SQLServer:SQL Statitics:SQLCompilations/sec vemos que coincide con el número de SQLServer:SQL Statitics:Batch Requests/sec, la conclusión es clara: todas las select que estamos lanzando están provocando la generación de un nuevo plan de ejecución, fuente clara de perdida de rendimiento. Una relación cercana a uno entre estos dos contadores es, casi siempre, síntoma inequívoco de que nuestras consultas no están parametrizadas. Este diagnóstico se ve apoyado por el contador SQLServer:SQL Statitics:Auto-Param Attemps/sec.

 

Si miramos además los contadores relativos a la cache de planes vemos que tenemos un Cache Hit Ratio muy bajo, de más o menos el 50% para los planes de ejecución (SQL Plans) y también podemos observar que casi toda la cache está ocupada por SQL Plans.

También podemos observar el contenido de la cache con la consulta que podéis ver en la siguiente captura:

Se puede observar que todos los planes corresponden a la misma consulta y que esta sería fácilmente parametrizable.

Otro mecanismo para identificar esta situación es ver como se reparte la cache, por ejemplo con la siguiente consulta:

 
Podemos ver en los resultados de la ejecución que muestro en la imagen que tenemos la friolera de 0,92 Mb en 38008 planes de ejecución. Sin duda otro mal síntoma que apunta a una pésima reutilización de planes de ejecución.

También podemos ver esta misma información de forma gráfica utilizando los informes de SQL Server:

Si la cache de SQL Server se llena de planes de ejecución, un problema adicional que penaliza el rendimiento, es que no tendremos capacidad para cachear otro tipo de objetos como por ejemplo páginas de datos.

Ahora que ya sabemos como detectar la situación…

¿Qué podemos hacer?

Desde SQL Server 2005 tenemos una utilísima característica que puede ayudarnos a mejorar el rendimiento de nuestro servidor. Se trata la parametrización forzada. Cuando la opción Parametrización de se establece en Forzada, cualquier valor literal que aparezca en una instrucción SELECT, INSERT, UPDATE o DELETE, enviada de a nuestro servidor, se convierte en un parámetro durante la compilación de consultas. Esta opción se establece a nivel de base de datos, bien desde la interfaz de usuario:

O con la sentencia:

ALTER DATABASE [NombreDeBaseDeDatos] SET PARAMETERIZATION FORCED

Por defecto la paremetrización forzada no está activada, el motivo es que lógicamente tiene un coste, y que solo supone un beneficio en los casos en los que las aplicaciones están lanzando consultas no parametrizadas a la base de datos.

Corolario

• Las consultas no parametrizadas son malas para la seguridad y el rendimiento de nuestro SQL Server. Siempre debemos usar consultas parametrizadas, no valen disculpas.
• SQL Server asocia los planes de ejecución con la cadena SQL que debe asociar en cada caso, si para consultas similares, que solo se diferencian en parámetros, utilizamos sentencias diferentes fruto de la concatenación de cadenas, SQL Server no será capaz de saber que puede reutilizar el plan de ejecución.
• Contamos con numerosas posibilidades para comprobar si las consultas no parametrizadas están afectando al rendimiento de nuestro servidor.
• A veces hacer que aplicaciones ya existentes pasen a usar consultas parametrizadas supone cambiar miles de líneas de código.
• Podemos evitar el impacto sobre el rendimiento de las consultas no parametrizadas estableciendo la parametrización forzada de nuestra base de datos.
• La parametrización forzada no arreglara los problemas de seguridad.

¡Espero que os sea de ayuda!

El pasado martes estuve participando como ponente en las ALM’09 Sessions. Un exitazo de evento que reunión a más de 800 profesionales interesados en mejorar la gestión del ciclo de desarrollo de sus aplicaciones. La agenda que propuso Microsoft y la calidad de los ponentes tubo una clara respuesta. Plain Concepts era uno de los patrocinadores del evento y colaboramos con tres charlas. Yo hablé en el track de procesos, mi compañero Jose Luis Soria hablo de ecosistemas heterogéneos de desarrollo y Team System, y mis compañeros Pablo Peláez y Ricardo Acosta, hablaron de como integrar a los diseñadores en el ciclo de vida.

Como no podía ser de otro modo hablé de Scrum, aderezándolo esta vez, con un poco de buenas prácticas y con un tema que cada vez me preocupa más, la gestión de la configuración en equipos ágiles. El motivo es que veo cada vez más aberraciones de arquitectura, complejidad innecesaria y disfunciones en el ciclo de vida que se pueden solucionar con una política de gestión de la configuración. La gestión de la configuración es una de las ramas más desconocidas, más infrautilizadas y peor utilizadas cuando se usa, de la ingeniería del software.

Os dejo la presentación que realice:

Como siempre, lo mejor en este tipo de eventos fue la oportunidad de charlar con compañeros de la comunidad, amigos, clientes y gente interesada en la gestión de sus proyectos y las tecnologías de Microsoft.

¡Un saludo!

Gracias a la amable invitación de Juan Carlos, MVP y miembro del CIIN fui invitado junto a Ibon Landa y Juan Irigoyen, a participar en un evento en Santander. El evento consistió en una reedición del Foro de Arquitectos (podéis seguir el link si queréis la ppt) en el que había participado en Madrid y Barcelona.

El evento reunión a tres decenas de profesionales del mundo informático cántabro, entre los que quiero resaltar al compañero de Geeks.ms Miguel Sierra, más que nada por que en la comida posterior al evento hubo mucho debate muy interesante sobre CMMI vs. Scrum y la idea de realizar ese debate en forma de evento… ¡algo que seguro que haremos!, estad atentos.

Sodercan TV siguió el evento y publicó una pequeña reseña sobre el evento. Desde luego no se quien eligió los cortes, pero en lo que a mi respecta… no me parece que me quisiese bien ;).

¡Un saludo!

¡Un saludo!

Escribía hace un tiempo sobre el triangulo de gestión de proyectos y la férrea dictadura que impone sobre la gestión de proyectos. En esencia, uses la metodología que uses para la gestión de proyectos o incluso si no usas ninguna hay cuatro factores sobre los que, como gestor de proyectos, puedes llevar a cabo tu gestión: la calidad, el alcance, el coste y el tiempo. De todos estos factores, el cliente puede controlar como máximo, tres. El cuarto será el que nos permite gestionar. Si el cliente o alguien externo a la gestión del proyecto controla la totalidad de los aspectos ¿que papel nos queda como gestores del proyecto?.

Dado que el dichoso tirano triángulo nos impone su realidad, cabe plantearse una serie de cuestiones sobre el mismo y su relación con Scrum: ¿Cuál es la relación de Scrum con estos factores? ¿Cómo se actúa sobre ellos en Scrum? ¿Cómo condicionan esta metodología? ¿Qué decisiones explicitas han tomado los diseñadores de Scrum sobre ellos? Estas son las preguntas que quiero responder, en la medida de mis conocimientos, con esta serie de post.

Hoy hablaremos de la calidad, desde la perspectiva de Scrum.

La calidad no es opcional, no es un factor sobre el que podamos especular. Ni siquiera lo podemos gestionar explícitamente: cualquier decisión que tomemos puede ser dañina, vaya esta en el sentido de incrementarla como en el sentido de reducirla. Es un aspecto que siempre decide el cliente no quien gestiona el proyecto. Si decidimos recortar calidad para ganar velocidad, por ejemplo, tarde o temprano lo pagaremos si la calidad que logramos no es la que el cliente está dispuesto a aceptar.

El riesgo, ocurre a menudo, es sobrereaccionar. Para asegurarnos de que cumplimos las expectativas ponemos más calidad de la necesaria en el proyecto. El problema es que la calidad adicional tiene un coste, pero sin embargo, no es percibida por el cliente. Suelo poner siempre el mismo ejemplo, que explica muy bien este asunto, solo es un ejemplo, que nadie se quede con los valores absolutos. A mi me gusta el vino, el buen vino, estoy dispuesto a pagar por un vino de cierta calidad. Si alguien me quiere regalar vino, que no se gaste más de 25 euros, ni menos de 10. Por debajo de 10 euros, es probable que el regalo no cumpla su cometido de agradarme, por encima de 25, estará tirando el dinero, ¡mi paladar no es capaz de distinguir un vino de 25 euros, de uno de 35!. A partir de 25 euros todos los vinos me parecen excelentes. Descubrir el nivel de calidad que satisface al cliente al menor coste, es nuestra principal labor a la hora de gestionar la calidad.

El otro aspecto clave la gestión de la calidad es mantenerla a lo largo del proyecto. Es sumamente difícil medir el nivel de calidad de una manera objetiva, precisamente, por que es algo que depende de los usuarios, de los clientes y de su percepción subjetiva. Pero siempre tenemos una idea más o menos intuitiva o analítica (será más analítica si tenemos métricas claras, un proceso de aseguramiento y validación y sobre todo si tenemos testers) sbore cual es nuestro nivel de calidad que nuestro cliente requiere. Y sobre todo de cuan lejos estamos del nivel de calidad que nuestro cliente esta dispuesto a aceptar: ¿se beberá nuestro cliente un Don Simón o un Castillo de Vulpi (dignísimos vinos en brick para calimotxo, pero capaces de corroer una copa de cristal) sin negarse a pagar la cuenta?. Supongamos que no, ¿cómo podemos descubrir que nuestro cliente no se conformará con nuestro Don Simón, sino que quiere mínimo un rioja joven un poco decente y en botella?. Y sobre todo, una vez que lo descubrimos, que sabemos el nivel mínimo de calidad que satisface a nuestro cliente, ¿cómo aseguramos que no estamos elaborando Don Simón?. Por que estaremos de acuerdo en que si estamos elaborando Don Simón es muy muy difícil que al final, hagamos lo que hagamos, logremos que nos salga un Vega Sicilia (¡hay clientes muy exigentes!). Debemos evitar a toda costa darnos cuenta al final de que no hemos alcanzado el nivel de calidad que nuestro cliente requiere, es un riesgo que no podemos asumir.

El único enfoque que funciona, es, sin duda el mantener de manera constante, durante toda la vida del proyecto, un nivel de calidad que sea aceptable al cliente. Si no averiguamos el nivel de calidad que el cliente esta dispuesto a aceptar y no lo mantenemos a lo largo del ciclo del vida del proyecto, a final, cuando los recursos y el tiempo que nos queden sean más bien justos, tendremos que, aunque la funcionalidad este completa, el proyecto se alargará para alcanzar el nivel de calidad necesario.

Las claves son claras: descubrir el nivel mínimo de calidad que el cliente esta dispuesto a aceptar y mantenerse alrededor del mismo durante todo el proyecto. La pregunta es ¿qué mecanismos establece Scrum para que esto ocurra?: El sprint review y los incrementos de funcionalidad potencialmente entregables.

El sprint review, actúa como regulador de la calidad. Por un lado nos va a permitir detectar, mediante el feedback que los asistentes aporten, si estamos lejos o no del nivel de calidad requerido. Además, que el equipo presente las nuevas funcionalidades, es un catalizador clave de la calidad: asegurando una calidad mínima (da mucha vergüenza que te ‘casque’ una demo) y asegurando que el equipo percibe cual es el nivel de calidad mínimo aceptable.

Los incrementos de funcionalidad potencialmente entregables son otro aspecto clave de Scrum. Si algo es ‘potencialmente entregable’, como debe ser el resultado de todo sprint en Scrum, debe cumplir las expectativas de calidad de nuestro clientes (o de su proxy, el Product Owner). Si algo no cumple las expectativas del cliente, no está completado y no se sigue avanzando. Esta es la única manera de asegurar que el equipo no toma atajos sacrificando funcionalidad o no cae en el preciosismo, añadiendo calidad que el cliente no está dispuesto a apreciar y mucho menos a pagar.

Un error habitual es recortar el sprint review o saltárselo, de tal manera que el equipo nunca llega a descubrir cual es el nivel de calidad mínimo aceptable por el cliente o no se asegura que no estamos lejos de este.

En la próxima entrega, Scrum y el triangulo de la gestión de proyectos: El alcance.

Aun estoy que no me lo creo. Pedazo de evento nos ha salido, y cuando digo nos ha salido me refiero a los 160, si 160, asistentes. Aunque los patrocinadores y la organización también hemos tenido algo que ver seguro. No cito a nadie de la organzación para no dejarme a nadie: compromiso compartido y responsabilidad compartida, para lo bueno y lo malo.

No esperaba yo tanto de este evento, sobre todo era bastante escéptico en lo que al formato de open space se refiere. Eso de no tener una lista de sesiones de antemano me ponía un poco nervioso ¿cómo podía saber que las sesiones merecían un viaje desde Bilbao? ¡Nada me garantizaba tener un hueco a pesar de que mi empresa patrocinaba el evento! ¿y si no había temas suficientes? ¿y si había mucho? ¿y si construir la agenda era un proceso eterno?… El resultado a tener de la retrospectiva que entre todos los asistentes realizamos al final del evento no puede ser más satisfactorio. En lo personal decir que a sido uno de los eventos en los que más he disfrutado… y mira que he participado en eventos ¿eh?…

La primera jornada del evento, viernes por la tarde, se dedicó a montar la rejilla. Básicamente el proceso es escribir el título de tu propuesta (sesión, debate, charla magistral o lo que sea) y tu nombre en una tarjeta, comentar en un minuto de que va el tema y luego poner tu tarjeta en un panel con una chincheta. Luego todos los asistentes cogen tres pegatinas rojas que representan votos y las reparten por aquellas sesiones de su interés. Se recogen las sesiones más votadas y de manera colaborativa se distribuyen por la rejilla de sesiones. Entre mi compañero Jose Luis y yo propusimos cinco sesiones (tampoco hay que abusar) y salieron las cinco. Una pena que una de J se solapo con una mía y no pude asistir. El que salgan todas tus propuestas tiene una pega, no puedes ir a las sesiones de los demás… es el único  pero que puedo poner. A continuación podéis ver la rejilla. Repasando la rejilla he visto que hay una sesión mía a la que no asistí, ¿Ya tengo Scrum y ahora qué?, se fusiono con otras y no me di cuenta. Pensé, erróneamente que se había quedado fuera, lamento el error y pido disculpas.

Las sesiones a la que acudí fueron:

Artesanía del software, propuesta por Xavi Gost

Esta sesión molo de verdad, la más friki, de todas la que asistí, sin duda. Pura diversión. La radical propuesta de Xavi (al que le ‘da vergüenza ser tan frki’ jajajaj…) era dejar fuera de la sala todo lo que oliese a negocio y centrarnos en la parte más artesanal, lúdica y motivadora del desarrollo de software. A final la sesión se centro en la belleza del código. Xavi defendía que el código debe ser bello, que el código bello en un valor en si mismo y yo, en otra línea más utilitarista comentaba que para mí el código bello es el código bueno. No todo el mundo compartía mi opinión. Se habló de analizadores estáticos, que garantizan un mínimo de calidad pero nunca belleza y todos concluimos por unanimidad que el camello de Perl es tan bello como mal ejemplo de código mantenible. También se hablo de las escuelas de programación y su relación con las escuelas de Kung Fu. La idea de Xavi que comparto plenamente es que a programar se aprende principalmente con maestros, con gente que te ayuda, es paciente contigo, te corrige el código con cariño (o tobas, en esto no nos pusimos de acuerdo), y leyendo buenos libros. Podéis ver otro resumen de esta sesión (y de otras) y la lista completa de libros propuestos en el post que ha publicado Jose Manuel Prieto sobre el evento.

Control en proyectos ágiles, propuesta por mi

Mi idea para esta sesión era debatir y compartir con los asistentes las métricas y técnicas de control y seguimiento de proyectos que utilizan las metodologías ágiles. Utilice la siguiente ppt para romper el hielo:

Luego a base de preguntas a la audiencia y su participación llegamos a las siguientes conclusiones, que fuimos poniendo en una pizarra durante la sesión:

La base del seguimiento del avance de un proyecto de un proyecto es utilizar tareas pequeñas y binarias.
Es necesario visibilizar y medir el avance.
La métrica clave es la velocidad, pero hacia fuera del equipo interesa más el grado de cumplimiento de lo comprometido en el sprint.
Para cumplir hace falta compromiso, sin equipos dedicados no se logra compromiso. Definir tus equipos es vital.
Solo con estimaciones colegiadas y consensuadas, logramos compromiso por parte del equipo.
Es vital la priorización. Cuando las métricas cantan que estamos retrasados, no tenemos más opción que recortar funcionalidad.
Sin priorización ese recorte deja fuera características importantes y daña el resultado del proyecto irreversiblemente.

Tres años de proyecto con Scrum, propuesta por mi

En esta sesión, ya un clásico, pues la he presentado en una u otra forma en varios foros diferentes trate de comentar mis experiencias de tres años en un proyecto gestionado con Scrum y Team System como herramienta de gestión. Una vez más use una ppt para romper el hielo:

En esta sesión hable de las dificultades, las acciones tomadas ante ellas y los resultados que nos ha dado la adopción de Scrum y Team System en el desarrollo de Captor 3 en Sisteplant. Angel Agueda tiene un excelente resumen sobre esta sesión en su blog, así que os remito a el.

Oficina de proyectos ágil, propuesta por Xavier Albaladejo.

Lo mejor de la sesión sin duda, escuchar las experiencias de Xavier en Indra y ver como está cambiando el panorama de la gestión de proyectos en empresas de esa envergadura gracias a tipos como él. La otra gran cosa fue coincidir con mi viejo conocido Angel Medinilla. Angel es uno de los grandes del agilísmo en España, coincidí con él en el curso de CSM y desde entonces, de un modo u otro hemos estado en contacto. Poder debatir con él la visión de una oficina de proyectos ágil fue toda una experiencia. La principal conclusión de la sesión para mí fue que una oficina de proyectos (PMO) que de una visión global de todos los proyectos de la empresa y que de soporte en ingeniería ágil a todos los proyectos es posible y deseable. También fue muy interesante la aportación de gente que ya está en PMOs, como Juan Mari Huarte de Orona.

Documentación ágil e historias de usuario propuesta por Jose Luis Soria, también de Plain Concepts y por otra persona cuyo nombre no recuerdo (disculpas):

Excelente sesión en la que se trataron temas como:

¿Cúal es la utilidad de la documentación?
¿Cómo de útiles son las historias?
¿Cómo es una buena historia?
La importancia de las condiciones de aceptación
Documentar frente a refactorizar

Las principales conclusiones:

La documentación es un subproducto del software que funciona. Debemos evitarla.
Los wikis pueden ser de gran ayuda, pero también tienen problemas relacionados con la organización, la responsabilidad sobre el contenido etc…. Ninguno de estos problemas anulan su utilidad.
Debemos tender a generar toda la documentación.
La única documentación única es aquella que evoluciona a la vez que el código.

Seguro que Jose Luis nos contará más cosas sobre esta sesión y sobre la otra sesión que propuso sobre gestión de la configuración en proyectos ágiles.

Destacar la aportación de Joao Gama en esta sesión. No todos los días se encuentra uno con un Product Owner profesional y que se dedica a ello ‘full time’. Esto es algo que me encanto del formato open space, ¡cualquiera puede aportar en una sesión!.

Mi conclusión sobre el evento: excelente, no he estado nunca en un evento más participativo. Todo el mundo tuvo voz y todo el mundo tenía cosas interesantes que decir. Pensé que no tenía mucho que aprender sobre agilidad, que era un campo ya muy arado, ¡como me equivocaba!.

Y sabéis lo mejor ¡este era el primer evento de Agile Spain!… en próximas ocasiones no se que va a ser esto…

Por último decir que también aprovechamos para constituir oficialmente como asociación Agile Spain. Puedo presumir de ser uno de los que han firmado los estatutos aun a costa de casi perder el avión… menos mal que lo cogí, sino me cuesta el matrimonio y con razón.

Podéis encontrar una recapitulación de post, fotos y twits sobre el evento en esta página.

¡Un saludo!

Hace ya un tiempo escribía sobre cómo evitar los interbloqueos en Sql Server y como diagnosticar que les está causando cuando se producen. Hoy quiero contar un pequeño ‘truco’ que nos puede ayudar a, sin cambio alguno en el código de nuestra aplicación, reducir las probabilidades de sufrir un bloqueo. Este pequeño truco es un ‘antídoto’ que nos permite solucionar a menudo problemas de interbloqueos con un mínimo impacto sobre la aplicación. Además, esta técnica también puede mejorar el rendimiento de aquellas aplicaciones que estén sufriendo problemas de esperas en bloqueos entre lectores (selects) y escritores (updates e inserts).

El nivel de aislamiento por defecto de Sql Server es Read Commited. Esto quiere decir que este nivel es el más utilizado y que si no tienes ni idea de qué es el nivel de aislamiento este es el que estás utilizando. En este nivel de aislamiento, con el fin de evitar las lecturas sucias, cuando una consulta esta actualizando una fila, establece un bloqueo sobre la misma. Este bloqueo hace que quien quiere leer esta fila, se encuentre con que debe esperar. Este bloqueo en principio inocuo, puede se origen de interbloqueos en aplicaciones altamente concurrentes que no se hayan diseñado adecuadamente. Cuantos mas bloqueos, menos rendimiento, y más posibilidades de interbloqueos Tengo que decir, antes de que mi compañero Pablo Alvarez Doval, gurú de estos temas, me saque los colores, que he simplificado mucho la película, para no liar el asunto.

A partir de Sql Server 2005 se introdujo un nuevo modo de funcionamiento para el nivel de aislamiento Read Commited, que sigue evitando las lecturas sucias y que también evita ese posible bloque dañino del que hablábamos. Este modo es el modo Snapshot del nivel de aislamiento Read Commited, en el que, simplificando de nuevo el asunto, en lugar de establecer un bloqueo que para las lecturas, hace una copia en la sombra (snapshot) de las filas que se están modificando y si alguien intenta leer no lo bloquea sino que devuelve el valor copiado en la sombra. Resumiendo, no hay lecturas sucias como exige el nivel Read Commited y además no hay bloqueo.

Una ventaja adicional de este modo, es que es así y solo así como Oracle se comporta, luego si tu aplicación soporta Oracle y Sql Server, con este modo consigues el mismo comportamiento en ambas bases de datos en lo que a las transacciones Read Commited se refiere.

Evidentemente nada es gratis en la vida, y a cambio de no tener bloqueos, vamos a tener más trasiego en la base de datos temporal (TempDb) donde se almacenan los Snapshot y esta va a crecer en tamaño. En la mayoría de las ocasiones este es un mal menor.

Corolario: Si tienes una aplicación que está sufriendo bloqueos o interbloqueos, donde hay tablas que se escriben y leen concurrentemente, activar el modo Snapshot puede ayudarte a solucionar el problema.

Os dejo un script que establece el modo Snapshot para el nivel de aislamiento Read Commited para un base de datos:

-- Script que cambia en comportamiento del nivel de aislamiento
-- READ_COMMITED para que use snapshots (READ_COMMITTED_SNAPSHOT ON)

-- ¡OJO!: Ejecutar este script establece la base de datos a modo
-- de usuario único y por tanto termina las conexiones actuales a la
-- base de datos

-- Establecer la base de datos sobre la que haremos el cambio
USE <nombreDeBaseDeDatos>

-- Comprobar que la versión es SQL Server 2005 o superior
IF ((SELECT @@microsoftversion / 0x01000000) >= 9)
  BEGIN
    DECLARE  @sql VARCHAR(8000)
    
    SELECT @sql = 
         'ALTER DATABASE ' + DB_NAME() + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE ;
          ALTER DATABASE ' + DB_NAME() + ' SET READ_COMMITTED_SNAPSHOT ON;
          ALTER DATABASE ' + DB_NAME() + ' SET MULTI_USER; ' 
    EXEC(@sql)
  END
ELSE
  PRINT 'La versión de su SQL Server no soporta READ_COMMITTED_SNAPSHOT'
GO

¡Suerte en la batalla contra los bloqueos y los interbloqueos!

Este pasado fin de semana tuve el enorme placer de ser uno de los ponentes del CodeCamp, evento que mi empresa Plain Concepts patrocinaba siguiendo con su línea de continuo apoyo a la comunidad de desarrolladores en .Net. Tuve la oportunidad de exponer en dos sesiones una sobre la plataforma Windows Azure y otra, compartida con dos titanes del tema Luis Fraile y Bruno Capuano, sobre las novedades de VSTS 2010.

Sobre la sesión de Azure puedo decir que me sorprendió gratamente la asistencia que hubo, no esperaba tanto interés sobre el tema, la verdad, y sin embargo la sala se llenó. A continuación os dejo la PPT que use, no tiene mucho contenido, puesto que al ser el evento un CodeCamp traté de mostrar código, pero quizás veáis en ella información que os interese. Si tenéis algún feedback sobre la charla, no dudéis en dejarlo en los comentarios de este post.

En la charla sobre las novedades de VSTS 2010, que puedo decir, que disfruté como un enano compartiendo sesión con Bruno y Luis. La verdad es que da gusto ver como cuando hay comunidad de por medio, podemos dejar a parte la lógica competencia entre empresas y pasar un rato charlando sobre los temas que nos apasionan.

No puedo cerrar este post sin un agradecimiento explicito a la organización de evento. El esfuerzo realizado por los grupos de usuario implicados y por las personas que ha llevado adelante la organización a sido espectacular. Un diez señores, podéis sacar pecho de comunidad .Net. Además hay que destacar que en esta ocasión también Mono estuvo presente, más comunidad aun, incorporando otras plataformas. Jose Miguel Torres, Viçens Masanas, Toni Recio, Marc Rubiño (y seguro que algunos otros que me dejo), se han lucido con la organización. No es fácil montar un evento para trescientas personas y que no haya fricciones y todo vaya como la seda.

Decir, por último que la sesiones fueron grabadas, así que supongo que, tras maquetarlas un poco, en un tiempo estarán disponibles para que las podáis disfrutar aquellos que no pudisteis asistir al evento, ¡estad atentos!.

Entre Plain Concepts y Sarein hemos preparado un interesante curso sobre Scrum y Team System: Gestión ágil de proyectos con Metodología Scrum y Visual Studio Team System que tendré el placer de impartir los días 30 de Septiembre y 1, 2 de Octubre en Bilbao.

El contenido del curso, que tiene una duración de 24 horas es:

Scrum

Introducción a Scrum y las metodologías ágiles
Roles en Scrum
Definición de Sprint
Artefactos en Scrum
Gráficos de progreso y control del proyecto
Comunicación en Scrum
Escalando Scrum
¿Precio y fecha cerrados con Scrum?
Madurez y Scrum
Las reglas de Scrum

Visual Studio Team System

Team Foundation Server y el ciclo de desarrollo
Gestión del proyecto utilizando elementos de trabajo y Scrum
Gestión de fuentes
Herramientas para calidad

El precio del curso, es de 900 euros e incluye el almuerzo de los tres días.

¡Espero que os animéis!