Dev3Cast Sobre Documentación Técnica

El pasado cinco de mayo participé en un episodio de dev3cast junto con Eber Irigoyen, Haarón González, Samuel Arellano y Gabriel Flores. Donde hablamos sobre la documentación técnica en proyectos de software.

Pueden descargar el episodio y comentar en el sitio de dev3cast para que todos quienes descarguen el podcast puedan leer sus opiniones.

Aplicar lo nuevo lleva su tiempo

Uno de los “problemas” que he encontrado al querer aplicar técnicas, usar librerías, frameworks, lenguajes, etcétera. De los que he leído e incluso usado en algún pet Project. Es que al momento de querer aplicarlo en algún proyecto real, este tienen fechas de entrega a muy corto plazo y por lo tanto lo más “seguro”, para cumplir con esas fechas de entrega, es haciéndolo utilizando lo ya conocido y probado en proyectos anteriores.

No es común que el cliente nos pida alguna aplicación y nos de el tiempo necesario para aprender la tecnología a usar. Primero porque desea el sistema lo más rápido posible y segundo porque no quiere cubrir el costo del tiempo invertido en aprender lo nuevo. Cuando al final el recibe el mismo sistema, no importando la tecnología o técnicas usadas en el desarrollo.

Pude ser que esta necesidad sea mas del desarrollador, ya que es él el que trabaja directamente con la tecnología (ya sea framework,lenguaje de programación, etc).

Para poder aplicar/implementar algo nuevo en un proyecto real requiere de un esfuerzo adicional al que se necesitaría para aplicar lo que ya se conoce. Todo, por fácil que sea, tiene su curva de aprendizaje, sus ventajas y sus desventajas y debes de haberte encontrado con algunas de ellas antes de poder usarlo en producción, para que así sepas como resolver lo posibles problemas que se presenten.

Pero entonces. ¿Como puedo aplicar o usar lo nuevo en los proyectos de mi trabajo, si nunca tengo el tiempo necesario? Algo que he tenido que hacer al querer aplicar algo nuevo en proyectos del trabajo es primero practicar por fuera en proyectos personales (a.k.a. pet projects) la tecnología/técnica que me interesa y en una oportunidad que se presente proponer el uso de tal tecnología o técnica. Esta propuesta procuro hacerla mostrando algo ya funcionando (un demo funcional), para convencer de las bondades que tiene utilizar lo nuevo.

Esto requiere dedicarle tiempo extra al trabajo, porque lo aprendido en pet projects lleva su tiempo aplicarlo en proyectos reales. Puede incluso llegar a ser frustrante tardar en realizar algo sencillo que usando lo que ya conocemos lo haríamos en minutos; pero a la larga es aun más frustrante (por lo menos para mi) el trabajar con técnicas/tecnologías viejas, con las que no puedo lograr lo que se que es posible realizar con algo nuevo.

De no dedicarle tiempo por mi cuenta a practicar lo que quiero usar, la decisión de usar algo diferente correría totalmente a cargo de alguien más, ya sea el cliente, jefe o algún programador más que hiciera la sugerencia. Para algunos eso no es problema, esperar que a el jefe/cliente se le ocurra intentar algo nuevo (a veces hasta que ya no es tan nuevo, incluso ya viejo); pero para mi conocer y no aplicarlo no es divertido.

Entonces: Si quiero usar algo nuevo tengo que proponerlo, lo mejor seria hacerlo mostrando avances donde puedan verse las ventajas. Esto requiere algunas veces dedicar algo de mi propio tiempo para aprender las nuevas tecnologías y así poder convencer a los clientes/jefes que estamos listos para usar la tecnología/técnica nueva, porque el cliente no quiere pagar la curva de aprendizaje.

La practica hace al maestro

Hace unos días tuve la oportunidad de dar una capacitación (en el .Net Framework) a unos compañeros de trabajo que acaban de egresar de la universidad y que aun no tienen experiencia laboral. Algo común entre ellos era la falta de practica al momento de empezar a escribir código. Podían entender fácilmente el ejemplo escrito por mi, pero no les era igual de fácil escribir código propio.

Me di cuenta que algunos tomaban varias notas en papel sobre lo que íbamos haciendo, en lugar de ponerse a practicar. Esto me hizo pensar que el aprender (y mejorar) a programar debe de hacerse de la misma forma en la que se aprenden las matemáticas. No basta con saber los procedimientos para resolver un problema, es necesario practicar las operaciones con varios ejercicios para poder dominar el tema (y resolver los problemas mas rápido y fácil).

Cuando aprendemos a sumar, restar, multiplicar, dividir, etcétera. La parte de tomar notas es muy poca, la mayor parte del aprendizaje se da al practicar. Lo mismo pasa con la ortografía, no es solo conociendo las reglas, es con la practica constante como aprendemos a escribir mejor y cometer menos faltas de ortografía (como reconocer las palabras que llevan acento).

También se podría comparar con el aprender un segundo idioma, llega un momento en que puedes entenderlo casi perfectamente pero para poder hablarlo correctamente se necesita de practica, equivocarte constantemente hasta que puedas darte cuenta que algo no suena bien y busques una mejor forma de expresarlo. Y si dejas de practícar puede ser que algunas palabras se te olviden aunque no tuvieras ningún problema en entenderla si alguien mas la dice.

Considero para que un desarrollador profesional pueda seguir superándose es importante leer, ya sea blog posts, artículos, código de algún proyecto de código abierto, screencasts, podcasts, en fin… consumir y producir contenido técnico. Pero algo que ayuda mucho a ser un mejor desarrollador es la practica constante, escribir muchas líneas de código, cometer errores y aprender de ellos (echando a perder se aprende). Así que además de leer y tomar notas es necesario practicar constantemente, porque (ya lo dice el viejo y conocido refrán) “la practica hace al maestro”.

NuGet Manejador de paquetes

Al trabajar en proyectos en .Net es común hacer uso de librerías de terceros, ya sean de código abierto e incluso de algunas con código propietario. Para usar estas librerías necesitaba ir al sitio de cada una de ellas y descargar la última versión (o la que necesitara) y descargar los archivos, después agregar una carpeta al nivel de mi archivo de solución de VisualStudio que acostumbraba llamarla “Lib” y ahí agregar los DLLs de terceros que usaría en mi solución.

Ahora con NuGet, el manejo de dependencias se simplifica. Lo primero que necesito es instalarlo, lo cual lo puedo hacer desde VisualStudio, usando el Extension Manager y buscando “NuGet”

 

En algunas maquinas con esto fue suficiente, sin embrago (desconozco la razón) en una de mis maquina no pude instalarlo a través del extension manager. Lo que hice fue instalarlo desde nuget.org

 

Una vez instalado se debe de reiniciar VisualStudio y aparece una nueva opción en el menú de Tools (Herramientas) y en el menú de View > Other Windows

Con esto se puede abrir la consola de NuGet (se necesita tener instalado PowerShell 2.0) y descargar e instalar desde ahí los paquetes (librerías) que se necesiten para el proyecto actual.

En un proyecto en particular necesitaba instalar MSpec, para eso solo ejecuté en la consola de NuGet:

PM> Install-Package Machine.Specifications

NuGet se encargó del resto: descargar dlls, agregar referencias, etc. El único ajuste que tuve que hacer en mi manera de trabajar es que nuget usa una carpeta llamada “packages” en lugar de “lib” como yo lo hacia. Pero es un pequeño cambio que bien vale la pena para aprovechar lo que hace NuGet por mi.

Al desarrollador le gusta desarrollar

Seguido leo (y escribo) comentarios, tweets, posts, etc sobre lo mal que la pasamos en ciertos proyectos en los que trabajamos. Aun y cuando lo que nos gusta hacer, como desarrolladores que somos, es desarrollar. ¿Entonces por qué es que surgen estas situaciones de descontento entre los desarrolladores?

Considero que parte del problema es la falta de decisión que se tiene sobre el curso de algún proyecto, la arquitectura, metodología, framework, (peor cuando nos toca usar el intento de framework que hizo alguien más), etc. Esto hace que el desarrollador se sienta como un code monkey, alguien que hace la talacha y no como alguien que desarrolla soluciones para las necesidades del cliente. No hay motivación.

Al participar en proyectos con diferentes empresas he notado que en los proyectos que he sufrido mas frustración, al trabajar en ellos, es cuando el cliente ya eligió que usar y peor cuando ya eligió el como hacerlo. Al iniciar o continuar el desarrollo del proyecto me encuentro con que la decisión del cliente no fue la mejor, muchas veces basada en las viejas formas de hacer las cosas o basado en la tecnología que un tercero le vendió. Esto hace que haya cierta frustración en el desarrollo del proyecto porque estoy en problemas por culpa de alguien más.

Este descontento también aparece cuando no se entienden bien las necesidades del cliente. Ya sea porque se trata de un sistema ya establecido y solo se pide que se corrijan algunos errores. Y no se quiere perder tiempo en explicarle al equipo la importancia de lo que hace el sistema. Esto hace que el desarrollador no sienta el proyecto como suyo y por lo tanto no sienta motivación para mejorarlo.

En cambio cuando se trabaja en proyectos donde el cliente explica, no solo las necesidades sino también las razones por las cuales es importante. Incluso que nos explique porque eligió la posible solución y el como. De una manera en la que el equipo pueda aportar y mejorar esa idea. Es cuando se siente una mayor motivación para trabajar en ese proyecto.

Hace poco grabamos un episodio de Dev3Cast y ahí nos comentaba Iván González sobre la importancia de la confianza en el equipo. Y la importancia de la opinión de todos los desarrolladores, incluso de aquellos que aun no tienen experiencia.

Esto puede ayudar a que el desarrollador sienta el proyecto como suyo y este dispuesto a dar un poco más de esfuerzo con tal de que se logre un mejor resultado, mientras hace lo que le gusta. Los managers deben de tomar ventaja de que al desarrollador le gusta desarrollar.

La idea de nuestro propio “Framework”

Creo que muchos de los desarrolladores hemos tenido la idea e incluso iniciado el desarrollo alguna vez de nuestro propio “Framework” para generar aplicaciones. No veo malo el escribir otro Framework. Pero muchas veces solo terminan limitándose, haciendo lo fácil mas fácil y lo difícil casi imposible, poco flexibles. Se vuelven una carga que mantener. Algo con lo que los desarrolladores no están muy entusiasmados en trabajar, porque prefieren usar algo nuevo.
He notado que esos pequeños Frameworks tienen algunas características en común (esta no es una receta, solo son unos de los problemas comunes que he visto en esos pequeños frameworks privados):
No se conocen los frameworks existentes: Lo más seguro es que ya exista algo que hace lo que se quiere lograr. Puede que se trate de un problema resuelto. Quizás lo mejor sea contribuir a un proyecto open source existente, agregando las características que se necesitan. Si la idea es hacer lo mismo que ya hace otro Framework, debe haber una razón más fuerte que el solo no tomarse la molestia de aprender a trabajar con los existentes.
No tienen un proyecto real donde usarlo: Sin una aplicación real donde probar los conceptos es difícil que se le atine a lo que realmente se necesita en un proyecto real. Puede tomarse en cuenta la experiencia de proyectos anteriores. Aun así creo que uno de los riesgos que se corre al no tener un proyecto donde probarlo es agregar características que no se necesitan u omitir las necesarias.
No son de código abierto (Open Source): Varios de estos pequeños frameworks son para uso exclusivo de quien lo desarrollo y a veces no quieren mostrarle el código a nadie fuera de la empresa, como si alguien les fuera a robar la idea y teniendo el secreto ya nadie necesitaría (contrataría) del autor del framework. Cuando en realidad es todo lo contrario, Al liberar el código de la librería/framework ayuda a que el código tenga mas ojos; y mas ojos pueden ayudar a que el proyecto sea mejor. Además de que es una buena oportunidad de que el autor se de a conocer en la comunidad (publicidad) y que la comunidad se beneficie de esto, ambas partes ganan, pero sobre todo código.
No conocen la teoría: Conocer la teoría para que la practica tenga mas sentido. Cuando el proyecto tiene buenas bases teóricas logra ser mas consistente en la manera como esta desarrollado y tanto la mantenebilidad, como su extensibilidad generalmente logran ser mayor.
Quieren abarcar mucho: El no tener un objetivo claro o un problema concreto el cual se quiere resolver termina generando una gran cantidad de código que nadie quiere usar.
El desarrollo de un framework es una buena actividad para ser un mejor desarrollador, es algo que se debe intentar (más si es en un proyecto open source). La innovación puede ocurrir. Si conociendo las soluciones existentes se cree necesitar una opción mas, pues adelante.

Comunicación con messenger en la oficina

Ahora que volví a trabajar desde la oficina, con compañeros de trabajo (antes trabajaba desde mi casa) he notado que mucha de la comunicación entre los desarrolladores, incluso con la administración, se da a través del messenger e incluso por redes sociales como twitter y facebook (aunque por estas la comunicación es mas informal). Es algo que ya venia haciendo, pero pensé que era porque no estaba físicamente ahí con ellos.

Al principio no me gustaba tanto y prefería levantarme e ir al lugar de los demás. Empece a notar que era de los pocos que hacia eso y sentía que estaba distrayendo a la persona que con la estaba hablando y a los de su alrededor.

Ahora uso mas el messenger (mensajero en español) para hablar con mis compañeros (aunque estén a lado mio) y he notado que tiene algunos beneficios que explico a continuación.

Debido a que somos muchos personas trabajando en la oficina, es casi imposible que a todos nos guste la misma música; por eso el uso de audífonos es algo común. Esto hace que al escuchar música (con los audífonos) logres cierta concentración hacia la computadora. El problema con una interrupción en persona es que obliga a "desconectarse" para poder atenderla. En cambio si la interrupción es a través del mensajero; entonces se puede atrasar un poco, no "desconectarte" en ese momento y después atender el mensaje cuando se tenga oportunidad. Incluso aunque se atienda el mensaje de inmediato, el no tener que poner en pausa la música y quitarte los audífonos para responder, logra que se pierda menos la concentración de lo que se esta haciendo.

Esto me hace pensar que si toda la comunicación se da a través de medios electrónicos, entonces ¿por que no trabajamos todos desde nuestras casas? Con las herramientas actuales de comunicación fácil podríamos todos trabajar desde casa; pero el problema es que no todos pueden. Hay para quienes trabajar desde casa implica muchas distracciones en persona, o simplemente se distraen por otras cosas, etc.

Extraño los días en que todo el equipo trabajaba escuchando la misma música (o sin música), cuando no había necesidad de audífonos. Y hablábamos sin necesidad del mensajero, pero ahora veo las ventajas y me parece una buena idea, porque hay quienes en la oficina no lo usan para hablar entre ellos y distraen a los demás con sus discusiones técnicas.

Desarrollo Web Arrastrando y Soltando

Hace unos días necesitaba realizar una aplicación web en muy poco tiempo. Debía mostrar un demo en un día; así que decidí olvidarme de las buenas practicas por un día y (usando ASP.NET WebForms) empezar a arrastrar y soltar componentes a mi página. Diseñando las paginas de captura y lectura (Grids) sin ver el markup que VisualStudio me iba generando.

Tenia mucho tiempo sin trabajar en Design View, pero no tenia tiempo de ponerme a editar el markup a mano. Una vez creadas las páginas (a la drag and drop) usando el ratón empece a conectar mis GridViews y DropDownsLists usando LinqDataSources. Todo esto con la ayuda de wizards, en algunas consultas utilice views definidas en la base de datos (MS SQL Server) también con la ayuda de diseñadores, no use SQL para definir mis views. (Creo que tenia años sin usar Views y menos de usar el query designer).

No pudieron faltar los lugares donde necesite algo de código y para ello LinqToSql me ayudo a realizar las consultas y/o actualizaciones a la base de datos. Como no tenia mucho tiempo y el código era poco opté por escribirlo directamente en los event handlers (button_click, etc). Donde el código crecía un poco entonces sí agregaba una clase para no tener métodos muy largos.

Al final el demo se pudo terminar en un día y la aplicación estaba lista para usarse en un semana. El haber podido entregar una aplicación en una semana me ha hecho reconsiderar mi opinión sobre el desarrollo web hecho arrastrando y soltando.

Se que el problema vendrá con el mantenimiento. Precisamente esta es una de las razones por las que deje de hacer desarrollo arrastrando y soltando; Pero el poco código que escribí es facil de mantener (al menos así lo veo ahora) y si despues necesito algo mas complejo podria refactorizarlo y apoyarme en pruebas unitarias para eso.

No se... me puso a pensar que tal vez si hubiera seguido las buenas practicas (TDD) quizas no hubiera terminado a tiempo y por lo tanto el proyecto se hubiera perdido.

Con esto no quiero decir que de ahora en adelante puro drag en drop (veremos como nos va con las nuevas features). Solo quise compartir mi experiencia en un proyecto pequeño y rápido del cual me sentí bien del código entregado y del poco tiempo que nos tomo hacerlo (Aunque fuera a la Drag and Drop) .

Editores para RubyOnRails en Windows

Al trabajar con RubyOnRails desde Windows he usado algunos editores y IDE's con sus ventajas y desventajas cada uno de ellos.

El primero que utilicé fue Notepad++, porque ya lo tenia instalado en el sistema. Me gustó por lo ligero y rápido que responde el editor, pero lo que me hizo buscar opciones es que no coloreaba muy bien todos los archivos con los que trabajaba. Ademas de que no cuenta con un explorador del proyecto. Hay complementos para para tener una lista de carpetas, pero ninguna me gustó del todo.

La segunda herramienta que usé fue NetBeans. Ya había trabajado con NetBeans antes (desarrollando en java) así que no me fue difícil conocer el IDE. Me gustó trabajar con el IDE ya que estoy acostumbrado a usar uno en mi trabajo (trabajo con .Net en C# desde Visual Studio). Pero seguí buscando alternativas, ya que NetBeans es algo pesado y al buscar información, sobre como realizar ciertas tareas en rails, siempre encontraba ejemplos con la consola y simples editores. Al hacerlos en netbeans sentía como que hacia "trampa".

Intenté aptana pero estaba lentísimo en mi maquina, así que lo des-instale luego luego.

Buscando algo parecido a TextMate encontré E-Editor que según dicen es algo así como el textmate para windows; pero es de pago y actualmente no cobro por desarrollar en ruby. Por lo que seguí buscando una opción gratis.

Así fue como encontré intype un editor muy sencillo y bonito que cuenta con un project view (que es simplemente una carpeta raíz en una vista de árbol, no tiene un archivo con la definición del proyecto). Lo estuve usando por algún tiempo junto con la consola de comandos; pero a ratos sentía que tenia que escribir mucho, no te auto-completa nada...entonces seguí buscando.

Encontré Komodo, un editor sencillo que si te auto-completa algunas cosas y ademas puedes definir tus propias plantillas, funciona bien. Sin embargo nunca me terminó de gustar. Tiene algunos detalles como no poder abrir un archivo rápidamente con solo teclear parte del nombre y otras cosillas que hacían que no me gustara del todo. Lo usaba junto con la consola de comandos.

Y así después de intentar con algunos editor regresé a NetBeans, donde todo esta integrado, No necesito la consola para usar los generadores básicos, ni para la mayoría de los comandos de rake, ni para iniciar el servidor Web. Es por eso que por ahora mi editor (IDE) para trabajar en ruby on rails en windows es netbeans.

Siento que me sirvió el estar usando editores sencillos y usar la consola. Para conocer (practicar) a bien los comandos. Pero una vez que los conozco me gusta lo rápido que los uso desde NetBeans...obviamente esta opinión puede cambiar de un momento a otro sin previo aviso.

Aun me falta por intentar Vim...

Hablando sobre Certificaciones

Hace tiempo participé en el podcast dev3cast donde hablamos sobre Certificaciones ¿para qué?

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

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.

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