Sistema de control de versiones distribuido, Git

Para aquellos que trabajan con archivos, normalmente archivos de código fuente de un programa, en grupos de trabajo en el que colaboran varias personas se hace imprescindible trabajar una una herramienta de control de versiones.

Entre las principales ventajas que aporta una herramienta de control de versiones es el disponer de todas las versiones que se han hecho de un archivo, permitir colaborar al equipo de manera ágil haciendo que las modificaciones que realiza cada persona sean fáciles de compartir con el resto y permitir hacer «fotos» del estado de los archivos del proyecto para su posterior consulta o uso.

A día de hoy existen principalmente dos tipos de heramientas según su arquitectura:

- Cliente/Servidor o centralizadas: donde el repositorio que almacena el estado de la herramienta de control de versiones se almacena en un servidor. Ejemplos de herramientas de control de versiones de este tipo son Subversion, CVS, Visual SourceSafe, Team Foundation Server, ...

- Distribuidas: donde cada persona que colabora en el proyecto posee una copia completa de todo el respositorio de versiones. Las herramientas de este tipo se están adoptando rápidamente por muchos proyectos de software libre por las ventajas que les aportan dada la forma en la que se colabora en ellos. Ejemplos de este tipo son Git, Bazaar, Mercurial, ...

La ventajas de un sistema de control de versiones sobre uno C/S son principalmente que no hay un único punto de fallo (el servidor) y que en algunos como en el caso de Git se puede seguir trabajando y haciendo commits, branches, etc... sin tener que estar conectado a la red o internet. Ejemplos de proyectos que usan Git son: Linux Kernel,Gnome, Qt, Android, Debian, ...

Una vez conocidas algunas de las ventajas, pero importantes, que nos puede aportar trabajar con un sistema de control de versiones distribuido vamos a ver los comandos básicos de Git que hay que conocer para realizar el trabajo diario y como integrar el enotorno de desarrollo eclipse con esta herramienta de control de versiones para un desarrollo más agil.

Creación del repositorio

$ git init

Añadiendo archivos

$ git add *.java

Haciendo commit

$ git commit -m 'initial project version'

Creando branches

$ git branch test

Cambiando de branch de trabajo

$ git checkout test

Haciendo merges de branches

$ git checkout master
$ git merge test

Obteniendo cambios de un reposotorio remoto

$ git fetch [remote-name]

Compartiendo cambios a un respositorio remoto

$ git push origin master

Integración con eclipse

Para eclipse está disponible el plugin egit que permite trabajar con Git sin salir del propio entorno y sin tener que usar la linea de comandos. La instalación del plugin se hace mediante un «update site», para ello vamos a Help > Install New Software e introducimos en el campo Work With el update site del plugin, que es: http://download.eclipse.org/egit/updates. Seleccionamos las opciones de las siguientes capturas de pantallas y finalmente reiniciamos. Una vez reiniciado veremos que en la opción Team > Share project ahora podemos conectarnos con un repositorio Git. Seleccionamos la opción Git y pulsamos la opción crear repositorio. Ya tenemos el proyecto en un repositorio Git ahora nos queda ir añadiendo los archivos y haciendo commits de ellos.

Enlaces:
Web de Git
Pro Git (libro)
Everyday GIT With 20 Commands Or So
GitHub, repositorio Git para proyectos

Hola mundo con Apache Tapestry (5.1) en Google App Engine

      

Este fin de semana he estado probando el servicio de hosting Google App Engine para aplicaciones web (GAE para los amigos). Y por el momento me ha dejado muy buen sabor de boca ya que he conseguido subir a la nube con este servicio sin excesibas dificultades la aplicación Hola Mundo con Tapestry 5.1 que hice en un post anterior.

Pero antes de ver el ejemplo vamos a hablar de las principales caracteristicas de este servicio. Dado que es un servicio de hosting lo principal que hay que tener en cuenta es que no estamos trabajando sobre un servidor propio sino que lo hacemos sobre la infraestructura y servidores que utiliza la propia Google para sus servicios y por tanto no podemos hacer cualquier cosa en él sino que nos tenemos que limitar a usar las funcionalidades que nos ofrece y dentro de los límites que nos impone el entorno. Pero no nos asustemos, si se puede hacer funcionar un framework como Apache Tapestry dentro de él, que no es un framework internamente sencillo, los límites son bastante amplios y con bastante probabilidad podremos trabajar con el framework o librerías que más nos gusten. También podemos optar por trabajar directamente con Servlets y JSPs si nuestra aplicación es sencilla.

El primer lenguaje soportado en GAE fue Python y posteriormente añadieron soporte para Java que le permite atraer a un mayor número de programadores dado que Java es uno de los lenguajes de programación más extendido en estos días. El soporte de Java no se limita al lenguaje Java unicamente sino que están soportados otros lenguajes que se pueden ejecutar sobre la Java Virtual Machine (JVM) como Scala, Groovy o JRuby.

Las aplicaciones GAE tienen unas cuotas diarias de cantidad de datos de subida y de bajada, de tiempo de CPU, de número de archivos, de tamaño de datos almacenados en el servicio y algunos otros que no podremos sobrepasar con el servicio gratuito pero que pagando se pueden ampliar (que será la forma en que Google rentabilice el servicio).

La herramienta a través de la cual subiremos la aplicación a GAE es el App Engine SDK que entre otras cosas incluye las librerías que necesitaremos para compilar y un servidor que simula el entorno de la nube y con el cual podremos desarrollar en local.

Para administrar las aplicaciones que subamos, GAE nos proporciona una consola de administración desde la cual podremos ver los recursos que ha consumido cada aplición, peticiones realizadas, trazas, deshabilitar y habilitar la aplicación, borrar versiones, etc... en resumen todo lo que necesitaremos a lo largo de la vida de la aplicación.

Los servicios que proporciona el entorno a las aplicaciones son por ahora:
- Memcache: servicio de cache en memoria para acceso rápido a la información.
- Extracción de URL: para hacer peticiones mediante HTTP o HTTPS.
- Correo: para enviar correos electrónicos desde la aplicación.
- Imágenes: para manipular imágenes (rotar, escalar, recortar, ...).
- Cuentas de Google: para autenticar a usuarios a través de cuentas de Google.
- Almacenamiento de datos: para almacenar de forma persistente datos en la aplicación y realizar consultas sobre ellos.

Para acabar con esta introducción, la idea de tener un servicio de hosting para aplicaciones Java me parece muy útil ya que muchos proveedores de hosting sólo ofrecen soporte para PHP, Python, ASP o ASP.NET.

Vayamos a ver ahora lo que hay que tener en cuenta para desplegar una aplicación con Apache Tapestry 5.1 en el Google App Engine. Partiendo de la aplicación Hola Mundo que ya tenia desarrollada para hacerla funcionar en Tomcat, he tenido que realizar los siguientes cambios:

- La páginas necesitan la clase Java para ser encontradas por el framework con lo que he añadido la clase con.blogspot.tapestry.helloworld.pages.Index que únicamente contiene:

package com.blogspot.elblogdepicodev.tapestry.helloWorld.pages;

import org.apache.tapestry5.MarkupWriter;

public class Index {

}

- Las librerías que hay que incluir en el directorio WEB-INF/lib de la aplicación web son muchas menos. Las que he necesitado incluir para que funcione el ejemplo son las siguientes:

• appengine-api-1.0-sdk-1.3.4.jar
• commons-codec-1.3.jar
• commons-fileupload-1.2.jar
• commons-io-1.3.jar
• commons-logging-1.1.1.jar
• javassist-3.9.0.GA.jar
• log4j-1.2.14.jar
• slf4j-api-1.5.2.jar
• slf4j-log4j12-1.5.2.jar
• stax-api-1.0.1.jar
• stax2-api-3.0.1.jar
• tapestry-core-5.1.0.5.jar
• tapestry-ioc-5.1.0.5.jar
• tapestry5-annotations-5.1.0.5.jar
• woodstox-core-asl-4.0.3.jar

Aunque posiblemente de estas alguna no sea imprescidible y se pueda quitar y tal vez alguna falte para alguna funcionalidad. Para el ejemplo estas son suficientes.

- Hay que incluir en el directorio WEB-INF el archivo appengine-web.xml (que es el descriptor de la aplicación en GAE) donde indicaremos el identificativo de nuestra aplicación a la que luego accederemos con la URL http://[application-id].appspot.com.

Y eso es todo, lo demás se queda igual que estaba. Para subir la aplicación primero tenemos que generar en nuestro sistema de archivos la estructura de archivos estandar de toda aplicación web Java con nuestra herramienta de contrucción favorita, en el caso de este ejemplo he utilizado Ant para la construcción e Ivy para las dependencias.

$ ./ant.sh resolve package

Y despues copiar manualmente la libreria appengine-api-1.0-sdk-1.3.4.jar del SDK del App Engine al directorio build/war/WEB-INF/lib.

Una vez que tenemos los archivos listos los subimos con el siguiente comando, también nos sirve para cuando queramos subir alguna modificación:

$ $GAE_HOME/bin/appcfg.sh update src/main/webapp/

También la podemos probar en el servidor de pruebas local proporcionado en el SDK:

$ $GAE_HOME/bin/dev_appserver.cmd src/main/webapp/

No pongo capturas de pantalla porque aquí tenéis la aplicación funcionando en el App Engine http://hello-world-tapestry5-gae.appspot.com/.

Espero que alguno se anime a probar y usar este framework  o le sirva de utilidad estas entradas que estoy publicando sobre Apache Tapestry.

Enlaces:
Documentación sobre Apache Tapestry
Codigo fuente ejemplo Hola Mundo con Apache Tapestry 5.1 en Google App Engine

Nota: Para obtener un código fuente más actualizado de esta aplicación a versiones superiores de las librerías de Tapestry, del Google App Engine y utilizando Gradle puedes ver el repositorio en el enlace anterior de Github.

¿Que es el Google App Engine?
Documentación sobre Google App Engine

Diseñador de plantillas de Blogger in Draft

Mediante el diseñador de plantillas de Blogger in Draft se pueden modificar muy fácilmente y sin necesidad de tener ningún conocimiento de HTML o CSS los aspectos más importantes del estilo del blog como la imagen de fondo, tamaños de letras, colores, anchura, disposición en columnas, número de columnas, etc... Este nuevo diseñador da una gran cantidad de nuevas posibilidades de personalización del blog y hacerlo diferente a otros.

Otras mejoras que se incluyen en Blogger in Draft es en la redacción de las entradas dando ahora la posibilidad de subir videos desde el propio equipo así como la incorporación de un diccionario y traductor de varios idiomas. También se incorpora una vista previa mucho más real del resultado final.

Sin embargo, hay que tener en cuenta que al cambiar de plantilla las modificaciones que hayamos hecho en el código fuente de la plantilla para incluir el código de Google Analytics u otras modificaciones se pierden, con lo que es recomendable guardar una copia de la plantilla antes de hacer los cambios.

En el siguiente video se pueden ver las características que incorpora este editor de plantillas.

Sin duda, el editor de Blogger in Draft cumple excelentemente con su propósito, también las características que están disponibles en él son muy interesantes. Aprovechando esta herramienta le he dado un nuevo aspecto al blog.

Enlaces:
Para consultar las novedades que se van incorporando a Blogger in Draft visita su blog.

Cambiar el fondo de escritorio automaticamente en GNOME

¿Te gusta cambiar de fondo de escritorio cada cierto tiempo? Pues si utilizas GNOME hay una forma de hacer que pasado un tiempo el fondo de escritorio cambie automáticamente. Esto es lo que hace el fondo de escritorio Cosmos que vienen por defecto en GNOME. Para ello hay que definir un archivo xml donde indicaremos las imágenes que queremos utilizar como fondo de escritorio y durante cuanto tiempo se visualizará cada una.

El archivo xml contiene dos partes que se van repitiendo sucesivamente. La primera (etiqueta static):

<static>
  <duration>1795.0</duration>
  <file>/usr/share/backgrounds/cosmos/cloud.jpg</file>
</static>

En esta primera parte indicamos la ruta de la imagen que queremos mostrar como fondo de escritorio (de forma absoluta) y durante cuanto tiempo se mostrará (en segundos, en el ejemplo casi 30 minutos).

En la segunda parte (etiqueta transition) indicamos la transición de la imagen actual a la siguiente imagen y cuanto durará el efecto de transición (en segundos). La etiqueta from contiene la ruta de la imagen que se está mostrando actualmente (la ruta de la sección static anterior) y la etiqueta to contiene la siguiente imagen que se utilizará como fondo de escritorio (la ruta de la sección static siguiente).

<transition>
  <duration>5.0</duration>
  <from>/usr/share/backgrounds/cosmos/cloud.jpg</from>    
  <to>/usr/share/backgrounds/cosmos/comet.jpg</to>
</transition>

A continuación se vuelve a repetir una sección static y otra transition hasta llegar al final del archivo. La última sección transition tendrá en su etiqueta to la ruta de la imagen de la primera sección static, de esta forma haremos que cuando se llegue a la última imagen se vuelva a empezar.

El xml que puede servir como base para crear otro «slideshown» de fondos de escritorio es el propio de Cosmos que en Arch Linux se encuentra en /usr/share/backgrounds/cosmos/.

Para instalar una colección de diapositivas hay que seleccionar el archivo xml con la definición de las diapositivas desde el diálogo Cambiar el fondo de escritorio > Preferencias de la apariencia > Añadir....

Sabiendo esto sólo queda buscar un conjunto de fondos de escritorio que nos gusten y crear el xml.