Apagar y volver a encender ha sido siempre y será la solución mejor para el informático. Para la vida personal, ni te cuento.

Semana de nadar, boulder, montaña, amigos, familia, spa… rica, rica. En una situación trabajando en jornada de verano, meditando y buscando la paz interior puedo afirmar que no estoy en mi mejor momento pero que me encuentro con muchísimas ganas de retomar los cursillos, proyectillos, colaboradora, etc. Incluso a medio gas, siempre se aprenden nuevas cosas.

Aquí va el resumen de la semana pasada.

Currele

Soluciones en AsisT

Lo defino así porque así lo he vivido. Ha sido una semana que han surgido nuevas peticiones en las instalaciones y soporte. Ante eso ha sido puro y duro buscar soluciones, transmitirlas, estimarlas y desarrollar las urgentes.

Experiencia de Git: Esta semana, aprovechando que era la única desarrollando,  he estado probando utilizar git-flow siguiendo el modelo de 4 ramas. Master, develop, Features, Hotfix.

Me ha gustado la experiencia de desarrollar toda en una y realizar commits y push sobre ella. La gran ventaja que he visto es que he tenido que solucionar un conflicto en vez de cada rama de desarrollo. Como observación no he hecho un pull request a desarrollo hasta que el responsable de mergear las ramas no volviera de sus vacaciones.

También, contra-pronóstico, he tenido que desarrollar un bug en  Hotfix. Nunca habíamos utilizado una rama distinta y «limpia» (sin ningún otro desarrollo) para subir un bug, utilizábamos ya los desarrollos hechos y probados e incorporábamos el bug solucionado. Para mí, utilizar Hotfix me da mayor seguridad para subir una versión de urgencia ya que subirla con pequeños desarrollos implicaría unas pruebas de integración que retrasaría la publicación de la versión o peor aún, subirla sin realizar las suficientes pruebas (no tenemos un sistema de integración continua).

Esta semana volveré a el desarrollo de historia de usuario por rama.

Lo que no es currele

Geek’s talks: Charla mensual para desarrolladores que quieren practicar inglés. Los orígenes los explico en este post. El pasado 7 de agosto se hicieron realidad. Los detalles de qué se hizo en el evento están aquí. En este resumen quería aprovechar para contar mi experiencia personal.

Fui al evento con bastante miedo de que no fuera nadie. ¿Las causas? Una lluvia torrencial que hasta a mí me había dejado incomunicada en la avenida navarra.  Me presenté con la filosofía: si no viene nadie, al menos me echaré una birra 🙂 Además, para conversar, sólo se necesitan dos personas 🙂

Grata sorpresa de estar 7 personas, empiezo a saludar en español… oh my cat! We must speak english. Cambio al inglés. Empieza la primera sesión de Geek’s Talks. Awesome!

Lo primero que hicimos fueron presentaciones personales: a qué nos dedicamos, porqué estamos en el grupo, qué esperamos de las charlas, etc. Es un gran momento para romper el hielo, conocernos y saber qué es lo que quiere aprender cada uno para orientar mejor las charlas. Cada uno tenía su propia opinión, algunos mejorar en lo técnico, otros en la gramática, otros en conversación, etc. Pero había un denominador común: ganas de mejorar y aprender.

Continuamos con el tema en cuestión: ¿Qué sistema de control de versiones utilizas? ¿Qué opinas de él? ¿Cosas buenas y malas? ¿Como utilizas el control de versiones? ¿Cosas buenas y malas?

Siendo la primera quedada me lancé a proponer un tema que a mí me venía bien en el ámbito profesional, pero la idea es que mediante la plataforma de Meetup se propongan temas para solucionar dudas de todos.

En esta charla quería sacar de conclusión si es mejor utilizar una rama por cada historia de funcionalidad o una rama feautures paralela a develop. Me llevé un saco de buenas ideas y creo que me decantaría por crear una rama por historia con una figura de persona mergeadora.

Guillermo Zanfra utiliza develop y master. El único problema que comentó es que hasta que hasta que no haces un push a develop, tienes todo tu desarrollo en local. Para el tipo de proyecto me parece que es buena solución. Este modelo es el típico a utilizar cuando una sola persona está en el proyecto. 

Por lo general en grandes proyectos utilizaban una rama por funcionalidad. Cuando subían esas ramas, se despreocupaban completamente de ellas. Existe una figura que las comprueba y realiza los merges con desarrollo.

Durante la conversación, anotamos vocabulario, gramática que dudábamos y algunos fallos de pronunciación 😉 Check the list!

Y cuando terminamos… continuamos hablando en inglés xDD. Nos fuimos por ahí cerca a cenar y hasta que no salimos del restaurante, continuamos nuestra andadura. Entre las cosas que comentamos fue la retro del evento. Estuvimos hablando de cómo mejorar en la siguiente iteración, técnicas para aprender, etc. No adelantaré detalles…. (más que nada porque ya me he liado bastante hablando xDD).

Esta semana será corta y poco productiva: el miércoles me iré de puente (bravo).

Sólo me queda desear que paséis y disfrutéis de unas preciosas, hermosas y felices vacaciones! A ser felices y comer perdices!