Hace unos meses hablaba sobre la posibilidad de manipular la forma en la que el framework almacena por defecto la información para obtener enumeraciones de campos de bits, algo que es muy habitual en programación a bajo nivel. Siguiendo en la misma línea, hoy voy a comentar cómo conseguir uniones en .Net, al más puro estilo C.

Una unión es muy similar a una estructura de datos (struct en C# o Structure en VB.Net), salvo en un detalle: sus componentes se almacenan sobre las mismas posiciones de memoria. O visto desde el ángulo opuesto, una unión podríamos definirla como una porción de memoria donde se guardan varias variables, habitualmente de tipos diferentes. Veamos un ejemplo clásico que nos ayudará a entender el concepto, en un lenguaje cualquiera:

union Ejemplo
{
  char caracter; // suponiendo char de 8 bits
  byte octeto;   // un byte ocupa 8 bits
};

Si declaramos una variable x del tipo Ejemplo, estaremos reservando un espacio de 8 bits al que accederemos desde cualquiera de sus miembros, como vemos a continuación:

    x.caracter = 'A';
    x.octeto ++;
    escribir_char (x.caracter); // mostraría 'B'  
    escribir_byte (x.octeto);   // mostraría 66

 

Pero espera... ¿memoria?... ¿almacenamiento de variables?... ¿pero existe eso en .Net?... Pues sí, aunque lo más normal es que no nos tengamos que enfrentar nunca a ello pues el framework realiza estas tareas por nosotros, hay escenarios en los que es necesario controlar la forma en que la información es almacenada en memoria, como cuando se esté operando a bajo nivel, por ejemplo creando estructuras específicas para llamar al API de Windows, o para facilitar el acceso a posiciones concretas de la información.

Desde la versión 1.1 de la plataforma .Net, disponemos del atributo StructLayout, que nos permite indicar en estructuras y clases cómo queremos representar en memoria la información de sus miembros. Básicamente, podemos indicar que:

• la información se almacene como el framework considere oportuno (LayoutKind.Auto)
• que se almacene de forma secuencial, en el mismo orden en el que han sido declarados (LayoutKind.Sequential).
• que se almacene donde le indiquemos de forma explícita (LayoutKind.Explicit). En este caso, necesitaremos especificar en cada miembro la posición exacta de memoria donde será guardado, utilizando el atributo FieldOffset.

Es este último método el que nos interesa para nuestros propósitos. Si adornamos una estructura con StructLayout(LayoutKind.Explicit) e indicamos en cada uno de sus miembros su desplazamiento (en bytes) dentro del espacio de memoria asignado a la misma, podemos conseguir uniones haciendo que todos ellos comiencen en la misma dirección.

Pasemos a vamos a verlo con un ejemplo en C#. Se trata de una unión a la que podemos acceder tratándola como un carácter unicode, o bien como un entero de 16 bits con signo. Los dos miembros, llamados Caracter y Valor están definidos sobre la misma posición de memoria (desplazamiento cero) en el interior de la estructura:

using System.Runtime.InteropServices;
using System;
namespace PruebaUniones
{
     [StructLayout(LayoutKind.Explicit)]
     public struct UnionTest
     {
            [FieldOffset(0)] public char Caracter;
            [FieldOffset(0)] public short Valor;
     }    
    class Program
    {
        public static void Main()
        {
            UnionTest ut = new UnionTest();
            ut.Caracter = 'A';
            ut.Valor ++;
            Console.WriteLine(ut.Caracter); // Muestra "B"
            Console.ReadKey();
            return;
        }
    }
}

 
Ahora usaremos VB.NET para mostrar otro ejemplo un poco más complejo que el anterior, donde usamos una unión para descomponer una palabra de 16 bits en los dos bytes que la componen, permitiendo la manipulación de forma directa e independiente de cada una de las dos visiones del valor almacenado en memoria. Para el ejemplo utilizo una unión dentro de otra, aunque no era estrictamente necesario, para que veáis que esto es posible.

Imports System.Runtime.InteropServices

<StructLayout(LayoutKind.Explicit)> _
Public Structure Union16
    <FieldOffset(0)> Dim Word As Int16
    <FieldOffset(0)> Dim Bytes As Bytes
End Structure

<StructLayout(LayoutKind.Explicit)> _
Public Structure Bytes
    <FieldOffset(0)> Dim Bajo As Byte
    <FieldOffset(1)> Dim Alto As Byte
End Structure

Public Class Program
    Public Shared Sub main()
        Dim u As New Union16
        u.Word = 513         ' 513 = 256*1 (Byte alto) + 1 (byte bajo)
        u.Bytes.Alto += 1
        Console.WriteLine("Word: " & u.Word)            ' Muestra 769 (3*256+1)
        Console.WriteLine("Byte alto: " & u.Bytes.Alto) ' Muestra 3
        Console.WriteLine("Byte bajo: " & u.Bytes.Bajo) ' Muestra 1
        Console.ReadKey()
        Console.ReadKey()
    End Sub
End Class

 
He encontrado un uso muy interesante para esta técnica en Xtreme .Net Talk, donde se muestra un ejemplo de cómo acceder a los componentes de color de un pixel de forma muy eficiente a través de una unión entre el valor ARGB (32 bits) y cada uno de los bytes que lo componen (alfa, rojo, verde y azul).

En cualquier caso no se recomienda el uso de uniones salvo en casos muy concretos, y siempre conociendo bien las implicaciones que puede tener en la estabilidad y mantenibilidad del sistema.

Pero bueno, ¡está bien al menos saber que existen!

Publicado en: http://www.variablenotfound.com/.

Ayer se publicó la segunda preview del ASP.Net MVC Framework, la plataforma que sin duda será la revolución del año para los desarrolladores de aplicaciones basadas en web sobre tecnología .Net, y he pensado que ya era un buen momento para echarle un vistazo de cerca.


Una vez descargado el paquete (poca cosa, menos de un mega), procedí a instalarlo, apareciéndome la siguiente ventana de error:



Esto, además, se confirma en el documento de notas de la versión:

“The new releases provide Visual Studio templates that are not supported in Visual Web Developer 2008 Express Edition. For example, you cannot create an MVC application or Silverlight .xap files by using Visual Web Developer 2008 Express Edition.”

En otras palabras, que la segunda CTP, al igual que la primera, incluye plantillas que no son válidas para la versión Express de Visual Web Developer. Qué contrariedad.

Y es cierto que no está soportada, pero esto no implica que los que utilizamos las versiones light de los entornos de desarrollo estemos condenados a no probar esta nueva tecnología; de hecho es perfectamente posible, aunque no contaremos con todas las ayudas que sí vienen de serie para las versiones más "pro".

Una vez finalizada la instalación, encontré en Google varias páginas (por ejemplo aquí y aquí) donde se facilitaban plantillas, basadas en las originales, que nos permitirían probar la primera CTP sobre la versión express. Lamentablemente, los cambios realizados en la plataforma desde entonces hacen incompatibles estas plantillas con la CTP 2, aunque es posible hacerlas funcionar simplemente siguiendo los pasos detallados en esta página.

Para que no tengáis que perder el tiempo en ello, he creado una plantilla de proyecto Web (en C#) para Visual Web Developer Express 2008 que podéis descargar desde aquí.

Si queréis probar un poco esta tecnología, una vez instalada la segunda preview del ASP.Net MVC Framework, descargad la plantilla y guardarla, sin descomprimir, en la carpeta "Visual Studio 2008/Templates/ProjectTemplates". Lo habitual es que encontréis esta carpeta en "Mis documentos".

Iniciad Visual Web Developer 2008 Express, cread un nuevo sitio web en C# seleccionando la plantilla que habéis incluido, llamada "MVCWebSite", así:



Esto creará un proyecto con el web.config correctamente configurado y la estructura de carpetas ideal para una aplicación web de este tipo, lista para salir andando. Por cierto, si al compilar el proyecto os aparece algún problema de referencias a ensamblados de la Preview, sólo debéis añadir a mano (botón derecho sobre el proyecto, añadir referencias) las DLL's que encontraréis en la carpeta donde se haya instalado la CTP, que en mi caso es "C:/Archivos de programa/Microsoft ASP.NET MVC Preview 2/Assemblies"

Y ya no hay nada más que hacer. Si pulsáis la tecla F5, se compilará y en pocos segundos tendréis funcionando un sitio web MVC, con un controlador y algunas vistas, las cuales usan una MasterPage para componer el esqueleto de las páginas. Además, una de ellas, "Links", muestra cómo obtener un parámetro (la lista de enlaces) desde el controlador.



¡Hala, a disfrutarlo!

Publicado en: http://www.variablenotfound.com/.

Cuando estamos desarrollando es habitual que tengamos que comentar porciones de código para realizar pruebas. Esto resulta de lo más sencillo cuando programamos en un lenguaje de los habituales como Javascript, C#, Visual Basic o incluso (X)HTML, pues todos ellos disponen de marcadores que hacen que el compilador o intérprete ignore determinadas líneas de código... pero, ¿cómo logramos este efecto si se trata de un archivo .ASPX, donde pueden encontrarse varios de ellos a la vez?

Por ejemplo, dado el siguiente código en el interior de una página ASP.NET, ¿cuál sería la forma correcta de comentarlo?

<script>
    var count = <%= borrarRegistros() %>
    alert("Borrados: " + count + " registros");
</script>

 
Una primera opción podría ser utilizar la sintaxis Javascript de la siguiente forma:

<script>
    /*
    var count = <%= borrarRegistros() %>
    alert("Borrados: " + count + " registros");
    */
</script>

 
Sin embargo, aunque podría valer en muchas ocasiones, también puede introducir unos efectos laterales considerables. Nótese que aunque el código Javascript (cliente) esté comentado, la función borrarRegistros() sería invocada en el lado del servidor, y su retorno introducido dentro del comentario. De hecho, la página enviada a cliente mostraría un código fuente similar al siguiente (imaginando que el retorno de la función fuera el valor 99):

<script>
    /*
    var count = 99;
    alert("Borrados: " + count + " registros");
    */
</script>

 
Tampoco valdría para nada incluir todo el bloque de script dentro de un comentario HTML (<!-- y -->), por la misma razón que antes. Además, en cualquiera de estos dos casos, estaríamos enviando al cliente la información aunque sea éste el que la ignora a la hora de mostrarla o ejecutarla y, por supuesto, estaríamos ejecutando la función en servidor, lo cual podría causar otros efectos no deseados, como, en nuestro ejemplo, eliminar los registros de una base de datos.

Afortunadamente, ASP.NET dispone de un mecanismo, denominado Server Side Comments (comentarios en el lado del servidor), que permite marcar zonas y hacer que se ignore todo su contenido, sea del tipo que sea, a la hora de procesar la página:

<%-- 
  <script>
    var count = <%= borrarRegistros() %>
    alert("Borrados: " + count + " registros");
  </script>
--%>

 
En este caso ni sería ejecutada la función del servidor ni tampoco enviado a cliente el código HTML/Script incluido.

Publicado en: http://www.variablenotfound.com/.

Como ya venimos comentando hace tiempo, la nueva versión de ambos lenguajes viene repleta de novedades y mejoras pensadas para hacernos la vida más fácil y, por tanto, aumentar la productividad de los desarrolladoradores. Bueno, no sé si fue así o en realidad es que simplemente eran necesarias para Linq y por eso fueron incluidas ;-), pero el caso es que a partir de las versiones 3.0 y 9.0 de C# y VB.NET respectivamente, tenemos a nuestra disposición interesantísimas herramientas que deberíamos conocer para sacar el máximo provecho a nuestro tiempo.

En esta ocasión vamos a centrarnos en los inicializadores de objetos, una nueva característica destinada, entre otras cosas, a ahorrarnos tiempo a la hora de establecer los valores iniciales de los objetos que creemos desde código.

Y es que, hasta ahora, podíamos utilizar dos patrones básicos de inicialización de propiedades al instanciar una clase:

• que fuera la clase la que realizara esta tarea, ofreciendo al usuario de la misma constructores con distintas sobrecargas cuyos parámetros corresponden con las propiedades a inicializar.
  

  // Constructor de la clase Persona:
  public Persona(string nombre, string apellidos, int edad, ...)
  {
     this.Nombre = nombre;
     this.Apellidos = apellidos;
     this.Edad = edad;
     ...
  }
  // Uso:
  Persona p = new Persona("Juan", "López", 32, ...);

   
• o bien dejar esta responsabilidad al usuario, permitiéndole el acceso directo a propiedades o campos del objeto creado.

  
  // Uso:
  Persona p = new Persona();
  p.Nombre = "Juan";
  p.Apellidos = "López";
  p.Edad = 32;
  ...
  

   
  

Cualquiera de las dos formas anteriores, así como de opciones intermedias que combinen ambas ideas, tiene sus ventajas e inconvenientes, pero son igualmente tediosas. Si hablamos de clases con un gran número de propiedades, la cantidad de líneas de código necesarias para realizar una inicialización son realmente importantes.

Los inicializadores de objetos permiten, en C# y VB.Net, realizar esta tarea de forma más sencilla, indicando en la llamada al constructor el valor de las propiedades o campos que deseemos establecer:

// C#:
Persona p = new Persona { Nombre="Juan", Apellidos="López", Edad=32 };


' VB.NET:
Dim p = New Persona With {.Nombre="Luis", .Apellidos="López", .Edad=32 }

 
Los ejemplos anteriores son válidos para clases que admitan constructores sin parámetros, pero, ¿qué ocurre con los demás? Imaginando que el constructor de la clase Persona recibe obligatoriamente dos parámetros, su nombre y apellidos, podríamos instanciar así:

// C#:
Persona p = new Persona ("Luis", "López") { Edad = 32 };


' VB.NET:
Dim p = New Persona ("Luis", "López") With { .Edad = 32 }

 
Aunque es obvio, es importante tener en cuenta que las inicializaciones (la porción de código entre llaves "{" y "}") se ejecutan después del constructor:

// C#:
Persona p = new Persona ("Juan", "Pérez") { Nombre="Luis" };
Console.WriteLine(p.Nombre); // Escribe "Luis"


' VB.NET:
Dim p = New Persona ("Juan", "Pérez") With { .Nombre="Luis" }
Console.WriteLine(p.Nombre); ' Escribe "Luis"

 
Y un último apunte: ¿cómo inicializaríamos propiedades de objetos que a su vez sean objetos que también queremos inicializar? Suponiendo que en nuestra clase Persona hemos incluido una propiedad llamada Domicilio que de tipo Localizacion, podríamos inicializar el bloque completo así:

// C#:
// Se han cortado las líneas para facilitar la lectura
Persona p = new Persona() 
{ 
    Nombre = "Juan",
    Apellidos = "López",
    Edad = 55,
    Domicilio = new Localizacion 
    {
        Direccion = "Callejas, 34",
        Localidad = "Sevilla",
        Provincia = "Sevilla"
    }
};


' VB.NET:
' Se han cortado las líneas para facilitar la lectura
Dim p = New Persona() With { _
  .Nombre = "Juan", _
  .Apellidos = "López", _
  .Edad = 55, _
  .Domicilio = New Localizacion With { _
    .Direccion = "Callejas, 23", _
    .Localidad = "Sevilla", _
    .Provincia = "Sevilla" _
    } _
  }

 
En fin, que de nuevo tenemos ante nosotros una característica de estos lenguajes que resulta interesante por sí misma, aunque toda su potencia y utilidad podremos percibirla cuando profundicemos en otras novedades, como los tipos anónimos y Linq... aunque eso será otra historia.

Publicado en: http://www.variablenotfound.com/.

Sabemos que los patrones son plantillas reutilizables que podemos usar para solucionar problemas habituales en el proceso de desarrollo de software. Así, permiten utilizar soluciones fiables y bien conocidas a problemas concretos, aprovechando experiencias previas como base para la consecución de mejores resultados en los nuevos desarrollos.

Pues bien, justo en el lado opuesto se encuentran los antipatrones, que definen situaciones y comportamientos que, según experiencias anteriores, nos conducen al fracaso en proyectos de desarrollo de software, es decir, son soluciones o planteamientos que se han demostrado incorrectos.

Y es ahí donde radica su interés: la observación y conocimiento de los mismos puede evitarnos resultados desastrosos, o actuar como alertas tempranas ante decisiones o dinámicas incorrectas, permitiéndonos prevenir, evitar o recuperarnos de estos problemas.

Al igual que en los patrones, su descripción está relativamente formalizada y suele recoger los siguientes aspectos:

• nombre del antipatrón, así como su "alias"
• su tipología: organizacional, de análisis, desarrollo... (veremos esto más tarde)
• contexto y entorno en el que se aplica
• descripción del problema concreto
• síntomas, y consecuencias de la aplicación del antipatrón
• causas típicas y raíces del problema
• refactorización a aplicar, es decir, una descripción de cómo podríamos replantear el problema y conseguir una solución positiva.
• ejemplos y escenarios para su comprensión.
• soluciones relacionadas con la propuesta.

Por ejemplo, un resumen del clásico antipatrón que reconoceréis muy rápidamente, el llamado spaghetti code:

Nombre:	Spaghetti Code
Tipología:	Desarrollo
Problema:	Existencia de una pieza de código compleja y sin apenas estructura que dificulta enormemente su mantenimiento posterior
Síntomas y consecuencias:	Tiempo de mantenimiento excesivo debido a la necesidad de estudio del código Código no reutilizable Aparición del temido "es mejor reescribirlo" Métodos y funciones muy extensas Abuso de variables globales
Causas:	Inexperiencia de desarrolladores Reutilización de código de prototipos rápidos Ausencia de diseño previo a la implementación Desarrolladores trabajando en solitario Falta de revisiones de código
Solución positiva:	Aplicar refactorización mientras se programa Usar disciplinas de desarrollo específicas, métricas y buenas prácticas Realizar y desarrollar el diseño del sistema antes de implementar

Según según la Wikipedia, los antipatrones se clasifican en los siguientes grupos, atendiendo a las áreas a las que afectan:

• Antipatrones Organizacionales, que incluyen prácticas nocivas a este nivel, como pueden ser, entre otros:
  
  • Gestión de champiñones (Mushroom management), o mantener al equipo en la oscuridad, desinformado, y cubierto de porquería.
  • Parálisis en análisis (Analysis paralysis), o quedar inmovilizado debido a un análisis o precaución excesiva, en contraposición a la siguiente:
  • Extinción por intuición (Extint by instinct), llegar a la muerte por adelantarse demasiado y usar la intuición para la toma de decisiones.
• Antipatrones de Gestión de proyectos, describiendo problemas en la gestión de proyectos, como los célebres:
  • Marcha de la muerte (Death march), que describe el avance de determinados proyectos hacia el fracaso aunque todo el personal, excepto los gerentes, saben que al final se darán el castañazo.
  • Humo y espejos (Smoke and mirrors), o la demostración de funcionalidades o características no implementadas como si fueran reales, lo que siempre he llamado "enseñar cartón piedra".
• Antipatrones de Gestión de equipos, que recoge problemas relacionados con la relación con y de equipos de trabajo, como:
• Doble diabólico (traducción libre del término Doppelganger), personas que dependiendo del día pueden ser magníficos colaboradores o auténticos demonios.
• Gestor ausente (Absentee manager), describiendo situaciones en las que el director está invisible periodos prolongados
• Antipatrones de Análisis, categoría que engloba antipatrones relacionados con la fase analítica de los proyectos software, entre otros:
• Retroespecificación (Retro-specification), o lo que viene a ser la realización del análisis una vez implementada la solución.
• Especificación de servilleta (Napkin specification), también muy socorrida, que consiste en pasar al equipo de desarrollo las especificaciones del producto a crear descritas con muy poco detalle o informalmente.
• Antipatrones de Diseño, que incluye malas prácticas de diseño de software que dan lugar a aplicaciones y componentes estructuralmente incorrectos:
• Gran bola de lodo (Big ball of mud), realización de aplicaciones sin estructura reconocible.
• Factoría de gas (Gas factory), diseños innecesariamente complejos.
• Botón mágico (Magic Pushbutton), o implementación de funcionalidades directamente en los manejadores de evento (p.e., click) del interfaz.
• Antipatrones en Orientación a objetos, como una especialización del anterior, describe problemas frecuentes en los diseños creados bajo este paradigma, como:
• Llamar al super (Call super), obligar a las subclases a llamar a la clase de la que heredan.
• Singletonitis, abuso del patrón singleton.
• Orgía de objetos (Object orgy), o encapsulación incorrecta en clases que permite el acceso incontrolado a sus métodos y propiedades internas.
• Otra jodida capa más (YAFL, Yet another fucking layer), o la inclusión excesiva de capas en un sistema.
• Antipatrones de Programación, con un gran número de errores frecuentes a evitar, como:
  • Spaghetti code, comentando anteriormente.
  • Ravioli code, que consiste en la existencia de un gran número de objetos desconectados o débilmente acoplados entre sí.
  • Ocultación de errores (Error hiding), o capturar errores antes de que lleguen usuario, mostrando mensajes incomprensibles o simplemente no mostrar nada.
  • Números mágicos (Magic numbers), incluir números inexplicables en el código.
• Antipatrones Metodológicos, o formas de desarrollar que se han demostrado incorrectas a lo largo del tiempo, como pueden ser:
  • Programación copy & paste, también llamada herencia de editor, consiste en copiar, pegar y modificar, en contraposición a la estritura de software reutilizable.
  • Factor de improbabilidad (Improbability factor), asumir que un error conocido es improbable que ocurra.
  • Optimización prematura (Premature optimization), según algunos la raíz de todos los males, consiste en sacrificar el buen diseño y mantebilidad de un software en benecificio de la eficiencia.
  • Programación por permutación (Programming by permutation), o intentar dar con una solución modificando sucesivamente el código para ver si funciona.
• Antipatrones de Gestión de configuración, hace referencia a antipatrones relacionados con la gestión de los entornos de desarrollo y explotación del software, como las variantes del infierno de las dependencias (Dependency hell), o problemas de versionado de librerías y componentes:
  • DLL's Hell, el conocido y traumático mundo de las librerías dinámicas en Windows.
  • JAR's Hell, idem, pero relativo a las librerías Java.

Por no hacer el post eterno sólo he recogido unos cuantos, aunque existen cientos de ellos, y con una gran variedad temática: antipatrones para el desarrollo guiado por pruebas (TDD), antipatrones de manejo de excepciones, para el uso de arquitecturas orientadas al servicio (SOA), de rendimiento, de seguridad, centrados en tecnologías (p.e., J2EE antipatterns) o según el tipo de software (sistemas de gestión, tiempo real, videojuegos, etc.).

Y como conclusión personal, decir que me he visto reconocido en multitud de ellos, lo cual significa que muy descaminados no andan. Es más, si hiciera una lista con patrones y otra con los antipatrones que utilizo o he utilizado, la segunda tendría más elementos que la primera... ¿quizás es momento de reflexionar un poco?

Publicado en: http://www.variablenotfound.com/.

Hace unos meses comentaba las distintas opciones para saber si una cadena está vacía en C#, y la conclusión era la recomendación del uso del método estático string.IsNullOrEmpty, sobre todo si podemos asegurar que no aparecerá el famoso bug del mismo (que al final no es para tanto, todo sea dicho).

Los métodos de extensión nos brindan la posibilidad de hacer lo mismo pero de una forma más elegante e intuitiva, impensable hasta la llegada de C# 3.0: extendiendo la clase string con un método que compruebe su contenido.

La forma de conseguirlo es bien sencilla. Declaramos en una clase estática el método de extensión sobre el tipo string:

public static class MyExtensions
{
    public static bool IsNullOrEmpty(this string s)
    {
        return s == null || s.Length == 0;
    }
}

 
Y listo, ya tenemos el nuevo método listo para ser utilizado:

string name = getCurrentUserName();
if (!name.IsNullOrEmpty())
...

 
De todas formas, hay un par de reflexiones que considero interesante comentar.

En primer lugar, fijaos en el ejemplo anterior que aunque la variable name contenga un nulo, se ejecutará la llamada a IsNullOrEmpty() sin provocar error, algo imposible si se tratara de un método de instancia. Obviamente, se debe a que en realidad se está enmascarando una llamada a un método estático al que le llegará como parámetro un null.

Como consecuencia de lo anterior, y dado que no se puede distinguir a simple vista en una llamada a un método si éste es de instancia o de extensión, es posible que un desarrollador considerara esta invocación incorrecta. Esto forma parte de los inconvenientes de los métodos de extensión que ya cité en un post anterior.

En segundo lugar, visto lo visto cabría preguntarse, ¿por qué podemos extender una clase añadiéndole nuevos métodos pero no es posible incluir otro tipo de elementos, como eventos o propiedades? En el caso anterior podría quedar más fino que IsNullOrEmpty fuera una propiedad de string, ¿no?

Sin embargo, esto no es posible de momento. Según comentó ScottGu hace tiempo, se estaba considerando añadir la posibilidad de extender las clases también con nuevas propiedades. Supongo que el hecho de no haberla incluido en esta versión se deberá a que no era necesario para LINQ, la estrella de esta entrega... ¡y para dejar algo por hacer para C# 4.0, claro! ;-)

En cualquier caso, se trata principalmente de una cuestión de estética del código. Todo lo que conseguimos con las propiedades se puede realizar a base de métodos; de hecho, las propiedades no son sino interfaces más agradables a métodos getters y setters, al más puro estilo Java, subyacentes.

Por último, todo lo dicho es válido para VB.NET 9, salvo las obvias diferencias. El código equivalente al anterior sería:

Imports System.Runtime.CompilerServices
Module MyExtensions
    <Extension()> _
    Public Function IsNullOrEmtpy(ByVal s As String) As String
        Return (s = Nothing) OrElse (s.Length = 0)
    End Function
End Module
[...]

' Forma de invocar el método:
If s.IsNullOrEmtpy() Then
[...]

 


Publicado en: http://www.variablenotfound.com/.

Después de pasar un buen rato entretenido con la recopilación de frases célebres relacionadas con el mundo de la informática y especialmente el desarrollo de software, "101 Great computer programming quotes", publicado en DevTopics hace unas semanas, no he podido resistir la tentación de traducirlo, previo contacto con su autor, el amabilísimo Timm Martin.

Este es el primer post de la serie compuesta por:

• 101 citas célebres del mundo de la informática (este post)
• Otras 101 citas célebres del mundo de la informática
• Y todavía otras 101 citas célebres del mundo de la informática
• 101 nuevas citas célebres del mundo de la informática (¡y van 404!)

Encuentro en Apuntes de un Loco que hace un par de días Microsoft publicó las especificaciones de varios de sus formatos de archivo binario de Microsoft Office, así como otros de soporte, en el contexto del compromiso de apertura de especificaciones que mantiene desde algo más de un año.

• Word 97-2007 (.doc)
• Powerpoint 97-2007 (.ppt)
• Excel 97-2007 (.xls)
• Excel 2007 (.xlsb)
• Office Drawing 97-2007
• Compound file (OLE 2.0)
• Windows Metafile (.wmf)
• Ink Serialized Format (ISF)

Una iniciativa interesante derivada de esto ha sido la creación en SourceForge del proyecto "Office Binary Translador to Open XML", que pretende crear herramientas de conversión automática a este estándar ECMA. Supongo que en breve esta información se usará también para realizar conversiones fiables hacia y desde otros formatos, como los utilizados en otras suites ofimáticas como Open Office (Open Document).

Se trata sin duda de una buena noticia para facilitar la interoperabilidad entre aplicaciones.

Publicado en: http://www.variablenotfound.com/.

Existen muchos consejos para crear código mantenible, como los que ya cité cuando hablaba sobre comentar el código fuente, pero ninguno iguala a este:

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live"

(Codifica siempre como si la persona que fuera a mantener tu código fuera un asesino en serie maníaco que sabe donde vives)

Al parecer se trata de un leyenda urbana sobre Visual C++ 6.0, pero no deja de tener su razón...

Imagen: My Confined Space

Publicado en: http://www.variablenotfound.com/.

Hace sólo unos días alucinaba con la existencia y gran difusión del leet speak, y de nuevo vuelvo a asombrarme con la programación esotérica, otra prueba de que en este mundillo siempre hay algo sorprendente que descubrir.

Los lenguajes esotéricos, también llamados esolangs, son lenguajes de programación cuyo objetivo, al contrario que en los "tradicionales", no es ser útil, ni solucionar problemas concretos, ni ser especialmente práctico, ni siquiera incrementar la productividad del desarrollador. De hecho, lo normal es que atente contra todas estas características de forma contundente.

Aunque algunos se diseñan como pruebas de concepto de ideas para determinar su viabilidad en lenguajes reales, lo más frecuente es que sean creados por diversión y exclusivamente con objeto de entretener a sus posibles usuarios. Viendo esto, puede parecer que no existirán más de un par de lenguajes esotéricos, ¿no? Pues haciendo un recuento rápido en la lista de lenguajes de esolang.org he podido contar más de cuatrocientos, lo cual da una idea de la dimensión de la frikada de la que estamos hablando.

Pero no hay nada como unos ejemplos ilustrativos para que tomemos conciencia total de la cuestión.

Ejemplo 1: "Hello World" en lenguaje Argh!

Este lenguaje utiliza una matriz de 80x40 caracteres, en cuyas celdas pueden aparecer tanto código como datos. La siguiente matriz codifica el tradicional "Hello World":

j       world
lppppppPPPPPPsrfj
 hello,      *  j
              qPh

 
Según la especificación oficial, la ejecución comienza en la esquina superior izquierda, donde la orden "j" hace que la dirección de la ejecución sea hacia abajo. La siguiente orden procesada, "l", modifica el sentido de la ejecución hacia la derecha. Una "p" hace que se envíe a la consola el carácter que se encuentra en la celda inmediatamente inferior, de la misma forma que las "P" lo hacen con los caracteres situados en las celdas superiores.

Para no extenderme demasiado, resumiré un poco. Una vez enviado el saludo, se imprime un retorno de carro utilizando la pila para restar del carácter "*" (ASCII 42) el espacio (ASCII 32), se envía a la consola y se finaliza el programa (orden "q").

Ejemplo 2: "Hello World" en Brainfuck (jodecerebros)

Este lenguaje es un clásico en este mundillo debido a que ha servido como base para la creación de muchos otros lenguajes esotéricos. Se basa en la manipulación de un array de celdas utilizando tan solo 8 comandos, los siguientes caracteres: <, >, +, -, punto, coma, [, ].

Estas órdenes permiten desplazarse por las celdas hacia delante y hacia atrás ("<" y ">"), incrementar o disminuir el valor de la celda actual ("+" y "-"), escribir y leer caracteres hacia/desde consola ("." y ",") y hacer bucles simples ("[" y "]"). Como muestra, ahí va el "Hello world":

>+++++++++[<++++++++>-]<.>
+++++++[<++++>-]<+.+++++++..+++.
>>>++++++++[<++++>-]
<.>>>++++++++++[<+++++++++
>-]<---.<<<<.+++.
------.--------.>>+.

 
Gran muestra de código mantenible, sin duda.

Como curiosidad, añadir que existe un intérprete y compilador de Brainfucker para .NET en Google Code.

Ejemplo 3: "HAI WORLD" en LOLCODE

Lolcode es otro buen ejemplo de frikismo, aunque en este caso más orientado hacia la broma. Se trata de programar utilizando el peculiar lenguaje que usan unos populares gatitos, llamados lolcats, una mezcla entre la jerga de un bebé y el lenguaje habitual en los SMS.

HAI
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE

 
Es interesante saber que existen multitud de implementaciones de este lenguaje, una de ellas incluso en .NET, aún en versión alfa, con perfecta integración en Visual Studio.



En fin, que después nos quejamos de que los desarrolladores tenemos fama de rarillos... ;-)

Publicado en: http://www.variablenotfound.com/.

Los métodos de extensión son otra de las interesantes características que nos ofrecen las nuevas versiones de los lenguajes C# y VB que han sido publicados junto con la plataforma .NET v3.5 y Visual Studio 2008.

Los, en inglés, extension methods, permiten añadir métodos a clases existentes sin necesidad de utilizar el mecanismo de la herencia. Aunque dicho así parezca ser una aberración y atente directamente contra una de las principales bases de la programación orientada a objetos, y de hecho están considerados por algunos como auténticos inventos diabólicos, la cosa tampoco es tan grave siempre que se mantenga cierto control y conocimiento de causa. Y es que, como muchas otras características aparecidas recientemente en estos lenguajes, no son sino una base sobre la que sustentar frameworks como Linq, y que de paso pueden ayudarnos a ser algo más productivos.

En realidad, y siendo prácticos, los métodos de extensión no aportan grandes novedades, casi nada que no pudiéramos hacer con la versión 1.0 del framework, simplemente nos facilitan nuevas vías sintácticamente más simples de hacerlo. Por ejemplo, seguro que alguna vez habéis querido dotar una clase X con nuevas funcionalidades y no habéis podido heredar de ella por estar sellada (sealed en C# o NotInheritable en VB)... ¿Qué es lo que habéis hecho? Pues probablemente crear en otra clase un método estático con un parámetro de tipo X que realizaba las funciones deseadas en alguna clase de utilidad. ¿Lo vemos mejor con un ejemplo?

Supongamos que deseamos añadir a la clase string un método que nos retorne la cadena almacenada entre un tag (X)HTML strong. Como String no es heredable, la solución idónea sería crear una clase de utilidad donde codificar este métodos y otros similares que pudieran hacernos falta:

public static class HtmlStringUtils
{
   public static function string Negrita(string s)
   {
     return "<strong>" + s + "</strong>";
   }
   public static function string Cursiva(string s) {...}
   public static function string Superindice(string s) {...}
   [...]
}

 
Su uso tendría que pasar necesariamente por la referencia a la clase estática y el paso del parámetro a convertir, así:

  HtmlStringUtils.Negrita(currentUser.Name)

 
Esta técnica es correcta, aunque tiene un problema de visibilidad del código. Ningún desarrollador podría intuir la existencia de la clase HtmlStringUtils de forma natural; tampoco sería posible que un IDE sofisticado nos sugiriese el método Negrita() como una posibilidad a la hora de manipular una cadena, como hace Intellisense con los métodos de instancia habituales.

Los extension methods vienen a cubrir estos inconvenientes, creando una vía de alternativa para codificar el ejemplo anterior, facilitando después su uso de una forma más sencilla. Ojo al parámetro que recibe la función, que incluye la palabra reservada "this" por delante del mismo:

public static class HtmlStringUtils
{
   public static function string Negrita(this string s)
   {
      return "<strong>" + s + "</strong>";
   }
   [...]
}

 
De esta forma, incluyendo como primer parámetro el tipo precedido de la palabra "this", este método estático se convertirá automáticamente en un método de extensión de dicho tipo, y pueda ser utilizado como si fuera un método de instancia más del mismo:

  return currentUser.Name.Negrita();

 

Y, por supuesto, tendríamos toda la potencia de nuestro querido Intellisense (en VS2008) a nuestra disposición.

Lo único a tener en cuenta es el primer parámetro, que debe ser del tipo a extender. En éste se introducirá la instancia de dicho tipo de forma automática, y el resto de parámetros serán enviados al método en el mismo orden, es decir:

   // Método de extensión sobre un string
   public static string Colorea(this string s, Color color)
   {
      [...]
   }

   // Forma de invocarlo:
   string str = User.Name.Colorea(Color.Red);

 
Vemos que la utilización es mucho más natural y, aunque parezca que estamos rompiendo todas las bases del paradigma de la orientación a objetos, no es más que un atajo para incrementar productividad y facilitar la visión del código, además de servir como apoyo a tecnologías novedosas como Linq.

Sin embargo, no todo son ventajas. Es interesante añadir posibles problemas que pueden causar la utilización descontrolada de esta nueva característica.

En primer lugar, no olvidemos que a menos que Visual Studio (o cualquier entorno similar) nos eche una mano, al leer un código fuente será imposible saber si una llamada que estamos observando es un método de instancia o se trata de uno de extensión. Aunque no deja de ser una pequeña molestia, puede provocar una inquietante sensación de desconocimiento y dispersión del código fuente.

Otro motivo de dolor de cabeza puede ser el versionado de los métodos de extensión. Éstos pueden tener una vida completamente independiente de la clase a la que afectan, lo que puede provocar efectos no deseados ante la evolución de ésta.

Especialmente peligrosos pueden ser los relacionados con los nombres de métodos de extensión. Por ejemplo, la inclusión de un método en una clase podría hacer (de hecho, haría) que un método de extensión asociado a la misma y con un nombre similar no se ejecutara, pues el miembro de la instancia siempre tendría preferencia sobre éste. El problema es que el compilador no podría avisar de ningún problema, y es en ejecución donde podrían aparecer las incompatibilidades o diferencia de funcionalidades entre ambos métodos.

Veamos un ejemplo simple, siguiendo con el caso expuesto más atrás, ¿qué ocurriría si una vez en uso el método de extensión Negrita() Microsoft decidiera añadir al tipo string un método de instancia llamado Negrita() en una versión posterior del framework, que retornara un tag HTML <b>? Pues que el compilador no sería capaz de detectar nada raro, por lo que no nos daríamos cuenta del cambio, y nuestra aplicación dejaría de validar XHTML.

De la misma forma, también pueden causar problemas difíciles de detectar la especificación de namespaces incorrectos. Nada impide que un mismo método de extensión sea definido en dos espacios de nombres diferentes, lo cual hace que el namespace indicado en el using sea el que esté decidiendo el extension method a ejecutar, lo cual no resulta nada natural ni intuitivo en estos casos.

En conclusión: la recomendación es usar métodos de instancia, los habituales, siempre que se pueda, recurriendo a la herencia. Y para cuando no, contaremos con este valioso aliado.

Publicado en: http://www.variablenotfound.com/.

En esta ocasión no hablaré nada de lenguajes de programación, aunque sí de algo igualmente críptico para los no iniciados, el 1337, L337 o "leet speak". Y es que, aunque lo había visto utilizado en muchos sitios y a veces incluso soy capaz de leerlo, no conocía el nombre de este tipo de escritura ni era consciente de su gran difusión.

1337 es una forma de escribir textos usada en la actualidad por usuarios avanzados de determinadas comunidades de Internet, que consiste en la utilización de combinaciones de caracteres alfanuméricos de forma que no puedan ser entendidos fácilmente por parte de los neófitos o no iniciados. Este carácter elitista se ha reflejado en su nombre, puesto que el término "1337" es la escritura correspodiente de "LEET", que proviene del término "élite" (en inglés). Además, aportaba a sus conocedores interesantes ventajas a la hora de esquivar filtros de contenidos en servicios on-line como chats o foros durante la popularización del uso de Internet.

¿Y cómo se lee o escribe 1337?

En un primer nivel, esta técnica sustituye los caracteres de un mensaje por otros similares, o al menos ligeramente parecidos, como dígitos o símbolos. Por ejemplo, la letra "S" puede ser sustituida por el número "5", "I" por el número uno, o la "T" por un "7":

• E570y 35cr1813nd0 3n 1337: Estoy escribiendo en 1337.
• Un4 53gund4 pru384: Una segunda prueba.
• En m1 0p1n1ón, 35 un h4ck3r: En mi opinión, es un hacker.

El texto en nivel uno puede leerse muy fácilmente, como comentaban en Microsiervos, si se lee muy rápidamente. Probad y veréis que es cierto.

Un uso avanzado de 1337, sin embargo, es algo más difícil de leer y escribir. Aquí ya hay sustituciones complejas, como representar una "M" como "|V|", o "B" como "|3" y similares, se utilizan acrónimos (BTW, EMHO, LOL), y términos propios (H4xOr),

• 3570Y 35(R|8|3|\||)0 3|\| 1337: Estoy escribiendo en 1337
• |_||\|4 53G|_||\||)4 PR|_|3|34: Una segunda prueba
• E|\/||-|0, 35 |_||\| H4xOr: En mi opinión, es un hacker

Por último, decir que 1337 no tiene unas reglas fijas, por lo que cada uno puede usar su propio leet speak, siempre que pueda entenderse de forma similar a la descrita aquí. La imaginación y creatividad en el uso de símbolos está permitida, al igual que la corrección ortográfica o sintáctica no son especialmente necesarias.

En fin, hay que ver la de cosas curiosas que hay por el mundo...

35P3R0 q|_|3 31 P057 05 |-|4Y4 R35|_|174|)0 ||\|73R354|\|73.

Más información en:

• Traductores 1337 on-line.
• Cómo leer y escribir en 1337
• Leet speak en la Wikipedia
• ¡Google en versión 1337!

Publicado en: http://www.variablenotfound.com/.

He encontrado una interesante relación de técnicas destinadas a favorecer la creatividad y generar ideas publicada en Neuronilla. En ella se explica, a veces de forma muy detallada, para qué puede ser aplicada cada técnica, el procedimiento a seguir en cada caso, ejemplos y enlaces para ampliar información.

A modo de resumen, encontraremos:

• Mapas mentales, que permite explorar problemas y generar ideas usando una técnica muy gráfica de acceso al potencial del cerebro a través del pensamiento irradiante.


• Arte de preguntar, útil para observar problemas desde distintas perspectivas, utilizando un arsenal de preguntas predefinidas (¿cuándo?¿qué clase de?¿con qué?...)


• Brainstorming, o tormenta de ideas, todo un clásico en las técnicas grupales para generar ideas.


• Relaciones forzadas, técnica que suele usarse complementando al brainstorming en momentos de aparente bloqueo, creando nuevas situaciones a partir de la combinación de hechos conocidos con desconocidos.


• SCAMPER, cuyo nombre está compuesto por las iniciales de las cuestiones a plantearse que estimulan la creación de ideas: ¿Sustituir?¿Combinar?¿Adaptar?¿Modificar?¿Para otros usos? ¿Eliminar o reducir?¿Reordenar o invertir?


• Listado de atributos, técnica considerada ideal para la generación de nuevos productos, o mejorar los existentes, consiste en enumerar atributos del objeto o concepto, e intentar mejorar o solucionar cada uno de ellos.


• Analogías, consistente en la generación de ideas para solucionar un problema dando un rodeo, acudiendo a otras disciplinas no relacionadas; por ejemplo, resolver un problema empresarial observando el comportamiento de un equipo deportivo.


• Biónica, técnica usada en ámbitos tecnológicos, que persigue la creación de aparatos útiles basados en el estudio de los sistemas biológicos. Ejemplos hay muchos: aviones, radares, el velcro...


• Creación en sueños, que aprovecha el poder creativo del sueño y estados de sopor para solucionar un problema, se basa en la interiorización de la cuestión a solventar antes de ir a dormir, y en tener a mano papel y lápiz para anotar las imágenes y asociaciones llegadas en estos momentos.


• Método Delfos, también llamado Delphi, que utiliza expertos en una materia para encontrar soluciones a problemas a través de análisis sucesivos de éste y las respuestas obtenidas en fases iterativas.


• Análisis morfológico, que permite generar gran cantidad de ideas en muy poco tiempo descomponiendo un problema en sus elementos más básicos, creando una matriz que facilita la combinación aleatoria de las distintas posibilidades existentes en cada uno de ellos.


• CPS (Creative Problem Solving) define procedimiento de seis pasos para la solución creativa de problemas: definición de objetivos, captura de información, reformulación del problema, generación de ideas, selección y refuerzo y creación del plan de acción.


• Técnica Clásica, que establece un método de cinco pasos secuenciales a seguir para la generación estructurada de ideas: recogida de materia prima, trabajo con ideas, incubación inconsciente, inspiración y finalización.


• Relajación, como técnica básica para potenciar la imaginación, intuición, concentración y atención.


• Visualización, o pensamiento mediante imágenes, esquiva las limitaciones del lenguaje centrándose exclusivamente en otros aspectos, facilitando la vivencia de experiencias futuras.


• Mitodología, aprendizaje del proceso creativo a través del uso de dramatizaciones basadas en personajes mitológicos.


• Ideart, usa estímulos visuales (pinturas) para la generación de ideas mediante provocación, creando vínculos entre ellos y el foco creativo.


• TRIZ, una metodología creada especialmente para generar ideas ingeniosas en problemas tecnológicos, muy utilizada en ámbitos industriales.


• CRE-IN, conjunto de técnicas destinadas a la búsqueda interna de la paz, la reflexión, relax, etc., con objeto de generar una actitud más imaginativa y desestructurada.


• 4x4x4, técnica de producción de ideas a base de la obtención, primero de forma individual y luego grupal, de ideas, que van compartiendo y seleccionando sucesivamente.


• La técnica DaVinci, que se basa en dejar actuar a la intuición para la generación de ideas de forma visual, dibujando y escribiendo conceptos procedentes del subconsciente.


• Seis sombreros para pensar, una técnica de análisis y resolución de problemas desde distintas perspectivas, representadas como sombreros. Así, los participantes deberán concentrarse en generar ideas según el sombrero que tengan puesto: optimismo, objetividad, creatividad, cautela, etc.


• Provocación, que elimina del pensamiento los patrones establecidos para la resolución de problemas al basarse en ideas deliberadamente absurdas (provocaciones), lo que facilita la generación de ideas diferentes.


• Programación neurolingüística, que ayuda a determinar las estrategias mentales de personas muy creativas para poder replicarlas en otros. Por ejemplo, del estudio de Walt Disney se obtuvo el Modelo de Creatividad Disney, una técnica basada en el comportamiento de este genio.


• DO IT, que además de traducirse como "Hazlo", corresponde a las iniciales de las fases de la técnica, Definir el problema, Open (abrir la mente a múltiples soluciones), Identificar la mejor solución y Transformarla en acción eficazmente.


• Estratal, técnica consistente en la creación de enunciados paralelos en torno al objetivo, que se consideran como una totalidad aún siendo independientes unos de otros.


• Método 635, en el que seis personas escriben tres ideas durante cinco minutos, pasándolas a sus compañeros hasta completar un ciclo. Se considera igual de efectivo que el brainstorming, y más controlable.


• Brainwriting, o lluvia de ideas escritas, utiliza una técnica similar al brainstorming para generar gran cantidad de ideas en grupos remotos, o con problemas con dificultades de comunicación.


• Conexiones morfológicas forzadas, facilita la aparición inicial de ideas sobre aspectos que no se han tenido en cuenta, así como la inspiración basada en analogías.


• Inversión, una interesante técnica que consiste en darle la vuelta al objetivo y hacer que este giro hacia un planteamiento absurdo provoque la aparición de nuevas ideas.


• Empatía, que facilita la percepción desde una perspectiva ajena al individuo.


• Alternative Environment, técnica utilizada para favorecer la aparición de soluciones inusuales a retos usuales.

Como indican al principio, aunque es posible usar muchas de ellas de forma individual, lo óptimo es trabajarlas en grupos de 6 u 8 personas de perfil heterogéneo, sin niveles jerárquicos, clima de confianza y cohesión y manteniendo siempre visibles los objetivos a lograr.

Para más información, visitad la web http://www.neuronilla.com/.

Publicado en: http://www.variablenotfound.com/.

FxCop es una herramienta que nos ayuda a mejorar la calidad de nuestras aplicaciones y librerías desarrolladas en cualquier versión de .Net, analizando de forma automática nuestros ensamblados desde distintas perspectivas y sugiriéndonos mejoras cuando detecta algún problema o incumplimiento de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers).

La versión actual (1.35) se puede descargar desde esta dirección, aunque ya existe una beta de la v1.36 en la web de Microsoft. Todos los comentarios que siguen se refieren a esta última versión, la 1.36 (beta), osado que es uno ;-), pero la mayor parte son válidos para la última revisión estable, la 1.35.

Una vez instalado tendremos a nuestra disposición dos aplicaciones: FxCop, que facilita el análisis y consulta de resultados a través de su propia GUI, y FxCopCmd, ideada para su utilización desde línea de comandos e integrarlo en otros sistemas, como Visual Studio, como parte del proceso de construcción (build) automatizado.

En cualquiera de los dos casos, el análisis de los ensamblados se realiza sometiéndolos a la comprobación de una serie de reglas basadas en buenas prácticas y consejos para asegurar la robustez y mantenibilidad de código. Del resultado del mismo obtendremos un informe con advertencias agrupadas en las siguientes categorías:

• Advertencias de diseño, recoge avisos de incumplimientos de buenas prácticas de diseño para .Net Framework, como pueden uso de constructores públicos en tipos abstractos, interfaces o namespaces vacíos, uso de parámetros out, capturas de excepciones genéricas y un largo etcétera.


• Advertencias de globalización, que avisan de problemas relacionados con la globalización de aplicaciones y librerías, como pueden ser el uso de aceleradores de teclado duplicados, inclusión de rutas a carpetas de sistema dependientes del idioma ("archivos de programa"), etc.


• Advertencias de interoperabilidad, que analizan problemas relativos al soporte de interacción con clientes COM, como el uso de tipos auto layout visibles a COM, utilización de System.Int64 en argumentos (que no pueden ser usados por clientes VB6), o la sobrecarga de métodos.


• Advertencias de movilidad, cuestionando el soporte eficiente de características de ahorro de energía, como uso de procesos con prioridad ProcessPriorityClass.Idle., o inclusión de Timers que se repitan más de una vez por segundo.


• Advertencias de nombrado, que detectan las faltas de cumplimiento de las guías y prácticas recomendadas en cuanto al nombrado de elementos (clases, métodos, variables, etc.), como uso de nombres de parámetros que coinciden con nombres de tipo, y más con los propios de un lenguaje concreto, mayúsculas y minúsculas no utilizadas correctamente, eventos que comiencen por "Before" o "After", puesto que deben nombrarse conjugando verbos en función del momento que se producen (p.e., Closing y Closed en lugar de BeforeClose y AfterClose), y un largo conjunto de comprobaciones.


• Advertencias de rendimiento, que ayudan a detectar problemas en el rendimiento de la aplicación o librería, comprobando puntos como el número de variables locales usadas, la existencia de miembros privados o internos (a nivel de ensamblado) no usados, creación de cadenas (strings) innecesarias, por llamadas múltiples a ToLower() o ToUpper() sobre la misma instancia, realización de conversiones (castings) innecesarios, concatenaciones de cadenas en bucles, etc.


• Advertencias de portabilidad, que recoge observaciones interesantes para la portabilidad a distintas plataformas, como el uso de declaraciones PInvoke.


• Advertencias de seguridad, que se centran en analizar aspectos que podrían dar lugar a aplicaciones o librerías inseguras, avisando de problemas potenciales como la ausencia de directivas de seguridad, punteros visibles, o uso de arrays de sólo lectura, entre otros.


• Advertencias de uso, que analizan el uso apropiado del framework .Net realizando multitud de chequeos sobre el código, detectando aspectos como ausencia la liberación (dispose) explícita de tipos IDisposable, resultados de métodos no usados, uso incorrecto de NaN, etc.

(Puedes ver la lista completa de comprobaciones, en inglés, aquí)

Realizar un análisis de un ensamblado con FxCop resulta de lo más sencillo. Basta con crear un proyecto (al iniciar la aplicación aparecerá uno creado por defecto), añadir los ensamblados a analizar y pulsar el botón que iniciará el proceso.

El tiempo dependerá del número y complejidad de los ensamblados a analizar, así como del conjunto de reglas (pestaña "rules") a aplicar, que por defecto serán todas. En cualquier caso, el proceso es rápido y finalizará con la presentación de una lista con el resumen de las anomalías detectadas, sobre la que podremos navegar y ampliar información.


Por cada anomalía, además, podremos acceder a una descripción completa de sus causas, origen en el código fuente, posibles soluciones, una URL para ampliar información, grado de certeza de existencia del problema, su gravedad y la categoría a la que pertenece. Con estos datos, sólo nos quedará acudir a nuestro código y corregir o mejorar los aspectos indicados.

En conclusión, se trata de una interesante herramienta que puede ayudarnos a mejorar la calidad del código que creamos. Aunque existen los "falsos positivos" y a veces no es todo lo precisa que debiera, la gran cantidad de comprobaciones que realiza, la posibilidad de añadir reglas personalizadas, así como el detalle de los informes de resultados hacen de ella una utilidad casi imprescindible para los desarrolladores .Net.

Publicado originalmente en: http://www.variablenotfound.com/.

Hace unos meses, el blog Inter-Sections publicó un interesante post donde el autor recogía las conclusiones obtenidas a partir de su experiencia desarrollando y seleccionando personal, respecto a cómo reconocer a los buenos desarrolladores.

Esta información, además, ha sido complementada con decenas de comentarios de lectores a raíz de su reciente aparición en Slashdot, convirtiéndose en un artículo muy recomendable para los que estamos en el mundo del desarrollo de software y vemos lo complicado que resulta a veces dar con las personas apropiadas. Y es que la contratación del personal adecuado es un factor clave para el éxito (y a veces supervivencia) en una empresa de software, cuya actividad se basa en gran medida en el talento de sus desarrolladores.

Los indicadores clave que, según Daniel, nos pueden ayudar a detectar a los buenos desarrolladores de software se agrupan en los siguientes puntos:

1. son apasionados por el desarrollo
2. son autodidactas y les encanta aprender
3. son inteligentes
4. normalmente tienen experiencia oculta
5. son conocedores de tecnologías variadas y punteras
6. por último, aporta lo que en su opinión no es en absoluto determinante: la titulación.

Estos se concretan en un resumen final de características positivas y negativas, casi un checklist, que nos podrían ayudar a detectar comportamientos y actitudes clave:

Indicadores Positivos (propios de los buenos desarrolladores)

1. Apasionado por la tecnología
2. Programa por hobby
3. Capaz de hablar durante horas sobre temas técnicos si se le anima
4. Lleva (y ha llevado) a cabo proyectos personales
5. Aprende nuevas tecnologías por su cuenta
6. Opina sobre las tecnologías apropiadas en cada caso
7. Se siente poco cómodo usando tecnologías que no considera correctas
8. Es claramente inteligente, se puede conversar con él de muchos temas
9. Comenzó a programar mucho antes de ir a la universidad o empezar a trabajar
10. Tiene "icebergs" ocultos, grandes proyectos y actividades personales que no aparecen en el currículum.
11. Conoce gran variedad de tecnologías, que pueden no encontrarse reflejadas en el CV.

Indicadores Negativos (propios de los no tan buenos desarrolladores)

1. Ve la programación simplemente como su trabajo
2. No habla de programación fuera del trabajo
3. Aprende nuevas tecnologías exclusivamente en cursos ofrecidos por la empresa
4. Se siente cómodo con la tecnología que se les imponga, piensa que cualquiera es buena
5. No parece ser muy inteligente
6. Comenzó a programar en la universidad
7. Toda su experiencia en programación está en su currículum
8. Está centrado exclusivamente en una o dos tecnologías

En mi opinión, aunque la lista incluye puntos interesantes y acertados, y puede sernos útil como base para la reflexión, el tema creo que es mucho más complejo. Seguro que cada uno de nosotros podría matizar los puntos, eliminarlos o ampliar las listas, tal y como se pone de manifiesto en los comentarios del post, partiendo de nuestras propias experiencias y convicciones.

Por ejemplo, desde mi punto de vista, los indicadores positivos podríamos ampliarlos mucho; los buenos desarrolladores deben mostrar, aparte de las habilidades y actitudes ya citadas, otras comentadas por aquí hace tiempo como capacidad de comunicación e integración en equipos de trabajo, responsabilidad, compromiso, interés y cariño por el resultado de los productos que uno genera, habilidades literarias, curiosidad y seguro que un larguísimo etcétera. Además, pueden producirse falsos positivos; como muestra, decir que es bueno ser un apasionado del desarrollo, pero este hecho no garantiza el ser un gran desarrollador.

En el grupo de los indicadores negativos podríamos añadir, por ejemplo, los inversos de las características anteriores (incapacidad de hacerse responsable de algo, falta de cuidado en los resultados...), o matizar las recogidas por Daniel. Por ejemplo, estar centrado exclusivamente en una o dos tecnologías puede ser indicador de una gran especialización, o tener intereses y hobbies ajenos a la programación puede ser muy beneficioso para los profesionales que nos dedicamos a esto.

Y es que también hay que tener en cuenta que no es lo mismo ser un gran desarrollador en tu casa, como hobby, que serlo en una empresa. He conocido magníficos desarrolladores que según estos indicadores no parecerían pasar de la mediocridad, al igual que otros que aún cumpliendo la mayoría de los puntos positivos adolece de otras características, como habilidades de trabajo en equipo o actitudes elitistas, que lo hacen absolutamente inútil en una compañía de producción de software en el que tendrá que trabajar codo con codo con sus compañeros.

En cualquier caso, se trata siempre de características difíciles de percibir por la empresa vía el tradicional currículum y de ahí la necesidad de contar con medios complementarios como los blogs (sabéis que tengo la certeza de que los blogs ayudan a encontrar empleo), o realizar entrevistas y pruebas de nivel cada vez más complejas.

Publicado en: http://www.variablenotfound.com/.

Visual Basic .NET 9.0, disponible con Visual Studio 2008, incluye, al igual que C# 3.0, multitud de novedades y mejoras que sin duda nos harán la vida más fácil.

Una de ellas es la posibilidad de declarar variables sin necesidad de indicar de forma explícita su tipo, cediendo al compilador la tarea de determinar cuál es en función del tipo de dato obtenido al evaluar su expresión de inicialización. El tipado implícito o inferencia de tipos también existe en C# y ya escribí sobre ello hace unos días, pero me parecía interesante también publicar la visión para el programador Visual Basic y las particularidades que presenta.

Gracias a esta nueva característica, en lugar de escribir:

  Dim x As XmlDateTimeSerializationMode = XmlDateTimeSerializationMode.Local
  Dim i As Integer = 1
  Dim d As Double = 1.8

podremos utilizar:

  Dim x = XmlDateTimeSerializationMode.Local
  Dim i = 1
  Dim d = 1.8

El resultado en ambos casos será idéntico, ganando en comodidad y eficiencia a la hora de la codificación y sin sacrificar los beneficios propios del tipado fuerte.

Hay un detalle importante que los veteranos habrán observado: Visual Basic ya permitía (y de hecho permite) la declaración de variables sin especificar el tipo, de la forma Dim i = 1 (con Option Strict Off), por lo que podría parecer que el tipado implícito no sería necesario. Sin embargo, en este caso los compiladores asumían que la variable era de tipo Object, por lo que nos veíamos obligados a realizar castings o conversiones en tiempo de ejecución, penalizando el rendimiento y aumentando el riesgo de aparición de errores imposibles de detectar en compilación. Tampoco tiene nada que ver con tipados dinámicos (como los presentes en javascript), o con el famoso tipo Variant que estaba presente en Visual Basic 6; el tipo asignado a la variable es fijo e inamovible, como si lo hubiésemos declarado explícitamente.

En Visual Basic 9, siempre que no se desactive esta característica incluyendo la directiva Option Infer Off en el código, el tipo de la variable será fijado justo en el momento de su declaración, deduciéndolo a partir del tipo devuelto por la expresión de inicialización. Por este motivo, la declaración y la inicialización deberán hacerse en el mismo momento:

  Dim i = 1 ' La variable "i" es Integer desde este momento

  Dim j     ' La variable "j" es Object, como siempre, 
  j = 1     ' ... si Option Scrict está en Off. 
            ' En caso contrario aparecerá un error de compilación.

 

El tipado implícito puede ser asimismo utilizado en las variables de control de bucles For o For Each, haciendo su escritura mucho más cómoda:

 
  Dim suma = 0
  For i = 1 To 10       ' i se está declarando ahí mismo como Integer,
    suma += i           ' no existía con anterioridad
  Next

  Dim str = "abcdefg"
  For Each ch In str    ' ch se declara automáticamente como char,
      Console.Write(ch) ' que es el tipo de los elementos de "str"
  Next

 
Y también puede resultar bastante útil a la hora de obtener objetos de tipos anónimos, es decir, aquellos cuya clase se define en el mismo momento de su instanciación, como en el siguiente ejemplo:

  Dim point = New With {.X = 1, .Y = 5}
  point.X += 1
  point.Y += 1

 

Por último, es interesante comentar que, a diferencia de C#, Visual Basic permite declarar en la misma línea distintas variables de tipo implícito, por lo que es posible escribir Dim k=1, j=4.8, str="Hola" sin temor a un error en compilación, asignándose a cada una de ellas el tipo apropiado en función de su inicialización (en el ejemplo, Integer, Double y String respectivamente).

Coinciden, sin embargo, en que en ambos lenguajes esta forma de declaración de variables se aplica exclusivamente a las locales, es decir, aquellas cuyo ámbito es un método, función o bloque de código. No pueden ser propiedades ni variables de instancia; en el siguiente ejemplo, x será declarada de forma implícita como Object, mientras que el tipo de la variable y será inferido como Integer:

  Public Class Class1
    Dim x = 2        ' Es una variable de instancia
    Public Sub New()
        Dim y = 2    ' Es una variable local
    End Sub
  End Class

 
En resumen, se trata de una característica muy útil que, además de permitirnos programar más rápidamente al ahorrarnos teclear los tipos de las variables locales, actúa como soporte de nuevas características del lenguaje y la plataforma .NET, como el interesantísimo Linq.

Es conveniente, sin embargo, utilizar esta característica con cordura y siendo siempre conscientes de que su uso puede dar lugar a un código menos legible y generar errores difíciles de depurar. De hecho, Microsoft recomienda usarlas "sólo cuando sea conveniente".

Publicado en: Variable Not Found.

En un blog relativamente joven como este, donde el tráfico se ha incrementado de forma bastante considerable en los últimos meses, y cuyos lectores son mayoritariamente nuevos, es posible que éstos no hayan accedido a artículos anteriores a este periodo que pueden resultar interesantes dado el número de lecturas y repercusión conseguida por los mismos.

Me ha parecido interesante la idea de Martín, desde Pensamientos Ágiles, de recoger los posts más visitados de su blog durante el pasado 2007, así que, con su permiso, voy a tomarla prestada y aplicarla a Variable Not Found. ;-)

1. El indiscutible vencedor, "Entre 10 y 28 programadores por el precio de uno", publicado el pasado mes de julio, en el que comentaba un post de Phil Haack que hablaba de factores que influyen en la productividad de los desarrolladores. Este post fue muy difundido gracias a menéame y otros blogs que se hicieron eco de él.

2. En segundo puesto, "Bordes redondeados en webs (sin esfuerzo) con Nifty Corners Cube" puso de manifiesto el interés que despierta este asunto entre los desarrolladores de webs. De hecho, la gran difusión de este post superó todas las expectativas, y fue el causante de la creación de NiftyDotNet, mi primer componente de código abierto.

3. "Llamar a métodos estáticos con ASP.NET Ajax" forma parte de una serie de posts sobre el framework Ajax de Microsoft, donde he procurado explicar cómo usar esta tecnología, siempre de forma muy práctica y aplicada a casos concretos. De hecho, sumando las visitas de forma individual a cada una de las páginas de la serie ("Llamar a servicios web paso a paso", "Intercambio de entidades de datos", "Retornar DataSets desde PageMethods" y "Espía a tus visitantes con Ajax"), casi podríamos llegar al primer puesto, pues todas ellas están entre las quince más visitadas del blog.

4. Los comentarios en el código fuente... sí, eso que parece tener bastante poca importancia a la hora de desarrollar, ha escalado rápidamente en diciembre hasta conseguir la cuarta posición de la mano del post "13 Consejos para comentar tu código fuente", conclusión llevada a la práctica de un artículo anterior, "Problemas al comentar el código fuente". Obviamente, el tema interesa bastante más de lo que podría parecer en un principio.

5. El quinto puesto ha sido una sorpresa. Aunque con un cierto aire off-topic, alejado de la temática habitual del blog, "Escaneo de puertos con idle scan" muestra de forma detallada los entresijos de una interesante técnica de detección de puertos abiertos en equipos remotos, y parece ser que ha resultado interesante. Su continuación práctica, "Idle scan en la práctica", también ha sido seguido, aunque con menor afluencia, por muchos usuarios a la búsqueda de información sobre esta técnica.

6. El sexto puesto también ha resultado sorprendente, pues se trata de un post bastante antiguo y cuya temática normalmente no se trata demasiado por aquí. "Instalar OpenCms bajo Windows" recogía los pasos a seguir para poner en marcha este CMS bajo Windows, y supongo que por la ausencia de otros textos similares en castellano, ha sido ofrecido por Google como resultado a todos los usuarios que buscaban respuesta a sus cuestiones.

7. El séptimo puesto va para un post de opinión, "10 razones por las que tu blog te ayuda a encontrar empleo", en el que recogía reflexiones sobre por qué un blog podía ser una ayuda interesante para destacar y promocionarse para la búsqueda de empleo.

8. La expectación ante la llegada de Visual Studio 2008 hizo que el post "Diez cosas a saber sobre VS2008 y .Net Framework 3.5" subiera también hasta los "top ten" del blog. Cosas que pasan cuando citas a los grandes como Daniel Moth.

9. El post "Hábitos de personas altamente inovadoras", demostró el interés que despiertan las actitudes que facilitan la generación de ideas y la innovación.

10. En el décimo lugar se encuentra una reflexión sobre esta profesión. "¿Recomendarías a tu hijo que se dedicase al mundo del desarrollo de software?" lanzaba una pregunta al aire sobre la satisfacción de los que nos ganamos la vida con esto.

Más allá de décimo lugar también han despertado interés los posts acerca de características de C# como los generics, null coalescing operator, tipos anulables, las cadenas de texto largas (heredoc), o más generales como "TryParse vs. Parse", "Obtener Guids en .Net", o frikadas como "¿Incrementos, autoincrementos o sumas?". Y mención especial para la serie de doce posts técnicas de spam, un tema que también ha interesado bastante a los lectores.

Publicado en: http://www.variablenotfound.com/.