Algunos puntos que se mencionan, para reforzar o para comenzar a implementar si todavía no lo hago:

• Hay mejores desarrolladores que yo. Tengo que ver cómo trabajan y así obtener algunos tips para superarme a mí mismo.
• Leer. Tanto blogs como código fuente de otros. Hay muchísimo conocimiento ahí afuera.
• Lo que aprendo y se, lo comparto. Esto ayuda muchísimo a reforzar el conocimiento. Si les muestro a los demás lo que pienso y hago puedo obtener valioso feedback para saber si realmente estoy haciéndolo bien. Además esto me puede ayudar a identificar problemas específicos y contar con la experiencia de otros para resolverlos.
• Hablar. Entrar en contacto con mi grupo local o en la facultad y dar una charla de lo que se. Además esto hace que los demás me conozcan. Pero sobre todo, como dice López, cuando enseño, aprendo. Interesante para los que se sientan llamados a la docencia.
• Practicar. Jugar e implementar algo para probar una idea. Luego publicarlo y mostrarlo a los demás. Por ejemplo escribir un intérprete: en esto Ángel López es experto, de vez en cuando escribe uno y lo publica en su blog.
• Aprender cosas nuevas. Ir más allá de lo que se. Un lenguaje, una plataforma, una técnica de programación, una metodología…

Y si bien ya está implícito, yo agregaría uno más: siempre mantener un cierto aire de inconformismo con lo que hacemos. El software siempre se puede mejorar, siempre podemos ser un poco mejores en lo que hacemos.

¿Ustedes qué estrategia tienen?

A primera vista, Juan Pablo II parece muy distinto a Benedicto XVI. Quizá pocos sepan que el Cardenal Joseph Ratzinger fue coautor de esa famosa frase sobre los judios: “son nuestros hermanos mayores en la fe”. O que fue la mano derecha de Juan Pablo II durante su pontificado, como prefecto de la Congregación para la Docrina de Fe. O que, después de 2001 cuando estos casos de pedofilia pasaron a las manos de dicha congregación, fue tan criticado por sus medidas de tolerancia cero, que incluso se lo llegó a considerar un enemigo de los Legionarios de Cristo por el caso del padre Marcial Maciel.

Me gustó el video porque seguramente la mayoría escucharon hablar de Benedicto XVI, pero muy pocos saben quién es Joseph Ratzinger, qué hizo y qué hace como Papa.

A veces encontramos en las parejas ésta concepción de lo que es el amor: “te amo porque así lo siento”. Según esta definición el amor es un sentimiento. El problema con esta concepción es que los sentimientos son impredecibles: hoy sentimos algo, pero mañana quizá no. Los sentimientos quizá sean lo más inestable que tiene el hombre. Por lo tanto si el amor es un sentimiento, y si mi pareja dice que me ama, es porque ahora lo siente así, pero mañana o pasado los sentimientos se irán. En algún momento el o ella me faltará el respeto, me ofenderá, me decepcionará… y no hay forma de mantener los sentimientos en alto en esas situaciones. Entonces ¿qué pasó con el amor?

Por supuesto que en las parejas donde “el amor es un sentimiento” las cosas no son tan caóticas. Pero sí bastante confusas. A veces no se entiende por qué uno está con el otro, después uno está totalmente convencido, y otra vez desanimado, y así. Esto pasa cuando son los sentimientos los que dirigen.

Por supuesto que la parte sentimental es muy importante en el amor, pero esto es distinto a decir que el amor es un sentimiento. En realidad, el amor es una decisión. En vez de decir “te amo porque así lo siento”, digo “te amo porque después de conocerte en todo este tiempo que pasamos juntos, he tomado la decisión de amarte”. En este último caso, si la decisión es firme y fundamentada, una decepción u ofensa del otro no hace caer al amor, porque éste no depende de un sentimiento, es una decisión mía. Yo quiero amarte. Yo lo decido.

Estas son las palabras finales de Cuevas en el post citado:

[...] sin duda los sentimientos deben ocupar su lugar en el amor, pero nunca deben ser guía de decisiones. No debemos permitir que sea el corazón quien nos guíe, debemos ser nosotros quienes le guiemos a él.

Amar significa comprometerse a diario, no sólo cuando el sentimiento acompaña. Significa determinarse en mantener el compromiso, poner los medios para que lo que yo pueda hacer no falte. El amor no es sólo cuestión de sentimientos sino de decisión.

Este es el primero de la serie:

Los demás videos los pueden encontrar en estos links.

Es muy buena la explicación de “Java” Lopez:

Implementa algo sencillo: código que dado un string con una URL, identificar el protocolo, el dominio, y el recurso que está contenida en esa dirección. En TDD, se va escribiendo el test, el código que pasa el test, y se va progresando de a poco. No hace falta escribir el código correcto y completo desde el principio. Como en otras tantas actividades, el “baby-step”, el “pequeños pasos” de avance, nos ayuda para ir incrementalmente produciendo el resultado esperado.

Noten el ciclo rojo-verde-refactor, el código mínimo que se agrega en cada tests (a veces, retornando valores puestos a mano, sólo para pasar los tests), refactorizando el test si hay código duplicado, las micro-decisiones de diseño que se van tomando, etc… Excelente trabajo para mostrar en video!

Además otra cosa interesante, no directamente relacionado con TDD pero si con las pruebas de unidad, es la cantidad de veces que el autor prueba distintas implementaciones sin preocuparse, ya que tiene toda una suite de tests para saber si la misma es válida. Eso es algo hermoso

En Making Good Software, leí una vez un post muy interesante titulado “TDD is not about testing!!!” que me llamó mucho la atención al principio. Mucha gente piensa que escribir los tests primero es hacer TDD, lo cual es incorrecto. TDD es una práctica de diseño, y es todo un proceso:

Esos tres estados de vida son el Matrimonio, el Sacerdocio y la Vida Consagrada. Me encantó el texto que hablaba sobre el sacramento del Matrimonio, y quería compartirlo con ustedes. Ahí va.

Y así resulta que tú eres para mí el sacramento, la posibilidad de encuentro con el amor de Dios, y yo lo soy para ti. Es Él quien en mí te ama, te comprende, te perdona… Y nunca soy más yo, más plenamente yo, que cuando es Él quien con mi vida, mis manos, mis labios y mi corazón se acerca a ti.

Y no termina aquí la realidad de este sacramento. Tú y yo, marido y mujer, somos sacramento para nuestros hijos. El primer “lugar” desde el que nuestro buen Dios se les va a acercar, les va a llamar, bendecir, proteger, hacer libres…

Y aún más: nuestro hogar, esta “primera” Iglesia, deberá ser para cuantos allí lleguen, posibilidad de encuentro con Dios. Un “lugar” desde el que nuestro Señor pueda acoger, comprender, escuchar y atender a cuantos vengan.

Él será en mí para ti la fuerza del don sin reservas, del perdón permanente, de la comprensión y de la ternura, de la exigencia y de la fidelidad. Él será en mí todo para ti y en ti todo para mí. El será cada día en mí una nueva oportunidad para ti, porque Él en mí siempre cree en ti y te espera y te ama.

Y los dos lo seremos para nuestros hijos y nuestro hogar lo será para todos.

Arquitectura de Buildbot

Buildbot permite configurar de varias formas el modo en que va a obtener el código fuente del proyecto y cómo realizará las actualizaciones subsiguientes. Por ejemplo, el modo “update” hace que las operaciones de checkout/update se ejecuten en el directorio de trabajo, y no en uno independiente, como en el modo “copy” o “clobber”, que mantienen un directorio separado y limpio del repositorio (en el caso de Mercurial, “copia de trabajo” en el caso de Subversion) y hacen una copia del mismo para realizar la compilación (esto asegura que siempre se compile todo y que no influyan archivos generados en procesos anteriores, además de otros problemas menos comunes pero que existen).

El problema que estuve teniendo es cuando utilizo Mercurial. Al intentar traer el código fuente, Buildbot entra en un bucle infinito donde realiza el checkout (clone), borra el directorio, otra vez clone y asi… me pareció rarísimo el comportamiento. Versiones anteriores de Buildbot con versiones anteriores de Mercurial funcionan bien.

En uno de los pasos para realizar el checkout/update, Buildbot verifica si ha cambiado la URL del repositorio. Si esto es así, entonces hace clobbering, o sea, vuelve a bajar todos los cambios (checkout) y obviamente no realiza un update, aunque el modo no sea “clobbering”. Para saber si dicha URL ha cambiado, ejecuta un “hg paths default” en el directorio de trabajo y lo compara con la URL asignada en el archivo de configuración central del Build Master.

El bug está en que al ejecutar “hg paths default” Mercurial 1.3.1 devuelve el password oculto con asteriscos:

$ hg paths default 

http://miltondp:***@url.mi_proyecto.com/path/al/repo

… y, obviamente, la URL asignada en el archivo de configuración está completa (sin el password oculto). Al compararse ambas, son distintas, y por lo tanto siempre se hace clobbering.

Rápidamente me fijé si Mercurial poseía alguna opción para mostrar el password en la salida de “hg paths”. No posee dicha opción por lo visto, pero me encontré con un parche que alguien envió alguna vez, el cual parece que nunca fue incluido. El mismo agrega la opción “–show-passwords” para mostrar la URL completa al ejecutar “hg paths”. Lo pueden bajar aquí. El archivo a parchear es “/usr/lib/pymodules/python2.6/mercurial/commands.py”.

También hay que parchear Buildbot para que utilice esta nueva opción al comparar los repositorios. Este otro parche lo pueden bajar desde este lugar. Tener en cuenta que el archivo a parchear tiene el mismo nombre que el de Mercurial. El path del mismo es “/usr/lib/python2.6/dist-packages/buildbot/slave/commands.py”

No se olviden de reiniciar el servicio de Buildbot, y de borrar los archivos .pyc de Python (por lo visto a veces funciona aunque no lo borremos). Ahora el ciclo funciona como uno espera:

La frase: “Cuando uno ve la pobreza, la miseria y hasta la injusticia, tiene dos maneras de actuar: tratar de buscar al culpable, o aceptar la cuota de responsabilidad que a cada uno nos cabe como miembros de esta sociedad y ver de qué manera podemos dar una mano [...] Todos debemos hacer lo que nos corresponde hacer y un poquito más.”