Rubyconf 2012

Update: ya estan disponibles todos los videos de la conferencia aca

Este fin de semana fui a la rubyconf que se organizo en la Argentina, pais donde vivo en el cual fue la segunda vez consecutiva que se organiza un evento de tal magnitud con Ruby como tema central.
En la foto principal de articulo pueden ver el pin rojo de la RubyConf 2011 y el nuevo pin amarillo de RubyConf 2012.

Como lo plantearon los organizadores del evento en un principio, esperaba la aparición de figuras relacionadas con el desarrollo del lenguaje provenientes de Japon al igual que el año pasado vinieron a presentar Yutaka Hara, Koichiro Eto y Narihiro Nakamura (pueden ver sus charlas y otras mas aca), por lo visto este año no fue posible pero mas alla de eso considero que el nivel de las charlas y la organiacion mejoraron en comparación al año pasado y no faltaron las grandes personalidades del mundo ruby local, paises vecinos y varios paises lejanos del "otro lado del charco", con visitar la pagina se puede saber quienes son

Todas las charlas estuvieron buenisimas, doy mis comentarios de las charlas que mas me gustaron
Update: tambien incluyo los videos de las mismas

Ship it: Staying Lean at LivingSocial


Andy Atkinson de livingsocial nos explica como aplican Lean a la hora de evaluar la incorporación de nuevas features. Una de las cosas mas interesantes que conto es que en lugar de desarrollar la feature completa y largarla, hacen "pedacitos de feature" o incluso solo un "preview" para que todos o un grupo seleccionado de usuarios envien feedback, si el feedback es bueno siguen adelante y van avanzando en el desarrollo de esa funcionalidad en caso contrario la dejan de lado.
Conto como ejemplo el caso de una funcionalidad hypercompleja de implementar (ahora no me acuerdo que era) que a los usuarios no les importaba y una cosa tan sencilla de implementar como un "boton de express checkout" tuvo mucho exito y les genero un monton de ganancia.

The web of tomorrow

Excelente charla de @cuerbot, con una buena presentación y graficas vintage acordes transmite un mensaje de Javascript, P2P y libertarismo digital. Basicamente explico con ejemplos puntuales como las aplicaciones en javascript usan WebRTC pueden comunicar directamente browser con browser sin servidor de por medio a excepcion de una intervencion minima al principio de la conexion similar a como lo hacen hoy VoIP y las redes P2P de intercambio de archivos. Las claras consecuencias de esto segun mi forma de ver:

• Streaming de audio y/o video entre browsers sin servers como intermediarios
• Drastica baja de requisitos de performance en el lado del server al trasladar casi la totalidad de la carga de la aplicacion a los browsers
• Descentralizacion de las comunicaciones mitigando la censura en la web
• Solo la imaginacion es el limite....

Otra cosa interesante de esta charla es que fue la única en mostrar puro codigo javascript, constituye un puesto de avanzada de invasion de javascript en el espacio de ruby, pero le doy la bienvenida

Aca los slides: https://speakerdeck.com/u/elcuervo/p/the-web-of-tomorrow

Rails 4 en 30 minutos

Introducción a Rails 4 que se liberara en pocas semanas la versión estable, fueron asombrosas las cosas que mostro como por ejemplo las queues (antes habia que recurrir a una gema adicional para eso) y ActionController::Live


Comida

Merienda con brownies de chocolate explosivo, medialunas, budines, sangunches, almuerzo con sanguches, metasushi, comida vegetariana y desayuno también.
La comida es una de las cosas en la que los organizadores se superaron












REST in peace

No se preocupen, todavia REST no murio (de hecho falta muucho para eso). Martin Salias ataca de nuevo y esta vez nos explica como hay que desarrollar interfaces REST como es debido.
Principales lecciones que me quedaron:

• Usar verbos y status codes que corresponden (ej: no usar un verbo GET para borrar algo)
• No devolver identificadores de obetos relacionados en el json/xml, porque el cliente tiene que construir las URLs (y estas podrian cambiar con el versionado, etc...)
• Sinatra parece ser mejor que rails para hacer algo simple como esto :D

Rapid Prototyping with Sass, Compass and Nanoc

No me acuerdo muchos detalles ahora, pero básicamente explicaron el toolkit de herramientas que usan para prototipar interfaces usando lo que ya se sabe de lenguajes markup de ruby, una de las que mas me intereso fue middleman,  un server de paginas estáticas muy util para prototipar cosas sin necesidad de tener que lidiar con alguna complejidad innecesaria de un framework web

Infrastructure as Ruby code

Explica como Ruby es extremadamente util  (mucho mas de lo que yo me imaginaba) al servicio de un Sysadmin, herramientas como vagrant y chef para administrar/deployar múltiples servidores, ya no en la forma "tradicional" de tener una maquina física que dure mucho tiempo, sino de una manera adaptada a la era del cloud computing en la cual los servidores son "efímeros" y el scripteo, la automatización  la escalabilidad horizontal y la posibilidad de repetir fácilmente las configuraciones se vuelve una herramienta crucial para aprovechar bien los recursos que hay ahora.

Slides: https://speakerdeck.com/u/abecciu/p/infrastructure-as-ruby-code

Fin de semana de lisp

El fin de semana pasado fui a la jsconf, y a partir de una charla de ajlopez (Implementando lenguajes de programacion en javascript) y una incidencia de lenguajes formales (una materia que estoy cursando ahora en la facultad) me plantee el objetivo de hacer el interprete de lisp en ruby

Lo que no estaba tan al tanto, es que como lisp es una influencia importante en muchos lenguajes actualmente vigentes (principalmente lenguajes dinamicos) como javascript, python y por supueso ruby, tiene caracteristicas que permiten hacer una "conversion" mas o menos legitima

Y es que, como explico ajlopez en su presentacion, muchos interpretes de X lenguaje hechos en otro lenguaje Y podrian utilizar la generacion de codigo, que es la tecnica que me llego a parecer mejor cuando estaba escribiendo las primeras lineas de dslisprb, 

Entonces...

Atomos numericos de lisp son Fixnum, Float, Bignum, o sea objetos numericos de ruby

Las listas de lisp son obviamente Arrays de ruby 

Los lambdas de lisp son lambdas de ruby, y por lo tanto...
Las variables de lisp son variables de ruby

Las funciones de lisp, no son mas que variables con un lambda asignado, por lo tanto son lambdas de ruby (ejemplo: la funcion car que se define como un lambda)

Para ejecutar el codigo lisp, este se parsea a un ast, el ast se convierte a ruby, y finalmente se evalua. Las variables lisp se representan en variables de ruby y todo se ejecuta en el mismo binding para cada instancia de DsLisp (de esta manera, si se asigna una variable en una llamada a evaluate esta sera accesible en las sucesivas llamadas)

Instalar y usar

gem install dslisprb


Para usarlo seguir las instrucciones en el README, igualmente lo hice lo mas intuitivo que me salio para Ruby 1.9, aunque no podria descartar que funcione tambien en el viejo ruby

Al final lo unico raro de este proyecto es que no implica absolutamente nada de javascript, ese lenguaje me resulta muy interesante, pero para otras cosas (webgl, jueguitos, UI, :D )

Menos precision por favor

Estoy cursando numerico en fiuba y se dio la necesidad de probar varios algoritmos en distintos grados de precision (el ejemplo mas claro de esto, es el tipo de datos double y float de C)

, como todo rubyfan decidi hacerlo en ruby, pero ruby solo tiene un tipo de dato de punto flotante, llamado Float, que wrappea el double nativo de C

El truco, como en otros lenguajes con solo una precision de punto flotante, es emularlo; es decir, truncarlo a la precision deseada despues de cada operacion. Ruby tiene soluciones interesantes para hacer este tipo de cosas.

El decorator

En un principio, usamos un patron llamado decorator, con la idea de modificar el comportamiento del float:

Nuestro FloatDecorator repite cada operacion en el objeto "decorado", pero al retornar el resultado lo trunca y lo decora tambien asi mantiene el comportamiento

Asi, la raiz cuadrada de dos 2**0.5 da 1.41 y no 1.4142135623730951

La manera mas rubyway de implementar un decorator es usando method_missing En este caso se implementaria asi:

class FloatPrecisionDecorator
  def initialize(inner, factor)
    @factor = factor
    @inner = inner.to_f
  end

  def method_missing(m,*x)
    # todas las operaciones sobre el numero se ejecutan sobre el float verdadero
    # y se obtiene el verdadero resultado con precision completa del Float original
    verdadero_resultado = @inner.send(m,*x)
    # se reduce la precision, multiplicando por el factor, redondeando y volviendo a dividir
    reduced = (verdadero_resultado.to_f * @factor).round.to_f / @factor
    FloatPrecisionDecorator.new(reduced, @factor)
  end
end

# esto da un FloatPrecisionDecorator con un 1.41, adentro, no un 1.4142135623730951
p FloatPrecisionDecorator.new(2,100)**0.5

Inspect

Pero cuando se hace el print por salida estandar, aparece algo asi:

#..floatprecisiondecorator:0x8cd63f8 factor="10," inner="1.4"...

¿ No seria mejor que simplemente mostrara el 1.41 ? Para eso hay que sobrecargar el metodo inspect

class FloatPrecisionDecorator
  def inspect
    # para que llame al inspect del float decorado
    @inner.inspect
  end
end

# ahora si va a mostra simplemente 1.41
p FloatPrecisionDecorator.new(2,100)**0.5

Numeric

Es mejor si se puede hacer asi:

4.0.to_reduced_precision(:decimals => 2)

4.0.to_rp(:decimals => 2)

Para eso lo mejor es agregarle el metodo a la clase numeric:

class Numeric
  def self.reduce_precision(number, factor)
    (number.to_f * factor).round.to_f / factor
  end

  def to_single_precision(options)
    unless options[:factor]
      options[:factor] = (options[:base]||10) ** (options[:decimals]||10)
    end

    factor = options[:factor]

    FloatPrecisionDecorator.new(Numeric.reduce_precision(to_f, factor), factor)
  end
end

Coerce

Puede surgir que se tenga que sumar un numero de precision reducida a un float, pero el metodo + de la clase Float de ruby no tiene forma de saber como sumar el numero que implementamos nosotros. Esos casos ruby lo contempla con el metodo coerce, que habilita conmutar los numeros en una operacion matematica, asi:

class FloatPrecisionDecorator
  def coerce(other)
    return self, other
  end
end

inifinite?, nan? y demas

Si se hace a nuestro numero

p 2.to_sp(:decimals => 10).infinite?

Va a devolver 0.0, cuando se supone que el metodo inifnite debe devolver true o false, esto ocurre porque inifnite? tambien llama a method_missing y este trata de truncar y wrappear lo que sea, lo mejor en estos casos es evitar modificar objetos que no sean numeros. Habra que modificar method_missing:

class FloatPrecisionDecorator
  def method_missing(m,*x)
    # todas las operaciones sobre el numero se ejecutan sobre el float verdadero
    # y se obtiene el verdadero resultado con precision completa del Float original
    verdadero_resultado = @inner.send(m,*x)

    # si es numeric, truncar y wrappear
    if Numeric === verdadero_resultado
      # se reduce la precision, multiplicando por el factor, redondeando y volviendo a dividir
      reduced = (verdadero_resultado.to_f * @factor).round.to_f / @factor
      FloatPrecisionDecorator.new(reduced, @factor)
    else
      # si no, devolve el resultado como es
      verdadero_resultado
    end
  end
end

Codigo completo

class Numeric
  def self.reduce_precision(number, factor)
    (number.to_f * factor).round.to_f / factor
  end

  def to_single_precision(options)
    unless options[:factor]
      options[:factor] = (options[:base]||10) ** (options[:decimals]||10)
    end

    factor = options[:factor]

    FloatPrecisionDecorator.new(Numeric.reduce_precision(to_f, factor), factor)
  end
end

class FloatPrecisionDecorator
  def initialize(inner, factor)
    @factor = factor
    @inner = inner.to_f
  end

  def method_missing(m,*x)
    # todas las operaciones sobre el numero se ejecutan sobre el float verdadero
    # y se obtiene el verdadero resultado con precision completa del Float original
    verdadero_resultado = @inner.send(m,*x)

    # si es numeric, truncar y wrappear
    if Numeric === verdadero_resultado
      # se reduce la precision, multiplicando por el factor, redondeando y volviendo a dividir
      reduced = (verdadero_resultado.to_f * @factor).round.to_f / @factor
      FloatPrecisionDecorator.new(reduced, @factor)
    else
      # si no, devolve el resultado como es
      verdadero_resultado
    end
  end

  def coerce(other)
    return self, other
  end

  def inspect
    # para que llame al inspect del float decorado
    @inner.inspect
  end
end

p FloatPrecisionDecorator.new(2,10).infinite?

TIrate que? tirate un AJAX

Por algo se empieza...

$.ajax({ url: '/meme', statusCode: {404: function(){alert('not found');} } }).done(function(){alert('hello');});

No mas excusas para no testear con picotest

Picotest es una gem pensada principalmente para testear pequeños metodos, como helpers, funciones de calculo, etc...

Apenas se libero una primera version 0.0.1 de prueba para mostrar la idea, la cual consiste en evitar el "no vale la pena testear esto" cuando estamos frente a metodos o funciones que tienen un monton de casos pero testearlos supondria escribir mucha mas cantidad de lineas de codigo de lo que implicaria la propia funcionalidad que se testea

La solucion a esto en picotest es ofrecer un DSL que permita escribir una gran cantidad de casos de prueba en una o por lo menos muy pocas lineas. Por ejemplo:

require "picotest"

suite(1 => 1, 4 => 2, 9 => 3, 16 => 4).test(Math.method(:sqrt))

Tambien tiene sintaxis especifica para hacer oracle testing y mocking muy sencillo (seguir los enlaces para mas informacion)

Enlaces

• Post un poco mas detallado, con ejemplos: http://tario-project.blogspot.com/2012/01/no-more-excuses-for-not-testing.html
• Sitio en github: https://github.com/tario/picotest/

The Ruby Game

http://therubygame.com/

Es un site que tira acertijos o problemas ruby en los que todos pueden participar enviando el codigo y ves los resultados al instante, lo copado es que podes ver un ranking de las soluciones que todos enviaron y aprender cosas interesantes de la sintaxis de ruby

Let's the game begins!

Git para usuarios de Subversion

O mejor dicho:

Git NO es para usuarios de Subversion

Ir de svn a git, no puede ser:

• Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
• Siendo usuario SVN, Usar git traduciendo los comandos que ejecutarias si usaras svn (epic fail),
• Encontraran esa experiencia fea mientras sacan en conclusión que git posee una complejidad innecesaria y es muy difícil de usarlo

"Para un usuario de svn siempre sera mas facil usar svn que git"

Par ir de svn a git, es mejor seguir estos pasos:

• Siendo usuario SVN, leer guia "Como volverse un usuario de git"
• Siendo usuario git, Usar git de manera natural

Asi git se usaria mejor, pero quedan dos problemas:

• "Para un usuario de git siempre sera mas facil usar git que svn" , es decir, que una vez acostumbrado a git usar svn se vuelve complicado.
• Y mas importante, cambiar de el svn mindset al git mindset no es para nada algo trivial

Si se sigue insistiendo con git, como una mera variante de svn, esto es lo q podria pasar (lo mas comun):

• Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
• Pasar meses de agonia mientras se maldice a git, a Linus Torvalds y al manager/PL/co-equiper/profesor que te hizo usarlo ya que es muy complicado al pedo ("¡lo unico que quiero hacer es commitear!", "¡mis cambios desaparecieron!", "¡el merge fallo y perdi todo!", y asi...)
• Librarse de git de alguna manera y volver al placido y reconfortante svn (o cvs :( )

O si no, esto es mas raro que pase:

• Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
• Pasar meses de agonia mientras se maldice a git, a Linus Torvalds y al manager/PL/co-equiper/profesor que te hizo usarlo ya que es muy complicado al pedo ("¡lo unico que quiero hacer es commitear!", "¡mis cambios desaparecieron!", "¡el merge fallo y perdi todo!", y asi...)
• Aprender como funciona y hacer "cosas que con svn no hacia", explotar sus ventajas
• Volverse "usuario git" al "entender como funciona" a costa de todo el sufrimiento previo
• Optar por git como control de versiones preferido en todo al punto de creer que usar subversion en realidad un obstáculo

De todo esto se concluye que es muy difícil que alguna tabla de equivalencia de comandos o "mini-tutorial" sirva para que un usuario que esta cómodo con svn pueda trabajar igual de cómodo y feliz con git, o por lo menos que valga la pena el cambio, para eso un usuario debe volverse "usuario de git" antes de usarlo y/o en primeras etapas del uso de la herramienta.

Que es ser un usuario de svn y que es ser un usuario de git (mindsets)

En esta seccion me voy a referir a un "usuario de svn" a alguien que usa svn desde hace mucho tiempo, y que esta comodo y feliz con la herramienta ya que tiene ese "mindset". Lo mismo para un "usuario de git".

No obstante, la característica mas importante a analizar no es la herramienta, sino la manera de pensar las cosas, los conceptos y en ultima instancia como resuelve las situaciones del dia a dia con su herramienta favorita. Como esto no es "git evangelism", y el foco es estudiar como pasar de svn a git, sere lo mas objetivo posible

Lo mas sencillo sera mostrar la siguiente tabla:

Problema o concepto	Usuario de svn	Usuario de git
Tengo código que quiero guardar, pero "no esta listo" para integrarlo al trunk por lo que no quiero commitearlo ¿Que hago?	"Facil: tengo tres opciones: copio el codigo, y lo pego en un notepad, copio en el mismo archivo pero comentado No hago nada, porque se que puedo volver atrás con ctrl+Z crear un branch, pero preferiria que no"	"Facil: puedo commitear ya que ese commit es local, o si no también puedo crear un branch"
Estoy trabajando en una feature nueva que todavia no commitie, y alguien me pide que resuelva un bug ¿que hago?	GTFO, esperar hasta que termine la feature y haga el commit Hacer checkout del mismo repo en otro directorio, arreglarlo ahi y commitearlo Copiar el codigo a otro directorio, revertir la WC, arreglarlo ahi y copiarlo	Guardo un "stash", arreglo el bug, commit, push. restauro el stash Hago un branch
Tengo una funcionalidad a medio hacer sin commitear y me tengo que ir a mi casa, mis compañeros se quedan y podrian continuarla	No commiteo, solo yo sigo mi trabajo mañana commiteo aunque el trunk quede inestable Les doy mi computadora Hago un zip con el codigo y se los mando Me quedo hasta que pueda commitear algo bueno	Commiteo (es local) y despues pusheo a un branch asi los demas pueden seguir trabajando en el
Dos o mas integrantes del equipo colaboraran en el desarrollo de un nueva feature, que tardara un mes	Ahora si se justifica crear un branch Pair-Programming y commitear cuando termine (no conviene) Fragmentar en features mas pequeñas y commitear todos los días siempre y cuando "no rompan nada"	Definitivamente hay que crear un branch
Dos o mas integrantes del equipo colaboraran en el desarrollo de un nueva feature, que se completara en el dia	Pair-Programming y commit cuando se complete	Branch
Commit	"Es la esencia de esto, hay que hacer update antes del commit para integrar los cambios del servidor"	"Puedo commitear cuando quiera independientemente de que ocurra en el 'servidor'"
Branch	"Creare branches solo cuando sea estrictamente necesario (por ej: features que tardaran mucho mucho tiempo) o lo indique la gente de SCM"	"Lo mas importante es saber manipular branches, porque aparecen todo el tiempo si se trabaja de manera distribuida"
Merge	"Pasa automatico cuando hago update pero hacer un merge manual es un quilombo y tarda, por eso no convienen los branches"	"Pasa automaticamente cada vez que hago un pull y hacerlo manual es trivial y rapido"
Historia	"La historia se almacena en una secuencia de changesets, por eso cada revision tiene un numero, eso lo hace sencillo"	"La historia se almacena como un DAG (Arbol) de commits, entender eso es importante para comprender los branches"

El usuario de svn usa los sencillos comandos provistos por svn y varias herramientas mas como editores, IDE, compresores, mail, etc... para resolver los problemas del dia a dia, mientras que el usuario de git para resolver los mismos problemas diarios usa solamente git, que para ser justos, git en realidad es un filesystem mas un set muy extenso de herramientas sencillas, pero git como conjunto de herramientas es complejo, quiere ser lo suficientemente complejo y sofisticado para cubrir todas las necesidades y que no sean necesarios ni notepads, ni código comentado, ni mails, ni ctrl-Z para manejar versiones de código.

Un usuario de git estara pensando todo el tiempo que hace control de versiones en branches, para el es fundamental saber como manipular branches (crear, mergear, etc...) ya que sabe que los branches se crean todo el tiempo por trabajar de manera distribuida. Asumen el concepto de que es literalmente imposible trabajar sin branches en un equipo de desarrollo y por lo tanto no buscaran el imposible de "evitar branch a toda costa" sino solamente se dedicaran a controlar los branches que surgen para que no diverjan demasiado.

Consideran que todas las versiones son parte de un arbol que muestra la divergencia.

Un usuario de svn se enfoca principalmente en la "linea principal" y pensara en branches solo si surgen ciertas situaciones puntuales como por ej una feature que tardara demasiado tiempo (que en general es mejor evitar) o una version alterna del producto a medida. Asumen que la creación de branches siempre conlleva un overhead que en muchos casos solo sirven para complicar mas las cosas, muchos usuarios svn concuerdan en que si un branch va a durar mucho tiempo (digamos semanas) y se justifica podria aceptarse si el beneficio que se presume traera el branch supera ese overhead. Asi mismo cuando un branch se extiende en el tiempo y diverge mucho la integracion a la linea principal se vuelve mas complicada por lo que la integracion de esos "branches mounstruosos" es algo que no se busca (true story).

No consideran que la diferencia entre su working copy y lo que hay en el servidor sea un branch por que commitear y updatear es mucho mas facil que manipular branches.

Ven las versiones del repositorio como algo lineal

¿ Que pasa cuando hay que usar una herramienta "diferente" ?

Si un usuario svn, pasa a usar git con la consigna "reemplazo svn con git en mi set de herramientas", se encontrara que la complejidad de git, que es mayor que la de svn, sumada a la complejidad de las herramientas que esta acostumbrado a usar (bloc de notas, mails, etc...) se convertira en una molestia y no podría trabajar bien. Mientras que un usuario habituado a git, usa git para una mayor cantidad de cosas aprovechando al maximo posible las posibilidades de la herramienta (que son la cara buena de esas complejidades) y no permitiendo que surja necesidad de usar algo adicional, asi es como muchos se maravillan con git mientras otros no entienden porque si git es tan complicado.

Por ejemplo, a un usuario svn generalmente no se le ocurriría crear branches de corta duracion, porque tiene la idea de que son complicados y no valen la pena, ahi habria una ventaja que no se aprovecharía (mientras que lidear con muchas de las cosas complicadas esta implícito en el uso dirio). A alguien habituado con svn tambien le causaria mucha confusion el hacer un git pull y que el merge automatico no funcione, que se haya arrepentido o lo que sea ya que lo que hay en git no puede ser visualizado con un modelo lineal.

También es complicado para un usuario de git trabajar con svn, ya que tiene la costumbre de manejar el versionado de código solamente con una herramienta, se encontrara con que en svn los branches cortos no valen la pena y que hay muchas herramientas que faltan en comparación con git al que esta habituado y como esta acostumbrado a usar git todo el tiempo casi no conoce de herramientas "extras" y trabajar con svn le seria dificil.

Por eso el philosoraptor de la imagen se pregunta porque no existen manuales de svn para usuarios de git (mas bien seria manuales de las herramientas adicionales que hacen falta para complementar svn) si existen manuales de git para usuarios de svn.

Conclusión, como pasar de svn a git

• Comprender que con git las cosas se hacen diferente, que hacerlas "a la vieja usanza" es mas complicado que con la herramienta de siempre
• Abordar git de cara a las ventajas (ej: branching, merging, distribuido, forks, staging area, versionado local, etc...)
• Cambiar la manera de hacer las cosas, para aprovechar funcionalidades de git (no pensar, tal funcionalidad no la uso porque así no hago las cosas, cambiar la manera de hacer las cosas)
• Pensar "out of the box", estar listo para cambiar las estructuras de pensamiento mas elementales
• Al enfrentarse a complejidades adicionales que no había en svn, buscar comprender porque es asi, como eso se relaciona con ventajas de la herramienta y como aprovechar esas ventajas
• Ver las versiones como un arbol y manipularlas de esa forma. NO tratar de que las cosas funcionen como en svn (por ej: no pretender que git pull funcione como svn update porque son cosas diferentes)
• Invertir tiempo, mucha gente que usa git dice que lo vale. No existe una manera rápida de aprender git pero el aprenderlo vale la pena

Links

Libro GitMagic: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/es/book.pdf

Libro ProGit: http://progit.org/

Blog GitEvangelism: http://gitevangelism.blogspot.com/

Generador de memes: http://memegenerator.net/