Desencadenando el GitKraken

En el pasado he hablado de Git para gestionar las versiones del código, pero hoy voy a volver al tema para hablar del cliente que estoy usando de forma regular: GitKraken. La interfaz gráfica de la casa siempre dejó que desear y he paseado por unas cuantas, habiendo estado durante mucho tiempo con SmartGit, pero recientemente me dió por probar esta no solo porque había leído buenas referencias, sino porque también me hizo gracia el nombre.

Desencadenando el GitKraken

Las ventajas de usar un cliente gráfico son obvias (aunque obviamente la línea de comandos consume menos recursos y una vez se tiene el vicio es rapidísima):

  • es mas fácil de usar, pues no hay que memorizar comandos, además de que ver el resultado en una imagen es mas sencillo de procesar, pues “una imagen vale mas que 1000 palabras”.
  • la posibilidad de condensar procesos en un par de clicks, ahorrándose muchas líneas complicadas.
  • la posibilidad de tener cómodamente almacenadas las credenciales.

Cada uno tiene sus gustos, pero para mí este cliente supera a SourceTree (que es el referente clásico) por su claridad de visualización de las ramas, lo que lo pone a la cabeza de todos los que usado hasta ahora en este terreno… y además es multiplataforma, asi que funcionalmente hay poco mas que se pueda pedir… La única lástima es que aunque su base sea de código abierto, no comparte esa filosofía.

Anuncios

Git y las ventajas del control de versiones

Uno de los regalos menos conocidos por el público que nos hizo Linus Torvalds es su sistema de control de versiones “Git”, pues hacer código en equipo no es tan fácil como puede parecer. Cuando este señor abrió su proyecto de un núcleo de sistema operativo al mundo, de forma que cualquiera pudiese colaborar, se encontró con un problema: a la hora de juntar fragmentos de código que le enviaban, tenía que revisar a mano cada uno de los ficheros, para buscar las versiones (fetch) para añadir el nuevo código intentando evitar conflictos (por ejemplo que un programador llamó a una variable de una manera y otro de otra, y llegado un punto nos hacemos un lío entre los dos nombres) y guardar la nueva versión (commit), o volver atrás si la hemos liado (revert). Además y proyecto puede dar pie a distintas líneas de desarrollo, bifurcándose (fork) para poder llegar a unirse de nuevo en algún momento (merge). Y todo esto se hacía en los 90 a mano, pegando el código que se enviaba por email.

Git y las ventajas del control de versiones

El caso es que cuando se inventó este sistema, se automatizó la comparación de código, se indicaban los conflictos para resolverlos rápidamente de forma manual y se agilizó muchísimo el proceso, de forma que cuando se trabaja en equipo hoy en día, el control de versiones se ha convertido en una piedra angular. Claro que para que esto sea posible siempre hace falta un par de cosas: lugar en Internet para dejar el código y que todos los participantes en el proyecto puedan sincronizarlo, y un programa amigable de fachada de Git, porque seamos sinceros: el señor Torvalds hace un código de back-end maravilloso que se maneja de lujo desde la consola, pero eso no es precisamente muy amigable para todos (personalmente siempre me gustó usar como cubierta SmarGit, gratuito para uso personal y disponible para Windows, Mac y Linux, pero para gustos hay colores).

De ahí que desde hace años hayan proliferados los repositorios digitales donde almacenar los contenidos y su documentación en forma de wiki, tales como Github (el lugar de referencia para el software libre, donde ha migrado la mayoría del código del difunto Google Code), Bitbucket (de Atlassian, creadores de Jira, muy bueno para proyectos privados de equipos pequeños), Codeplex (de Microsoft, casi todo lo que hay allí es del ecosistema de Windows), Launchpad (de Canonical, casi todo lo que hay allí es de ecosistema de Ubuntu-Unity) o SourceForge (nada recomendable hoy en día).

En mi caso, como prefiero desarrollar sin estar ligada a ninguna plataforma concreta y con plena libertad a la hora de elegir el lenguaje de programación, utilizo Bitbucket y Github según me convengan mas: si mi pequeño proyecto debe ser privado, Bitbucket es el lugar apropiado, pues admite repositorios privados para equipos de hasta 5 personas de forma gratuita. En cambio, si prefiero crear algo que compartir con el mundo, Github es mucho mejor, pues además de la wiki da la posibilidad de crear una web de tu proyecto mucho mas atractiva, y hoy en día, nos guste o no, el diseño importa.

La decadencia de Sourceforge

Para los que nos gusta el software libre, SourceForge siempre ha sido una lugar de referencia. Una enorme cantidad de proyectos se almacenaban y mantenían allí, de forma que siempre contó con una buena comunidad de programadores. Sin embargo, algo ha cambiado en los últimos años. Es cierto que GiHub se ha convertido en el nuevo lugar de referencia de los grandes proyectos colaborativos, y BitBucket responde muy bien para proyectos pequeños, pero tener allí la comunidad siempre daba una ventaja competitiva… así que algo gordo tuvo que pasar, y ese algo es que SourceForge jugó con principios básicos del software libre.

La decadencia de Sourceforge

Cuando almacenas un proyecto en un repositorio, lo pones a disposición de la comunidad diversos formatos, y ofreces la posibilidad de bajar fragmentos individuales de código o documentación, compartir tus modificaciones, y puede que se incluyan versiones ya compiladas de la aplicación preparadas para la instalación por la propia plataforma, cosa que depende del lenguaje en el que se hayan codificado estas. Y justo ahí es donde esta gente metió la pata: si ya molestaban los iconos de descarga que no descargaban la aplicación sino otras cosas (proporcionados “generosamente” por Google Adsense en un intento de monetizar el sitio), repentinamente los instaladores de SourceForge comenzaron a aparecer modificados para incluirse la instalación de programas de tercera partes no solicitados (que puede ir desde el omnipresente Google Chrome a la insufrible barra de Ask en el navegador) por el usuario, sin consentimiento, o siquiera conocimiento, de los programadores que crearon el código de lo realmente buscabas instalar. Esto que acabo de describir no es algo que pasase con un proyecto pequeño, sino con GIMP (programa de manipulación de imagen de software libre, que para quien no esté muy puesto, es un Photoshop de andar por casa francamente icónico), Nmap (programa para auditar redes) y VLC (famosísimo y maravilloso reproductor vídeo).

Evidentemente esta situación les ha hecho perder la confianza de los programadores, por lo que ya muchos están preparando su salida. Los primeros son evidentemente los afectados por esta manipulación, pero otros muchos mas van detrás, como por ejemplo WINE. En consecuencia, quienes picamos código recomendamos evitar descargar de SourceForge en el futuro, porque a saber qué mas le habrán añadido en un intento de sacar tajada del trabajo ajeno.

Limpieza de primavera 2015 de Google: cierra Google Code

Como todas las primaveras, llega el temido momento de ver qué va a cerrar Google este año, y la nueva víctima es Google Code. ¿El motivo? El típico abandono del proyecto, y al popularidad ganada por GitHub y Bitbucket.

Limpieza de primavera 2015 de Google: cierra Google Code

Supongo que lo primero es explicar que es Git para quien no esté puesto en el tema. Git es un software de control de versiones, creado por Linus Torvalds (ese señor que es famoso por ser el creador del kernel o núcleo de software libre Linux, ¿ya os suena mas?). Cuando Linux comenzó a trabajar de forma colaborativa, recibía por correo los cambios de los demás desarrolladores, y debía integrarlos manualmente. Conforme la comunidad crecía, esto se fue volviendo insostenible, de forma que después de darle vueltas al tema, comenzó a crear un sistema que le ayudase con este cometido. Este sistema recibía los nuevos ficheros de código, detectaba los cambios, y los actualizaba, generando “nuevas versiones”. si algo iba mal, siempre se podía volver a versiones anteriores, o empezar a desarrollar nuevos proyectos basados en los anteriores (llamados branches o  ramas), que bien podían diversificarse o juntarse de nuevo en algún punto (merge o unirse). La cuestión fue dónde se almacenaba ese código, al que todo el mundo podía aportar.

Una de esas posibilidades era Google Code, que era bastante popular. Con todas las aplicaciones que tiene Google, parecía un buen lugar, con bastantes prestaciones, hasta que comenzó a dejarlo abandonado una vez mas. Si comparamos su situación con Github, su mas fiero competidor ahora mismo, la migración de sus usuarios es normal. Solo hay que mirar la facilidad de uso y la interfaz bien diseñadas y adaptativa a cualquier dispositivo de Github, sus aplicaciones para dispositivos móviles, o sus capacidades sociales frente al aspecto pre-moviles de Google Code.

A estas alturas empieza a preocuparme la posición de Google respecto a la gestión de contenidos: primero Google Reader, después Feedburner, ahora Google Code, Blogger en la cuerda floja desde hace años… por no hablar de la inexistencia de una aplicación nativa de Google Drive para Linux desde luego cada vez confío menos en ellos para gestionar mis contenidos.