Hace un par de días os escribía un resumen del Git Merge User Day. Aquí os dejo mis impresiones sobre el Hack Day.

Durante el desayuno, compartí mesa, entre otros, con  Thomas Ferris Nicolaisen, que produce el podcast gitminutes.com. Su entusiasmo por lo que hace y cómo lo cuenta es especialmente motivador y me ha dado un par de buenos consejos para el blog que confío en poner en práctica en breve. Estaba, además, muy interesado en cómo está funcionando tanto este blog como los cursos de git así que estuvimos compartiendo datos de Google Analytics e intercambiando experiencias.

Compartiendo la mesa estaba con nosotros Scott Chacon, que nos estuvo contando cómo utilizan en github algunas de las herramientas para trabajar colaborativamente. Me quedé con dos ejemplos sobre cómo utilizan campfire:

• Cuando se nombra a una persona en una sala, esta recibe un aviso y puede eventualmente unirse o responder offline si la sala ya está cerrada cuando se intenta conectar.
• Meten las conversaciones de campfire en Elastic Search y luego utilizan el motor para buscar las conversaciones. Antes de esta combinación, aparentemente se perdía mucha información que luego no podía encontrarse de nuevo.

Curioso ¿verdad? Con estas «simples» modificaciones el ratio de participación en las conversaciones se disparó, así como la utilidad de la herramienta. También interesante cómo han ido evolucionando del «stupid drinking» al «we still drink a lot» con un, digamos, consumo responsable. Scott comentó durante el desayuno dos comandos que no conocía: git-fast-import y git-fast-export. Bastante útiles para mover commits de un sitio a otro sin hacer rebase (básicamente es copiar commits).

Después del desayuno empezamos a trabajar. Yo decidí hablar un poco más con Thomas, que me entrevistó para su podcast. Cuando terminé estuve charlando con algunas de las personas que hablaron el día anterior y aproveché una buena parte de la mañana para organizar las notas y avanzar lo máximo posible en los posts.

Después de comer empecé un pequeño proyecto en ruby que, utilizando rugged, me permite generar repositorios con commits y ramas predeterminadas. Situación muy habitual: te preguntan algo sobre un rebase y para responder necesitas un repositorio con dos ramas y varios commits en cada una de ellas. Antes empleaba unos 2-3 minutos en crear los commits y las ramas. Con esta herramienta puedo hacerlo en segundos. Está bastante verde, cuando la tenga un poco más pulida la liberaré. La verdad es que para dos horas que le dediqué al tema no está nada mal. Lo bueno de este tipo de eventos es tener a mano a la persona que te puede sacar del atolladero. En mi caso fue Carlos Martín Nieto, que me ayudó a desatascarme cuando no veía por dónde seguir.

Por la noche estuvimos en el Golgatha Biergarten. El nombre prometía y el DrinkUp desde luego no defraudó: para alguien que no le gusta la cerveza, beberse un litro y medio en una noche es todo un logro. Lo acompañé de un par de salchichas o tres (ya no me cuerdo). La verdad es que con un par de cervezas de ese tamaño en el cuerpo es más fácil romper el hielo así que seguimos hablando un poco de git, arreglando los problemas de España y comentando la cantidad de Españoles que había últimamente en Berlín. Como dijo Sergio: es la venganza por la «ocupación» Alemana de Mallorca.

Os animo a que asistáis a este tipo de eventos, y si es fuera de España mejor. Se aprende mucho compartiendo con gente de otros países. Hacía casi un año que no salía fuera y lo echaba de menos. El próximo viaje es el iOS Dev UK. Ya os contaré.

Estamos en Berlín en pleno Git Merge Hack Day. Ayer fue el user day en git-merge 2013, la conferencia para usuarios de git que Github ha organizado en la capital alemana este fin de semana. 

A primera hora registro y café y un ratito de networking hasta que ha dado comienzo la conferencia. El formato ha sido abierto y muy, como no, colaborativo (muy github):

• Lightning Talks hasta la hora de la comida
• Tarde libre en formato “open space” en el que se proponían temas para hablar sobre ellos

Para los que no sepáis lo que son las Lightning Talks, podemos resumirlo en lo siguiente: “el que tenga algo que compartir que salga y lo haga”.

Y la verdad es que ha salido bastante gente a compartir herramientas, presentarse, sugerir temas de conversación para la tarde o contar el último proyecto en el que estaba trabajando:

• El primero ha empezado con fuerza. Un plugin para integrar XCode con Github disponible vía “Alcatraz”. Podéis encontrarlo aquí: https://github.com/larsxschneider/ShowInGitHub. Está todavía en desarrollo aunque la verdad es que promete bastante.
• Luego nos han presentado una iniciativa para hacer públicas las discusiones de los parlamentarios a medida que las leyes se van elaborando. ¿Os imagináis a nuestros queridos políticos haciendo un merge de la ley antipiratería y luego haciendo un pull request para incluir sus modificaciones y comentarlas con el resto de grupos? No, yo tampoco. Hay sitios en los que esto pasa. Esto es madurez democrática y lo demás son tonterías. Aquí tenéis el repositorio y el listado de leyes: https://github.com/Bundestag y http://bundestag.github.io/gesetze/ (en Alemán).
• Dos de los desarrolladores de git-submodules han presentado rápidamente las novedades que están implementando (https://github.com/jlehmann/git-submod-enhancements/wiki).
• Christian Couder nos ha contado lo potente que es git-bisect para localizar bugs (http://es.slideshare.net/ChristianCouder/enjoy-fighting-regressionswithgitbisect). Además, es muy fácil automatizar la búsqueda con un test y, una vez localizado, corregirlo y crear un commit con la solución y el script de testeo. En una encuesta / estudio realizado entre 40 desarrolladores se ha observado un 40% menos de bugs y hasta un 80% de reducción en el tiempo de localización y depuración del bug cuando se utiliza con TDD. Una herramienta para tener en cuenta. En una intervención posterior, una persona de Ericsson ha compartido con nosotros como utilizó git bisect para detectar y corregir un bug en perl.
• Roberto Tyley nos ha presentado BFG-repo-cleaner, una herramienta escrita en Scala que multiplica por mucho la velocidad de git-filter-branch: http://rtyley.github.io/bfg-repo-cleaner/. En este enlace tenéis un vídeo que compara el rendimiento de un raspberry-pi usando su herramienta vs un MacBook Pro usando git-filter-branch… por supuesto gana la RaspberryPi.
• Michael Haggerty ha presentado git-imerge, una herramienta para hacer merges incrementales entre ramas de larga duración (http://softwareswirl.blogspot.de/2013/05/git-incremental-merge.html, https://github.com/mhagger/git-imerge). Muchas vences me habréis oído decir “no dejes el merge para el final”, haz merge a menudo para resolver los conflictos poco a poco. Puesta esta herramienta facilita esta tarea. Está todavía en modo experimental, seguiremos su evolución con atención porque es realmente útil.
• Jack Pearkes ha presentado get una herramienta escrita en Go y pensada para hacer fetch de una cuenta de github y todos sus repositorios. Siguiendo con el ejemplo que ha puesto Jack, antes de salir de casa con el portátil, me hago un fetch de todos los repositorios de mi cuenta y me voy al tren con todos actualizados.
• Filip Noetzel ha hablado de dos proyectos bumpversion y geocommit. El primero sirve para actualizar todas las cadenas de versión de un programa, crear un commit y etiquetarlo. Está escrito en python y nos puede ahorrar trabajo a la hora de generar una nueva versión de nuestra aplicación. El segundo, geocommit, es un servicio que geolocaliza los commits y nos ayuda a ver de dónde vienen las contribuciones a un proyecto.
• Una persona nos ha presentado gource. Digo una persona porque no me he quedado con su nombre y no era el que lo ha desarrollado. Es una aplicación que lee el repositorio y hace una animación de cómo evoluciona un repositorio. Muy chulo el resultado para repositorios grandes con muchos participantes. Después de esto las pantallas han estado mostrando la animación del repositorio de git el resto del día.
• Se hicieron varias presentaciones sobre libgit2. En este momento es la niña bonita de Github ya que como nos contó Vicent Martí en la presentación (http://vimeo.com/64716825) les ha permitido resolver varios problemas de escalabilidad en el backend. Se trata de una implementación de git empaquetada en una librería en C de forma que puede utilizarse en cualquier aplicación. ¿Te imaginas poder hacer un commit desde una aplicación echa por tí en ruby o python? Pues esto es, entre otras cosas, lo que permite hacer libgit2. La librería está bastante madura y tiene bindings para muchos lenguajes (lo siento, parece que Java no es uno de ellos de momento).
• Relacionado con libgit2, tuvimos dos presentaciones de personal de Microsoft en la que nos mostraron cómo instalar y usar el plugin de git en Visual Studio 2012 y cómo clonar un repositorio alojado en TFS usando git-tf. Parece que dentro de poco Visual Studio ya incluirá el soporte de git nativo y no será necesario instalar ningún plugin.
• Mislav Marohnić nos presenta hub una herramienta escrita en ruby para trabajar con repositorios github desde la línea de comandos. Github la utiliza en sus cursos intermedios/avanzados.
• Sergei nos presentó una herramienta para enseñar git bastante curiosa, muy parecida a http://pcottle.github.io/learnGitBranching/. Aunque el código no está en este momento abierto sí se puede usar en este enlace http://io.git-init.ru/git-trainer/
• Matthew McCullough nos habló sobre los recursos que github ha puesto a disposición de la comunidad para aprender git: teach.github.com, learn.github.com y www.youtube.com/github.
• Simon nos presentó subgit una herramienta que permite utilizar un repositorio tanto con clientes subversion como con clientes git. Si trabajas con los dos sistemas o te estás planteando una migración, esta puede ser una herramienta muy útil.
• Jetbrains hos nizo una rápida exposición de algunas de las mejoras en las que están trabajando para el cliente git que incluyen en sus IDE. Me gustó mucho lo que ellos llaman “smart checkout” que básicamente es un stash-checkout-unstash, muy útil cuando has hecho varias modificaciones en el código en la rama que no era. También mostraron una nueva característica: cuando te rechazan un push porque tus referencias no están actualizadas, tienes que volver hacer un pull y luego volver a hacer el push. En las próximas versiones, Jetbrains lo hará por nosotros dándonos la opción la hacer el pull con un merge o con un rebase. Estos chicos siempre pensando en que trabajemos menos…(http://www.jetbrains.com/idea/webhelp/using-git-integration.html)
• Nos enseñan otro proyecto muy curioso: emscripten. Se trata de un compilador LLVM-to-Javascript, es decir, coge LLVM Bitcode y lo transforma en javascript… ¿qué excusa tenéis ahora para no escribir javascript?
• Sergio Gil, con el que tuve el placer de estar charlando un buen rato durante la tarde, nos presentó GHContributors (http://ghcontributors.herokuapp.com/) una web que nos muestra todas las contribuciones que un usuario ha hecho a github.
• http://www.versioneye.com/ un servicio que monitoriza las librerías que utilizas en tu proyecto y te avisa cuando cambian de versión.
• Para cerrar la sesión, Scott Chacon nos habló del portal git-scm.com/community. Como el mismo dijo, una página para usuarios de git, no para desarrolladores. Nos estuvo hablando del libro (http://www.github.com/progit/progit) y de los planes que tiene para la segunda edición, que quiere escribir contando con la colaboración más activa de usuarios y desarrolladores. También se habló de la traducción del libro, que os recuerdo se realiza a través de la comunidad, y nos habló de que en github se están planteando incluso la contratación de traductores profesionales para mejorar ese aspecto. Por supuesto no dio fechas ni plasmaron un compromiso formal sobre ello, lo plantearon como opción para ayudar a resolver el problema que se plantea con un tema tan complicado como es la traducción. En esta discusión, que continuó más tarde en el grupo de formación en git, contamos con la experiencia de Axel Hecht (Mozilla) y cómo gestionan ellos las traducciones de sus herramientas.
• Para terminar las ligthning talks, Scott nos recordó, por si se nos había olvidado, que github es el servidor de repositorios subversion más grande del mundo. Basta con que hagáis un checkout de cualquier repositorio de git con vuestro cliente favorito de subversion:

svn checkout https://github.com/progit/progit

Después de las charlas, se establecieron varios grupos en los que se habló de diferentes temas: formación, migración a git, traducción de material y recursos. Matthew McCullough y Brent Beer estuvieron hablando sobre cómo enseñan git y github en diferentes partes del mundo. Entre las 10 personas que estuvimos charlando e intercambiando experiencias, había dos corrientes: los que mostraban el grafo desde el primer momento y los que preferían esperar un poco antes de mostrar las famosas “pelotas con padres”. La conversación fue muy productiva con ideas y un notas para mejorar los cursos de git.

En paralelo a esta conversación sobre formación en git, tuvo lugar otra muy interesante sobre migración. Como por el momento no he desarrollado la capacidad de estar en dos sitios a la vez, Peter Jönsson (https://github.com/mindjiver) and Andrey Devyatkin (https://github.com/Andrey9kin) tuvieron la gentileza de volver a hablar conmigo sobre cómo hicieron en Ericsson una migración de Clear Case a git que afectó a mil personas. Lo primero que hicieron fue formar un equipo de 8 personas que durante los casi dos años que duró el proceso se dedicaron en exclusiva a ese proyecto. Dado que tenían un alto grado de personalización en la instalación que tenían de Clear Case, tuvieron que realizar varias herramientas a medida para implementar la funcionalidad que necesitaban. De echo, 4 de las personas del equipo eran programadores de backend y frontend dedicados a la aplicación que han desarrollado. Una de las necesidades que tenían era el almacenamiento de metadatos en los repositorios y me estuvieron comentando que de las tres opciones que tenían (mensaje del commit, git-notes y etiquetas) finalmente optaron por almacenarlos en el mensaje del commit y desarrollar un parser con expresiones regulares para extraer y buscar la información. Comentamos opciones como almacenarlos en una base de datos (SQL o NoSQL) aunque no era para ellos una opción por complicar la infraestructura más de lo necesario.

Si algo saco en claro de la experiencia tanto mía como de las conversaciones que tengo con cualquier persona que afronta una migración en git es que no es un proceso sencillo. Requiere planificación y una adecuada ejecución, y aunque lo que se gana es mucho, el proceso es doloroso y requiere compromiso de todo el equipo para poder llevarlo a cabo con éxito.

Como veis un día muy intenso y productivo. Veremos cómo se desarrolla el hack-day.

Más enlaces

• https://github.com/git-merge/user-day/blob/master/docs/01-index.md
• Resumen e impresiones sobre el Hack Day