Archive for March 25, 2010

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 :)

Workflow Foundation, Cuándo, Cómo, Dónde

Una pregunta común que recibo a diario es "cúando debo usar Workflow Foundation, en mi lógica de negocio? en mi cliente? como un almacen de persitencia?". Hace unos días un amigo me escribió un correo comentandome esto:

“Entonces en Workflow Foundation debo reemplazar mi lógica de negocio hecha en código por un workflow secuencial”

Esta pregunta coincide con algo sumamente recurrente que suelo escuchar cada vez que hablo acerca de Workflow Foundation: Dónde encaja Workflow Foundation en mi aplicación

Recuerdo a finales del año 2005 cuando las primeras Beta de la Framework 3.0 o “previews” salieron al aire, recuerdo haberme emocionado muchísimo al leer sobre las “Foundations” (de hecho, en ese tiempo estaba cambiando de plataforma y vivía en un período gris y no podía evitar el comparar cosas en .Net con cosas en lo “otro” en que trabajaba). Una de las cosas que más me llamó la atención fue Workflow Foundation, probablemente porque en uno de nuestros proyectos anteriores pasé un buen tiempo desarrollando una máquina secuencial de flujo y bueno me pareció excelente el que ahora una framework incluyera todo un toolset y “runtime” para el manejo de flujos de trabajo.

Hagamos antes un repaso rápido de qué involucra Workflow Foundation (para conocer un poco más acerca de que hace o se trata, recomiendo este link): http://msdn.microsoft.com/en-us/netframework/aa663328.aspx

  • Un runtime para ejecución de procesos (workflows)
  • Una serie de bloques o actividades básicas para la construcción de procesos (Activities)
  • Un toolset completo para el manejo y diseño de procesos (Addins, Services)

Adicionalmente la framework completa puede extenderse, o sea, embeber el runtime en nuestra aplicación, extender los flujos actuales, crear nuestras propias actividades y servicios y hasta embeber el designer de Workflows en nuestra aplicación.

Bien, entonces nace la pregunta de oro, ¿cuándo usar Workflow Foundation?. Bien, podríamos decir que WF puede usarse en las siguientes situaciones

  • Orquestación de pasos o actividades dentro de un modelo de negocio
  • Visibilidad del proceso del negocio
  • Persistencia en un proceso de negocio

Y bueno, para evitar confusiones, vale la pena mencionar cuándo a mi criterio no debe utilizarse Workflow Foundation

  • Para desarrollar la lógica de negocio del sistema
  • Para desarrollar una herramienta de programación para personal no técnico
  • Para reemplazar un DSL ya establecido en la organización
  • Para reemplazar la persistencia de otros aspectos que no están relacionados al proceso en si

Esto es importante, especialmente la primera parte, he visto muchos sistemas que buscan reemplazar o diseñar la lógica de negocio del sistema completamente desde cero usando WF, creo que ese es el ingrediente principal para futuros dolores de cabeza.

En vez de reemplazar o crear la lógica de negocio completamente desde WF, porqué mejor no “orquestamos” esa lógica mediante WF? Un buen indicador de que estamos empleando mal WF es la proliferación de codebehind en el Workflow y de Code Activities. Un buen Workflow debe ser netamente declarativo, eso elimina el uso de Code Activities, de hecho, en Workflow Foundation 4.0 las Code Activities ya no existen.

En resumidas cuentas, Workflow Foundation deben ser un agregado a la lógica de nuestra entidad de negocio y no el core de ella. Debe funcionar como un coordinador entre los pasos o secuencias de cada uno de los servicios o actividades de un proceso actual, debe ser una herramienta de extensión, no una central del desarrollo.

Bueno, como siempre, cuéntenme sus ideas, perspectivas o comentarios al respecto. Soy todo oídos :)

Book Review: Programming Windows Workflow Foundation

Programming Windows Workflow Foundation Días atrás terminé de leer uno de mis primeros libros sobre Workflow Foundation, “Programming Windows Workflow Foundation – Practical WF Techniques and Examples using XAML and C#” de K. Scott Allen publicado por Packt Publishing. Un libro simple, sencillo, corto y conciso para aquel que simplemente ha escuchado acerca de Workflow Foundation y quiere aprender de qué se trata y como explotarlo o sacarle provecho a esta tecnología. El libro, como muchos otros de la Editorial Packt, es un libro básico, para principiantes pero a la vez no se queda corto, profundiza en las áreas que debe hacerlo y le deja la oportunidad al lector de sumergirse por su propia cuenta e ir más allá de los ejemplos expuestos en el libro (ejemplos relativamente sencillos y fáciles de completar, nada del otro mundo). El libro es corto (a mi criterio una gran ventaja ya que muchos quieren algo de “fácil digestión” y que puedan leer rápidamente un fin de semana) y consta de sólo 8 capítulos con alrededor de 233 páginas que incluyen tópicos tales como: introducción a la tecnología, creación de workflows, explicación de cada una de las actividades de la librería base de actividades, creación de actividades customizadas, hosting del runtime de workflow foundation, workflows secuenciales y de estado, intercomunicación de workflows y manejo de reglas y condiciones. En general cosas que me gustaron del libro:

  • El libro es bastante corto y de muy fácil lectura
  • El libro es bastante simple y sus ejemplos sencillos y fáciles de hacer
  • La narrativa del autor es sumamente sencilla de seguir
  • El libro contiene la información básica y necesaria para comenzar a usar Workflow Foundation

Sin embargo, creo que muchos de estos puntos también son la debilidad del libro, por ejemplo

  • El libro no incluye información útil sobre como efectivamente hacer hosting de Workflow Foundation en una aplicación web
  • El libro fue hecho y esta orientado al desarrollo con Workflow Foundation 3.0, en la versión 3.5 las cosas (especialmente interoperatibilidad con servicios) cambiaron drásticamente
  • El libro no ahonda en algunos detalles a consideración del autor, por ejemplo, como se trabajan los servicios (especialmente web services) en un Workflow Secuencial
  • Creo que al capítulo de extensión de actividades (Actividades customizadas) le falto un poco más de contenido, es decir, ¿cuándo necesitamos una actividad customizada? o cómo utilizar binders propios de Visual Studio en nuestras actividades.

Bueno, en general, si usted ya es un feliz usuario de Workflow Foundation 3.0 no le recomendaría este libro, probablemente para referencia rápida; pero si usted esta pensando en conocer Workflow Foundation, ya sea para sus aplicaciones actuales o para un uso futuro (por ejemplo, no entiende WF en Sharepoint) definitivamente lo recomiendo, es algo que en un descansado fin de semana puede leer y comprender, en fin, una excelente guía rápida de aprendizaje.

Advertencia: Encontré entre mis post guardados esta review pero al parecer nunca la publiqué, la review es de muchos meses atrás.

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

Book Review: Don’t Just Roll the Dice

Don't Just Roll the Dice Hace unos días terminé de leer el maravilloso libro “Don’t Just Roll the Dice – A usefully short guide to software pricing” de Neil Davidson (cofundador de RedGate Software), a mi criterio un excelente libro el cuál nos ofrece una guía consisa sobre un tema que no muchos se atreven de escribir o comentar: El poner precio al software.

El libro esta orientado principalmente a ISVs (Independent Software Vendors) , o traducido al español, a todo aquel que hace software “empaquetado” (si, el vender software bajo el término de “bajo pedido” o consultoría es otro dragón de múltiples cabezas totalmente diferente).

Algunos de nosotros que trabajamos software “empaquetado” al finalizar el desarrollo y pasar a la etapa de “venta” nos topamos con la difícil decisión de “¿y a cuánto lo vendo?”, algunos basan su precio en el precio de la competencia, otros en la mera apreciación subjetiva de lo que cree vale el software y otros simplemente adivinan (si, hay casos en que el precio es simplemente un número aleatorio entre cierto rango).

No es un libro de cocina, tampoco un “manual” de reglas de precios, o una guía de “cómo se que mi precio es el correcto”. El libro va más allá, explicándonos el porqué los precios varían y todo lo que el precio puede decir de nuestro producto y/o compañía. Numerosos ejemplos de empresas y productos nos ilustran los puntos que el escritor comenta en su obra, en resumidas cuentas, el libro es toda una joya.

Si usted actualmente es o piensa en un futuro ser un ISV, este libro es un “must have”.

¡Hasta el próximo post!