Variable not found

Aspectos a tener en cuenta al crear sitios web públicos

2009-07-06T23:56:00.000+02:00

Hace unos meses, un usuario de StackOverflow planteaba una interesante cuestión: ¿qué debería saber un desarrollador para construir un sitio web público? Es decir, ¿cuáles son aquellos aspectos importantes que deben tenerse en cuenta a la hora de crear un site de calidad, desde el punto de vista técnico?

Tras un tiempo de respuestas, ideas y debates, otro usuario ha realizado una recopilación de los aspectos y sugerencias más votadas y los ha publicado en forma de lista categorizada, donde podemos encontrar muy buenas ideas a tener en cuenta en nuestros propios desarrollos, y que me he permitido traducir.

Muchos de los puntos son obvios y seguro que ya los estáis teniendo en cuenta, quizás otros son demasiado exagerados, y seguro que alguno de ellos ni siquiera os los habíais planteado. En cualquier caso el resultado es una relación interesante y muy a tener en cuenta para mejorar nuestros sitios web.

Interfaz y experiencia de usuario

Ser consciente de que los navegadores implementan los estándares de forma diferente y asegurarse de que el sitio web funciona razonablemente bien en la mayoría de los principales navegadores. Como mínimo, sería necesario probarlo con un navegador que utilice un motor reciente Gecko (Firefox), Webkit (Safari, Chrome y algunos navegadores móviles), las versiones soportadas de Internet Explorer, y Opera.
Tener en cuenta que el sitio web puede ser visitado utilizando medios distintos a los navegadores habituales, como por ejemplo teléfonos móviles, lectores de pantalla, o motores de búsqueda. Usar estándares de accesibilidad como WAI o Section508 .
Considerar los mecanismos de actualización del sitio web para que estos procesos no afecten a los usuarios una vez que el sistema está en marcha y puedan producirse de forma suave y transparente. Por ejemplo, puede ayudar el mantener entornos de prueba paralelos, el uso de herramientas de control del código fuente, o mecanismos de builds automatizados.
No mostrar errores directamente al usuario.
No incluir en las páginas direcciones de correo de usuarios en texto plano, para evitar que sean bombardeados por los spammers.
Incluir límites razonables de utilización del sitio para evitar malos usos por parte de usuarios o procesos automáticos (como puede ser los virus). Por ejemplo, es razonable que un sistema de correo electrónico gratuito limite el número de mensajes diarios que puede enviar un usuario, aunque el número máximo sea muy alto; otro ejemplo podemos verlo en Google, que muestra un mensaje de error cuando detecta demasiado tráfico hacia sus servidores desde una única dirección IP.

Seguridad

Conocer la amplia guía de desarrollo OWASP, que cubre la seguridad de sitios web de forma muy completa.
Conocer el fundamento de los ataques de inyección SQL y cómo prevenirlos.
Jamás confiar en los datos introducidos por los usuarios.
Evitar el almacenamiento de contraseñas en texto plano utilizando técnicas criptográficas como hashes y salts.
No intentes utilizar tu magnífico y elaborado sistema de autenticación; es bastante probable que existan fallos impredecibles de los que sólo te darás cuenta después de haber sido hackeado.
Usar SSL/HTTPS en las páginas de identificación de usuarios y, en general, en todas aquellas páginas donde sea introducida información sensible, como datos personales o bancarios.
Evitar el secuestro de sesiones (session hijacking ).
Evitar los ataques XSS (Cross Site Scripting).
Evitar los ataques XSRF (Cross Site Request Forgeries).
Mantener tus sistemas actualizados con los últimos parches disponibles.
Asegurarse de que la información de conexión a la base de datos está almacenada en un lugar lo suficientemente seguro.
Mantener informado sobre las últimas técnicas de ataque y vulnerabilidades que afecten a la plataforma sobre la que trabajas.
Conocer el manual The Google Browser Security Handbook.

Rendimiento

Implementar el cacheado de páginas cuando sea necesario. Comprender y usar apropiadamente los mecanismos de cacheo HTTP.
Optimizar las imágenes. Por ejemplo, no utilizar una imagen de 20 Kb. como mosaico de fondo.
Conocer cómo comprimir el contenido de las páginas con gzip.
Echar un vistazo al sitio Yahoo Exceptional Performance, donde se muestran directrices y buenas prácticas para mejorar el rendimiento de sitios web. Utilizar herramientas como YSlow.
Utilizar la técnica de CSS Sprites para las pequeñas imágenes (como las que encontramos en las barras de herramientas), con objeto de minimizar el número de peticiones HTTP.
Los sitios web de alto tráfico deberían considerar el despliegue de componentes en distintos dominios para optimizar la descarga en paralelo de los mismos.
En general, minimizar el número total de peticiones HTTP necesarias para que el navegador muestre las páginas.

SEO

Utilizar direcciones URL amigables para los buscadores. Por ejemplo, utilizar direcciones del tipo "ejemplo.com/paginas/titulo-del-articulo" en lugar de "ejemplo.com/index.php?page=45".
No utilizar enlaces que digan "pulse aquí". Estarías creando sitio web poco optimizado para buscadores, a la vez que complicando las cosas para los usuarios que utilizan lectores de pantalla.
Crear un mapa del sitio en XML (sitemap).
Utilizar <link rel="canonical" ... /> Cuando tengas múltiples URLs que apunten a un mismo contenido.
Utilizar las herramientas disponibles en www.google.com/webmasters.
Instalar Google Analytics desde el principio.
Conocer cómo funcionan los rastreadores de los buscadores y el archivo robots.txt.
No maquetar con tablas; Google generalmente valorará positivamente el marcado HTML semántico y la maquetación con CSS.
Si tienes contenido no textual en la página, utiliza en el sitemap las extensiones de Google para audio, video, etc. Hay alguna información sobre ello en la respuesta de Tim Farley .

Tecnología

Entender el protocolo HTTP; conocer cosas como GET, POST, sesiones, cookies, y saber lo que significa e implica su naturaleza "sin estado" (stateless).
Escribir el código (X)HTML y CSS conformes a las especificaciones de la W3C, y asegurarse de que validan. El objetivo es evitar las particularidades de los navegadores, a la vez que se facilita enormemente la navegación utilizando browsers no estándar como lectores de pantalla o dispositivos móviles.
Comprender cómo se procesa el código javascript en los navegadores. Mover los scripts al final de las páginas.
Comprender cómo funciona el sandbox de javascript, especialmente si pretendes utilizar iframes.
Asegurarse de que javascript puede ser deshabilitado sin que la página deje de funcionar. AJAX debe ser una extensión, y no la base sobre la que se construya un sitio. Aunque la mayoría de usuarios lo tengan activado, recordar que existen muchos y muy populares dispositivos en los que no funcionará correctamente.
Entender la diferencia entre las reflexiones 301 y 302 (esto también es un aspecto SEO).
Aprender tanto como sea posible sobre la plataforma en la que será desplegado el sitio web en producción.
Considerar el uso de un reseteador de CSS.
Considerar herramientas como jQuery, que oculta muchas de las particularidades de los distintos navegadores utilizando javascript para la manipulación del DOM.

Corrección de errores

Entender que pasarás el 20% del tiempo codificando y el 80% restante manteniéndolo, por tanto codifica apropiadamente.
Configurar un buen sistema de notificación y gestión de errores.
Habilitar sistemas para que los usuarios puedan contactar contigo y trasladarte críticas y sugerencias.
Documentar cómo funciona la aplicación para facilitar el futuro soporte y mantenimiento del sistema.
Poner a funcionar el sistema primero en Firefox y después en Internet Explorer.
Hacer copias de seguridad frecuentes.

Publicado en: Variable not found.

Cómo crear un ControllerFactory personalizado para ASP.NET MVC

2009-07-01T21:33:00.003+02:00

Hace unas semanas, en el post Cambiar la ubicación de las vistas en ASP.NET MVC estuvimos viendo cómo era posible aprovechar la flexibilidad del framework para saltarse las convenciones respecto a la ubicación de los archivos de vistas (.aspx, .ascx y .master).

En esta ocasión vamos a seguir profundizando en los puntos de extensión del framework, centrándonos en la facilidad con la que podemos modificar el ControllerFactory, que es el componente encargado de localizar y crear las instancias de los controladores que deben procesar las peticiones.

Y vamos a ilustrarlo con un ejemplo, en el que desmontaremos otra de las convenciones del framework MVC: el nombre de los controladores. Como sabemos, cuando se recibe una petición que según su ruta debe ser procesada por un controlador llamado XYZ, el motor por defecto intentará instanciar una clase denominada XYZController. Lo que vamos a hacer es retocar este comportamiento para que nuestros controladores puedan denominarse “ControladorDeXYZ”, un nombre mucho más acertado en nuestro idioma.

En este post veremos cómo podemos modificar la forma en que este componente localiza las clases de controladores y adaptarla a nuestras preferencias.

Pero antes, recuerda:

Saltarse las convenciones = malo

Hazlo sólo cuando realmente esté justificado... o por diversión, como es el caso ;-)

Lo que vamos a hacer en el post no es una implementación eficiente, y por supuesto no es válida para un entorno de producción; se trata simplemente de un experimento que demuestra la facilidad para sustituir ciertos componentes del framework, y la flexibilidad que nos aporta. Los conceptos que vamos a tratar pueden ser utilizados con otros fines, como facilitar la inyección de dependencias en controladores, que probablemente veamos en un futuro post.

Y ahora, al tema…

1. El proceso básico de la petición

Antes de empezar la faena, es conveniente estudiar un poco el funcionamiento del framework; así podremos entender mejor qué estamos tocando.

Cuando se recibe una petición, su tratamiento pasa a través de una serie de componentes que se encargan de procesarla a distintos niveles siguiendo el ciclo de vida definido para el framework. Así, una vez que el sistema de enrutamiento ha terminado su tarea detectando la información presente en la URL y determinando, por tanto, su destino, utilizará un manejador MvcHandler para continuar procesando la petición desde el método ProcessRequest().

La porción de código de ASP.NET MVC framework donde se define este método es la siguiente (en el archivo MvcHandler.cs, recordad que el código fuente está disponible en Codeplex):

   1: protected internal virtual void ProcessRequest(HttpContextBase httpContext)

   2: {

   3:     [...]

4:

   5:     // Get the controller type

   6:     string controllerName =

   7:         RequestContext.RouteData.GetRequiredString("controller");

8:

   9:     // Instantiate the controller and call Execute

  10:     IControllerFactory factory =

  11:         ControllerBuilder.GetControllerFactory();

12:

  13:     IController controller =

  14:         factory.CreateController(RequestContext, controllerName);

15:

  16:     if (controller == null)

  17:     {

  18:         throw new InvalidOperationException(...); // Simplificado

  19:     }

  20:     try

  21:     {

  22:         controller.Execute(RequestContext);

  23:     }

  24:     finally

  25:     {

  26:         factory.ReleaseController(controller);

  27:     }

  28: }

Resumidamente, podríamos decir que el sistema procesa las peticiones siguiendo estos pasos:

en primer lugar, obtiene el nombre del controlador desde el contexto de la petición (normalmente desde la ruta). En el código anterior, se guarda en la variable controllerName.
a continuación obtiene una instancia de la factoría de controladores desde la clase ControllerBuilder.
una vez obtenida la factoría según el paso anterior, se le pide mediante una llamada a su método CreateController() que cree el controlador que procesará la petición, enviándole como parámetro el nombre obtenido anteriormente.
y por último, se invoca al método Execute del controlador para que realice las acciones oportunas, liberando al final los recursos utilizados mediante una llamada a ReleaseController.

Como en otras muchas partes del framework, se puede observar en el código anterior la utilización de interfaces en lugar de clases para los elementos que intervienen en el proceso, lo que da pistas sobre la flexibilidad de ASP.NET MVC: casi cualquier elemento puede ser sustituido por otro siempre que se cumpla el contrato definido.

2. La factoría de controladores, a corazón abierto

Visto el procedimiento anteriormente descrito, está claro que la lógica de localización e instanciación del controlador es responsabilidad de las factorías de controladores, y más exactamente del método CreateController() que éstas deben implementar.

ASP.NET MVC utiliza como factoría la clase DefaultControllerFactory de forma predeterminada, sin embargo, nada en el código anterior obliga a que esto sea así. Si logramos crear una nueva factoría que implemente el interfaz IControllerFactory e indicamos al framework que la utilice, ya casi tendremos el trabajo hecho.

En el código de la clase DefaultControllerFactory (la factoría predeterminada), se puede observar que el proceso de creación está compuesto por dos pasos; en el primero de ellos se obtiene el tipo de controlador mediante una llamada a GetControllerType(), mientras que en el segundo se obtiene una instancia de dicho tipo llamando a GetControllerInstance(), que es la que retorna el método:

   1: public virtual IController

   2:     CreateController(RequestContext requestContext, string controllerName)

   3: {

   4:     [...] // Simplificado

   5:     Type controllerType = GetControllerType(controllerName);

   6:     IController controller = GetControllerInstance(controllerType);

   7:     return controller;

   8: }

Dado que lo único que queremos sustituir es el mecanismo de localización, lo más sencillo es crear nuestra nueva factoría, a la que llamaremos AcmeControllerFactory, heredando de DefaultControllerFactory y sobrescribir el método GetControllerType, que afortunadamente es virtual.

El código completo para esta nueva clase es el siguiente:

   1: public class AcmeControllerFactory: DefaultControllerFactory

   2: {

   3:   protected override Type GetControllerType(string controllerName)

   4:   {

   5:       Type r = base.GetControllerType(controllerName);

   6:       if (r == null)

   7:       {

   8:           Assembly current = Assembly.GetExecutingAssembly();

   9:           r = (from t in current.GetTypes()

  10:                where

  11:                (

  12:                        t.Name.Equals("ControladorDe" + controllerName,

  13:                                       StringComparison.InvariantCultureIgnoreCase)

  14:                   && t.IsPublic

  15:                   && !t.IsAbstract

  16:                   && typeof(IController).IsAssignableFrom(t)

  17:                )

  18:                select t).FirstOrDefault();

  19:       }

  20:       return r;

  21:   }

  22: }

Como podemos observar, lo primero que hacemos es intentar localizar el controlador con el nombre que nos llega en el parámetro, pero utilizando el método propuesto por la factoría por defecto, es decir, llamando al método GetControllerType() original. Es decir, vamos a ser al menos algo respetuosos con las convenciones de nombrado existentes ;-) … primero intentaremos localizar el controlador ciñéndonos a ellas, y sólo si no tenemos éxito aplicaremos nuestro propio criterio de nombrado.

Así, ante una petición rutada hacia el controlador Cliente, primero buscaremos la clase ClienteController (según la convención), y si no existe es cuando intentaremos localizar un tipo llamado ControladorDeCliente. Obviamente, podríamos hacerlo al revés, es decir, buscar primero según nuestro criterio de nombrado y si no tenemos éxito buscar utilizando el estándar, o bien ni siquiera intentar esta última opción.

Por tanto, si el método por defecto no es capaz de encontrar un controlador correspondiente a dicha denominación es cuando ejecutamos nuestra lógica adicional, que consiste en buscar en el ensamblado actual, mediante una consulta LINQ, aquellas clases cuyo nombre corresponda con el patrón que pretendemos emplear (“ControladorDe”+controllerName), y que sean públicas, instanciables, e implementen el interfaz IController.

No se han implementado optimizaciones, como la inclusión de un caché, que permitan mejorar el rendimiento en esta consulta. Cada petición deberá recorrer, en el peor de los casos, todo el ensamblado en busca de un controlador apropiado.
Tampoco se ha implementado ningún tipo de resolución de conflictos; si existe más de un controlador con el mismo nombre en distintos namespaces, se retornará el primero que se encuentre.
Eso os lo dejo de deberes ;-)

3. Sustituir la factoría de controladores

Ya tenemos creada la clase AcmeControllerFactory, nuestra propia factoría de controladores, y está lista para entrar en acción. Pero, ¿cómo le decimos al framework que queremos utilizar una factoría de controladores distinta a la predeterminada?

Volvamos a estudiar el código de procesado de las peticiones que vimos anteriormente. Como se puede observar, el IControllerFactory a utilizar es obtenido desde la clase ControllerBuilder:

   1: protected internal virtual void ProcessRequest(HttpContextBase httpContext)

   2: {

   3:   [...]

   4:   // Instantiate the controller and call Execute

   5:   IControllerFactory factory =

   6:             ControllerBuilder.GetControllerFactory();

7:

   8:   IController controller =

   9:             factory.CreateController(RequestContext, controllerName);

  10:     [...]

  11: }

Y aquí de nuevo entra en juego la flexibilidad del diseño de ASP.NET MVC: ControllerBuilder viene preparada para que podamos sustituir muy fácilmente la factoría a instanciar, por lo que podemos indicarle el tipo concreto que queremos que utilice.

En el siguiente código estamos indicando al ControllerBuilder que nuestra factoría por defecto, es decir, la clase encargada de buscar e instanciar los controladores, será AcmeControllerFactory. Como se define en la inicialización de la aplicación (Application_Start del global.asax), todas las peticiones utilizarán esta factoría para crear los controladores:

   1: protected void Application_Start()

   2: {

   3:     RegisterRoutes(RouteTable.Routes);

   4:     ControllerBuilder

   5:         .Current

   6:         .SetControllerFactory(typeof(AcmeControllerFactory));

   7: }

4. Probar que realmente funciona

Podemos comprobar el funcionamiento de todo este invento de forma muy sencilla. Una vez seguidos los pasos anteriores, basta con crear un nuevo controlador que ya atienda a nuestra propia convención de nombrado, como el siguiente:

   1: [HandleError]

   2: public class ControladorDeCliente : Controller

   3: {

   4:   public ActionResult Listar()

   5:   {

   6:       return View();

   7:   }

8:

   9:   public ActionResult Editar()

  10:   {

  11:       return View();

  12:   }

  13: }

Creamos, asimismo, una vista “Listar.aspx” y otra “Editar.aspx” en la carpeta “Views\Cliente” para que el motor pueda localizarlas y podamos ver algún resultado en pantalla. A partir de este momento, ejecutando el proyecto, podremos comprobar cómo si introducimos la URL http://localhost:tupuerto/Cliente/Listar el flujo de ejecución pasará por el método Listar() visto anteriormente. También podemos invocar a la acción Editar(), y el resultado será el esperado.

Y para los perezosos, ahí va el código fuente del proyecto (requiere Visual Studio 2008 o Web Developer Express con SP1 y ASP.NET MVC 1.0):

Publicado en: Variable not found.

Desactivar el inicio en modo diseño de lectura de Word 2003

2009-06-30T23:12:00.001+02:00

Lo sé. Estoy desactualizado... pero me sigue gustando Office 2003, como supongo que ocurre a mucha gente todavía. Y de hecho, continúo creando mis documentos con Microsoft Word 2003.

Sin embargo, a pesar del largo camino que hemos recorrido juntos, aún no he sido capaz de verle sentido al modo diseño de lectura, esa extraña forma de presentar los documentos por defecto al abrirlos, o que podemos activar voluntariamente desde el menú “edición”. ¿A quién se le ocurrió esa idea? ¿Alguien la ha visto útil alguna vez? ¿Tiene, quizás, alguna utilidad oculta que no he sido capaz de intuir en todos estos años?

Bueno, en cualquier caso, podemos conseguir muy fácilmente que no utilice el diseño de lectura en el momento de abrir los documentos, accediendo al cuadro de diálogo de configuración (Herramientas >> Opciones) y desmarcando el check “Permitir el inicio en diseño Lectura”:

Sencillo, ¿eh? Desde luego, no tengo excusa para haber aguantado este odioso comportamiento durante más de un lustro…

Publicado en: Variable not found.

Recopilación de capítulos gratuitos de libros sobre ASP.NET MVC

2009-06-29T00:00:00.006+02:00

He recibido algunos mensajes de lectores de Variable not found que quieren iniciarse en ASP.NET MVC, pero no saben por dónde empezar, y me sugieren que escriba algunos posts que expliquen desde cero este nuevo framework. Posiblemente lo haga algún día, pero mientras tanto, les he recordado que existen recursos gratuitos que pueden ser de mucha utilidad para dar los primeros pasos (e incluso profundizar un poco) en esta tecnología.

Por ejemplo, recientemente han aparecido una gran cantidad de libros sobre ASP.NET MVC, y de la mayoría de ellos se pueden descargar capítulos gratuitos que, además de ayudarnos a decidir cuál de ellos puede ser de nuestro interés, tienen valor por la información que nos pueden aportar. Como siempre, el problema es la dispersión de esta información, por lo que he decidido hacer esta recopilación para tenerlos todos a mano. Conforme vaya descubriendo nuevos ejemplares iré ampliando la lista; y por supuesto, si conocéis alguno que no esté aquí, me lo comentáis y lo añadimos.

Eso sí, todos en inglés, aunque al ser muy técnicos creo que son fáciles de comprender.

	Pro ASP.NET MVC Framework Autor: Steve Sanderson Post de presentación: Now Published Pro ASP.NET MVC Framework (Apress) « Steve Sanderson’s blog Capítulo gratuito: Chapter 2: Your First ASP.NET MVC Application (23 páginas)En este capítulo, el autor muestra muy detalladamente, prácticamente paso a paso, cómo crear nuestra primera aplicación simple con ASP.NET MVC. En primer lugar, crea un proyecto muy básico mediante el cual explica los fundamentos básicos de la programación siguiendo este modelo, y a continuación entra en la creación de una mini-aplicación con entrada de datos, validaciones y lógica simple.
	Professional ASP.NET MVC 1.0 Autores: Scott Hanselman, Rob Conery, Phil Haack y Scott Guthrie Capítulo gratuito: Chapter 1: Nerdinner (192 páginas) Este extenso capítulo describe la creación de un sitio web medianamente complejo, www.nerddinner.com, utilizando gran cantidad de tecnologías relacionadas con el framework MVC como filtros, Ajax, LinqToSql, pruebas unitarias, etc. Muy recomendable, imprescindible.
	ASP.NET MVC 1.0 Quickly Autor: Maarten Balliauw Post de presentación: Announcing my book- ASP.NET MVC 1.0 Quickly Capítulo gratuito: Chapter 2: Your first ASP.NET MVC application (20 páginas) Breve recorrido por el proceso de creación de una aplicación MVC, el sistema de rutas, controladores, vistas y realización de pruebas unitarias. Bastante básico, quizás demasiado “quickly”, pero válido en cualquier caso.
	ASP.NET MVC in Action Autores: Jeffrey Palermo, Ben Scheirman, Jimmy Bogard Post de presentación: Announcing ASP.NET MVC in Action (from Manning) - Jeffrey Palermo (.com) - CodeBetter.Com Recurso gratuito: Getting Started with the ASP.NET MVC Framework (Green Paper – PDF) (18 páginas) (El enlace a este documento te lo envían por correo electrónico tras facilitar tu dirección). Se trata de otra introducción al framework, el sistema de rutas, controladores y vistas partiendo desde cero. Capítulo gratuito: Chapter 9: AJAX in ASP.NET MVC (21 páginas) Interesante capítulo de introducción al uso de la tecnología Ajax sobre ASP.NET MVC utilizando jQuery y los Ajax helpers para intercambiar datos con el servidor.
	ASP.NET MVC Framework Unleashed Autor: Stephen Walther Capítulos gratuitos: el autor ha publicado varios capítulos en su blog, y los retirará en cuanto el libro esté disponible en Amazon, así que daos prisa que los contenidos son excelentes. Chapter 1 - An Introduction to ASP.NET MVC Chapter 2 - Building a Simple ASP.NET MVC Application Chapter 3 - Understanding Controllers Chapter 4 - Understanding Views Chapter 5 - Understanding Models Chapter 6 - Understanding HTML Helpers Chapter 9 - Understanding Routing
	Beginning ASP.NET MVC 1.0 Autores: Simone Chiaretta, Keyvan Nayyeri Capítulo gratuito: Chapter 9: Testing ASP.NET MVC Applications (38 páginas) Interesantísimo capítulo que describe distintas técnicas para la realización de pruebas unitarias de aplicaciones creadas con este framework, incluyendo la creación de mocks, inyección de dependencias en controladores, testeo de rutas y de refilón, algo de TDD.

Publicado en: Variable not found

Control de errores en acciones ASP.NET MVC

2009-06-14T23:59:00.000+02:00

El control de errores en aplicaciones web es fundamental si queremos ofrecer un interfaz robusto y amigable para los usuarios en cualquier situación. No hay nada más frustrante para un usuario que una pantalla de error con contenidos indescifrables y que no le aportan alternativas de salida.

El framework ASP.NET MVC nos ofrece mecanismos de control de errores muy potentes basada en la utilización del atributo HandleError, el cual definirá la vista que será mostrada al usuario cuando se produzca alguna excepción no controlada en el código de los controladores, siempre que en el web.config se haya activado el uso de errores personalizados mediante la propiedad CustomErrors.

En este post vamos a profundizar en el uso del atributo HandleError, comentando cómo se implementa en el controlador, su ámbito de actuación, los parámetros que ofrece y la forma de crear las vistas para mostrar los errores de forma amigable.

El controlador

HandleError puede ser declarado tanto a nivel de clase (controlador) como a nivel de acción. En el primer caso, se establecerá el comportamiento general para todas las acciones del controlador, mientras que en el segundo será aplicable sólo a la acción a la que se asocie el atributo:

// Control de errores a nivel de clase de controlador, 
// que será aplicado a todas las acciones del mismo.
[HandleError()]
public class HomeController : Controller
{
    ...
}

// Control de errores a nivel de acción concreta...
[HandleError(ExceptionType=typeof(ArgumentException), View="ArgumentError")]
public ActionResult Calculate(int a, int b)
{
  ViewData["results"] = calculateSomething();
  return View();
}

En realidad, el comportamiento definido en el atributo HandleError a nivel de clase también se aplicará a los errores generados por las vistas u otros resultados (ActionResult) retornados por los controladores. Es decir, sobre el segundo de los ejemplos anteriores, la vista “ArgumentError” (que existirá en un archivo llamado ArgumentError.aspx) será invocada cuando la excepción ArgumentException sea lanzada bien por el propio controlador, o bien por la vista “Calculate” que retorna por defecto.

Un último detalle sobre esto: el atributo HandleError puede ser especificado tantas veces como necesitemos sobre la misma acción o controlador, indicando comportamientos para distintos tipos de excepción. El atributo que se tendrá en cuenta cuando se produzca un error será el primero que se encuentre cuyo tipo de excepción (parámetro ExceptionType) sea compatible con la excepción lanzada.

El manejador de errores que se empleará en una acción será el primero que corresponda al tipo de excepción producida, teniendo en cuenta tanto los atributos que adornan la acción como los que acompañan a su controlador, y siempre según un orden preestablecido.

Veamos con más detenimiento los parámetros que admite la declaración del atributo.

Parámetros de HandleError

        [HandleError(
            ExceptionType=typeof(DivisionByZero), 
            View="ErrorPersonalizado", 
            Master="MaestraErrores",
            Order = 0)
        ]
        public ActionResult Index()
        ...

ExceptionType permite indicar el tipo de excepción que se pretende controlar. Por defecto, el sistema entenderá que la regla se refiere al tipo base Exception, por lo que se aplicará a todos los errores que se generen, pues todas las excepciones heredan de esta clase.
View, el nombre de la vista que será mostrada al usuario. Por defecto se tomará el valor “Error”, por eso en la plantilla de proyectos ASP.NET MVC ya existe una vista con este nombre.
Master, la página maestra con la que será renderizada la vista, independientemente de lo que tenga declarado ésta.
Order, un valor numérico (por defecto –1, el más prioritario) que indica la prioridad de aplicación de esta regla cuando el sistema encuentre varios atributos HandleError aplicables al mismo elemento y que puedan presentar conflictos. Los valores más pequeños, Por ejemplo, si no se indicara este parámetro en el siguiente caso, el resultado dependería del orden de declaración, lo cual no es demasiado recomendable:
```
[HandleError(Order=10, View="ErrorGenerico")]
public class HomeController : Controller
{
  ...
  [HandleError (ExceptionType=typeof(DivisionByZero),
                View="OperacionIncorrecta", Order=1)]
  public ActionResult Calculate()
  ...
```
Como puede intuirse, esto hará que en caso de producirse una división por cero, se muestre la vista “OperacionIncorrecta” y no la “ErrorGenerico”.

Cada vez que utilicemos HandleError es conveniente tener muy en cuenta la prioridad (definida en la propiedad Order), el alcance (las excepciones a tratar, definidas en la propiedad ExceptionType), así como los valores por defecto en cada caso. Esto evitará comportamientos misteriosos del sistema una vez se produzcan errores en tiempo de ejecución.

Acceso desde la vista a la información del error

Ya hemos comentado anteriormente que la vista que será mostrada a los usuarios cuando se produzca un error será la indicada en el parámetro View del atributo HandleError, o la vista "Error", si este parámetro no es informado. Sea cual sea, el archivo nombredevista.aspx deberá estar localizable por el motor de vistas en el momento de su lanzamiento (por cierto, si no te gustan las ubicaciones por defecto, puedes ver cómo modificar la forma en la que se buscan las vistas en este post).

La vista de un error es una página .aspx normal, como una vista más de la web, pero con la particularidad de que puede recibir información sobre el error que ha provocado su presentación. De hecho, se trata de una vista tipada que hereda de ViewPage<System.Web.Mvc.HandleErrorInfo>, de forma que la propiedad Model será del tipo HandleErrorInfo, clase que nos ofrece completa información sobre el origen del problema:

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
    Inherits="System.Web.Mvc.ViewPage<System.Web.Mvc.HandleErrorInfo>" %>

<asp:Content ID="errorTitle" ContentPlaceHolderID="TitleContent" runat="server">
    Error en el sistema
</asp:Content>
<asp:Content ID="errorContent" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        Ups, se ha producido un ligero inconveniente...
    </h2>
    <p>
        La acción <%= Model.ActionName %>  
        del controlador <%= Model.ControllerName %>
        ha lanzado la excepción <%= Model.Exception.GetType().Name %> con
        el mensaje "<%= Model.Exception.Message %>".
    </p>
</asp:Content>

A pesar de no ser un buen ejemplo como pantalla del error amigable para el usuario ;-), el código anterior ilustra cómo es posible acceder desde la vista a los datos del contexto del error proporcionados por el entorno, y cómo la clase HandleErrorInfo nos ofrece una información sobre la acción en la que se ha lanzado la excepción, el controlador en el que se encuentra la misma, y lo más interesante, nos ofrece en la propiedad Exception la excepción producida, por lo que tendremos acceso a su tipo, descripción e incluso al estado de la pila de llamadas en el momento de producirse el error.

Publicado en: www.variablenotfound.com

Cómo crear un plugin sencillo para Live Writer, paso a paso

2009-06-07T23:52:00.014+02:00

Hace unos días publiqué CodeTag, un sencillo plugin para Windows Live Writer que permite insertar pequeñas porciones de código fuente en línea en los contenidos de los posts. Resumidamente, lo único que hace esta utilidad es envolver entre etiquetas <code> y </code> el texto que tengamos seleccionado en el momento de su utilización, pero evita tener que entrar al modo de edición HTML para hacer estos ajustes.

Basándome en el código fuente de CodeTag (que podéis descargar al final de este post), voy a describir, paso a paso, cómo podemos crear complementos para Writer que nos faciliten un poco las tareas cotidianas de edición.

0. Antes de empezar…

Para poder desarrollar el plugin necesitáis básicamente dos cosas:

en primer lugar, el propio software Live Writer, más que nada porque necesitamos referenciar algunos de sus ensamblados, y por ir probando el complemento durante el desarrollo.
en segundo lugar, Visual Studio 2005 o 2008, aunque sea una edición express . Este desarrollo vamos a realizarlo en C#, pero la traducción a Visual Basic .NET sería trivial.

En este post voy a incluir capturas de pantalla correspondientes a Microsoft Visual C# 2008 Express, que es el único que tengo a mano.

1. Preparación del proyecto

Los plugins para Live Writer son archivos .dll, es decir, ensamblados .NET, que se colocan en el directorio "plugins" de la carpeta de instalación del programa. En mi caso, están en la carpeta C:\Archivos de programa\Windows Live\Writer\Plugins, y si no habéis cambiado las rutas de instalación por defecto, será allí donde los podéis encontrar también. Durante el proceso de arranque, Writer examinará dicha carpeta y cargará los complementos que encuentre en ella.

Lo que vamos a hacer es crear desde Visual Studio un proyecto de librería de clases. Cada vez que compilemos, copiaremos el ensamblado resultante en dicho directorio (veremos cómo podemos automatizar esta tarea) y podremos lanzar Live Writer para comprobar el funcionamiento.

Por tanto, en primer lugar creamos un proyecto de librería de clases como siempre, al que le damos el nombre CodeTag. Obviamente, podéis dar al proyecto el nombre que estiméis conveniente.

Una vez que el IDE crea la estructura, debemos añadir dos referencias al proyecto, que serán necesarias para poder continuar:

La primera referencia es al ensamblado que contiene el API de Live Writer, que podéis encontrar en el directorio de instalación de la herramienta. El archivo a incluir es WindowsLive.Writer.Api.dll .
La segunda es a System.Windows.Forms. Hay que tener en cuenta que Live Writer es una herramienta de escritorio, y esta referencia es importante para poder interactuar con el mismo.

Otro detalle más que nos va a facilitar las cosas: vamos a indicar a Visual Studio que el resultado de la compilación lo copie en el directorio de plugins de Live Writer. Para ello, lo único que tenemos que hacer es acudir a las propiedades del proyecto, pestaña “eventos de generación” e incluir la siguiente orden en el cuadro “línea de comandos del evento posterior a la generación” (obviamente, modificando la ruta si es necesario):

XCOPY /D /Y /R "$(TargetPath)" "C:\Archivos de Programa\Windows Live\Writer\Plugins\"

Ojo, es importante tener en cuenta algo más cuando vayamos a compilar: si Live Writer está abierto, no podremos sobrescribir nuestro plugin con una nueva versión, pues éste se encontrará en uso. En estos casos debemos cerrar el programa antes de copiar el archivo, o antes de compilar.

Con estas operaciones ya tenemos el proyecto listo para empezar a codificar el plugin.

2. Escribimos la clase principal

Un plugin sencillo como este no requiere demasiada programación, pero sí hay que cumplir una serie de requisitos para que se integre correctamente en Live Writer.

En primer lugar, creamos una clase, a la que llamaremos CodeTag, e insertamos el siguiente código:

  public class CodeTag: ContentSource
  {
     public override DialogResult CreateContent(IWin32Window dialogOwner, 
                                               ref string content)
    {
      if (string.IsNullOrEmpty(content))
          content = "YourCodeHere";
      
      content = "<code>" + content + "</code> ";
      return DialogResult.OK;
    }
  }

Como se puede observar, la clase hereda de ContentSource, un tipo definido en WindowsLive.Writer.Api, que sirve como base para la creación de complementos sencillos como el que nos ocupa. Para casos más complejos, que permitieran por ejemplo edición de contenidos bidireccional entre el contenido de la página y un editor personalizado podríamos heredar de SmartContentSource, pero no profundizaremos en ello ahora.

La codificación de la lógica del plugin puede realizarse en varios puntos, dependiendo de la forma en que Writer lo active; en nuestro caso, el complemento se lanzará cuando el usuario presione un botón en la barra lateral o seleccione la opción correspondiente en el menú "insertar", por lo que simplemente deberemos sobrescribir el método CreateContent.

Dicho método recibe dos parámetros. El primero de ellos hace referencia a la ventana activa, que podemos utilizar como "padre" si quisiéramos crear un cuadro de diálogo desde nuestro código. El segundo parámetro contendrá una referencia al texto seleccionado en el momento de lanzar el plugin, pudiendo darse los dos casos que se contemplan en la codificación:

Si la variable content viene vacía o con valor nulo, es que el complemento ha sido lanzado en modo inserción, es decir, no existía ningún texto seleccionado y por lo tanto lo que se pretende es añadir las etiquetas de código para introducir posteriormente contenido. Como puede observarse en el código, lo que se hace en este caso es insertar las etiquetas <code> con un texto arbitrario para que el usuario lo modifique a su antojo más adelante.
En caso contrario, si la variable content trae algún contenido, lo que se hace es rodear éste por la apertura y cierre de la etiqueta <code>.

En ambos casos se retorna un valor DialogResult.OK, que indica a Live Writer que debe insertar el texto contenido en content en la ubicación donde se encuentre el cursor, o bien sustituir el texto seleccionado por el nuevo valor.

3. Añadimos metadatos

Heredar de la clase ContentSource no es el único requisito para que esta sea considerada como un componente de Writer, es necesario adornarla con un conjunto de atributos como los mostrados en el siguiente código:

[WriterPlugin("98497c2b-bbfd-4bd1-b343-226f3c9e766b", "Code Tag",
    Description = "Crea etiquetas <code></code> en el contenido",
    PublisherUrl = "http://www.variablenotfound.com")]
[InsertableContentSource("Etiqueta <code>")]
public class CodeTag: ContentSource
{
  [...]
}

El atributo [WriterPlugin] es el que realmente identifica la clase como plugin de Live Writer. Los parámetros que se le están enviando son los siguientes:

El primer parámetro es un GUID, es decir, un identificador único que debemos generar para el plugin, utilizando este servicio on-line u otras herramientas como la incluida en Visual Studio.
El segundo parámetro es el nombre del plugin. Es la identificación que aparece en el cuadro de diálogo de configuración de complementos de Live Writer.
Description permite añadir una descripción textual ampliada del plugin.
PublisherUrl es una dirección web de referencia al autor. Pura propaganda ;-)

El atributo [InsertableContentsource] indica que el complemento debe aparecer en el menú "insertar" de las barra de tareas de Writer y en el menú principal. El parámetro que le estamos enviando es simplemente el texto que aparecerá en estos menús.

4. Compilamos el proyecto

Con lo hecho hasta el momento ya podemos compilar e intentar probar nuestro complemento. Este procedimiento lo repetiremos varias veces durante el desarrollo, por lo que es posible que nos encontremos a menudo con un error como el siguiente:

Esto simplemente quiere decir que Live Writer está usando CodeTag.dll y no puede ser sobrescrito, por lo que ¡cerrad Live Writer antes de compilar!

Una vez superado este leve impedimento, si aparece, ya podremos comenzar a disfrutar de nuestro plugin. Veremos que aparece en el menú "insertar", con la descripción apropiada, y funcionando correctamente.

Pero vaya, es cierto que en el menú aparece, pero destaca sobre el resto de complementos porque es el único que no tiene un icono, así que habrá que mejorarlo un poco…

5. Añadirle un icono al plugin

Incluir un icono a nuestro complemento le dará sin duda un aspecto más profesional, vamos a ello.

Lo primero que necesitamos es una imagen de 16x16 píxeles, por ejemplo en formato .bmp, que actuará como icono. Como el diseño gráfico decididamente no es lo mío, he creado una imagen muy simple pero creo que bastante ilustrativa de la tarea que realiza el complemento: la propia etiqueta <code> que pretendemos crear.

El archivo debemos incluirlo, para no tener problemas, en el directorio raíz del proyecto, y a continuación, hay que indicar a Visual Studio que dicha imagen será un recurso incrustado (embedded resource) en el ensamblado. Este paso es importante, pues si no se hace correctamente, la imagen no será incluida en la DLL.

A continuación es necesario indicar a Live Writer la imagen a utilizar como icono, lo que se consigue añadiendo un parámetro más (ImagePath) en la definición del atributo [WriterPlugin] con la ruta hacia el fichero que hemos incrustado. Eso sí, no me refiero a la ruta física del archivo .bmp, sino a la representación como espacio de nombres de la misma (por ejemplo, si la imagen se llama logo.bmp y está en (raíz)\recursos, la ruta hacia ella será “recursos.logo.bmp”).

Como en este caso hemos depositado la imagen en el directorio raíz, la declaración de atributos quedará como sigue:

    [WriterPlugin("98497c2b-bbfd-4bd1-b343-226f3c9e766b", "Code Tag",
        Description = "Crea etiquetas <code></code> en el contenido",
        ImagePath = "CodeTag.bmp",
        PublisherUrl = "http://www.variablenotfound.com")]
    [InsertableContentSource("Etiqueta <code>")]
    public class CodeTag : ContentSource
    {
      [...]
    }

Un último apunte relativo a este tema: si al iniciar Live Writer éste es incapaz de localizar el recurso indicado en el parámetro ImagePath, el plugin funcionará, pero aparecerá el siguiente mensaje en el arranque de la aplicación:

6. O, por si no quieres teclear…

… he colgado en SkyDrive el código fuente del proyecto, para el que quiera utilizarlo como base de creación de sus propios complementos, o simplemente para trastearlo un poco.

Requiere, como mínimo, Visual C# 2008 Express, con su correspondiente Service Pack 1.

Publicado en: Variable not found.

Cambiar la ubicación de las vistas en ASP.NET MVC

2009-06-02T23:58:00.000+02:00

El framework ASP.NET MVC utiliza en varios puntos la filosofía que suele denominarse convención sobre configuración, ahorrando tiempo y esfuerzos al desarrollador que decida asumir una serie de normas preestablecidas, a la vez que facilita la homogeneidad y coherencia en las soluciones que las implementen.

Por ejemplo, todos sabemos que las vistas de una aplicación ASP.NET MVC deben encontrarse en la carpeta Views. Si se trata de una vista compartida como puede ser una página maestra, debemos colocarlas en la subcarpeta Shared; en caso contrario, deberá existir una subcarpeta con el nombre del controlador en la que se encontrarán las vistas para las distintas acciones, nombradas igual que éstas. Esto, a la postre, evita que sea el desarrollador el que tenga que decidir dónde ubicar dichos archivos y configurar el sistema para que sea capaz de localizarlos cuando sean necesarios: simplemente deberá seguir la convención preestablecida.

Pero, ¿qué ocurre cuando estas convenciones no encajan con nuestras necesidades o preferencias?

En este post voy a describir cómo es posible modificar la ubicación de las vistas en una aplicación ASP.NET MVC 1.0, saltándonos las convenciones establecidas por el framework. Pero sobre todo, ojo:

Saltarse las convenciones = malo

Hazlo sólo cuando realmente esté justificado... o por diversión, como es el caso ;-)

1. Cómo localiza ASP.NET MVC las vistas

Cada vez que el framework necesita localizar una vista, por ejemplo después de ejecutar una acción cuyo resultado indica que debe mostrarse al usuario una página, recorre los directorios donde, por convención, se supone que debe estar. Esta información se encuentra definida a nivel de código en el constructor de la clase WebFormViewEngine, es decir, en el motor de vistas Webforms que se utiliza por defecto en ASP.NET MVC. Su definición es la siguiente (recordad que está disponible el código fuente del framework):

public class WebFormViewEngine : VirtualPathProviderViewEngine
{
  [...]
  public WebFormViewEngine()
  {
    base.MasterLocationFormats = new string[]
    { 
      "~/Views/{1}/{0}.master", 
      "~/Views/Shared/{0}.master"
    };
      
    base.ViewLocationFormats = new string[] 
    { 
      "~/Views/{1}/{0}.aspx", 
      "~/Views/{1}/{0}.ascx", 
      "~/Views/Shared/{0}.aspx", 
      "~/Views/Shared/{0}.ascx" 
    };
    base.PartialViewLocationFormats = base.ViewLocationFormats;
  }
  [...]
}

Como se puede observar, existen tres propiedades en el motor del vistas, heredadas de su antecesor, que indican los directorios donde se encuentran los archivos con la definición del interfaz:

MasterLocationFormats es un array con las rutas en las que se buscarán sucesivamente las páginas maestras. En el código puede verse que por defecto el sistema intentará localizar las masters en ~/Views y ~/Views/Shared; los parámetros {0} y {1} corresponden al nombre de la master y del controlador que están siendo buscados, respectivamente.
Es importante tener en cuenta que el valor de esta propiedad sólo se aplica cuando se establece desde el código la página maestra con la que debe ser mostrada una vista.
ViewLocationFormats contiene las rutas donde se intentarán localizar las vistas. En la implementación por defecto, puede verse cómo el framework intenta localizar primero en ~/Views/{1} (recordad que este parámetro se sustituirá por el nombre del controlador) y luego en ~/Views/Shared una página .aspx o .ascx con el nombre de la vista (parámetro {0}).
Por último, PartialViewLocationFormats indica las carpetas donde se deberán buscar las vistas parciales. Por defecto, se buscarán en los mismos directorios que las vistas normales.

2. Lo que pretendemos

Una vez visto en qué se basa el framework para localizar las vistas, vamos al ataque. Nuestra intención es saltarnos las convenciones creando una nueva estructura de carpetas para las mismas, como la que puede observarse en la imagen lateral. Existirá un directorio raíz, llamado "Interfaz", en el que podemos encontrar dos subdirectorios: "Vistas" y "Masters". En ellos almacenaremos, respectivamente, las vistas y las páginas maestras de nuestra aplicación.

La estructura de carpetas del proyecto será, por tanto, diferente a la propuesta por las plantillas de Visual Studio. Además, no tiene demasiado sentido, desde el punto de vista práctico, pero nos valdrá como ejemplo.

En los siguientes apartados vamos a ver dos formas distintas de conseguirlo.

3. Cómo lograrlo

La forma más sencilla de conseguir reemplazar las rutas de búsqueda de las vistas es, sin duda, alterar el contenido de las propiedades del motor descritas en el primer punto (MasterLocationFormats, ViewLocationFormats y PartialViewLocationFormats).

Esto puede conseguirse introduciendo el siguiente código en la inicialización de la aplicación, en el archivo global.asax:

public class MvcApplication : System.Web.HttpApplication
{
  [...]
  protected void Application_Start()
  {
      ReplacePaths();   // Reemplaza las rutas en el View Engine actual
      RegisterRoutes(RouteTable.Routes);
  }

  private void ReplacePaths()
  {
      WebFormViewEngine eng = ViewEngines.Engines[0] as WebFormViewEngine;
      eng.MasterLocationFormats =
          new string[] { 
              "~/Interfaz/Masters/{0}.master"
          };
       eng.ViewLocationFormats =
          new string[] { 
              "~/Interfaz/Vistas/{0}.aspx",
              "~/Interfaz/Vistas/{0}.ascx"
          };
       eng.PartialViewLocationFormats = eng.ViewLocationFormats;
  }
  [...]
}

Como se observa en el código anterior, en el método ReplacePaths() en primer lugar se obtiene una referencia al motor de vistas por defecto, que sabemos que es del tipo WebFormViewEngine. Después, modificamos las propiedades para introducir las rutas que nos interesan. Tan simple como eso.

Es obvio que de esta forma estamos realizando una actualización destructiva de las propiedades. Si quisiéramos mantener las localizaciones por defecto del WebFormViewEngine pero añadir nuevas ubicaciones de búsqueda deberíamos copiar el contenido original del array, añadirle las rutas adicionales, y establecerlo en las propiedades.

Veamos otra forma de conseguir lo mismo.

4. Cómo lograrlo, toma 2

ASP.NET MVC framework ha sido diseñado desde sus orígenes con la extensibilidad en mente. Prácticamente cualquiera de sus comportamientos puede ser personalizado sustituyendo componentes como si se trataran de piezas de un mecano.

Una de las posibilidades de extensión incluidas en la plataforma es la sustitución del motor de vistas que utiliza para componer los interfaces de usuario. Esto, llevado al extremo, permite la utilización de motores distintos al proporcionado por defecto (WebForms) y utilizar alternativas como NHaml, Spark, Brail, o NVelocity, entre otros.

Pero nosotros no iremos tan lejos. Para cumplir con nuestros objetivos simplemente necesitamos crear y registrar en el sistema un nuevo motor de vistas que herede de WebFormViewEngine y reemplace la inicialización de las propiedades que definen la localización de las vistas.

El nuevo motor, al que llamaremos AcmeViewEngine, será algo como lo siguiente:

 public class AcmeViewEngine : WebFormViewEngine
 {
     public AcmeViewEngine()
     {
         MasterLocationFormats =
             new string[] { 
                 "~/Interfaz/Masters/{0}.master"
             };

         ViewLocationFormats =
             new string[] { 
                 "~/Interfaz/Vistas/{0}.aspx",
                 "~/Interfaz/Vistas/{0}.ascx",
             };

         PartialViewLocationFormats = base.ViewLocationFormats;
     }
 }

Y ahora sólo nos faltaría registrar el motor de vistas en ASP.NET MVC framework, tarea que podemos realizar en el global.asax, así:

protected void Application_Start()
{
   ReplaceViewEngine(); // Registra el nuevo View Engine
   RegisterRoutes(RouteTable.Routes);
}

private void ReplaceViewEngine()
{
   ViewEngines.Engines.Clear();
   ViewEngines.Engines.Add(new AcmeViewEngine());
}

Observad que antes de añadir el nuevo motor de vistas a la colección estamos vaciándola (llamando a su método Clear()), lo cual asegurará que nuestro AcmeViewEngine será el utilizado por la plataforma.

5. Conclusión

Como ya he comentado al principio, saltarnos las convenciones no es buena idea. Por ejemplo, un daño colateral de romper con la convención propuesta por el framework MVC para la localización de las vistas es que Visual Studio no será capaz de proporcionarnos la función que nos permite abrir la vista asociada con una acción seleccionando la opción “Go to View” del menú contextual, o intentará insistentemente crear las nuevas vistas (con la opción “Add View”) en las carpetas en las que deberían encontrarse según la convención.

Pero en cualquier caso, es un ejercicio interesante para conocer las interioridades de este framework y comprobar de primera mano la flexibilidad con la que ha sido implementado.

Si lo deseas, puedes descargar el código fuente de los ejemplos (requiere Visual Studio 2008 o Web Developer Express con SP1 y ASP.NET MVC 1.0):

Publicado en: www.variablenotfound.com

Sintoniza la onda de Google

2009-05-31T23:45:00.000+02:00

No sé si será un cambio en la forma de comunicarse a través de la red, pero sin duda es una idea conceptualmente atractiva: unir en una única plataforma todas las conversaciones que mantenemos sobre Internet… pero entendiendo el término conversación de una forma más amplia de lo habitual.

Mensajes de correo, foros, mensajería instantánea, compartición de imágenes y documentos, posts, comentarios en blogs, sus respuestas, twits, intercambio de mensajes vía redes sociales, documentos colaborativos en tiempo real, wikis, juegos… todo cabe en Google Wave, la criatura en la que los hermanos Lars y Jens Rasmussen (famosos por haber creado Google Maps) llevan trabajando más de dos años, y que fue presentada hace unos días en el Google I/O.

Básicamente, Google Wave es la respuesta a una serie de preguntas que se formularon al comienzo del proyecto:

¿cómo sería el correo electrónico si hubiera sido inventado hoy, y no hace más de tres décadas?
si en el fondo todo es comunicación, ¿por qué tenemos que diferenciar entre emails, chats, conversaciones o documentos?
¿es posible que un único modelo de comunicaciones sea capaz de unir de forma sencilla los sistemas web que utilizamos hoy?
dado que las herramientas de comunicación habituales son meros reflejos digitales de los procesos del mundo analógico (email vs. correo tradicional, mensajería instantánea vs. teléfono…), ¿cómo sería un sistema diseñado para beneficiarse de las capacidades de las redes y ordenadores actuales, en lugar de limitarse a emular los medios no electrónicos?

Pero no penséis que Google Wave sólo es una aplicación más, como GMail o Google Reader, capaz de hacer de forma diferente cosas que ya se podían hacer antes. Se trata de un trío compuesto por tres elementos: producto, plataforma y protocolo:

El producto, que es la aplicación cliente que mostraron en el evento, muy al estilo Google, desde la que se pueden iniciar y gestionar nuestras conversaciones. Se trata de una aplicación HTML5 construida sobre Google Web Toolkit, que todavía sólo está disponible para un grupo reducido de desarrolladores, y que han confirmado que será open source.
La plataforma, el conjunto de APIs y especificaciones que permiten integrar Wave en cualquier sistema web, o extenderlo mediante la creación de Robots o Gadgets .
El protocolo, Google Wave Federation Protocol , aún en borrador, se encuentra definido en una serie de documentos que detallan su arquitectura, el modelo de datos, las comunicaciones entre clientes y servidores y, en general, toda la información necesaria para que puedan existir distintas implementaciones del servicio. De hecho, el producto de Google será únicamente una implementación de referencia.

Esta nueva forma de colaboración gira en torno a la figura del Wave, que según dicen los entendidos es una mezcla entre una conversación y un documento sobre los que trabajan de forma colaborativa una serie de participantes. Y la verdad, tiene un aire a las conversaciones de GMail, y también a la edición multiusuario de Google Docs, pero va bastante más allá. Un Wave puede contener mensajes, comentarios, anotaciones y elementos más avanzados, como mapas, encuestas, juegos, o tomar datos desde otras aplicaciones y servicios, como blogs, twits, foros, sistemas de seguimiento de errores, y todo integrado dentro de un mismo contexto (la conversación). La cuestión es tener agrupadas todas las comunicaciones relativas a un mismo tema en un único punto.

Además, los participantes no tienen que ser necesariamente humanos, es decir, por ejemplo es posible que en un Wave intervenga un robot que se encargue de ir traduciendo los mensajes al idioma de cada participante, lo cual abre unas posibilidades inimaginables. En el vídeo al que hago referencia abajo hay una demo de Rosy, un robot traductor muy apañado que realiza estas funciones.

Otro aspecto interesante es la facilidad para organizar la información, y me ha gustado mucho la capacidad de temporalizar las conversaciones, de forma que sea posible reproducir la secuencia de aportaciones realizadas al Wave por cada uno de los participantes.

Si tenéis una horita y media libre, y podéis haceros de coca-cola y palomitas, no os perdáis el vídeo de la presentación del producto de mano de sus responsables. Muy divertida y sin duda espectacular. Eso sí, si no domináis el inglés, tendréis que activar vuestro modo de inferencia lingüística, ese que se encarga de rellenar con la imaginación las expresiones que no llegamos a comprender ;-)

Se dice que Wave estará disponible a finales de año. En este momento, lo más que podéis hacer es solicitar que os tengan en consideración cuando lo abran al público.

Enlaces interesantes:

Más enlaces interesantes (en inglés):

Publicado en: Variable not found.

Plugin para insertar etiquetas `en Live Writer`


2009-05-26T23:48:00.001+02:00
Desde hace unos meses estoy escribiendo las entradas de Variable Not Found desde Windows Live Writer, y la verdad es que estoy encantado con esta herramienta. Pero como nadie es perfecto, me he encontrado con ocasiones en las que tengo que acceder y retocar a mano el código fuente de la página para que el resultado sea el que pretendo.
  Me suele ocurrir, por ejemplo, cuando inserto pequeñas porciones de código fuente en mitad de una frase, pues siempre me ha gustado rodear este tipo de textos por las correspondientes etiquetas <code> y </code>. Esto, además de ser un marcado semánticamente más correcto, me permite modificar la forma en que se muestra desde CSS, estableciéndole, por ejemplo, una tipografía de ancho fijo.
  Para no tener que hacerlo más a mano, he creado un pequeño plugin para Live Writer que permite seleccionar un texto y envolverlo automáticamente por dichas etiquetas, y he pensado que quizás pueda serle útil a alguien más.
   La criatura se llama “CodeTag”, y la podéis descargar desde el enlace de más abajo. Para instalarla en vuestro Live Writer, simplemente debéis descomprimir el archivo y copiar CodeTag.dll a la carpeta Plugins dentro del directorio donde hayáis instalado la herramienta (en mi caso, la ruta completa es C:\Archivos de programa\Windows Live\Writer\Plugins). 
  Seguidamente, reiniciáis Live Writer y listo, veréis que en la barra lateral y el menú “insertar” ha aparecido la opción “Etiqueta <code>”, que os permitirá realizar el proceso descrito anteriormente.
  En breve publicaré un post describiendo paso a paso cómo se crea un plugin para Live Writer, y veréis lo sencillo que resulta hacer estas pequeñas herramientas de productividad.
   Publicado en: Variable not found



Compilar las vistas en ASP.NET MVC
2009-05-24T23:45:00.004+02:00
 El código introducido en las vistas ASP.NET MVC pueden ser fuente de problemas en tiempo de ejecución debido a que, por defecto, no se compilan con el proyecto, sino cuando el sistema necesita mostrarlas por primera vez. Es decir, es perfectamente posible que errores de codificación en un archivo .ASPX no sean detectados hasta el momento de su ejecución, provocando un YSOD de los de toda la vida.
  Un ejemplo. Imaginemos una vista tipada (en un archivo .ASPX) en la que hemos incluido el siguiente código, perfectamente válido…
  
  
  <%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
         Inherits="System.Web.Mvc.ViewPage<Persona>" %>
[...]
<h2>Datos personales</h2>
Nombre: <%= this.Model.Nombre %>

[...]
… perfectamente válido mientras la clase Persona tenga una propiedad que se llame Nombre. Si eliminamos esta propiedad o simplemente cambiamos su nombre, la refactorización automática del IDE no se realizará sobre el código de la vista, y se generará un error en ejecución en cuanto intentemos acceder a ella, es decir, estaremos llevando a tiempo de ejecución problemas propios del tiempo de compilación.Afortunadamente, ASP.NET MVC framework incluye un mecanismo que nos permite forzar la compilación de las vistas y, así, detectar estos problemas de forma temprana, antes de poner el sitio en producción. 
Para activarlo, lo primero que hay que hacer es abrir el archivo del proyecto (.csproj o .vbproj) con cualquier editor de textos, como el block de notas, localizar en las primeras líneas el comienzo de la sección PropertyGroup, e insertar justo después la declaración que habilita la compilación de las vistas:
<PropertyGroup>
   <MvcBuildViews>true</MvcBuildViews>
   [...]
</PropertyGroup>   
Ojo a un detalle: es posible que en algún punto del archivo del proyecto exista una declaración que anule la anterior así: <MvcBuildViews>false</MvcBuildViews>. Debéis eliminar esa línea, pues de lo contrario no se activará esta característica.
Acto seguido, debemos asegurarnos de que exista el siguiente código cerca del final del archivo; en mi caso ya existía, pero si no es así debemos insertarlo, por ejemplo, justo antes del cierre del documento (en la línea anterior a </Projects>).
<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
   <AspNetCompiler VirtualPath="temp" 
                   PhysicalPath="$(ProjectDir)\..\$(ProjectName)" /> 
</Target>
Una vez guardado el archivo, recargamos la solución en Visual Studio, y listo. Eso sí, a partir de este momento tendremos que esperar un poco más durante la generación del proyecto, pero la seguridad que aporta bien vale la pena.
Fuente: Compile Views in ASP.NET MVC - Stack Overflow
Publicado en: Variable not found.




     



Cómo depurar selectores jQuery
2009-05-20T23:38:00.000+02:00
El gran K. Scott Allen comentaba hace unas semanas en OdeToCode un pequeño truco que puede resultar de utilidad cuando tengamos un código jQuery que no funcione correctamente.
  Como comenta el autor, la mayoría de los problemas con jQuery se deben a un uso incorrecto de los potentes selectores, así que lo que propone es el uso de la consola javascript incluida en algunas herramientas como Firebug (para Firefox) o las propias herramientas de desarrollo incluidas en Internet Explorer 8 (geniales, por cierto).
  Esta consola permite en ambos casos introducir instrucciones javascript de forma directa, que serán ejecutadas en el contexto de la página actual como si formaran parte del código de las mismas. Por tanto, en aquellas páginas en las que se incluido jQuery, será posible ejecutar llamadas y selecciones a lo largo del DOM y observar el resultado de forma interactiva.
  En la imagen adjunta se ve cómo podemos ir realizando consultas con selectores e ir observando sus resultados con Firebug. Hay que tener en cuenta que la mayoría de operaciones de selección con jQuery retornan una colección con los elementos encontrados, por eso podemos utilizar length para obtener el número de coincidencias. Pero no sólo eso, podríamos utilizar expresiones como la siguiente para mostrar por consola el texto contenido en las etiquetas que cumplan el criterio: 
  $("div > a").each(function() { console.log($(this).text()) })

Y más aún, si lo que queremos es obtener una representación visual sobre la propia página, podemos alterar los elementos o destacarlos con cualquiera de los métodos de manipulación disponibles en jQuery, por ejemplo:
$("a:contains['sex']").css("background-color", "yellow")
La siguiente captura muestra el resultado de una consulta realizada con las herramientas de desarrollo incluidas en Internet Explorer 8: 

En fin, un pequeño truco para facilitarnos un poco la vida.

Fuente: What I Do When My jQuery Code Doesn’t Work




     



Y todavía otras 101 citas célebres del mundo de la informática
2009-05-18T05:48:00.001+02:00
Ha transcurrido un año desde que publiqué mi recopilación de citas célebres del mundo de la informática, como continuación de la serie iniciada originalmente por el amigo Timm Martin en DevTopics. Desde entonces he ido anotando todas las citas que me llamaban la atención, hasta que por fin he llegado al número mágico y puedo publicar el tercer post de la serie que tanto me divierte. Que aproveche.
  Desarrollo de software
  1. “Cualquier problema en ciencias de la computación puede ser solucionado con otra capa de indirección… pero usualmente creará otro problema”    
    -- David Wheeler 
  2. “Hay únicamente dos problemas realmente duros en informática: el primero es la invalidación de cachés, y el segundo darles nombres apropiados a las cosas”    
    -- Phil Karlton 
  3. “Una documentación voluminosa es parte del problema, no de la solución”    
    -- Tom DeMarco 
  4. “Compatibilidad significa repetir deliberadamente los errores de otras personas”    
    -- David Wheeler
  5. “Cuando te enfrentes a la ambigüedad, no caigas la tentación de adivinar”    
    -- Guido van Rossum 
  Usuarios y usabilidad
  6. “‘Usuario’ es la palabra que usan los profesionales de la informática cuando quieren decir idiota”    
    -- Dave Barry 
  7. “Me siento frente a la condenada pantalla del ordenador todo el día, varios días, semana tras semana, y pienso: tío, si pudieras tan sólo encontrar el interruptor de encendido…”    
    -- Zachary Good 
  8. “Un error frecuente que comete la gente cuando intenta diseñar algo a prueba de tontos es que subestiman la ingenuidad de los tontos“    
    -- Douglas Adams 
  9. “Estas máquinas no tienen sentido común; todavía no han aprendido a pensar, sólo hacen exactamente lo que se les ordena, ni más ni menos. Este hecho es el concepto más difícil de entender la primera vez que se utiliza un ordenador”    
    -- Donald Knuth 
  10. “Ordenador, mata a Flanders”  
    -- Homer Simpson 
  11. “La última prueba que me gustaría proponerle para medir la usabilidad es realmente simple: si el sistema fuera una persona, ¿cuánto tiempo tardarías en golpearle en la nariz?”    
    -- Tom Carey 
  12. “La base de usuarios de sistemas criptográficos fuertes se reduce a la mitad por cada pulsación de tecla o click de ratón requerido para hacerlos funcionar“    
    -- Carl Ellison 
  Errores
  13. “Cuidado con los errores en el código anterior; sólo he demostrado que es correcto, no lo he probado”    
    -- Donald Knuth 
  14. "No hay en nuestro software un número significativo de errores que un número significativo de usuarios necesite ver resueltos"    
    -- Bill Gates, 1995 
  15. “Cometer fallos es humano. Y echarle las culpas a un ordenador, aún más”    
    -- Robert Orben 
  16. “Si tu proyecto no funciona, busca en la parte que no pensaste que fuera importante“    
    -- Arthur Bloch 
  17. “No me culpes. Solo soy un intérprete. No sabia que el enchufe de energía llegaba a esta terminal de computadora”   
    -- C3PO, después de freír a R2D2
  18. “Cualquier bug lo suficientemente avanzado es indistinguible de una funcionalidad”    
    -- Rich Kulawiec
  19. “A veces vale más la pena quedarse en la cama el lunes que pasar el resto de la semana depurando el código que creaste el lunes”    
    -- Dan Salomon
  20. “Una solución elegante a un problema incorrecto no resuelve nada”  
    -- M. Bryce 
  21. “Nunca cometo errores estúpidos. Sólo errores inteligentes, muy inteligentes”    
    -- Dr. Who 
  22. “Hay una cosa peor que un programa que no funciona como debe: un programa que funciona como no debe”    
    -- Bob Archer 
  Trabajo en equipo
  23. “Siempre he encontrado los planes inútiles, pero la planificación es indispensable”    
    -- Dwight Eisenhower 
  24. “Eliminar a un mal desarrollador del equipo de un proyecto es a menudo más productivo que añadir un desarrollador bueno”  
    -- Tom DeMarco 
  25. “Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente”    
    -- Ley de Brooks 
  26. “Un grupo es un montón de gente en un ascensor. Un equipo es un montón de gente en un ascensor, ¡pero con el ascensor roto!”    
    -- Bonnie Edelstein 
  27. “Ninguno de nosotros es tan inteligente como todos nosotros”    
    -- Ken Blanchard 
  Conocimiento
  28. “Mi definición de un experto en cualquier campo es una persona que sabe lo suficiente sobre la realidad como para estar asustado”  
    -- P.J. Plauger 
  29. “La inteligencia consiste no sólo en el conocimiento, sino también en la destreza de aplicar los conocimientos en la práctica”    
    -- Aristóteles 
  30. “Hay tres maneras de adquirir sabiduría: primero, por la reflexión, que es la más noble; segundo, por imitación, que es la más sencilla; y tercero, por la experiencia, que es la más amarga”  
    -- Confucio 
  31. “Los elementos más comunes en el universo son el hidrógeno y la estupidez”    
    -- Harlan Ellison 
  32. “Tengo que dejar de hablar. Ya te he contado más de lo que sé”    
    -- Wolf Logan 
  33. “Un experto es una persona que ha cometido todos los errores posibles en un determinado terreno”    
    -- Niels Bohr 
  34. “No podemos solucionar problemas usando el mismo razonamiento que usamos cuando los creamos”    
    --Albert Einstein 
  35. “No hay parche que corrija la estupidez”  
    -- Kevin Mitnick 
  36. “Solía pensar que el cerebro era el órgano más importante del cuerpo, hasta que me di cuenta de quién era el que me estaba diciendo eso”  
    -- Emo Philips 
  Inteligencia artificial
  37. “Dentro de 30 años tendremos los medios tecnológicos para crear una inteligencia superhumana… Algún tiempo después, la era humana habrá terminado”    
    -- Vernor Vinge 
  38. “Algunos se preocupan de que la inteligencia artificial pueda hacer que nos sintamos inferiores, pero entonces cualquiera en su sano juicio debería sentir complejo de inferioridad cada vez que mirase a una flor”    
    -- Alan Kay 
  39. “No le atribuyas cualidades humanas a los ordenadores. No les gusta”    
    -- anónimo
  40. “Lo siento, Dave. No puedo hacer eso”    
    -- HAL 9000 
  41. “La inteligencia artificial nunca podrá competir con la estupidez natural”    
    -- anónimo 
  42. “El esfuerzo de utilizar las máquina para emular el pensamiento humano siempre me ha parecido bastante estúpido. Preferiría usarlas para emular algo mejor”    
    -- Edsger Dijkstra 
  Creatividad
  43. "Yo lo inventé, Bill lo hizo famoso"    
    -- David Bradley, el hombre que inventó el Control-Alt-Suprimir
  44. “No te preocupes de que la gente te pueda robar una idea. Si es original, se la harás tragar a la fuerza”    
    -- Howard Aiken, creador del Mark I. 
  45. “Hacer lo simple complicado es bastante corriente; hacer lo complicado simple, sorprendentemente simple, eso es la creatividad”    
    -- Charles Mingus 
  Desarrolladores
  46. “Los hombres de verdad no hacen copias de seguridad. Publican sus cosas en servidores FTP públicos, y dejan que el resto del mundo las copie”    
    -- Linus Torvald, desarrollador del Linux 
47. “Cuídate de los programadores que llevan destornillador”   
    -- Leonard Brandwein 
  48. “Los programadores hablan sobre desarrollo los fines de semana, vacaciones y en las comidas, no por falta de imaginación, sino porque su imaginación revela mundos que otros no pueden ver”    
    -- Larry O'Brien y Bruce Eckel en "Thinking in C#"
  49. “Los programadores de verdad siempre confunden Navidad con Halloween porque saben que Oct 31 == Dec 25”  
    -- Andrew Rutherford 
  50. “Un buen programador es aquél que mira a los dos lados antes de cruzar una carretera con un único sentido”    
    -- Doug Linder 
  51. "Sólo por diversión."    
    -- Linus Torvalds, refiriéndose a las razones para haber creado Linux. 
  Codificación
  52. “Ese código es demasiado inteligente como para tener esperanzas de que funcione correctamente”    
    -- Tim Peters 
  53. “Las guías de estilo de codificación son como los traseros: todo el mundo tiene uno, y a nadie le gusta el de los demás”    
    -- Eric Warmenhoven 
  54. “Reutilizar porciones de código es como tomar frases de textos de otras personas e intentar escribir con ellas un artículo en una revista”    
    -- Bob Frankston 
  55. “La programación orientada a objetos ofrece una vía sostenible de escribir código spaghetti”    
    -- Paul Graham 
  56. “Cuanto antes comiences a codificar, más tiempo tardarás en finalizar el programa”    
    -- Roy Carlson 
  Empresa
  57. “El objetivo es entregar código limpio que funcione… ahora”    
    -- Kent Beck 
  58. “No puedes simplemente preguntar a los clientes lo que quieren e intentar dárselo. Algo después, cuando lo hayas construido, ellos querrán otra cosa”    
    -- Steve Jobs 
  59. “Si pagas con cacahuetes, sólo puedes aspirar a contratar monos”  
    -- Sir James Goldsmith
  60. “La primera regla de cualquier tecnología utilizada en los negocios es que la automatización aplicada a una operación eficiente magnificará la eficiencia. La segunda es que si la automatización se aplica a una operación ineficiente, magnificará la ineficiencia”    
    -- Bill Gates 
  61. “Walt Disney creó su imperio con un ratón. Igual que Steve Jobs”    
    -- San Francisco Chronicle, Febrero de 2004 
  Lenguajes
  62. “C fue diseñado para ser escrito; Ada para ser leído”    
    -- Jean Ichbiah 
  63. “Java es C++, pero sin pistolas, cuchillos ni garrotes”    
    -- James Gosling
  64. “Perl es otro ejemplo de cómo cubrir una pequeña necesidad a corto plazo, y que se convierte en problema real a la larga”    
    -- Alan Kay 
  65. “APL es un lenguaje de sólo escritura. Puedo escribir programas en APL, pero luego no puedo leer ninguno de ellos”    
    -- Roy Keir 
  66. “El lenguaje C++ intenta proteger de Murphy, no de Maquiavelo”    
    -- Damian Conway 
  67. “Si C++ me ha enseñado algo es que por muy consistente que sea un sistema, no significa que no sea un trabajo de Satanás”    
    -- Andrew Plotkin 
  68. “SQL, Lisp y Haskell son los únicos lenguajes de programación que he visto en los que uno pasa más tiempo pensando que escribiendo”    
    -- Philip Greenspun 
  Predicciones
  69. “Hacer predicciones es muy difícil, especialmente sobre el futuro”    
    -- Niels Bohr 
  70. ”La inteligencia artificial, ESTÁ AQUÍ”    
    -- Portada del Business Week, July 9, 1984 
  71. “He viajado a lo largo y ancho de este país, y hablado con la gente más preparada, y puedo asegurar que el proceso de datos es una moda pasajera que pasará antes de fin de año”    
    -- El editor responsable de libros de negocios de Prentice Hall, 1957. 
  72. “Los Macintosh usan un dispositivo apuntador llamado “ratón”. No hay razón alguna para que la gente quiera usar esas cosas”     
    -- John C. Dvorak, 1984 
  73. “El casette doméstico está acabando con la música”    
    -- Campaña de la BPI (Industria Fonográfica Británica), en 1980 
  74. “Los americanos han necesitado el teléfono, pero nosotros no. Tenemos gran cantidad de mensajeros”    
    -- Sir William Preece, Ingeniero jefe de la British Post Office, 1878. 
  75. “Las máquinas serán capaces, en los próximos veinte años, de hacer cualquier trabajo que una persona pueda hacer”    
    -- Herbert Simon, 1965 
  Internet
  76. “Navegar en Internet es como el sexo; todo el mundo presume de hacerlo mucho más de lo que realmente lo practican. Pero en el caso de Internet, mucho más todavía”   
   -- Tom Fasulo
  77. “En el ciberespacio todo el mundo es anónimo 15 minutos”  
    -- Graham Greenleaf 
  78. “Si imagináis un colegio con niños que saben leer y escribir, pero los profesores no, tendréis una metáfora de la era de la información en la que vivimos”    
    -- Peter Cochrane. 
  79. “Internet es la primera creación de la humanidad que la propia humanidad no entiende, el más grande experimento de anarquía que jamás hemos conocido”    
    -- Eric Schmidt 
  80. “En internet nadie sabe que eres un perro”    
    -- Peter Steiner, chiste en The New Yorker, Julio de 1993 
  81. “El email es algo maravilloso para aquellos cuyo rol en la vida es estar encima de todo. Pero no para mí, que estoy debajo. Lo que hago requiere horas de estudio y concentración ininterrumplible”  
    -- Donald Knuth 
  82. “Internet es la biblioteca más grande del mundo. Lo que ocurre es que todos los libros están por el suelo”    
    -- John Allen Paulos
  Ordenadores
  83. “La memoria es como un orgasmo: es mucho mejor cuando no tienes que simularla”    
    -- Seymoure Cray 
  84. “Imagínate que todos los jueves tus zapatos explotaran cuando te los atas de la forma habitual. Esto es lo que nos ocurre siempre con los ordenadores, pero a nadie se le ocurre quejarse”    
    -- Jef Raskin 
  85. “Los ordenadores son imbéciles”       
    -- Peter Drucker 
  86. “Ningún ordenador ha sido jamás diseñado para ser consciente de lo que está haciendo; pero la mayor parte del tiempo, nosotros tampoco lo somos”    
    -- Marvin Minsky 
  87. “La mejor forma de acelerar un ordenador es aquella que lo lanza a 9.8 m/s2”    
    -- anónimo 
  88. “La paridad es para los granjeros”  
    -- Seymoure Cray, por qué no incluyó sistemas de corrección de errores en el CDC 6600. 
  89. “He aprendido que muchos granjeros compran ordenadores”    
    -- Seymoure Cray, por qué incluyó sistemas de corrección de errores en el CDC 7600. 
  90. “El hombre todavía puede apagar el ordenador. sin embargo, tendremos que esforzarnos mucho para conservar este privilegio”    
    -- J. Weizembaum 
  Calidad del software
  91. “La seguridad, como la corrección, no es una característica adicional”    
    -- Andrew S. Tanenbaum 
  92. “La calidad es gratis, pero sólo para aquellos que están dispuestos a pagar mucho por ella”    
    -- Tom deMarco 
  93. “Un sistema que se base en la fiabilidad de un ordenador, no es fiable. Si se basa en la fiabilidad del ser humano, tampoco”    
    -- Una de las leyes de Troutman 
  Complejidad
  94. “Si piensas que la criptografía es la solución a tu problema, es que realmente no conoces tu problema”    
    -- Peter G. Neumann 
  95. “La generación de números aleatorios es demasiado importante como para ser dejada al azar”    
    -- Robert R. Covey 
  96. "Cualquiera que considere métodos aritméticos para producir dígitos aleatorios está, por supuesto, en pecado mortal"    
    -- John von Neumann 
  97. “La simplicidad es un prerequisito para la fiabilidad”    
    -- E. W. Dijkstra 
  Videojuegos
  98. "Como cualquier programador de juegos sabe, los 3 tipos básicos de alimento son Fritos, Cheetos y Doritos"    
    -- Satoru Iwata (presidente de Nintendo) 
  99. “La historia en un juego es como la de una película porno. Se espera que esté ahí, pero no es eso lo que importa”    
    -- John Carmack 
  100. “Siempre me he preguntado si existe una versión Hezbolá del buscaminas en la que obtienes puntos si haces explotar el tablero en el primer movimiento”    
    --James Lileks
  101. “Los videojuegos no tienen ninguna influencia sobre los niños. Es decir, si el Pac-Man hubiese influenciado a nuestra generación, estaríamos todos corriendo en salas oscuras, masticando píldoras mágicas y escuchando músicas electrónicas repetitivas”    
    -- Atribuida a Kristian Wilson, de Nintendo Inc; reivindicada por Marcus Brigstocke
  Y no te pierdas las entregas anteriores:
     101 citas célebres del mundo de la informática
    Otras 101 citas célebres del mundo de la informática 
 
  Publicado en: www.variablenotfound.com




     



yUML, generación de diagramas UML al vuelo
2009-05-12T23:05:00.000+02:00
 Tobin Harris ha puesto en marcha un curioso e interesante servicio, al que ha denominado yUML, cuyo propósito es facilitar la generación al vuelo de diagramas UML a partir de una concisa descripción expresada en un sencillo lenguaje específico.
  Pero además de la generación automática del diagrama UML, que ya tiene mérito de por sí, llama la atención que esto puede realizarse desde una etiqueta (X)HTML <img> a la que se le envía la especificación como parámetro, generándose en tiempo real una imagen con el diagrama correspondiente. Por ello, está especialmente indicado para autores de blogs, wikis o contenidos web que deseen introducir muy fácilmente estos diagramas en sus creaciones.
  En los siguientes ejemplos se muestran la especificación y la imagen generada de un diagrama de clases y uno de casos de uso, respectivamente. Como podréis comprobar, la especificación es bastante legible directamente.
  Diagrama de clases
  Especificación: [Company]<>-1>[Location], [Location]+->[Point]
  
  Código fuente para su inserción en una página:
  <img src="http://yuml.me/diagram/class/[Company]<>-1>[Location], [Location]+->[Point]" />

Una curiosidad es que si en la dirección insertamos la palabra “scruffy”, el sistema generará un diagrama como si hubiese sido dibujado a mano, en un estilo mucho más informal: 
<img src="http://yuml.me/diagram/scruffy/class/[Company]<>-1>[Location], [Location]+->[Point]" />

Diagrama de casos de uso
Especificación: [User]-(Login), [User]-(Logout), (Login)<(Reminder), (Login)>(Captcha)
 
Código fuente para su inserción en una página:
<img src="http://yuml.me/diagram/usecase/[User]-(Login), [User]-(Logout), (Login)<(Reminder), (Login)>(Captcha)" />
Si prefieres simplemente descargar el diagrama para subirlo a tu web, opción bastante prudente hasta que se pueda confiar en la fiabilidad y disponibilidad del servicio, desde el mismo sitio web del producto podemos generar la imagen introduciendo la especificación textual; a partir de ahí podremos copiarla y pegarla sobre nuestra herramienta de edición, o salvarla en nuestro equipo para enviarla a su ubicación definitiva.
Si bien todavía yUML está en pruebas y es algo limitado (sólo soporta diagramas de clases y de casos de uso), me ha parecido muy interesante tanto la idea como la implementación del servicio.

Publicado en: Variable not found




     



Plantillas de proyectos ASP.NET MVC 1.0 para NUnit
2009-05-11T23:45:00.000+02:00
Joe Cartano, perteneciente al Visual Web Development Team de Microsoft, ha publicado en el blog oficial (Visual Web Developer Team Blog) un post anunciando que ha actualizado la plantilla que permite crear directamente proyectos ASP.NET MVC con tests unitarios NUnit.
  Así, una vez instalado, al crear un proyecto de tipo ASP.NET MVC nos aparecerá un cuadro de diálogo como el siguiente, en el que se nos brindará la oportunidad de crear en la solución un proyecto de pruebas unitarias utilizando NUnit:
  
  Para los poseedores de algunas de las versiones profesionales de Visual Studio 2008, esta ventana no es nueva, puesto que por defecto ya se incluyen los proyectos de tests propios de Microsoft, pero sí lo es para la versión express del IDE, que no incluye el framework de pruebas y en el que había que crear el proyecto a mano.
  El proyecto, que se crea automáticamente, realiza 27 tests sobre la plantilla original de proyectos ASP.NET MVC, y pueden servir como base para seguir creando nuestro propio conjunto de pruebas:
   
  La plantilla se instala descargando el archivo .zip cuyo enlace encontraréis en el post original y ejecutando, si es necesario con un usuario con privilegios de administrador, el script installNUnit.cmd disponible en el raíz del directorio donde lo hayáis descomprimido.
  Para que todo vaya bien, debéis contar con NUnit previamente instalado en vuestro equipo. Pero ojo, las plantillas están preparadas para la versión 2.4.8.0 y la versión actual es la 2.5.0.9122, por lo que puede que no os funcionen bien si estáis a la última.
  En este caso, es necesario tocar a mano los archivos de plantillas. Podéis seguir estos pasos:
     Descargad el archivo de plantillas desde el blog del Visual Web Developer Team.
    Descomprimidlo sobre cualquier carpeta.
    En los subdirectorios CSharp y Visual Basic encontraréis un archivo llamado MvcApplication.NUnit.Tests.zip. Son las plantillas para cada uno de esos lenguajes.
    El interior de dicho zip está el archivo de proyecto (MvcApplication.NUnit.Test.vbproj en el caso de Visual Basic, MvcApplication.NUnit.Test.csproj en C#). Descomprimid sólo estos archivos y buscar en ambos la cadena “2.4.8.0” y sustituirla por la versión de NUnit que tengáis instalada (en mi caso, “2.5.0.9122”). Al acabar, actualizad de nuevo el .zip con el archivo que acabáis de editar.
    Ejecutad el script de instalación installNUnit.cmd.
 
  Publicado en: Variable not found.




     



Ya van tres años sin saber nada de la variable
2009-05-10T23:46:00.002+02:00
 El pasado 8 de mayo, además de conmemorarse el nacimiento de la Coca-Cola, se cumplían tres años desde que publiqué el primer post en este blog. Y me sigue pareciendo que fue ayer, cómo pasa el tiempo…
  Como en otras ocasiones, es un bonito momento para recapitular y comentar lo que ha ido ocurriendo por aquí desde entonces.
  Durante la celebración del segundo cumpleaños hice una distinción de dos periodos en la historia de Variable not found, que os resumo:
     Año 1: la travesía del desierto (mayo 2006 - mayo 2007), periodo caracterizado principalmente por la ausencia prácticamente total de visitantes al blog, por aquellos tiempos disponible a través de la dirección jmaguilar.blogspot.com. Y no exagero, observad el registro de visitas de los primeros meses, y tened en cuenta que yo mismo también visitaba la página:       
      
  
Aprovecho para introducir un mensaje de aliento para los que estéis en esta situación ahora, empezando un blog: no os desaniméis, ni aun viendo este desastre. Con un poco de esfuerzo todo puede cambiar. El desierto también tiene su fin.       
  
    Año 2: el despegue (mayo 2007 - mayo 2008), durante el cual se produjeron múltiples novedades, como la adquisición del dominio variablenotfound.com, la difusión de feeds a través de, el por aquél entonces magnífico, Feedburner, la creación del diseño actual, y la inclusión en agregadores y comunidades como Planeta Código, Planet WebDev y Geeks.ms.       Este segundo año lo acabamos con un incremento del 2.500% en el número de visitas (la verdad, tampoco lo tenía muy difícil partiendo desde cero ;-)), y lo que me parecía más increíble, 380 suscriptores.
   
 
  Y siguiendo esta línea, el año que hemos acabamos ahora podríamos describirlo como:
  Año 3: la consolidación (mayo 2008 – mayo 2009)
  Aunque ha sido un año sin grandes cambios, Variable not found ha seguido creciendo. Obviamente no en las proporciones anteriores, pero sí ha mostrado un aumento considerable tanto de visitantes como de suscriptores.
  Respecto a las visitas a la web, hay que destacar los siguientes datos:
     las visitas, en general, han aumentado cerca de un 40%, así como el número de usuarios únicos absolutos. Hay que tener en cuenta que durante este último año no se han producido meneos espectaculares como el año anterior, no han pasado de meneillos, por lo que la subida de visitas en global tiene bastante mérito. 
    También se han incrementado ligeramente el número de páginas vistas por visita, y el tiempo medio en la página. 
    El tráfico dirigido desde buscadores se han incrementado en un 75% desde el periodo anterior. Esto podría entenderse como que el blog está logrando un posicionamiento importante en estos motores, probablemente debido a la antigüedad, a las referencias externas y a los propios contenidos. 
    Curiosamente, ha disminuido el número de visitantes nuevos en proporción a los que repiten, lo que implica que aumenta el número de usuarios que han visitado el blog más de una vez. 
    Los comentarios, como manda la tradición, siguen siendo escasos: la media no llega a dos comentarios por cada post publicado. Nada que objetar en esto, soy el primero al que le cuesta la misma vida comentar algo en blogs ajenos que sigo con asiduidad. Es cierto que me gustaría obtener más feedback y opiniones de los lectores, pero entiendo que no sea así. 
 
  En cuanto a las suscripciones, siguen siendo uno de los datos que más me están sorprendiendo, y muy gratamente. En estos momentos, a pesar de los cambios de humor de Feedburner, hemos llegado ya a alcanzar los 650 suscriptores.
  Y sinceramente, este es uno de los datos que más valoro. La temática tan específica del blog hace que los destinatarios de los contenidos, principalmente desarrolladores, sean una minoría, y conseguir que un número tan alto de personas decidan voluntariamente añadirte de alguna forma a sus fuentes favoritas es todo un honor y, sin duda, motivo de orgullo.
  En el aspecto económico, sigo arrasando con los ingresos por AdSense. El mes pasado, junto con el cheque mensual me enviaron una caja de bombones, con una tarjeta de felicitación firmada por el mismísimo Sergey Brin…
  … vaya, parece que me había quedado dormido otra vez ;-D. Pues no, de momento sigo recaudando centimillos a un ritmo lamentable, pero bueno, ¿quién dijo que esto de bloguear se hacía por dinero?
  Lo que considero mi recompensa es lo que estoy aprendiendo. Cada tema tratado, ejemplo, referencia, cada comentario, cada mensaje privado recibido, me aportan una nueva oportunidad para ampliar conocimientos. Si esto lo unimos al placer de comunicar y de compartir los descubrimientos, ya tenemos un buen conjunto de motivaciones que animan a seguir trabajando en el blog.
  Pero aún falta algo, sin duda lo más importante: vosotros. Los que estáis ahí leyendo, enviando comentarios o mensajes, añadiendo valor a las entradas, los que le dais sentido a todo esto. Repito lo que ya comenté en el post en el que celebraba el primer aniversario:
     Os puedo asegurar que he disfrutado escribiendo cada post, pero las alegrías han venido con cada comentario, con cada visita, con cada referencia.
 
  Muchas gracias a todos, y espero que sigáis por aquí, ayudándome a buscar la variable.
  Publicado en: Variable not found




     



NDepend, analiza a fondo tu código
2009-05-03T23:40:00.002+02:00
Existen numerosas aplicaciones que permiten analizar nuestros desarrollos con el objetivo final de incrementar la calidad de los mismos. FxCop, por ejemplo, es capaz de analizar los ensamblados y avisarnos cuando se encuentra con incumplimientos de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers). También hace tiempo comenté por aquí la disponibilidad de  Microsoft Source Analysis for C#, una herramienta que se centra en el código fuente y el cumplimiento de reglas de codificación.
  Ahora, gracias al ofrecimiento de Patrick Smacchia, lead developer del producto, he podido probar NDepend, una herramienta de análisis de código de la que había oído hablar y que va mucho más allá que las citadas anteriormente.
  La principal misión de NDepend es ayudarnos a incrementar la calidad de nuestros sistemas desarrollados con .NET mediante el análisis de sus ensamblados y código fuente desde distintas perspectivas, como la complejidad de sus módulos, el tamaño de los mismos, las interdependencias entre ellos, etc. Es decir, a diferencia de otros analizadores, su objetivo no es avisarnos de aspectos como la utilización de convenciones de codificación (aunque también puede hacerlo), o el uso de buenas prácticas de diseño, sino ayudarnos a determinar, por ejemplo, cuándo ponemos en peligro la mantenibilidad y evolución de un sistema debido a la complejidad  o al fuerte acoplamiento de algunos de sus componentes, por citar sólo algunos criterios.
  El entorno gráfico
  VisualNDepend es el entorno gráfico de la herramienta, y nos ofrece un entorno de trabajo muy potente e intuitivo, aunque durante los primeros minutos pueda resultar algo complejo debido a la cantidad de información mostrada.
  Iniciar el análisis de un sistema es muy sencillo; una vez seleccionado el ensamblado, conjunto de ensamblados o proyecto a estudiar, el sistema realiza el análisis, del cual se obtiene un informe bastante completo, basado en web, sobre el mismo (podéis ver un ejemplo de informe en la página del producto). En él se recogen:
     métricas de la aplicación, entre las que encontramos el número de líneas de código, comentarios, número de clases, métodos, etc., así como datos estadísticos relativos a la complejidad, extensión y estructura del código. 
    métricas por ensamblado, donde se refleja, por cada uno de los ensamblados que componen la solución, datos sobre su tamaño, grados de cohesión, acoplamiento, y otros aspectos relativos a su complejidad e interdependencia. 
     vista de estructura (captura de la derecha) que muestra la distribución de componentes, la granularidad y su complejidad relativa según el tamaño de los bloques visualizados. 
    diagrama de abstracción e inestabilidad, que posiciona cada ensamblado en función del número de clases abstractas e interfaces que presenta y su dependencia del resto de elementos. 
    relación entre ensamblados, que detalla las interdependencias entre ensamblados del proyecto, los posibles ciclos, así como un posible orden de generación. 
    consultas y restricciones CQL, que realiza una serie de consultas predefinidas sobre los ensamblados y el código que nos ayuda a detectar una infinidad de problemas en nuestros desarrollos, desde aspectos relativamente simples como el exceso de métodos en clases o el incumplimiento de ciertas convenciones de nombrado, hasta problemas en la cobertura de los tests generados con NCover o Visual Studio Team System. 
 
  Pero lo mejor del entorno gráfico no es poder generar un análisis en formato web para poder consultarlo más adelante, de hecho esto puede conseguir también con la aplicación de consola que incluye NDepend. Lo mejor son las fantásticas herramientas interactivas que nos permiten navegar a través de nuestras aplicaciones, cambiar de vista, ampliar información sobre cualquier elemento, y realizar consultas en tiempo real, siempre ofreciendo unos resultados muy claros y visuales, como:
   
     diagrama de dependencias entre todo tipo de elementos, como clases, espacios de nombres, o ensamblados. Resulta muy útil, además, configurar el tamaño de los bloques, el grosor del borde y el de las flechas de unión para que sean proporcionales a la complejidad, tamaño y una larga lista de criterios.
     matriz de dependencias, que muestra de forma visual las relaciones de utilización entre espacios de nombres, tipos, métodos o propiedades, con posibilidad de ir ampliando información. 
    comparación entre ensamblados, mostrándonos los cambios producidos entre, por ejemplo, dos versiones de una misma librería o aplicación.
    navegación avanzada por el código a través del uso del menú contextual que facilita la rápida localización de referencias, directas e indirectas, hacia y desde un método, propiedad o tipo existente.
    enlace con Reflector, una herramienta indispensable, con la que se integra perfectamente gracias a su plugin.
 
   
  CQL (Code Query Language)
  Sin duda, una de las características más interesante que tiene NDepend es el soporte del lenguaje de consulta CQL (Code Query Language), que nos ofrece la posibilidad de tratar nuestro código y ensamblados como si fuesen una gigantesca base de datos sobre la que podemos realizar consultas de forma muy natural.  Las posibilidades que esto ofrece son tan amplias que prácticamente todas las funcionalidades de la aplicación están basadas en órdenes CQL prediseñadas que acompañan al producto, aunque podemos crear todas las consultas personalizadas que necesitemos, como por ejemplo:
/* Obtiene los métodos que escriben una propiedad */
SELECT METHODS WHERE IsDirectlyWritingField "Model.Cliente.Nombre"

/* Obtiene métodos que acceden incorrectamente a los
   datos desde la capa de interfaz
*/
SELECT METHODS FROM NAMESPACES "Interfaz" WHERE IsDirectlyUsing "MySql.Data"

/* Obtiene los 10 métodos con más líneas de código */
SELECT TOP 10 METHODS ORDER BY NbLinesOfCode DESC

/* Obtiene los métodos considerados "peligrosos" según su complejidad ciclomática */
SELECT METHODS WHERE CyclomaticComplexity > 20


Además de consultas CQL cuyo resultado podremos observar de forma directa tanto visualmente como en forma de listado, es posible incluir restricciones (WARN) que hará que el sistema nos alerte durante el análisis de un proyecto que cumpla las condiciones especificadas. Por ejemplo, la siguiente restricción nos avisará cuando exista un cierto tufillo a complejidad excesiva en un método (que haya sido definido con más de 10 parámetros):
WARN IF Count > 0 IN  SELECT METHODS WHERE NbParameters > 10
Estas consultas pueden ser añadidas (en la versión Pro) e integradas en los análisis, así como modificar las existentes, de forma que el producto puede ser personalizado a nuestras convenciones o necesidades específicas. 
Otra posibilidad es incluir dentro del código de un ensamblado las restricciones que deseamos que se cumplan, expresándolas en lenguaje CQL embebido en un atributo de tipo CQLConstraint aplicado a sus elementos:
Afortunadamente existe mucha información disponible en la web sobre el lenguaje CQL, y consultas que nos muestran cómo sacarle el máximo partido.
Instalación e integraciones
NDepend se distribuye en formato .zip, y que puede ejecutarse directamente una vez descomprimido el contenido sobre una carpeta. La licencia, una vez obtenida, es un archivo XML firmado digitalmente que debemos colocar en el directorio de la aplicación, y listo.
 
Ya en ejecución, desde el menú “options” es posible configurarlo para que se integre con Visual Studio 2005, 2008 y como he comentado anteriormente, con el magnífico Reflector, con el que hace una excelente pareja.
Asimismo, es posible utilizarlo en sistemas como MSBuild y NAnt, facilitando así su uso en entornos de integración continua y montaje automatizado, para los que ofrece librerías 
Finalmente, he de aclarar que NDepend es una aplicación comercial, aunque dispone de una versión limitada gratuita utilizable por universidades, desarrolladores open source e incluso, durante un tiempo determinado, de prueba en proyectos comerciales. 
En cualquier caso, no dudéis en probarlo: os dará un control sobre vuestro código difícil de conseguir con otras herramientas.

Publicado en: www.variablenotfound.com




     



Palabras malditas
2009-05-01T19:40:00.002+02:00
Huye como del diablo de aquél que utilice demasiadas veces las palabras:
     Necesitamos
    Debemos
    No podemos
    Sencillo
    Simplemente
    Sólo
    Rápido
 
  … y especialmente si las utiliza en el mismo párrafo.
  (Del clásico Four Letter Words –need, must, can’t, easy, just, only, fast- publicado en Signals vs Noise).
Publicado en: www.variablenotfound.com




     



El hombre que inventó el Control-Alt-Suprimir
2009-04-26T23:47:00.000+02:00
  La combinación de teclas Control-Alt-Suprimir lleva con nosotros prácticamente desde el principio de los tiempos ayudándonos a escapar de callejones sin salida. Y como muchas otras pequeñas cosas de la vida, tiene su curiosa historia por detrás.
  David Bradley era uno de los doce ingenieros que trabajaron en el diseño del IBM PC original a principios de los años 80, implementando el código de la ROM BIOS.
  El objetivo inicial era crear una combinación de teclas exclusivamente para que los desarrolladores y escritores técnicos pudieran resetear el ordenador en caliente, de forma rápida, puesto que el apagado manual requería la espera de algunos segundos antes de volver a encenderlo para evitar daños a la fuente de alimentación, y cuando esto había que repetirlo muchas veces al día, como era el caso, la pérdida de tiempo era considerable. 
  De hecho, al principio ni siquiera se pensaba en trasladar esta función a los usuarios finales de estos ordenadores, pero finalmente resultó tan útil y ahorraba tanto tiempo que difundió y popularizó rápidamente entre los usuarios.
   La combinación original de teclas era Control-Alt-Escape, pero pensaron que de esa forma alguien podía pulsarlas accidentalmente al encontrarse todas en el lado izquierdo del teclado. Por ello, finalmente se decantaron por una secuencia que era imposible, en los teclados de entonces, reproducir con una única mano. Había nacido el Control-Alt-Suprimir, y para muchos, un icono cultural de nuestros tiempos.
  David Bradley también es famoso por la frase que tanto hizo reír a casi todos durante la celebración del 20 aniversario del IBM PC:
     “Yo lo inventé, pero Bill lo hizo famoso”
 
  
  Bradley se retiró en 2004, tras cerca de 29 años trabajando en IBM.
  Publicado en: www.variablenotfound.com




     



ASP.NET MVC: trece preguntas básicas
2009-04-19T22:25:00.002+02:00
 En marzo de 2008 publiqué un post en el que se recogían respuestas a diez preguntas básicas sobre el framework ASP.NET MVC, que por aquellos entonces se encontraba todavía en una versión muy preliminar, la Preview 2. 
Más de un año después, coincidiendo con el reciente lanzamiento de la versión 1.0, voy a actualizar el contenido y las preguntas conforme a la evolución de los desarrollos y a lo que he podido profundizar en el tema desde entonces.
  Las cuestiones que trataré son las siguientes:
     Empecemos desde el principio, ¿qué es MVC? 
    ¿Qué ventajas tiene el uso del patrón MVC? 
    ¿Qué es ASP.NET MVC framework? 
    ¿Es el primer framework MVC creado para .NET? 
    Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework? 
    Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET? 
    ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms? 
    ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC? 
    ¿Se puede utilizar ASP.NET Ajax con el framework MVC? 
    ¿Se puede utilizar VB.NET con ASP.NET MVC? 
    ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework? 
    ¿Qué tipo de tecnologías puedo utilizar en las vistas? 
    ¿Es ASP.NET MVC framework software libre? 
 
  1. Empecemos desde el principio, ¿qué es MVC?
 Aunque de forma algo simplista, podríamos definir MVC como un patrón arquitectural que describe una forma de desarrollar aplicaciones software separando los componentes en tres grupos (o capas):      El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia. 
    La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos interacción con éste. 
    El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno. 
 
  MVC son las siglas de Modelo-Vista-Controlador, y se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo.
  Puedes encontrar más información en: 
     Wikipedia, Modelo-Vista-Controlador 
    Documentos originales de definición de MVC, de Trygve M. H. Reenskaug, en Xerox (¡año 1978!)  
    Tutorial de Java, Arquitectura MVC 
    Model-View-Controller Web presentation pattern en MSDN 
 
  2. ¿Qué ventajas tiene el uso del patrón MVC?
 Como siempre, esto de enumerar ventajas es algo subjetivo, por lo que puede que pienses que falta o sobra alguna (¡dímelo!). En un primer asalto podríamos aportar las siguientes:      Clara separación entre interfaz, lógica de negocio y de presentación, que además provoca parte de las ventajas siguientes. 
    Sencillez para crear distintas representaciones de los mismos datos. 
    Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD). 
    Reutilización de los componentes. 
    Simplicidad en el mantenimiento de los sistemas. 
    Facilidad para desarrollar prototipos rápidos. 
    Los desarrollos suelen ser más escalables. 
 
 Pero bueno, también se pueden citar algunos inconvenientes:      Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC. 
    La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de modelos más simples como Webforms. 
    La distribución de componentes obliga a crear y mantener un mayor número de ficheros. 
 
  3. ¿Qué es ASP.NET MVC Framework?
   Es un framework, un entorno de trabajo cuya primera versión acaba de ver la luz, creado por Microsoft con objeto de ayudarnos a desarrollar aplicaciones que sigan la filosofía MVC sobre ASP.NET.
  Además del conjunto de librerías (ensamblados) que proporcionan las nuevas funcionalidades a nivel de API, incluye plantillas y herramientas que se integran en Visual Studio 2008 (tanto en la versión Express de Visual Web Developer como en sus hermanas mayores) para facilitarnos un poco las cosas.
  Una vez instalado el marco de trabajo (que puedes iniciar desde aquí o desde el Web Platform Installer), Visual Studio mostrará un nuevo tipo de proyecto (ASP.NET MVC Web Application) que nos permitirá crear el esqueleto básico de un proyecto de este tipo. Y ya para cuando estemos en faena, el entorno ofrece multitud de utilidades para hacer nuestro trabajo más fácil, como la herramienta de creación de vistas automáticas, el desplazamiento entre controladores y vistas, o plantillas para la definición de controladores, entre otras.
  4. ¿Es el primer framework MVC creado para .NET?
  No, ni el único. Existen multitud de frameworks MVC para ASP.Net, como MonoRail, Maverick.Net, ProMesh.Net y muchos otros.
  5. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?
  No necesariamente. Puedes seguir desarrollando aplicaciones como hasta ahora, con Webforms. Si así lo decides, este nuevo framework no te afectará nada; simplemente, ignóralo.
     De todas formas, ya que has leído hasta aquí, permíteme un consejo: aprende a utilizar ASP.NET MVC framework. Después podrás decidir con conocimiento de causa si te conviene o no.
 
  6. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?
   En absoluto. Son simplemente dos filosofías diferentes para conseguir lo mismo, ¡páginas web!
  La tecnología de Webforms es muy útil para asemejar el desarrollo de aplicaciones web a las de escritorio, ocultando la complejidad derivada del entorno desconectado y stateless (sin conservación de estado) del protocolo HTTP a base de complejos roundtrips, postbacks y viewstates, lo que nos permite crear de forma muy productiva formularios impresionantes y que el funcionamiento de nuestra aplicación esté guiado por eventos, como si estuviéramos programando Winforms.
  Sin embargo, esta misma potencia a veces hace que las páginas sean pesadas y difícilmente mantenibles, además de dificultar enormemente la realización de pruebas automatizadas. Y por no hablar de comportamientos extraños cuando intentamos intervenir en el ciclo de vida de las páginas, por ejemplo para la carga y descarga de controles dinámicos.
  ASP.NET MVC propone una forma distinta de trabajar, más cercana a la realidad del protocolo y, curiosamente, más parecida a cómo se hacía unos años atrás, cuando controlábamos cada byte que se enviaba al cliente o se recibía de éste. No existen, por tanto, conceptos como el mantenimiento del estado en el viewstate, ni el postback, ni nos valdrán los controles de servidor basados en estas características, que son la mayoría. Sin embargo, dado que el framework está creado sobre ASP.NET, será posible utilizar páginas maestras, codificar las vistas en un .aspx utilizando C# o VB.NET, usar los mecanismos de seguridad internos, control de caché, gestión de sesiones, localización, etc.
  7. ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?
  En mi opinión, probablemente no se trate de decidirse por una u otra tecnología, sino de conocer ambas y utilizar la más apropiada en cada momento. Hay muchos aspectos a tener en cuenta, por citar algunos:
     los conocimientos y experiencia del equipo de desarrollo 
    la necesidad de usar controles o sistemas preexistentes 
    la madurez del framework 
    el futuro de la tecnología 
    la importancia de ventajas propias de MVC 
    el tipo de sistema que se pretende construir 
 
  Vamos a reflexionar sobre cada uno de estos puntos, y la decisión os la dejo a vosotros. ;-)
  El equipo de desarrollo
  
  La tecnología de formularios web (Webforms) permite el desarrollo rápido de aplicaciones (RAD) a través de diseñadores visuales con los que es posible componer una página compleja y definir el comportamiento del interfaz a golpe de ratón, puesto que el framework se encarga de realizar parte del trabajo duro, como el mantenimiento del estado entre peticiones, convertir propiedades de controles en código HTML y CSS, o incluso generar scripts que realicen determinadas tareas en cliente. De hecho, siguiendo este modelo es posible crear aplicaciones para Internet sin tener apenas idea de las particularidades inherentes al desarrollo web, lo que permite que muchos programadores procedentes del mundo del escritorio puedan ser productivos muy rápidamente, aunque sea a costa de generar páginas mucho más pesadas y con un código de marcado complejo.
  No hay que olvidar que para determinado tipo de aplicaciones, los Webforms son una buena opción, tanto como lo han sido hasta ahora. Por tanto, si el equipo de desarrollo tiene ya experiencia creando aplicaciones con esta tecnología y no poseen grandes conocimientos sobre programación web de más bajo nivel ni experiencia previa trabajando con el patrón MVC, deberíamos pensárnoslo antes de dar el salto a ASP.NET MVC, puesto que la productividad, al menos inicialmente, va a caer.
  ASP.NET MVC requiere un conocimiento más profundo del entorno web y sus tecnologías subyacentes, puesto que a la vez que ofrece un control mucho más riguroso sobre los datos que se envían y reciben desde el cliente, exige una mayor responsabilidad por parte del desarrollador, ya que deberá encargarse él mismo de mantener el estado entre peticiones, maquetar las vistas, crear las hojas de estilo apropiadas, e incluso los scripts. Esto, sin embargo, no difiere mucho de la forma de trabajar unos años atrás, y es posible que en el equipo de trabajo haya desarrolladores experimentados que se sientan incluso más cómodos trabajando a este nivel que utilizando abstracciones como las provistas por ASP.NET Webforms.
  Controles y módulos reutilizables
  Otro aspecto a valorar antes de dar el salto a ASP.NET MVC es que existe una altísima probabilidad de que no podamos utilizar sistemas o componentes que hayamos desarrollado previamente, lo cual redundará en los tiempos de desarrollo y productividad del equipo de trabajo. No nos valdrán los controles de servidor, ni las plantillas de proyectos, ni los generadores de código, y en muchos casos ni siquiera la herencia de editor (que por muy antipatrón que sea seguro que acostumbramos a utilizar).
  Probablemente en breve dispondremos de componentes para ASP.NET MVC generados por la propia comunidad de desarrolladores, ya sea en forma de helpers (métodos estáticos de generación de código en cliente), en forma de vistas parciales (por ejemplo en archivos .ASCX) y nos permitan reutilizar código, o incluso como controles de servidor (ya se puede ver algo de eso en el ensamblado MVC Futures, disponible en CodePlex). 
     Puedes ver un ejemplo de helper en el post “Helper para desplegables enlazados con ASP.NET MVC y jQuery”.
 
  Madurez del framework
  ASP.NET MVC es un framework recién salido del horno, por lo cual su adopción implica ciertos riesgos, ya superados por los veteranos Webforms.
  En primer lugar, es bastante probable que durante un primer periodo de adopción comiencen a surgir bugs, agujeros de seguridad y otros problemas que podrán hacer tambalear los cimientos de los sistemas que utilicen este marco de trabajo. También es cierto que dada la disponibilidad del código fuente del mismo y su relativa simplicidad frente a los formularios web, los inconvenientes que puedan aparecer podrían ser rápidamente subsanados.
  La madurez también se hace patente en la cantidad y calidad de información disponible. ASP.NET MVC, aunque cuenta con una comunidad de desarrolladores bastante entusiasta, son una minoría comparándola con su veterana competencia.
  Y lo mismo ocurre con el número ingente de componentes y controles reutilizables disponibles para Webforms. Dado que no son compatibles con el framework MVC, se parte de una situación de clara desventaja frente a éstos, aunque como comentaba anteriormente seguro que con el tiempo este aspecto irá mejorando.
  Consideraciones sobre el futuro de la tecnología
  Si lo que te preocupa es el futuro de los Webforms, has de saber que Microsoft va a seguir dándoles soporte y mejorándolos, como no podía ser de otra forma. Por tanto, de momento no es necesario que bases tu decisión en esto.
  Eso sí, hay quien opina que ASP.NET MVC será el estándar de creación de sistemas web en unos años, por lo que en cualquier caso se trata de una tecnología que no habría que perder de vista…
  Beneficios de ASP.NET MVC
  Las ventajas de la arquitectura MVC, descritas anteriormente, y las bondades del diseño del framework son un buen aliciente para comenzar a trabajar con ASP.NET MVC. De hecho, deberíamos tener muy en cuenta en qué aspectos nuestros desarrollos van a beneficiarse del uso de esta tecnología y valorar si estas ventajas compensan los inconvenientes que su adopción va a suponer:
     la separación de aspectos impuesta por el patrón MVC obligará a tener un código más limpio y estructurado, independizando totalmente la interfaz de la lógica de navegación y, por supuesto, de la de negocio. 
    de la misma forma, esta división facilita el trabajo en equipo, pues permite el avance en paralelo en las distintas capas. 
    si entre nuestras prioridades está el asegurar el correcto funcionamiento de nuestros componentes a través de pruebas unitarias, o hemos optado por utilizar una metodología de desarrollo guiado por pruebas (TDD), ASP.NET MVC nos vendrá de perlas. La separación de aspectos citada anteriormente facilita la creación de pruebas específicas para los componentes de cada capa de forma independiente, así como el uso de técnicas avanzadas (mocking, inyección de dependencias…) para que éstas sean lo más completas posible. 
    las friendly URLS, o direcciones amigables, es un beneficio directo del uso del framework de Microsoft. Estrictamente hablando no es mérito de la plataforma MVC, sino del juego de clases presentes en el espacio de nombres System.Web.Routing, incluidas en .NET framework 3.5, pero en cualquier caso si optamos por esta tecnología la tendremos “de serie”, con las ventajas que ello conlleva (SEO, REST, claridad en direcciones…). 
    al final, el software será mucho más mantenible; el hecho de que los componentes estén separados y bien estructurados simplificará las tareas de mantenimiento. 
    el conjunto de convenciones en cuanto a la estructura de proyectos y de nombrado y disposición de elementos facilitará el desarrollo una vez sean asimiladas. 
 
  El tipo de sistema
  A la hora de plantearse un cambio de este tipo es imprescindible tener en cuenta el tipo de proyecto en el que solemos trabajar. No es lo mismo desarrollar un sitio web colaborativo destinado a un gran número de usuarios, como Facebook o Digg, donde el control fino sobre la entrada y salida es crucial para asegurar aspectos como la escalabilidad, cumplimiento de estándares, o accesibilidad, que crear una aplicación de gestión que utilizarán un grupo relativamente reducido de usuarios desde una intranet corporativa.
  Para el primer caso, ASP.NET MVC es una buena opción. La simplicidad de la arquitectura MVC hace que el ciclo de vida de las páginas de este framework sea mucho más sencillo que el de los Webforms, y la ausencia de automatismos y persistencia de estado aligera en gran medida el peso y complejidad de las páginas, lo cual redundará muy positivamente en el rendimiento del sistema. Si además el proyecto requiere o resulta beneficiado por el uso de direcciones URL amigables (por razones de SEO, para presentar un interfaz claro de tipo REST, o cualquier otro motivo), más aún. 
  Un ejemplo de aplicación real de este tipo es la famosa comunidad StackOverflow.
  En cambio, el segundo caso, cuando se trata de crear pesadas aplicaciones de gestión con interfaces de usuario complejos y en las que no es especialmente relevante la calidad del código HTML enviado al cliente, ni el peso de éstas al ser entornos cerrados y controlados, ASP.NET Webforms sigue siendo la opción más razonable. Las facilidades para el desarrollo rápido de aplicaciones (RAD) son mayores utilizando formularios web, aunque sea a cambio de sacrificar aspectos como la separación de código e interfaz, o la facilidad para realización de pruebas unitarias.
  8. ¿Puedo convertir mi proyecto ASP.NET Webforms a ASP.NET MVC?
  Sí, pero tardarás un buen rato ;-)
  Al menos que conozca, no existe ninguna herramienta ni siquiera capaz de intentar realizar tal proeza. Hay que tener en cuenta que el cambio de una a otra tecnología no es una mera traducción como podría ser convertir una aplicación VB.NET a C#; se trata de un nuevo marco de trabajo que afecta sobre todo a la presentación y control de flujo del sistema. 
  Si tienes unas buenas clases de lógica de negocio, bien aisladas de la tecnología Webforms (como debería ser, por otra parte), probablemente sean los únicos componentes que puedas reutilizar de forma directa, sin grandes cambios. El resto, es decir, todo lo relativo a la interacción con el usuario, habría que convertirlo de forma manual, y por tanto, probablemente habría que pensarse bien si vale la pena hacerlo.
  
  9. ¿Se puede utilizar ASP.NET Ajax con el framework MVC?
  Si nos estamos refiriendo a la posibilidad de utilizar controles de servidor Ajax, como el célebre UpdatePanel o los controles del ASP.NET Ajax Control Toolkit, la respuesta es rotunda: no. De hecho, el modelo MVC no permite el uso de controles de servidor (runat="server"); bueno, o al menos no lo permite de la forma en que veníamos haciéndolo, pues han dejado de existir aspectos tan fundamentales para ellos como el viewstate o los postbacks.
  Ahora bien, si la pregunta la generalizamos como “¿se pueden utilizar librerías Ajax con el framework MVC?” la respuesta es absolutamente. De hecho, ASP.NET MVC se lleva de fábula con librerías de scripting como las incluidas en el framework ASP.NET 3.5, o con la magnífica jQuery. La limpieza de la filosofía MVC hace posible que sea realmente sencillo realizar desde cliente llamadas a los controladores mediante scripting con objeto de obtener datos, actualizar porciones de contenido de la página con el marcado de la vista correspondiente, o, en definitiva, interactuar con el servidor.
  En este mismo blog puedes encontrar multitud de ejemplos de integración de jQuery y ASP.NET MVC, que aunque implementados con las previews del framework (¡a ver si un día tengo un rato y los voy actualizando!), pueden ayudarte a entender cómo hacerlo.
  Otro aspecto interesante respecto a jQuery es que esta librería entró a formar parte de la plataforma de desarrollo de Microsoft el pasado mes de septiembre, lo que en la práctica aporta varias ventajas: la primera, que jQuery viene incluido de serie en las plantillas de proyectos ASP.NET MVC; la segunda, que Microsoft se ha esforzado por mejorar la integración con Visual Studio de esta librería, facilitando archivos que hacen posible el disfrute de intellisense mientras la utilizamos.
  10. ¿Se puede utilizar VB.NET con ASP.NET MVC?
  Por supuesto. Aunque la mayoría de código que se encuentra por la red utiliza C#, probablemente porque es el lenguaje en el que ha sido desarrollado y sobre el que se están exponiendo más ejemplos desde las previews más tempranas, cualquier lenguaje .NET podría ser utilizado sin problema para desarrollar aplicaciones sobre este framework. 
  A nivel de entorno de desarrollo, Visual Basic ofrece el mismo nivel de ayudas y plantillas que C#, pero desconozco si esto es así en otros lenguajes.
  11. ¿Puedo usar LINQ desarrollando aplicaciones con ASP.NET MVC framework?
  Sí, de hecho se complementan a la perfección.
  Aunque LINQ como tal sólo es un mecanismo de consulta integrado en los lenguajes de programación, las tecnologías ORM que lo rodean, como LINQ2SQL o Entity Framework son ideales para implementar los componentes propios del Modelo (la M de “MVC”). En aplicaciones relativamente simples, estas clases podrían generarse con los diseñadores visuales del entorno de desarrollo, o de forma externa con herramientas como SQLMetal, facilitándonos enormemente el trabajo.
  Este es un buen momento para comentar que una de las grandes críticas que se están haciendo a la implementación del framework ASP.NET MVC es que parece hacer olvidado la “M”. Si bien el marco de trabajo establece con claridad el alcance y responsabilidades de los controladores y las vistas y dota de herramientas y convenciones específicas a cada una de estas capas, no ocurre lo mismo con el Modelo, que queda totalmente al libre albedrío del desarrollador.
12. ¿Qué tipo de tecnologías puedo utilizar en las vistas?
  El objetivo de las vistas es componer el interfaz de usuario y los mecanismos de interacción con el usuario. Lo habitual será utilizar XHTML, CSS y Javascript, aderezado con bloques de código de servidor que se ejecutará en el momento de renderizar la página.
  También puedes utilizar la tecnología Ajax para enviar u obtener información desde el servidor, siempre mediante llamadas a acciones definidas en el controlador, que te permitirán crear interfaces más dinámicos y actuales.
  Pero sobre todo, nada de utilizar controles de servidor (Label, Button, Dropdowns…). Estos deberán ser sustituidos por sus elementos XHTML equivalentes, lo que implica que perderemos los automatismos provistos por Webforms para el mantenimiento del estado de los controles.
  
  
  <for each="var name in names">
  <test if="name == 'Jose'">
    <p>Yo mismo</p>
    <else/>
    <p>Amigo: ${name}  
  </test>
</for>
Otra posibilidad interesante que aprovecha y demuestra la flexibilidad de la arquitectura de ASP.NET MVC framework, es la utilización de motores de vistas distintos al estándar. Existen multitud de motores ligeros (NHaml, Spark, Brail, NVelocity…), cada uno con su propio lenguaje de marcas y convenciones, que permiten la definición de vistas a partir de plantillas como la que se muestra en el lateral (ejemplo de Spark). 
13. ¿Es ASP.NET MVC framework software libre?
He aquí una de las grandes novedades respecto al post que escribí un año atrás. Por aquellos tiempos era inimaginable que esta pregunta pudiera responderse de forma afirmativa, pero… efectivamente, ASP.NET MVC Framework es software libre.
A primeros de abril de 2009 se comenzó a distribuir oficialmente el código fuente de ASP.NET MVC con licencia MS-PL (Microsoft Public License), un modelo de licencia aprobado por la OSI (Open Source Initiative) que permite el uso del software en aplicaciones comerciales y no comerciales.

Publicado en: www.variablenotfound.com




     



Helper para desplegables enlazados actualizado para ASP.NET MVC 1.0.
2009-04-05T23:24:00.002+02:00
   He actualizado a la versión 1.0 de ASP.NET MVC framework el ejemplo de Helper para crear desplegables enlazados (cascading dropdowns) con jQuery que escribí unos meses atrás. 
  El contenido del post sigue siendo válido, sólo ha sido necesario retocar algunos detallitos en el código debido a los cambios introducidos en el framework desde la versión Beta.
  Descargar proyecto (comprimido en .zip)
  Requisitos:
     Visual Studio 2008/Web Developer Express 2008 
    Service Pack 1 (VS2008/VWD2008) 
    ASP.NET MVC framework 1.0 
 
  Publicado en: www.variablenotfound.com.




     



¡ASP.NET MVC es open source!
2009-04-02T17:42:00.001+02:00
 Tras esperar un poco por aquello del April’s Fool (el equivalente a nuestro Día de los Inocentes ), ya hoy se puede confirmar que el código fuente del framework ASP.NET MVC 1.0 ha sido publicado con licencia MS-PL, lo que en la práctica significa que ha pasado a ser oficialmente software libre.
  Aunque el código fuente de la plataforma estaba disponible en CodePlex prácticamente desde que empezaron a publicarse las primeras previews de la plataforma, es ahora cuando, en palabras de Scott Hanselman, ha pasado de ser “source opened” a “open source”.
  Muchas de las grandes figuras implicadas en el proyecto han publicado ya en sus respectivos blogs el esperado anuncio, felicitándose por el logro conseguido, una nueva demostración del cambio de rumbo de Microsoft respecto al código abierto.
  También Miguel de Icaza, quien por cierto recientemente anunciaba la disponibilidad de Mono 2.4 y MonoDevelop 2.0, ya ha comentado que se trata de una magnífica noticia no sólo para el equipo del Proyecto Mono, sino para toda la comunidad de desarrolladores ASP.NET.
  Enlaces (en inglés):
     ASP.NET MVC 1.0 (ScottGu) 
    Microsoft ASP.NET MVC 1.0 is now Open Source MS-PL (Hanselman) 
    Open Source License For System.Web.Mvc (Haack) 
    Rolling a Bubble – ASP.NET MVC is Ms-PL (Connery) 
    Microsoft releases ASP.NET under the MS-PL License (Miguel de Icaza) 
    Download ASP.NET MVC 1.0 
 
  Publicado en: www.variablenotfound.com
  



     



C#: Desmitificando las expresiones lambda (y III)
2009-04-01T16:40:00.000+02:00
En el primer post intentamos describir qué eran las expresiones lambda, resumiendo muy brevemente su utilidad, así como los aspectos sintácticos de este tipo de construcciones del lenguaje. El segundo lo enfocamos a explicar el papel de las lambda como funciones anónimas, su estrecha relación con los delegados, y su forma de utilización.

En esta tercera y última entrega de la serie, vamos a centrarnos en otra de las grandes utilidades de las expresiones lambda en .NET framework: la definición de árboles de expresión.

Las lambda como árboles de expresión
Los compiladores de C# y VB.NET pueden, bajo determinadas circunstancias, utilizar las lambdas para crear un árbol  de expresión, una estructura en memoria que representa en forma de árbol las operaciones a realizar, y en el orden que hay que hacerlo, para lograr un objetivo. Si lo queréis ver más claro, observad el diagrama adjunto, en el que se muestra el árbol de expresión correspondiente a una función lambda que obtiene la media de dos números.

Esto es muy diferente al caso anterior, donde hablábamos de las lambda como funciones ejecutables que podían ser referenciadas por delegados e invocadas de forma directa. Entonces las expresiones lambda eran transformadas en tiempo de compilación en código ejecutable (de hecho, en métodos estáticos que pueden ser consultados usando Reflector u otros desensambladores), y por ello podíamos utilizarlas de forma directa.

En el caso de los árboles de expresión, la compilación no genera código ejecutable correspondiente a las instrucciones definidas en la lambda, sino el código para crear y llenar el árbol con dicha expresión. Después, en tiempo de ejecución, será posible recorrer dicho árbol, analizarlo, seriarlo para almacenarlo o moverlo a otras capas, e incluso compilarlo para poder lanzar su ejecución.

Pero paremos aquí un momento... según lo dicho, cuando el compilador se encuentra con una expresión lambda, por ejemplo x => x * 2, puede optar por generar una función anónima o por generar el código de llenado del árbol, ¿cómo sabe lo que debe hacer?

Pues bien, el compilador elegirá la opción adecuada dependiendo del tipo de la referencia a la expresión lambda. Si se trata de un tipo de delegado como Func o Action, generará código ejecutable y las referencias a la función serán tratados como delegados; si se usa el tipo Expression, que veremos más adelante, se generará el árbol de expresión y las referencias no se considerarán delegados, sino objetos de este tipo. Por este motivo no podemos utilizar para declarar lambdas variables locales de tipo implícito: el compilador no sabría qué hacer.
  var dobla = a => a * 2; // Error: no se puede asignar
                          // una expresión lambda a una variable
                          // local de tipo implícito.
 
Definición de árboles con expresiones lambda
Para definir un árbol de expresión a partir de una lambda debemos utilizar el tipo genérico Expression<TipoDelegado>, siendo TipoDelegado un delegado como Action o Func de los descritos en el post anterior. ¿Que esto os parece confuso? Pues esperad a ver el ejemplo... ;-)  Expression<Func<int, int, int>> media = (a, b) => (a + b) / 2;
 
En realidad, aparte de lo difícil de leer que es una declaración de este tipo, la idea es bastante sencilla. Lo que estamos indicando al compilador es que queremos montar un árbol de una expresión de la que conocemos el tipo de los parámetros de entrada y del valor de retorno, datos que indicamos mediante el delegado que utilizamos como argumento genérico de la clase Expression, la porción que he marcado de amarillo en el ejemplo anterior. Además, este delegado lo utilizaremos cuando queramos convertir el árbol de expresión en código ejecutable, más adelante veremos cómo.

Para que quede claro, ahí van algunos ejemplos más:  // Árbol de expresión de una función que determina
  // si el parámetro que le llega es par
  Expression<Func<int, bool>> esPar = a => a%2==0;

  // Árbol de expresión de una función 
  // que retorna el máximo de dos números.
  Expression<Func<int, int, int>> maximo =
              (a, b) => a > b ? a:b;

  // Árbol de expresión de una función que
  // retorna un string transformado
  Expression<Func<string, string>> TrimMays = 
              a => a.Trim().ToUpper();

  // Árbol de expresión de una acción 
  // sin parámetros que escribe por consola la fecha y hora.
  Expression<Action> accion =
              () => Console.WriteLine(DateTime.Now); 
 
Fijaos que el tipo de delegado Action o Func, que son los parámetros genéricos de la expresión, son los que definen los tipos de parámetros y retornos de la lambda. En el primer caso, el Func<int, bool> define que la función recibe un entero y retorna un booleano; en el último caso, ni se envía ni se recibe nada, de ahí que utilicemos un delegado Action.

Un detalle importante, antes de que se me olvide comentarlo. Los árboles de expresión sirven, como su nombre indica, para almacenar expresiones. Esto limita el tipo de construcciones de código que podemos usar en las lambdas que los definen: no está permitido utilizar asignaciones, bloques con llaves { }, ni bucles... debe tratarse de una expresión que pueda representarse en una jerarquía de árbol. Si intentamos saltarnos estas restricciones, el compilador generará un error, aunque el tipo de delegado sea correcto y la función lambda también, como en el siguiente ejemplo:
  // Suma los n primeros naturales
  Expression<Func<int, int>> expr =
    n => {
           int t = 0;
           for (int i = 1; i <= n; t += i++) ;
           return t;
         };

  // Error CS0834: Una expresión lambda con cuerpo no puede ser 
  // convertida a árbol de expresión
 
Volvemos un poco atrás ahora para recordar cuando comentaba que la compilación de una lambda no genera código ejecutable correspondiente a las instrucciones definidas en la expresión, sino el código para llenar el árbol de expresión que la representa. 

¿Y cómo hace eso? Muy sencillo. El compilador analiza la expresión, genera la secuencia de instrucciones que compone el árbol, las compila, e introduce el resultado en el ensamblado. El siguiente ejemplo muestra cómo crear un árbol de expresión usando una lambda, y una aproximación al código equivalente que genera el compilador, para que nos podamos hacer una idea del trabajo que nos ahorra esta característica del lenguaje:

  // Árbol definido con una lambda:
  Expression<Func<int, bool>> esPar = a => a % 2 == 0;

  // Y el mismo árbol definido a mano, 
  // lo que genera el compilador automáticamente:
  ParameterExpression param = Expression.Parameter(typeof(int), "a");
  ConstantExpression dos = Expression.Constant(2, typeof(int));
  ConstantExpression cero = Expression.Constant(0, typeof(int));
  BinaryExpression modulo = Expression.Modulo(param, dos);
  BinaryExpression comparacion = Expression.Equal(modulo, cero);
  Expression<Func<int, bool>> esPar2 =
       Expression.Lambda<Func<int, bool>>(comparacion, param);
 
Uso de los árboles de expresión
Ya sabemos qué son los árboles de expresión y cómo podemos definirlos, pero aún no le hemos visto sentido a su existencia. Pero lo tiene, vaya si lo tiene ;-)

En primer lugar, el hecho de poder definir el árbol partiendo de una expresión lambda, además de comodidad a la hora de codificar, nos permite aprovechar el tipado fuerte y la potencia del intellisense para evitar errores. En el ejemplo anterior, las probabilidades de que nos equivoquemos creando el árbol de forma manual son muy superiores a que ocurra si utilizamos la sintaxis lambda.

Segundo, fijaos que en ningún momento se está generando código IL o compilando la expresión representada por la lambda. Estamos creando una estructura en memoria. Esto quiere decir que después podemos procesar esta información como estimemos conveniente; podemos, por ejemplo, analizar su contenido, recorrerlo, seriarlo, o transformarlo, en función de nuestras necesidades. Es ideal, por tanto, cuando tengamos interés en interpretar una expresión para realizar alguna acción con ella.

Vamos a ver ahora varios ejemplos para ilustrar el uso de las lambdas y árboles de expresión en el mundo real.
Linq
En el caso de Linq aplicado a un proveedor externo de datos relacional (por ejemplo, las tecnologías Linq to SQL, o Entity Framework), no tiene interés alguno el código ejecutable asociado a una expresión, sino su estructura, pues al final va a ser traducida al lenguaje o tecnología del almacén de información. Supongamos la siguiente consulta para obtener los productos que comienzan por "S":  // Usando una consulta Linq:
  var datos = from p in productos 
                 where p.Nombre.StartsWith("S")
                 select p;

  // O su equivalente usando 
  // operadores de consulta:
  var datos = productos.Where(p=>p.Nombre.StartsWith("S"));

 
La lambda resaltada servirá para crear un árbol de expresión con las condiciones indicadas, pues el método de extensión Where aplicado acepta un predicado de tipo Expression. No se genera ningún método anónimo para la expresión lambda, ni se traduce a IL su contenido: sólo interesa para definir la expresión que será introducida en el árbol. Más adelante, en el momento de extraer realmente la información desde el almacén correspondiente, el componente proveedor de datos recorrerá y analizará la estructura en memoria, generando su equivalente en SQL, que es lo que lanzará al SGBD para obtener los datos.

Por cierto, existen en la actualidad una gran cantidad de proveedores de Linq, capaces de transformar los árboles de expresión en consultas a casi cualquier tipo de almacén. Fijaos que la posibilidad de separar la codificación lambda de la interpretación de la expresión hace posible su utilización en una gran variedad de ámbitos.

Cálculo simbólico
Otro ejemplo que ilustra muy bien las posibilidades de los árboles de expresión, de mano del maestro Octavio Hernández. Se trata del artículo Cálculo simbólico en C# 3.0, publicado en la web de El Guille a principios de 2007.

A lo largo del artículo se realiza la implementación básica de un sistema de cálculo de derivadas de funciones matemáticas partiendo de un árbol de expresiones. El proceso, que el autor va explicando paso a paso, consiste en analizar el árbol, e ir generando otro árbol con el resultado de la derivación de cada expresión encontrada. A continuación se muestra la porción de código donde se realiza la derivación de una operación de suma, utilizando recursividad para derivar además cada uno de los sumandos:  private static Expression Derive(this Expression e, string paramName)
  {
      switch (e.NodeType)
      {
          [...]
          // sum rule
          case ExpressionType.Add:
              {
                  Expression dleft = 
                     ((BinaryExpression) e).Left.Derive(paramName);
                  Expression dright = 
                     ((BinaryExpression) e).Right.Derive(paramName);
                  return Expression.Add(dleft, dright);
              }
          [...]
      }
  }
 
Al final, fijaos que de nuevo no nos interesa en absoluto la lambda como función anónima ni delegado, sino la estructura de la propia expresión, de forma que podamos recorrerla y transformarla en otra expresión, en este caso la función derivada de la original. El siguiente ejemplo muestra el uso de esta clase:   Expression<Func<double, double>> 
                funcion = x => x*x;          // f(x)=x^2

  Expression<Func<double, double>> 
                derivada = funcion.Derive(); // f'(x)=2*x

  Console.WriteLine(derivada); // Muestra la función derivada:
                               //    x => ((x * 1) + (1 * x))
 
Creedme, vale la pena echarle un vistazo.

ASP.NET MVC
Un último ejemplo, que demuestra la versatilidad del uso de lambdas y árboles de expresión en multitud de escenarios. En el framework ASP.NET MVC, es posible crear enlaces hacia acciones desde dentro de las vistas (páginas .ASPX), que no son sino métodos dentro de unas clases concretas llamadas "controladores". El caso es que para hacer referencia a un método del controlador, pueden utilizarse estas dos vías, de resultado idéntico:  // Obtiene un enlace al método "ChangePassword"
  // de la clase "AccountController":
  Html.ActionLink("Cambiar clave", "ChangePassword", "Account")

  // Lo mismo, pero usando un árbol de expresión:
  Html.ActionLink<AccountController>
              (acc=>acc.ChangePassword(), "Cambiar clave")
 
Aunque el resultado es el mismo, la segunda usa un árbol de expresión para realizar la referencia al método ChangePassword de la clase AccountController. La implementación del método ActionLink recorre el árbol generado desde la expresión lambda para obtener el nombre del controlador y del método, por lo que es equivalente a primera fórmula, pero beneficiándose de las ventajas del tipado fuerte y del intellisense en la edición.
Los árboles de expresión como código ejecutable
Hasta ahora siempre me he referido a los árboles de expresión como entidades de almacenamiento. De alguna u otra forma, estaba equiparando su utilidad a la cualquier estructura de datos que permitiera guardar y procesar información, lo cual es cierto pero sólo parcialmente.

Los árboles de expresión aportan una característica adicional: se pueden convertir en código ejecutable. Es decir, es posible compilar un árbol de expresión en tiempo de ejecución, dando lugar a una función anónima a la que podemos tener acceso, es decir, invocarla, a través de sus delegados.

Veámoslo con un caso concreto. Retomando el ejemplo de obtención de derivadas, sería perfectamente posible obtener el valor de la función derivada en un punto ampliando ligeramente el código visto anteriormente:  Expression<Func<double, double>> 
                funcion = x => x*x;          // f(x)=x^2

  Expression<Func<double, double>> 
                derivada = funcion.Derive(); // f'(x)=2*x

  // Compilamos la función derivada
  // y obtenemos un delegado a la misma:
  Func<double, double> funcDerivada = derivada.Compile();

  double result = funcDerivada(6); // Obtenemos el valor de la función 
                                   // invocando al delegado con x=6
  Console.WriteLine(result);       // Muestra "12"
 
Como se puede observar en el código, la llamada al método Compile() devuelve un delegado del tipo Func indicado en el parámetro genérico de la expresión, que apunta hacia la función anónima creada "al vuelo" a partir de las expresiones contenidas en el árbol. Es decir, desde la definición simbólica contenida en el árbol ¡obtenemos código ejecutable!

Aunque espectacular, en realidad no hay nada mágico en esta característica: se trata de ir recorriendo el árbol y emitiendo el código IL correspondiente a cada expresión, que está perfectamente tipificada y definida. En el namespace System.Linq.Expressions existe una bonita clase interna llamada ExpressionCompiler que se dedica exclusivamente a ello, utilizando herramientas suministradas por System.Reflection.Emit, como los generadores de lenguaje intermedio ILGenerator.
¡Y hasta aquí hemos llegado!
A lo largo de estos tres posts hemos recorrido las principales características y utilidades de las expresiones lambda. Obviamente, han quedado cosas por detrás; no era objetivo de esta serie profundizar demasiado, sino ofrecer una visión suficiente para animar a los desarrolladores a utilizar esta potente característica que nos ofrece C# (y VB.NET).

Espero que os haya sido una lectura útil, al menos tanto como me ha resultado a mí su escritura. Ah, y para consultas, sugerencias o puntualizaciones, por aquí me tenéis.

Publicado en: www.variablenotfound.com.



     



C#: Desmitificando las expresiones lambda (II)
2009-04-01T16:32:00.000+02:00
En el post anterior intentamos realizar una primera aproximación a las expresiones lambda, centrándonos en obtener una definición lo suficientemente cercana, que nos permitiera conocer a grandes rasgos qué son, así como en describir su forma general y sus particularidades sintácticas.

En esta segunda entrega vamos a profundizar un poco en el papel de las expresiones lambda como vía para definir muy rápidamente funciones anónimas y los tipos de delegados con los que podemos referenciarlas, y por tanto, invocarlas.

Ya en el tercer post describiremos el papel de las expresiones lambda como herramienta de generación de árboles de expresión.

Las lambdas como funciones anónimas
Como habíamos insinuado anteriormente, uno de los usos de las expresiones lambda es permitir la definición "en línea" de funciones anónimas. De hecho, en tiempo de compilación las expresiones lambda son convertidas en métodos a los que el compilador establece un nombre único autogenerado, como los ejemplos mostrados a continuación:


Las referencias a estas funciones anónimas son transformadas en delegados (punteros) a las mismas, lo que nos permitirá, por ejemplo, invocarlas desde el código. En la práctica esto  quiere decir que podemos asignar una lambda a una variable y ejecutarla como muestra el siguiente pseudocódigo:
  delegado duplica = x => x * 2; 
  escribe duplica(2); // Escribe un 4
 
En este primer acercamiento, fijaos que duplica es el nombre del delegado, la función definida en forma de expresión lambda no tiene nombre, será el compilador el que se asigne uno. 

Veamos cómo se concreta esta idea en C#. En el siguiente código, la variable duplica apunta hacia una función anónima definida a través de la expresión lambda en cuya implementación lo único que se hace es retornar el doble del valor que le llega como parámetro. Vemos también cómo podemos utilizarla de forma directa:  Func<int, int> duplica = x => x * 2;
  int result = duplica(7); // result vale 14
 
Sólo con objeto de que podáis entender el código anterior, os adelantaré que la porción Func<int, int> es una forma rápida de tipificar el delegado, indicando que duplica apunta a una función que espera un entero como parámetro de entrada, y que su valor de retorno será otro entero. Esto lo veremos dentro de un momento.

De la misma forma que asignamos la expresión lambda a una variable, podemos hacerlo también para indicar el valor de un parámetro a un método que acepte un delegado concreto. Por ejemplo, el siguiente código muestra un método llamado calcula que recibe un valor entero y una referencia a una función, retornando el resultado de efectuar dicha operación sobre el entero proporcionado:  // Es método ejecuta la función indicada por
  // el parámetro operacion, enviándole el valor especificado, 
  // y retorna el resultado obtenido de la misma.
  public int calcula(int valor, Func<int, int> operacion)
  {
    return operacion(valor); // retorna el resultado de aplicar la 
                             // expresión indicada al valor.
  }

  // Usos posibles:
  int i = calcula(4, x => x / 2); // Le pasamos una referencia a la 
                                  // función que estamos definiendo sobre
                                  // la marcha. El resultado es que i=2.

  int j = calcula(4, duplica);    // Le pasamos la variable "duplica", 
                                  // que es una referencia a la lambda
                                  // definida anteriormente. J valdrá 8.
 
<HistoriaDelAbuelete>
Seguro que a los más viejos del lugar esto le recuerda a los Codeblocks que utilizábamos en Clipper a principios de los 90 (uuf, cómo pasa el tiempo...). ¿Todavía reconocéis el siguiente código?  bDuplica := { |n| n*2 }
  ? EVAL(bDuplica, 7)     // Muestra un 14
 </HistoriaDelAbuelete>

Una consecuencia directa de que las expresiones lambdas sean referenciadas a través de delegados es que podemos utilizarlas en cualquier sitio donde se acepte un delegado, con la única precaución de escribirla teniendo en cuenta el tipo de su retorno y los parámetros que recibe. Un ejemplo claro lo tenemos en la suscripción a eventos, donde la técnica habitual consiste en utilizar un delegado a un método en el que se implementa la lógica del tratamiento de los mismos, algo como:
  // Nos suscribimos al evento MouseMove:
  this.MouseMove += new MouseEventHandler(this.Form1_MouseMove);
  [...]

  // Tratamiento del evento MouseMove:
  private void Form1_MouseMove(object sender, MouseEventArgs e)
  {
    this.Text = e.X + "," + e.Y;
  }
 
Como sabemos, podemos suscribirnos al evento MouseMove añadiéndole delegados del tipo MouseEventHandler, definido en System.Windows.Forms, cuya firma indica que recibe un parámetro de tipo object, otro de tipo MouseEventArgs y no retorna ningún valor, exactamente igual que sería un delegado anónimo (C# 2.0) escrito así:
  this.MouseMove += delegate(object sender, MouseEventArgs args)
  {
    this.Text = args.X + "," + args.Y;
  };
 
Y dado que las lambdas pueden sustituir de forma directa a cualquier delegado, podemos utilizarlas para conseguir un código más compacto:
  this.MouseMove += (sender, args) => {
                       this.Text = args.X + "," + args.Y;
                    };
 
Llegados a este punto es conveniente aclarar que las expresiones lambda son características introducidas en los lenguajes, y por tanto en sus compiladores, pero no en la plataforma de ejecución (CLR) en sí. Por tanto, todo lo descrito hasta el momento era posible realizarlo antes que las lambda aparecieran por el horizonte, aunque de forma un poco más tediosa, utilizando mecanismos que la versión 2.0 del framework ponía a nuestra disposición, como los delegados y métodos anónimos. En este sentido, el uso de expresiones lambda aportan mucha simplicidad, elegancia y legibilidad al código.

Esto explica, además, que Visual Studio 2008 sea capaz de generar código para .NET 2.0 a partir de código fuente C# 3.0.

Tipos de delegados de expresiones lambda
Antes ya había adelantado que la definición Func<int, int> era simplemente una forma de indicar el tipo del parámetro que recibía la función lambda, así como el tipo del valor de retorno. En realidad, lo único que estábamos haciendo era definir, de forma muy sencilla y rápida, el delegado hacia la función. 

Vamos a concretar esto un poco más, pero antes de continuar, una cosa: si para tí un genérico es un tipo de medicamento, mejor que leas algo sobre el tema antes de continuar, pues en caso contrario es posible que te pierdas un poco ;-). Pues probar leyendo una introducción a los generics en c#, o la Guía de programación de C#.

.NET Framework ofrece en el espacio de nombres System un conjunto de definiciones de genéricas de delegados para que podamos utilizarlos para "apuntar" hacia las funciones definidas mediante expresiones lambda, llamados Action y Func.

Utilizaremos los tipos Func para definir referencias a expresiones lambda que retornen un valor, o sea, funciones. De ahí su nombre. Los tipos Action, en cambio, están destinados a referenciar a lambdas que realicen acciones y que no retornen ningún valor. De ahí su nombre también. ;-)

Una de estas definiciones es la que habíamos usado en un ejemplo anterior:  Func<int, int> duplica = x => x * 2;
 
Como se puede observar, al tratarse de una referencia a una función que retorna un valor, hemos utilizado un tipo Func con dos parámetros genéricos, que corresponde con la siguiente declaración existente en el espacio de nombres System:
  public delegate TResult Func<T, TResult>(T arg);
 
Por ello, cuando declarábamos que la variable duplica era del tipo Func<int, int>, lo que indicábamos era, en primer lugar que el parámetro que necesitaba la lambda era un int, y que ésta nos devolvería también un int, es decir, lo mismo que si hubiéramos definido duplica así, utilizando métodos anónimos de C# 2.0:
  // En el área de declaraciones:
  public delegate int Duplicador(int arg);
  ...
  // En el código:
  Duplicador duplica = delegate(int k) { return k*2 };
 
Obviamente, la sintaxis lambda es mucho más compacta y expresiva.

En la práctica, lo único que tenemos que tener claro a la hora de referenciar una función lambda es el tipo de cada uno de los parámetros que usa, y el tipo de retorno. Estos se introducen, en ese orden, en los parámetros genéricos de la clase Func y listo. Como esto debe quedar claro, ahí van unos ejemplos de definición y uso:  // Recibe un entero y retorna un booleano:
  Func<int, bool> esPar = x => x%2==0;     
  Console.WriteLine(esPar(2)); // Muestra "True"

  // Recibe dos enteros, retorna otro entero:
  Func<int, int, int> suma = (a,b) => a+b;
  Console.WriteLine(suma(2,3)); // Muestra "5"

  // No recibe nada, retorna un texto:
  Func<string> hora = () => "Son las "
                             + DateTime.Now.ToShortTimeString();
  Console.WriteLine(hora()); // Muestra "Son las 14:21:10"

 
Es importante saber que en el framework están definidos los delegados Func<tipo1, tipo2..., tipoResult> para funciones de hasta cuatro parámetros. Si necesitamos más deberemos definir los delegados a mano, aunque esto es realmente sencillo utilizando una de las declaraciones existentes y añadiéndole el número de parámetros que deseemos. Por ejemplo, para seis parámetros la definición del genérico sería algo así como:  public delegate 
         TResult Func<T1, T2, T3, T4, T5, T6, TResult>
                 (T1 p1, T2 p2, T3 p3, T4 p4, T5 p5, T6 p6);
 
Pero ahora aparece un pequeño problema: las funciones sin retorno no pueden referenciarse con delegados de tipo Func, puesto que el framework .NET no soporta la instanciación de tipos genéricos utilizando parámetros void (ECMA 335, sección 9.4, pág. 153). Por tanto, no podríamos declarar un delegado como Func<int, void> para apuntar hacia una función que recibe un entero y no devuelve nada. Si lo pensáis un poco, este es el motivo de que no exista ninguna sobrecarga de la clase Func sin parámetros genéricos, pues como mínimo debemos indicar el tipo del valor de retorno.

La clave para cubrir estos casos se encuentra en el tipo Action. Como comentaba unas líneas más arriba, el objeto de estos tipos de delegados es apuntar a expresiones lambda que realicen acciones y que no retornen ningún valor, por lo que sus parámetros genéricos describirán exclusivamente los tipos de los parámetros de la función. En este caso, como es obvio, sí existe una clase no parametrizada Action para apuntar a funciones sin parámetros, además de disponer de genéricos que cubren las acciones de hasta cuatro parámetros. Veamos unos ejemplos:
  // Acción sin parámetros (no genérica):
  Action saluda = () => Console.WriteLine("hola");
  saluda();  // Muestra "hola";

  // Acción que recibe un string
  Action<string> apaga = motivo => { 
                                      log(motivo);
                                      shutdown();
                                   };
  apaga("mantenimiento"); // Apaga el sistema
 
Por último, me parece interesante recordar algo que había comentado en el post anterior, que en las expresiones lambda no era necesario indicar el tipo de los parámetros ni del retorno porque el compilador los infería del contexto. Como podemos ver, lo tiene bastante fácil, puesto que simplemente debe tomar la definición del delegado para conocerlos; por eso no es necesario introducir redundancias como las siguientes:  Func<int, int> duplica = (int a) => (int)(a * 2); // ¡Redundante!

  // Forma más cómoda:

  Func<int, int> duplica =  a => a * 2; // Ok!
 
En cualquier caso, si por algún motivo es necesario utilizar la forma explícita, sabed que no se permite hacerlo de forma parcial, es decir, o le ponéis los tipos a todo, o no se los ponéis a nada.

Y hasta aquí esta segunda entrega. En el siguiente post, el último de la serie, estudiaremos el uso de las lambda como herramientas de definición de árboles de expresión.

Por supuesto, para cualquier duda o sugerencia, ya sabéis dónde encontrarme. :-)

Publicado en: www.variablenotfound.com.



     



C#: Desmitificando las expresiones lambda (I)
2009-04-01T16:30:00.001+02:00
Entre las múltiples novedades aparecidas con C# 3.0 y VB.NET 9.0, las expresiones lambda son sin duda una de las que en principio pueden parecer más complejas, probablemente por su relación con conceptos no demasiado asimilables como los delegados, inferencia de tipado, métodos anónimos, o tipos genéricos, entre otros.

Sin embargo, esa aparente dificultad desaparece en cuanto se les presta un poco de atención, y una vez comprendidas aportan a los desarrolladores una potencia y agilidad difíciles de lograr con las herramientas disponibles hasta el momento. Sólo hay que ver su amplia utilización dentro del propio .NET framework, LINQ, y nuevas plataformas como ASP.NET MVC, para darse cuenta de su importancia. Y por si fuera poco, según cuentan los expertos, su uso "engancha".

A lo largo de esta serie de tres posts intentaré describir las expresiones lambda desde un punto de vista práctico, con la única pretensión de aportar algo de luz a los que todavía no han sucumbido a su poder. ;-)

El objetivo de este primer post es puramente introductorio, y trataré conceptos y nociones básicas para poder abordar los siguientes. En el segundo post de la serie trataremos las expresiones lambda como funciones anónimas, dejando para el tercero los misteriosos árboles de expresión.

Introducción a las lambda
Según la definición en la Referencia del lenguaje C# de MSDN:
"Una expresión lambda es una función anónima que puede contener expresiones e instrucciones y se puede utilizar para crear delegados o tipos de árboles de expresión"
En la Guía de programación de Visual Basic 9 encontramos otra definición, muy simple y pragmática:"Una expresión lambda es una función sin nombre que calcula y devuelve un solo valor. Se pueden utilizar las expresiones lambda dondequiera que un tipo de delegado sea válido"
ScottGu también aportó su granito de arena para hacer el concepto más cercano a los desarrolladores; como siempre, al grano:"Las Expresiones Lambda aportan una sintaxis más concisa y funcional para escribir métodos anónimos."
[...]
"La forma más sencilla para conceptualizar las expresiones lambda es pensar en ellas como formas de escribir métodos breves en una línea."
Partiendo de estas definiciones, y de otras muchas aportadas por Google ;-), está claro que las lambda son funciones, es decir, un conjunto de intrucciones capaces de retornar un valor partiendo de los parámetros que se les suministra, aunque en determinados casos es posible que no reciba ningún parámetro, o que realicen una acción sin retornar nada. Igual que una función tradicional, vaya. Y de hecho, en el cuerpo de una expresión lambda puede haber casi de todo: llamadas a otras funciones, expresiones, bucles, declaraciones de variables...

Sin embargo, a diferencia de los métodos o funciones habituales, las lambdas no necesitan de un identificador, puesto que se declaran in situ, justo en el momento en que van a asignarse a una variable o a utilizarse como parámetro de una función, pasando el destinatario de esta asignación a actuar como delegado, o puntero, hacia la misma, o a ser el contenedor del árbol de expresión que la representa. Ein? Chino, eh? No pasa nada, dentro de poco estudiaremos estos dos usos en profundidad, pero antes vamos a ver cómo se definen las expresiones lambda a nivel de código.
Forma de las expresiones lambda
Las expresiones lambda en C# se escriben según el patrón descrito a continuación, al que le siguen algunos ejemplos que lo ilustran e introducen algunas particularidades.Forma general: parámetros => expresión, donde:
- parámetros: lista de parámetros separados por comas
- "=>" : separador.
- expresión: implementación de las operaciones a realizar

num => num * 2     // Lambda con un parámetro que retorna
                   // el doble del valor que se le pasa.

(a, b) => a + b    // Lambda con dos parámetros que retorna
                   // la suma de ambos.

num => {                        // Lambda con cuerpo que recibe un 
   int x = new Random().Next(); // entero, y retorna la suma de éste
   return num+x;                // con un número aleatorio.
}  

() => DateTime.Now // Lambda que no recibe parámetros
                   // y retorna la fecha y hora del sistema.

msg => Console.WriteLine(msg); // Recibe un parámetro, realiza una
                               // acción y no retorna nada.
 
Como se puede observar, cuando sólo existe un parámetro no es necesario utilizar paréntesis en el lado izquierdo de la expresión, mientras que hay que hacerlo en todos los demás casos. También es interesante destacar que las lambda con cuerpo deben utilizar return para retornar el valor deseado, cuando esto sea necesario.

Y un último dato: fijaos que ni los parámetros ni el retorno de la función tienen indicado un tipo. Aunque puede hacerse, normalmente no será necesario puesto que el compilador podrá inferir (deducir) el tipo a partir de su contexto, más adelante veremos cómo es esto posible. Por tanto, no es necesario escribir código tan extenso como:  (int a, int b) => (int)(a+b)
 
Y hasta aquí este primer post introductorio. En el siguiente trataremos de explicar el papel de las expresiones lambda como funciones anónimas y facilitadoras del trabajo con delegados.

Publicado en: www.variablenotfound.com.



     



Windows Live Writer
2009-03-22T23:50:00.002+01:00
 Aunque lamentablemente no me haya dado  demasiada prisa en hacerlo, tenía ganas de probar este producto. Si habéis utilizado alguna vez el interfaz de edición de Blogger, sabréis que no es precisamente una maravilla, y que a veces complica bastante la publicación de entradas en el blog, y máxime cuando se trata de contenidos con formatos especiales, como puede ser código fuente en cualquier lenguaje.
  Live Writer es una fantástica aplicación de escritorio desarrollada por Microsoft en el contexto de su iniciativa Live, cuyo objetivo es facilitar la edición y publicación de entradas en blogs y, lo más curioso, compatible con los motores más difundidos del mercado: Blogger, WordPress, LiveSpaces, LiveJournal, TypePad, y un largo etcétera. Y cuando digo compatible, al menos con Blogger, me refiero a realmente compatible, una integración casi perfecta, que hace que la edición de entradas sea una gozada.
  Durante la instalación, Writer nos solicita la introducción de los datos de acceso al blog: la dirección, el usuario y clave. Con esta información, y por supuesto previa confirmación por parte del usuario, crea automáticamente una entrada temporal en el blog que utiliza para tomarla como plantilla, eliminándola unos segundos después. De esta forma, cuando estamos escribiendo, podemos acceder a una previsualización del contenido insertada en sobre dicha plantilla, que nos dará una idea muy aproximada, prácticamente real, del resultado final que obtendremos una vez publiquemos la entrada.
  El editor sobre el que escribimos es muy ligero, tiene las opciones justas para poder escribir y dar formato a los textos, siempre de forma visual (el famoso WYSIWYG). Aunque a primera vista puede parecer que se quedará corto, nada más lejos de la realidad; no he echado en falta prácticamente ninguna característica que realmente pudiera hacerme falta durante la escritura: formatos estándar (negritas-cursivas-tachados, subrayados), colores, tablas, alineados, listas, citas,… y siempre generando un código XHTML realmente limpio y muy bien estructurado, a diferencia de otros editores basados en web (como el de Blogger, por ejemplo). 
  Sólo en casos especiales (por ejemplo, la inclusión de una etiqueta <acronym> para mostrar ayuda sobre el significado de WYSIWYG, o la inclusión de código fuente marcado con <code> son los únicos casos en los que he tenido que salirme del editor visual y acceder a la vista de código fuente XHTML para introducir las etiquetas.
  Otro aspecto muy importante es su extensibilidad. Existen un gran número de complementos que pueden instalarse sobre este software para dotarlo de nuevas capacidades no contempladas en el producto base. Por aunque la galería de complementos de Microsoft todavía está a cero no está muy transitada, es fácil encontrar muchos sitios web donde se ofrecen plugins de todo tipo. Por ejemplo, he encontrado uno que a priori puede resultar muy útil, Steve’s Dunn Code Formatter, que permite incluir fácilmente porciones de código formateadas como la siguiente:
  try
{
    calculate(); // Hard work!
}
catch (Exception ex)
{
    Logger.Log(ex.Message);
    throw;
}


Pero lo que sin duda más ha llamado mi atención es la gran facilidad para insertar contenidos multimedia, como álbumes de fotos, vídeos, mapas interactivos, y especialmente imágenes, que es lo que más suelo utilizar en mis posts. En este último caso, es sorprendentemente útil la capacidad de Live Writer para abrir imágenes del equipo local o pegarlas directamente desde el portapapeles (por ejemplo capturas de pantalla), ajustarlas al tamaño indicado e incluso agregarle sobre la marcha efectos como sombreados o reflejos (podéis ver ejemplos más arriba). Por fin se acabó el retoque con aplicaciones externas, tener que subir la imagen al servidor, ver cómo queda, retocarla de nuevo, volver a subirla…
Por último, el hecho de tratarse de una herramienta off-line aporta mucha agilidad, y nos brinda la posibilidad de trabajar en modo desconectado, aunque a costa de perder algunas funcionalidades para las que obviamente es necesario disponer de conexión a internet, como la edición de posts ya publicados, almacenados en el blog, o el envío directo de las entradas. En estos casos, el sistema almacena toda la información en local, para que más adelante podamos enviar los cambios realizados.
Ni que decir tiene que este post está completamente escrito sobre Live Writer, e incluso las imágenes las he generado desde la propia herramienta.
En resumen: una maravilla, imprescindible.
Descarga: Microsoft Live Writer
Publicado en: www.variablenotfound.com.

Variable not found

Aspectos a tener en cuenta al crear sitios web públicos

Interfaz y experiencia de usuario

Seguridad

Rendimiento

SEO

Tecnología

Corrección de errores

Cómo crear un ControllerFactory personalizado para ASP.NET MVC

1. El proceso básico de la petición

2. La factoría de controladores, a corazón abierto

3. Sustituir la factoría de controladores

4. Probar que realmente funciona

Desactivar el inicio en modo diseño de lectura de Word 2003

Recopilación de capítulos gratuitos de libros sobre ASP.NET MVC

Control de errores en acciones ASP.NET MVC

El controlador

Parámetros de HandleError

Acceso desde la vista a la información del error

Cómo crear un plugin sencillo para Live Writer, paso a paso

0. Antes de empezar…

1. Preparación del proyecto

2. Escribimos la clase principal

3. Añadimos metadatos

4. Compilamos el proyecto

5. Añadirle un icono al plugin

6. O, por si no quieres teclear…

Cambiar la ubicación de las vistas en ASP.NET MVC

1. Cómo localiza ASP.NET MVC las vistas

2. Lo que pretendemos

3. Cómo lograrlo

4. Cómo lograrlo, toma 2

5. Conclusión

Sintoniza la onda de Google

Plugin para insertar etiquetas en Live Writer

Compilar las vistas en ASP.NET MVC

Cómo depurar selectores jQuery

Y todavía otras 101 citas célebres del mundo de la informática

Desarrollo de software

Usuarios y usabilidad

Errores

Trabajo en equipo

Conocimiento

Inteligencia artificial

Creatividad

Desarrolladores

Codificación

Empresa

Lenguajes

Predicciones

Internet

Ordenadores

Calidad del software

Complejidad

Videojuegos

yUML, generación de diagramas UML al vuelo

Diagrama de clases

Diagrama de casos de uso

Plantillas de proyectos ASP.NET MVC 1.0 para NUnit

Ya van tres años sin saber nada de la variable

Año 3: la consolidación (mayo 2008 – mayo 2009)

NDepend, analiza a fondo tu código

El entorno gráfico

CQL (Code Query Language)

Instalación e integraciones

Palabras malditas

El hombre que inventó el Control-Alt-Suprimir

ASP.NET MVC: trece preguntas básicas

1. Empecemos desde el principio, ¿qué es MVC?

2. ¿Qué ventajas tiene el uso del patrón MVC?

3. ¿Qué es ASP.NET MVC Framework?

4. ¿Es el primer framework MVC creado para .NET?

5. Como desarrollador de aplicaciones web con ASP.NET, ¿me afectará la llegada de este framework?

6. Entonces, ¿no significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.NET?

7. ¿Vale la pena pasarse a ASP.NET MVC o sigo usando Webforms?

El equipo de desarrollo

Controles y módulos reutilizables

Madurez del framework

Consideraciones sobre el futuro de la tecnología

Beneficios de ASP.NET MVC

Plugin para insertar etiquetas `en Live Writer`