Developing Frogtek

El blog del Departamento de Tecnología

Autor: admin (página 2 de 8)

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

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.

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

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

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.

 

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

Scalabble: hot desking en Zaragoza

Desde hace unos meses, el equipo de Frogtek está asistiendo un día a la semana a las instalaciones de Scalabble, un local de “coworking” para practicar “hot desking”.


¿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í 🙂

Pomodoros de verdad

La última semana tuvimos el placer de acoger en las oficinas de Frogtek al freelance y experto en craftmanship Enrique Comba (@ecomba), el cual trabajó codo con codo con nosotros para ayudarnos a mejorar nuestro proceso.

Siendo un experto en la materia como es él, aprovechamos para preguntarle cómo mejorar nuestros pomodoros. La técnica del pomodoro es un método de timeboxing (administración del tiempo) para realizar tareas en periodos alternos de trabajo exhaustivo y pausas. Nosotros ya habíamos integrado esta técnica a nuestro trabajo habitual, y esto era lo que sabíamos:

  • Cada pomodoro consiste en un periodo de trabajo continuo de 25 minutos.
  • Durante ese tiempo, hay que trabajar concentrándose en la tareaevitando cualquier distracción (correo, twitter, etc.). Algunas distracciones, sin embargo, son inevitables, como otros compañeros preguntando una duda, una llamada al teléfono, etc.
  • Un pomodoro es indivisible (no existe medio pomodoro). Lo utilizamos como unidad atómica de trabajo.
  • Después de cada pomodoro, hay que tomar una pausa breve de 5 minutos.
  • Después de un cierto número de pomodoros (entre 3 y 5 en nuestro caso) hay que tomar un descanso largo, de entre 15 y 25 minutos.
  • Al principio de cada jornada de trabajo, hay que planificar los pomodoros y descansos que se van a realizar.
  • Además hay que estimar cuánto tiempo (medido en pomodoros) va a costar realizar una tarea determinada.

Sin embargo, Enrique nos dio algunos consejos sobre las pausas, que no estabamos aplicando:

  • Es muy importante levantarse del asiento e incluse hacer ejercicios para evitar contracturas.
  • Debe intentar dejarse la mente en blanco. Esto es debido a que nuestro cerebro almacena la información y crea conexiones o momentos de inactividad, como durante el sueño.
  • No vale mirar el correo o twitter. Si es necesario utilizarlo, mejor tomar un pomodoro de “comunicación” de 25 minutos para realizar este tipo de tareas.

Sobre las distracciones:

  • Cualquier distracción (tanto interna como externa) debe anotarse en un papel, indicando su procedencia.
  • Al acabar la jornada, habrá que revisar la lista de distracciones y comprobar si pueden reducirse de alguna manera. En caso contrario, intentar agruparlas dentro de un mismo pomodoro.

Para más información, recomiendo leer este PDF del propio creador de la Técnica Pomodoro, Francesco Cirillo.

Tiendatek y sus amigos los Periféricos

Estoy seguro de que casi todos hemos visto en alguna ocasión un Sistema Punto de Venta (POS) con su correspondiente escáner de códigos de barras, impresión de recibos, pagos con tarjetas y por qué no, un lector de huellas digital. Con la demanda actual del mercado y los avances en tecnología, un POS no tendría sentido sin la ayuda de todos o parte de estos dispositivos. La realidad dicta que no es suficiente con poder registrar una venta sino que hay que hacerlo de la forma más rápida posible, a nadie nos gusta estar esperando en la cola del supermecado, porque además al cliente le gusta tener constancia de lo que ha comprado, a nadie nos gusta que nos engañen.

Tiendatek ha conocido a diferentes amigos conforme ha ido creciendo, apartándose de aquellos que no le convenían y que le retrasaban su aprendizaje. Cuando tan solo iba a la guardería conoció a un pequeño sistema de lectura de códigos de barras a través de la propia cámara del teléfono y cuyo nombre es ZXING. Una tarea que aparentemente puede parecer sencilla, al final resultaba desesperante para el tendero, debido a su baja eficiencia. Enseguida se dio cuenta de que tenía que encontrar a alguien que de verdad estuviese diseñado para ese fin. Así, cuando empezó la primaria conoció a un lector bluetooth llamado CipherLab quién además de bonito era barato. Se podía decir, que hasta el momento, el lector es y ha sido su mejor amigo. De esas relaciones donde nada cambia con el paso de los años.

Ya en la secundaria, Tiendatek y LectorTek, hicieron nuevos amigos. En esta ocasión se trataba de una linda y joven impresora de recibos vía bluetooth. Desde el primer día supo como seducirlos tanto a ellos como a los tenderos pasando por los programadores y el “product owner” de Tiendatek. Apenas han pasado unos meses, pero a simple vista se ve que existe química entre ellos.

 

Todavía les queda mucho camino que recorrer y periféricos que conocer pero ¿por qué no?, ¿veremos algún día a Tiendatek saliendo a bailar con un lector de pagos con tarjeta y/o sistema de identificación por huella digital en el día de su graduación?

Antiguas entradas Recientes entradas