Tag Archive for programming

Enumeradores – Bit Flags

Todos recordamos que podemos usar los enumeradores como flags y luego recuperar la selección con operaciones de bit, por ejemplo, tomemos el siguiente enumerador (tomado de la documentación de MSDN):

[Flags]
public enum MultiHue {
    Black = 0,
    Red = 1,
    Green = 2,
    Blue = 4
}

Podemos pedirle al usuario de la API que seleccione un set de colores o tonalidades y luego obtener su selección mediante bit operations:

var hue = MultiHue.Black | MultiHue.Red;
var isRed = ((hue & MultiHue.Red) == MultiHue.Red);
var isGreen = ((hue & MultiHue.Green) == MultiHue.Green);

Bien, ahora en la .Net Framework 4.0 tenemos un nuevo método que nos hace mas “claro” la lectura de la bit flag:

var hue = MultiHue.Black | MultiHue.Red;
var isRed = hue.HasFlag(MultiHue.Red);
var isGreen = hue.HasFlag(MultiHue.Green);

No se ustedes pero este último es de mejor lectura para mi.

¡Saludos!

Lo nuevo en ASP.NET 4.0, Introducción

El lanzamiento de Visual Studio 2010 y con ello la .Net Framework 4.0 esta a la vuelta de la esquina, con cada nuevo lanzamiento (desde que recuerdo usar la .Net Framework, o sea, tampoco mucho tiempo atrás :P ) siempre me propongo como meta el escribir una serie de posts acerca de lo “nuevo” que trae y los cambios que hay que observar. Esta vez estoy decidido a cumplir con ese propósito, así que creo que no hay algo tan ilustrativo para mostrar los cambios en general como el que hablemos acerca del “nuevo” ASP.NET 4.0

Según wikipedia, ASP.NET tiene ya casi 8 años de haber sido released, sin embargo si leemos su historia, fue ideado y pensado para la arquitectura o forma de desarrollar aplicaciones web a finales de los años 90. En ese tiempo pensar en “compatiblidades” entre browsers era impensable (los niveles de compatibilidad entre los browsers realmente eran mucho más complicados de lo que son ahora). Programar en “client side” con javascript en el browser era un sueño lejano, trabajar con hojas de estilo era algo que (aún hoy para muchos) representa un tabú. Cuando vemos cosas como un gigantesco ViewState, un horrible markup generado sin estilos y usando tablas, impronunciables identificadores de elementos en markup de html, realmente estamos viendo la crema y nata del web development a finales de los años 90. Ya era hora de un cambio en el mundo de ASP.NET.

Hoy por hoy el uso de Javascript frameworks ya representa un “must have” en todo desarrollo web, HTML5 esta a la vuelta de la esquina, aplicaciones web netamente clientside ya son muy comunes, los paradigmas de desarrollo han cambiado drásticamente. Microsoft ha tratado de “ponerse al día” con estas nuevas tendencias, tomemos por ejemplo ASP.NET AJAX (yep, algo horrible y poco práctica al final, pero creo que fue el primer inicio de Microsoft en la dirección correcta) y hoy por hoy el nacimiento de ASP.NET MVC, casi que podríamos decir: “Runtime nuevo, ASP.NET nuevo”.

En esta serie trataré de dar un par de hojeadas a las cosas “nuevas” que nos ofrece ASP.NET 4.0, qué problemas resuelve y como cambia con respecto a versiones anteriores.

Hasta la próxima entrega :)

Lenguajes funcionales, divide y vencerás

Hace unos días me encontraba en una sesión de review de código en la oficina de un cliente y me topé con el típico problema recurrente del cual creo que ya muchos estamos empapados: “La clase superhéroe”, si, esa amiga que no sólo se conecta a la base de datos, sino que también crea la consulta, chequea los datos, genera el id aleatorio del usuario y también al mismo tiempo inserta y cambia los registros en la base de datos, todo en una “compacta” clase que hace literalmente todo.

No, este post no es acerca de SRP (Single Responsability Principle) o de principios de diseño y pensamiento en objetos ni tampoco se trata de la vieja escuela de “modularización” usando subrutinas (me imagino que alguien recuerda sus viejas lecturas de hace muchos años cuando aprendían algo como Pascal o BASIC). En vez de eso, decidí conversar un poco de lo que he aprendido mientras continuo mi jornada de aprendizaje en lenguajes funcionales (usando Haskell).

Advertencia: Estoy en el proceso de aprendizaje de lenguajes funcionales y Haskell, es muy probable que lo que exprese o diga en este post realmente sean producto de mi alta taza de ignorancia al respecto. :D

En Haskell las funciones son ciudadanos de primer orden, son uno más, de hecho, son sumamente importantes (me imagino que en los demás lenguajes funcionales el principio es el mismo). El principio que rige o elimina la duplicidad y la reutilización de operaciones en lenguajes funcionales es la simple composición de funciones, o sea, de forma similar a como deberíamos desarrollar aplicaciones mediante composición de objetos, en un lenguaje funcional, funciones complejas se crean mediante funciones más simples, primitivas y sencillas. Lección a aprender, procura que tu “método” o “función” (o como quieras llamarlo, si quieres, hasta “subrutina” le puedes poner) haga una y sólo una cosa.

Tomemos el siguiente ejemplo (tomado del libro Programming in Haskell de Graham Hutton) dónde definimos un cifrador de cesar usando simples funciones en Haskell (probablemente se puede definir en una forma mucho más óptima, pero que se yo!)

import Data.Char

{-
- Caesar cypher definition
-}

-- Transform a char to its numeric representation
let2int  :: Char -> Int
let2int a = ord a - ord 'a'

-- Transform an integer to a char representation
int2let  :: Int -> Char
int2let a = chr (ord 'a' + a)

-- Shift a character by its factor
shift    :: Int -> Char -> Char
shift n a | isLower a = int2let z
          | otherwise = a
    where
        x = let2int a
        y = x + n
        z = y `mod` 26 -- because we can reach z someday!

-- Now it is time to encrypt!
encode      :: Int -> String -> String
encode n xs = [shift n x | x <- xs]

La forma en que funciona es simple, al final esta declarada la función encode que utiliza a su vez list comprehension (hablaré de esto después) y a la función definida shif, que a su vez utiliza la función let2int e int2let que también usan a la función incluída ord (que existe en el space Data.Char).

Quizás todo esto se pueda ver “trivial” pero es muy común ver métodos o “Modules” con métodos en Visual Basic que literalmente hacen todo: piden la entrada a la pantalla al usuario, verifican que la entrada sea la correcta, luego hacen el calculo y por último le muestran al usuario el resultado, si, todo en el mismo Main del módulo…

Creo que debemos comenzar a aprender un poco más de lenguajes simples como los lenguajes funcionales, sin construcciones exóticas, sin extensiones mágicas… simples composiciones, simple reutilización, donde la simpleza es el motivo. Claro, esto no implica que no podemos hacer cosas “complejas” en un lenguaje funcional, por ejemplo, Darcs (un sistema de control de versiones distribuido) y Leksah (un IDE para Haskell) se encuentran ambos hechos en Haskell.

La próxima vez que se topen con un super gordo método main, recuerden que es mejor ponerlo a dieta, aprendan de Haskell :D

¡Saludos!

NOTA: mi amigo José Romaniello me comenta que el patrón o el “antipatrón” de la clase superhéroe se conoce como “God Class”, aunque yo prefiero el nombre de superhéroe :D

The complex way is not really the right way…

Today I was visiting a client, and I just stop and watch something that really caught my attention:

foreach (item in myList) {
    if (item.Length > 0) {
        SaveItem(item);
    }
}
// more ugly code...

Well, the code was really different (an uglier one) but you got the idea…. What I suggested to my client was a more concise solutio, create an extension method:

public static class IEnumerableExt {
    public static IEnumerable<T> ForEach(this IEnumerable<T> items, Action<T> action) {
        foreach(var item in items) {
            action(e);
        }
    }
}

The second part is the easy one…

myList
    .Where((item) => item.Length > 0)
    .ForEach((item) => SaveItem(Item));

I don’t know you, but this way looks a lot clearer to me…

Lessson learned: If your code looks complex, please, take a time and look how to make it more clearer.

XUnit.NET Extensions, TheoryAttribute y DataAttribute

Es bastante común toparnos con casos en los que debemos asegurarnos que el mismo test se cumpla para varias condiciones. Imagínense el desarrollo de una calculadora o mucho mejor, el de alguna pieza de lógica de negocio dependiente de data. En vez de escribir ciclos dentro de nuestro test o peor aún, escribir varios test para el caso, en XUnit.NET tenemos el apoyo de las “Theory” que son test que estan fuertemente ligados a los datos.

Los datos son pasados como parámetros del test y el origen de los datos depende de nuestro proveedor de datos seleccionado. En XUnit.NET Extensions tenemos de “cajita” varios proveedores de datos que podemos usar:

  • InlineDataAttribute, los datos se presentan en línea en cada atributo
  • ClassDataAttribute, los datos son proporcionados por una clase que implementa IEnumerable<T>
  • PropertyDataAttribute, los datos son entregados por la propiedad de una clase que retorna IEnumerable<T>
  • SqlServerDataAttribute, los datos vienen de una consulta de una base de datos de SQL Server
  • OleDbDataAttribute, los datos tienen como origen una consulta de un proveedor OleDb
  • ExcelDataAttribute, los datos tienen como origen una hoja de cálculo de Excel.

El uso de Theory y DataAttribute proporciona una agilidad increíble al probar ciertas condiciones que antes requeririan mucha más pericia. Depende de nosotros sacarle provecho :)

[Theory]
[InlineData(1, 2, 3)]
[InlineData(4, 5, 9)]
public void It_can_use_correctly_the_data_attribute(int a, int b, int result)
{
    Assert.Equal(result, (a + b));
}

[Theory, ExcelData("myTestData.xls", "SELECT a, b, result FROM Data")]
public void It_can_use_correctly_the_data_from_an_excel_file(int a, int b, int result)
{
    Assert.Equal(result, (a + b));
}

Bien, hasta aquí llegamos con las Extensiones de XUnit.NET, la próxima entrega veremos como extender a nuestro antojo XUnit.NET ;)