Developing Frogtek

El blog del Departamento de Tecnología

Categoría: programación (página 1 de 6)

Sobre código, revisiones y despliegues

Lo sé. Lo admito. Me encanta la sensación de acabar de programar algo a las 5 de la mañana. Satisfecho. Orgulloso. Tal vez con un exceso de cafeína. Mergeas, despliegas y a dormir con una sonrisa. En tus sueños un cowboy se monta en su caballo, llega al pueblo y desmonta bajo la mirada de los pueblerinos. Captura a los malos, se sacude el polvo y se va triunfal con los suspiros de aquellos y aquellas a sus espaldas. Sí, ese desarrollador cowboy que es capaz de hacerlo todo, sin hablar con nadie, sin consensuar nada.

Te levantas con la sonrisa todavía en la boca (dejemos de lado babas y otros sucesos paranormales). Vas al ordenador y ¡boom!, algo ha ido mal. La explosión despierta hasta al cowboy de tus sueños, que se tapa con una piel y se acurruca junto a la hoguera, ahora hay miedo en ojos del valiente cowboy. Creo que esta historia nos suena a muchos y a muchas. Y sí, los sueños y las sonrisas, e incluso las risas molan; pero mejor dejar las explosiones para nuestros proyectos locos y no para los serios, o para el trabajo.

Historias de usuario públicas. Ramas. Revisión de código. Pruebas manuales. Pruebas automáticas. Despliegues. El cowboy puede hacer lo que quiera, que vamos a hacer que esto no explote (o mejor dicho, que explote cuanto menos, mejor).
Seguir leyendo

El Día del Bedel

El último viernes día 6 estaba marcado en el calendario de nuestra oficina como Janitor’s Day. ¿En qué consiste este día? El día del Janitor, bedel en español, es un día de trabajo que se dedica a limpiar, pulir y dar esplendor a todo la suciedad, desorden o incidencia en nuestro software (aunque claro, también podría haberse llamado el Día del Apaleamiento).

De esta forma, durante un día el equipo se dedica en exclusiva a realizar mejoras y modificaciones en el código que de otra manera se hubieran postergado y abandonado en el olvido.

El janitor de Scrubs, hombre 10

Para organizar el evento, creamos una hoja de cálculo con una amalgama de tareas que realizar. La idea era que voluntariamente, cada uno tomáramos una de esas tareas y nos encargáramos de solucionarla. Las tareas podían ser tan variopintas como arreglar una tanda de tests, refactorizar una clase o traducir al inglés las cadenas que quedan en español en la aplicación.

En definitiva: todos los que trabajamos en software nos damos cuenta de que en ocasiones, algunas tareas se postponen o se descartan porque se descubren a mitad de otra tarea, y el miedo al cambio de contexto impide su realización. Es por ello que realizar un Janitor’s Day cada cierto tiempo es una tarea que recomendamos encarecidamente, ya que las ventajas son incontables:

  • Permite coordinar al equipo en un mismo objetivo
  • Aumenta el control del código por parte del equipo.
  • Permite e incluso potencia el pair programming
  • Da cabida a tareas que de otra forma jamás se realizarían (desidia, desconocimiento del problema por parte del C-level, …)

Cómo evitar abrir más de una Activity desde un botón

  • ¿Harto de que se pueda pulsar un botón de tu aplicación repetidas veces antes de que se cree la nueva Activity?
  • ¿Harto de tratar de evitar este comportamiento deshabilitando el botón nada más ser pulsado, y que aun así se lancen Activity sin talento?
  • ¿Harto de consultar StackOverflow y la Internet entera para no encontrar una solución que funcione de verdad?

Nosotros también lo estábamos. Concretamente, habíamos estado experimentando este problema durante años. Ahora tenemos la solución.

Como nunca hemos sido unos expertos programadores, y teníamos muchas prisas por sacar mucho trabajo adelante, nos fiábamos del “método Google” para iniciar una nueva Activity:

Intent intent = new Intent(this, NuevaActivity.class);
this.startActivity(intent);

Y aun así… daba igual que la nueva, como la vieja Activity procesaran mucha información, o poca, que marcásemos la nueva Activity como singleTop, que invocásemos al setEnabled(false); del objeto View que llamaba al startActivity(). También hemos de decir que nuestros usuarios son expertos en pulsar varios botones al mismo tiempo, o que les tiemble el dedo y hagan varias pulsaciones muy rápidas sobre el mismo botón, o que debido a la lentitud del hardware chino se desesperen a la hora de completar una tarea y sigan pulsando el mismo botón hasta el infinito y más allá.
Abrir dos o más instancias de una Activity en nuestra aplicación era muy sencillo, hasta que se nos ocurrió convertir la variable de tipo Intent en un field de nuestra clase de tipo Activity padre. Y cada vez que queremos invocar al startActivity(intent);, lo hacemos sólo si el field intent es == null.
Hay que tener cuidado si la Activity padre es una pantalla principal desde la que se pueden iniciar distintas Activity, por que si todos los new Intent() los asociamos con el field que comentaba antes, al querer iniciar la segunda vez la Activity, como intent != null, la aplicación no haría nada. Es decisión del lector de esta entrada saber cuándo hacer que el field intent sea igual a null de nuevo. ¿Quizás en el onResume()? ¿O mejor en el onActivityResult()? ¿Qué tal crear una clase de tipo Activity con este truco y que todas las actividades de la aplicación hereden de esta clase?

A nosotros nos funciona a la perfección, ¿y a ti?

Cualquier mejora a este truco, queja, grito, etc. es más que bienvenida.

Cuenta atrás en Android

Si alguna vez nos hemos visto en la situación de tener que realizar una cuenta atrás en nuestra aplicación Android (muy útil para juegos, para indicar el tiempo restante) seguramente habremos hecho uso de la clase típica para estas cosas en Java: TimerTask (java.util.TimerTask)

private TimerTask getTimerTask() {
	return new TimerTask() {
		@Override
		public void run() {
			// Aquí hacemos todo
			} catch (Exception e) {
				e.printStackTrace();
				schedule(NOW);
			}
		}
	};
}

Deberíamos modificar bastante esa clase para que llevara una cuenta regresiva de los segundos que quedan, así como hacer un schedule cada segundo de la task.
En vez de esto, resulta mucho más elegante utilizar una clase que provee Android llamada CountDownTimer. Tan fácil como hacer lo siguiente:

timer = new CountDownTimer(secondsUntilFinished, 1000) {
	public void onTick(long millisUntilFinished) {
              // Do something every second
	}

	@Override
	public void onFinish() {
              // Do something when finished
	}
}.start();

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.

 

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[33[0;33m]$(parse_git_branch_and_add_brackets) [33[0m]$ “

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.

Katas diarias

Hace unas semanas se nos ocurrió retomar el tema de las Katas, y digo retomar porque hace un tiempo nos dio por hacer Katas una vez a la semana. Esta vez fue diferente, en vez de hacerlo con tanto tiempo de diferencia, nos planteamos hacerlas diariamente. En eso consiste la Kata, ¿no? en practicar, practicar y practicar.

Así pues, empezamos Julio, Pedro y yo con Katas diarias (más adelante se uniría Javier Martínez a la fiesta). Cada uno de nosotros se propuso un objetivo concreto con dichas Katas:

* Julio pretende mejorar su rapidez de desarrollo en Eclipse, aprendiendo teclas rápidas y trucos del IDE

* Pedro se propuso aprender emacs y mejorar su programación en este entorno (¡¡y vaya si lo está haciendo!! Ayer me enseñó unas cosas espectaculares, pero creo que eso se merece otro post)

* Yo, por otro lado, me propuse aprender Vim.

Y todos haríamos la Kata en un lenguaje diferente al que estamos habituados, en este caso, Python.

Cada semana elegíamos una Kata del repositorio de 12meses12katas y durante esa semana trabajábamos durante 25 minutos en esa Kata. Una vez pasado el tiempo, mostrábamos a los compañeros el código realizado y lo comentábamos entre todos. Al día siguiente empezaríamos de nuevo, desde cero.

Hace poco, cambiamos las reglas del juego. Ahora, lo que pretendíamos hacer es escoger una Kata y hacerla durante un mes. La primera semana la haríamos normalmente pero el resto de las semanas y hasta que acabase el mes nos pondríamos limitaciones, para explorar otras formas de resolver el problema y cambiar la forma de pensar. Se nos ocurrieron cosas como:

* Hacer la Kata solo con objetos, nada de primitivos. Encapsulamiento máximo

* Hacer la Kata en modo spaghetti-code. Nada de refactors

(Llevamos poco tiempo haciendo esto, así que solo se nos han ocurrido estas restricciones).

No puedo hablar por mis compañeros, pero creo que en general es una muy buena práctica. No solo mejoras en rapidez a la hora de desarrollar en un lenguaje en concreto si no que además, en nuestro caso, estamos aprendiendo otras herramientas de trabajo. 25 minutos al día, cada día. Es poco tiempo y aporta mucho.

 

Resumen del Global Day of Code Retreat en Aragón

El resumen es sencillo: lo pasamos muy bien.

Es toda una satisfacción ver como la gente responde ante eventos de estas características, y se puede juntar a 3o personas con ganas de aprender un sábado entero. Sebastián fue el maestro de ceremonias perfecto, proponiendo distintos retos cada vez más complejos e imaginativos. Creo que el que más gustó fue lo de hacer ping-pong programming en silencio.

También fue divertido contar con las dos programadoras más jóvenes de todas las localizaciones de este Global Day of Code Retreat y ver cómo alternan los pomodoros con el juego de la goma.

Os dejo un par de fotos del evento.

Hasta la próxima!

Aprendiendo a usar el NDK (Parte I)

En Frogtek, últimamente, hemos estado usando la NDK para poder dar a nuestro querido tiendatek una funcionalidad muy especial.
Queremos compartir con vosotros toda nuestra aventura y para eso vamos a comenzar desde lo más básico (NDK Hello World), terminando con algo realmente mágico (que no majico) y anfibio.

La ndk es un conjunto de herramientas que nos permite construir librerías compartidas para poder llamar desde Java a código nativo.
Las instrucciones nativas se ejecutan sin pasar por la máquina virtual. Por eso, una de las razones por las cuales se escribe código en la ndk es el rendimiento.
En nuestro caso la elección de la ndk viene dada por la necesidad de cargar librerías que no podemos utilizar directamente en Java. Realmente podemos programar una aplicación 100% nativa. Es decir: incluyendo actividades codificadas completamente en C.

Para realizar esta tarea, la gente de Google usa JNI (Java Native Interface)JNI es una interfaz que nos permite hacer llamadas a código escrito en C desde Java mediante un sencillo sistema de nombrado de los métodos.
Eso sí: debemos tener cuidado con la gestión de memoria que hace JNI; pero de ello hablaremos en próximos posts.

Vayamos al grano. Debemos descargar el conjunto de herramientas que provee Android desde aquí. Después, debemos seguir estas instrucciones:

Creamos un proyecto Android normal, creando un layout básico con un botón (el que hará la llamada al código nativo). 

En la carpeta raíz del proyecto creamos una carpeta llamada jni, que incluirá dos ficheros llamados Android.mk (el makefile, con la A en mayúscula). Este fichero contiene las instrucciones para construir el código nativo.

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE:= ndksample
LOCAL_SRC_FILES:= ndksample.c

include $(BUILD_SHARED_LIBRARY)

Seguidamente, crear otro fichero que nosotros hemos llamado ndksample.c (fichero que contendrá las funciones nativas). 

#include 
#include 

jstring Java_org_frogtek_ndksample_Main_getStringFromNDK(JNIEnv* env, jobject this)
{
	return (*env)->NewStringUTF(env, "Croak!!");
}

Ahora hay que compilar dicho fichero c para construir la librería que será cargada desde Java. Para ellos se utiliza la herramienta nkd-build que está en la carpeta de la ndk que anteriormente descargamos, ejecutando este comando:

./ndk-buil -C /ruta/a/nuestro/proyecto

Ha de ser la ruta raíz del proyecto. Este comando terminará con una linea similar a

libndksample.so => libs/armeabi/libndksample.so

Esto quiere decir que todo ha ido bien y que nos ha generado la librería, copiándola al sitio correcto dentro de nuestro proyecto. Si hacemos un refresh en Eclipse observaremos la presencia de dicho fichero.

Una vez que tenemos la librería compilada y generada, podemos llamarla desde Java. Para este cometido, lo primero que tenemos que hacer es cargar dicha librería usando el siguiente método de la clase System:

static {
        System.loadLibrary("ndksample");
}

Esta llamada hay que hacerla de manera estática, dentro de la clase que hará uso de la función o funciones de C. Nótese que el nombre que ponemos ha de ser el que hemos puesto en LOCAL_MODULE en el Android.mk

También tenemos que definir el método nativo para poder llamarlo desde Java. Lo haremos de la siguiente manera:

 public native String getStringFromNDK();

Tenemos que notar que dicho método ha de corresponder con la firma del que definimos en el código c, y no solo eso, también ha de coincidir el paquete y la clase que contienen esta llamada con la que hemos escrito en la firma del método de c.

Ahora solo nos queda llamarlo para poder ver que todo funciona:

 Toast.makeText(Main.this, getStringFromNDK(), Toast.LENGTH_LONG).show();

Esto ha sido todo para nuestro primer post de una serie en la que hablaremos sobre la NDK. Y recordad, pequeños developers: lo nativo mola. Podéis descargar el proyecto desde aquí.

Antiguas entradas