Monthly Archives: June 2008

You are browsing the site archives by month.

Carolina Liar

Carolina Liar es un grupo recientemente formado de rock (según tags de last.fm indie rock) compuesto íntegramente por suecos.

La formación de la banda es el típico argumento de película Hollywoodiense donde su cantante y compositor, Chad Wolf, protagoniza la típica idílica historia de un cantautor que se muda a Los Angeles para intentar triunfar y finalmente consigue formar un grupo y éxito. Lo curioso es que esta historia no es una película y está pasando de verdad.

Una de las cosas que más me gusta es que las canciones son bastante diferentes entre si (obviamente no cambia radicalmente, pero no es el típico grupo donde todas suenan igual) y las letras enganchan (hasta me sé alguna y todo, yo que no me aprendo nunca ninguna).

Hace un mes, 20 mayo, se publicó su primer disco: Coming to Terms y han publicado su primer single I’m not over, si te gusta cualquier subgénero del Rock (¿a quien no? decir rock es casi como decir, “música”) tienes que darle una oportunidad a este grupo de suecos que se han ganado su prominente carrera a pulso y espero que consigan el lugar que les corresponde.

ps: ¡gracias Josepul por recomendármelo!

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.

¿Qué es la programación?

Ya sabemos cómo podríamos comparar el desarrollo del software. Pero, ¿cómo podríamos definir la programación? (Visto en coding horror).

Programming is all about knowing when to boil the orange sponge donkey across the phillipines with an orangutang gorilla crossed with a ham sandwich to the fourth power of twelve across the nile with an awful headache from the previous night when all of alfred’s naughty jalapeno peppers frog-marched the nordic elves across the loom-lined geronimo induced swamp donkey over and above the fortran fortified kilomanjaro fence past the meticulously crafted anti disgusting sponge cake scenario where all the hats doth quoteth the milk which is not unlike the super werewolf from the infinite realm of ninja-step. it’s hard to define, really.

Una traducción pésima podría ser algo así como:

En la programación todo consiste en saber cuándo hervir la esponja del mono naranja en las Filipinas con un gorila orangután cruzado con un bocata de jamón a la cuarta potencia de doce a lo largo del Nilo con un espantoso dolor de cabeza de la noche anterior cuando todas las traviesas guindillas de paco llevaron a la fuerza a los elfos nórdicos por el telar geronimo provocados por el burro del pantano por encima de la fortificada valla del Kilimanjaro pasada la lucha contra el meticulosamente preparado bizcocho asqueroso donde todos los sombreros citaban la leche la cual no se diferencia de los super hombres lobo del infinito dominio de los ninja. Es difícil de definir, en serio.

Breve y conciso.

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.