Primero un poco de background, a principio de año lei el libro “The productive programmer”.

La verdad no es un gran libro, me deje llevar por un par de reviews y el glosario parecía interesante, pero resulto ser una colección de anécdotas (algunas muy buenas) y alguna que otra analogía que me ayudaron a entender mejor algunos conceptos, pero el resumen del libro se puede hacer en una palabra: automatizar.

Automatizar es genial: cualquier trabajo repetitivo es propenso a errores cuando lo realiza una persona, en cambio cuando lo hace una computadora no. Una computadora no se “olvida de un parámetro” o “se saltea un paso”, la computadora hace lo que le digamos y listo (Si sabemos decírselo es otro tema). Y dentro de la creación de software existen muchas tareas que se pueden hacer de forma automática, una de ellas es la integración continua (del ingles Continuous Integration):

Integración continua es una practica del desarrollo de software donde los miembros de un equipo integran su trabajo frecuentemente, normalmente cada persona integra su trabajo al menos una ve por día – dando múltiples integraciones por día. Cada una de estas integraciones es verificada por una construcción automática del software (incluyendo los tests) para detectar errores de integración tan rápido como sea posible. Muchos equipos encontraron que este acercamiento llevo a reducir significativamente los problemas de integración y permitió al equipo a desarrollar software de una forma mas rápida.

Martin Fowler, Continuous Integration

El primer paso para la integración continua se logra teniendo el código fuente de la aplicación en algún sistema de control de versiones (SCM por sus siglas en ingles). Particularmente a mi me gusta Mercurial por ser distribuido y simple, pero existen otras opciones como GIT y Subversion. El segundo paso es tener una construcción automática (automated build).

¿Que es un “automated build”? Del mismo texto de Fowler:

Hacer que el código fuente se convierta en un sistema funcionando puede ser un proceso complicado que involucre compilar, mover archivos, cargar esquemas en las bases de datos y mas. Pero, como la mayoría de las tareas en el desarrollo de software, puede ser automatizada y, como consecuencia de esto, debe ser automatizada. Pedirle a personas que escriban comandos o hagan clicks en ventanas de dialogo es una perdida de tiempo y un campo fértil para errores.

Así que entendemos a un automated build como tomar el código fuente y llevarlo a un sistema andando, en el que corremos las pruebas de forma automática. ¡Eso es perfectamente scripteable! Puede hacerse un hook para el SCM que elijamos que cuando recibe un commit se encargue de correr un script que compile el código (en este caso en particular estoy usando Python para el proyecto, así que no se compila, ¡pero puede correr los tests!), es tan fácil que me sorprende que nadie lo halla hecho ya… Hudson, CruiceControl o Bitten (de los creadores de Trac) son algunos de los que ya lo hicieron, y hay muchos mas en la pagina de Wikipedia al respecto. De hecho ayer anunciaron en Mozilla que van a empezar a utilizar Hudson para el desarrollo de la pagina de Addons de Firefox y Thunderbird.

Mi gusto particular en herramientas de CI es BuildBot. La primer razón por la que me gusta es porque esta hecho en Python, y se puede extender y configurar utilizando este lenguaje. Eso es una ventaja grande porque en el espíritu de ser DRY puedo hacer que configuraciones como “a quienes avisarles por email cuando falla un build” puedo, en lugar de escribirlas en la configuración, hacer que las lea dinamicamente de la base de datos de Redmine o Trac para el proyecto en cuestión. La segunda es que es muy completo, tiene distintas formas de notificarte, trabaja con muchos SCM (Subversion, Mercurial, GIT, ¡hasta CVS!) y tiene una documentación que es muy buena como referencia, aunque lamentablemente es pésima como introducción.

Así que el plan para el próximo post es configurar que cuando subo código al repositorio de Mercurial para django-yabe, BuildBot haga un build (Django tiene un framework de unittesting muy completo) y me avise por email si fallo.

Good programs do not contain spelling errors or have grammatical mistakes. I think this is probably a result of fractal attention to detail; in great programs things are correct at all levels, down to the periods at the ends of sentences in comments.

Dad hacker en  30 years of C

Me viene justo porque estoy leyendo  The Elements of Style.

En su libro The 7 Habits of Highly Effective People Stephen Covey crea una de las analogías mas claras sobre esto:

Un hombre se encontró con un leñador en las montañas. El hombre paro a observar al leñador, mirándolo atentamente mientras talaba un gran árbol. El noto que el leñador sudaba mientras trabajaba talando y talando, pero que no avanzaba mucho en su tarea. El espectador entonces noto que la a sierra que el leñador estaba usando estaba tan afilada como un cuchillo de manteca. Entonces le dijo: “Disculpe señor leñador, no pude dejar de notar que duro que esta trabajando en ese árbol, pero sin avanzar mucho”. El leñador respondió mientras se secaba el sudor de la frente, “Si… lo se. Este árbol me esta dando algunos problemas.”. El espectador entonces le dijo, “Pero señor leñador, su sierra tiene tan poco filo que es imposible que corte algo.” “Lo se”, dijo el leñador, “pero estoy muy ocupado talando este árbol como para ponerme a afilar la sierra.”

“Sharpen the Saw”, The 7 Habits of Highly Effective People, Stephen R. Covey, 1989

The 7 Habits of Highly Effective People

Si bien el libro no es exclusivo de programadores recomiendo leerlo porque sirve bastante bien para nuestra disciplina.

Personalmente considero que de las herramientas que utilizo día a día le saco el jugo a unas pocas, vim, firefox, zsh y la shell en general, y quizás a Python como lenguaje de scripting para automatizar las tareas repetitivas. Pero sin mucho esfuerzo veo muchos mas lugares donde podría mejorar los programas que uso o elegir mejores programas para usar:

El rol que cumplo en mi trabajo se puede llamar “Project Manager Pulpo”, porque son varios los proyectos que “llevo adelante” y una de las formas de comunicación mas comunes es el email, para el cual utilizo Thunderbird. Hay decenas de metodologías para organizar/seguir varios temas por email, yo personalmente sigo una versión bastante liberal de GTD (Getting Things Done: The Art of Stress-Free Productivity, David Allen, 2002) pero mucho del trabajo que hago es manual (Como marcar emails con etiquetas “Por Hacer” y “Esperando Respuesta”), debería automatizar eso, y quizás pasarme a mutt, getmail, maildrop y scriptearlo un poco mas así hago uso de vim en mutt.

El libro que estoy leyendo ahora es The Productive Programmer, si bien aun voy por los primeros capítulos ya me dio bastantes temas en los que pensar, y me motivo a hacer algunas pruebas: utilizar macros (una función de vim que siempre supe que existía pero ignore deliberadamente), utilizar un program launcher (tenia keybinds a los programas mas utilizados, pero con Gnome-Do ahora puedo hacer prácticamente todo sin mover mis manos del teclado hacia el mouse), aprovechar mejor algunas funcionalidades de los SCM que utilizo (Mercurial y Subversion), y hasta aprovechar de forma eficiente los virtual desktops.

Hoy en Hacker News, un muy buen sitio si buscan estar informados del ambiente IT internacional, salio la siguiente pregunta: “Ask HN: Why no love for PHP? ” y me dio mucha risa la primer respuesta:

Las personas que son realmente buenas en sus trabajos se obsesionan sobre sus herramientas. Los artistas se obsesionan sobre la pintura, los carpinteros sobre sus herramientas a medida y los cocineros sobre sus cuchillos.

PHP es como comprar un cuchillo de chef en Wal-Mart. Vos podes hacer un plato 5 estrellas con el, corta perfectamente, pero no inspira la misma pasión que un cuchillo Shun.

Esto se extiende a todo. Si elegís el mejor editor de texto, uno completo como el que describí en mi primer post en este blog, vas a darle un uso y una importancia mucho mas alta que la que va a tener notepad que también puede editar código. Si elegís cualquier SCM, seguramente sea para tirar código ahí, si evalúas los pro y contras de cada uno seguramente cuando lo uses vas a aprovechar esos pro y no ignorarlos o dejarlos en desuso.

Dejo para otro día elaborar una lista de lo que podría considerarse las herramientas básicas de cada programador, ya enumere editor y SCM pero creo que hay muchas mas y cada una se merece su artículo aparte.