• Orientado a: Desarrolladores con experiencia en lenguajes orientados a objetos
• Plazas: 15
• Fecha: Del 16 al 20 de abril. De 9 a 14 horas.
• Lugar: Iniciativas Viables. C/ La Milagrosa 5-7. 50009 Zaragoza
• Precio: 250€.
• Inscripciones e información a: jose (arroba) frogtek (punto) org

Más bien queremos contar algunos ajustes que hicimos a la configuración de git para que nos sea más usable.

1. Crear unos cuantos útiles “alias”:

Lo primero es editar nuestro archivo .gitconfig, añadiendo algunas versiones cortas de los comandos más usados.

[alias]
        co = checkout
        ci = commit
        st = status
        br = branch
        brancha = branch -a

Aquí va uno muy útil: mostrar el listado de commits en una línea cada uno y mostrando los autores al principio (todo ello a color):

hist = log --graph --decorate --pretty=format:'%C(bold blue)%Creset
%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)'
--abbrev-commit --date=relative

Los dos siguientes son muy útiles para gestionar los archivos y carpetas marcados como unchanged:

unchange = update-index --assume-unchanged
unchanged = !git ls-files -v | grep ^[a-z]

El primero nos permite marcar un archivo como “assume unchanged”, en caso de que no queramos que tenga control de versiones. El segundo nos muestra qué archivos de nuestro repositorio están marcados de esta forma.

Crear una nueva branch asociada a una nueva historia de usuario:

us = "!f() { git checkout -b US$1; }; f"

Este comando funciona de la siguiente manera. Si tecleamos US 13, nos creará una nueva branch (desde la que estemos en ese momento) con el nombre US13. Muy útil.

Y para acabar, activar el color para todos los comandos de GIT:

[color]
        ui = true

2. Pasarnos a bash y crear más “alias“:

alias go='git checkout'
alias gp='git pull'
alias gs='git status'

Cambié mi terminal para que usara bash como intérprete, ya que me permitía funciones adicionales como la del punto 3. Después añadí unos cuantos alias entrando en el home y editando el archivo .bash_profile

Hay gente que prefiere utilizar el comando completo, es cuestión de gustos. He añadido git pull y git status porque son algunos de los comandos que más uso en consola.

3. Mostrar la rama actual en el shell de bash. Esto ya lo vimos en capítulos anteriores.

Y esto es todo. Recordad que lo principal es que cada uno configure sus instrumentos a su voluntad. Al fin y al cabo, se trata de estar a gusto con las herramientas que utilizas.

“Always inspect your changes before committing”

“Repasa tus cambios siempre antes de subirlos al repositorio”

Hazlo, no lo pienses. No te fíes ni de tu sombra. Al principio puede parecer una perdida de tiempo, pero es una de las costumbres que más agradezco. Porque soy despistado y humano. Por lo tanto me olvido que he cambiado algo que no quería subir o me equivoco en el código. Ese segundo vistazo me ayuda a eliminar muchos errores y problemas para mis compañeros desarrolladores.

“Remember the axe-murderer when writing commit messages”

“Recuerda al asesino del hacha cuando escribes tus mensajes de commit”

Y os preguntaréis quién coño es el “asesino del hacha“. Pues según el autor del artículo, existe un dicho que viene a decir lo siguiente: “Escribe tu siguiente comentario de commit como si el siguiente desarrollador que va a leerlo fuera un maníaco depresivo con un hacha que sabe donde vives”.

No lo cabrees, ¡por tu vida! Cosas como las que siguen probablemente lo pongan de muy mala leche:

#10 Mierda

#89 Fix tests

Opino que son dos ejemplos claros de pésimos comentarios para commits. Y eso que he escrito unos cuantos de esos, lo reconozco. El problema viene cuando tienes que volver sobre ellos porque estas revisando la historia de tu repositorio: te acuerdas del maldito día que naciste, os lo prometo.

Mucho mejor algo así:

#89 Fixing the first UI test to work better, introducing new concept ClassSetup and ClassTearDown

Y no vale currarse uno largo y reutilizarlo durante los cinco siguiente commits, cada commit tiene que ser diferente; se debe poder saber qué se ha hecho en ese commit con solo leer el mensaje. La diferencia cuando leas tu log será brutal.

Os recomiendo que os leáis el artículo de arriba a abajo, es muy bueno.

PS: He encontrado varios de los mandamientos en otra fuente, el libro Continuous Delivery. No pueden estar equivocados los dos, ¿no?

Erase una vez un gestor de un equipo encargado de llevar a cabo tareas planificadas y no planificadas en un periodo de tiempo determinado y cíclico. No sé cual de las dos introducciones es peor.

Érase, también, una vez un Product Owner malvado que no hacía más que meter Kanban en el sprint, haciendo sufrir al Scrum Master y poniendo a prueba la velocidad del equipo. El Scrum Master le insistía al equipo para que no dejara abandonadas las tareas de Scrum, mantuviera una velocidad de Scrum aceptable y consiguiera los objetivos del sprint. Y en estas llegó la retrospectiva y el equipo le afeó al Scrum Master que priorizara el Scrum frente al Kanban, ya que todos son hijos de Dios (del Product Owner en este caso). Así que el Scrum Master se puso a pensar y sacó las siguientes moralejas además de escribir este post.

• El equipo tiene razón, en teoría, el Kanban es tan válido como el Scrum. La suma de todo nos da la velocidad total del equipo y si los puntos totales al final del sprint son iguales o mayores que los planificados el equipo habrá cumplido con su papel.
• El Scrum Master también tiene razón, en la práctica, el Product Owner siempre, salvo cambios grandes de requerimientos, espera que todo el Scrum esté acabado en la fecha final de sprint. Si el Scrum se termina, el Scrum Master habrá cumplido con su papel.
• El hecho de no tener definidos claramente las prioridades del Kanban (FIRE, PRIO, ASAP) puede fomentar estos problemas. El Kanban en Frogtek entra directamente en la pila de producto del sprint y se empieza antes o después en función de lo arriba que entre en la columna. Es decir, es priorizado junto con lo demás (hasta ahí bien), pero luego cuando entra y navega por las diferentes fases no tiene ni más, ni menos prioridad que el resto de lo que está en desarrollo. De ahí que el Scrum Master en algún caso acabe defendiendo lo planificado y el programador quiera que todo se valore por igual, ambos defendiendo su trabajo. Pero ¿debe hacerse?.

Aquí es cuando entra en juego la relación entre las tareas de Scrum, Kanban y la matriz de Eisenhower. Eisenhower se ve que era un tío muy organizado y las malas lenguas dicen que inventó el típico plano cartesiano con cuatro cuadrantes, con un eje señalando la importancia y otro la urgencia. Así tras analizar una tarea en un momento dado podía decidir qué hacer con ella:

• Urgente e importante. Consejo de Eisenhower: ¡Hazla ya!. Consejo ágil: Normalmente esto es Scrum (en el peor de los casos esto entrará como Kanban de alta prioridad a mitad de sprint pero en ese caso es bastante fácil poner al Scrum Master y al equipo de acuerdo en lo importante que es sacarla la tarea cuanto antes adelante).
• No urgente pero importante. Consejo de Eisenhower: Planifícala. Consejo ágil: Vuelve a analizarla en la siguiente ronda de planificación y métela como Scrum en el siguiente sprint cuando ya sea urgente e importante.
• Urgente pero no importante. Consejo de Eisenhower: Delega. Consejo ágil: Normalmente esto es Kanban, ya que su urgencia suele salir a relucir a mitad de sprint y nunca tendrá la importancia suficiente para entrar como Scrum. Este tipo de tareas son las que crean conflicto a veces y las que acaban retrasando los sprints.
• Ni urgente, ni importante. Consejo de Eisenhower: ¡A la basura!. Consejo ágil: si ves muchas de estas en tu tabla, cambia de Product Owner.

Simplificando un poco se podría asimilar Importante con Scrum y Urgente con Kanban. Es por eso que como Scrum Master creo que Scrum casi siempre debe ir por delante que Kanban. Siendo flexibles, claro.

Esto no es nuevo. En Frogtek ya llevamos tiempo dado cursos de Android, pero hemos decidido hacerlo de forma un poco más continua y con el tiempo añadir nuevos cursos con los que nos sintamos cómodos (todos, sin falta, son cursos sobre cosas con las que trabajamos en el día a día).

En este caso ofrecemos un Curso de Iniciación a la programación en Android que vamos a dar en Walqa, estos son los datos:

• Duración: 25 horas en 5 días.
• Fechas: Del 26 al 30 de Marzo.
• Lugar: Sala de formación de AST en Walqa.
• Precio: 250€
• Número de alumnos: alrededor de 12.
• Temario: click aquí.
• Inscripciones e información sobre el pago: mandando un correo a walqa@ptwalqa.com

¡Os esperamos!.

Es por eso que alrededor del feedback hay mucho… ¿cómo decirlo?, ¿artificio?, ¿tontería?. Una de mis favoritas es esa que dice que para dar una mala noticia primero tienes que dar dos buenas, luego la mala y acabar con otra buena. La técnica del ++-+ (sí, existe, no me lo estoy inventando a mi me la contaron en Vodafone aunque no he encontrado rastro de ella en internet) ó “cómo dar feedback negativo y que nadie salga herido“, imagino que las más de las veces la persona que recibe el feedback entre tanta cháchara no se entera del problema, sí de las alabanzas que lo envuelven y sale de la sesión sin entender nada. Da hasta para un chiste malo:

“Era un programador tan malo, tan malo, tan malo que en lugar de programar en C, programaba en C++-+”.

En fin, antes de que se me aplique directamente el lanzamiento de pomodoro, por el chiste, seguiré con lo del feedback. Al final todo se reduce a acudir a una reunión de esas con actitud constructiva tanto por un lado como por el otro, ser respetuoso y sincero.

El pasado Enero en Frogtek hicimos la primera sesión de feedback pública todos con todos. Consistió en lo siguiente, hacer una ronda en la que primero uno contaba de sí mismo cual era su rol en la empresa, que cosas se le daban bien y qué cosas se le daban mal. A continuación el resto del grupo hacía lo propio con la persona que había iniciado la ronda, es decir contarle cual pensábamos que era su rol, y cuales sus puntos fuertes y sus áreas de mejora. Al acabar la primera ronda una persona había recibido feedback de todo el resto de compañeros sobre su trabajo. Obviamente es importante que el feedback se traiga preparado de casa, ya que de lo contrario en seguida se cae en el “yo lo mismo que fulanito“. De hecho en Frogtek lo trajimos escrito en fichas de forma que al final de cada ronda la persona “objeto de análisis” se hacía con 7+1 (la propia) fichas con un buen surtido de ideas interesantes. Una vez recibido el feedback los “expertos” recomiendan tener a mano a SARAH y no, Sarah no es una encantadora señorita que nos consuele, si no las fases por las que vamos a pasar inevitablemente. A saber:

• Fase 1: Shock “¿¡pero este tío qué dice!?”
• Fase 2: Anger “¿¡pero este tío qué dice!?”
• Fase 3: Resistance “¿¡pero este tío qué dice!?“
• Fase 4: Acceptance “mmmm“
• Fase 5: Help “oye tío, ¿me explicas cómo hacer eso tan bien?”

Después de un buen rato (hay que tomarse su tiempo, este ejercicio se lleva toda una mañana) y de las ocho rondas de rigor. Habíamos intercambiado 64 opiniones todos con todos en un ejercicio que, realizado con buen rollo, honestidad e interés (y con Sarah), resulta muy enriquecedor.

Además, para hacerlo todavía más interesante nosotros le pedimos a todo el mundo que se auto-clasificara y clasificara a sus compañeros de más identificado a menos identificado en las siguientes categorías (basado en el método de los 6 sombreros):

• Orientación cooperadora (verde)
• Orientación organizadora (azul)
• Orientación emprendedora (rojo)
• Orientación sociable (amarillo)

De forma que al final del día todos descubrimos cómo nos veíamos a nosotros mismos y cómo nos veía el resto del equipo. Afortunadamente en Huesca tenemos un equipo multicolor en el que no falta de nada.

Git permite manejar muy fácil y rápidamente las branches, con lo cual es muy frecuente pasar de una a otra. Git tiene la rama master que equivale al trunk de svn y por lo tanto trabajar sobre ella directamente no es recomendable, de hecho en frogtek hemos creado una tarifa de 2 euros de castigo para quien haga push directo. Para saber en qué branch estás puedes ejecutar varios comandos, pero tras ver ayer este vídeo (muy recomendable si quieres cambiar a git o simplemente enterarte de qué va), vimos que podíamos mostrar en el prompt del bash la rama actual quedando ente corchetes:

pfraca:tiendatek [US1438] $

Para hacer esto nos hemos basado en el siguiente ejemplo haciendo algún cambio para que no aparezca un prompt tan largo. Es tan fácil como copiar el siguiente código al .bash_profile

# Mostrar la branch de git en el prompt

function parse_git_branch_and_add_brackets {
git branch –no-color 2> /dev/null | sed -e ‘/^[^*]/d’ -e ‘s/* \(.*\)/\ \[\1\]/’
}

PS1=”\u:\W\[\033[0;33m\]\$(parse_git_branch_and_add_brackets) \[\033[0m\]\$ “

Por ello, los visitantes asiduos habréis notado una mejora sustancial en la velocidad de carga de la web

¡Ah! También podéis notar esta mejora en nuestra web comercial: frogtek.org

Decidimos remediarlo y Julio se puso con la instalación de  Cucumber + Capybara en el servidor, creando un test de demo y animándonos a montar el entorno en nuestras máquinas para comenzar a darle poquito a poco. Teníamos que aprender Ruby y conocer cómo funcionan sus versiones y conceptos nuevos como RubyGems, por lo que la cosa iba a ser divertida pero no rápida y por ello se nos ocurrió darle una oportunidad a una herramienta que nos sonaba de oídas: Lettuce, combinándola con otra herramienta bastante nueva: Splinter, de manera que, en lugar de pepinos y capibaras:

tendremos lechugas y poder mutante. ¡Cowabunga!

Lettuce permite definir test de aceptación automáticos para proyectos Python, y Splinter proporciona un API sencilla y potente para implementar los pasos de los tests usando diferentes webDrivers.

De momento parece que aún falta que ambos proyectos mejoren un poco ya que son relativamente recientes. En el caso de Splinter, si no llega a darnos todo el potencial que necesitamos, siempre podemos sustituirlo por twill, selenium, webdriver o windmill.

¿Por qué usar estas herramientas quizás no tan maduras como sus homólogas del mundo Ruby? Una razón discutible – aprender un nuevo lenguaje siempre es divertido y enriquecedor – es que no nos obliga a aprender Ruby y nos permite definir los pasos en Python con el que estamos mucho más cómodos. Pero la ventaja principal es que tenemos una librería Python usada en nuestros tests de integración para crear diferentes escenarios de test en GAE y esta solución nos permite aprovechar todo su potencial instantáneamente. Bueno, eso si conseguimos instalar correctamente todo lo necesario para rular estas herramientas con GAE.

En Frogtek ninguno tenemos experiencia con Django más allá de su integración con Google App Engine, por lo que seguramente nos falte algo de familiaridad con ciertos conceptos que no aplican dentro de la plataforma de Google. Es quizás por esto por lo que nos encontramos con bastantes problemas de instalación y configuración que nos gustaría compartir con todos aquí. Eso será en el próximo post.

Con el viejo servidor, actualmente en desuso, una pantalla vieja y el plugin de Jenkins  eXtreme Feedback Panel Plugin. Hemos montado un visualizador del estado de nuestro servidor de integración continua (Jenkins).

El objetivo esta claro. Conseguir estar enterados en todo momento de la salud de nuestras construcciones. Ya no vale eso de “no vi el email”.

Además informa del culpable de la rotura si la hay. Y muestra el número de tests añadidos en la última construcción, entre otras virguerías.