
Desde esta semana usará el número de esta en el año en vez del número de la serie de los post, así será más fácil ubicarlo en este espacio tiempo. Dicho esto, no estoy muy satisfecho con los objetivos conseguidos la semana pasada, han aparecido algunos efectos colaterales que el viernes también me han tenido enganchado al 50% al trabajo sin poder dedicarme de forma completa a mi plan de formación.
Pero no todo fue tan mala, el sábado como ya habréis podido ver ganamos el hackaton de #BBJamSessions organizado por RIM. Todo un lujazo de día.
Por el los entresijos de la red me he quedado con unos cuantos recursos:
Como veis un poco de todo, Java Script para móviles (me ha gustado mucho la librería de SwipeView), escalabilidad, xcode y… con el ojo ya puesto en Rails4.0. Como extra os dejo un vídeo muy útil de performance con Apache + Passenger.
Prometo esta semana avanzar en los tutos de Git!!! Trustme!

Ayer estuve todo el día en la BBJamSession Galicia que tuvo lugar en Santiago de Compostela. Se celebraba un hackton por equipos durante 10 horas con el objetivo de avanzar lo máximo posible en el desarrollo de un proyecto para BlackBerry 10. A escoger la tecnología, HTML5, JS, Cascade, QT y otras de las alternativas que presenta, y con acierto, RIM para BB10.
En mi caso el equipo lo formamos estos fenómen@s:
CarPool representa la idea de compartir transporte (como anda la gasolina y los peajes suena bien) facilitando la labor de compartir gastos entre los viajeros, la búsqueda y la “reservar” de una plaza al momento en un transporte. Desde la linea 1 de código hasta el elevator pitch pasamos 10 horas de buena compañía, café, pizzas, Redbull, Doritos etc… ingredientes básicos en cualquier hackaton que se precie. Para atacar el proyecto nos dividimos las funcionalidades entre nosotros para que cada uno se centrase 100% en esa función. Escogimos lo principal para empezar a funcionar, registro y login de viajeros, creación de trayectos, búsquedas, visualización en mapas y reserva de plazas para hacer una ruta. El front-end web y la capa de servicios los desarrollamos en Rails y la parte móvil usando HTML5, jQueryMobile y BB Webworks;al final cumplimos todos estos puntos, sin muchos testing ni validaciones pero suficiente.
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.
En la primera parte de esta serie de posts sobre Git hemos creado nuestro primer repo con los comandos más básicos de git:
Add y commit junto con push y pull comenzaremos a ver en este parte son el pan nuestro de cada día en la gestión de código con Git. A modo de recordatorio teníamos nuestro repositorio creado en la carpeta git1, está podría ser un proyecto, una serie de documentos o cualquier tipo de contenido.
Ahora veremos como trabajar con las ramas (branches) y la convención de nombres de git.
Master branch es el master de todos
Tocando un poco de teoría y buenas prácticas la rama principal en Git se llama master, y solo hay que tener un factor en cuenta para gestionar el código sin dolores de cabeza:
En la rama master SIEMPRE tenemos que tener una versión operativa del código
¿Por que? La razón es sencilla. Normalmente trabajamos con Capistrano para hacer los pases a producción o a los servidores de desarrollo y este se conecta al repositorio para descargar la última versión en la rama master (se puede configurar para usar otra, pero esto es lo óptimo) para realizar las operaciones sobre ella. Yo me he acostumbrado a crear una rama por caso, funcionalidad o user story, lo que mejor os venga, desarrollar sobre ella y después pasarla al master cuando está lista. Esto nos permite borrar una rama de golpe si el resultado no es bueno o al final desechamos esa funcionalidad sin necesidad de hacer resets (operaciones que veremos en la III parte) sobre la rama principal. Con esto ya nos podemos poner hands on it y trabajar con las ramas en local. Iremos viendo paso a paso como evolucionan los commits en local con la herramienta gitk.
Ú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.
Si me descuido pasa un año si que le dedicase un solo momento al blog, pero volvemos a la carga con un nuevo estilo orientado a la lectura sencilla, espero que sea de vuestro agrado.
Desde mi último blog la absorción por el trabajo y levantar Softwhisper como empresa ha sido una tarea que me ha consumido, y sigue, una media de 12 horas diarias, pero eso ya lo tenía claro desde un principio. Nuevos retos, proyectos que se vuelven tortuosos, impagos, errores que cometimos por falta de experiencia, estrés, presiones, malas relaciones… cosas que con las que hay que lidiar en determinadas ocasiones. Estás son situaciones límite con las que todos nos encontramos en algún momento e intentamos minimizarlas con la experiencia.
¿Que es para mi la experiencia que he adquirido en Softwhisper?
Lo primero de lo que he tomado nota es que no hay amigos, ni debe de haberlos en la relación con los clientes. La relación siempre debe transcurrir en unos términos cordiales en un marco en el que todos rememos en la misma dirección, es la única manera de sacar adelante el trabajo de una forma satisfactoria. Esto no quita que fuera del ámbito profesional dos personas compatibles puedan tener una relación más halla de la laboral, pero dentro de lo profesional hay que apartar esas sensaciones y cada uno ha de desempeñar el rol que debe.
Otro aspecto que he considerado importante es la transparecia. Siempre he querido que con Softwhisper el cliente se sintiese uno más del equipo participando en todos y cada uno de los procesos del ciclo de vida de un proyecto. Es importante que ha su vez el cliente comparta con nosotros situaciones, problemas o preocupaciones. Un problema hablado y atajado a tiempo, es siempre mejor que un problema guardado y que dejas explotar. Esto puede generar conflictos y tensiones innecesarias que perjudiquen a todo el equipo, las situaciones “Entre dimes y diretes” acaban por intoxicar un proyectos y la relación cliente-proveedor.
Un punto importante del que estoy aprendiendo poco a poco es la especificación de los proyectos. Está claro que son necesarias y hay que hacerlas para poder cerrar cualquier proyecto. Ahora bien, el problema reside en el nivel de especificación. En algunas ocasiones todo ha salido bien, y aun habiendo cambiado la especificación inicial, y sobre la que se ha presupuestado y firmado, ambas partes éramos conscientes de la situación. El problema viene cuando el haber dejado algunos puntos sin cerrar pueden provocar situaciones tensa… los puntos que considero más importantes para dejar aclarados son los siguiente:
En los últimos meses haber hecho mejor alguno de estos puntos me hubieses ahorrado muchos quebraderos de cabeza.
En definitiva…
Como hace poco me decía @luisdiazdeldedo en twitter:
@pabloformoso a aprender y a superar las etapas malas cuanto antes! así las buenas volverán más pronto!
De todo se aprende y la experiencia es algo que viene de los errores, solo espero seguirme equivocando durante muchos más
Ya estoy pensado empezar un libro de aventuras empresariales
Desde hace algo más de un año creo que rara vez he descansado un día festivo completo o ha pasado un domingo si que me metiese en la vorágine de información.
He empezado a leer el libro “Focus” y comienza tratando precisamente este tema, emails, tweets, mensajes, notificaciones, whatsapps, skype, reporting, …. Un stream de información infinito he imparable que genera una falsa necesidad de tener que saber al momento lo último, esto desencadena una sensación de satisfacción inmediata que el cuerpo agradece y que pasa a convertirse en una clara procrastinación, al menos en mi, me imagino que algunos os identificareis también con esto.
De momento el libro me ha dado unas cuantas cosas en las que pensar en tan solo 2 capítulos y el resto me lo reservo para asimilaron con calma en las vacaciones. ¿Pero realmente necesitamos saber que pasa cada segundo en nuestro time line general? ¿donde esta el time life? El tiempo de vivir, desconectar, valorar las pequeñas cosas y crear.
Cada día más sube mi nivel como programador, pero me he dado cuenta de que me he convertido en una maquina de picar completamente automatiza, la belleza de la creatividad se ha esfumado parcialmente quedando relegada a un segundo plano, cuando eso tiene que ser el motor que mueva todos mis trabajos, si no habré dejado de ser yo. Antes la ideas fluían libres, analizaba e intentaba innovar cada paso, eso tiene que seguir así y para ello el tiempo consumido por el inmenso stream de información al que estamos sometidos a diario debe reducirse. Cada vez más, si a los contenidos personalizados, no quiero un periódico, quiero mi periódico; no quiero saber que ha salido un nuevo modelo de X, quiero que el modelo Y que me gusta y quiero comprar me lo mandes a mi correo, TL o donde sea cuando esté.
No es nada nuevo, ni nada que nadie se haya planteado y realmente es algo muy difícil de conseguir ya que nos enfrentamos a un medio no heterogéneo y en continua expansión y crecimiento, pero todo se andará.
Ahora es cuando encaja la frase de “I have a dream”