Es curioso cómo puede variar el significado de las palabras… al oír este nombre en código, no puedo evitar visualizar imágenes de mi juventud, en concreto cuando los hombres del campo se acercaban al bar para robarle un respiro al día y apoyándose en la barra pedían a voces “un café” “una Copa” y un “Rosly’n” gesticulando transcendentalmente… jajaja, No sé si por casualidad o coincidencia todos los machotes que practicaron esa poco saludable costumbre, terminaron como los compiladores… con las cajas torácicas bien negras.

Dicho esto, parece ser que el término se invierte y ahora “Roslyn” representara el fin de tres décadas de cajas negras invocando los prompt’s de un misterioso mago escondido tras un ejecutable llamado compilador.

Este es otro de esos excitantes puntos de inflación en los lenguajes, a pesar de los “roadmap” de producto, evoluciones y tecnologías que Visual Studio va incorporando a la plataforma, sin duda este paso me recuerda a un nuevo hito que cambiara nuestro concepto a la par que lo hizo Linq en su momento. Por lo tanto “Bienvenido Roslyn”

¿Pero qué es Roslyn?

Es la posibilidad de utilizar los compiladores de C# y Visual Basic invocándolos en un modelo de servicios. Lo se una respuesta simple, difícil de asimilar.

Durante muchos años cientos de programadores han estado reclamando la posibilidad de disponer de “compiladores dinámicos” a los que poder invocar sin necesidad de llamar complejos ‘scripts’ dentro o fuera del propio entorno de programación.

Anders Hejlsberg, dio una charla sobre el futuro C# y Visual Basic en el pasado BUILD, os dejo el enlace por si acaso: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T

Os aconsejo descargaros la CTP de octubre 2011, es divertidísimo trastear con ella, además tendrás acceso a un montón de ‘Walkthrough’ entre los cuales encontraras el proyecto para generarte la extensión que te permitirá jugar a ser Anders, copiando código entre dos proyectos distintos; uno en VB y pegando en C#, poco menos que genial!!

Para ello solo tenéis que compilar el proyecto “ConvertingPasteExtensions” incluido en el CTP y luego instalar la extensión generada en Visual Studio… una vez completado, podrás disponer del genial “Paste as C#” o “Paste as Visual Basic”.

Aunque es este sentido, la implementación no está realizada al completo, deberéis tener paciencia pues no todas las expresiones “sobre todo Linq” funcionaran de un lado a otro… pero como digo, eso no quita las ganas de empezar a inventar descubriendo el montón de nuevas posibilidades que “Roslyn” nos podrá al descubierto.

Puedes descargarte la CTP desde: http://msdn.microsoft.com/es-es/roslyn

Que lo disfrutéis!,
PepLluis,

A propósito de mi último post, mi encuentro con el equipo de tres desarrolladores propicio una discusión en torno a cómo controlar el número de versión de cada proyecto, después de discutir llano y largo lo oportuno de realizar estas tareas de una manera centralizada desde los gestores de “Control de Código” y dando por imposible entenderlo de otra forma, se me planteo el reto de cómo poder incrementar el número de versión del ensamblado del proyecto desde el propio código del proyecto de forma automática y en función a si se estaba haciendo un ‘debug’ o un ‘release’.

Evidentemente el siguiente código, muestra y demuestra que es posible aunque debo rehuir de cualquier otra interpretación para tales prácticas, pues creo que es evidente que salvo excepciones no pueden ser tomadas más que como un ejercicio “curioso”.

using System;
using System.Text.RegularExpressions;
using System.Windows.Forms;
 
namespace VersionString
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
 
        private void Form1_Load(object sender, EventArgs e)
        {
            SetNewVersion();
            LblVersion.Text = Application.ProductVersion.ToString();
        }
 
        private void SetNewVersion()
        {
            try
            {
                string AssemblyFile = @"..\..\Properties\AssemblyInfo.cs";
                string str = System.IO.File.ReadAllText(AssemblyFile);
                Regex r = new Regex(@"\[assembly\: AssemblyVersion\(""(\d{1,})\.(\d{1,})\.(\d{1,})\.(\d{1,})""\)\]");
                Match m = r.Match(str);
 
                string rz = string.Format("[assembly: {4}(\"{0}.{1}.{2}.{3}\")]"
                    , m.Groups[1].Value
                    , m.Groups[2].Value
                    , m.Groups[3].Value
                    , Convert.ToString((Convert.ToInt16(m.Groups[4].Value))+1)
                    , "AssemblyVersion");
                System.IO.File.WriteAllText(AssemblyFile, r.Replace(str, rz));
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message);
            }
        }
    }
 
}

A falta de convencer al equipo para que se animen a utilizar algunos de los excelentes gestores de código para visual studio, aquí va mi dedicatoria… a demás con el código reclamo esa ronda de cervezas. J
PepLluis,

Tengo la suerte de poder compartir conocimientos con una gran diversidad de profesionales y entre ellos con un nutrido grupo de desarrolladores. En este sentido a menudo soy espectador de cómo somos víctimas de nuestra propia sinergia y obviamente a menudo nos vemos sorprendidos por utilizar o adoptar técnicas incorrectas simplemente porque así lo hicimos o mal entendimos desde el principio. Me encanta compartir esto con vosotros, pues son historias que algunas veces ponen al descubierto las mas retorcidas formas de interpretar la tecnología en nuestro “aburrido” día a día… para los que no quieren convertirlo en “divertido”.

Intentare abreviar e ir al grano pero creo que será difícil, os explicare que se trata de la forma en que gestionamos nuestros proyectos, si bien en equipos organizados el propio control de código nos ofrece herramientas suficientemente sofisticadas para evitar las malas prácticas, conduciéndonos y aplicándonos metodologías sobradamente contrastadas; existe aún un gran grueso de pequeños equipos de desarrolladores que “a su bola” realizan su trabajo en un frenético pulso por sacarse las tareas de encima sin reparar en las graves consecuencias a nivel de costes horarios cuando dejan de ocupar su puesto de trabajo.

Dicho esto, la semana pasada recibí una llamada de un buen colega, pidiéndome soporte para averiguar si podíamos entender unos inexplicables problemas con alguno de los proyectos que un antiguo empleado había liderado y al parecer era un problema de gran magnitud.. Por supuesto mi interés en entender tal misterio fue tan poderoso que no tarde ni una hora en acudir.

Recordad: Los grandes problemas se resuelven con pequeñas soluciones 🙂

Se trataba de un equipo de tres desarrolladores, creando sus proyectos en un recurso compartido “mal hecho!”, cada uno gestionando su parcela “el colmo!” y para rematarlo algunas librerías y proyectos eran base para compartir “peor imposible!” , puede parecer irreal pero os aseguro que es real y esta situación se produce en mas ocasiones de las que podemos imaginarnos.

El problema radicaba en que ciertos proyectos parecían no compilarse adecuadamente o que las referencias a ciertas partes en común no terminaban de contener la totalidad de las funciones diseñadas. Ummm… ciertamente extraño.

Al dar un vistazo por alguno de los proyectos base, pude observar que se compilaban como parte de la solución, sin embargo en otros proyectos más simples en vez de crear una solución conteniendo los distintos proyectos, se hacía referencia a clases que estaban ubicadas en “ese recurso compartido”, cuál fue mi sorpresa al observar que el antiguo empleado, cuando necesitaba alguna clase base para su proyecto… simplemente la añadía al proyecto! Sin atinar que cuando simplemente utilizas la opción de “Agregar Elemento Existente” en el explorador de Visual Studio lo que estás haciendo es una copia del “archivo en cuestión” a la ubicación de tu proyecto, por lo tanto cuantas modificaciones sobre el mismo serán para ese proyecto y no del origen del mismo.

Después de investigar algunos de los proyectos en los que “el antiguo empleado” había trabajado, nos quedo un rastro de algunas decenas de clases con el mismo nombre en diferentes proyectos y por supuesto diferentes contenidos, supongo que dicha persona nunca llego a entender lo que realmente estaba haciendo, pues en otro caso debo pensar que fue negligencia total.

Salvando las distancias quiero pensar, que en algún punto del camino cuando este profesional aprendía como utilizar las herramientas, no presto suficiente atención para entender que existen dos formas distintas para añadir un “elemento Existente”… está claro que el escenario de una clase compartida en un recurso compartido la opción correcta no es “Agregar”, si no “Agregar como Vinculo” solo debería haber prestado un poquito de atención en el combo que ofrece las opciones de agregar, supongo que ello hubiera ahorrado un montón de angustias.

Finalmente y a titulo de reflexión, tal y como empecé diciendo me gustaría pensar que somos víctimas de nuestras propias sinergias y desgraciadamente no atinamos en ellas hasta que alguien atina a explicarlas. Bien para que no quede en entredicho, si por alguna de aquellas casualidades alguien más desconoce este matiz, estar encantando de haber sido útil.

Recordad: Los detalles más insignificantes son los que causan los problemas más graves! 🙂

IMPORTANTE: La version “Basic” de Team Fundation es gratis!… que excusa tienes ahora?

Saludos,
PepLluis,