Necesitamos buenos técnicos

Para empezar, una frase:

Más hacer y menos hablar

es un ejemplo que define muy bien lo que está pasando ahora mismo. Nos hemos hartado de montar castillos sobre las nubes y cuando ya no podíamos llegar más algo nos la hemos pegado.

Estamos en un punto en el que una persona hace 1 año sin apenas saber sumar podía comprar una vivienda y sacarla un 30% sin despeinarse o que nos vendan la leche por que tiene calcio "de leche" -esta misma noche he visto un anuncio de pascual en TV, se habrán parado a verlo, alejandose unos metros de la pantalla, los creadores?-

Estoy hasta las narices de humo, quiero que cuando vaya al taller con mi coche venga un técnico y que sin pensar sepa lo que es ese ruido que apenas se escucha, y me da igual que el taller cumpla la norma de turno, quiero que cuando vaya al médico éste tenga los huevos pelados de tratar con pacientes, que sepa que me pasa o como mínimo que tenga recursos para saber qué hacer, quiero que cuando llame al banco a preguntar no me insten a hablar con "fulanito de tal" que es el que "lleva estas cosas".

Quiero que haya gente que sepa, gente preparada, que sepa hacer, que me solucione, que me aporte.

Pero claro, para hacer todo eso necesitamos muchos años de preparación -sí, de esas cosas que nunca valen para nada en la universidad-, mucha experiencia, dedicación, gusto por hacer las cosas bien... y una recompensa (social, económica, del tipo que sea), pero para que me voy yo a esforzar si puedo pasar de #ponga aquí su puesto vendehumista de moda# una temporada y eso de escornarse no está bien visto -menudo pringao que diría aquel-

Cada vez que veo a alguien haciendo bien su trabajo me resulta imposible no soltarle un "da gusto pagar cuando la gente hace las cosas bien"

Razones para NO usar un IDE

Un IDE, con permiso de la definición en la wikipedia, no deja de ser un editor de texto y una serie de utilidades que facilitan el trabajo de desarrollo, tales como configuración de los parámetros del compilador, debugger, ayuda en la sintáxis, documentación del lenguaje, etc.

Hace ya cosa de un par de años que no uso un IDE, bueno, uso vim como "IDE" y las razones son las siguientes:

- Me obliga normalmente a usar el editor que el IDE quiere. Con vim uso siempre, para editar lo que edite, las mismas combinaciones de teclas, misma configuración y en todas las máquinas en las que trabajo solo con llevarme el .vimrc

- Tiende a añadir complejidad. Los makefiles que se generan, los wizards de código, etc tienden a añadir mucho código que realmente no sabes como funciona y que es difícil de modificar.

- La ayuda con la sintáxis o el autocomplete. Aunque pueda parecer una maravilla me parece uno de los inventos más perversos. Usé eclipse durante más de un año y medio con java y un día intenté hacer un pequeño programa en el editor de texto y compilarlo con javac... fue imposible, no recordaba nada, cual eran los imports que debía hacer (eclipse lo hace como mágia), nombres de clases, excepciones que debía capturar...

- Trabajo en máquinas remotas. Muchas veces tienes que editar ficheros o incluso programar en una máquina que solo tienes acceso ssh. Usando vim es transparente el estar en tu máquina o en otra por ssh.

- Si no lo usas aprendes a manejar las cosas que pasan por debajo. Cuántos habrá que no sepan crear un .jar sin eclipse, como se especifica a gcc una librería o el path donde encontrar las cabeceras... sin contar aquellos que se sorprenden cuando puedes hacer todas esas cosas que hace el IDE pero sin el IDE. Si sabes como crear un .jar puedes estar tranquilo que con el IDE sabrás hacerlo igual de bien.


Sé que todo esto que digo suena a programador masoca, pero si de verdad quieres conocer lo que estás haciendo con detalle debes conocer lo que hay por debajo.

Bien es cierto que hay cosas muy útiles, por ejemplo la documentación siempre a mano, pero qué tiene eso que no tenga un man o un pydoc en la consola, una búsqueda en todo el proyecto, aunque no la cambio un ack-grep... lo único para lo que no he encontrado algo tan potente como eclipse es para las refactorizaciones... pero los buenos programadores nunca nos confundimos :P

Testing con datetime en python

Este es un pequeño "truco" para testear métodos o funciones que usen datetime.now. Se podrían usar trucos aprovechando que python es un lenguaje muy dinámico, pero siempre que se pueda hacer explícito y simple, para qué complicarnos?

def method(param1, param2, now=None): 
    now = now or datetime.now()
    # do something with now
    pass

En el uso normal la llamaremos normalmente, pero en el test podremos pasarle un datetime concreto para testear.

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"