Curso de introducción a Android en Zaragoza

Hace unas semanas anunciábamos un curso de Android en Walqa, pero su escasa participación nos obligó a cancelarlo. Ahora, volvemos a lanzar el curso en Zaragoza. Aquí están los datos sobre el curso para los que podáis estar interesados.

  • 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
Escrito en miscelánea | 2 comentarios

Afinando GIT

Después de varios meses trabajando en la migración a GIT, finalmente podemos decir que todo ha salido a pedir de Milhouse. Además nos ha servido para darnos cuenta de que vamos a tener que acostumbrarnos a que el sistema de control de versiones sea una parte fundamental de nuestra metodología de trabajo. Principalmente por el gráfico que aparece a continuación. Está extraído de este gran artículo sobre control de ramas con GIT. De él obtuvimos la inspiración para realizar nuestro sistema de branching, pero no es de esto de lo que queremos hablar…

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”:
  2. 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
  3. Pasarnos a bash y crear más “alias“:
  4. 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.

  5. 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.

Escrito en git, herramientas | Etiquetado como , , , , | Escribe un comentario

Las buenas maneras de un programador

Ayer me encontré con el siguiente artículo, “The 10 commandments of good source control management” .  Había sido twiteado por @psluaces. Comencé a leerlo y no pude evitar que una sonrisa invadiera mi cara conforme iba leyendo. Aunque algunos de los mandamientos no son muy útiles o relevantes para mí (no he usado VSS nunca, por ejemplo). Otros los he cometido y sufrido con demasiada frecuencia como para dejar pasar la oportunidad de comentar al menos un par de ellos.

“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?

 

Escrito en miscelánea | Escribe un comentario

Scrum, Kanban y la matriz de Eisenhower

Érase una vez un Scrum Master que controlaba el proceso Scrumban que un equipo seguía. ¿Le pitan a alguien los oídos?. Dicho de otro modo, para que no se diga que aquí sólo escribimos para los “talibanes agilistas” ;P.

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. :)

Escrito en agile, metodología, miscelánea, scrum | Etiquetado como , , , , , | Escribe un comentario

Curso de Iniciación a Android en Walqa, Huesca

Si habéis estado atentos al blog os habréis dado cuenta que de arriba, al lado del Disclaimer ha aparecido una nueva sección de nombre “Formación“. No son necesarias demasiadas explicaciones ¿verdad?.

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!.

Escrito en miscelánea | 2 comentarios

Feedback público todos con todos

Hacía tiempo que tenía pendiente escribir sobre el feedback en una start-up. El feedback sí, bueno, hablando en cristiano, cuando te dicen las cosas que haces bien y las que no tanto. Un ejercicio de sinceridad que es muy necesario si se quiere mejorar en cualquier entorno, ya sea el trabajo o alguna otra faceta de la vida. Necesario pero incómodo. No siempre resulta fácil que tu jefe o que uno de tus compañeros resalte esas cosas que haces mal ya sea en privado en incluso en público.

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.

Escrito en miscelánea | 2 comentarios

Ver la branch de git en la que estas en bash

Hace unas dos semanas que hemos migrado a github. Tras pasar varios meses con git-svn y ver que cada día nos gustaba más, decidimos dar el paso a este servicio para también evitar tener que perder tiempo en el mantenimiento de la herramienta de review, los back ups, y el repositorio.

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\]\$ “

Escrito en programación | Etiquetado como | 1 comentario

Developing Frogtek Reloaded

Llevábamos unos meses sufriendo problemas de latencia en este blog, por lo que decidimos investigar el problema. Después de darle muchas vueltas, decidimos alojar el blog en un host dedicado.

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

Escrito en miscelánea | Escribe un comentario

BDD en Google App Engine con Lettuce y Splinter (I)

Hemos de reconocerlo: tenemos mucho que aprender en lo que se refiere a programación de pruebas automáticas en la web. Hace ya bastante tiempo que veníamos usando Selenium , primero grabando las pruebas con su IDE, más tarde programándolas con Web Driver. Pero los tests resultantes eran frágiles y aburridos de programar, por lo que sentíamos bastante envidia de los developers Ruby con su flamante Cucumber y sus elegantes tests BDD.

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:
Siempre es verano con el pepino en la mano

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.

Escrito en gae, google app engine, programación, python, testing | 1 comentario

Visualizar el servidor de integración continua

Monitor de monitorizaciónOs presento la última “frikada” que hemos añadido a nuestra colección de gadgets de oficina.

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.

 

 

 

Escrito en agile, eficiencia, herramientas, integración continua | Etiquetado como , , | 3 comentarios