Microsoft acababa de lanzar Visual Studio 2010. Con él se vienen, nuevos e importantes cambios. Algunos cambios incluidos en el nuevo Framework .NET 4.0 están modificando el paradigma para los programadores.

De las nuevas características, la más llamativa sin lugar a dudas se halla en el  factor dinámico. Microsoft incluyó al framework un nuevo tipo denominado “dynamic”, buscando aliviar el trabajo de los programadores.

Con la programación dinámica muchas de las cosas que anteriormente se realizaban en tiempo de compilación, se podrán hacer en tiempo de ejecución. Esto puede ser muy práctico para escribir código, dado que no necesitaremos programar basados en tipos de objetos, sino más bien basándonos en el comportamiento de los mismos.

Sólo mira el siguiente código y podrás entender en qué consiste dynamic.

dynamic e = 1;
e.Prueba();

int w = e + 2;

Console.Write(e);
Console.Write(w);

En la línea 1, creamos un objeto dynamic. En la siguiente línea, llamamos a un método Prueba(), el cual el compilador lo pasará por alto. De este modo, aunque te parezca extraño, este código compila sin errores. Pero cuando ejecutemos la aplicación, lanzará una excepción en tiempo de ejecución, porque el tipo Int no expone un método llamado “Prueba”.

Por eso es importante diferenciar las cosas que se realizan en tiempo de compilación y cuales en tiempo de ejecución. Los objetos dynamic tienen una particularidad, todas sus propiedades y comportamientos se resolverán en tiempo de ejecución.

Lo malo de la programación dinámica:

Todas las ventajas que observamos en la programación dinámica pueden ser favorables, aunque también tiene su lado negativo.  Una aplicación que lance excepciones en tiempo de ejecución arroja un grado de incertidumbre para el comportamiento de la misma. También debemos olvidarnos de algunas características de los lenguajes estáticos como por ejemplo: Herramientas Intellisense, performance y el escalamiento de las aplicaciones.

DLR

Para que la programación dinámica sea posible, Microsoft incorporó una importante capa más sobre el CLR, a la que llamó DLR.

El DLR está encargado del enlace dinámico y de suministrar un medio o soporte común para la comunicación entre distintos lenguajes como C#, VB, IronPyton, IronRuby, etc.

Es un complemento al CLR y por lo tanto no lo suplanta.  El DLR se trata de un set o conjuntos de dlls, librerías, etc. que se ubican sobre el CLR, haciendo de puente entre los lenguajes dinámicos y proporcionando un marco en tiempo de ejecución para los lenguajes y un punto de enlace entre lenguajes estáticos y no estáticos.

Ya llevo unas cuantas semanas probando Django. Primero empecé leyendo el libro “The Definitive Guide to Django” que por cierto lo recomiendo, es un libro muy bueno que posee un lenguaje claro que nos ayudará en la introducción a esta nueva tecnología.

Al principio me costo un poco entender como trabaja el framework, hay cosas que son distintas a las que encontramos en C# pero al final se entiende su metodología y realmente estoy muy conforme con el.

Ahora haré una pequeña lista de algunas características llamativas de este framework que pueden interesarte.

1. ORM incorporado: Cuando empecé a leer la documentación sobre el ORM de Django me prepare para encontrarme con algo complejo pero no fue así en realidad. La definición de modelos en Django es una tarea sencilla y puedes trabajar con distintos motores de bases de datos como: MySQL, SQL Server, SQLite, ORACLE,  etc.
2. Manejo de URLs: Django utiliza expresiones regulares para mapear las distintas URLs con las vistas. Sólo tienes que editar un archivo y allí colocar las distintas reglas de matcheo. Muy práctico y sencillo de utilizar.
3. Código pragmático: Django es un framework poderoso, sus extensiones de Python son muy buenas. Tus líneas de código quedarán cortas, bellas y muy claras. ¿Qué mas quieres?
4. Filtros: Cuando diseñas vistas para Django es probable que tengas que usar filtros. Son funciones o métodos para procesar variables o alterar datos en la vista.
5. Vistas Genéricas: Django quiere ahorrarnos el trabajo de escribir tanto código y sin duda que donde más escribimos código HTML es en las vistas. Para esto están las vistas genéricas. Con unas pocas líneas de código podremos crear vistas para nuestro modelo.
6. Administración Automática: Django te brinda todo un backend de administración para tu modelo sin escribir una sola línea de código. Luego, si necesitas, puedes cambiar esta administración, ya sea la visualización, cambios de items, etc, Todo estos cambios puedes hacerlo utilizando la api de Django.
7. Facilidad: Programar en Django es un placer, de por si ya el lenguaje Python es una belleza de simplicidad y con el agregado otorgado por el framework hacen una combinación casi irresistible.
8. Documentación: La documentación de Django es excelente. Esto fue uno de los motivos por lo que elegí esta tecnología.
9. Velocidad: Django se desempeña muy bien en servers Apache, no hice pruebas aun en servers Windows pero creo que también funcionarán bien. Django es bastante mas rápido que cualquier otro framework MVC, por ejemplo ASP.NET MVC te parecerá una carreta empantanada comparado con este framework :P.
10. Seguridad: Django posee un sistema propio de membresía, el mismo lo podremos manejar desde la administración automática.

OpenID es un sistema de membresía descentralizado que permite mantener nuestros perfiles y passwords seguros en un solo lugar y compartirlo con los sitios que deseamos tener acceso. El sistema OpenID remplaza el popular “Login” y “password” de los diferentes sitios que accedemos por un sistema abierto, estándar y completamente seguro.

Existen muchísimos proveedores de OpenID, casi todas las empresas proveedoras de servicios importantes en la red brindan un servicio de OpenID para sus usuarios.

Para crear una cuenta OpenID deberás primer escoger un proveedor de la lista, luego crear tu perfil (que es algo muy parecido a crear un perfil en cualquier otro servicio web) y luego podrás acceder a tus datos de OpenID para utilizarlos en los servicios que desees.

Algunos Proveedores OpenID:

• Perfil Google
• Yahoo
• myid.net
• myopenid.com
• claimid
• identity.net

Ver lista completa de Proveedores OpenID

Lo necesitábamos. Un lavado de cara para este sitio ;). Gracias a los reportes de errores y sugerencias de ustedes es que ahora estoy implementando esta nueva versión del portal que implementa nuevas características y un gran cambio en su morfología interna.

 
Foto: flickr.com

Luego de unos meses de trabajo en el rediseño de yoprogramo.net pongo en línea las nuevas reformas en el sitio.

Casi un 90% del código lo escribí en el IDE MonoDevelop, en su momento tenia esperanzas de instalar esta nueva versión sobre Linux con Apache (mod_mono). Pero esto no pudo ser por las incompatibilidades con MONO en distintas DLLs como NhIbernate y Castle.

Informe de incompatibilidades de MoMA:

Cambios en yoprogramo.net:

• Login OpenID: La membresía de yoprogramo.net ahora está basada en DotNetOpenAuth. Con esta fantástica librería pude incluir fácilmente esta característica al portal.
  Con respecto a los usuarios de la anterior versión, pasaron a ser todos usuarios anónimos. Si lo deseas, puedes registrarte ahora con tu cuenta OpenID desde aquí.
• Usuarios anónimos: Ahora no es necesario ser usuario del portal para enviar una respuesta a una pregunta, solo será necesario que introduzcas tu nombre, email y sitio web.
• Visualización de código: Cambié los estilos para las porciones de código, ahora uso SyntaxHighlighter
  
• Otros cambios: Quizás los cambios más importantes no se vean, pero hay muchos cambios en la estructura del portal y el modelo. Por ejemplo, antes habían objetos como Post y Respuesta, ahora todo es tomado como simples posts. De esta manera logre simplificar mucho los procesos en los servicios y el diseño de las tablas.

No quiero terminar este post sin antes agradecer a todos los que me apoyaron en este sitio, José, Mario, Jorge, Milagros, Darío, Alan y la lista no termina ;). Muchas gracias y espero que les gusten estos cambios. Cualquier duda que tengan, informe de errores o sugerencias será siempre bienvenida.

Con esta impresionante herramienta podremos mapear nuestros objetos sin necesidad de crear un solo XML o cualquier otra clase de archivo, también es posible crear tests, etc.

Aquí podemos ver un ejemplo donde es posible apreciar el poderío de esta fantástica herramienta.

var fObj = FantasticDSL()
            .LoadModel(“model.dll”)
            .UseNH.CreateDataMaps
            .PersistenceIn.SQLServer2008;

bool tests = fObj.CreateUnitTests.UsexUnit.Run.AllTests();

¡Que la inocencia les valga! ;)

Desde yoprogramo.net va un sincero y fuerte abrazo para todos los programadores deseándoles una muy, pero muy, feliz navidad.

Al leer el post de Darío llamado “Predicados y Especificaciones” y luego de hablar ayer con José quise implementar lo que Darío escribió en ese post usando lo que me enseño José. La idea es utilizar el delegado Func<T, bool> en vez de un delegado común.

En el código fuente de yoprogramo.net existen muchas partes donde necesito especificar cosas, ya sea para consultas, etc. Para esto el patrón de especificaciones anda perfecto, les muestro lo que yo hice.

Mi función antes de usar especificaciones:

public IList<IPost> TraerPostsParaHome(int? top)
{
    var query = (from s in TraerTodosSinSpam()
                 where !s.Bloqueado
                 orderby s.PostedAt descending
                 select s).Take(top ?? 100).ToList();
}

Y ahora, luego del refactory quedó así:

public IList<IPost> TraerPostsParaHome(int? top)
{
    return TraerTodosSinSpam()
            .Where(PostEspecificacion.EsApto)
            .OrderByDescending(PostEspecificacion.OrdenarHomePor)
            .Take(top ?? 100)
            .ToList();
}

Mi clase PostEspecificacion:

namespace YoProgramo.Core.Especificaciones
{
    public class PostEspecificacion
    {
        public static Func<IPost, bool> EsApto
        {
            get
            {
                return x => !x.Bloqueado;
            }            
        }

        public static Func<IPost, DateTime> OrdenarHomePor
        {
            get
            {
                return x => x.PostedAt;
            }
        }
    }
}

Los controladores son una parte vital de nuestra aplicación, en ellos ocurren procesos importantes del lado del servidor y muchas veces los controladores culminan albergando muchas líneas de código.

Tener controladores gordos no está muy bien que digamos. Particularmente, cuando programo controladores no me gusta llamar a Repositorios, prefiero utilizar instancias de servicios.

Para despejarme estas dudas pregunté esto en la comunidad AltnetHispano y muy gentilmente los muchachos me contestaron.

¿Porque los controladores suben de peso?

• Al usar directamente Repositorios en nuestros Controladores es probable que terminemos incluyendo Lógica de Negocio en ellos.
• Hacer reiterativas llamadas a servicios también es malo. En general, si esto es necesario es probable que necesites replantearte donde deberían ir esas líneas de código.

Recordemos, que en arquitecturas DDD, los repositorios pertenecen al Dominio pero en realidad son implementados o inyectados en la capa de infraestructura.
En la capa de servicios de aplicación, solo existen interfaces de servicios que luego son inyectados por algún IoC a los servicios con comportamiento.
Un controlador debería poder acceder al dominio para tener acceso a las interfaces de las entidades.

Conclusión:

Usar servicios de aplicación y que estos sean los encargados de acceder a los repositorios es definitivamente una buena idea.
Y recordemos siempre, los controladores deben ser lo más pequeños posibles y fáciles de entender.

Más información: The Fat Controller must die!

Definición de TDD:

TDD es una metodología de trabajo donde su principal área de trabajo son los Tests, el desarrollo de una aplicación basada en TDD consiste en  diseñar los tests y luego ir superándolos por medio del refactoreo de la aplicación.

Muchos también dicen que TDD es la suma de dos técnicas de programación: TFD y Refactorización. Con respecto a TFD, es la técnica que a muchos programadores les parecerá extraña y establece inicialmente una pauta que consiste en la creación de los tests primero antes que todo, inclusive antes de cualquier porción de código de nuestra aplicación.

Ciclos TDD:

En esta metodología existen pocos pero importantes pasos a seguir, dichos pasos forman el corazón de TDD y no deberíamos saltear ninguno de ellos.

Crear un Test: Escribimos un código que representará a nuestro test o prueba para un determinado requerimiento a superar.

Creación de código y refactoreo: Este es uno de los puntos más importante de TDD, dado que en el es donde modelamos la aplicación basándonos en superar nuestras pruebas.

Ejecutar tests: Consiste en correr todos los tests y verificar que no hayan fallos. En caso de haberlos deberemos refactorizar para lograr pasar las pruebas satisfactoriamente.

Crear nuevos test: El desarrollo continúa y agregamos mas tests para dar comienzo otra vez a todo el ciclo.

Para los que quieran hacer un “not in” en Linq es muy fácil, solo hay que usar el operador ! en el clausula Where. Aquí publico el método TraerTodosSinSpam() del servicio PostServicio de la nueva versión de este portal:

public IList<IPost> TraerTodosSinSpam()
{
    var spamsReportados = 
        _spamReportadoServicio.TraerTodasLasEntidades();

    var query = (from c in _postRepositorio.TraerTodos()
                where !(from o in spamsReportados
                        select o.Id).Contains(c.Id)
                 select c).ToList<IPost>();

    return query;            
}