Herramientas: Una buena obsesión
Como ya mencioné en otros posts la elección de las herramientas con las que trabajo es una obsesión, una sana pero exigente obsesión. Considero a esa particular mirada a como trabajo y si lo hago lo suficientemente efectivo como sana porque me gusta trabajar menos. ¿A quien no? Si hay algo que estoy haciendo de una forma no-óptima en mi trabajo quiero darme cuenta, corregirlo, y disfrutar de ese tiempo haciendo otras cosas.
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.
¿Que hace a un buen commit?
May 5, 2009 Articulos
Estaba leyendo este artículo de Pablo Santos sobre como los changelogs que puede generar un SCM como Mercurial o Subversion pueden ser utilizados como “documentación” del código y del trabajo que se hizo sobre el y me puse a pensar: ¿Que hace un buen mensaje de commit?
Después de un par de ideas, la mayoría de las cuales las tengo por haberlas leídos en otros blogs, concluí que un buen mensaje cumple con los siguientes puntos.
- Es corto.
- Describe lo que se cambio, si es posible también porque.
- Referencia el ticket/email que hizo necesario el cambio en el código.
- Utilizar prefijos como FIX y ADD para identificar que es lo que se hizo.
Un buen ejemplo es el que puedo encontrar en esta discusión de StackOverflow:
Changed paragraph separation from indentation to vertical space.
…
Fix: Extra image removed.
Fix: CSS patched to give better results when embedded in javadoc.
Add: A javadoc {@link} tag in the lyx, just to show it’s possible.
…
- Moved third party projects to ext folder.
- Added lib folder for binary library files.
…
Fix: Fixed bug #1938.
Add: Implemented change request #39381.
Yo soy de los puristas que creen que el código se debe escribir en ingles, y, por extensión, los commit messages.
Pero hubo un punto de esa misma discusión que me llamo mas la atención:
If you find yourself writing a very long list of changes, consider splitting your commit into smaller parts
Que me llevo a pensar en algo mas importante del mensaje: ¿Que hace a un buen commit?
Un commit es, en la mayoría de los SCM, la acción por la cual los cambios que uno hizo al código en una copia que tenga en su PC son introducidos al repositorio general donde todo el resto puede ver y utilizar el código. El que sea bueno o malo depende de su utilidad, y en el caso de algo tan simple y delineado como “cambios al código” solamente tengo dos opciones: utilizar o descartar esos cambios.
Un buen commit es aquel que me permite ignorarlo o revertirlo,y seguir aprovechando el resto de las funcionalidades de otros commits previos y posteriores. Para que esto sea así un commit debe seguir algunos lineamientos:
- No arreglar o cambiar mas de una caso por commit.
- Los cambios tienen que ser chicos.
Mas de una ves vi joyas en los bugzilla de varios proyectos open source: discusiones, información, incluso documentación. Pero algo que siempre me asombro es que hay grandes patchs (en ambos sentidos, lo que aportan y el tamaño de los mismos), hechos por gente que no colabora habitualmente con el proyecto y que quedan ahí indefinidamente porque al ser tan grandes nadie los aplica como un commit.
Haciendo uso de Trac, una herramienta que incluye un wiki para documentar, un navegador del SCM en uso (Mercurial, SVN y GIT estan soportados, no se otros) y un sistema de tickets, puedo ver los cambios que se van comiteando a los distintos proyectos open source que uso, y es raro ver alguno que supere las 100 líneas con documentación y tests cases incluidos! (Ej: Django)
Dejo para otro post una buena descripción de los distintos SCM.