Desarrollo en NET

Resumen de blog Enero2

2011-02-06T11:28:00.002-08:00

Posts recientes en el blog http://blog.decisionesinteligentes.com

Por cierto los invito al Webinar sobre Ruby on Rails organizado por @JoeDayz, este próximo 8 de febrero del 4pm a 6pm PST. Se pueden registrar en la pagina de JoeDayz.

Resumen de blog Enero

2011-01-23T10:42:00.002-08:00

Posts recientes en el blog de http://blog.decisionesinteligentes.com

Resumen de blog

2010-12-30T11:50:00.003-08:00

Posts recientes en el blog de http://blog.decisionesinteligentes.com

EmpleosTI

2010-12-08T11:18:00.002-08:00

El día de hoy anuncio un sitio para publicar ofertas de trabajo relacionadas con Tecnologías de Información, el sitio es empleosTI.

El sitio es muy sencillo de utilizar, no requiere de registro ni para publicar ofertas ni para consultarlas, las ofertan publicadas son enviadas automáticamente a Twitter a través de la cuenta @empleosti_dein, además de tener la posibilidad desde la vista de una oferta de enviarla por email, a Twitter o a Facebook.

Para ver el funcionamiento del sitio les dejo el siguiente video:

Actualmente el sitio aún esta en fase beta, es "usable" y funcional, y no tiene costo para publicar ofertas, así que si están buscando personal de TI.

El sitio salió como idea después de la VAN que di a @altnethispano sobre Ruby on Rails, inicialmente como una aplicación de concepto, después de verlo funcionar decidí hacerlo público como un servicio.

Resumen de posts

2010-12-04T15:03:00.003-08:00

Posts recientes en el blog de http://blog.decisionesinteligentes.com

Separación del blog

2010-11-29T10:10:00.002-08:00

Durante este pasado fin de semana ha habido una separación del blog, esto a implicado la creación de un nuevo blog en http://blog.decisionesinteligentes.com, donde ya he copiado todos los posts referentes a Ruby y Ruby On Rails, el blog original http://mario-chavez.blogspot.com seguira pero con contenido, quizas, un poco mas personal.

El feed RSS del nuevo blog es http://feeds.feedburner.com/DecisionesInteligentes y la cuenta de twitter queda como @decisionesin

Wash, DRY and fold

2010-11-18T16:59:00.003-08:00

DRY es una de las recomendaciones mas mencionadas en el desarrollo de software, DRY es el acronimo de "Don't Repeat Yourself" o "No te repitas" en español.

DRY lo que promueve es la no duplicidad de código fuente en nuestro software, ya que la duplicidad acarrea una serie de problemas de mantenimiento, inconsistencia en la funcionalidad, falta de claridad, etc.

Es por eso que en nuestros desarrollos debemos de buscar patrones de código que se repiten una y otra vez para tratar de extraerlos, abstraerlos y reutilizarlos.

El origen de este post es precisamente, que en un desarrollo en Ruby On Rails que estoy haciendo, encontre estos patrones repetitivos en mis controladores. La mayoría de ellos trabajan haciendo CRUD de manera muy tradicional, por lo tanto las acciones de: Index, Show, Edit, New, Create, Update y Destroy tienen código muy similar a excepción de las referencias al modelo sobre el cual actúan.

Buscando una solución para eliminar esto, me encontré con el proyecto de José Valim (@josevalim) Inherited Resources, el cual trata precisamente sobre como mantenerse DRY.
Algo importante es que Inherited Resources no cambia nuestra forma de trabajar al nombrar variables con nombres genéricos para que puedan ser usadas en nuestros controladores, el se encarga de nombrar las variables de acuerdo a la convención de Rails por lo tanto su uso es bastante transparente.

El post no se trata sobre Inherited Resources, por lo que aqui les dejo ligas a material de referencia para quien guste conocer mas:

¿Bueno entonces de que se trata el post? Es sobre DRY, pero mi implementación de DRY para un problema particular.

En el proyecto que estoy trabajando, tuve la necesidad de que la aplicación de Rails consumiera datos de un API de otra aplicación, la aplicación, de hecho son varias aplicaciones, que contiene lo datos no tiene API, por lo que con una aplicación de Sinatra, le cree un API Rest para que pueda ser consumida con la aplicación Rails - la aplicación de Rails y las aplicaciones sin API están en diferentes servidores/redes -. Esta API Rest puede ser consumida desde Rails a través del uso de ActiveResources, que aparentan ser modelos normales de Rails, pero que en realidad hacen llamados remotos a través de http para obtener sus datos.

En mi problema, tengo un controlador con diversas acciones, donde cada acción hace una llamada Rest a diferentes modelos y muestra los datos obtenidos, hay llamadas que traen una colección de objetos y otras que solamente traen un objeto en particular.

El patron que comencé a ver en las diversas llamadas para traer colecciones de datos fue:

así como la variación siguiente, también para traer colecciones de objetos:

La diferencia entre ellos es que en ocasiones se pasa el ID y en otras no, fuera de eso son muy similares.

Por otro lado, al traer un solo elemento el patrón era el siguiente:

Donde se pasa el ID en otro orden como parametro y la llamada ya no es al metodo all, es a find.

Este código se repetia una y otra ves en mi controlador donde solo cambiaba el nombre del Modelo, así como las variables @modelos y @modelo que es a donde se asignan los datos una vez que se obtienen.

Mi intención aquí es hacer que esto funcione DRY, y con la ayuda de un poco de metaprogramacion es fácil el lograrlo.

La idea es que pudiese hacer algo como:

fetch_resources! :modelo

fetch_resource! :modelo

Para obtener mis datos a través de Rest para el modelo adecuado y que se cargara la variable correspondiente con los datos correctos.

Así es como llegue al código que se muestra arriba. El método en singular trae un solo modelo a través de Rest y el metodo en plural trae una colección de modelos, opcionalmente ambos pueden aceptar un filtro en forma de Hash, y el modelo se indica a través de un símbolo.

El metodo fetch! es el que hace toda la magia, primero crea un Hash con el filtro default para todas las llamadas Rest, luego evalúa si a traves de fetch_resource! o fetch_resources! le estamos pasando filtros adicionales, si es así, los integra al Hash de filtro default.

En este punto es donde esta lo mas interesante, usamos en simbolo que se almacena en la variable resource para obtener la referencia a la clase del modelo sobre el cual nos interesa hacer la consulta, por ejemplo si nuestro símbolo es :cliente, asume que tenemos un modelo Cliente y sobre el queremos enviar nuestra solicitud Rest.

Acto seguido identificamos si tenemos un ID a traves del Hash params en el controlador, si es así, identificamos si debemos de llamar al metodo find o all y colocamos los parámetros de la forma correcta, mediante send hacemos el llamado de forma dinamica y el resultado lo guardamos en la variable values.

Finalmente fetch! asume que si tenemos una colección y nuestro símbolo es :cliente, esperamos tener una variable @clientes con los datos, en cambio si tenemos un solo modelo como respuesta y nuestro símbolo sigue siendo :cliente, asume que esperamos una variable @cliente con el dato.

De esta forma en nuestras vistas podemos hacer uso de @clientes o @cliente según corresponda.

Si bien no hubo un ahorro significativo en lineas de código, si hubo la eliminación de lineas de código repetidas y susceptibles a errores o cambios, las cuales fueron reemplazadas por otras instrucciones mas simples que manejan el mismo escenario para cualquiera de mis modelos.

Tercera reunión de Tijuana.rb

2010-11-17T12:52:00.001-08:00

Tentativamente el miércoles 1 de Diciembre sera la tercera reunión de Tijuana.rb, una vez mas será en la oficinas de Ingenia Creative, ubicadas en:

Blvd. de las Americas
5636 Interior D.
Lomas de Agua Caliente
Tijuana, Baja California 22040 México

Para ver el mapa de lugar, lo pueden consultar aquí.

La reunion sera de 7pm a 9pm, aun no hay temas ni presentadores definidos, así que si te interesa participar no dudes en comentarlo, cualquier tema de Ruby/Rails/Sinatra, principiante o avanzado es bueno.

Te puedes apuntar aquí en los comentarios del post o en el google group de Tijuana.rb

Actualización!
Ya hay presentaciones para esta reunión
@obelich hablara de su experiencia con Rails desde el punto de vista de un PHPero.
@stanmx nos platicara como usar el polimorfismo en Rails para ser mas DRY.

Nos vemos en la reunión.

Segunda Reunion de Tijuana.rb

2010-11-07T09:06:00.001-08:00

Este proximo miércoles 10 de Noviembre sera la segunda reunión de Tijuana.rb, edición llamada "mas vale tarde que nunca", en esta ocasión será en la oficinas de Ingenia Creative, ubicadas en:

Blvd. de las Americas
5636 Interior D.
Lomas de Agua Caliente
Tijuana, Baja California 22040 Mexico

Para ver el mapa de lugar, lo pueden consultar aquí.

La reunion sera de 7pm a 9pm, los temas a presentar se actualizaran en las próximas horas.
Temas para hoy en la reunion:
- Antonio Antillon: "Boy meets Rails"
La experiencia personal de un programador novato, durante la creación de una app en Rails para solucionar el registro de asistentes a la Expo Industrial BajaMak.

- Fernando Castellanos: "Google Maps V3 con Rails3"
Como usar los mapas de Google API V3 de manera facil y sencilla con Rails3.

Ruby on Rails este mes de Noviembre

2010-11-04T10:50:00.001-07:00

Al parecer un mes mas activo en cuanto a mis actividades en Ruby y Rails este mes de Noviembre.

Primeramente Alt.NET Hispano me ha invitado este sábado 6 de Noviembre a dar una VAN sobre Rails, la dirección para conectarse aparecera ese mismo dia en el sitio o traves de la cuenta de twitter @altnethispano, la VAN sera a las 18:00 UTC/GMT.

El domingo 7 participare en el evento "Latam en Rails" de Rails.mx, con la platica "Uso de Steakrb para BDD", la platica en es linea y sera a las 5:30pm hora del centro de Mexico.

Finalmente el proximo sábado 13 de noviembre estaré en el evento "Software Freedom Day 2010" del grupo de usuarios linux de Tijuana, este evento sera en el Museo del Trompo y estaré a las 10:00am hora del pacifico platicando sobre Rails.

Ayuda fuera de linea para Rails 3.0 en OSX

2010-10-16T22:38:00.001-07:00

Existe en linea una buena cantidad de recursos de ayuda para trabajar en Rails, uno de los primeros sitios a consultar es RailsGuide, otro sitio en linea importante es el que contiene la documentación del API de Rails o el sitio Rails API; finalmente la fuente de ayuda mas importante es el mismo código fuente de Rails.

Todas estas opciones son muy buenas para resolver dudas sobre el API, el detalle viene cuando por algún motivo no estamos en linea. Si al momento de instalar nuestra gemas instalamos también la ayuda en formato rdoc, entonces podemos consultar el API desde la linea de comando con ri.

Por ejemplo si buscamos ayuda sobre content_for, en la linea de comando podemos ejecutar:

$ ri content_for

Después de un momento ri nos indica que hay mas de un resultado, entonces elijo el que están dentro del namespace de Ruby que nos interesa y volvemos a ejecutar ri:

$ri ActionView::Helpers::CaptureHelper#content_for

En este caso el resultado que nos muestra ri es la ayuda sobre ese especifico método de Rails. Esta opción funciona en todas las plataformas donde podamos instalar Rails, pero si estamos en OSX, pues tenemos una opción gráfica para la ayuda en linea.

Esta opción consiste en usar la aplicación de diccionario de OSX, donde instalamos el diccionario con la ayuda de Rails, este lo podemos descargar de el vinculo publicado en este post, y para instalarlo solamente copiamos el diccionario a la carpeta ~/Library/Dictionaries.

Abrimos la aplicación de diccionario y ya podemos consultar el API de Rails fuera de linea.

Inclusive mejor aun, desde nuestro editor - en mi caso MacVIM, me posiciono sobre la instrucción de la que quiero consultar el API y presiono las teclas Command + Ctrl + D y me aparece una "burbuja" con la ayuda proveniente del API.

Ya sea en linea o fuera de linea, hay opciones muy convenientes para siempre poder consultar el API de Rails.

iWeekend Tijuana 2010

2010-10-09T16:39:00.001-07:00

Así es, leyeron bien, el evento de iWeekend viene a Tijuana este próximo 26, 27 y 28 de Noviembre.

iWeekend es un evento cuyo objetivo es ayudar a la creación de dos starups con base tecnológica de la ciudad de Tijuana, así que si tienes una idea para una startup, no lo pienses mas y participa.

El objetivo es inspirar a los desarrolladores locales, emprendedores, gente de marketing, diseñadores, encargados de ventas y gerentes de cualquier actividad (tecnológica, salud, moda, textil, manufactura, investigación, etc) se reúnan para dar a conocer sus interés y conocimientos; con el fin de ayudar a poner en marcha las ideas de emprendedores de su región.
iWeekend les dará la oportunidad de crear conexiones sin precedentes para las Startups que surjan de los 4 eventos, donde los lideres de cada idea podrán interactuar con mas de 50 emprendedores y captar el talento humano suficiente para crear un equipo robusto alrededor del proyecto, el cual se creara durante un fin de semana.

La fecha limite de inscripción es el 21 de Noviembre y la sede será la Universidad Iberoamericana Campus Norte - Playas de Tijuana -.

Para mas información visita

Plática, vistiendo un sitio con CSS

2010-10-09T16:24:00.001-07:00

Actualización: Aqui esta el video grabado de esta platica.

Sesión CSS from Gabriel Flores on Vimeo.

Como en otras ocasiones todo inicio con un "tweet" ¿y que tal si?, en esta ocasión el que tal si fue para tener una plática sobre el uso de HTML y CSS en el desarrollo web, desde la experiencia de un desarrollador/diseñador @stanmx.

@stanmx planea llevar un proyecto base en HTML y en base a técnicas y experiencias personales mostrar como "vestir" este sitio web.

La plática se llevará a cabo el día 14 de Octubre 2010 de 6pm a 8pm en Grupo Expotarlia:
Calle Ricardo Castro No. 355,
Fracc. Nueva Tijuana

La entrada es gratis y algo importante es que este evento esta organizado por:

Como iniciarse en Ruby/Rails

2010-10-05T17:38:00.001-07:00

En varias ocasiones me han hecho esta pregunta y generalmente no tengo una respuesta sencilla, ya que no creo que exista una receta para lograr esto.

Creo que lo primero es obviamente tener interes por Ruby y/o Rails, un buen lugar para comenzar con Ruby es el sitio de Ruby Lang. Un libro muy bueno es Programming Ruby. Realmente no conozco muchos recursos en español sobre Ruby en particular. Otro libro interesante es Learn to Program donde enseña como programar desde el punto de vista de Ruby.

Una buena recomendación, antes de moverse a programar en Rails es aprender a programar con Sinatrarb, ya que que Sinatrarb a diferencia de Rails, no agrega tanta "magia" y hay que conocer mejor el lenguaje para hacer una aplicación con este DSL.

Sobre Rails igualmente no conozco mucho contenido en español sin embargo puedo recomendar seguir y estar pendiente de las siguientes comunidades y eventos:

Rails.mx, comunidad de Rails en México
OnRails, comunidad de Rails en Argentina
Rails Hispano, podcast en español sobre Rails
Conferencia Rails, conferencias de Rails en España, hay videos de conferencias pasadas.
Tambien porque no seguir a @tijuanarb en lo que esta el sitio listo en tijuanarb.org
Mario Cornejo tiene algunos videos introductorios en español sobre Rails

Una buena opción también es buscar si seguir a los tweeteros sobre temas de Ruby/Rails es español.

En cuestión de libros el único que puedo recomendar es Agile Web Development with Rails, aunque hay muchos otros.

De los recursos de podcasts y video, gratuitos y de paga puedo recomendar:

Peepcode $$, tiene por ahí varios vídeos básicos para aprender Rails
Tekpub $$, hay 2 series de videos una sobre Rails y otra sobre Sinatra y Rack
Rails3 de Gregg Pollack, videos con lo nuevo sobre Rails3
Railscasts, los videos por excelencia sobre Rails
SDRuby, videos de las sesiones de la comunidad de Ruby en San Diego CA
Ruby5, el mejor podcast sobre Ruby
Confreaks, videos de diversas conferencias de Ruby y Rails

Por ultimo y porque aun hay tiempo, bueno no mucho, Magma Rails es la primera - creo - conferencia de Rails en México y al parecer van a tener varias sesiones interesantes.

Como dije al principio no hay una receta especifica, pero si hay muchos recursos en Internet sobre Ruby y Rails, aunque la mayoría en ingles.

NOTA: En los comentarios me han pasado algunas referencias en español para comenzar en Rails.
Antonio me hace referencia RailsTutorial, el cual es un buen libro en linea
Obelich recomienda "El maldito libro de los descarrilados" ademas de recomendar la comunidad GuateOnRails de Guatemala y su curso de Rails. Tambien recomienda ASCII Casts en Español y un tutorial de Ruby.

Por otro lado desde algunas semanas me ha estado rondando la inquietud de hacer un taller de Ruby y Rails de unas 3 o 4 sesiones donde podamos aprender y construir aplicaciones, pero de momento no se que tanto interés habría aquí en la ciudad.

Heroku y MongoHQ con Mongoid en Rails3

2010-09-28T10:47:00.001-07:00

He tenido la necesidad de mostrarle en linea a un cliente un prototipo de una aplicación Rails3 que usa MongoDB como base de datos, para mi la opción por excelencia para estos prototipos es usar Heroku, un hosting de aplicaciones en la nube para Rails muy fácil de usar.

Lo interesante de Heroku es que tiene cuentas gratuitas - aunque con ciertas limitaciones -, que son perfectas para mi propósito. (En la primera reunión de @tijuanarb, @bitfon platico sobre Heroku).

Pero Heroku no tiene soporte directo para bases de datos MongoDB, aunque si ofrece un addon para integrarse con MongoHQ, servicio también en la nube para este tipo de base de datos, y al igual que Heroku, también tiene cuentas gratuitas, excelente también para prototipos. (También en la primera reunión de @tijuanarb, @fcastellanos hablo sobre MongoDB)

Hasta aqui todo bien, mi detalle vino al revisar la documentación de Heroku de como configurar la conexión a MongoHQ, ya que se requiere de una variable ambiente MONGOHQ_URL donde se coloca una URL que MongoHQ proporciona para cada base de datos, la forma de agregar esta variable en nuestra aplicación de Heroku es la siguiente:

$ heroku config:add MONGOHQ_URL="mongodb://mi-url-de-la-db-que-me-dio-mongohq"

Nota: a comentario de @fcastellanos, a la url de MongoHQ ha que agregarle el usuario y clave que tiene acceso a la base de datos, ejemplo:

$ heroku config:add MONGOHQ_URL="mongodb://[usuario]:[password]@[url_mongohq]"

Mi detalle viene a partir de que la documentación de Heroku no indica ningún paso adicional para configurar MongoID, la libreria de Ruby que mi aplicación usa para comunicarse con una base de datos MongoDB, sin embargo si hay pasos adicionales para otras librerías similares.

Así que asumí que todo estaba bien, me conecto a la aplicación y me indica un error, al revisar el log veo que no encuentra la base de datos, por lo tanto al parecer MongoID no estaba haciendo uso de la variable de ambiente MONGOHQ_URL.

Revisando el archivo config/mongoid.yml donde se configura la base de datos veo que espera obtener los valores de varias variables de ambiente:

host:
port:
username:
password:
database:

Así que lo que procedí a hacer es cargar esas variables al momento de iniciar mi aplicación para esto modifique el archivo config/applicacion.rb y justo a partir de la segunda linea y antes de los "require" agregue el siguiente código:

# MongoHQ Setup
require 'uri'
if ENV["MONGOHQ_URL"]
mongo_uri = URI.parse(ENV["MONGOHQ_URL"])
ENV["MONGOID_HOST"] = mongo_uri.host
ENV["MONGOID_PORT"] = mongo_uri.port.to_s
ENV["MONGOID_USERNAME"] = mongo_uri.user
ENV["MONGOID_PASSWORD"] = mongo_uri.password
ENV["MONGOID_DATABASE"] = mongo_uri.path.gsub("/", "")
end

Después de esto, volví a lanzar mi aplicación y ahí estaba finalmente funcionando, por fin Heroku y MongoHQ estaban trabajando juntos.

Manos, un framework ligero para aplicaciones web en .NET/Mono

2010-09-26T12:27:00.001-07:00

Hace unos días platicando con @fcastellanos, me hizo notar un nuevo framework para el desarrollo de aplicaciones web para .NET/Mono, el framework es Manos.

Manos esta siendo desarrollado por el hacker de Mono Jackson Harper, quien comenta en su manifesto que le gusta desarrollar aplicaciones web y le gusta el lenguaje C#, pero no le gusta ASP.NET, cree que ASP.NET en general hace que las cosas sencillas sean muy complicadas y por eso decidió crear Manos y dejar a ASP.NET fuera de la ecuación.

Los objetivos de Manos es ser un framework:

Escalable y de alto rendimiento
Con un sistema "pipes" que permita conectarse y extender cualquier punto de la solicitud HTTP
Un sistema de rutas facil y simple, por medio de concordancia de texto y expresiones regulares
Auto conversion de parámetros en la ruta o post
Que funcione con HTML5 por omisión
Un sistema de plantillas basado en HTML
Linea de comando simple para la creación de aplicaciones, construcción y "hosteo" de aplicaciones, sin necesidad de IDEs
Basado en la reutilizacion de componentes, modular y facil de probar.

Si estuviese leyendo estos puntos y no sabría que se esta hablando de C# y .NET, pensaría que me están describiendo Rack y muy probablemente la combinación con Sinatra, pero no es así.

Estuve viendo los ejemplos y no puedo evitar pensar en términos de Rack/Sinatra, por ejemplo:

$ manos -init myapp # Crea un directorio con mi aplicación con jquery, algunos css y el modulo .cs

En nuestro modulo podremos escribir nuestra aplicación "Hola mundo" tan fácil como:

Get ("/", ctx => ctx.Response.Write("Hola mundo!"));

Lo compilamos, por ejemplo con Mono:

$ gmcs -target:library -out:myapp.dll myapp.cc StaticContectModule.cs

Y finalmente dentro del directorio ejecutamos

$ manos -server

Navegamos a localhost:8080 y nuestra aplicación debe de responder.

Increíblemente sencillo y facil, en el sitio de Github hay un ejemplo mas elaborado, junto con 2 tutoriales sobre Manos, tutorial1 y tutorial2.

Por cierto Manos es Open Source con licencia MIT X11, bastante permisiva.

Reunion del grupo tijuana.rb

2010-09-23T08:00:00.001-07:00

El dia de ayer miércoles, se llevo a cabo la 1ra reunion de grupo de usuario de ruby/rails tijuana.rb, en la cual Sergio Lopez (@bitfon) habló sobre Heroku y el flujo de trabajo para publicar aplicaciones en ruby en la nube y Fernando Castellanos (@fcastellanos) sobre mongodb y como usarla en Rails.

El lugar fue la parte exterior del Starbucks Lucerna en zona rio, y tengo que admitirlo llego mucha mas gente de la esperada, en un punto éramos alrededor de 15 o poco mas, y aunque las condiciones del lugar no fueron las optimas - no nos alcanzo el espacio donde estábamos -, creo que estuvo bastante bien para la primera reunión. Así que para la siguiente reunión vamos a tratar de tener un lugar adecuado.

Ambas platicas interesantes y con muchas preguntas por parte de los asistentes.

En la reunion tambien nos acompañaron Jed Sundwall (@jedsundwall), Edward O'Connor (@hober) y Patrick Crowley (@mokolabs) del grupo de @SDRuby y SANDPYT - San Diego Phyton -. Y aunque solo uno de ellos hablaba español participaron de manera activa; y trajeron algunos regalos para rifar con los asistentes.

De lo interesante de que ellos nos acompañaran, es que tuve la oportunidad de platicar con Patrick, y salió la posibilidad de realizar eventos en conjunto, ya sea aqui en Tijuana o San Diego, lo cual es de lo mas interesante. De entrada ya veremos la posibilidad de realizar un "carpool" para asistir a la próxima reunión de @SDRuby.

Gracias a los que asistieron y esperamos verlos el siguiente mes, con mejores condiciones de espacio y gracias a @bitfon y @fcastellanos por su participación.

Calcular fechas laborables con Ruby

2010-09-22T16:00:00.001-07:00

Hoy me encontré con este post llamado "Calculate Business Days using LINQ" donde explican como usar C# y LINQ para de un rango de fechas obtener solo las fechas que son laborables, es decir excluir las fechas que caigan en sábado y domingo.

El código se muestra a continuación donde se haca primero una llamada al método GetAllDates y se le pasa una fecha inicial y otra final, después con Where de LINQ se evalúa cada fecha un método que regresa falso o verdadero si la fecha cae en fin de semana o no, obteniendo al fina un arreglo con las fechas laborables.

Después de revisarlo, me pregunte, que tan complicado es hacer lo mismo en Ruby. Después de unos minutos me di cuenta que es ridículamente simple hacer lo mismo que LINQ y C# en solo 1 linea de código.

A mi metodo wroking_days se le pasa una fecha inicial y una fecha final y como resultado tenemos una arreglo de fechas excluyendo las que caen en fin de semana.

La complejidad de Ruby On Rails

2010-09-20T11:25:00.001-07:00

A raíz de mi post anterior y algunos comentarios expresados en él acerca de la complejidad para tener una aplicación de Ruby On Rails funcionando con MongoDB, he decidido escribir este post, el cual lo voy a tratar desde la vista de un ex(o casi)-desarrollador de .NET y aunque quizás algunos de mis comentarios parezcan un ataque a un .NET, no es esa mi intención, así que por favor tomenlos relajados. Ni tampoco es mi intención decir cual es mejor o cual es peor, ese es un ejercicio que cada quien forma personal debe de realizar

Comencé a desarrollar en .NET desde las versiones beta del mismo, ya hace mas de 10 años, e inclusive desarrolle para Web desde antes, ya sea con código escrito en C a modo de cgi-bin o Perl, al igual me toco desarrollar para Web en Visual Basic 4 - 6. En esos tiempos era realmente algo complejo hacer paginas dinámicas y era muy sencillo tomar decisiones incorrectas y hacer que el desarrollo se complicara enormemente.

Con la llegada de .NET Microsoft proponía otro paradigma un tanto diferente de como desarrollar a Web, proponía hacerlo tal y como se escribían aplicaciones de escritorio, solo haciendo "drag and drop", "right click", configurar aqui y alla y listo, tener aplicaciones sin - o casi sin - escribir una linea de código, digo cuantas veces no hemos visto a empleados de Microsoft haciendo este tipo de demos en eventos de la empresa.

Desde mi punto de vista - si desde mi punto de vista y experiencia - esto funcionada super bien para aplicaciones muy simples y predecibles, mi problema siempre venia cuando se quería hacer "algo mas" con la aplicación, la complejidad de desarrollo iba en aumento y en ocasiones se convertía en algo nada trivial. Durante ese tiempo también me toco hacer desarrollo con Java, varios frameworks para Web y Tomcat, y la experiencia no fue mejor.

Llego un punto en el cual casi casi decidí dejar de escribir aplicaciones para Web y únicamente escribir aplicaciones para escritorio, pero los clientes seguían solicitando aplicaciones Web, así que busque alternativas en .NET - PHP realmente nunca me gusto ni me gusta, quizás no tengo argumentos técnicos para decir porque, simplemente no me gusta -.

La alternativa que encontre fue MonoRail, comencé a ver los ejemplos y a entender sus dependencias, MonoRail es un framework para ASP.NET que trabaja con los patrones de MVC y ActiveRecord, inspirado por Action Pack. Al investigar que es Action Pack, descubrí Ruby On Rails, pero en ese momento le encontre un problema, tenia que aprender otro lenguaje de programación y tenia algunas semanas para entregar una aplicación Web para un cliente.

Así que me decidi por MonoRail, pero había algunos "detalles", tenia muchas dependencias, no tenia "Wizards" ni componentes o controles como se les llama en ASP.NET WebForms, en lo personal no lo vi como problema ya que en lo personal es raro que use los "Wizards" o que utilice controles de 3ros, así que para mi no había perdida ahí, aunque si me ha tocado conocer y dar cursos a desarrolladores de .NET que si no tiene un "Wizard" o no pueden poner su "Grid" súper "fancy" no son capaces de desarrollar una aplicación.

Por otro lado, si bien la configuración de un ambiente de trabajo con MonoRail requeria de un poco de trabajo y entendimiento por arriba de "Drag and Drop" y "Right click", no me pareció gran cosa y mas cuando es algo que solo haces una sola vez. MonoRail me permitió entregar varias aplicaciones de manera muy rápida, quede impresionado y eso me llevo a investigar sobre Ruby On Rails. Por cierto hace algunos días anunciaron, parte de "Roadmap" de MonoRail.

El motivo por el cual MonoRail me permitió entregar aplicaciones muy rápido fue porque no tuve que tomar decisiones, MonoRail lo hizo por mi, por ejemplo no tuve que decidir como organizar mi aplicación, no tuve que decidir como conectarme a la base de datos, todo lo decidió MonoRail, así solo tuve que enfocarme en la funcionalidad que era importante para mis clientes y ya. MonoRail al igual que Ruby on Rails es opinioted software.

Al llegar a Ruby on Rails, obviamente la primera barrera fue el lenguaje Ruby, pero es muy facil acostumbrarse a el, aunque todavia escribo código a la C#, pero creo que voy mejorando.

Para la gente acostumbrada a los IDEs hay una gran variedad de opciones a elegir, en lo personal no soy fan de las IDEs, prefiero ambientes mas ligeros y que me hagan usar la consola de comandos, por lo tanto en Windows se puede seguir esta guia y en Linux estas dos guias, puede parecer complicado, pero es algo que solo se tiene que hacer una vez, si se usa un IDE en cuestión de minutos se tiene un ambiente complete y configurado.

Es muy sencillo crear una nueva aplicación con Ruby On Rails (RoR) haciendo uso de las decisiones que el framework hace por nosotros, por ejemplo:

$ rails new mi_super_app
$ cd mi_super_app
$ rails generate scaffold client name:string, address:string
$ rails server

Dirigimos nuestro navegador a http://localhost:3000/clients y listo ya podemos comenzar a dar de alta y modificar clientes, simple, fácil y rápido.

Si bien esto funcionara tal y como esta en un gran numero de casos, la gente en RoR pensamos en la regla 80/20, hay momentos en que se tiene que hacer algo un poco diferente para configurar nuestra aplicación, donde podemos cambiar las decisiones que RoR hace por nosotros y adaptarlas al 100% de nuestras necesidades, como las modificaciones propuestas en mi post para usar MongoDB en lugar de una base de datos relacional.

Si bien la intención de mi post es servir como una guia o receta, paso a paso de como hacerlo, también podemos hacerlo sencillo con el uso de Templates - así como existen también templates en Visual Studio para crear aplicaciones con ciertas características y defaults -, en e siguiente video de Railscasts se explica el concepto. De hecho existe ya un template para pre-configurar una aplicación de RoR para usar MongoDB y Rspec, con el cual se puede omitir mi post y solo ejecutar:

$ rails new mi_super_app -JOT -m ~/path_a/mongodb_template/templater.rb

Ya viendolo así, ¿ya no se ve que sean muchos pasos no?

Sobre el tema de las dependencias, al igual que en cualquier otro framework o lenguaje podemos tener dependencias a librerías de terceros o podemos elegir no hacerlo. En el caso de Ruby y sus diferentes frameworks, hay librerías para casi todo lo que nos podamos imaginar, RubyGems es un buen lugar para descubrirlas y Bundler nos permite manejar esas dependencias de forma sencilla y a nivel aplicaciones, es decir podemos tener la misma dependencia pero hacia diferentes versiones de la librería sin conflictos, no hay "DLL Hell".

Para determinar como elegir que dependencias tener en nuestra aplicación, va en relación directa de nuestras necesidades, pero creo que puedo sumarizar algunos criterios:

Librerías que fueron extraídas del framework de RoR
Librerías mantenidas por miembros del equipo de desarrollo de RoR
Librerías que son tan viejas como el mismo framework de RoR y que evolucionan paralelamente
Librerías mantenidas por empresas de desarrollo en RoR
Librerías populares y que tengan pruebas

Con respecto al soporte de los librerías disponibles en Ruby, este varia, pero el común denominador es que son OSS y el código de casi todas esta disponible en Github. En experiencia personal no he tenido problemas con esto, ya que a través de los grupos, IRC, reportando bugs o correo directo he tenido solución cuando se me ha presentado algún problema, inclusive, he enviado parches que han sido aceptados y generalmente la corrección a mi problema puede llevar algunas horas en lugar de tener que esperar días si fuese un bug en una librería comercial.

De las librerías que he utilizado realmente no me ha tocado alguna que pierda el soporte, cuando el desarrollador principal se retira generalmente sale alguien a continuar trabajando en ella, lo que si me ha tocado experimentar es el reemplazo de librerías por otras mejores, por ejemplo, cuando entre a RoR restful_authentication era "la librería" para el manejo y autentificacion de usuarios, posteriormente authlogic la reemplazo y actualmente devise es la librería popular, no es que las otras tengan algo malo o funcionen mejor o peor, es solo la manera en como evolucionan las cosas.

Creo que personalmente lo que encontre en RoR es que no me tengo que pelear contra el framework para poder entregarle aplicaciones a mis clientes, todo lo contrario, me puedo olvidar un poco del framework y dedicarme a implementar la funcionalidad que le da valor a mi trabajo.

Y afortunadamente puedo decir que aquí en Tijuana no he sido el único que ha encontrado este valor, ya que desde que comencé a platicar sobre RoR varios amigos implementaron soluciones para sus empresas y clientes de estas que están en linea y en tiempo record, y traen todavía mas proyectos nuevos que están siendo desarrollados en RoR, de mi parte igualmente tengo un par de proyectos en RoR que pronto verán "la luz", proyectos para mis clientes. Al mismo tiempo se de empresas que están tomando cursos y evaluando RoR para el desarrollo de nuevas versiones de sus productos, todo esto solo en Tijuana.

Creo que después de esta explicación algunos estarán de acuerdo conmigo y otros no, a final de cuentas debemos de ser apasionados con el lenguaje/framework que elijamos para trabajar, porque para bien o para mal a estos le vamos a dedicar nuestro tiempo laboral; pero el ser apasionados también implica el ser críticos de lo que usamos y si es posible conocer y probar otras herramientas, aunque si trabajamos para una empresa "casada" con una compañía/tecnología va a ser un poco difícil cambiar su visión, ya que generalmente se usan x tecnología por cuestión política o de mercadotecnia o gusto personal de la persona que toma las decisiones.

Aplicación de Rails 3 con MongoDB

2010-09-18T00:06:00.001-07:00

En los últimos días he tenido que iniciar un par de proyectos en Ruby On Rails, donde la base de datos que se ha requerido es una base de datos no relacional, en este caso MongoDB.

La idea de este post es documentar la configuración de una nueva aplicación en Rails 3 para usar con MongoDB, donde vamos a desactivar ActiveRecord e instalar las siguientes herramientas:

Generadores Rails para Mongo
Rspec para pruebas
Factory Girl para fixtures
Haml como plantilla de vistas y jQuery.

Como paso inicial es necesario crear una nueva aplicación de Rails 3 - Se asume que ya se tiene instalado Rails 3 y MongoDB -, pero vamos a pasar las opciones -O para que no se creen archivos de ActiveRecord, -J para que no se instale la librería de javascript Prototype y -T para que no cree el fólder para Test::Unit

$ rails new mi_app -O -J -T

Después de creada la aplicación, seria buena idea inicializar un repositorio de Git.

Una vez creada nuestra aplicación hay que realizarle algunas adiciones nuestro archivo Gemfile para agregar las dependencias de nuestra aplicación:

mongoid y bson_ext => Mongoid es la librería que usaremos para conectarnos a la base de datos de MongoDB y bson_ext es una extensión en C para acelerar la serializacion de BSON
haml => Lenguaje de plantilla alternativa para vistas en Rails, desde mi punto de vista menos verbal y mas "developer friendly" que html y erb.

Dentro de un grupo llamado :development agregamos las siguientes gemas:

rails3-generators => varios generadores para Rails 3, lo que nos permite ejecutar rails generate
haml-rails => generadores de haml para Rails 3
jquery-rails => generadores de jquery para Rails 3

En el grupo :test agregamos:

rspec => framework para pruebas en Ruby
rspec-rails => utilerias para pruebas en RSpec para Rails
factory_girl_rails => utileria para la creación de modelos para pruebas
remarkable_mongoid => librería para pruebas de modelos de mongoid con RSpec

El archivo Gemfile debe de quedar como se muestra a continuación.

Para instalar las gemas solo ejecutamos

$ bundle install

Para conocer mas de las gemas instaladas aquí les dejo los vínculos a sus referencias

Una vez instaladas las gemas hay que realizar algunas configuraciones, lo primero es configurar mongoid para trabajar con Rails y desactivar ActiveRecord, para eso ejecutamos el comando:

$ rails generate mongoid:config

Este comando va crear el archivo config/mongoid.yml donde vamos a configurar el acceso a la base de datos de MongoDB, también va a modificar el archivo config/application.rb y va a eliminar la dependencia de ActiveRecord, la parte superior de config/application.rb deberá quedar algo similar a:

# require "active_record/railtie"
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
#require "rails/test_unit/railtie"

Ya que estamos en el archivo config/application.rb vamos indicandole a Rails que en nuestra aplicación deseamos usar haml, rspec y factory_girl por omisión, para esto dentro de la declaración de la clase Application < Rails::Application, pero al final agregamos el siguiente código

A partir de este punto instalamos el soporte para jQuery y Rspec en nuestra aplicación de la siguiente forma:

$ rails generate jquery:install #--ui para activar jQuery UI
$ rails generate rspec:install

Como ultimo paso vamos configurar RSpec para que trabaje con factory_girl y remarkable, ademas de eliminar el soporte a ActiveRecord y hacer que RSpec elimine las colecciones creadas en MongoDB por nuestras pruebas antes de la ejecución de cada prueba, esto es necesario para asegurarnos que al correr cada prueba la base de datos este "limpia" y así no crear conflictos y/o dependencias en las pruebas.

Al inicio del archivo spec/spec_helper.rb hay que requerir:

require 'factory_girl'
require 'remarkable/mongoid'

Un poco mas abajo indicamos que cargue los archivos Factory de factory_girl

Dir[Rails.root.join("spec/factories/**/*.rb")].each {|f| require f}

Después eliminamos el soporte a ActiveRecord comentando las siguientes lineas:

config.fixture_path = "#{::Rails.root}/spec/fixtures"
config.use_transactional_fixtures = false

Y finalmente dentro y al final del bloque de configuración de RSpec indicamos que antes de cada prueba elimine las colecciones de MongoDB

config.before :each do
Mongoid.master.collections.select {|c| c.name !~ /system/ }.each(&:drop)
end

El archivo spec/spec_helper.rb deberá quedar muy parecido a

Una vez en este punto ya podemos proceder a crear nuestra súper aplicación usando MongoDB como base de datos, si ejecutamos el generador para model, o controller o scaffold, Rails 3 generara modelos para MongoDB o vistas en haml y creara los archivos necesarios en spec para realizar pruebas con RSpec.

Primera Reunion de tijuana.rb

2010-09-13T08:38:00.001-07:00

Ven y asiste a la primera reunion del grupo de usuario Ruby/Rails de Tijuana, tijuana.rb, este proximo miércoles 22 de Septiembre en el Starbucks Lucerna de la Zona Río, a partir de las 7pm.

En esta primera reunión, Sergio Lopez (@bitfon) nos platicará sobre @heroku, un hosting para Ruby/Rails con cuentas gratuitas. ~~Estamos a la espera de la confirmación de una plática más~~. Fernando Castellanos(@fcastellanos) ya se apuntó con una platica sobre como usar MongoDB con Rails.

Para los que me han preguntado sobre como iniciar con Ruby, le dejo esta liga a un post "larguísimo" que escribí con ejemplos y aunque es sobre IronRuby funciona igual con Ruby. Si alguien lo quiere ver en video aquí esta la sesión grabada en ALT.NET Hispano.

Para estar al pendiente de lo que sucede con tijuana.rb únete al Google Group o sigue a @tijuanarb en twitter.

Localización de fechas en Rails

2010-09-01T18:29:00.001-07:00

Al estar trabajando en un sitio/aplicación para un cliente bajo el CMS RefineryCMS, cambie el idioma de CMS a español, pero las fecha seguían apareciendo en formato en Inglés, ej: September 01, en lugar de 01 de Septiembre.

Aun y cuando ya tenia instalado el archivo es-MX.yml en el directorio locale y Rails estaba localizando otros textos pero no las fechas. En el archivo yml encontramos la siguiente estructura:

date:
order: [:day, :month, :year]
abbr_day_names: [Dom, Lun, Mar, Mie, Jue, Vie, Sab]
abbr_month_names: [~, Ene, Feb, Mar, Abr, May, Jun, Jul, Ago, Sep, Oct, Nov, Dic]
day_names: [Domingo, Lunes, Martes, Miércoles, Jueves, Viernes, Sábado]
month_names: [~, Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto, Septiembre, Octubre, Noviembre, Diciembre]
formats:
short: "%d de %b"
default: "%d/%m/%Y"
long: "%A, %d de %B de %Y"
formal: "%d de %B"
time:
formats:
short: "%d de %b a las %H:%M hrs"
default: "%a, %d de %b de %Y a las %H:%M:%S %Z"
long: "%A, %d de %B de %Y a las %I:%M %p"
am: "am"
pm: "pm"

En donde en Date:Formats:Formal encontramos "%d de %B, con lo que esperaria formatos de fecha 01 de Septiembre.

Resulta que con:

t (:formal, :scope => [:date, :formats])

podemos leer el formato "%d de %B del archivo de localización, pero ahora el problema es ¿como le indicamos a la fecha que formato usar?, bueno para eso usamos I18n, donde pasamos la fecha a formatear y el formato de acuerdo al idioma de la aplicación:

I18n::localize(date, :format => t (:formal, :scope => [:date, :formats]))

Ahora el único problema es que este código es bastante largo para colocarlo dentro de una vista, por lo que podemos mandarlo a un método helper de la siguiente forma:

def localize_short_date(date)
I18n::localize(date, :format => t (:formal, :scope => [:date, :formats]))
end

Con esto en nuestra vista solo llamamos:

<%= localize_short_date Date.now %>

Y nos aseguramos que la fecha es desplegada en el formato definido y localizada al idioma de la aplicación Rails.

Presentaciones de Ruby on Rails

2010-08-23T17:49:00.001-07:00

Este próximo sábado 28 de Agosto estaré participando en el evento en línea "Desarrollando en Ruby On Rails", durante todo el sábado habrán una serie de charlas que cubren diversos aspectos del desarrollo de Ruby On Rails.

En mi caso estaré participando con la plática "Vistas en Rails" en la cual platicaré sobre facilidades que nos proporcionar Ruby On Rails al desarrollar nuestras UI.

Para ver las platicas solo es necesario ingresar el sábado a tv.rails.mx, recuerden que el horario de las platicas es del centro de México (CDT -05).

Ademas, los chicos del Grupo de Usuarios Linux de Tijuana están organizando el "Día Mundial del Software Libre" para este 18 de Septiembre, donde tambien ya me invitaron a dar la plática de "Desarrollo Web a la Rails" - un no tengo el horario -.

Así que si les interesa Ruby On Rails, no lo piensen y acompañenme en ambos o alguno de los eventos. Adicionalmente y de manera no-oficial, los invito a la Comunidad Tijuana.rb, comunidad sobre Ruby y Ruby On Rails de Tijuana, aunque aun no tenemos sitio web, ni reuniones, ya hay actividad en el grupo de la comunidad en Google Groups, asi como en la cuenta de twitter @tijuanarb

El Gobierno y el Opensource

2010-08-18T12:06:00.002-07:00

Hace algunos días, ya a punto de terminar el cuatrimestre en una de las materias que impartí en el Cesun, les preguntaba a los alumnos su opinión sobre si el gobierno debería de usar o no el Opensource.

La respuesta fue unánime, todos estuvieron de acuerdo en que si, de que el gobierno antes de decidir comprar algún software, debería primero ver si existe su contraparte libre y usarla si es factible; las razones que me dieron fueron varias:

Un ahorro considerable de dinero por cuestión de licencias de software
Mas transparencia en las compras de software o no compras
Desarrollar un mercado diferente de TI
Respuesta mas rápida a fallos de seguridad

Después vino la pregunta, ¿y si el gobierno necesita desarrollar algún sistema, este desarrollo debe liberarse como Opensource o no?; al principio se vieron unos a otros, tratando de valorar la idea; les aclare que generalmente cuando el gobierno necesita de una aplicación especifica para llevar a cabo su labor tiene dos opciones, desarrollarla internamente o licitar el proyecto a un tercero, en ambos casos el gobierno paga por ese desarrollo.

Al escuchar esta explicación, discutieron un poco, pero al final también llegaron a la misma conclusión, que el desarrollo debería ser liberado como Opensource, los motivos fueron los siguientes:

Ser mas transparentes con los costos de desarrollo y poder evaluar si lo que cobro una empresa externa realmente lo vale o no
Asegurarse que el gobierno recibe el código fuente de la aplicación y así ya no depender de la empresa externa, si es que ya no se desea depender
Darle la oportunidad a otros gobiernos de hacer uso de la aplicación si es que le es útil
Evitar que empresas hagan un desarrollo pagado y luego lo vendan a otros gobiernos
Crear ecosistemas de servicios alrededor de estas aplicaciones

Si bien este ejercicio no tiene un sustento solido, creo que si podríamos estar de acuerdo con algunos puntos, si no es que todos; y tal es así que en el pasado han habido iniciativas para tratar de usar Opensource en el gobierno, aunque no han cristalizado del todo.

En alt1040 hay un post llamado "Cuando el gobierno mexicano se decidió por el software libre" y narra como el gobierno de Vicente Fox tuvo que apostar por el Opensource, e inclusive se hicieron análisis sobre factibilidad del Opensource en el gobierno; pero después los "Amigos de Fox" se convirtieron en los "Amigos de Microsoft" y con la llegada de Calderón el panorama del Opensource no mejoro.

Aun así, hace unos días salió a la luz que la CFE esta haciendo un esfuerzo por migrar su plataforma tecnológica a Opensource, buscando lograr un ahorro en licencias y ser una empresa un poco mas abierta.

Se le aplaude el esfuerzo y ojalá otras paraestales y gobiernos sigan el mismo ejemplo.

¿Y ustedes que opinan, debe el gobierno acercase seriamente al Opensource o no?, ¿se debería de abrir un foro en el gobierno local, por ejemplo de Tijuana, para discutir con el nuevo Presidente electo - el de verdad, no el otro - Bustamante la factibilidad?, ¿será necesario la creación de comité de informática, donde estén escuelas y organismos TI para regular el desarrollo TI del gobierno local?

Recursos de ASP.NET MVC

2010-07-30T16:59:00.002-07:00

Debido a un posible próximo proyecto con un cliente, me solicito le pasara una lista de recursos para conocer ASP.NET MVC, ya que su idea original era realizar el proyecto con ASP.NET Webforms, pero después de hablarle un poco de MVC y realizarle algunos demos, su interés por el mismo crecio.

De algunas de las platicas que tuve con él, al principio no estaba muy convencido, debido a que como él me lo comento "parece que en MVC tienes que hacer las cosas a mano", ya que no haríamos uso del "drag and drop" ni de la suite de controles web de Infragistics como él deseaba. Mis puntos para que se interesara en MVC fueron los siguientes:

El patrón de MVC es una "receta" probada por varias décadas
El usar MVC generalmente implica el uso de otra serie de patrones adicionales para resolver otros problemas en la aplicación
Aplicando estas "recetas" ayuda a que el desarrollo de la aplicacion sea mas uniforme si se siguen ciertos lineamientos, los cuales creo que son mucho mas claros si los comparamos con una aplicacion de Webforms
El usar MVC crea una linea de complejidad de la aplicacion mas estable, la cual puede ser un poco alta para pequeños proyectos, mas no asi para medianos y grandes, donde esta complejidad es mas uniforme, en cambio con Webforms la complejidad si es muy baja en proyectos pequeños, pero esta se va incrementando casi exponencial con proyectos mas grandes.
Otro punto importante es que en MVC se puede desarrollar y probar funcionalidad de la aplicación de manera aislada, mediante el uso de tecnicas y herramientas como: mocks, stubs, TDD o BDD, lo que permite ir creando bloques estables de la aplicacion e irla creciendo organicamente.

A final de cuentas, no se cual sea la decision del cliente con respecto al proyecto, espero me sea favorable, pero mientras tanto aqui les dejo el listado de recursos que le hice llegar sobre ASP.NET MVC esperando que les sirva de algo.

Libros interesantes

- ASP.NET MVC in Action 1 y 2 http://www.manning.com/palermo/ y http://www.manning.com/palermo2/

- Brownfield Application Development in .NET http://www.manning.com/baley/

Herramientas y arquitectura

- SharpArchitecture, framework para MVC http://sharparchitecture.net/

- NHibernate, ORM para .NET http://blogs.hibernatingrhinos.com/nhibernate/Default.aspx

- Arquitectura de Cebolla, parte 1 y 2 http://mario-chavez.blogspot.com/2008/07/la-arquitectura-de-cebolla-parte-1.html y http://mario-chavez.blogspot.com/2008/08/la-arquitectura-de-cebolla-parte-2.html

- El patrón MVC http://mario-chavez.blogspot.com/2008/09/programacin-web-patrn-mvc.html

Videos

- ASP.NET MVC http://www.asp.net/mvc

- Comunidad ALT.NET Hispano http://altnet-hispano.pbworks.com/Historial-de-reuniones

- Videos de MVCConf http://www.viddler.com/explore/mvcconf/videos