javisantana.com

Usar git en proyectos que usan subversion

Si has dado click en este enlace es que sabes que svn ya no mola, ahora lo que “lo peta” es git (o si eres un poco alternativo mercurial). Dejando a un lado lo de seguir las modas, seguramente conozcas más de un proyecto que trabaja con subversion y es difícil cambiar la tendencia, sobretodo por la barrera que supone pasar del modelo de funcionamiento de subversion a git.

Este post no pretende ser una guía de comandos a ejecutar para usar acceder a un repositorio subversion, para eso ya hay tropecientos manuales, voy tratar de explicar qué ventajas y problemas (alguna solución también) que he encontrado trabajando de esta forma y sobretodo pretende ser una pequeña guía para aquellos que están pensando usar git.

Ventajas:

- Puedes hacer los commits intermedios que quieras. Para los somos “amigos del commit” es muy útil, porque puedes hacer commit aunque el código no esté funcionando. En subversion para evitar esto tenías que hacer una rama y trabajar en ella hasta que terminases. En este caso tienes todo el repositorio en local y símplemente esos commits se acumulan a tu repositorio local hasta que tú decidas enviarlos al servidor.

- Trabajo en ramas: en Git trabajar con ramas es mucho más ágil que en subversion, de modo que puedes trabjar en ramas locales de trabajo para ciertas tareas, pruebas.

- Rapidez: creas ramas, cambias de rama, haces commit, compruebas el log o diff de un fichero. Aún recuerdo cuando tortoise se me quedaba pillado esperando el log de un fichero… aunque las dos anteriores son interesantes, en subversion tenían solución, esta no la tiene por el modelo cliente servidor.

- Puedes usar otras utilidades de git: stash, cherry-pick, rebases, etc.

Desventajas:

- No hay tortoise, particularmente uso gitx y/o gitg que permiten sobretodo visualizar cómodamente diffs y la historia del repo. Edito: Carlos me comenta que sí existe un tortoisegit, aunque no lo he probado.

- Los rebases del demonio. Cuando quieres actualizarte (lo que sería un svn update) debes hacer un git svn rebase. Esto, en pocas palabras, coge los commits que has hecho en local, los deshace, se baja las nuevas actualizaciones que haya en el servidor y aplica esos commits de nuevo. Personalmente odio el rebase (me recuerda a los peores momentos de regreso al futuro), así que una forma de trabajar sería crear una rama, actualizar la rama que apunte al servidor subversion (a trunk posiblemente) y después mezclar (en git, claro) la rama de trabajo.

- No puedes actualizar si tienes algo modificado en local. Con el subversion tradicional te hacía merge de lo que venía del repo con los cambios en local. Tienes dos opciones, o hacer commit o usar stash (almacena de forma temporal esos cambios, una especie de rama rápida)

- Tienes que aprender git además de subversion. A git cuesta acostumbrarse, pero luego es más versatil y rápido, es una cuestión de inversión.

Siempre puedes empezar a probar, como siempre digo a mis pobres pupilos: “con un repositorio puedes cagarla todo lo que quieras, siempre puedes volver para atrás”

Una historia de ventanas rotas

Sí, otra historia, y esta es de las que no tiene final feliz.

Las ventanas rotas en programación se pueden explicar con una variación del sabio refrán español:

No dejes para mañana lo que puedes hacer pasado mañana

Estás tirando unas líneas de código, ves que hay un problema, lo das unas vueltas, te pones a otra cosa y cuando te das cuenta el problema no está. Lo siguiente es un:

De puta madre -piensas- marrón que me quito de encima, soy un hacha, resuelvo sin querer

Total, que sabes que has dejado un error y además estás programado por coincidencia.

Pero los programadores somos muy orgullosos, así que buscamos una solución rápida:

- seguro que era una gilipollez
- la informática es así, a veces a los ordenadores les da por hacer “cosas raras”
- habrá sido “el driver”
- seguro que ha sido un pete de la base de datos
- le ha pasado a Jose el comercial, no tiene ni puta idea y lo habrá jodido
- eso ha sido porque estoy en debug
- eso ha sido porque estoy en release

Total, pasa el tiempo y un día estás programando algo que nada tiene que ver y el pete vuelve. Tú sabes que aquello volvería y en el peor momento aparece para joderte.

Bien, como los accidentes de tráfico nunca piensas que algo así te va a pasar a ti, pero siempre llega el día. Hace dos días encontré una ventana rota en agroguía (nuestro sistema de guiado GPS para la agricultura) de hace 4 años y medio.

Un error al teclear ha generado cáncer que se ha expandido por toda la aplicación. En el momento de convertir las coordenadas del GPS a cartesianas cometí el error de poner la coordenada Y donde debería estar la X y viceversa. Seguramente fue de lo primero que programé y está al principio de toda la cadena de la aplicación, ya que las posiciones del GPS son la fuente de datos.

En principio es un flip de los ejes, no debería causar problema pero eso ha causado que, sin saber porque, cambié el render del eje X (por tanto todo el render está “flipeado” en el eje X), toda la exportación está cambiada de lado, tuve que hacer ñapas para que el render cuadrase con la realidad… etc.

Ahora he estado integrando un formato de fichero GIS para darle una vuelta más de tuerca al guiado GPS de bajo coste y he tenido que arrastrar todo el fallo para que la cosa funcionase.

Casos como este y otros puedes encontrar en el libro The Pragmatic Programmer, indispensable para cualquier programador.

Una historia de subvenciones

Hoy toca hablar de subvenciones y voy a hablar muy muy mal de ellas a pesar de que mi salario de estos últimos años atrás ha dependido casi en exclusiva de subvenciones.

Pongamos una empresa española, gente trabajadora, alto nivel técnico, buen planteamiento… y ahora pongamos que existen una cosa que se llama subvenciones que hace que a los que comandan esa empresa vean un buen punto de ayuda:

“Es una de esas ayudas de i-mas-de, nos puede ayudar en el proyecto tal y contratar a cual”.

A priori está muy bien, se pone a trabajar una persona en presentar la documentación, trabajar en ella, etc (lógicamente esa persona también cobra por su trabajo, faltaría más). Se consigue a subvención y se contratra a 3 personas más y, dado que se tiene mas gente, el proyecto se hace más ambicioso. El director comercial se coge de renting un Audi TT ya que es necesario ir bien representado:

“somos una empresa seria”, afirma el director tajantemente a uno de sus empleados, esos que están todo el día en el ordenador.

Se va acercando el final del dinero, y como siempre pasa, al proyecto está casi listo (el 80%, por poner una cifra).

“No pasa nada, se puede buscar otro proyecto de i+d”

Y vuelta a empezar, pero aún peor, porque ahora tenemos que pagar 3 sueldos más, los coches de los comerciales y alguna que otra cosa más que se contrató en la bonanza. Por no hablar de lo minada que está la moral por no ver que el trabajo fructifica y que todo lo que haces es trabajo tirado a la basura.

Y este es el pan de cada día de muchas PYMES tecnológicas en España.

Cada vez que hablo con alguien que ha montado o está montando su empresa, que es productivo, no pasa sin que comente el daño que hacen, y no solo del lado que yo he comentado.

No estoy a favor de que desaparezcan, pero sí de que se apliquen razonablemente y siempre tratando de apoyar una mejora, no como una vía de mantener una empresa.

En voota hay una propuesta muy interesante sobre este tema.

desafío abredatos: cortesabiertas.org

Sí, participé junto a Félix López, Edu Lanchares y Antonio Garrote tratando de hacer una aplicación para mostrar el pueblo castellano leonés de que se habla en esas flamantes cortes.

Lo que pudimos hacer en 48h para el concurso abredatos: http://cortesabiertas.org/

y la explicación técnica detallada en en blog del sr garrote.

Osadía

No hay vez que no vea un documental de construcciones u obras de ingeniería que no sienta una profunda envidia. Y siento envidia porque me doy cuenta que comparado con las empresas de software, ellos tienen claras muchas cosas que nosotros no tenemos.

Entre estas cosas hay una cosa que casi me hace llorar, y es que se tiene en cuenta al experto, si tienen que poner una plancha de un puente hay un -señor- ingeniero que es el que tiene los huevos pelados de pasarlas putas poniendo puentes, hay especialistas por cada una de las partes; especialista de hormigón, de neumática… y no se mueve ni un santo dedo si no hay un “ok” de esos expertos.

Otra de las cosas que me gusta es que saben hasta donde pueden llegar con más o menos deriva en el tiempo. Nadie pondría a 3 ingenieros a hacer un viaducto de 200m de altura y 500metros de largo y mucho menos les diría, esto tiene que salir sí o sí.

Sin embargo en el mundo del software, estoy ya acostumbrado a que se planteen objetivos sin sentido, metas a la vuelta de la esquina para algo que queremos denominar producto, planificaciones que no se ajustan en cuanto a personal…

Si algo he aprendido con el desarrollo de agroguía, es que el producto empieza a ser tal cuando tiene cierta madurez, se ha trabajado duro en los detalles. Esos que no se ven cuando se hacen planificaciones a boleo. Y esos detalles no son que la aplicación funcione -eso se da por hecho, que no es poco-, si no que sea simple de usar, que resuelva bien las situaciones inesperadas, que hable el mismo idioma que el usuario (no, no me refiero literalmente) y esos miles de cosas que hacen de una aplicación un producto.

Creo que uno de los grandes problemas del software es que no hay soporte material sobre el que basarse. Sabemos que llevar una piedra de 4toneladas de un sitio a otro no lo podemos hacer si no es con una grúa o un camión, es obvio, es algo palpable, sin embargo algo que no se puede tocar es difícil de cuantificar.