chernando

PHP, PEAR y PHPUnit para Yii en Mac OS X Lion

2011-10-16T17:22:00+02:00

He tenido que montar un entorno de desarrollo para Yii, un framework de PHP, en mi Mac OS X Lion. Como he tenido que hacer varios apaños he recopilado todos los ajustes en esta entrada.

Antes de nada enumero las versiones del software utilizadas:

Mac OS X 10.7.2
PHP 5.3.6
PEAR 1.9.4
PHPUnit 3.5.15
Selenium Server 2.8.0
Yii 1.1.8
Firefox 7.0.1

La mayoría de las acciones que comento han de realizarse con permisos de administrador.

Activar el servidor web con PHP

Mac OS X Lion incluye Apache con soporte para PHP. Sin embargo es necesario activarlo. Para ello en /etc/apache2/httpd.conf descomentamos:

LoadModule php5_module libexec/apache2/libphp5.so

Y en /etc copiamos el fichero de configuración de fábrica:

# cp /etc/php.ini.default /etc/php.ini

Nota: personalmente prefiero que mis entornos de desarrollo y pruebas sean lo más privados posibles. Por ello modifico el Listen de /etc/apache2/httpd.conf a

Listen 127.0.0.1:80

Solamente resta activar el servidor web desde System Preferences / Sharing / Web Sharing.

El directorio que se publica como página principal está ubicado en /Library/WebServer/Documents/ podemos utilizar directamente esta carpeta o bien utilizar carpetas personales ( http://localhost/~usuario/ ). La opción de carpetas personales busca el directorio Sites en el home del usuario, que se puede crear a partir del cuadro de configuración anterior.

Para probar que todo está funcionando lo más recomendable es publicar un fichero .php con un getinfo():

<?php
phpinfo();
?>

Instalar PEAR y PHPUnit

En las versiones anteriores de Mac OS X PEAR está directamente instalado, en Lion es necesario hacer un paso previo:

# php /usr/lib/php/install-pear-nozlib.phar

Con esto ya tenemos PEAR instalado. Actualizamos:

# pear upgrade-all

configuramos el autodiscover (para hacernos las cosas más fáciles) e instalamos PHPUnit:

# pear config-set auto_discover 1
# pear install pear.phpunit.de/PHPUnit

Solamente nos falta un detalle más, añadir el software instalado por PEAR a la configuración de PHP. Añadimos al /etc/php.ini:

include_path = "/usr/lib/php/pear/"

Para comprobar que todo va bien comprobamos la versión de PHPUnit

$ phpunit --version

Montar y ejecutar las pruebas de un proyecto Yii

A partir de aquí lidiaremos con los problemas que surgen con Yii. Primero nos descargamos Yii y creamos un proyecto de prueba:

$ yii/framework/yiic webapp demo

Problema con date.timezone

Al acceder a la demo puede que nos muestre un mensaje de error como el siguiente:

It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function.

La solución más sencilla es configurar en /etc/php.ini el timezone, por ejemplo:

date.timezone = "Europe/Madrid"

Problema con Selenium, arrancar Firefox

Configuramos la URL para las pruebas en el fichero protected/tests/WebTestCase.php:

define('TEST_BASE_URL','http://localhost/~chernando/demo/index-test.php/');

Descargamos Selenium y lo dejamos ejecutando:

$ java -jar selenium-server-standalone-2.8.0.jar

e intentamos lanzar las pruebas funcionales del proyecto yii:

$ cd demo/protected/tests/
$ phpunit functional/SiteTest.php

Lo más probable es que falle el lanzamiento de iexplorer (bastante razonable en Mac OS X ;) ) o que no encuentre firefox-bin ya que no está en el path. Para solucionarlos editamos protected/tests/phpunit.xml, eliminamos:

<browser name="Internet Explorer" browser="*iexplore" />

y modificamos la entrada del Firefox a nuestro, en mi caso es el siguiente:

<browser name="Firefox" browser="*firefox /Users/chernando/Applications/Firefox.app/Contents/MacOS/firefox-bin" />

Con esto podremos ejecutar las pruebas funcionales.

Problema con Selenium, fallan los test

Después de llegar hasta aquí me sorprendió bastante que de los tres tests que vienen de fábrica fallaran dos ;) Concretamente estos dos fallos:

Body cannot be blank.

Failed asserting that <boolean:false> is true.

Password cannot be blank.

Failed asserting that <boolean:false> is true.

Por suerte es un problema conocido y ya está corregido en el repositorio.

El problema es que no se espera a que se ejecuten las validaciones con JavaScript. El parche publicado corrige un par de líneas en el fichero protected/tests/functional/SiteTest.php que cambia los dos assert que fallan por waitFor, consiguiendo el comportamiento esperado.

Homebrew, gestión de paquetes en Mac OS X

2011-09-22T15:15:00+02:00

Homebrew es un sistema de gestión de paquetes de software para Mac OS X como podría ser un apt en sistemas GNU/Linux pero sin distribución de paquetes precompilados.

Gestión de paquetes en Mac OS X

Apple propone el App Store como sistema para obtener software y mantenerlo actualizado. Evidentemente solo las aplicaciones publicadas en el Apple Store pueden ser mantenidas de esta manera. Y aún así la oferta es bastante limitada si nos fijamos en software Unix.

Otras opciones disponibles son MacPorts o Fink. Todos ellas tienen un planteamiento parecido y diferente al mismo tiempo. MacPorts y Fink plantean mantener todo el software a parte de la base de Mac OS X mientras que Homebrew prefiere utilizar al máximo la base propuesta por el sistema y construir únicamente lo que falte.

Este planteamiento tiene sus ventajas y sus inconvenientes:

Al necesitar menos dependencias externas es más rápido.
Al utilizar las dependencias del sistema las cosas se pueden romper cuando el sistema las actualice.

Por otro lado MacPorts y Fink, aunque más laboriosos tienen un entorno más controlado y por tanto más estable.

En resumen, depende de las necesidades de cada uno. En este artículo veremos el uso de habitual de Homebrew que probablemente sea el más ligero para empezar a probar.

Requisitos

Necesitamos el entorno de compilación de Mac OS X. Aunque algunas utilidades vienen ya instaladas de fábrica en el sistema, es recomendable (y en algunos casos indispensable) instalar Xcode. Lo podemos encontrar en el App Store.

Instalación de Homebrew

Desde la web oficial podemos acceder a la guía de instalación. En la práctica se reduce a ejecutar (a fecha de este artículo):

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

La instalación se realiza en /usr/local por lo que o bien lo ejecutamos como administrador o bien nos damos de permisos para escribir en ese directorio.

Actualizar el listado de fórmulas

Homebrew utiliza el concepto de fórmula. Este concepto transmite la idea de cómo se obtiene un programa, es decir, sus dependencias y sus pasos de compilación.

El listado de fórmulas se mantiene en los repositorios de GitHub. Esto nos permite crear forks del proyecto, añadir nuestras fórmulas y demás. Veamos cómo se actualiza el listado:

$ brew update
remote: Counting objects: 141, done.
remote: Compressing objects: 100% (63/63), done.
remote: Total 122 (delta 93), reused 88 (delta 59)
Receiving objects: 100% (122/122), 13.71 KiB, done.
Resolving deltas: 100% (93/93), completed with 18 local objects.
From http://github.com/mxcl/homebrew
   f34cda7..09ad71b  master     -> origin/master
Updated Homebrew from f34cda74 to 09ad71bd.
[...]

Es la salida típica de git. A partir de ahí veremos un resumen de las nuevas fórmulas añadidas y de las actualizadas.

Buscar fórmulas

brew search PATRÓN

Mostrar información de una fórmula

Tenemos la opción clásica:

brew info FÓRMULA

y la curiosa opción de visitar la página del proyecto:

brew home FÓRMULA

Instalación de fórmulas

brew install FÓRMULA

Listar fórmulas antiguas

En el proceso de actualización del listado de fórmulas se detectarán nuevas versiones de fórmulas ya instaladas:

brew outdated

Actualización de paquetes

Tenemos dos opciones

brew upgrade

que actualiza todos las fórmulas con nuevas versiones o

brew upgrade FÓRMULA

que actualiza únicamente la fórmula especificada.

Eliminación de versiones antiguas

Una curiosidad de Homebrew es que no desinstala versiones anticuadas para ello usamos:

brew cleanup

Crear nuevas fórmulas

Es bastante sencillo crear una fórmula nueva. Aunque el Formula Cookbook es bastante claro, veremos brevemente los paso principales:

brew create URL (con la URL de la descarga)
Editar el fichero, creado automáticamente, en /usr/local/Library/Formula/FÓRMULA.rb
Añadir las dependencias con depends_on.
Añadir los comandos system necesarios para la compilación
Probar la fórmula con brew install -vd FÓRMULA

Más información

NTP Sincronización de tiempos

2011-09-15T15:15:00+02:00

Uno de los principios que debemos mantener en nuestros equipos es mantenerlos en hora. En algunos es un requisito, por ejemplo sistemas de autenticación dependientes del tiempo, y en otros para mantener la cordura, por ejemplo para realizar un seguimiento de logs en distintas máquinas.

La solución es el uso de NTP (Network Time Protocol) que nos permite sincronizar los relojes de nuestros equipos y mantenerlos en hora con el paso del tiempo. Vamos a ver las configuraciones típicas usando ntpdate y el demonio ntpd.

Pero antes un breve comentario sobre el stratum. El número del stratum nos indica el número de pasos a los que estamos de un reloj atómico (nivel 0). Los relojes atómicos son muy precisos (no como los relojes de cuarzo) pero también muy caros, por lo que es habitual que se utilicen relojes de GPS como origen.

Existen multitud de servidores públicos de NTP. Una iniciativa que mantiene un pool abierto y que además realiza balanceo es NTP pool project. Para este artículo utilizaremos de ejemplo 2.es.pool.ntp.org.

ntpdate, para equipos itinerantes

ntpdate está pensando para utilizarse una sola vez. Lo lanzamos, obtiene el tiempo del servidor remoto y sincroniza la hora local. Por ejemplo:

# ntpdate 2.es.pool.ntp.org
14 Sep 12:18:03 ntpdate[3359]: adjust time server 158.227.98.15 offset 0.000969 sec

El uso más habitual es para equipos portátiles u ordenadores que no tienen conexión permanente a Internet. Los equipos esperan a tener conexión y efectúan la sincronización.

Un error habitual es que el socket esté en uso, normalmente por el demonio ntpd, que exige cerrar primero ntpd y luego lanzar ntpdate:

# ntpdate 2.es.pool.ntp.org
14 Sep 12:21:57 ntpdate[3392]: the NTP socket is in use, exiting

La configuración de ntpdate como servicio es muy sencilla, podemos echar un vistazo en /etc/default/ntpdate (sistemas Debian).

Demonio ntpd, equipos con conexión permanente

Si el equipo está conectado la gran parte del tiempo lo recomendable es utilizar el demonio ntpd. Evidentemente se encargará de mantener el equipo sincronizado con el paso del tiempo.

Existe una diferencia importante entre ntpdate y ntpd. ntpd realiza un ajuste sutil sobre la velocidad del reloj para compensar la deriva natural del reloj (drift). Esto tiene una repercusión: el tiempo es continuo (obviemos cuestiones metafísicas ;) ).

Por ejemplo imaginemos que nuestro equipo está 5 minutos atrasado. ntpd intentará que el reloj “corra” hasta llegar a la sincronización sin saltarse ni un segundo (simplemente “cuenta los segundos más rápido”). ntpdate por otro lado al ver que la diferencia es mayor a medio segundo directamente “saltará” en el tiempo fijando la hora actual inmediatamente.

La práctica recomendada es arrancar el equipo con ntpdate y dejar que el demonio ntpd se haga cargo de mantener la hora.

La configuración es un poco más elaborada, ya que podemos configurarlo como servidor de NTP. El fichero de configuración /etc/ntp.conf está muy bien comentado y básicamente cambiando las directivas server por servidores locales (o del NTP pool project) sería suficiente.

Prestando servicio interno

Si queremos sincronizar varios equipos dentro de nuestra red haremos que un par de equipos se sincronicen con servidores externos y al mismo tiempo presten ese servicio a nivel local. De esta forma, incluso si se cae la conexión, todos los equipos estarán sincronizados contra la misma fuente de referencia. Además es más educado y consume menos recursos :)

Para ello simplemente es necesario revisar las directivas restrict.

Broadcast

La última modalidad es la sincronización por broadcast. En esta configuración un servidor local de NTP emite de forma regular la hora actual, los equipos que escuchen actualizan la hora. Es una configuración muy típica para desplegar equipos con conexión a red como impresoras, cámaras y dispositivos similares.

Para configurar al servidor para que emita hay que hacer uso de la directiva broadcast.

Para hacer que un equipo escuche las emisiones la directiva es broadcastclient.

Más información

Python generators

2011-09-01T15:15:00+02:00

Todos conocemos las listas de Python mientras que sus hermanos los generadores son menos conocidos. Este breve artículo es un recordatorio :-)

El concepto de generador

La idea de los Generators se basa en dos conceptos: los iteradores y la evaluación perezosa.

Python utiliza el concepto de iterador de una forma muy natural, por ejemplo:

for i in elementos:
    print i

Por debajo el intérprete lo que hace es crear un iterador mediante el método iter() y avanzar posiciones con el método next() del iterador devuelto. Cualquier objeto que cubra estos métodos puede ser tratado como un iterador y por tanto trabajar de forma transparente con el resto de la API.

El segundo concepto es la evaluación perezosa (lazy evaluation), que en pocas palabras significa que una expresión se resuelve únicamente cuando se la necesita, no antes.

Uniendo ambos conceptos tenemos el generador: una estructura, sobre la que podemos iterar, cuyos componentes se van obteniendo según se va avanzando.

La diferencia fundamental con la lista es que la lista tiene una evaluación ansiosa/codiciosa (eager evaluation). Esto implica que cuando queremos manejar una lista de 10 elementos la lista necesita disponer de esos 10 elementos en el momento de su declaración. Sin embargo el generador solamente necesita saber cómo generar el siguiente valor por lo que no necesita ni reservar espacio ni conocer a priori ningún elemento.

Declaración de un método generador

Un método que utilice la palabra reservada yield se trata como un generador. yield puede devolver un valor, como si fuera un return (cuidado, return se utiliza para terminar el generador).

Por ejemplo definimos la función naturales() que devuelve un iterador de todos los números naturales:

def naturales():
    n = 1
    while True:
        yield n
        n = n + 1

i = naturales()
print i # <generator object naturales at 0x10f1a3050>
print i.next() # 1
print i.next() # 2

Vemos que la primera ventaja de la evaluación perezosa es que podemos tratar estructuras infinitas.

Emulemos el método enumerate(list) nativo de Python utilizando el generador como una lista (o mejor dicho su iterador):

ls = ['a', 'b', 'c']
print zip(naturales(), ls) # [(1, 'a'), (2, 'b'), (3, 'c')]

Declaración de una expresión generadora

Otra forma de declarar un generador es exactamente igual que una expresión de lista pero con paréntesis. Por ejemplo los números pares:

print [p for p in range(10) if p % 2 == 0] # [0, 2, 4, 6, 8]
print (p for p in range(10) if p % 2 == 0) # <generator object <genexpr> at 0x10f1a3190>

En este caso vemos que la lista está completa mientras que el generador se queda a la espera. A partir de este ejemplo podemos definir otro generador de números naturales pares:

i = (p for p in naturales() if p % 2 == 0)
print i.next() # 2
print i.next() # 4

Es importante encadenar generadores con generadores, en caso contrario la evaluación de la lista obligaría el recorrido completo del generador. Si la estructura fuera infinita, como el ejemplo, provocaría la muerte del intérprete:

[p for p in naturales() if p % 2 == 0]

Conclusiones

Evidentemente utilizar los generadores no es la solución para todos los problemas.

Hay unos escenarios concretos en los que merece la pena considerados:

Estructuras infinitas.
Estructuras que ocupen mucha memoria, reducimos así el espacio de memoria a reservar.
La generación de los elementos es costosa, podemos retrasar su cálculo hasta el último momento.
Sabemos que la estructura no se va a consumir completamente, una mezcla de las dos anteriores.
Cuando trabajamos con otros generadores.

Más información

Servidor de proyectos con Subversion, Trac, Apache (y LDAP)

2008-07-20T13:29:00+02:00

En esta entrada vamos a montar un servidor para la gestión de proyectos. Para ello utilizaremos un sistema de control de versiones (Subversion), un sistema de gestión de incidencias (Trac) y un sistema de autenticación compartido, para ello utilizaremos Apache y alguno de sus métodos de autenticación como por ejemplo LDAP (válido si es necesario utilizar las cuentas de un Directorio Activo).

Aunque existen soluciones más elaboradas y más integradas, como el software de SourceForge.net, este planteamiento permite montar un servidor a medida, pudiendo alterar cualquiera de sus elementos, y en mi opinión más sencillo de mantener.

Nos basaremos en una instalación mínima de Ubuntu Server 8.04 (por lo que no disponemos ni de Subversion 1.5 ni de Trac 0.11) con la idea de montar un servidor preparado para mantener varios proyectos.

Instalación y configuración de Subversion

Para empezar instalaremos subversion, también es recomendable subversion-tools por los scripts adicionales que incorpora, y preparamos un repositorio de prueba:

# apt-get install subversion subversion-tools
# mkdir /srv/svn
# svnadmin create /srv/svn/proyecto

Aprovechamos ahora para crear una estructura básica dentro del repositorio, esto nos servirá en las pruebas para ver si realmente podemos acceder al repositorio:

# svn co file:///srv/svn/proyecto
# svn mkdir proyecto/{branches,tags,trunk}
# svn ci -m 'Estructura Inicial' proyecto

Instalación y configuración de Trac

Instalaremos y configuraremos mínimamente un proyecto de Trac para el repositorio que acabamos de crear:

# apt-get install trac
# mkdir /srv/trac
# trac-admin /srv/trac/proyecto initenv
(Opciones sugeridas)
Path to repository [/path/to/repos]> /srv/svn/proyecto

Es el momento de comprobar que trac y su unión con el repositorio de subversion funcionan correctamente, para ello lanzaremos el servidor incluido en trac:

# tracd -p 80 /srv/trac/proyecto

Abriendo la URL http://localhost:80/ deberíamos ver disponible nuestro proyecto, "My Project", y comprobamos que la función de "Browse Source" funciona correctamente.

Por el momento nada nuevo, paremos tracd y sigamos.

Instalación y configuración de Apache

Optamos por enganchar Trac con mod_python así que lo más sencillo es instalar el paquete de mod_python y que instale apache por sus dependencias:

# apt-get install libapache2-mod-python

Bien, ahora editamos la configuración para que Apache pase las peticiones que vayan a /trac a nuestro conjunto de proyectos en /srv/trac. Editando el fichero /etc/apache2/sites-available/default añadimos antes del cierre de </VirtualHost> lo siguiente:

<Location /trac>
  SetHandler mod_python
  PythonInterpreter main_interpreter
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /srv/trac
  PythonOption TracUriRoot /trac
</Location>

Forzamos la recarga de la configuración de Apache:

# /etc/init.d/apache2 reload

Hacemos una prueba con el navegador en http://localhost/trac/ que debería mostrarnos un error por falta de permisos de escritura. Como vamos a dejar a Apache como gestor de los proyectos es necesario darle los permisos que necesita:

# chown -R www-data.www-data /srv/trac/proyecto

Con esto todo debería funcionar exactamente igual que con la prueba realizada con tracd. Vamos ahora a mostrar el repositorio desde Apache.

Subversion trabaja con Apache haciendo uso de WebDAV así que instalamos el módulo necesario:

# apt-get install libapache2-svn

Añadimos la configuración necesaria en el fichero /etc/apache2/mods-available/dav_svn.conf, podéis descomentar las opciones si os resulta más cómodo. En cualquier caso la configuración debe quedar de la siguiente manera:

<Location /svn>
  DAV svn
  SVNParentPath /srv/svn
</Location>

De nuevo, forzamos la recarga de la configuración de Apache y comprobamos que http://localhost/svn/proyecto muestra el proyecto y que podemos navegar dentro de él. Si probáis http://localhost/svn/ os dará un error, ya que en este caso no existe un listado de proyectos disponibles como hacía Trac.

Igualmente que en Trac, si Apache es el gestor del repositorio es necesario que tenga permisos de escritura. En este caso vamos a ceder completamente el control a Apache:

# chown -R www-data.www-data /srv/svn/proyecto

Ahora mismo disponemos de un sistema completamente funcional en el que no se exige ningún tipo de autenticación. En el caso de Trac no se puede hacer login y en el caso de Subversion ni siquiera se pide. Si queréis verlo en podéis hacer la siguiente prueba:

# svn co http://localhost/svn/proyecto/trunk
# touch trunk/README.txt
# svn add trunk/README.txt
# svn ci -m "Fichero leame" trunk

Si comprobamos el historial, svn log trunk/README.txt, podremos ver que no hay ningún usuario responsable del commit. En ningún momento se nos ha pedido identificarnos, ya que hay permisos de lectura y escritura para todo el mundo, así que podemos bajarnos el contenido del repositorio y los commit son anónimos.

Autenticando usuarios

Empecemos con lo más sencillo, usuarios válidos de un fichero htpasswd, podéis leer algo más en otro de mis artículos sobre ficheros .htpasswd.

# htpasswd -c /etc/apache2/users.conf chernando

Editamos Trac para soportar un login centralizado añadiendo un nuevo location a default:

<Location /trac/*/login>
  AuthType Basic
  AuthName "Trac Projects"
  AuthUserFile /etc/apache2/users.conf
  Require valid-user
</Location>

Forzando la recarga de Apache ya disponemos de la función "login" en Trac. Para el repositorio vamos a dejar el acceso de lectura para todo el mundo y limitar el acceso de escritura a los usuarios registrados añadiendo a la configuración de WebDAV:

AuthType Basic AuthName "Subversion Repository"
AuthUserFile /etc/apache2/users.conf
<LimitExcept GET PROPFIND OPTIONS REPORT>
  Require valid-user
</LimitExcept>

Una vez más recargando Apache ahora podemos bajar y actualizar un repositorio pero necesitaremos identificarnos para subir cambios al repositorio. Probad a añadir un nuevo fichero y comprobaréis que ahora se exige un usuario y password válidos.

Rizando el rizo, autenticando contra un LDAP

En el caso de disponer de un sistema de autenticación centralizada, por ejemplo LDAP o un Directorio Activo con el servicio LDAP activo, podemos delegar toda la carga de la gestión de usuarios dejando nuestro servidor de proyectos completamente "inhabitado".

Para ello lo único que necesitamos es cambiar ambas configuraciones. En primer lugar habilitamos los módulos necesarios:

# a2enmod authnz_ldap
(esto debería habilitar el módulo ldap por dependencias)

Y configuramos ambas secciones de autenticación. Primero eliminamos AuthUserFile que ya no es necesaria y después añadimos:

AuthBasicProvider "ldap"
AuthLDAPURL "ldap://127.0.0.1/dc=chernando,dc=eu?uid?sub?(objectClass=inetOrgPerson)"
authzldapauthoritative Off

Podéis ver más detalles en http://trac.edgewall.org/wiki/TracModPython.

Ampliaciones que pueden hacerse a partir de aquí

En esta entrada he intentado introducir el menor ruido posible, tanto en comandos como software a instalar, por lo que hay ciertas mejoras que se han quedado en el tintero. Por ejemplo:

Configurar Apache para hacer uso de SSL, muy necesario ya que hasta el momento todas las negociaciones con Apache van en texto claro.
Establecer limitaciones en el acceso de los repositorios (y en secciones de los mismos) haciendo uso de authz.
Configurar un sistema de correo, que permita notificar todo tipo de eventos: nuevos tickets, cambios en el repositorio...
Integrar Subversion con Trac, por ejemplo permitir que un commit cierre o añada información a un ticket de Trac.
Utilizar la última versión de Subversion, 1.5, por su mejora en la gestión de merge de ramas.
Utilizar la última versión de Trac, 0.11, por las mejoras en el interfaz y en la gestión del flujo de trabajo asociado a un ticket.
Ampliar el sistema incluyendo otros servicios: listas de correo, servidor de integración continua...

Apache Ant, primeros pasos creando un build.xml

2008-03-02T18:34:00+01:00

Uno de los inconvenientes en la construcción de software con más de dos ficheros (cualquier cosa que se salga de un "Hello world!") es el proceso de compilación: orden de compilación de ficheros, dependencias, rutas de librerías internas, etc... En esta entrada vamos a dar los primeros pasos en una de las soluciones más comunes para proyectos Java: Apache Ant.

Para los impacientes: al final de la entrada encontraréis el build.xml con todo lo explicado que seguramente os sirva tal cuál.

En primer lugar creamos un fichero build.xml en el raíz de nuestro proyecto y definimos su nombre:

<project name="Proyecto">
</project>

Ant, al igual que otras herramientas de construcción, se basa en el concepto de objetivos o targets cuya definición engloba tanto las dependencias previas como los pasos a seguir para conseguirlo.

Vamos a comenzar definiendo un objetivo de preparación llamado init que será el encargado de crear un directorio classes donde guardaremos los ficheros .class resultantes de la compilación y el directorio build para el .*jar* final. Para ello basta incluir dentro de <project> las siguientes líneas:

<target name="init">
    <mkdir dir="classes" />
    <mkdir dir="build" />
</target>

Como podemos ver los objetivos se delimitan con etiquetas <target> y un nombre. Dentro de ellos se enumeran los pasos que se han de seguir para alcanzar el objetivo, en este caso ha de crear directorios.

Si queremos alcanzar el objetivo init basta con realizar:

$ ant init
Buildfile: build.xml

init:
    [mkdir] Created dir: /home/chernando/proyecto/classes
    [mkdir] Created dir: /home/chernando/proyecto/build

BUILD SUCCESSFUL
Total time: 0 seconds

Es hora de compilar nuestro proyecto, vamos a definir el objetivo compile. Ahora bien, la compilación depende de la creación del directorio classes que se realiza objetivo anterior. Con esto en cuenta basta con incluir:

<target name="compile" depends="init">
    <javac srcdir="src" destdir="classes" />
</target>

La dependencia se fija en la declaración del target de tal manera que se garantiza su cumplimiento antes de comenzarla. Nuestro código está en el directorio src y el resultado de la compilación se lleva al directorio classes.

Importante notar que esta vez estamos usando <javac> esto es lo que Ant se denomina tarea. Hay muchas tareas predefinidas, consultad el manual de ant.

Con nuestro proyecto compilado vamos a generar el .*jar* que distribuiremos haciendo uso de un nuevo objetivo llamado build.

<target name="build" depends="compile">
    <jar destfile="build/proyecto.jar" basedir="classes" />
</target>

En este caso dependemos de los frutos de compile y utilizamos la tarea jar que se encarga de empaquetar todo el contenido del directorio classes en el fichero proyecto.jar.

Finalmente incluiremos un nuevo objetivo para limpiar todo el entorno, el objetivo clean:

<target name="clean">
    <delete dir="classes" />
    <delete dir="build" />
</target>

A estas alturas es fácil entender que lo único que realiza es eliminar los directorios de trabajo dejando el entorno limpio del proceso de compilación.

Resumiendo nuestro fichero build.xml es:

 <project name="Proyecto">
        <target name="init">
                <mkdir dir="classes" />
                <mkdir dir="build" />
        </target>
        <target name="compile" depends="init">
                <javac srcdir="src" destdir="classes" />
        </target>
        <target name="build" depends="compile">
                <jar destfile="build/proyecto.jar" basedir="classes" />
        </target>
        <target name="clean">
                <delete dir="classes" />
                <delete dir="build" />
        </target>
</project>

Y hasta aquí este minitutorial sobre el uso de ant :-)

Cifrando una partición con cryptsetup

2007-09-17T18:50:00+02:00

Disponemos de un ordenador portátil (en este caso concreto una Kubuntu Gutsy) con una partición destinada a /home que queremos cifrar.

Esta solución no es de las más seguras, quedando por tratar temas importantes como el cifrado de swap, controlar la integridad del sistema y el correcto manejo de los ficheros temporales.

Los pasos son los siguientes:

Ciframos la partición física con crypsetup y LUKS:

# cryptsetup luksFormat /dev/sda6

Mapeamos lógicamente el dispositivo descifrado:

# cryptsetup luksOpen /dev/sda6 home

Trabajamos como si fuera una partición normal:

# mkfs.ext3 /dev/mapper/home
# mount -t ext3 /dev/mapper/home /home

Para realizar el montaje automático de la partición en el arranque es necesario modificar los ficheros /etc/crypttab y /etc/fstab:

crypttab:

# <target name> <source device>         <key file>      <options>

home    /dev/sda6       none    luks

fstab:

/dev/mapper/home        /home   ext3    defaults        0       2

Con la configuración mostrada se pedirá la contraseña en el momento del arranque.

Podéis encontrar ejemplos más interesantes en la documentación de LUKS o simplemente buscando por Google.

Trac, gestión de proyectos

2007-07-10T19:38:00+02:00

Trac es una herramienta de gestión de proyectos, principalmente de software, que unifica un sistema wiki con un sistema de seguimiento (issue tracking) con claras ventajas a la hora de trabajar con un repositorio de subversion.

Esta entrada constituye una breve guía de iniciación a Trac.

Instalación

Una vez instalado el programa (utilizando el gestor de paquetes según la distribución utilizada) disponemos de varios métodos para ponerlo en funcionamiento: como un CGI, con Apache y mod_python o con el servidor que viene incluido. Para esta guía utilizaré el servidor incluido.

Creación de un nuevo entorno

Haciendo uso de trac-admin podemos crear un nuevo entorno:

$ trac-admin /srv/trac/proyecto initenv

Creating a new Trac environment at /home/chernando/trac/proyecto

Trac will first ask a few questions about your environment
in order to initalize and prepare the project database.

Please enter the name of your project.
This name will be used in page titles and descriptions.

Project Name [My Project]> Proyecto

Please specify the connection string for the database to use.
By default, a local SQLite database is created in the environment
directory. It is also possible to use an already existing
PostgreSQL database (check the Trac documentation for the exact
connection string syntax).

Database connection string [sqlite:db/trac.db]>

Please specify the type of version control system,
By default, it will be svn.

If you don't want to use Trac with version control integration,
choose the default here and don't specify a repository directory.
in the next question.

Repository type [svn]>

Please specify the absolute path to the version control
repository, or leave it blank to use Trac without a repository.
You can also set the repository location later.

Path to repository [/path/to/repos]> /srv/svn/proyecto

Please enter location of Trac page templates.
Default is the location of the site-wide templates installed with Trac.

Templates directory [/usr/share/trac/templates]>
...

Con esto tendremos una mínima configuración funcional de Trac para nuestro proyecto.

Comprobación rápida con el servidor incluido

Para comprobar el aspecto que van teniendo las cosas utilizaremos el servidor incluido en el puerto 8000:

$ tracd -p 8000 /srv/trac/proyecto

Abriendo un navegador en http://localhost:8000/ podremos contemplar el entorno por defecto. Aprovechando el objetivo didáctico de este ejemplo os animo a que juguéis con la wiki y sistema de tickets.

Personalización del entorno

En el fichero proyecto/conf/trac.ini podréis encontrar cosas como [header_logo] que os permitirá cambiar el logotipo o como [project] para fijar el nombre, URLs relacionadas y demás.

Además en el directorio proyecto/templates podéis añadir vuestras propias plantillas que tendrán preferencia sobre las del sistema.

Ajustando detalles sobre nuestro proyecto: componentes e hitos

trac-admin crea una serie de componentes y de hitos genéricos que con toda seguridad no nos servirán para nuestro proyecto. Para gestionar estos detalles utilizaremos trac-admin de nuevo.

$ trac-admin /srv/trac/proyecto

Con esto tendremos una shell interactiva con la que podremos ajustar los detalles que necesitemos. Por ejemplo para cambiar los componentes podemos realizar:

> component list

Name        Owner
--------------------
component1  somebody
component2  somebody

> component rename component1 interfaz
> component chown interfaz ana
> component rename component2 datos
> component chown datos beatriz
> component add nucleo
> component add nucleo carlos
> component list

Name      Owner
-----------------
datos     beatriz
interfaz  ana
nucleo    carlos

Con esto ya tenemos creados 3 componentes (ajustando el responsable de cada componente) que quedarán reflejados en el sistema de tickets. Veamos ahora modificación de los hitos:

> milestone list

Name        Due  Completed
--------------------------
milestone1
milestone2
milestone3
milestone4

Trac [/tmp/trac/proyecto]> milestone rename milestone1 0.1
Trac [/tmp/trac/proyecto]> milestone rename milestone2 0.2
Trac [/tmp/trac/proyecto]> milestone rename milestone3 1.0
Trac [/tmp/trac/proyecto]> milestone rename milestone4 2.0
Trac [/tmp/trac/proyecto]> milestone list

Name  Due  Completed
--------------------
0.1
0.2
1.0
2.0

Ajustemos las fechas de entrega de cada hito:

Trac [/tmp/trac/proyecto]> milestone due 0.1 2007-07-01
Trac [/tmp/trac/proyecto]> milestone due 0.2 2007-09-01
Trac [/tmp/trac/proyecto]> milestone due 1.0 2008-01-01
Trac [/tmp/trac/proyecto]> milestone due 2.0 2009-01-01
Trac [/tmp/trac/proyecto]> milestone list

Name  Due         Completed
---------------------------
0.1   2007-07-01
0.2   2007-09-01
1.0   2008-01-01
2.0   2009-01-01

Una vez completado un hito podremos utilizar el comando milestone completed:

> milestone completed 0.1 now

Podéis curiosear más opciones haciendo uso del comando help dentro de la shell.

CVS: Manejando ramas

2007-03-07T19:32:00+01:00

Hace algunos años publiqué una breve guía práctica de CVS, incompleta. Aprovechando que tengo algo de tiempo he decidido tachar este punto de mi lista de tareas :-)

Creando una nueva rama

Antes de nada hemos de recordar que necesitamos una versión etiquetada, por ejemplo 'v1_2', sobre la que vamos a trabajar. Comenzamos extrayendo la versión a nuestro entorno de trabajo:

$ cvs checkout -d proyecto-1.2 -r v1_2 proyecto``

Procedamos a crear la rama propiamente dicha:

$ cd proyecto-1.2
$ cvs tag -b v1_2-branch``

El nombre de la rama es un gusto personal, yo prefiero añadir -branch aunque he visto -bugfixes o combinaciones de ambos.

Con estos simples pasos ya disponemos de una rama de desarrollo a la que podemos acceder, por ejemplo para hacer un cambio a la rama:

$ pwd  /home/chernando/proyecto
$ cvs up -r v1_2-branch``

Si revisamos el estado de 'main.c' podemos ver que está incluido en una rama:

$ cvs -q status main.c
==================================================================
Working revision:    1.1.2.1 2007-03-07 19:06:39 +0100
Repository revision: 1.1.2.1 /tmp/repositorio/proyecto/main.c,v
Commit Identifier:   QwJwh9fAP56fxb9s
Sticky Tag:          v1_2-branch (branch: 1.1.2)
Sticky Date:         (none)
Sticky Options:      (none)``

Importante fijarse en el cambio en la numeración, a partir de ahora en vez de avanzar con 1.*X*, se avanza con 1.*N*.*X*, siendo N la numeración de la rama.

Mezclando dos ramas

Bien, supongamos que queremos traernos cambios realizados desde una rama,'v1_2-branch', a la principal. Muy fácil, haremos como si forzáramos un cambio de una versión anterior pero especificando la rama en vez de la revisión:

$ cvs update -j v1_2-branch main.c
RCS file: /tmp/repositorio/proyecto/main.c,v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into main.c
$ cvs commit -m 'Cambios desde la rama v1.2' main.c``

Hay un problema: no podemos hacer esta jugada dos veces seguidas sin dar conflictos :-)

Supongamos que queremos volver a traernos un cambio desde la rama 'v1_2-branch' con el comando update. El diferencial de cambios para hacer la mezcla se hace desde la base de la derivación de la rama, si ya hemos aplicado parte de ese diferencial en una actualización anterior provocará irremediablemente un conflicto.

La solución para evitar el engorro de trabajar con conflictos es utilizar una referencia de la rama justo después de traer los cambios. Dos opciones principales:

Etiquetar la rama cada vez que se traen cambios de ellas, 'v1_2- branch-fixes-1'.
Utilizar las nociones de tiempo de CVS, 'v1_2-branch:3 days ago'.

La idea intuitiva es la de señalar en el historial de la rama dos marcas de tiempo, la última que se llevo a la principal y el actual de la rama, y aplicar los cambios que se realizaron entre esos dos instantes en la rama en la principal. Por ejemplo:

$ cvs update -j v1_2-branch-fixes-1 -j v1_2branch``