Acabo de salvar mi vida con git… Parte 1/5

Domingo en la noche. Desde que estoy en Londres, trabajando con un par de desarrolladores geniales que me consumen la totalidad del tiempo (sí, también son buenos para beber), no he parado de darle al trabajo. Estamos documentando una plataforma complicada.

Trabajo como consultor en una empresa distribuidora de alimentos, en la que obviamente no tienen la menor idea sobre computadoras. La empresa se vendió a otra en que el dueño sabe mucho sobre sistemas no documentados (fracasó en un desarrollo, que tuve que salvarlo yo en 2006), y evaluó lo que existía en términos de… ¿infraestructura?

Toda la información de importación, exportación, compras, ventas y otros se ingresa a sistemas en RMCOBOL 85, que se comunican a través de Perl CGI con el exterior. La cosa funciona, pero los que conocen todo el sistema son unos señores de unos 40 años de edad, tan valiosos que si llegasen a tener una mejor oferta en el exterior echan por la borda todo.

Lo peor, uno de ellos ya tuvo un cáncer y estuvo varios meses en la clínica (la importancia de documentar es esa: si te mueres, tu desarrollo prevalecerá por los siglos de los siglos, por eso Dios contrató a varios webmasters para que escribieran el Antiguo Testamento y Jesús contrató a 12 apóstoles, de los cuales varios eran blogueros). Lo primero que hizo el dueño (The Big Boss) fue enviar a documentar, pero al estilo de él: paga un buen dinero pero no invierte en infraestructura hasta que está seguro de que lo que nosotros realizamos está bien. De todas formas, echar por la borda lo que hay en unos 45 servidores y poner tres o cuatro servidores más lo necesario para la redundancia no es tarea fácil para nadie, por mucho que el sistema nuevo esté desarrollado en Ruby on Rails y se use Python para las aplicaciones ayudantes.

Ahora bien, el concepto de «bien» es extraño. Una aplicación debe funcionar bien hasta en equipos de desecho. Y eso fue más o menos lo que me dieron: diez computadoras conectadas a un hub (sí, hub, capa 1), que habían comprado hace unos diez años. Las computadoras no son nada especial, lo único que realmente admiro son los teclados que tienen, porque hasta los displays tienen la pegatina de Energy Star decolorada de tanta radiación.

Ok, ante tal escenario, imaginarán que no tienen ni siquiera un sistema de control de documentos. Y yo odio los sistemas de control de documentos tipo Wiki por alguna razón específica que no viene al caso, y odio los sistemas de control de documentos tipo «Suba el documento, baje el documento, agregue descripción…» que son en Web, porque no siempre uno tiene acceso a Internet y mucho menos con esta clase de chiches que hay en la oficina, por ende, se me ocurrió usar HTML para documentar (sí, OpenOffice.org puede guardar archivos en HTML y quedan lo suficientemente bonitos como para ser legibles, exportables a PDF y todo eso).

¿Lo malo de HTML para este caso?

Nada.

¿Lo bueno?

Son archivos de texto plano que tienen un formato bastante bien definido, permiten enlaces, dibujos y todo eso. Si alguien quiere un documento, abro el HTML, lo exporto a OpenDocument y el resultado queda aceptable y legible (y si hay errores, pues, nada más basta decirles que es por mientras, y que la documentación final no tendrá ese interlineado poco elegante).

GIT es el sistema de control de versiones creado por Linus B. Torvalds para mantener el código fuente del kernel Linux distribuido en varios lugares. Tiene varias características muy particulares, como que marca los branches de manera lógica, una copia del git puede ser usada como repositorio local y permite varias configuraciones de red: si queremos usarlo centralizado, podemos; si queremos usarlo distribuido, también es posible. Además, incluye algunos ganchos (hooks) para añadir seguridad y otras hierbas. Si ya sabes usar git, tal vez te convenga usar gitosis para configurar tu propio repositorio.

Luego de esta introducción, seguimos en la siguiente parte.

Imágenes:

• Energy Star en Flickr por d_true