viernes, diciembre 10, 2010

Instalar Ruby on Rails 3 en Windows

He estado explicando en el trabajo los pasos para iniciar una aplicación con rails 3 en windows, así que pensé que seria buena idea escribir los pasos en un post:

A continuación muestro los pasos que sigo para instalar Ruby on Rails por primera vez en Windows.

  1. Lo primero que necesitamos es instalar Ruby, lo podemos descargar desde rubyinstaller.org
  2. Bajar el DLL de sqlite3 y copiarlo a la carpeta bin de la carpeta donde se instaló ruby
  3. Instalar rails, para eso desde la consola de comandos podemos ejecutar "gem install rails". Esto bajará e instalará la última versión estable de Rails.
  4. Ahora si podemos crear una nueva aplicación ejecutando en la consola: "rails new app_name" (donde app_name es el nombre de tu aplicación). Después nos cambiamos al directorio de la aplicación (cd app_name).
  5. Para que la aplicación corra necesitamos instalar las gemas necesarias por nuestro proyecto, si vemos el archivo gemfile que esta en la raíz del proyecto nos damos cuenta de las gemas necesarias (sqlite3-ruby por ejemplo). Para eso podemos correr desde la consola "bundle install"; Lo que pasará es que se instalarán todas las gemas que necesita nuestra aplicación (según el gemfile).
  6. Ahora podemos arrancar nuestro servidor web usando "rails server" (o simplemente "rails s")
  7. Una vez que esta corriendo el servidor web podemos abrir una ventana de nuestro navegador e ir a la dirección "http://localhost:3000" y podremos ver nuestra aplicación corriendo.

Antes estaba usando NetBeans para realizar la mayoría de estas tareas, ahora prefiero hacerlo en la consola, de hecho como editor estoy usando intype (aun sigo pensando que netbeans es una buena opcion, sobre todo si vas empezando).

jueves, octubre 07, 2010

Permiso para hacer TDD

Al estar en platicas/presentaciones sobre TDD (Test Driven Development) donde los participantes son gente que ya esta trabajando. La mayoría de los participantes coincide en que es una buena practica realizar el desarrollo guiado por pruebas. Sin embargo una pregunta que surge frecuentemente es ¿Como convenzo a mi jefe de hacer TDD?

Bueno para empezar no creo que un equipo de desarrollo deba pedir permiso para escribir mejor código, debería ser su obligación. Todos deberíamos de tratar de realizar cada vez un mejor trabajo. Mientras se entreguen resultados con calidad no debería de haber problema con los jefes.

Es claro que el realizar pruebas unitarias aumenta la cantidad de código escrito. Pero solo es eso, mas código y de mejor calidad. Si bien es cierto que eso implica mas tiempo (al principio), también es cierto que el tiempo invertido en el código de una prueba es menor al tiempo que se invierte en mantener el código después o en encontrar un bug que una prueba (y un mejor diseño) nos hubiera evitado. Al final estamos escribiendo mejor código que prácticamente ya esta probado. Y al realizar TDD frecuentemente el tiempo para realizar prueba e implementación mejora.

Entonces al realizar TDD pasa lo siguiente:

  1. Mejora el diseño
  2. Mejora el código, es mas fácil modificarlo después
  3. Aumenta el numero de clases (código)

Ahora yo te pregunto ¿Necesitas convencer a tu jefe de que te deje escribir una clase?

Creo que la respuesta es no; así que solo hazlo. Escribe tus pruebas unitarias sin hacer una junta con tu jefe. Hazlo como parte del desarrollo normal del proyecto. Pero, si la respuesta es sí, es decir que necesitas convencer a tu jefe que te deje escribir una clase o un archivo con código entonces quizás tengas un problema mas grande.

Si tu estas convencido que es lo mejor, no esperes a convencer a otros para sentir que tienes la razón. Solo haz lo mejor.

jueves, septiembre 30, 2010

Model View Presenter en ASP.NET WebForms

En la reunión 37 de la comunidad Tijuana Net, realizada el pasado 29 de Septiembre en la Universidad Autónoma de Baja California. Hablé sobre el patrón MVP (Model View Presenter) en aplicaciones escritas usando ASP.NET WebForms.

Actualmente considero una mejor alternativa utilizar el framework ASP.NET MVC sobre WebForms sin embargo, por diversos motivos, muchos de nosotros aun tenemos que trabajar en aplicaciones escritas con WebForms. Es por ello que me pareció buena idea presentar como aplicar este patrón y así quienes aun trabajamos en WebForms podamos obtener algunas de las ventajas de separación de intereses y capacidad de pruebas que brinda MVC.

En la presentación inicie una aplicación WebForms de manera “tradicional” después la modifiqué para poder aplicar el patrón MVP y así tener la posibilidad de realizar pruebas unitarias al código que antes estaba en el code behind. En la segunda parte de la presentación modifiqué una vez mas el código de la aplicación para poder tener una estructura de clases reutilizable, además de utilizar un contenedor de dependencias.

Abajo pueden ver la presentación y el material que se utilizó. Agradezco sus comentarios que puedan ayudar a mejorar siguientes presentaciones. De igual forma si tienen alguna duda sobre la presentación no duden en hacérmela llegar a través de los comentarios del blog.

Agradezco también a todos los asistentes su presencia y participación durante la reunión. Y claro a la comunidad Tijuana Net y a su líder Gabriel Flores por hacer posible estas reuniones.

Screencast

Fotos

Proyecto de ejemplo



Reuniones previas mencionadas (para ver los screencasts):
Test Driven Development
IoC containers

lunes, julio 26, 2010

Eduardo Ramón Cornejo Portillo

 

moto_0620

Mi hijo Eduardo Ramón nació el 24 de Julio del 2010 a las 5:41 am. Le gusta dormir de día y estar despierto en la noche.
Peso 3.3 Kg y midió 0.52 m al nacer.

Su hermana, mamá y papá estamos muy contentos.

martes, julio 06, 2010

martes, junio 29, 2010

Iniciando con RubyOnRails Parte 3

Aprovechando un poco de tiempo libre que tenia agregué algo de validación a la aplicación “Traje”, agregue el modelo y empecé el controlador para registrar invitados a las reuniones. El screencast dura 7 minutos aproximadamente

lunes, junio 28, 2010

Iniciando con RubyOnRails Parte 2

Sigo aprendiendo RubyOnRails, en este screencast veo como agregar un campo a mi modelo, generando una migración. También veo como usar vistas parciales para reutilizar partes en las vistas.

jueves, junio 24, 2010

Iniciando Con RubyOnRails

Hace tiempo que querido aprender RubyOnRails y por una cosa o la otra siempre lo posponía. Hace poco inicio la comunidad de Ruby en Tijuana lo cual me ha inspirado a aprender RubyOnRails aprovechando que puedo tener el apoyo y ayuda de la comunidad mientras aprendo.

Acá entre nos, una de las razones por las que no iniciaba con ruby era que pensaba comprarme una Mac. He visto que la mayoría de los desarrolladores de ruby es lo que usan. Pero realmente no la necesito y además tomando en cuenta que próximamente seré papá nuevamente :-), ese es un gasto que tendrá que esperar. Sin embargo puedo aprender sobre RubyOnRails desde Windows.

He decidido grabar lo que voy aprendiendo, en videos cortos de no mas de 10 minutos, para que así alguien que también se quiera animar quizás pueda ayudarse de mi experiencia. De igual forma alguien que tenga experiencia y vea lo que estoy haciendo pueda orientarme a través de los comentarios del blog, lo cual agradeceré.

Para iniciar instalé ruby, rails y sqlite3 sobre Windows usando la información de esta página. Intente con varios editores pero al final no encontré ninguno que me convenciera, además estoy muy acostumbrado a usar un IDE; así que por lo pronto iniciaré la aplicación usando NetBeans (Ruby Bundle).

La aplicación que intentaré realizar es un sitio donde pueda organizar “Reuniones de Traje”. Son reuniones donde cada uno de los asistentes trae algo para la reunión, el traje se refiere al verbo traer y no a la vestimenta (ej. “yo traje botana”) .

Iniciando con la aplicación (screencast de 7 minutos y fracción)

lunes, mayo 24, 2010

MEF Parte 4 - Imports

Usando el mismo ejemplo de la aplicación “Saludador” (Iniciada en el Lanzamiento de VisualStudio 2010 en Tijuana) en el siguiente video muestro otras opciones al momento de importar partes de nuestro objeto usando MEF. En concreto ImportingConstructor y AllowDefault.

Entradas Relacionadas:
Introducción a MEF Parte 1
Introducción a MEF Parte 2
Introducción a MEF Parte 3 - Recomposición

sábado, mayo 22, 2010

Introducción a MEF Parte 3 - Recomposición

Continuando con la aplicación de ejemplo sobre MEF, en esta ocasión muestro el concepto de recomposición de MEF. El cual permite cargar componentes de forma dinámica mientras nuestra aplicación corre.

Algo a notar con este ejemplo fue que lo realice utilizando la librería de MEF que se encuentra en codeplex, usando VisualStudio 2008 con el .Net Framework 3.5. En lugar de utilizar VS2010 con el .Net 4.0 como lo había venido haciendo. Por ahora el código es el mismo para ambas versiones del framework.

Como siempre mi meta es que estos videos (screencasts) no pasen de 5 min, por lo tanto si fui muy rápido, me falto algo o me equivoque, les agradeceré sus comentarios.

También se puede ver el video desde screencast.com

Post Relacionados:
Introducción a MEF Parte 1
Introducción a MEF Parte 2

viernes, mayo 21, 2010

Como usar Unity IoC Container en ASP.NET MVC

Una de las ventajas sobre la plataforma ASP.NET MVC sobre WebForms es que podemos utilizar el principio de inversión de control usando la inyección de dependencias (generalmente a través de los constructores). De tal forma que nuestros controladores reciben parámetros en los constructores. Esto hace que la plataforma MVC no pueda, por si sola (usando el DefaultControllerFactory), construir nuestros controladores usando el constructor que recibe parámetros. Es por ello que vemos ejemplos (como el proyecto plantilla de VisualStudio) donde se sobre carga el constructor con uno que no recibe parámetros y es el propio controlador el encargado de crear sus dependencias. Lo cual va en contra del principio de inversión de control.

Resolver este problema es muy sencillo, basta con crear nuestro propio IControllerFactory que es el contrato que utiliza la plataforma MVC para construir los controladores. En este ejemplo nuestro controller factory hará uso de Unity un Contenedor de dependencias (IoC container) para administrar las dependencias.

La forma mas sencilla de crear un IControllerFactory es heredar del DefaultControllerFactory y redefinir el método GetControllerInstance. Aquí muestro el código:

public class UnityControllerFactory: DefaultControllerFactory
{
readonly IUnityContainer container;

public UnityControllerFactory(IUnityContainer container)
{
this.container = container;
}

protected override IController GetControllerInstance(
RequestContext requestContext, Type controllerType)
{
if (controllerType == null )
return null;

return (IController)container.Resolve(controllerType);
}
}





Como puede verse el UnityControllerFactory recibe un contenedor con las dependencias registradas, el cual utiliza para crear los controladores en el método GetControllerInstance. No hace falta registrar los controladores en el contenedor ya que Unity puede construir instancias de tipos no registrados.



Una vez creado nuestro controller factory es necesario indicarle a MVC (en concreto al ControllerBuilder) que utilice nuestro UnityControllerFactory para crear los controladores; el código queda algo así:




var container = new UnityContainer();
//aqui se registran las dependencias
ControllerBuilder.Current.SetControllerFactory(
new UnityControllerFactory(container));





Esto se debe ejecutar al iniciar la aplicación (el Application_Start() en el Global.asax.cs).



Como puede verse con muy poco código podemos estar usando un IoC container en nuestra aplicación ASP.NET MVC, no es complicado y el UnityControllerFactory puede reutilizarse en otras aplicaciones MVC. Así que, ya lo saben, no hay pretexto para no utilizar un contenedor de dependencias.

jueves, mayo 20, 2010

Singleton por cada HTTP Request usando Unity IoC

Hay ocasiones en las que necesitamos tener un objeto compartido por varios objetos en nuestra aplicacion web, similar al patrón singleton, pero solo para esa petición HTTP. Es decir sin compartirlo en toda la aplicación.

Hace tiempo escribí sobre como compartir un LinqToSql DataContext por cada request en una aplicación web. Ahora utilizando Unity podemos lograr ese comportamiento y dejar que el contenedor de dependencias se encargue de darnos la instancia adecuada.

Para manejar el tiempo de vida de las instancias unity utiliza lo que llama LifetimeManager, entonces lo primero que debemos hacer es crear nuestro LifetimeManager, en este caso lo llamaré HttpRequestLifetimeManager y heredamos de la clase abstracta Microsoft.Practices.Unity.LifetimeManager y debemos de definir 3 metodos GetValue, RemoveValue y SetValue.

public class HttpRequestLifetimeManager: LifetimeManager
{
object key;

public HttpRequestLifetimeManager(): this(null)
{
}

public HttpRequestLifetimeManager(object key)
{
this.key = key;
}

public override object GetValue()
{
if (key == null) return null;
return HttpContext.Current.Items[key];
}

public override void RemoveValue()
{

}

public override void SetValue(object newValue)
{
if (key == null)
key = newValue.GetType();

HttpContext.Current.Items[key] = newValue;
}
}


Lo que hace el HttpRequestLifetimeManager es guardar la instancia de la clase en el Items dictionary con el key que se le especifique en el constructor, si no se ha especificado un key, entonces utilizará el tipo del objeto para identificarlo en el diccionario.


Una vez teniendo nuestro LifetimeManager solo es cuestión de especificarle a unitity, al momento de registrar nuestro tipo, que utilice nuestro HttpRequestLifetimeManager para manejar el tiempo de vida de nuestra instancia.


Por ejemplo supongamos que tenemos declarados algunas clases (posiblemente repositorios) que recibe el constructor un DataContext algo como esto:


public class UserRepository : IUserRepository       
{
readonly MyDataContext db;

public UserRepository(MyDataContext db)
{
this.db = db;
}
...

Si queremos que todos nuestros repositorios compartan el mismo MyDataContext por cada request, entonces configuramos nuestro contenedor (generalmente en el Global.asx.cs) de la siguiente manera:


var container = new UnityContainer();                             

container.RegisterType<IAccountRepository, AccountRepository>();
container.RegisterType<IUserRepository, UserRepository>();

container.RegisterType<MyDataContext>(
new HttpRequestLifetimeManager(), new InjectionConstructor());

Ahí podemos ver como al registrar MyDataContext paso una instancia de la clase HttpRequestLifetimeManager para usar la misma instancia durante todo el request y además le paso un instancia de InjectionConstructor para indicarle que utilice el constructor sin argumentos de nuestra clase MyDataContext.


Una vez hecho esto nuestro contenedor se encargará de entregarnos repositorios que comparten el mismo datacontext por cada request.

jueves, abril 15, 2010

Introducción a MEF Parte 2

Siguiendo con el ejemplo del post anterior sobre MEF (La aplicación para consola “Saludador” que presente en el Launch de Visual Studio 2010 en Tijuana). En este screencast muestro como usar MEF para que alguien que no tiene acceso al código fuente de la aplicación, pueda extenderla (plugins) y agregar sus propios saludos.

Debido a que los videos solo los quiero realizar de 5 min, tuve que irme (quizás) un poco rápido. Como siempre cualquier comentario es bienvenido.

Post relacionado: Introducción a MEF Parte 1

Código Fuente:

martes, abril 13, 2010

Introducción a MEF Parte 1

En el pasado Launch de Visual Studio 2010 en Tijuana presenté el tema: Extendiendo Aplicaciones con MEF. Debido a que olvide grabar la presentación, quise rehacer el ejemplo dividiéndolo en screencasts de no mas 5 min. Usando el mismo ejemplo que en la sesión. Espero sirva como introducción para quienes quieran conocer sobre MEF (Managed Extensibility Framework).

El ejemplo trata de una aplicación para consola que tiene una lista de saludos, el usuario puede seleccionar el saludo que guste y ejecutarlo. La idea es que el saludador pueda ser extendido, de tal forma que yo (como desarrollador de la aplicación) o cualquier tercero pueda agregar saludos a la aplicación.

En este primer video, muestro el funcionamiento básico de MEF (Importar, Exportar y Componer).

Post Relacionado: Introducción a MEF Parte 2

martes, marzo 30, 2010

Singleton con Unity

En la pasada reunión de la comunidad TJ.Net presenté el tema IoC, donde mostré un ejemplo usando el contenedor de dependencias Unity. Una de las preguntas de los asistentes fue sobre si unity siempre crea nuevas instancias para los tipos registrados y como podría indicarle que utilice siempre la misma (lo que se conoce como el patrón singleton). Al momento de la reunión conteste que por omisión Unity crea una nueva instancia cada que resuelve un tipo, pero que sí era posible indicar un comportamiento distinto, sin embargo no recordé la manera exacta para ello. Bueno pues aquí la respuesta.

Al registrar un tipo con el método registerType<TFrom, TTo> podemos pasarle un LifetimeManager el cual será encargado de manejar el tiempo de vida de las instancias resueltas por el contenedor. Podríamos crear nuestro propio LifetimeManager, pero (para el caso del patrón singleton) unity ya cuenta con uno del tipo ContainerControlledLifetimeManager.

Así que lo único que necesitamos para que nuestro contenedor implemente el patrón singleton al momento de resolver nuestro tipo es pasarle una instancia de la clase ContainerControlledLifetimeManager. Utilizando el mismo ejemplo de la reunión, podríamos suponer que necesitamos que nuestro INotificationService sea siempre la misma instancia para todos los componentes que requieran usarlo. Entonces el código donde registramos nuestro tipo quedaría así:

container.RegisterType<INotificationService, NotificationServiceWithTemplates>(
new
ContainerControlledLifetimeManager());
Con esto logramos el patrón singleton con unity.

jueves, marzo 25, 2010

Inversión de Control - IoC

El día de ayer (Miércoles 24 de Marzo 2010) fue la Reunión 33 de la comunidad TJ.NET donde presenté el tema “Inversión de control (IoC)”. La reunión se llevo a cabo en las instalaciones del Instituto Tecnológico de Tijuana.

En la reunión presenté una introducción a lo que se refiere el principio IoC; con ejemplos como: el usar eventos en nuestros componentes para la interfaz de usuario y el utilizar un Contenedor de dependencias (IoC Container) para realizar una Inversión de control aplicando el patrón de diseño “Inyección de dependencias”. Como ejemplo se refactorizó una aplicación Web ASP.NET para usar un IoC Container (Unity en este caso). La presentación que fue grabada y el material (diapositivas y archivos) pueden ser descargados desde la página del evento en la comunidad.



Fotos

 


Presentación y archivos

 

jueves, febrero 11, 2010

Iniciando con MongoDB desde .Net

En el post anterior mostré como iniciar con mongoDB utilizando las herramientas que obtenemos al descargar la base de datos. Ahora quiero mostrar las mismas operaciones pero desde .Net (específicamente C#). Para esto es necesario descargar el driver para hablar con mongo desde .net

Para abrir la conexión a la base de datos debo crear una instancia de la clase MongoDB.Driver.Mongo, llamar el método Connect y después hacer un getDB con el nombre de la base de datos a la que quiero conectarme. Tomando el ejemplo anterior de la libreta de direcciones, el código queda así:

var mongo = new Mongo();
mongo.Connect();
var db = mongo.getDB("AddressBook");

una vez conectado a la base de datos obtengo una referencia a mi colección de documentos llamada “Contacts” (similar al concepto de tabla en una base de datos relacional).

var contacts = db.GetCollection("Contacts");

Ahora para insertar documentos creamos instancias de la clase MongoDB.Driver.Document (el cual es básicamente un diccionario de datos), le damos valores y lo insertamos a nuestra colección de contactos; como en el post anterior inserto 2 documentos a nuestra colección:

var mario = new Document();
mario["Name"] = "Mario";
mario["Phone"] = "1234567";
contacts.Insert(mario);

contacts.Insert(new Document()
.Append("Name", "Humberto")
.Append("Phone", "5555555")
);

Puede observarse dos formas de crear documentos. Una vez teniendo dos contactos (Mario y Humberto). Voy a actualizar al contacto con el nombre “Mario”. Aprovechando que estoy usando una base de datos no relacional, cambiaré las campos del documento, para ello utilizo el método Update de la colección contacts pasando como primer parámetro el nuevo documento y como segundo parámetro un documento que me sirve como selector

contacts.Update(
new Document()
.Append("FirstName", "Mario")
.Append("LastName", "Cornejo")
.Append("Phone", "1234567")
, new Document()
.Append("Name", "Mario")
);

Para hacer solo la actualización del campo teléfono del contacto con el nombre “Humberto” puedo hacer lo siguiente:

var humberto = contacts.FindOne(new Document().Append("Name", "Humberto"));
humberto["Phone"] = "4444444";
contacts.Update(humberto);
Aquí utilice el mismo método Update, pero solo le pase como parámetro el documento actualizado. Como se puede ver, la forma de realizar las operaciones desde C# es muy similar a como lo haríamos desde la consola usando la aplicación Mongo.exe

miércoles, febrero 03, 2010

Iniciando con MongoDB

Recientemente he empezado a jugar con la base de datos no relacional MongoDB, grabe un mini-screencast donde muestro la características básicas de esta base de datos orientada a documentos.

También puedes ver el video directamente desde www.screencast.com