Modificando las guias de proceso de Team System

Por fin!!! Se acabo el dar palos de ciegos, y realizar incesantes procesos de prueba y error, o leer reconditos blogs cuando queremos adaptar las guias de proceso de Team System.


Ya tenemos documentación completa y de calidad sobre como hacer estas modificaciones: Customizing MSF Process Guidance


Cubre todos los aspectos relevantes: Actidades, roles, how-tos, informes, consultas etc…

Patrones para Ajax

Si duda las técnicas Ajax han llegado para quedarse. Y cada vez más y más desarrolladores y arquitectos estamos haciendo uso de estas técnicas. Pues bien como siempre que nos adentramos en un terreno nuevo, los patrones nos pueden ser de gran ayuda, pues evitarán que cometamos errores que otros ya han cometido.

Esta mañana he sabido por un compañero de trabajo que existe un interesante sitio, en formato Wiki, que se dedica a recopilar patrones relativos a Ajax. Sin duda un repositorio de patrones a tener en cuenta si queremos escribir aplicaciones Ajax. Además, lo que más me gusta, es bastante agnostico respecto a que tecnología se use para implementar los patrones.

El ¿futuro? de WinFS

A raíz de un post en el blog del equipo de desarrollo de WinFS, se están alzando muchas voces que dudan de su continuidad. Yo creo que no hay dudas, WinFS tal y como lo entendíamos hasta ahora ha dejado de existir. Lo que esta claro es que ya no se persigue que WinFS sea una tecnología con vida propia de la que surjan entregables (no habrá Beta 2), sino que será una tecnología que formará parte de otros productos, SQL Server y ADO.net, principalmente.


 


El trabajo realizado en WinFS, no ha sido baldío, ya que tendrá aplicación directa. Por ejemplo la próxima versión de Ado.net, tendrá capacidad para trabajar con entidades, sobre la base del trabajo realizado en WinFS. Entity Data Model (EDM), es heredero directo de Object Spaces y WinFS, y tiene visos de ser un digno heredero.


 

El hecho es que muchas de las características de WinFS tienen más sentido dentro de las tecnologías de almacenamiento y acceso a datos que como parte del sistema operativo. Creo que reconocer esto es un gran paso, desde el punto de vista de las arquitecturas empresariales, mi campo de trabajo e interés. Pero sin duda las capacidades de búsqueda y clasificación en el cliente, que se prometían espectaculares con WinFS, son las grandes sacrificadas.

Truco: Como ver el estado de una página HTML que usa AJAX

Cuando usamos técnicas AJAX es habitual el tocar el DOM del documento y modificar su estado de manera dinamica utilizando DHTML, el problema es que si queremos conocer el estado de la página, no nos sirve el usar el menu contextual para ver el código HTML por que este cambia dinámicamente.


La solución poner en la URL tu navegador: javascript:‘<xmp>’+document.documentElement.outerHTML+‘</xmp>’;


No se donde leí este truco, pero es realmente útil.

AJAX: Intercambio de datos con JSON

JSON es un protocolo de intercambio de datos ligero, fácil de leer para humanos y máquinas.


Exiten parses de JSON para la mayoria de lenguajes de programación y para todos los más populares.


Ahora viene la prengunta clave, ¿Por qué usar JSON si el estandar habitual es XML?. JSON tiene algunas ventajas sobre XML que debemos conocer.


La primera es que los datos en JSON ocupan mucho menos que XML, porque aunque nadie discute que XML es un gran invento, añade bastante sobrecarga a los datos que queremos serializar. En esta página comentan cuales son las ventajas de JSON frente a XML.


Este es un ejemplo de los datos de una persona una persona en XML:


<persona>
 <nombre>Rodrigo</nombre>
 <apellido>Corral</apellido>
 <genero>varón</genero>
 <edad>29</edad>
</persona>


Y estos son los mismos datos en JSON:


{
 “nombre” : “Rodrigo”,
 “apellido” : “Corral”,
 “genero” : “varón”,
 “edad” : 29
}


Ahora la pregunta es, ¿qué tiene que ver JSON con AJAX?
El problema principal en AJAX es mover datos entre el servidor y el cliente, este problema se suele resolver usando XML. Es por todos conocido que en las aplicaciones AJAX en el cliente la programción se realiza casi siempre con JavaScript. Exiten diversas posibilidades para leer XML desde JavaScript, pero todas ellas son farragosas en mayor o menor medida y son bastante lentas y pesadas. Aquí es donde JSON, a mi modo de ver más brilla. JASON en esencia es JavaScript perfectamente correcto, esto nos permite que simplemente haciendo


var persona = eval(
 ‘({
 “nombre” : “Rodrigo”,
 “apellido” : “Corral”,
 “genero” : “varón”,
 “edad” : 29
 })’ 
 );


tengamos un objeto JavaScript perfectamente valido!!! Simplemente usando eval!!! A partir de este momento podemos haceder a los datos de una manera orientada a objetos, por ejemplo:


alert(“El nombre de la persona es: ” + persona.nombre);


Esto tiene alguna implicaciones respecto a la seguridad, porque el eval de JavaScript acepta cualquier cádena valida que contenga código JavaScript. Para evitar esto problemas es mejor usar un parser de JSON para JavaScript, que solo acepta JSON valido. El parser permite hacer:


var persona = persona_como_Jason_string.parseJSON();


para reconstruir el objeto JavaScript desde su representación textual en JSON y


var persona_como_Jason_string = persona.toJSONString();


para obtener la representación JSON del objeto, por ejemplo para devolverlo usando técnicas AJAX al servidor.


¿Es o no es espectacular?


Pues esto no es todo evidentemente tenemos que generar el string que representa los datos que queremos mover desde el servidor al cliente y exporner una URL que permita obtener estos datos. No es que se una labor complicada, pero aún así tenemos ayuda. Existe una libreria llamada Jayrock , que implementa el protocolo JSON-RPC (similar a XML-RPC aunque más limitado) para C# y que nos permite de manera muy sencilla, usando un handler de ASP.NET y una serie de atributos devolver objetos JASON desde el servidor al cliente.

Documentando software y… más motivos por los que UML no es la solución

En mi opinión, el código es la única fuente de verdad sobre un proyecto de software a nivel de detalle. Entendidendo como código, la documentación directamente asociada al mismo o embebida en él (comentarios que permitan generar documentación por ejemplo, con NDoc o JDoc) o aquella que se genera de manera automática desde el mismo (por ejemplo diagramas de clases que solo son otra vista del código). Vaste recordar lo que todos hemos hecho para comprender un sistema del que disponíamos de su código fuente y que debíamos mantener o extender, leer el código, aunque exista documentación. Los desarrolladores preferimos leer código por que no es ambiguo. Si no en segundo caso, descripciones textuales, en ningún caso UML. La unica excepción se produce cuando contamos con información directamente generada desde el código en formato textual y descriptivo.

Otra documentación que no emana del código fuente directamente y que es de gran utilidad, si no imprescindible, es la relativa a arquitectura. Es necesario que un nuevo desarrollador o aquel que resucita el proyecto tras un tiempo pueda comprender que decisiones de alto nivel guiaron el desarrollo. Esta documentación si que es valiosa puesto que sirve para comprender por que se tomaron determinadas decisiones que no se cambian con facilidad a lo largo del proyecto y proporciona una primera aproximación que siempre es necesaria. La arquitectura de una aplicación no suele cambiar a menudo, lo que cambia es la implementación, el código. Documentar la arquitectura y que alguien la comprenda es algo que se hace perfectamente en lenguaje textual y utilizando algunos diagramas, no necesitas algo de tanta complejidad como UML. Esta documentación es simple de mantener porque es mucho más estática que la de diseño detallado. Además algo especialmente valioso de la documentación de arquitectura es que establece el lenguaje común, la nomenclatura propia y el estilo que va a guiar del desarrollo.

Pensemos en una pieza de software tan compleja y extensa como el Framework de .Net (lo mismo se aplica en cualquier caso al de J2EE). La única documentación de la que disponemos es la MSDN, que no incluye ni un solo diagrama UML. Sin embargo, pensemos en como actuamos como programadores cuando empezamos a usar un nuevo Framework Lo primero que hacemos es extender el Framework en un sentido genérico (programa algo sobre él) y la principal fuente de información es el nombre de las clases y las funciones, no utilizamos la documentación sino en IntelliSense. La principal documentación con la contamos es el estilo de nomenclatura, la coherencia a la hora de nombrar cosas y una arquitectura general coherente. La principal documentación del software debe emanar de una serie de patrones que se repiten a lo largo del proyecto, tanto a nivel arquitectónico como de diseño y estos patrones donde viven es en el código. Y si tenemos problemas esperamos encontrar articulos y ejemplos, no diagramas UML. Es facil mantener una base de conocimiento sobre nuestro proyecto, basada en articulos cortos y con ejemplos, tipo “knowledge base”, de manera que sean facilmente buscables.

Otra cuestión es la captura de requisitos, donde el enfoque de historias sencillas es suficiente. Y documentando el enfoque siempre debe ser: solo lo suficiente y nada más. Aquí el problema de UML es que se queda corto. Los diagramas de casos de uso solo no son suficiente, siempre necesitan una descripción textual asociada. Además en cualquier caso, harto problema es entender los requisitos como para además tener que entender el lenguaje en el que están escritos.

Sin duda el enfoque seguido en Team System es parecido al que describo, y creo que han dado en el clavo.


Por cierto, esta historia empieza aquí.

Por qué no me gusta UML

UML es una herramienta que casi todos los proyectos utilizan mal y que tiene tendencia al mal uso. Siempre que se plantea utilizar UML en un proyecto, se pone el enfasis en generar documentación, en realizar tal o cual diagrama, en seleccionar aquellos diagramas de UML que nos serán de utilidad.

El error en este caso es que se nos olvida que significa la L de UML, Lenguage. Y un lenguaje tiene como único cometido permitir la comunicación. Seleccionar una serie de diagramas es como arrancar las paginas a partir de la J del diccionario de la RAE y obligar a que la gente solo use las palabras que quedan. Seleccionar diagramas concretos es limitar la capacidad de comunicación usando UML.

La comunicación es algo que ocurre en un cotexto en un momento dado en el tiempo, y el motivo de la comunicación cambia continuamente, pensar que la documentación generada en un momento dado del tiempo será útil meses más tarde es pecar de ingenuo. A no ser que realmente pongamos más peso en la documentación que en el desarrollo de software, y la documentación tiene el problema de que no es ejecutable. La documentación ejecutable ya nos la vendieron las herramientas CASE y ¿alguien recuerda el nombre de una de esas herramientas? ¿Quien no ha estado un proyecto que despues de 10 meses solo tenia una cantidad infumable de documentación?

Que nadie piense que la postura que defiendo es que la documentación es innecesaria, solo defiendo que la documentación no asociada al código fuente o directamente generada desde el, pierde su validez tan rápido que no merece la pena generarla y mantenerla. Este tipo de documentación solo sirve para transmitir información en un momento del tiempo, comprender problemas y pensar sobre cuestiones y pierde su validez en cuanto a realizado su comentido, por tanto no merece la pena poner mucho enfasis en que sea correcta, siga estandares o plantillas, debemos poner el enfasis en que nos sirva para comunicar y sea flexible y facil de modificar, una pizarra es el elemento de comunicación ideal: lo escrito se modifica fácilmente, permite la colaboración de múltiples personas y puede mantenerse la información mientras es relevante y luego borrarse.

Tampoco defiendo que UML no tenga valor, pero solo como herramienta de comunicación, no como paradigma o método de documentación, que es como se tiende a utilizar. Aunque si cuestiono que sea mejor como herramienta de comunicación que cualquier otra herramienta, creo que es peor. Exige que todo el equipo conozca un lenguaje impuesto, que puede no ser natural al dominio de aplicación que nos ocupa, quiza DSL resuelva este problema, pero tiene mucho que demostrar aún.

Además UML no promueve de por si ninguna buena práctica de desarrolo de sofware. Solo es un lenguaje, uno que es facil de utilizar mal, que exige mucho esfuerzo de aprendizaje, demasiado para lo que proporciona y que es dificil de leer por alguien no iniciado. Ya todos contamos ya con un lenguaje y la capacidad de dibujar diagramas, de manera casi innata, creo que es mucho mejor ejercicio aprender a usar las herramientas con las que contamos en nuevos dominios. Si que es cierto que en ciertos contextos, facilita la comunicación, por ejemplo cuando se habla de patrones, pero solo es por un motivo cultural: los patrones tradicionalmente se han explicado usando UML.

La única documentación útil es la que emerge del código fuente y el código fuente de calidad es la principal documentación de cualquier proyecto.