Hoy ha salido una entrevista que me hicieron en Appleinforma.com. Quiero agradecer a Manu el interés y la oportunidad que nos da a los desarrolladores de aparecen un medio y expresarnos libremente.
Quiero dar las gracias a todos lo que estáis haciendo el tuto de git, no me imaginé que fuera a registrar tantas entradas. Esto da ánimos para hacer más y mejor, nunca fui muy diestro con la redacción.
Tras el post sobre mi reflexión sobre lo mucho que descuidaba el invertir en conocimiento para auto formación he de decir que la primera semana no ha salido nada mal. La media de horario fue de 08:00 a 19:30 / 20:00 con una hora para comer completando las casi 44 horas entre Lunes y Jueves. El viernes por la mañana me puede dedicar a seguir con el curso Scala en @corusera (terreno que me dará para escribir, me está gustando bastante) y entrar a fondo con puntos nuevos de iOS6, trasteo con CollectionViews, adaptación a iPhone5 y un par de puntos más interesantes.
También he podido sacar tiempo para mantener los feeds al día donde he encontrado cosas interesantes como
Con todo esto el fin de semana también hubo tiempo para seguir preparando la boda (60 días y bajando), churrasco y desconectar un poco. Esta semana habrá que intentar repetirlo. Espero que esta parte de la semana en resumen se transforme en algo de largo recorrido.
Por el título no esperéis un post sobre bolsa, economía o donde está el precio del BigMac más barato. Este artículo va sobre mi experiencia en los 15 años que llevo programando. Y en que me he equivocado a la hora de gestionar el conocimiento.
Ya quedan lejos los tiempos de los cursos de Basic en verano con 14 años, o cuando el hermano mayor de un buen compañero de colegio me enseño a configurar mi primer *nix para descargar toda la música de FTPs públicas, por el 1998 con la belleza de baudio mis expectativas eran de 4 o 5 canciones cada noche. Todos lo que sabía se aplicaba en el contexto del cacharreo y romper cosas donde muchas veces los dos profesores de Informática del colegio tenía una pequeña ayuda para mi.
15 años más tarde me veo en una espiral infinita en la que cada día sale al mercado una nueva tecnología, un nuevo framework que promete el oro y el moro, donde las versiones de muchas SDK de desarrollo avanzan galopantes sin piedad de los pobres desarrolladores, que cuando estamos, por poner un ejemplo, dominando los Storyboards de iOS5 a alto nivel nos espetan en los morros CollectionViews, todo maravilloso y fenomenal para nosotros, pero el tiempo para asimilar toda esta información nueva cada día requiere una inversión con el fin de mejorar. Pero esto no es nada cuando además lo tienes que compaginar con emprender y crear una empresa, las distracciones son continuas:
Reuniones en las que muchas veces sacas nada en claro
Llamadas de teléfono
Mails a cada rato
Presupuestos, facturación, conflictos con los clientes
Últimamente estamos trabajando de forma más exhaustiva en varios proyectos con otros colaboradores que encuentran en Git un problema para llevar la gestión de versiones y el código.
Los primero que hay que tener claro a la hora de empezar con Git es que no es sistema de control de versiones como SVN, pertenece a la nueva generación de DVCS, sistemas de control de versiones distribuidos.
El flujo normal en con SVN es de tirar siempre los commits hacia un mismo servidor centralizado, de modo que cada persona implicada en el proyecto trabajara sobre el mismo punto final.
Con Git lo más difícil de entender al principio es la desaparición de esa centralización para entrar en un mundo en el que cada uno tiene su repositorio en local sobre el que hacer los commits, merges, ramas y todas las operaciones que realizaremos sobre un repositorio normal pero en nuestro maquina local.
¿Que sucede con la parte remota y donde esta la colaboración?
En Git se crean repositorios remotos, cada usuario puede tener el suyo (la forma ideal de trabajar) o se puede tener un único repositorio remoto que hacen de principal. Sobre estos repositorios se realizan la mayor parte de veces las operaciones de push, para enviar nuestros commits, o pull, apara actualizar el contenido de nuestro repositorio local pero estas operaciones las veremos con mas detalla más adelante.