Mejorar la información sobre excepciones con el SQL Server Exception Message Box

Todos los que utilizamos Sql Server 2005, hemos visto en alguna ocasión el cuadro de dialogo que aparece cuando ocurre algún error, aunque solo sea cuando nos equivocamos el introducir el nombre de un servidor:



Este cuadro de dialogo prensenta algunas carácteristicas avanzadas, especialmente útiles a la hora de lidiar con excepciones:


  • El diálogo se ajusta automáticamente al texto mostrado.
  • Permite a los usuarios copiar facilmente toda la información mostrada a formato texto, ideal, para su envio a un departamente de soporte.
  • Muestra todos las excepciones subyacentes en forma de arbol cuando el usuario pulsa el botón de información adicional.
  • Permite al usuario elegir si quiere que se muestre el cuadro de diálogo si de nuevo se produce la misma excepción.
  • Permite acceder a un sistema de ayuda en línea usando un vinculo de ayuda asociado con la excepción.


  • Ahora que todos teneís los dientes largos con las posibilidades de este mega cuadro de diálogo para el manejo de excepciones, llega la parte más interesante de la historia: este componente se puede descargar y utilizar gratuitamente en nuestras aplicaciones. Es muy sencillo de usar, aquí teneís un How to.

    ¿Se están actualizando las estadísticas de tus índices?

    Hoy he vivido la curiosa situación de que una consulta estaba tardando muchísimo tiempo en ejecutarse debido a que, por error u omisión, se habia desactivado la opción de actualizar automáticamente las estadísticas de un índice. Lo habitual es dejar esta opción activada, aunque a veces puede tener sentido actualizar las estadísticas ‘a mano’, ejecutando sp_updatestats o mediante un plan de mantenimiento cuando la base de datos no tenga carga.


    Os dejo un script que detecta que índices no tiene la actualización automatica y cuando fue la última vez que se actualizaron. Si hace mucho que un índice actualizó sus estadísticas, es interesante hacer un sp_updatestas sobre ese índice.


    — Proprociona todos los índices que están en
    — tablas de usuario si actualizan o no automáticamente
    — sus estadisticas, además de la fecha de ultima actualización


    SELECT
          object_name(indexes.object_id) AS table_name,
         
    indexes.name AS index_name,
          STATS_DATE(indexes.object_id, indexes.index_id) AS last_update_date

    FROM
          sys.indexes as indexes

    INNER JOIN
          sys.stats AS stats ON
                indexes.object_id = stats.object_id
                AND indexes.name = stats.name

    WHERE
        OBJECTPROPERTY(indexes.object_id, N‘IsUserTable’) = 1 AND
        stats.no_recompute = 1

    ORDER BY 
        STATS_DATE
    (indexes.object_id, indexes.index_id) ASC

    Que caña con WPF

    Todos los que me conocen saben que la interfaz de usuario no es uno de los aspectos que más llaman la atención de desarrollo del software, en concreto es el que menos me llama la atención con diferencia. Supongo que se debe a mi poca capacidad creativa en lo que a aspectos visuales se refiere. Muchos incluso estarán ampliamente sorprendidos de ver un post sobre WPF en mi blog y más aun para alabar esta tecnología.


    Pero tambien, supongo que a consecuencia de mi incapacidad en ese campo, me admiran las intefaces de usuario espectaculares, como las que se curra el amigo Cristian con ‘facilidad’ pasmosa a base de WPF. A ver si empezamos a ver pantallazos


    Bueno, al grano, hoy, pululando por los blog de MSDN he caido, no se como en el de Tim Sneath, Windows Vista Technical Evangelist. Me ha llamado poderosamente la atención de una recopilación de post sobre aplicaciones que usan WPF, realmente viendo esta recopilación, he comprendido que las posibilidades de WPF son realmente espectaculares.


    Os dejo algunos pantallazos, de los que se pueden ver en la recopilación, para que os hagaís idea de que merece la pena visitarlo. Muchas de la aplicaciones además se pueden descargar para juguetear con ellas.















    Varios temas interesantes sobre Team Foundation Server y Visual Studio Team System

    Por fin una interfaz Web para Team Foundation Server

    Microsoft se ha comprado TeamPlain, empresa que desarrolla una popular intefaz de acceso a TFS a través del navegador Web. No solo es una buena herramienta para acceder a TFS desde otras plataformas sino, que tambien facilita la vida a aquellos miembros del equipo de desarrollo que colaboen ocasionalmente con el proyecto. Esta interfaz permite manipular work itens y código fuente. Además todo el que posea una CAL de TFS podrá descargar gratuitamente esta utilísima herramienta.  Más detalles aquí. Os dejo un pantallazo para que os hagaís una idea.

    Patrones y prácticas sobre TFS y VSTS

    El equipo de Patterns & Practices a publicado reciente una serie de guias prescritivas para TFS/VSTS de imprescindible lectura antes de abordar una implantación de TFS.

    Imprecindible guia sobre estrategias de merge y branch con TFS

    Aprovechar a fondo las posibilidad del gestor de fuentes pasa por conocer las posibilidades que nos brinda el mantener ramas paralelas en el gestor de fuentes. Por fin desde Microsoft, en CodePlex y en forma de Wiki han publicado un montón de información sobre este tema.

    Publicado el Roadmap de Team System

    ¿Quíen no esta intrigado por el futuro de Team System? Nos esperan grandes novedades. Puedo decir que muchas de ellas las vi incluso funcionar de la mano del equipo de desarrollo en el Summit. Sin duda TFS y VSTS llevan un buen camino.

    Plantillas gratuitas para Windows Sharepoint Services 3.0

    Microsoft ha lanzado un montón de plantillas gratuitas para WSS 3.0. Son un excelente recurso para ver lo que se puede lograr hacer con las plantillas de sitio de WSS y además muchas de ellas pueden sernos de utilidad o servirnos como base para aplicaciones más elaboradas.

    Hay dos juegos de plantillas, uno que no requiere privilegios de administrador de servidor para su instalación, pues se trata de ‘site templates’ y otro que si requiere privilegios, pues se trata de ‘site definitions’ y su integración con WSS es mayor. Solo estas últimas están disponibles traducidas al castellano.

    Para que os hagaís idea, hay plantillas para solicitud de vacaciones, presupuestación y seguimiento de proyectos, gestión de peticiones de cambios, planeamiento de eventos, seguimiento de inventarios, gestión del conocimiento, reservas de equipos y salas, apertura de nuevas tiendas, gestión de la formación de empleados, help desk y un largo etc…

    ¿A más procesadores consulta más lenta?

    Que paradojas tiene la informática… tendemos a suponer que tener más procesadores tiende ha hacer que nuestros procesos se realicen más rápido, pero esto no es cierto. Un proceso expandido entre varios procesadores, siempre tardará más en realizarse que si se realiza en un único procesador. Esto no quiere decir que tener muchos procesadores no sea ventajoso, pues lo que permite es realizar muchas tareas a la vez, cada una será un poco más lenta, debido al tiempo que los cambios de contexto consumiran, pero sin embargo transcurrido un tiempo tendremos muchas más tareas completadas lo que hará que la velocidad percibida sea mucho mayor.

    Hay una situación en la que este problema se puede hacer patente de una manera cuando menos sorprendente: al migrar nuestro servidor de bases de datos a un servidor con muchos más procesadores. Es relativamente habitual que, una consulta, que en una máquina de dos procesadores tarda un tiempo razonable, al migrar nuesto Sql Server a una máquina con más procesadores tarda mucho más en completarse. ¡Lo peor es que esta situación es principio es un sinsentido!, tengo más máquina y mi aplicación va más lenta…

    Javier Loria, me explicaba en el Summit la situación de una manera muy gráfica: que es más facil, que una persona cante una canción o que lo hagan ocho. Evidentemente ocho se tendrán que poner de acuerdo en que parte cantar cada uno, y tendrán que poner atención en no pisarse. A Sql Server le pasa exactamente lo mismo. Cuando ocho procesadores intentan ejecutar la misma consulta puede ser que se molesten entre ellos, estas ‘molestias’ tienen su origen, habitualmente en que los diferentes hilos ‘pelean’ entre si por bloqueos, en esencia es un problema de bloqueos.

    La solución simple, pero un poco chapucera es usar el hint MAXDOP en la consulta para limitar el número de procesadores que como máximo se utilizarán para ejecutar un consulta. Teneís más información sobre cómo usar MAXDOP en esta entrada del Knowledge Base.

    La solución que debemos buscar es evitar que los diferentes hilos se molesten entre si y eso pasa por reducir la cantidad de bloqueos y la manera más simple de lograrlo es establecer los índices adecuados para la consulta. Como siempre vuelve a aparece aquí la importancia que los índices tienen para que nuestras bases de datos rindan perfectamente.

    Otra moraleja clara de este asunto es que existen errores en diseño de base de datos (y en general en el diseño de aplicaciones) que no se arreglan poniendo más máquina.

    Gestión de proyectos y paellas

    Este post comenzaba su vida como un comentario en respuesta a otro comentario de Antonio Quiros en un post en el que, al hilo de un artículo suyo, yo escribía sobre CMMI y la madurez. Me encanta que mi blog se convierta, gracias a la participación de Antonio y otros expertos y desarrolladores, en una tribuna libre en la que discuitir y comentar uno de los temas que mas me apasiona de la informática: la gestión de proyectos.


    Bueno vayamos al grano…


    Antonio en su comentario, dice que ‘no ve necesidad el debatir la validez de metodologías como CMMI’, este es el punto que menos comparto de su comentario. En mi opinión es imprescindible cuestionar un modelo de desarrollo de software y gestión de proyectos que no esta dando frutos. Bueno, si que está dando frutos al SEI y a los consutores SCAMPI y a quienes venden certificadiones. Uso el termino vender con toda consciencia, obtener un certificación CMMI solo es resultado de una inversión económica, de nada más. Toda empresa que lo intenta y ‘afloja la gallina’ consigue su certificación, luego no es un factor diferencial. Sobre mi conocimiento de como funcionan las certificaciones ISO, que Antonio cuestiona, decir que trabajé en calidad durante una parte de mi carrera (en industria no en desarrollo de software, pero las lecciones aprendidas se aplican) y que en todas las empresas por las que he pasado he sufrido el ‘sistema de calidad’. Todos tenemos certificaciones ISO (u otras) y todos sabemos como se consiguen.


    A parte de estos frutos, tras muchos años hablando sobre la familia CMM siempre que voy a una presentación sobre CMMI (poniendonos puristas deberiamos decir CMMI for Software Development), desde hace años, los ponentes, empiezan con la misma ppt, una mostrando estadísticas sobre cuantos proyectos de desarrollo de software fallan. ¿Qué ha hecho CMMI en todo este tiempo por mejorar el desarrollo de software? Nada. Si duda hay que cuestionar un modelo que sigue tropezando en las mismas piedras una y otra vez: no involucra al cliente, no entiende que las personas no los procesos son la clave en desarrollo de software, no asume que si algo es cierto es que el software cambia, y sigue aproximando el modelo de vida de ciclo de desarrollo desde una clara visión en cascada, asumiendo que se pueden conocer los requisitos a priori. Todos estos son errores ciertos, repetidos una y otra vez, que CMMI, RUP y otras metodologías no ágiles siguen cometiendo versión tras versión. Nada está más en contra del sentido común que perseverar en el error.


    Aunque quiza estos errores no sean achacables completamente a CMMI, que en esencia no es la pesima idea en la que se suele convertir, MSF for CMMI Process Improvement es un ejemplo, sino a cómo se realizan la implantaciones de CMMI. CMMI o RUP son modelos tan complejos, que cuando se implantan se acaban convirtiendo en un proceso en cascada porque, en la práctica, es la única manera de atajar la complejidad impuesta por la burocracia que estos modelos generan. Tienes que cubrir ciertas areas, con independencia de que sean de valor o no para tu proyecto, y recolectar evidencias de que las cubres y eso conlleva un esfuerzo que para nada repercute en el avance real del proyecto. No sirve de nada generar documentación y diagramas que la experiencia nos dice que van a acabar obsoletos, debemos centrarnos en construir software que se ejecuta sin errores, acepta el cambio sin un esfuerzo inviable y cubre las necesidades desde el cliente. Nada aporta al cliente que tu hagas una extensísima documentación de analisis y que cubras mil formularios para recolectar evidencias solo con el afán de recolectarlas para el auditor SCAMPI, quien es el único, que en alguna ocasión va a leer esta documentación, y el único que no sabe que cuando la lee ya está obsoleta. Ya escribí en dos ocasiones ( Por qué no me gusta UML y Documentando software y… más motivos por los que UML no es la solución) sobre la escasa utilidad que tiene esta aproximación a la documentación. Las metodologías ágiles tampoco son una bala de plata, pero si son una aproximación diferente a la que lleva fallando unos cuantos años y en mi opinión si algo necesita esta industria es una nueva visión.


    La base de estos errores está muy enraizada en la escuela de pensamiento clásica sobre gestión de proyectos. El resumen de este pensamiento es asumir que un proceso de desarrollo excelente es lo que garantiza un desarrollo de software excelente. Antonio en su comentario expone algunos de los argumentos clásicos de esta escuela de gestión de proyectos: ‘si pongo los ingredientes de una paella en la mesa y a diez personas delante, la probabilidad de que salga una buena paella será más alta si junto a los ingredientes pongo una receta que si no la pongo’ o ‘un procedimiento es por definición una serie de pasos que nos permite hacer un proceso repetible. Seguir un procedimiento demostrado válido para gestionar proyectos nos da más garantías que no seguirlo. ¿Preferirias que te operase un medico siguiendo un procedimiento aprobado mundialmente? o por el contrario ¿prefieres la lotería y cruzar los dedos para que la forma de trabajar del cirujano, su sentido común y experiencia le digan como tiene que operar’.


    No seré yo quien este en contra de seguir un proceso, lo que estoy en contra es de pensar en un proceso de desarrollo como en una receta. Las recetas están bien siempre que sepas exactamente cual es el plato que quieres hacer y siempre que tu cliente este de acuerdo en cual es la receta a utilizar. El problema es que en los procesos de desarrollo de software eso no ocurre casi nunca. Tenemos clientes que no saben que quieren comer, que no van a decidir si quieren la paella de marisco hasta que vean  la de carne, es más antes de ver la de marisco ni sabian que es lo que querian. Tengo algunos clientes que odian los pimientos y unos cuantos realmente enamorados de ellos, otros son alergicos y no puedo ponerlos en sus platos. En este entorno el jefe de concina (lease jefe de proyecto) no tiene más opción que tratar de contar con un equipo que no necesite una receta, que sea capaz de hacer la paella que el cliente quiere en base a unos fundamentos ferreos pero sin seguir unos pasos totalmente marcados (es mala práctica hechar azucar a la paella por ejemplo). Y además debemos dotarles de las herramientas que necesitan, básicamente, si no hay pollo, como jefes de proyecto (perdon de cocina), tenemos que conseguir uno (eliminar el impedimiento), porque sino nada podrá hacer nuestro equipo, por mucho que tengamos una metodología cinco estrellas certificada por la Nasa. Solo tener un excelente equipo nos salva, y tener cierto proceso, que apoye al equipo, que evangelize en las buenas prácticas, que no encorsete la creatividad y que no hunda al equipo bajo una montaña de burocracia. Mi abuela hace una excelente paella, por supuesto, sin receta. Es más dudo que dos veces seguidas ponga exactamente los mismos ingredientes y el mismo tiempo de cocción. No hay recetas, ni procedimientos ‘aprobados muldialmente’ para garantizar una gestión existosa de un proyecto, el motivo es simple, ¡cada proyecto de desarrollo es radicalmente diferente!. Esto es simplemente una ‘verdad verdadera’ que nadie que trabaje en esta industria puede negar… la tecnología es diferente, el cliente es diferente, el equipo de desarrollo es diferente, etc…


    Tampoco el desarrollo de software es comparable a la cirugia, todas las operaciones de, digamos por ejemplo, transplante de riñon son iguales. Solo algunas se complican, y en ese caso solo salvará al paciente la agilidad del cirujano y su equipo para actuar de manera creativa y basada en excelentes prácticas: no vale olvidarse de la esterilización o de poner anestesia, por mal que vaya la operación. En gestión de proyectos no puedes olvidarte de la calidad, o de realizar integración contínua o de tener un gestor de fuentes organizado o de mantener la legibilidad del código. El problema es, que en los proyectos de desarrollo de software, las cosas, nadie puede negarlo, siempre se complican, con independencia de la metodología que se utilize. Es que desarrolla software es una tarea muy compleja, mucho más compleja que ninguna otra. Un solo error, en una sola línea de código y los resultados son miles de usuario sin poder acceder a la web de comercio electrónico de tu principal cliente. Por lo tanto el punto es: ¿Si sea cual sea la metodología los proyectos se complican, por qué elegir una metodología pesada? Elegir una metodología pesada, de partida, solo garantiza que es probable que tu pesado proceso no te ayude, sino te entorpezca. Cada vez menos gente en la industria del software discute esta aproximación. 


    Lógicamente, no usar metodología alguna no es la solución. No hay peor metodología que ninguna. En Peopleware hay un capitulo excelente dedicado a las metologías con mayúsculas y a por qué no es buena idea confiar en ellas, básicamente pone el valor en las buenas prácticas. Ni siquiera estoy seguro que de una metodología ágil sea la solución total, pero si estoy seguro que no molesta tanto a los desarrolladores como una pesada y a menudo incluso les ayuda. Tendemos a olvidarmos de que la principal labor de una metodología es ayudar a los desarrolladores a hacer su trabajo, porque ellos hacen el trabajo duro. Propongo a los gerentes que han decidido implantar una metodología pesada tipo CMMI o RUP que salgan de sus despachos, y hagan el siguiente ejrecicio: Coger al primer desarrollador que encuentren, y depués de dejarle claro que su respuesta no influirá para nada en sus posibilidades de conseguir un aumento a fin de año hacer la siguiente pregunta: ¿Qué opinas de nuestra metodología?. No olvideís que quien principalmente sufre las carencias de una metodología son los desarrolladores. Luego pueden buscar un equipo de desarrollo ágil y hacer esta misma pregunta. Si no conocen ninguno, tienen las puertas abiertas en el proyecto en el que yo participo para hacer esta misma pregunta y comparar las respuestas.


    El problema es que cuando las metodologías no ayudan, molestan y esto daña la moral del desarrollador, que en lugar de poder concentrarse en su trabajo, se tiene que concentrar en que la metodología no le moleste. Y no debemos olvidar que numerosísimos estudios llegan a la conclusión de que nada afecta más a la productividad de un equipo de desarrollo que la moral y la motivación de los desarrolladores.


    Si comparto con Antonio su comentario sobre la carencia de profesionales realmente formados en gestión de proyectos. Es un problema grave. La universidad no prepara en temas relativos a la gestión de proyectos, al menos desde una prespectiva moderna y actualizada de la gestión de proyectos. Otro problema grave es que las certificaciones más reconocidas, estilo PMI y similares, están basadas en la gestión de proyectos clásica, guiada por un plan. Pero esto está cambiando: la certificación de mayor crecimiento y reconocimiento en los últimos años es la de Scrum Master. Esta certificación tiene el mismo escaso valor que el resto, pues cualquiera con el dinero suficiente la puede conseguir, pero su crecimiento, quizás resultado de su orientación completamente práctica, sin duda es señal de un cambio claro de tendencia en la gestión de proyectos en los últimos años.


    Invitio a todos los lectores de este post a discutir los temas que trato. Si algo tengo claro sobre la gestión de proyectos es que no hay más verdad absoluta que la máxima de que las personas son lo que marcan la diferencia de un proyecto a otro. El resto esta abierto a discusión y esta discusión siempre es enriquecedora.

    Summit 2007: La parte lúdica del Summit

    Llegué a Seattle el sábado por la noche y desde entonces no he parado. Hemos tenido dos días muy intensos con poca informática de por medio. La cuadrillita de Plain Concepts y Jose Alarcón y su chica, nos hemos alquilado dos coches y nos hemos dedicado a hacer un poco de turismo por los alrededores de Seattle. A pesar de ser la tercera vez que visito esta ciudad, y los Estados Unidos, hasta este viaje siempre me habia centrado en la parte urbana del pais a la hora de hacer turismo, pero he de decir que depués de estos dos días fuera de las zonas urbanas estoy sobrecogido por la belleza de este país, donde el paisaje natural es tan espectacular y sobre dimensionado como el urbano. Los rascacielos se sustituyen por enormes arboles y motañas gigantescas.

    La ruta turistica empezo el sabado por la mañana visitando la factoría de Boeing, increible el tamaño de todo allí dentro, impresiona ver cuatro aviones en construcción dentro de un edificio. La imagen que pongo no fue tomada por mi sino descargada de internet, puesto que no dejan sacar fotos dentro de la planta, pero lo que vimos es lo que muestra la imagen.

     

    Luego continuamos la jornada con la idea de visitar un inmenso parque natural cercano a Seattle, no sin antes parar en la versión americana de un batzoki, The Fat Smitie. Un lugar muy peculiar donde hacen la que, oficialmente, es la mejor hamburguesa del  estado de Washintong, y en mi opinión la mejor que jamás he comido, y en el que los manteles son vanderas americanas, y en la carta dejan claro que les encanta George Bush y que están contentisímos con la invasión de Irak. No me suele gustar compartir política con pitanza, pero a veces el hambre nubla la razón. El local esta regentado por una curiosísima mujer con aspecto indio, pero de origen japones.

    Luego continuabamos viaje hacia el parque natural de Olympia, un lugar donde la naturaleza está desmadrada y de una belleza impresionante. Una pena que no pudiesemos subir a la parte realmente impresionante del parque pues estaba el camino cortado por el riesgo de avalancha. Manda huevos, lo civilizados que somos los españoles fuera de nuestro país, lo único que impedia el paso eran unas luces rojas, ni barreras, ni cadenas, ni na… y aún así nos dimos la vuelta antes de que apareciesen los guarda bosques… vamos que en españa no nos había parado ni el Seprona, ni el riesgo de avalanchas. Los de la foto a pesar de lo feos que son, no son bigfoots… sino Jorge, Iván y Eduardo y al fondo Jose y su Eva horrorizados ante la vista de estos tres ‘monstruos’ en medio del bosque…

    El lunes nos levantamos y fuimos a desayunar al pueblo donde se rodaba Doctor en Alaska, como buenos frikis, todos somos fans de la serie. El pueblo está tal cual aparece en la serie con todos los lugares míticos, como el café Roslyn que podeís ver en la foto.

     

    O la KBHR…

     

    La verdad, es acojanante los que se desayuna un americano… pero conste que como buen Beliforano, deje el pabellón alto y me lo comí todo. A este paso creo que voy a bajar del avión rodando…

     

    El paisaje camino de este lugar acojanante… no se si se aprecia, en la foto, pero se trata de un lago helado, nunca había visto uno…

     

    Por la noche, asistimos la fiesta regional para MVPs, donde todos dimos buena cuenta del vino californiano este que es tan dulzón y cabezón, y que ensalza tanto la amistad jejejej… que en eso es en lo único que se parece al de la Rioja y al Ribera, dicho sea de paso… De esto no hay fotos dado que todos los presentes tenemos una reputación que salvaguardar, hasta aquí puedo leer.

    A partir de este post empezaré a daros la chapa con la parte informática y técnica del Summit, que aunque no lo creaís existe…

    Summit 2007: Ya estoy en Seattle!!!

    Pues eso, que tras el durísimo viaje (Bilbao – Londres – Seattle), por fin estoy comodamente alojado en un hotelazo en Seattle. Muerto pero comodo. Hay que reconocer que Microsoft se estira con los hoteles. Menos mal que el viaje ha sido ameno gracias a la compañia de Carlos Segura, Eladio Rincón, Salva Ramos, Pep, Juansa, Marc, etc… Ahora a esperar que vaya llegando el resto de la tropa de MVPs, especialmente el desembarco de los Plain MVPs. Os dejo una fotíto de lo que se ve desde mi habitación… y si, más que nada es para dar un poco de envidia… Lo que me espera: unos días con los frikis (frikis frikis) del equipo de desarrollo de C++, unas cuantas charlitas de los ejecutivos (Bill Gates incluido, vaya chapa), visita a la Boeing, conciertos varios… y muchas cervezas con los amiguetes MVPs… que semana más dura… 😉