Category Archives: Software

Backup incremental de tu base de datos con Git

Una forma realmente interesante de realizar backups de tus bases de datos (por ser trivial y muy potente) es usando Git. El proceso es simple y se basa en la realización de los dumps de la base de datos de forma que cada fila de las tablas sea un insert aislado, de esa forma en cada commit solo estaremos salvando las diferencias respecto al último estado (tanto deletes como inserts, como updates).

En el caso concreto de MySQL inicialmente haríamos algo como esto:

$ mkdir mydatabase && cd mydatabase
$ mysqldump --skip-extended-insert > data.sql
$ git init
$ git add data.sql
$ git commit -m "Initial dump of mydatabase"

A partir de entonces podemos automatizar el proceso con un script tan simple como este:

$ cat /usr/bin/git_backup_database
#!/bin/sh
BACKUP_DIRECTORY=$1
DATABASE=$2
 
cd $BACKUP_DIRECTORY && \
mysqldump --skip-extended-insert $DATABASE > data.sql && \
git commit -am "Updating dump `date +%Y_%m_%d__%H_%M`"

Según el volumen de consultas que tenga tu base de datos, te será interesante ponerlo en cron con una frecuencia determina u otra. Adicionalmente sería recomendable ejecutar $ git gc para optimizar el repositorio. Por ejemplo, dos veces al día y una vez a la semana mantenimiento:

0 0 * * * /usr/bin/git_backup_database /path/to/mydatabase mydatabase
0 12 * * * /usr/bin/git_backup_database  /path/to/mydatabase mydatabase
0 1 * * 1 cd /path/to/mydatabase && git gc

Además desde otro equipo nadie te impide hacer un $ git clone ssh://equipo:path/to/mydatabase y tener todo el historial de la base de datos en un plis (bueno eso es relativo, que ocupará lo suyo…) o incluso programar un $ git pull para tener varios backups en distintas maquinas. En definitiva, se abren un sinfín de opciones :).

Añadir soporte de links spotify en firefox

Quien dice spotify, podría decir ed2k o el protocolo que vuesa merced guste. El proceso siempre es el mismo:

  1. Abrir about:config en firefox
  2. Añadir par de booleanos (valores lógicos):
    • network.protocol-handler.external.spotify a true
    • network.protocol-handler.warn-external.spotify a false
  3. Añadir una cadena network.protocol-handler.app.spotify con valor /usr/bin/spotify
  4. Crear un ejecutable (en este caso en /usr/bin/spotify y teniendo en cuenta dónde lo instalamos anteriormente)
    #!/bin/sh
    exec wine "C:\Program Files\Spotify\spotify.exe" /uri "$@"

Diferencias entre rebase y merge en git

A la hora de integrar los cambios realizados en una rama de desarrollo, se puede optar por diferentes formas. Una de ellas, la más tradicional, sería aplicando un parche que previamente hemos recibido por algún medio. Otras formas más lógicas si son cambios propios sería mergear o hacer un rebase de dicha rama hacia la principal. En svn (y cvs) no existe el concepto de rebase, por lo que al moverse a sistemas como git al principio puede ser algo confuso.

No hay mejor forma de visualizarlo que con unas imágenes de los resultados que podríamos obtener. Partimos de esta situación inicial (imágenes sacadas usando gitk):
Rebase vs merge, situación inicial
Y ahora vayamos a las posibles acciones que podríamos realizar para incorporar los cambios de la rama perrea a master:

  • git merge perrea
    Rebase vs merge, realizado merge
  • git rebase perrea
    Rebase vs merge, realizado rebase
  • git merge --squash perrea (&& git commit)
    Rebase vs merge, realizado merge squash

En un merge squash lo que hacemos sería el equivalente a aplicar un parche. Es decir, simplemente se aplican los cambios de dicha rama pero no se asocia con ésta (ni se realiza un commit automáticamente). Esto puede venir bien cuando tengamos muchos commits “sucios” (quien dice sucios, dice poco elegantes, chapuceros, embarazosos, etc…) o que queramos ocultar. Posiblemente útil al integrar cambios a una rama pública en un grupo de trabajo grande.

Entonces, ¿qué es mejor usar?. Que yo sepa, no hay una respuesta absoluta (como en casi todo). Posiblemente sea cuestión de gustos personales. De cara al historial, un rebase hace que luego sea más fácil seguir la evolución, pues un grafo sin ramificaciones es obviamente mucho más simple que uno que las tiene y si podemos simplificar las cosas, ¿para qué complicarnos la vida?.

Subversion: the most pointless project ever

At least, that’s what he said…

When I say I hate CVS with a passion, I have to also say that if there any SVN users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was “CVS done right” or something like that. And if you start with that kind of slogan, there is nowhere you can go. It’s like, there is no way to do CVS right.

Linus Torvalds

From his Git talk in Google last year, a really good one.

Git, ¿merece la pena?

Un sistema de control de versiones es una de las principales herramientas para cualquier programador, independientemente de si se esté trabajando en solitario o con un equipo de cientos de personas.

Desde hace un par de semanas estoy usando Git, un sistema de control de versiones distribuido desarrollado por Linus Tolvards (usado actualmente en el desarrollo del kernel). Git, está teniendo últimamente mucho hype. Pero las modas son muy peligrosas y siendo una herramienta tan fundamental, hay que evaluar a conciencia si realmente merece la pena usarla.

Comentando mi experiencia personal, tengo que decir que nunca me han gustado los SCMs. Comencé a usar subversion después de aprender a base de palos algunas de las causas de no usarlo. Aunque hasta hace poco no lo usaba plenamente, o todo lo bien que debería como para que empezase a ser una herramienta y no una carga. Pero a pesar de ello, todavía tenía auténtico pánico cada vez que se me pasaba por la mente las palabras branch o merge. Auténtico pánico.

Por suerte todo aquello es cosa del pasado (de hace 2 semanas :P). Lo que me animó a probar Git fue este estupendo post, merging by example, donde se muestra un ejemplo de uso en el que se van realizando diversos branches y merges de una forma lógica en un escenario típico del MundoReal™. Intenta hacer eso mismo con subversion (o si eres del pasado, con tu cvs) y me comentas (no pasarás del tercer merge sin conflictos).

Basta de contar mi vida y decir pamplinas, ¿qué ventajas aporta Git respecto a subversion? (digo subversion porque es el comúnmente usado, lo mismo se podría decir respecto a cvs pero con todavía más puntos).

  • Está de moda, y si lo usas molarás más, ¿no?. No hay mejor conversación para atraer a humanos del género opuesto que comenzar con un típico “¿sabes que uso git con una mano?”
  • Es distribuido. Esto tiene dos implicaciones muy importantes:
    • Independencia. Tú eres un repositorio, no necesitas ninguna información de ningún otro lado para realizar las operaciones. Es decir, no necesitas para nada red.
    • Mejor integración y comunicación en grupos de desarrollo grandes, pues cada desarrollador puede compartir cambios con el resto sin depender de un servidor central.
  • Rapidez, derivada principalmente por el anterior punto (y porque los que lo han implementado no deben de ser malos programadores, a decir verdad, según Linus la eficiencia fue uno de sus requisitos principales). Si para realizar una operación vas a necesitar acceder a la red (svn), quieras o no quieras vas a ser siempre mucho más ineficiente que alguien que no lo necesita (git)
  • Manejo más simple, intuitivo y eficiente de branches.
    • Con git puedes mergear varias ramas a la vez en una tercera (llamado merge octopus).

    • Mergear eficientemente ramas cuyo punto en común es un antiguo padre.
    • Y lo más importante (para mi :P), el scm conoce qué es un branch. Se acabo eso de tener diferentes directorios, uno por branch.
  • Git sigue y almacena contenido, no ficheros como lo hace svn. Esto tiene importantes repercusiones, una es (que podría considerarse negativa, para mi al menos lo es) que no soporta almacenar directorio vacíos (¡pues no tienen contenido! no hay nada que salvar) y otra es una detección transparente de movimiento de ficheros (renombrado, copias, movimientos, etc…).
  • Nuevo concepto, el index. El índice es un punto intermedio entre nuestros ficheros reales en el directorio de trabajo y el repositorio. Permite ser usado como un punto intermedio en el que almacenar (y preparar) nuestro cambios. En él podemos guardar nuestras modificaciones de forma temporal y recuperarlas posteriormente (por ejemplo después de cambiar de rama y arreglar lo que sea). O también podemos crear un commit personalizado creando un parche llegando a la granularidad de líneas de ficheros.

En resumen, es un cambio realmente significativo respecto al modelo tradicional (aunque podrías usar git con el mismo “workflow” que sigues en svn). De primeras es muy fácil de usar (algo que siendo un patan con estas herramientas, como lo es un servidor, se agradece), pero a su vez te permite profundizar y conseguir nuevos modelos de trabajo más productivos gracias a sus enormes posibilidades (el index es realmente útil). Es decir, tiene una curva de aprendizaje razonable pero que llega muchísimo más alto que la de svn (en cuanto a posibilidades), algún día llegaré a dominarlo pero mientras tanto me hace la vida más fácil.

Además puede ser usado teniendo repositorios de otro tipo como maestros (svn, por ejemplo gracias a git-svn), por lo que puedes seguir usando svn y localmente usar git sin “problemas” (tú trabajas con git, y git-svn se ocupa de manejar el subversion remoto, así estoy trabajando actualmente).

Por último mencionar algunas alternativas muy similares a git (es decir, que son distribuidos), los cuales desconozco completamente, pero que estoy casi seguro que son una mejor apuesta respecto al modelo svn/cvs. Los dos primeros escritos en python y el último en Haskell (¡con un par!):

Todo se podría resumir en una moraleja: Git, el sistema de control de versiones que no produce un incremento de deseo de participar en un suicidio colectivo.

Subversion en aplicaciones Java desde Ubuntu

Cualquiera que haya usado Java, tanto usuarios como desarrolladores, habrán tenido múltiples problemas debido al tipico problema del classpath y derivados. Es posiblemente uno de los (múltiples) principales problemas de Java. Y no será por soluciones adoptadas en otras ámbitos ampliamente usadas y aceptadas como válidas. Pero bueno, ese es otro debate.

Para poder interactuar con subversion desde aplicaciones Java necesitas la librería cliente JavaHL, ésta puede ser instalada fácilmente usando los paquetes de tu distro, en Ubuntu:

$ sudo aptitude install libsvn-java

Pero a pesar de esto, tus aplicaciones Java seguirán sin “encontrarla“, necesitas indicar en tu comando de ejecución de cientos de caracteres de tu aplicación el siguiente parámetro:

-Djava.library.path=/usr/lib/jni

Obviamente /usr/lib/jni es donde está la librería (el .so), quizá en otras distros no-ubuntu sea diferente.

En mi caso particular lo necesitaba para subclipse en Aptana, en cuyo caso hay que añadir esa opción al AptanaStudio.ini donde están los parámetros usados al arrancar Aptana.