Leer un nodo XML con Xpath

El mundo de .NET es simplemente inabarcable. Pero hace unos meses me encontré delante de la pantalla de un ordenador intentando superar una prueba que se trataba justamente de lo que se trata en este post.
Es decir leer el atributo de un nodo específico de un fichero xml. Tengo un xml tal cual:

<Configuracion>
  <PresentacionDatosEspecificos>
    <PresentacionWeb cifEmisor="CIF del emisor UNO" />
    <PresentacionWeb cifEmisor="CIF del emisor DOS" />
  </PresentacionDatosEspecificos>
</Configuracion>

Y quiero leer el atributo “cifEmisor” de los nodos PresentacionWeb.

Mi primer camino, y el que mi experiencia me indicó como el más rápido, es usar el metodo readXML de un dataset. Esta función devuelve una tabla con los nodos PresentacionWeb, con los cuales puedo hacer lo que quiera. Muy interesante si se va a visualizar en un GridView.

public DataTable lectorXMLDataSet(string file_path)
{
    DataSet ds = new DataSet();
    ds.ReadXml(file_path);
    return ds.Tables["PresentacionWeb"];
}

Pero, para no cargar todo todo el xml en memoria, puedo utilizar XPath. Que es mucho más rápido en la lectura, me permite acceso aleatorio a los nodos de un xml y realizar búsquedas por patrones complejos.

public void lectorXMLPath(string file_path)
{
    XPathDocument doc = new XPathDocument(file_path);
    XPathNavigator nav = doc.CreateNavigator();

    Response.Write("Listado de nodos <br/>");
    foreach (XPathNavigator node in nav.Select("//PresentacionWeb"))
        Response.Write (node.GetAttribute("cifEmisor",string.Empty) + "<br/>");
}

Algún día probare LinqToXML y os contaré qué tal va… :)

Cinco meses de retraso o como NO gestionar proyectos.

Es curioso como en la vida profesional se puede pasar en unos pocos meses de tener un EXITO con palabras mayúsculas a estar metido en un tarro de melaza, empujando y luchando contra todo y contra todos para sobreponerse a un FRACASO.

Y, como hice hace unos meses, quisiera dejar una pequeña lista de antiDecisiones (palabrejo que me acabo de inventar) que quisiera evitar volver a sufrir en ningún otro proyecto en el que esté implicado. Sea en el rol que sea.

1. Inestabilidad de la plataforma tecnológica.
Acostumbrado a la plataforma .NET en donde desde la versión 2003 hasta la 2010 se puede poner la mano en el fuego que un response.write va a funcionar correctamente, el trabajar en una plataforma que en cada revisión significa que el proyecto pende de un hilo y muy seguramente se paralice una semana, es desesperante.

2. Inestabilidad en la asignación de personal.
Es imposible cumplir los tiempos y la calidad si las personas asignadas a desarrollar  la aplicación va menguando en el tiempo, en sus horas asignadas o simplemente el equipo se queda sin desarrolladores  - aún teniendo recursos económicos asignados al proyecto.

3. Falta de experiencia y conocimientos del equipo.
Es un salto al vacio el asignar a un proyecto un equipo AL COMPLETO sin experiencia. Ni en la plataforma de desarrollo, ni en el lenguaje, ni en la tecnología, ni en la metodología. Es decir, desde el Jefe de Proyecto (quien escribe estas líneas) hasta el programador, todos sin experiencia en la plataforma tecnológica en la que se va a desarrollar.

4. Desarrollo “caja negra”.
Un auténtico proyecto “caja negra”. El cliente lo único que ha visto es un análisis funcional sobre los requisitos iniciales. Y cuatro meses después, mi experiencia personal es que puede acabar con un “muy bonito pero no es lo que quiero” como una catedral.

5. Aquí decide hasta el tato (menos el cliente).
Dos coordinadores, un gerente y un director. Todos opinando sobre la aplicación, todos decidiendo sobre la aplicación, todos forzando cambios en requisitos y desarrollos de ultimísima hora… ¿y la voz del cliente?.

6. Documentación antes que producto.
Un CMMI mal entendido, o aplicado. CMMI es una metodología de madurez. Implementas una serie de procedimientos que aumentan la visibilidad y trazabilidad de los procesos para encontrar donde se puede o debe mejorar. No es el objetivo es la herramienta.

Si pones al frente de un proyecto a un Jefe de Proyecto que nunca ha trabajado en CMMI, y no le echas una mano, pero le haces repetir cuatro y cinco veces cada documentación de cada una de las fases obtienes tres cosas:

1. Un retraso importante en el proyecto, hasta que la documentación se cumplimenta correctamente de acuerdo a todos (y son unos cuantos) cargos superiores que lo revisan y lo mandan a rehacer o retocar (a veces ni tan siquiera indicando de forma clara qué es lo que está mal). Añadiendo a ello, por supuesto, que las revisiones han sido realizadas totalmente fuera del plazo previsto (3 semanas para la primer revisión cuando no debe pasar más de un día en realizarse una vez realizada la documentación según la la implementación de CMMI).

2. El jefe de proyecto, desesperado, se salta la metodología y realiza la documentación por detrás. Por lo cual se pierde la trazabilidad y la visibilidad de los procesos y llegamos a la conclusión en que el primer proceso a madurar es la propia implementación de CMMI.

3. Caída de la motivación. Se convierte en una merienda de negros donde el Jefe de Proyecto, seguido a muerte por su equipo, tira pa’ lante del proyecto –picando código, adoptando todos los roles o lo que sea necesario - con la mirada puesta en la entrega y con ganas de “terminar la pesadilla”.  Lo cual casi siempre redunda negativamente en la calidad.

Moralejas:

• Que fácil es observar y criticar desde mi posición de Jefe de Proyecto. Y aún más fácil es echarle la culpa al Jefe de Proyecto por parte de los responsables superiores. Y que lejos está la labor de un Jefe de Proyecto desde la percepción de la dirección.
• Se aprende mucho de los éxitos pero MUCHO mas de los fracasos. Las correcciones son obvias y estoy mucho más preparado que antes para gestionar proyectos.

Recuperar tabla de un dataset en C#

Uno que viene de Visual Basic se encuentra con pequeñas diferencias de sintaxis en C# que hay que reconocer que “tocan la moral”. Por ejemplo el cómo extraer una tabla de un dataset.

En VB es sencillo:
Imports System.Data

Dim ds as New DataSet -- (debo cargar el dataSet con datos)
Dim tabla as new DataTable
tabla = ds.Table(“<nombre de la tabla”>)

Y en C# es igual de sencillo (bueno realmente más) peeeero:
using System.Data;

DataSet ds = new DataSet();
DataTable tabla = new DataTable();
tabla = ds.Tables["<nombre de la tabla>"];

Dita sea, el tiempo que perdí hasta que me di cuenta que hay que cambiar los paréntesis por corchetes :D

Bruno y su robotijo. MADNug

Este jueves pasado, por fin saqué tiempo para acercarme a las oficinas de Microsoft para disfrutar de una presentación realizada por Bruno sobre Microsoft Robotics. Y poder conocer de primera mano el famoso “Robotijo” que lleva paseando por, literalmente, medio mundo.

He de reconocer que mi “ego” se sintió un poquito más grande al reconocerme este distinguido caballero. Y es que ya son más de una y de dos reuniones a la que asisto como oyente.

La charla estuvo bien. Me aclaró el alcance de las posibilidades con este “juguetito” y me quito de la mente el dedicarme a programar estaciones espaciales automáticas con este software. El robotijo es la cosa más fea del mundo –pero no tanto como la aspiradora- pero con un increíble feeling a “number 5” y con el mismo buen rollito.

 
El robotijo siguiendo la línea negra…

Es de señalar que le acababa de llegar LA MAQUINA a Bruno (un bicharraco con un micro de 64bits y 8Gb de RAM) y la charla fue un verdadero compendio de la ley de Murphy y el efecto “presentación”. Vamos, todo lo que pudo ir mal lo fue. Y algo más. Pero Bruno, con su increíble capacidad de comunicación, sobrellevo la presentación y nos mantuvo atentos durante las dos horas que duró.

De lo mejor, los vídeos del “perseguidor de gatos negros”, el VPL (Visual Programming Language” y – con mucho – los movimientos del robotijo. Que aún haciendo nada, nos tenía embobados a los frikis de la electrónica que estábamos presentes y que lo mirábamos como si fuera magia.

 “la diferencia entre los niños y los adultos es el precio de los juguetes.”

P.D. Que gusto/interesante la charla antes de la presentación sobre metodologías y procesos de desarrollo.

Visual Studio con Subversion

Mi compañía utiliza el SubVersion como repositorio de datos. Y es la primera vez que lo utilizo de forma intensiva como ya he utilizado con anterioridad el SourceSafe o el Team Foundation Server.

Asique, ni corto ni perezoso, me bajo el plugin para el Visual Studio AnkhSVN y a ver qué me encuentro.

Primera instalación correcta, abro un VS2005 que tengo y… fallo. No veo el conector al subversión. Una vez más el dicho de “Plimelo jodel apalato DESPUES leel instlucciones” vuelve a cobrar protagonismo y me toca leerme el faq a ver qué estoy haciendo mal.

Vale, reinicio el VS2005 (:)) y tengo una nueva opción en el menú de “File”.  Subversion Project.

Y también en el menú “View” tengo varias nuevas opciones que veremos después de cargar el proyecto.

Bueno, todo parece que funciona correctamente. He subido al repositorio Subversion -con el Tortoise-, el código de la aplicación y me la estoy bajando igual que si fuera un SourceSafe. Accediendo a la carpeta local y diciéndole que haga un SVN Update.

Si el proyecto que estás cargando viene de estar en el sourceSafe, es buena idea eliminar todos los ficheros *scc. Y después en el Visual Studio quitarle a la solución el repositorio de datos y que tome el control el Subversion.

Por último, nos  vamos a nuestra solución, la abrimos y vemos los cambios en las vistas. Aparecen nuevas entradas en el menú de los ficheros en la vista  del explorador de la solución.

En la vista de cambios pendientes.

Una nueva vista de explorador del repositorio… mola!!

Y una cosa que echaba de menos mucho… un explorador de la solución en su carpeta en local!!

Por ahora me gusta mucho más que el SourceSafe y ya veremos que tal se comporta en comparación con el Team Foundation Server.

Quitar Proyectos Recientes del Visual Studio

 Edición 11/02/2010

El blog de Jorgelig y la página de referencia ha muerto. Por lo cual voy a utilizar el Blog de Leo para copiarme la solución. Muchas gracias,

• Se ejecuta en el linea de comando la instrucción regedit, para invocar al editor de registro.
• En la siguiente ruta de nuestro registro HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\ProjectMRUList
• Alli se encontrarán con archivos con nombres tales como File1, File 2, etc.. Deja solo los que quieres que te aparezcas y el resto los puedes borrar.
• A considerar, si tu borras, por ejemplo, File2 tienes que renombrar los Files3, File4 y asi consecutivamente.

---
Es un auténtico fastidio los proyectos que se mantienen eternamente en la ventana de inicio del Visual Studio y que no utilizas para nada.
Gracias a San Google he encontrado esta solución que es muy sencillita.
Muchas gracias a Jorgelig y su Blog… :)

No me olvidado...

No me he olvidado, se me agolpan tantas cosas, buenas algunas malas muchas, en la mente por el "pollo" que tengo montado en mi empresa que llevo meses sin escribir.

Mientras estoy aprendiendo C#.

En cuanto entregue los dos proyectos que tengo entre manos volveré a escribir, que están siendo un auténtico suplicio.