Developing Frogtek

El blog del Departamento de Tecnología

Autor: Julio García (página 1 de 3)

Conferencia Agile Spain 2016

La Conferencia Agile Spain es uno de los dos eventos organizados a nivel nacional por la asociación Agile Spain. Desde Frogtek acudimos todos los años a aprender y compartir sobre metodologías ágiles. Este año nos ha tocado a Jorge y a ser los privilegiados que íbamos en representación de Frogtek.

Hacía ya un par de años que no podía acercarme y he vuelto con la cabeza llena de ideas y cosas para hacer. La verdad es que no recordaba lo que me cargan las pilas este tipo de eventos. Las charlas pueden gustarme más o menos según elija. Pero siempre me hacen pensar, de una forma otra. De hecho a mitad de muchas de ellas me sorprendo a mi mismo evadido de la charla y pensando en como aplicar el concepto que acaba de explicar el ponente en nuestra empresa. O cómo nos afecta o por qué deberíamos mejorar en ese area.

Vamos que nunca me deja indiferente un sitio tan lleno de gente con ideas tan buenas y con tantas ganas de compartirlas. Además este año la organización ha estado de diez. Así que muchas gracias desde aquí a todos los que han participado, ponentes, voluntarios, etc. Por ayudar a que podamos seguir mejorando.

La comunicación y las nuevas herramientas: Slack

Siguiendo con el tema de la comunicación que ha iniciado Miky, me gustaría ahondar un poquito más en el tema.

El día 1 de abril, en Zaragoza, acudí al siguiente meetup donde Francho nos explicó cómo en su empresa, Spines, usan Slack y sus distintas integraciones. Siendo el centro de estas integraciones Hubot, un bot que permite realizar una serie de automatismos e integrar servicios y acciones fácilmente con Slack.

Como buen friki que soy tengo muchas ganas de montarme mi propio Hubot y ponerlo en nuestro Slack, pero eso no fue lo que más me llamó la atención de la charla. Lo que más me tocó fue el que ellos llevarán casi toda la comunicación a través de Slack. El email lo usaban lo mínimo. Según nos contó Francho en su cuenta de correo de la empresa sólo tenía 5 mails en los dos años y pico de empresa que llevan. Para poder llegar a esto, nos comentó que la clave residía en la separación correcta de las conversaciones en distintos canales, permitiendo así la selección de las conversaciones y facilitando la búsqueda y lectura de las mismas.

Como ya comentó Miky nosotros llevamos menos tiempo con Slack y nos ha reportado ya una serie de beneficios increíbles. No tengo claro que el objetivo deba ser abandonar el email del todo, pero sí que veo que para ciertos tipos de comunicación deberíamos tender más a Slack, sobre todo en torno a emails automáticos y alertas. Además creo que el tema de los canales por conversación tiene mucho sentido. Ahora mismo sufrimos, entiendo, uno de los primeros anti-patrones de uso de Slack, que es mezclar y tener muchas conversaciones en un mismo canal. No es que tengamos un único canal, ni mucho menos, pero igual deberíamos plantearnos dividir alguno más y acostumbrarnos a hacer un buen uso de los canales.

Al fin y al cabo es lo mismo que ocurre con el email. Con un buen uso de la herramienta se puede conseguir mejorar mucho la comunicación, sobre todo su calidad y facilidad de lectura. Aplicar una herramienta nueva lleva su tiempo y se necesitan distintas iteraciones hasta que se consigue dar en el clavo. Tenemos que trabajar en ello, así que ya tengo tema para la siguiente retrospectiva.

Comunicación: ajustando una máquina compleja (Work In Progress)

La regla del boy Scout

Desde mi último cambio de trabajo le he estado dando vueltas a un tema que me parece interesante.

Por un lado en el traspaso de conocimiento que hice antes de irme de Zentyal, la persona que se incorporaba llegó con energía, cuestionándose las cosas y mejorando en general todos los sistemas que yo le estaba traspasando. Había cosas que él proponía que me costaba aceptar. Seguramente porque no quería reconocer que me había acomodado, ya no buscaba las mejoras con el mismo ímpetu y ganas; y había dejado que ciertas áreas se estancaran bastante.

Al entrar de nuevo en Frogtek sí que fui yo el que se puso a buscar dónde aplicar todo lo aprendido desde mi última vez por aquí, planteando mejoras y buscando sitios donde aplicar mis conocimientos para el provecho del equipo. Ahora voy con mucha energía y ganas, pero me da miedo que dentro de un tiempo vuelva a acomodarme otra vez y me cueste buscar mejoras y realizarlas.

Creo que el problema tiene mucho que ver con la teoría de las ventanas rotas. Al principio, al llegar, quiero mejorarlo todo porque creo que el edificio esta nuevecito, para mí obviamente lo está. Pero conforme pasa el tiempo y voy conociendo más los entresijos de la empresa, el equipo, el código… se me van rompiendo las ventanas y me va dando más pereza intentar arreglarlas. Porque me parece el estado normal, total una ventana más o menos qué más da,  ¿no? ¿ Qué importa un archivo sin usar en el repositorio, una librería desactualizada, un proceso mejorable o unos tests de más o menos?

¡¡Mucho!! Por eso creo que es muy importante La regla del boy Scout, pero no sólo aplicada al código, sino a todo. Cada vez que toquemos un archivo del repo, cambiemos una configuración de Jenkins o simplemente asistamos a una reunión del proceso. Hay que estar atentos para buscar esos pequeños cambios o mejoras que nos van a permitir poco a poco llevar nuestro trabajo, y el del todo el equipo, a otro nivel.

Hay que tener paciencia y no desesperar, no sólo los grandes refactors pueden ayudarte a saber vivir con tu deuda técnica, pequeño paso a pequeño paso se puede llegar muy lejos. A ver si soy capaz de tener paciencia y aplicarme esta última frase.

Agile Open Space Zaragoza 2012

¿Qué es un Open Space?

La técnica del Open Space permite conseguir, de un grupo numeroso de personas y en un mínimo tiempo, las mejores ideas alrededor de una o varias materias (“tracks”) sobre un gran tema.

Definición y más explicación aquí.

¿Por qué “Agile“?

Porque gira en torno a las metodologías ágiles y es una de las dos reuniones anuales realizadas por la Comunidad Ágil en España.

¿Qué hace Frogtek hablando de este evento?

Desde la creacción de Frogtek, hemos valorado mucho la formación y la mejora continua a la hora de realizar nuestro trabajo. No hay mejor forma de aprender y mejorar que compartir tus experiencias y escuchar las de otros.  En un Open Space, se potencian esas dinámicas para permitirte obtener el mayor conocimiento y valor el tiempo que pases allí.

¿Os han servido de algo vuestras asistencias de otros años?

Siempre, de una forma u otra hemos sacado algo positivo. Del último, por ejemplo, obtuvimos ideas nuevas sobre Agile Testing o creación de User Stories. En el de 2010, compartimos nuestro modelo de organización y nos sacaron punta, ayudándonos a mejorar en la dirección correcta.

¿Recomendáis acudir al eventazo del año?

Por supuesto, ¿a qué esperas para apuntarte? Regístrate aquí y vente a compartir y aprender en un evento distinto.

 

actionbarsherlock para Android

Hace poco nos vimos en la tesitura de querer añadir una actionBar a nuestra aplicación. Investigando sobre cómo hacerlo, nos dimos cuenta de que la compatibilidad hacía atrás era un poco “laboriosa“.

Mientras dudábamos sobre cómo afrontar la creación de la nueva actionBar, nuestro querido compañero Francho nos informó de la existencia de ActionBarSherlock.

ActionBarSherlock es una librería que facilita el uso de la librería de compatibilidad de Android y además incorpora la creación de la barra de acciones que por defecto no está soportada. Su funcionamiento es impecable y simplifica mucho el uso de todos los elementos no soportados en versiones pre-HoneyComb.

Echadle un vistazo si estáis pensando dar soporte a versiones antiguas, sin perder la potencia de los elementos y herramientas de lo más nuevo de Android.

 

Google App Engine: Lanzar un MapReduce desde un Cron (Segunda Parte)

Hace más de un año, Alberto nos explicaba cómo lanzar un MapReduce desde un Cron en Google App Engine. Desde entonces ha llovido mucho. Google App Engine ha evolucionado y madurado, trayéndonos mejor documentación y una comunidad más activa.

Gracias a ello he podido encontrar una solución más sencilla que la que os ofrecímos en nuestro último post al respecto. Digamos que queda mucho más sencillo 😛

from mapreduce import control
 
mapreduce_id = control.start_map(
"My Mapper",
"main.my_mapper",
"mapreduce.input_readers.DatastoreInputReader",
{"entity_kind": "models.MyEntity"},
shard_count=10)

Cuidado con el shard_count. Aseguraos que corresponde con el que tenéis configurado en vuestra aplicación.

 

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?

 

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.

 

 

 

El cambio comienza contigo

Henrik Kniberg autor de “Scrum and XP from the Trenches” publicó hace poco la presentación que realizó en el Tokyo Scrum Gathering. Me ha gustado mucho poder leerla y eso que son sólo slides, me habría encantado verla.

El cambio comienza contigo

Puede que no cuente nada nuevo, como suele pasar como estas cosas, pero me ha gustado  ver como él mismo aplica sus ideas a su familia y a su vida. ¡Y le funciona! Podéis verlo en la parte final de la presentación.

Tendré que hacerle caso y comenzar a cambiar 🙂

Produce el mejor código que puedas

Leyendo un post de Lisa Crispin he leído algo que me ha hecho recapacitar sobre el modo en que programo.

He exhorted us every day to write code that we’d be proud to take home and show our moms. He told us over and over, “I don’t care how much you get done, or whether you meet some deadline. I only care that you produce the best quality that you can.”

Traducción al español

Y ahí le doy toda la razón. Deberíamos escribir código del que estuviéramos orgullosos.  Y reconozco que yo no lo hago o no tanto como debería.

Por eso me encanta que me lo recuerden de vez en cuando. Porque si no serán los propios bugs que he generado los que me demuestren que no debería correr tanto o escribir tan pocos tests…

Antiguas entradas