Integrar MSBuild con Visual Studio

Aunque no utilicemos Team Foundation Server para hacer Builds, nos puede interesar utilizar MSBuild para automatizar nuestras construcciones. Aunque existen numerosas herramientas para editar los archivos de MSBuild, una primera opción que tenemos a mano es utilizar Visual Studio para editar estos ficheros, para ello basta con abriles como XML utilizando el menu contextual Abrir como… y además obtendremos intellisense.

Otra interesante posibilidad es la de ejecutar esos archivos de MSBuild desde dentro del entorno de Visual Studio. Para ello podemos usar el siguiente truco:

Añadimos un proyecto "Makefile project" de Visual C++ a la solución.

Dentro de este añadimos como nuestro archivo(s) de MSBuild.

Luego desde la pantalla de configuración del proyecto, podemos seleccionar los comandos que queremos lanzar para Build, ReBuild y Clean.

Una vez hecho esto prodremos, desde el menu contextual del proyecto Makefile, lanzar nuestras construcciones de MSBuild…

…y ver los resultados en la pantalla de resultados de salida de Visual Studio.

Desarrollo web en C++ en IIS 7

Ya he hablado anteriormente en este blog sobre el desarrollo web con C++ sobre IIS. Pues bien según he sabido, las cosas en IIS cambian un poco, porque el API C/C++ expuesta por IIS 7 es diferente a la de IIS 6, a consecuencia de lo cual, los ISAPI han caido en deshuso.

Para extender las capacidades de IIS 7 aparece un nuevo API nativo en C++ que reemplaza al antiguo API de filtros y extensiones ISAPI, en favor de los ahora llamados modulos. En cualquier caso los filtros y extensiones ISAPI existentes simplemente seguiran funcionando. El nuevo API en C++ es más intuitivo y orientado a objetos y utiliza patrones más sencillos para el manejo de peticiones a la vez de darnos más control.

Para usar este API es necesario instalar el último SDK, e incluir el archivo de cabezera httpserv.h. Evidentemente le tendremos que decir a Visual Studio que use las librerias y archivos de cabecera del SDK.

Para ver un ejemplo de el uso de este nuevo API podeís descargar el IIS7 Module Starter Kit for C++.

La pregunta es ¿qué pasará con ATL Server que esta construido sobre la infraestructura ISAPI?, ¿tendremos una nueva versión de ATL Server construida sobre este nuevo API en Visual Studio 'Orcas'?. No he encontrado información sobre este punto.

Para los programadores .net, existirá la opción de crear modulos en lenguajes .net
, siguiendo un proceso no muy diferente del actualmente existente para crear modulos y filtros Asp.net

Por qué me gusta Scrum

Scrum es una metodología que me gusta mucho, los motivos principales son los siguientes:

Es simple: la simplicidad es un valor interesante para un metodología porque facilita su transmisión. Es facil contarsela a otros, que la entiendan y por tanto que la puedan poner en práctica. No necesita una fase de 'implantación' larga y es facil encontrar sporsor para realizar esta 'implantación' porque no requiere de grandes recursos humanos ni materiales. Solo necesitas un Scrum Master que entienda su papel y esté dispuesto a realizarlo con dedicación, contundencia y mano izquierda.

Hace incapié en la visibilidad y en el ROI: es un factor vital para Scrum que los progresos realizados sean visibles. Existe un momento claro en que esa visibilidad se lleva a su máxima expresión, durante el Sprint Review, en el que el equipo presenta los avances realizados durante el último sprint. Además este avance se demuestra mediante software ejecutable, no mediante es uso de otros artefactos que solo presentan un avance teorico. Un Gantt con barras en negro no es avance, software que puedes usar si. Además el cliente puede decidir poner en producción lo ya desarrollado, con lo que es el cliente quien decide cuando comienza a recuperar su inversión. A más corto plazo, durante un Sprint, se consigue visibilidad del avance mediante el gráfico de Burndown del Sprint y a más largo plazo se consigue tambien visibilidad mediante el gráfico de Burndown del Producto. Este último permite estimar a priori, y basandonos en la capacidad y velocidad del equipo con el que contamos, cuando podremos tener una determinada funcionalidad implementada. La estimación 'tradicional' tiende a obviar las diferencias radicales que hay entre el desempeño de diferentes equipos.

Tiene roles y normas claras: Es una metodología facil de llevar a cabo, porque todas las actividades y flujos de trabajo están definidas explicitamente usando normas claras. Existe un rol, el de Scrum Master, que entre sus reponsabilidades tiene el hacer posible y vigilar que se cumplan estas normas.

Protege al equipo de desarrollo: Con el fin de evitar las distorsiones derivadas de los 'cambios de contexto', el equipo de desarrollo se encuentra protegido de los cambios, de las interrupciones, de las variaciones estrategicas, de los cambios de visión durante un sprint, esto permite que el equipo se centre en lo que realmente es importante para el avance del proyecto, construir software ejecutable con calidad suficiente para ser desplegado. Una de las quejas más frecuentes en los equipos de desarrollo es que no les dejan hacer su trabajo con la dedicación necesaria, Scrum ataja este problema de manera explicita.

Se basa en el compromiso personal: El equipo se compromete a implementar una funcionalidad en un cierto tiempo (los 20 días de un Sprint), nadie le impone fechas absurdas o imposibles. Cuando se valora al equipo se le mide por cumplir sus compromisos, no por cumplir los compromisos de los demás. Además las personas ponen mucho más empeño en cumplir sus compromisos que en cumplir los compromisos de los demás. A menudo los equipos se quejan de situaciones en las que el departamente comercial impone compromisos imposibles. Esto además no significa que la gente de producto y el cliente no reciba lo que necesita, todo lo contrario. El equipo no tiene potestad sobre el 'que' solo sobre el 'cuanto' (cuanto podemos hacer en un Sprint) y el 'como' (solo el equipo es responsable de la solución técnica.

Soluciona los problemas día a día: El Daily Scrum Metting sirve para, de una manera efectiva (no puede durar más de 15 minutos), detectar pronto los problemas, realizar un seguimiento diario y planificar el corto plazo. Se atajan pronto las situaciones anomalas, dado que esta es una de las labores del Scrum Master

Tiene una implementación para Team System.

Es ágil y por tanto, sigue los principios del manifiesto ágil:

Individuos e interacciones sobre procesos y herramientas
Software que funciona sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contratos
Responder ante el cambio sobre seguimiento de un plan

¿Por qué os gusta o no Scrum?
¿Cúal es vuestra metodología favorita? ¿Por qué?

Funciones callback, interop y copiado de ficheros conociendo el progreso en C++/CLI

Respecto a C++/CLI siempre oimos que es facilisimo el mezclar código manejado con código no manejado. Hasta hoy no había probado a fondo esta posibilidad. Pero a raiz de una pregunta en el grupo de news de C++ de Microsoft me he puesto manos a la obra. C++/CLI, aunque puede usar toda la 'artilleria' de Interop  con la que cuenta el Framework de .Net, cuenta con una tecnología llamada IJW (It Just Works) que permite hacer llamadas entre código manejado y no manejado de manera muchisimo más natural, totalmente integrada en el lenguaje, y lo que es tambien importante, con mucho mayor rendimiento. Podeís encontrar más información sobre esto en Escribir código más rápido con las modernas funciones de lenguaje de Visual C++ 2005

Volviendo a lo que nos ocupa. La pregunta en foro de C++ era ¿Como copiar un archivo en Visual C++/CLI y mostrar el progreso?. Pues bien la respuesta pasa por llamar a la función CopyFileEx del API de Windows, que nos informa mediante una función de callback del progreso de la copia del archivo.

Pero claro ¿cómo se come eso de punteros a función y demás si queremos hacerlo desde una clase manejada (por ejemplo un formulario) en C++/CLI?. Pues de manera muy natural, si veís el código de ejempo que pongo debajo, no hay ni un solo atributo de Interop. Ni siquiera hay que cambiar los tipos nativos de C++!!!. Realmente It Just Works. La función de callback la cambiamos por un delegado, que es el equivalente manejado a los punteros a función y usamos la funcion Marshal::GetFunctionPointerForDelegate para obtener un puntero que podamos pasar a la función no manejada CopyFileEx.

//Este código solo es una prueba de concepto

//No incluye en necesario código de control de errores

//Como mejora habría que añadir un evento a la clase para optener desde 

//fuera de la misma notificaciones sobre el progreso, no lo he hecho por 

//mantener el ejemplo más claro. 

//Requerido para poder usar CopyFileEx

#define _WIN32_WINNT 0x0400

#include <windows.h>

 

#include <vcclr.h> // Requerido para usar PtrToStringChars

 

using namespace System;

using namespace System::Runtime::InteropServices;

using namespace System::Diagnostics;

 

… 

public ref class CopyFileWithProgress

ref class FCopyFileWithProgress : public System::Windows::Forms::Form
 

 

    //Copiar un archivo recibiendo notificaciones de progreso

    public: System::Void CopyFileWithProgress(String^ from, String^ to)

    {

      //Convertir a cadenas no manejadas

      //Es necesario 'pinearlas' para que no las recolecte el recolector de basura

      //mientras las estamos usando

      pin_ptr<const TCHAR> _From = PtrToStringChars(from);

      pin_ptr<const TCHAR> _To = PtrToStringChars(to);

 

      //Crear un delegado a la función que recibe las notificaciones de progreso

      CopyProgressRoutineDelegate ^ progressCallback =

        gcnew CopyProgressRoutineDelegate(this, &CopyFileWithProgress::FCopyFileWithProgress::CopyProgressRoutine);

 

      //Copiado mostrando el progreso

      //Es necesario convertir el delegado a un puntero a función

      //usando Marshal::GetFunctionPointerForDelegate porque CopyFileEx

      //es una función no manejada que espera una función de callback

      //mediante un puntero a función no manejada.

      ::CopyFileEx(_From, _To,

        (LPPROGRESS_ROUTINE)Marshal::GetFunctionPointerForDelegate(progressCallback).ToPointer(),

        NULL, NULL, COPY_FILE_RESTARTABLE);

    };

 

    //Declaración de delegado a una función con la misma firma

    //que la función no manejada de callback que espera CopyFileEx

    private: delegate DWORD CopyProgressRoutineDelegate(

      LARGE_INTEGER TotalFileSize,

      LARGE_INTEGER TotalBytesTransferred,

      LARGE_INTEGER StreamSize,

      LARGE_INTEGER StreamBytesTransferred,

      DWORD dwStreamNumber,

      DWORD dwCallbackReason,

      HANDLE hSourceFile,

      HANDLE hDestinationFile,

      LPVOID lpData);

 

    //Función que recibe las notificaciones de progreso

    private: DWORD CopyProgressRoutine

    (

      LARGE_INTEGER TotalFileSize,

      LARGE_INTEGER TotalBytesTransferred,

      LARGE_INTEGER /*StreamSize*/,

      LARGE_INTEGER /*StreamBytesTransferred*/,

      DWORD /*dwStreamNumber*/,

      DWORD /*dwCallbackReason*/,

      HANDLE /*hSourceFile*/,

      HANDLE /*hDestinationFile*/,

      LPVOID /*lpData*/

    )

    {

      //Calculamos el porcentaje de progreso

      Int64 total = Marshal::ReadInt64((IntPtr)&TotalFileSize);

      Int64 trasferred = Marshal::ReadInt64((IntPtr)&TotalBytesTransferred);

      Byte percent = (Byte)(trasferred / total * 100);

      Debug::WriteLine(String::Format("Porcentaje de progreso de la copia: {0}", percent));

      //TODO: Desde aquí disparariamos un evento para informar del progreso

      //a cualquier otra clase interesada en conocerlo.

      return 0;

    }

… 

};

La técnica usada en este pequeño ejemplo sirve para llamar a cualquier función del API que nos notifique mediante una función de callback, como EnumWindows, FindWindows, etc… (aunque lo lógico es buscar la función correspondiente del .Net Framework antes de lanzarnos de cabeza al API).

Escribir en el registro desde Visual Basic 6.0

He encontrado, de casualidad, olvidada en un rincón de mi disco duro, mi primera colaboración con la comunidad. Se trata de una librería escrita en VB 6.0 y en forma de ActiveX que permite escribir en el registro de Windows, desde VB 6.0, en cualquier ubicación.

Ha estas alturas, VB 6.0 esta un poquito anticuado, pero hay millones de líneas de código y millones de aplicaciones escritas en este lenguaje, que aun usan miles de programadores, quizás esta libreria todabia pueda servir a alguien.

Además por razones 'historicas' creo que mi primera contribución a la comunidad debe de estar en este blog… antiguamente estaba ubicada en mi página web en Retecal, fallecida hace años, cuando me mude de Burgos a Bilbao… y que llego a tener un puñado nada despreciable de visitas.

Es un buen ejemplo de como hacer una librería de funciones ActiveX en Visual Basic 6.0, de como acceder al registro, y de como usar el API de Windows desde Visual Basic 6.0. Puedes descargar el código fuente.

RegUtils es una dll de ActiveX creada con VB 6.0.
Provee un objeto regutil con una serie de metodos y propiedades que permiten escribir, leer,  eliminar o crear valores o claves en el registro de windows.
Este objeto no es global. Debes declarar una variable. Esto permite mayor control sobre la destrucción del objeto.
Para ver como se utiliza puede examinar el proyecto de ejemplo TestRegUtils que se copia al instalar.
Si, en los métodos que lo aceptan, se pasa el argumento value como una cadena vacia se lee o escribe el valor predeterminado de la clave.

Implantar mejoras en la gestión de tus desarrollos

Siempre que imparto un curso sobre gestión de proyectos de software, con independencia de la empresa a la que se lo imparta, con independencia del perfil de los asistentes, siempre surge la misma cuestión, básicamente lo que dicen los alumnos es: "Si, Rodrigo tu nos has enseñado un montón de técnicas, y algunas hasta me parecen utiles e incluso me gustaría implantarlas o implantar la metodología X, pero soy el único que de mi empresa/equipo de desarrollo que ha venido al curso, el resto no las conocen. Además me voy a encontrar resistencia. ¿Cómo empiezo a 'implantar' lo aprendido?"

Lo primero es que se de la precondición de realmente querer realizar esa 'implantación', de pagar el esfuerzo inicial que hemos de hacer para poder ahorrar, aun mucho más esfuerzo, a corto plazo. Simplemente protestar no vale.

A partir de aquí, en mi opinión, las tácticas que pueden funcionar  para vencer la reticencia al cambio son pocas. Podemos buscar o comprar un sponsor, o actuar como caballo de troya.

Buscar un sponsor, consiste en encontrar alguien de mayor peso que nosotros en la organización, lograr que vea como algo interesante el realizar cambios en el proceso de desarrollo y lograr su respaldo a la hora de realizarlos. A menudo es dificil de lograr. Es dificil romper las innercias inherentes a toda empresa. Es dificil que alguien se preste a sponsorizar la implantación de las mejoras. Tambien es dificil que nosotros podamos abandonar nuestro trabajo diario para poder llevar a cabo las mejoras, aunque tengamos un sponsor y exista la consciencia de la necesidad de mejorar. Pero que sea dificil no quiere decir que debamos renunciar a intertarlo. Lograr un sponsor de peso (de cuanto más peso mejor) es algo vital para todo proyecto.

Comprar un sponsor, consiste en contratar a alguien y dotarle del poder suficiente para realizar los cambios necesarios. Y digo realizar, que no imponer. Debajo de toda mejora que necesita imposición se oculta a menudo burocracia, la verdaderas mejoras se imponen solas: simplemente demuestran su validad y se quedan. La ventaja es que curiosamente, y siguiendo el dicho de que 'nadie es profeta en su tierra', los equipos tienden a mostrar más respeto por alguien de fuera. Además el hecho de que sea alguien de fuera propicia que no sufra interrupciones en su trabajo de 'implantar' mejoras en el proceso de desarrollo. Sin duda tambien es algo dificil, más aun quizas que buscar un sponsor, porque generalmente, no se tiene acceso a la financiación necesaria.

Encontrar o comprar un sponsor es algo vital para implantar una metodología de cabo a rabo.

Existe un tercer camino, más ágil y sencillo, que no necesita del apoyo de nadie, consiste en actuar como un Caballo de Troya. Ir introducciendo pequeñas mejoras paulatinas que te ayuden en tu trabajo y que ayuden a los demás. Que el equipo no cuenta con un gestor de bugs: instalaló. Que no se lleva una gestión de riesgos y lo crees, interesante, realizala. Que crees que la calidad de tu proyecto es baja, escribe pruebas, realiza testeo. Tienes problemas de integración, automatiza la construcción de tu software y construye a diario. Estos cambios suponen un trabajo inicial, sin duda, pero los beneficios que tú y tu equipo de desarrollo obtendreís son muchos. Esta opción exige tambien asumir que no todas las técnicas sirven a todos los equipos o a todos los proyectos. Si pasada una fase inicial, en la que es imprescindible realizar cierta evangelización sobre las técnicas o herramients, el resto del equipo no las adopta de manera espontanea, es que no le sirven, luego no debemos empeñarnos. Aquello que sirve se queda de manera natural. De esta manera, podemos ir introducciendo poco a poco mejoras, descartando aquellas que no resulten evidentemente útiles, sin necesidad de realizar imposiciones y logrando el efecto buscado: mejorar cómo desarrollamos software. Esta via del caballo de Troya tambien tiene sus desventajas: es imposible de llevar a cabo de puertas afuera de tu equipo o para todo un departamento o empresa. Las ventajas son evidentes: el coste es bajo, no tienes que contar con nadie y puede que logres que tus compañeros de equipo mejoren como realizan su trabajo.

Algunas lecturas adicionales relacionadas:

Subir achivos a Sharepoint desde un programa en un equipo remoto

Me pedía el otro día un amigo una función para subir archivos a una librería de documentos de Sharepoint desde un equipo remoto. Yo, aunque no lo habia hecho nunca, pense que seria una tarea sencilla de realizar usando los servicios Web expuestos por Sharpoint. Tras un rato de investigación descubrí que no hay ningun servicio Web de Sharepoint que permita hacer esto de manera directa.

Tras un poco más de información encontre un solución sencilla, basada en hacer una llamada PUT al servidor de Sharepoint. Podeís ver a continuación un código de ejemplo de esta solución.

    /// <summary>

    /// Función que sube un archivo a un servidor Sharepoint remoto

    /// usando una petición PUT.

    /// </summary>

    /// <param name="localFile">Path del archivo local</param>

    /// <param name="remoteFile">Url del archivo remoto</param>

    /// <remarks>

    /// Esta función sirve desde la versión 1.0 del Framework en adelante

    /// </remarks>

    public void UploadDocument(string localFile, string remoteFile)

    {

      // Leer el archivo local

      FileStream fs = new FileStream(localFile, FileMode.Open, FileAccess.Read);

      byte[] buffer = new byte[fs.Length];

      fs.Read(buffer, 0, Convert.ToInt32(fs.Length));

      fs.Close();

 

      // Creamos el objeto request para lanzar la petición

      WebRequest wr = WebRequest.Create(remoteFile);

      wr.Credentials = System.Net.CredentialCache.DefaultCredentials;

      wr.Method = "PUT";

      wr.ContentLength = buffer.Length;

 

      // Escribimos el archivo en sitio remoto

      BinaryWriter bw = new BinaryWriter(wr.GetRequestStream());

      bw.Write(buffer, 0, buffer.Length);

      bw.Close();

 

      // Obtener el resultado de la petción

      HttpWebResponse wres = (HttpWebResponse)wr.GetResponse();

      wres.Close();

    }

El código anterior funciona perfectamente, pero tiene dos pegas, si subimos el archivo así no se guarda el historial de versiones y la petición es síncrona, lo que puede ser un problema para subir muchos archivos o archivos grandes. La primera es inevitable usando el método de hacer PUT, la segunda, si utilizamos el Framework 2.0 de .Net es simple de solucionar. Podemos utilizar las funciones asíncronas de la clase WebClient para subir el archivo. Tambien, podriamos hacerlo en .Net 1.x, pero tendríamos que usar hilos . Aquí va un pequeño ejemplo de código de como subir un archivo asíncronamente.

    /// <summary>

    /// Función que sube un archivo a un servidor Sharepoint remoto,

    /// de manera asíncrona, usando una petición PUT.

    /// </summary>

    /// <param name="localFile">Path del archivo local</param>

    /// <param name="remoteFile">Url del archivo remoto</param>

    /// <remarks>

    /// Esta función sirve desde la versión 2.0 del Framework en adelante,

    /// no funciona en 1.0, ni en 1.1

    /// </remarks>

    public void UploadDocumentAsync(string localFile, string remoteFile)

    {

      // Leemos el archivo

      FileStream fs = new FileStream(localFile, FileMode.Open, FileAccess.Read);

      byte[] buffer = new byte[fs.Length];

      fs.Read(buffer, 0, Convert.ToInt32(fs .Length));

      fs.Close();

 

      //Subimos el archivo de manera asíncrona

      WebClient wc = new WebClient();

      wc.Credentials = System.Net.CredentialCache.DefaultCredentials;

 

      //Manejador de evento para obtener información sobre el progreso

      wc.UploadProgressChanged += new UploadProgressChangedEventHandler(UploadProgressChanged);

      //Manejador de evento para saber cuando se completo la subida del archivo

      wc.UploadDataCompleted += new UploadDataCompletedEventHandler(UploadDataCompleted);

      //Iniciamos la subida del archivo asincronamente

      wc.UploadDataAsync(new Uri(remoteFile), "PUT", buffer);

      //Podriamos cancelar la carga del archivo

      //wc.CancelAsync();

    }

 

    /// <summary>

    /// Manejador de evento que recibe información sobre

    /// el progreso de la carga asíncrona del fichero.

    /// </summary>

    void UploadProgressChanged(object sender, UploadProgressChangedEventArgs e)

    {

      String msg = string.Format("Progreso: {0}%", e.ProgressPercentage);

      Trace.WriteLine(msg);

    }

 

    /// <summary>

    /// Manejador de evento que recibe información sobre

    /// el resultado de la operación de carga del fichero

    /// cuando esa se completa

    /// </summary>

    void UploadDataCompleted(object sender, UploadDataCompletedEventArgs e)

    {

      if (e.Cancelled == true)

        Trace.WriteLine("Se cancelo la operación");

      else if (e.Error != null)

      {

        String msg =

          string.Format(

          "Se produjo una excepción durante la operación: {0}",

          e.Error.ToString());

        Trace.WriteLine(msg);

      }

    }

Pero que pasa si no podemos vivir sin el historial. Pues existe un tercer cámino, bastante más complejo, que es crear un Web Service e integrarlo en el API de Sharepoint. La solución no es tan sencilla de realizar como las anteriores, pero esta perfectamente explicada en este artículo. Además, alguien ya implemento este web service y lo compartio con la comunidad, podeís descargarlo, desde GotDotNet

Seguro que alguno de los lectores de mi blog incluso sugiere alguna otra via…

Recibe notificaciones sobre tus builds de TFS

Os presento una utilísima herramienta que permite recibir notificaciones tipo Outlook sobre el resultado de nuestras builds. Simple y sencilla de utilizar, no se puede pedir más. Podeís descargar la herramienta desde aqui y la fuentes desde aquí. Teneís más información en el blog del autor.

Características de la aplicación:

  • No necesita Team Explorer para funcionar.
  • Se ubica en el 'System Tray'
  • Puede monitorizar simultaneamente varios servidores TF y varios tipos de build.
  • Muestra pop-ups para realizar notificaciones
  • Se inicia automaticamente tras reiniciar la máquina

¿Eres un desarrollador con principios?

Es curioso como existen algunos principios que son de aplicación en todas las facetas del desarrollo de software, desde la escritura de código, pasando por el diseño y el diseño arquitectónico, hasta la gestión de proyectos.

No son patrones, sino algo mucho más etereo y que no tiene una instanciación directa como estos, aunque, en cierto modo estos principios de los que hablo son los que, para mí, diferencian a un buen desarrollador. En esencia estos pincipios son la base de la 'cultura' del desarollo de software, son sus memes. En mi opinión los desarrolladores experimentados tenemos la obligación de preservar y transmitir estos gnes de información.

Son princpios universalmente aceptados, pero no universalmente conocidos. Pequeñas perlas de conocimiento y experiencia que debemos transmitir como medio para mejorar el nivel de conocimientos en nuestra profesión. Agunos son universales, se aplican en todas las facetas del desarrollo de software, como por ejemplo

KIIS (Keep It Simple Stupid), principio que mantiene la conveniencia de buscar las solución más simple posible a un problema.
DRY (Don´t Repeat Yourself), principio que sostiene lo dañino de las repeticiones.
SoC (Separation of Corcerns), principio que propugna la conveniencia de asociar responsabilidades claras a las partes que componen un sistema.
Orthogonality, principio que defiende la conveniencia de que los diferentes componentes de un sistema puedan variar sus comportamientos sin afectar al resto de componentes.

Otros son más especificos del dominio concreto, por ejemplo, relativos a la gestión de proyectos:

Involucra al cliente
Gestiona tus riesgos
Haz de la integración un habito
Libera pronto software
Haz de la calidad un preocupación continua
Evita la optimización prematura
etc…

Los desarrolladores de Microsoft Solution Framework se han dado cuenta de la importancia de los principios y tanto MSF for CMMI como MSF Agile, contienen una lista de los principios en los que están fundadas estas metodologías.

Compralo en AmazonLo que tienen en común todos estos diferentes tipos de principios es que sirven para transmitir conocimiento de una manera rápida y concisa. Son un arma que yo utilizo de la siguiente manera, que alguien se esta complicando la vida al hacer una arquitectura, le suelto: "Te estas saltando el principio KISS", si sabe de que va el principio perfecto, ya sabe lo que estas diciendo, sino, le remites a la Wikipedia y en 20 minutos sabe lo que tratas de decirle en un sentido más amplio que si se lo explicas detalladamente. Además si quiere profundizar hay miles de artículos y libros que justifican el contenido de este principio.

Estos principios, tambien sirven para facilitarnos la toma de deciones en nuestro trabajo como desarrolladores de manera rápida, directa y basandonos en fundamentos ferreos, pero sin tener que tomarnos excesivo tiempo en analizar la situación. Básicamente, si tienes dos opciones y una viola alguno de tus principios, tomar la decisión adecuada, es inmediato.

Pero claro, si eres un desarrollador nobel y en el proyecto en el que estas nadie se preocupa de transmitirte estos principios, la pregunta imediata es ¿Por donde puedo comenzar para construir mi lista de principios?. Pues bien, un buen inicio es 'The pragmatic programmer' de Andrew Hunt y David Thomas, un libro que hace una recopilación y una explicación de los principios adoptados por estos dos experimentadisimos programadores. Puedes ver una lista de estos principios. Existen alguan otras listas de principios universalmente conocidas y aceptadas, al menos en algunos ambitos, como por ejemplo 'El Manifiesto Ágil'. Otra lista de principios recomedable es Los 10 mandamientos del programador ágil. Y existen muchas más…

Software libre en la administración

Leo en Barrapunto: El software libre en la Administración ya no interesa al PSOE, y hacen un llamamiento a que, usando el Portal del Ciudadano demos nuestra opinión sobre la Ley de Administración Electrónica. Pues bien, para una vez que puedo dar mi opinión sobre una ley que me interesa, lo he hecho. Comparto la opinión expuesta en Barrapunto de que "es le momento de actuar". Invito a todos mis lectores a que den su opinión, sea cual sea. A continuación expongo la mía, tal y como la he remitido a través de la web, para que quede constancia.

"Existe un fuerte movimiento que trata de influir políticamente para que se prime el software libre en la administración. Desde mi punto de vistas esto es un claro error.

Detrás del software libre hay empresas que están haciendo negocios y que cobran por sus servicios. Exactamente igual que hacen las empresas de software no libre. No se debe primar a unas sobre otras solo por elegir un modelo de negocio u otro.

Además existe una comunidad en torno al software libre, pero esta no es más rica que la que existe entorno al software no libre. El argumento de disponer del código es falaz, puesto que la gran mayoria de empresas de software no libre tambien hacen disponible el código fuente a las administraciones, grandes clientes y miembros destacados de la comunidad.

El software que utilize la administración debe seleccionarse solo atendiendo al principio de servir mejor al ciudadano."