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.

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.

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!

El resultado:

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 <string.h>
#include <jni.h>
 
jstring Java_org_frogtek_ndksample_Main_getStringFromNDK(JNIEnv* env, jobject this)
{
	return (*env)-&gt;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í.

Teaser para el Global Code Retreat de Aragon 2011 from Sebastian Hermida on Vimeo.

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

…
¿No ha quedado claro, verdad? La traducción al cristiano es la siguiente: es un lugar donde gente de distintas empresas puede asistir a trabajar. Algo así como una oficina global, donde poder compartir ideas y promover iniciativas. Podemos llegar con nuestros portátiles, enchufarlos y conectarnos a la wifi existente, ¡y a trabajar!

Pero no solo eso, Scalabble también es un lugar donde poder presentar tu proyecto y potenciar tu empresa a través de distintas iniciativas.

Nosotros, además, no solo hemos utilizado las instalaciones para trabajar, sino que además hemos podido disfrutar (e impartir) charlas y talleres técnicos con gente de los círculos tecnológicos de Aragón.

Hace un año, desde Frogtek reclamábamos un hub de empresas para la zona de Zaragoza. Pues bien, ya lo tenemos aquí