Estaré en el Tech Ed


Pues lo dicho, la semana que viene estaré en el Tech Ed Developers de Barcelona. Espero que todos los que leaís este post y vayaís a acudir os unáis al grupito de gente habitual en estos eventos (es mi cuarto Tech Ed, como pasa el tiempo) para charlar sobre desarrollo de software y demás…


A los que no vayaís a acudir, al igual que el año pasado, os intentaré mantener informados sobre aquellas novedades y charlas que me llamen la atención… estad atentos!!!.


Y a los compañeros del grupo de usuarios del Pais Vasco, Artalde, decirles que trataré de emular algunas de las charlas que más interesantes me parezcan en el grupo de usuarios. Seguro que Oskar, que también estará en el Tech Ed, también se anima…


Ya os iré contando…

Simplifica tus archivos de configuración trozeandolos

Un característica poco conocida sobre los archivos de configuración de .net (app.config, web.config…) es la posibilidad de trocearlos. Me he decidido a comentar este tema depués de tener que pegarme con un enorme e inmantenible archivo de configuración.


La idea es simple, podemos sacar secciones de nuestro archivo .config a otros archivos .config.


Supongamos que, por ejemplo, queremos sacar a un archivo de configuración separado las cadenas de conexión de nuestra aplicación. Suele tener sentido hacer esto pues es algo que a menudo los usuarios tienen que tocar. Crearemos un archivo llamado, por ejemplo, connectionStrings.config con el contenido de la sección connectionStrings, tal y como se muestra a continuación:



    1 <connectionStrings>


    2   <add name=«SiteSqlServer« connectionString=«tuConnectionString« />


    3 </connectionStrings>


Luego, en nuestro archivo principal de configuración (app.config o web.config), tendremos que incluir la sección que hemos extraido a otro archivo, estableciendo en el atributo configSource de la sección el nombre el archivo en el que se encuentran los valores de configuración:




    1 <configuration>


    2   …


    3   <connectionStrings configSource=«connectionStrings.config« />


    4   …


    5 </configuration>


Usando esta técnica podemos mantener en nuestro archivo principal de configuración todo lo relativo a infraestructura de la aplicación (Http Handlers, Configuration Section Handlers, configuración de la seguridad…) aquella información que cambia poco y los parámetros que son subceptibles de ser tocados por el usuario, sacarlos a archivos separados mucho más simples de editar y mantener.

Libro gratuito: Patterns of Agile Practice Adoption

agile-patterns-infoq-cover Las metodologías ágiles son muy simples. Pero su adopción no es tan simple, implantar una metodología ágil, aunque es mucho más sencillo que implantar RUP o CMMI, no es una tarea exenta de riesgos, nadie dijo que no exigiese un esfuerzo.

Una vez tomada la decisión de implantar una metodología ágil hay un motón de preguntas que responder: ¿Por donde empiezo?, ¿Qué prácticas debo adoptar?, ¿Cómo puedo adoptar la metodología incrementalmente?, etc…

Amr Elssamadisy en su libro Patterns of Agile Practice Adpotion, disponible para libre descarga en formato PDF, se ha molestado en recopilar una serie de patrones relacionados con la adopción de metodologías ágiles que nos ayudaran a responder estás preguntas y que nos guiaran en la adopción de prácticas ágiles como el desarrollo guiado por pruebas, el diseño simple, la arquitectura emergente etc…

Aun no he tenido tiempo más que para ojear el libro, pero la verdad es que tiene pinta de ser bastante recomendable.

Ha muerto la persona con la que más aprendí de informática…

Ha muerto repentinamente Juan Antonio Cebrian maestro de la radio y mi principal compañia cuando hace ya un montón de años comence a consumir noches programando en lugar de durmiendo, con su Turno de Noche de fondo, luego fue La Rosa de los Vientos el programa que ponia fondo al ruido de mi teclado. Escuchando a Juan Antonio aprendí ha programar en Visual Basic, escuchando sus pasajes de la historia me pico el gusanillo de C++, mientras me cagaba de miedo con sus pasajes del terror deboraba libros de informática… y oyendole hice mis primeros proyectos como freelance.

Total que con quien más aprendí de informática fue con él y de paso, de él aprendí sobre el pasado, sobre el misterio, sobre ecología, sobre civilizaciones perdidas y grandes aventuras y me enamore de la historia gracias a sus a sus Pasajes… ¡si enseñasen así la historia en las escuelas!.

Su voz me acompaño mientras, en algunas noches insomnes, montaba Geeks.ms…

A muerto un sabio, un genio, descanse en paz. Quede aquí mi pequeño homenaje.

Yo traceo, tu traceas, el tracea…

fingerprintTodos en mayor o menor medida nos vemos en la necesidad de poder, en un momento dado, conocer como se está comportando nuestra aplicación mediante el uso de trazas. Como me a tocado trabajar en la arquitectura de un buen puñado de aplicaciones, me propongo recopilar aquí unas cuantas reflexiones y buenas prácticas sobre este tema. No se trata de sentar cátedra, en informática rara vez hay una única aproximación buena, sino comentar las tácticas que suelo emplear a la hora de diseñar el traceo y aquellos aspectos clave a los que se debe mirar. Cada aplicación tiene diferentes necesidades en lo que a traceo se refiere. Además me encantaría que se generase cierto debate alrededor de este tema.


Disponemos de un motón de soluciones para llevar a cabo la implementación de esta característica en nuestras aplicaciones: System.Diagnostics, Log4net, el Application Block de Microsoft para este cometido…


El principal objetivo de las trazas es poder conocer a posteriori el comportamiento de nuestra aplicación y los diferentes estados por los que ha pasado. Las trazas son las únicas huellas que la ejecución de nuestra aplicación deja en ocasiones. Generalmente necesitaremos estudiar esta información cuando surjan problemas. No considero aquí las trazas como auditoria de permisos, de uso de la aplicación, de visitas, de uso de características, solo hablo de trazas de diagnostico, que son las que aparecen en una mayor número de aplicaciones.


El traceo debe ser suficientemente eficiente. Es importante que las trazas no afecten demasiado al comportamiento de nuestro aplicación en lo que al rendimiento se refiere. Indudablemente siempre se activemos las trazas de nuestra aplicación tendremos una penalización en el rendimiento de la aplicación, aunque esta penalización es inevitable, debe ser la menor posible. Otro aspecto vital es que cuando las trazas se encuentren desactivadas tenga un impacto cercano a cero sobre el rendimiento de la aplicación. Apoyar nuestro sistema de trazas en una librería ampliamente utilizada o en las posibilidades de traceo que casi todos los frameworks de desarrollo moderno proporcionan suele ser una garantía para lograr un rendimiento aceptable.


El traceo debe ser thread safe. Una tentación habitual es utilizar un hilo adicional para realizar las actividades de traceo de nuestra aplicación. En teoria esto permite que nuestra aplicación sufra un menor impacto en su rendimiento por las trazas. Esta es una aproximación errónea por varios motivos: Primero, porque los cambios de contexto que se producirán al utilizar múltiples hilos con numerosas trazas invalidarán cualquier ventaja de rendimiento y segundo, porque una situación en la que nos resultan vitales las trazas es cuando no encontramos con problemas relacionados con el comportamiento con múltiples hilos de la aplicación (interbloqueos, condiciones de carrera, etc…) y lógicamente en esta situación lo último que necesitamos es que las trazas introduzcan más ruido en el problema. Debemos poder confiar en que las trazas se escriben de manera síncrona a la ejecución del código que las rodea y con el que están relacionadas.


El traceo debe ser simple. Las librerías y clases de traceo nos permiten utilizar una gran cantidad de parámetros de configuración que permiten controlar en gran detalle en nivel de locuacidad de las trazas, su destino, para que módulos están o no activadas y un largo etc… Pero a menudo en nuestras aplicaciones debemos enmascarar y simplificar estos aspectos para hacer utilizable y sencillo nuestro sistema de trazas, tanto para los desarrolladores que lo utilizan como para los administradores de la aplicación. Aunque poder controlar el nivel de locuacidad de las trazas es una gran idea, en la gran mayoría de las ocasiones es suficiente utilizar solo tres niveles: error, advertencia e información. Una idea que suele parecer atractiva es dejar en manos de los operadores de la aplicación la configuración del tipo de salida y de que módulos deben proporcionar traceo, pero en la práctica suele ser mucho más útil, en mi experiencia, que simplemente sea necesario seleccionar una salida y activar el nivel de trazas adecuado. La idea es mantener simple el sistema de trazas pues cuando nuestras aplicaciones tienen problemas, al otro lado de la línea de soporte, no siempre hay un avezado administrador de sistemas que conoce a fondo nuestra aplicación. Es más simple simplemente pedir que se activen todas las trazas, se nos envié el resultado y realizar una análisis detallado y tranquilo de las mismas a base de filtrar lo que no es necesario. Mejor tener información suficiente y filtrarla a posteriori que no contar con la información suficiente para hacer una análisis detallado y tener que pedir de nuevo al administrador de la aplicación que cambie tal o cual parámetro.


Las trazas deben ser facilmente filtrables. Por lo anteriormente expuesto se hace evidente que las trazas deben ser fácilmente filtrables. Para ello todas las trazas que nuestra aplicación emita deben tener la misma estructura, presentar los mismos campos y en esencia ser homogéneas entre sí. Es muy complejo filtrar trazas que proporcionan información heterogénea.


El traceo debe tener como salida las fuentes habituales. A menudo cuando se implementa un sistema de traceo se olvidan ciertas salida que los usuarios de ciertas tecnologías esperan que estén presentes. Por ejemplo, todo administrador de sistemas espera que toda traza de nivel crítico se vea reflejada en el visor de eventos, o los programadores y administradores de aplicaciones Asp.Net esperan poder ver las trazas usando trace.axd, y todos los desarrolladores del mundo esperan poder ver las trazas usando DebugView o la ventana de salida de Visual Studio. Por lo tanto, cuando diseñamos el sistema de traceo de nuestra aplicación debemos asegurarnos de que concemos y utlizamos las salidas esperadas por los desarrolladores y administradores de nuestra aplicación.


DebugView


Las trazas deben mostrar información suficiente y no excesiva. Tan importante es que la información volcada por las trazas sean suficiente como que no sea excesiva. De todos modos ante la duda, se debe tracear toda la información que pueda resultar relevante, pues siempre podremos filtrar a posteriori: Identificador del hilo que crea la traza, hora de la traza, módulo, función, pila de llamadas, mensaje de la traza, usuario, etc… Es necesario para cada dominio de aplicación hacer un esfuerzo para seleccionar de manera explicita aquella información que por su relevancia es susceptible de ser traceado.


Para terminar, fuertemente relacionado con el tema del traceo se encuentra el manejo de excepciones, quiza os interese hechar un vistazo a unos post que escribí hace algún tiempo sobre antipatrones en el manejo de excepciones (I, II y III), donde recojo algunos errores habituales al logear excepciones.


Espero sugerencias y comentarios sobre como abordáis el traceo en vuestras aplicaciones.