Developing Frogtek

El blog del Departamento de Tecnología

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

Empezando a usar Git

Como alguna vez hemos comentado ya, en Frogtek usamos SVN como gestor de versiones. Hace tiempo valoramos cambiar a un DCVS, Git, Mercurial o similares. Estuvimos estudiando las posibilidades e hicimos varias pruebas de concepto con algunos de ellos. Incluso llegamos a instalar y configurar Gerrit.

Al final no hicimos el cambio. Sabíamos que un cambio de arriba abajo, directo, era inviable. Pero no encontrábamos el momento para ir migrando poco a poco parte los proyectos. Siempre había User Stories que terminar u otras cosas que hacer. En resumen, la idea se quedo en eso, una idea.

Pero hace menos de un mes, por culpa de la gente de Cachirulo Valley y gracias a @leptom, la idea resurgió.  Esta vez, de forma distinta. Una aproximación más llevadera y tranquila. En vez de modificar los proyectos, ¡¡decidimos modificar a los developers!!

Gracias a que Git dispone de un módulo que permite comunicar un repositorio Git y uno SVN , dos developers han empezado a trabajar con Git en su ordenador. Sufriendo las maldades múltiples de dicho gestor de versiones del demonio, por mucho que diga Linus que no.

La idea es ir migrando todos los clientes poco a poco. De esta forma los developers se irán familiarizando poco a poco con Git, aprendiendo sus peculiaridades y compartiendo su conocimiento. Y cuando estemos todos ya trabajando con Git en local daremos el paso final, y cambiaremos el servidor central de SVN a lo que nos apetezca o nos beneficie más.

Os iremos contando qué tal va nuestra experiencia.

 

 

 

Drive, de Daniel H. Pink

Drive book

Increíble libro que ahonda en el “sistema operativo” que nos conduce. Planteando lo anticuado que se está quedando el sistema tradicional de motivación del “palo y las zanahorias” del Siglo XX con respecto al nuevo sistema del Siglo XXI, donde la motivación se basa en factores no tan extrínsecos y más intrínsecos como la autonomía, el propósito y la maestría.

Conforme iba leyendo me ha encantado ver que en nuestra empresa mucho de estos conceptos ya se están aplicando en mayor o menor medida. Y me encanta poder disfrutar de un ambiente tan positivo para crecer como persona y profesional.

Mucho de lo explicado en el libro me sonaba ya. O lo había comentado de una forma u otra con los amigos… Pero no es lo mismo hablarlo, o intuir un concepto que leer las teorías, las explicaciones, todo. He salido con muchas ideas nuevas para auto motivarme. Un libro que vale la pena mucho leerse, desde mi punto de vista.

Para aquellos más vagos, os dejo un vídeo que resume parte de sus teorías de una forma graciosa e interesante. Además también esta disponible la Ted Talk que dio Daniel Pink en 2009.

 

¿Por qué usar Maven?

A raíz de mi grata visita a PocketWidget, en nuestro Desk-Surfing más reciente, he revisado la configuración de Maven que nos permite construir nuestros entregables.

Al volver sobre ella con Francho, repasarla y volver a aplicarla en otros proyectos, me he dado cuenta de lo potente que es y lo difícil que sería la vida sin ella.

Aparte de todas las bondades que su propia página web resalta, personalmente, me quedo con dos de ellas.

  • La herencia entre los archivos de configuración. Permitiendo eliminar duplicidades en las configuraciones y facilitando la configuración de multiples proyectos similares partiendo de una configuración padre-base.
  • Su extensibilidad mediante plugins. Los hay de todos los tipos y si no encuentras uno que se cuadre a tus necesidades, puedes desarrollarlo y usarlo fácilmente. Nosotros el que más usamos es el de Android. No ha estado siempre a la última, pero la comunidad que hay detrás es impresionante y en su última versión beta (2.9) ya soporta los Library Projects.

Solo usamos Maven en el entorno de integración continua, porque durante desarrollo con el plugin de Eclipse ADT para Android, no solemos tener problemas. Pero a la hora de automatizar, la elección ha sido clara: Maven sobre Ant.

Odio escribir

De pequeño siempre he odiado tener que escribir. Lengua no era mi asignatura favorita. Y aunque me encanta leer, me cuesta sentarme y escribir algo. Incluso la lista de la compra.

Pensaba que al elegir la programación como destino profesional, me libraba de toda esa parafernalia de la escritura, ortografía y demás. Un if es un if, ¿no?. Y no lleva tilde, que yo sepa.

Pero una vez me uní al equipo de Frogtek, no fue todo como yo esperaba. Obviamente no me dí cuenta al principio, ni creo que hubiera caído en ello, si no hubiera sido por mi manía de leer…

The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas.

How to Write Without Writing

The single most important thing you must do to improve your programming career is improve your ability to communicate.

The single most important thing you must do to improve your programming career

Lo único que intento es que aquellos que nunca se han planteado que deberían mejorar su escritura encuentren aquí algunas ideas que les ayuden a hacerlo. O por lo menos a empezar el camino hacia esa mejora.

Escritura para programadores

Reflexionando sobre estos artículos, me di cuenta de que… ¡Tenían razón! Comunicarse con los compañeros o con el jefe es muy importante en el trabajo diario. Ya sea escribiendo o hablando.

A mí me cuesta mucho expresarme de forma escrita. Además, lo suelo hacer con faltas y de forma no muy clara que digamos. Mis compañeros pueden dar fe de ello.

Así que me he planteado mejorar. ¿Como? Pues para empezar frecuentando más este blog para contar cosas, lo que sea. Y así practicar. Leeré esa serie de posts de gonzalo sobre como mejorar la escritura. Y por supuesto intentaré prestar mucha más atención cuando escribo. ¿Alguna recomendación o truco?

¡Kaizen!

Android y sus Layouts

Imaginad que al realizar una aplicación web compleja, en vez de hacerla para que se vea bien en todos los navegadores, la hacéis solo para una resolución de pantalla concreta y un navegador específico. Sería un infierno tener que repasarla entera, una vez acabada, para que se adapte a cualquier navegador y resolución, ¿verdad?.

Android Layout

Pues algo así nos pasó a nosotros, pero en Android. Parte de culpa tuvimos, he de reconocer, por no ser previsores y tirarnos por el camino fácil. Aunque diré en nuestra defensa que cuando se empezó nuestro producto Android estaba en pañales y no existía tanta tablet y teléfono en el cual ejecutar tu aplicación.

Aquí van pues una serie de recomendaciones. Para que no cometáis los mismos errores que nosotros.

  • Entended cómo funciona el tema de las pantallas en Android, no es lo mismo una densidad que otra, el tamaño de pantalla, etc.
  • No uséis la unidad de medida px. Mejor dp, o sp si son tamaños de texto.
  • Tened claro como elige Android los recursos que ponéis a su disponibilidad.
  • Evitad en toda medida posible usar layouts con medidas absolutas, hacedlos adaptables (fill_parent, wrap_content). Os ahorrareis muchos quebraderos de cabeza.
  • Si no podéis evitarlo y tenéis que usar valores en vuestros layouts. Extraedlos a un xml y definidlos como Dimensions. Así os será más fácil adaptar la aplicación a las distintas configuraciones que queráis soportar, pues con definir el archivo de dimensiones para cada modalidad de recursos os valdrá.
  • Usad el atributo android:drawableTop, android:drawableLeft…, para introducir imágenes en botones. No os pase como a nosotros que o pedíamos el fondo ya con la imagen o introducíamos un elemento adicional, recargando el layout.
  • No os dejéis enamorar por las bondades de los RelativeLayout. No son malos. Pero a veces un LinearLayout con sus pesos puede ser más fácilmente adaptado a varias pantallas.

Y nada más. Si se os ocurre alguna más que nosotros no hemos nombrado, compartidlo con todos!

 

Revisión de código

Code Review

¿Revisar código?

¿Para qué?

¿Lo has probado?

Pues ya está ¿no?

Pues no. O al menos en Frogtek no nos vale. Y se agradece, la verdad. Veamos cómo y cuándo hacemos las revisiones de código.

Actualmente realizamos tres tipos de revisión de código:

  • Revisiones de código de las User Stories. Una vez terminadas y subidas al repositorio se revisan usando ReviewBoard, dando feedback, cuando sea necesario, a través de la herramienta. Dicha revisión se realiza dos veces. La primera por un programador y la segunda, por el tester antes de realizar el testing y verificación de la User Story.
  • Reuniones de revisión de código. Consisten en unas reuniones semanales en las cuales nos juntamos todos a ver, revisar, comentar… una funcionalidad nueva o un refactor especialmente delicado. Cualquier programador puede proponer código para ser revisado y nos animamos unos a los otros a ello.
  • Pair programinng de User Stories o parte de ellas. Aunque lo realizamos menos de lo deseado, lo usamos sobre todo cuando la funcionalidad que programar es complicada o propensa a errores. Nos ha dado muy buenos resultados siempre que lo hemos utilizado.

Solo llevamos alrededor de un año aplicando estás técnicas de manera exhaustiva, pero creo que las mejoras han sido sustanciales en la calidad de nuestro código y de nuestras habilidades.

Personalmente, lo que más me ha gustado es el conocimiento que se adquiere de toda la aplicación gracias a las revisiones. Ya no solo sabes lo que tú has hecho, sino gran parte de lo que el resto ha programado también.

Como nota final, un vídeo gracioso sobre Pair programing. En Inglés, lo siento.

Bloqueo de SVN en caso de build fallida

Hace poco tuvimos una agradable visita aquí en Frogtek. Una de las muchas aportaciones de Emma fue hacernos replantear nuestro sistema de lanzamiento de builds en Jenkins, pasando de uno más pesado en recursos a otro más eficiente. A raíz de dicho cambio hemos aprovechado y mejorado el procedimiento de bloqueo que tenemos configurado en Jenkins y la forma en la que lo realizamos. Vamos a explicarlo para que nos ayudéis a mejorarlo todavía mas.

En sí, el procedimiento consiste en no permitir commits al servidor SVN si hay una build rota. Excepto al usuario que haya provocado dicha rotura. De esta forma nos aseguramos de varias cosas:

  • No se avanza en el desarrollo si el código subido no es de una calidad mínima, pasa los test y se construye correctamente.
  • Los desarrolladores se hacen responsables de los problemas que ellos han generado y los arreglan.
  • Cuando existe un problema en una parte del proyecto, y dicho problema tarda en resolverse, todo el equipo se preocupa por saber qué pasa y ayudar a resolverlo para poder seguir avanzando.

Seguir leyendo

VirtualEnv para Google App Engine en local

Por defecto en Google App Engine , hasta hace bien poco, solo se podía usar hasta la versión 1.1 de Django. Esto generaba problemas si tenías alguna otra aplicación web que requería una versión más reciente de Django, como por ejemplo nuestra herramienta de revisión de código. Obtenías una serie de conflictos que eran una molestia para el desarrollo y uso en local del servidor, impidiendo un desarrollo fluido y una configuración estable.

La solución por la que optamos fue usar virtualenv. Con esta herramienta podríamos separar el entorno de ejecución de Google App Engine, del resto de aplicaciones instaladas, tanto en el servidor de integración continua como en los equipos de los desarrolladores.

Después de consultar varios sitios web al respecto, el proceso de configuración quedo algo así:


aptitude install python-virtualenv python-pip

Para instalar tanto el propio virtualenv como pip, una herramienta para instalar paquetes en dicho entorno.


virtualenv --no-site-packages --python=python2.5 ENV

Para configurar en ENV el entorno. –no-site-packages indica que no herede ningún package de la instalación de la cual se toma python y le indicamos que queremos la versión 2.5 pues GAE se ejecuta en con la 2.5 en los servidores de Google.

pip install -E ENV Django==1.1

Añadimos la versión de Django que utilizar con pip.

Para finalizar ya solo falta copiar la carpeta de Google App Engine dentro de ENV. Activar el entorno utilizando un par de scripts que hay en ENV/bin/ y lanzar el servidor de desarrollo.

Ahora mismo toda esta parafernalia tiene algo menos de sentido pues en la última versión del SDK del GAE han añadido la versión 1.2 de Django. Pero aún así puede ser útil para conseguir un entorno controlado y separado del resto de la máquina. Ya sea un servidor de integración continua o nuestra propia máquina de trabajo.

Aquí huele a cuco (IV)

Bueno, un poco de autocrítica nunca viene mal y en este caso yo soy uno de los culpables de este desaguisado….

public int getVendorsCount() {
	if (this.mDm.openDBConnection()) {
		this.mDbHelper = new VendorsDbAdapter();
		Cursor cursor = this.mDbHelper.getVendorsCount();
		if (cursor != null) {
			cursor.close();
			return cursor.getCount();
		}
		this.mDm.closeDBConnection();
	}
	return 0;
}

Fijaos bien: estamos intentando acceder a un cursor después de cerrarlo….. además solo cerramos la base de datos si el cursor es null… vamos, una joya de código. Gracias a que tenemos test funcionales en Android hemos encontrado semejante esperpento. Ya vamos recuperando poco a poco lo invertido en ellos 🙂 .

Así he dejado el código después del pertinente refactor.

public int getVendorsCount() {
	int vendorsCount = 0;
	if (this.mDm.openDBConnection()) {
		this.mDbHelper = new VendorsDbAdapter();
		Cursor cursor = this.mDbHelper.getVendorsCount();
		if (cursor != null) {
			vendorsCount = cursor.getCount();
			cursor.close();
		}
		this.mDm.closeDBConnection();
	}
	return vendorsCount;
}

¿Bastante mejor no? ¿Alguna sugerencia para mejorarlo todavía más?

Herramientas: Resource filtering en Maven

Nuestro querido servidor de desarrollo es el encargado de generar las versiones de nuestros productos, los publica en la web, nos avisa por e-mail de que se han generado nuevas versiones, etc. Además se encarga de que desde el mismo código salgan dos versiones diferentes de la aplicación. La versión de producción, sólo para clientes finales, y la de pre-producción donde se prueban todas las funcionalidades antes de ser pasadas a producción.

Las diferencias entre ambas versiones son mínimas pero delicadas, así que hace tiempo programamos una serie de bash scripts que hacían los cambios automáticamente en Hudson. Nada elegante pero muy útil para evitar errores al subir archivos de configuración a nuestro sistema de control de versiones.

Hace unos días, a raíz de este post de Francho, Pedro pensó que igual podíamos mejorar dichos scripts para incluir ese proceso de definición en la propia aplicación. Nosotros no usamos Ant a nivel del servidor de integración continua, sino Maven. Me tocó desempolvar el recomendable libro que me dio a conocer Maven y me puse manos a la obra.

Así descubrí el Resource filtering, plugin de Maven que permite filtrar archivos y sustituir variables definidas en el pom.xml (archivo de configuración de Maven). A continuación os muestro lo sencillo que fue deshacerme de tres o cuatro scripts y pasar a definir dicho proceso desde el propio archivo de configuración de Maven.

Para ello en primer lugar se definen las variables.

...

   false
   UA-********
   http://*******/tiendatek/prebuilds/latest.apk
   frogtek

...

Seguir leyendo

Antiguas entradas Recientes entradas