The script creates…

• A new Subversion repository to host the source code of the project.
• A new MySQL database to store the data of the Trac instance.
• A new instance of Trac, linked to the just created Subversion repository, to be used like the project’s portal.
• A configuration file for Apache2 in order to made accesible the Trac repository.

The structure of the new Subversion repository is as follows:

-> branches
-> tags
-> trunk
   -> docs
   -> src

The environment used was the following

• Ubuntu Server 11.04 64 bits
• Apache/2.2.17 (installed from the Ubuntu repositories)
• MySQL Server 5.1.541ub (installed from the Ubuntu repositories)
• Subversion 1.6.12 (installed from the Ubuntu repositories)
• Python 2.7.1+ (installed from the Ubuntu repositories)
• Trac 0.12

TODO

• Implement checking to ensure that the different elements do not exists before trying to create them (for example the Subversion repository, or the MySQL database).
• Implement the installation of the Subversion hooks that ensure that the Trac instance keeps in sync with the Subversion repository

#!/bin/bash

# Author: Jorge Tomé Hernando <jorge@jorgetome.info>
# Date: August 2011
# Version: 1.0
#
# Description
# -----------
# This scripts creates all the environment needed to support
# a new software development project.
#
# It creates a new Subversion repository, a new Trac instance
# (and the associated MySQL database) and a configuration file
# for the Apache2 web server.
#
# It also restart the Apache2 server in order to apply the new
# configuration.
#
# It has been developed and tested in an Ubuntu 11.04 environment.

usage()
{
    cat<<EOF
usage:$0 options

This script creates a new support environment for a software
development project including: Subversion repository and
Trac instance.

Options:
-h Shows this message
-p Name of the project
-u User name of the project's administrator
EOF
}

if [[ $EUID -ne 0 ]]; then
    echo "This script must be run as root" 1>&2
    exit 1
fi

PROJECT_NAME=
PROJECT_ADMIN=

while getopts ":hp:u:" opt; do
    case $opt in
        h)
            usage
            exit 1
            ;;
        p)
            PROJECT_NAME=$OPTARG
            ;;
        u)
            PROJECT_ADMIN=$OPTARG
            ;;
        ?)
            usage
            exit
        ;;
    esac
done

if [ -z $PROJECT_NAME ] || [ -z $PROJECT_ADMIN ]
then
    usage
    exit 1
fi

# Configuration variables
SVN_HOME=/srv/svn
TRAC_HOME=/srv/trac
DB_PREFIX=trac_
DB_USR=MyUserForTrac
DB_PWD=MyPasswordForTheUserForTrac
DB_HOST=localhost
DB_PORT=3306
APACHE_USR=www-data
APACHE_CONF_DIR=/etc/apache2/projects.d

# Utility variables
PROJECT_DIR=`echo ${PROJECT_NAME,,}`
DB_NAME=${DB_PREFIX}${PROJECT_DIR}
SVN_DIR=${SVN_HOME}/${PROJECT_DIR}
TRAC_DIR=${TRAC_HOME}/${PROJECT_DIR}

# First we create the Subversion repository
svnadmin create --fs-type fsfs ${SVN_DIR}
svn mkdir -m "Initialization of the repository" \
--parents \
file://${SVN_DIR}/trunk/docs \
file://${SVN_DIR}/trunk/src \
file://${SVN_DIR}/branches \
file://${SVN_DIR}/tags

# Second we have to create the MySQL database to support Trac
mysql -u root -p <<QUERY_INPUT
CREATE DATABASE ${DB_NAME};
GRANT ALL PRIVILEGES ON ${DB_NAME}.* TO ${DB_USR}@${DB_HOST} IDENTIFIED BY '${DB_PWD}';
QUERY_INPUT

# Third we have to create the Trac instance
trac-admin ${TRAC_DIR} initenv ${PROJECT_NAME} mysql://${DB_USR}:${DB_PWD}@${DB_HOST}:${DB_PORT}/${DB_NAME}
trac-admin ${TRAC_DIR} repository add ${PROJECT_DIR} ${SVN_DIR} svn
trac-admin ${TRAC_DIR} repository resync ${PROJECT_DIR}
trac-admin ${TRAC_DIR} permission add ${PROJECT_ADMIN} TRAC_ADMIN
trac-admin ${TRAC_DIR} deploy ${TRAC_DIR}/deploy

# Fourth we have to create the Apache2 configuration file
cat > ${APACHE_CONF_DIR}/${PROJECT_DIR}.conf <<EOF
WSGIScriptAlias /trac/${PROJECT_DIR} ${TRAC_DIR}/deploy/cgi-bin/trac.wsgi

<Directory ${TRAC_DIR}/deploy/cgi-bin>
    WSGIApplicationGroup %{GLOBAL}
    Order deny,allow
    Allow from all
</Directory>http://www.jorgetome.info/bash-script-to-create-a-full-software-development-environment.html  

<Location "/trac/${PROJECT_DIR}/login">
    AuthType Basic
    AuthName "Trac"
    AuthUserFile /srv/trac/.htpasswd
    Require valid-user
</Location>
EOF

# Last we have to adjust the permissions on the directories and
# restart the web server
chown -R ${APACHE_USR}:${APACHE_USR} ${SVN_DIR} ${TRAC_DIR}
apache2ctl restart

1. KISS (Keep it simple, stupid). Creo que nunca valoraremos lo suficiente el valor de simplificar todo lo posible los sistemas que construimos.
2. No construyas si puedes usar algo que ya existe.
3. Entrega (parte de) el producto cuanto antes a sus usuarios, sigue construyéndolo apoyándote en los comentarios de los usuarios.
4. La interfase del usuario debe ser web, siempre.
5. La interfase del usuario es un animal totalmente distinto. Debe diseñarla y construirla un equipo de especialistas en interfases de usuario y debe estar totalmente desacoplada de la lógica de la aplicación.

¿Qué opináis?.

VMware Converter es una herramienta gratuita de VMware que nos permite convertir máquinas virtuales de unos formatos a otros. Es muy útil en entornos mixtos en los que tienes máquinas en distintos formatos: VMware Server 1.x, VMware Server 2.x, VMware ESX, etc..

Yo ya lo había utilizado en alguna ocasión y había funcionado sin problemas, ahora viene la pesadilla…

Hace unas semanas recibí un disco duro externo que contenía unas máquinas virtuales en formato OVF, después de descubrir qué era el dichoso formato me bajé la última versión del VMware Converter, la 4.0.1, para convertir las máquinas en cuestión a formato VMware Server 1.x, que es el  que utilizamos en nuestros servidores.

Las máquinas eran grandes (relativamente), desde los 40 GB a los 150 GB. No disponía de dicho espacio libre en ninguno de mis ordenadores así que pensé convertir las máquinas desde el disco duro externo en las que las tenía (de 2 TB de tamaño) hacia el mismo disco duro externo ya que tenía más de 1 TB de espacio disponible, vamos, que por espacio no será

Bueno, pues el amigo VMware Converter se empeñaba en decirme que no disponía de espacio suficiente para realizar la conversión. Probé todo lo que se me ocurrió, incluso a cambiar el punto de montaje del disco duro externo ya que contenía un espacio en el nombre y pensé que sería la típica situación en la que el software no “digiere” correctamente ubicaciones con espacios en el nombre. No funcionó.

Lo probé en distintos ordenadores, en distintos sistemas operativos (MS Windows XP Profesional, Ubuntu), con distintas combinaciones de discos (por si acaso al VMware Converter no le gustaba que el origen y el destino estuviesen en un disco externo). No funcionó nada.

En una de las muchas búsquedas  que hice en Google al respecto llegué al blog de Shan Wildermuth en el que hay un artículo comentando distintos problemas que él también ha sufrido con VMware Converter y uno de  ellos el mismo que estaba sufriendo yo. ¡¡Aleluya!!, ¡¡también explicaba el motivo y la solución!!

Bueno, pues en un alarde de calidad en la programación, resulta que el VMware Converter utiliza como directorio temporal para las tareas de conversión, no el directorio temporal que todos los sistemas operativos asignan a los usuarios, sino el directorio desde el que arrancas el puñetero VMware Converter.

Claro, en todas mis pruebas había lanzado el VMware Converter desde el menú, es decir, desde el directorio en el que está instalado el programa, que, para más INRI, en todos los equipos en los que había hecho pruebas no disponía del espacio suficiente (más de 30 GB) para que el VMware Converter pudiera realizar la conversión.

Solución, abrir una consola de comandos, situarse en un disco/directorio en el que haya suficiente espacio libre (yo me ubiqué en el disco duro externo) y desde ahí lanzar el programa. Problema resuelto.

Si a alguno le pilla cerca el programador responsable de tal desaguisado que le de un cate de mi parte

O a su superior que no le dio el tiempo suficiente para probar en condiciones el programa

Una de las cosas que más he apreciado de esta versión 8.10 es la enorme mejora en la gestión de configuraciones con múltiples pantallas. Cuando estoy en la oficina conecto el portátil, que tiene una pantalla que admite una resolución de 1280×600 a un monitor externo de 17 pulgadas que admite una resolución de 1280×1024. Nunca antes de la versión 8.10 había conseguido hacer funcionar esta configuración y ahora lo he podido hacer utilizando la herramienta de “Configuración de los ajustes de la pantalla” que simplemente hay que añadir a alguno de los paneles.

Total, que estoy muy contento con mi actual configuración. Pero el problema es que, de vez en cuando, ocurre algo que estropea esta idílica situación. No sé qué puede ser, pero creo que no está relacionado con ninguna actualización de software. El caso es que ya me ha pasado más de una vez que, de repente, pierdo los efectos de escritorio y al intentar volver a activarlos Ubuntu me informa de que no es posible hacerlo.

Estaba acostumbrado, ante problemas relacionados con la configuración de las X, a acudir a la edición del fichero xorg.conf para revisar a mano la configuración. Pero en la actual versión de Ubuntu/Xorg este fichero apenas contiene lo siguiente:

Section "Device"
Identifier "Configured Video Device"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
SubSection "Display"
Virtual 2560 1031
EndSubSection
EndSection

Como veis, apenas nada que tocar. Lo único que he podido comprobar es que es la inclusión de la subsección…

SubSection "Display"
Virtual 2560 1031
EndSubSection

…la que provoca que Ubuntu empiece a decirme que no puede activar los efectos de escritorio. Pero el caso es que es necesaria para soportar el escritorio virtual que forman los dos monitores conectados.

Hoy, después de que esto me haya pasado varias veces y después de haber buscado por Internet toda información relacionada (mucha gente con el mismo problema) he encontrado esta página en la que se describe una sencilla y curiosa solución.

La solución consiste en añadir (o crear el fichero, ya que en mi caso no existía) al fichero ~/.config/compiz/compiz-manager una línea con el contenido SKIP_CHECKS=yes.

Mano de santo, ha sido crear el fichero con dicha línea, reiniciar las X y de vuelta los efectos con ambos monitores conectados a mi Dell Latitude E5400.

Pero en el planeta en el que vivo, el planeta Internet, en el que, por cierto, no existen los países; se producen noticias de mucho mayor calado, mucho más interesantes sin necesidad de que nadie sufra. Y hoy es uno de esos días en los que se produce no una gran bomba informativa, sino dos.

Sun Microsystems ha anunciado la adquisición de MySQL por mil millones de dólares y Oracle ha anunciado la adquisición de BEA Systems por 7.500 8.500 millones de dólares.

Me enteré primero de la adquisición de MySQL por Sun Microsystems. Me lo comentó mi compañero de trabajo Félix Velasco (saluda Félix, a ver cuando creas tu propio blog para que pueda enlazarte). La noticia es importante y habrá mucho debate acerca del impacto que en el mundo Open Source va a tener esta adquisición. ¿Es buena o es mala para el mundo Open Source?. Yo ahora mismo me inclino a pensar que es buena. Las acciones de Sun Microsystems en los últimos meses, la más importante liberando el código de Java con una licencia Open Source, me hacen pensar que esta adquisición podría permitir eliminar algunas sombras que siempre han acompañado a MySQL (léase licenciamiento dual) y convertir realmente MySQL en un proyecto gestionado y construido por una comunidad abierta y no por una empresa privada como hasta ahora. Ya se verá.

Pero hete ahí que cuando en casa me pongo a leer los feeds para terminar de enterarme de la noticia me encuentro en Barrapunto con el otro bombazo. Oracle anuncia hoy mismo la adquisición de BEA Systems por 7.500 millones de dólares. Ésto si que tiene tela y requerirá mucha reflexión para ir vislumbrando el impacto que puede llegar a tener, esta vez no en el mundo Open Source, sino en la Industria (escrito así, con mayúscula) de las Tecnologías de la Información.

Oracle lleva muchos años intentando posicionarse en segmentos distintos al de puro proveedor de un motor de base de datos. No es el primer intento (ni el segundo) que hace de incorporar a su catálogo de productos un servidor de aplicaciones J2EE competitivo, hasta ahora nunca lo había conseguido y el resultado ha sido que, dejando de lado las alternativas Open Source, el mercado se había decantado por la dualidad IBM WebSphere versus BEA WebLogic.

Esta será la tercera vez que Oracle adquiere un servidor de aplicaciones J2EE. En las dos ocasiones anteriores los servidores adquiridos eran buenos productos con mucho potencial pero la, a mi juicio, equivocada estrategia de Oracle los hundió. A lo mejor a la tercera va la vencida.

Tengo la impresión de que los empleados de BEA Systems no deben de estar dando saltos de alegría con la noticia. No creo tampoco que los clientes de BEA Systems estén contentos con las perspectivas. Sinceramente creo que los únicos que posiblemente estén emborrachándose con champán ahora mismo sean los chicos del gigante azul y los del sombrero rojo. Los apaches lo estarán celebrando bebiendo agua de fuego y fumando alucinógenos en las pipas de la paz.

El script es muy simplón y realmente habría mejores formas de hacerlo, pero el caso es que necesitaba contar el número de sesiones CVS y hacerlo con un shell script no me ha llevado más de 2 minutos.

#!/bin/sh
#
# File     : CountCVSConnections.sh
# Version  : 1.0
# Date     : November 22th 2007
# Author   : Jorge Tomé Hernando <jorge@jorgetome.info>
#
# Description
# ===========
#
# Connect to a host via SNMP and count the number
# of TCP sessions in state "established" over the
# 2401 port.
#
# Usage
# =====
# CountCVSConnections [COMMUNITY] [HOST]</pre>
<pre>snmpwalk -Os -c $1 -v 1 $2 .1.3.6.1.2.1.6.13.1.1 | \\  # Get the full list of TCP connections
grep -e ".2401..*established" | \\      # Filter the established connections over 2401 port (CVS)
wc -l | \\      # Count the number of connections
awk '{printf "Active CVS connections: " int($1)}'     # Print the result

Siempre reacciono de la misma forma, preguntando cuáles son (cifras) esos enormes volúmenes y muy a menudo resulta que la respuesta no está muy a mano. La enormidad es una sensación que no se concreta en cifras.

Y entonces llego a artículos como éste (la fuente original es ésta) en el que se informa de que eBay atiende mas de 5.700 millones de invocaciones mensuales a su API y pienso – esto si que es volumen y no los que gastamos por aquí –

En este otro artículo podéis encontrar información acerca de cómo eBay es capaz de hacer esto. Para los impacientes, el stack tecnológico es Java, IBM WebSphere Application Server y Oracle Enterprise Server; nada demasiado cool . Lo cool está en la forma de usarlo, lo estrictos que son en el cumplimiento de los principios de diseño. Algunas pinceladas:

• La base de datos es el cuello de botella, hay que llevarse todo el proceso posible a las capas superiores (incluso joins).
• La estrategia de escalado es horizontal.
• El desacoplamiento es vital. Integración asíncrona entre los componentes.
• Hay que virtualizar todos los componentes posibles. Reduce las dependencias de los elementos físicos y facilita el despliegue y la evolución de la plataforma.

En este documento los autores definen el concepto de RAIDb como una extensión del concepto de RAID (Redundant Array of Inexpensive Disks) aplicado a los repositorios de datos y presentan la implementación que han realizado de su concepto bajo el nombre de C-JDBC.

El problema a resolver es la escalabilidad de las bases de datos y la propuesta es hacerlo de forma horizontal utilizando hardware (y software) de bajo coste.

Tradicionalmente se ha avanzado mucho en la escalabilidad de las capas superiores de una arquitectura de sistemas de información moderna (multi-capa). Así el escalado de la capa de presentación (servidores web) y de la capa de aplicaciones/procesos (servidores de aplicaciones) está bastante bien resuelta. Mientras que la escalabilidad de la capa de datos normalmente se aborda mediante el escalado vertical (agrupaciones con un número de nodos pequeño, típicamente 2, y muy potentes).

Así es “fácil” encontrar instalaciones en las que existen centenares de servidores web atendiendo la presentación, decenas de servidores de aplicaciones ejecutando la aplicación/los procesos y un macro-cluster de base de datos soportando todo eso.

Ese macro-cluster acaba siendo la hardware más potente del fabricante de turno (IBM pSeries, Sun Fire Enterprise Server 25K, HP Superdome, etc.) con decenas de procesadores (sino cientos), cantidades ingentes de memoria y de almacenamiento. En estos clusters casi siempre y por definición, la mitad de la capacidad de proceso está desperdiciada. En un cluster de 2 nodos cada uno de los nodos tiene que ser capaz de asumir la carga completa del cluster ante la caída del otro nodo. Esto significa que se intenta mantener la carga del cluster de forma que ninguno de sus nodos supere el 50% de carga y, por lo tanto, el otro 50% de su capacidad no se usa en condiciones normales.

El planteamiento de RAIDb es llevar el concepto de escalabilidad horizontal a la capa de datos. Permitir el escalado horizontal (añadir más servidores, más pequeños, más baratos) de una forma sencilla, eficaz y económica. RAIDb viene a cubrir las necesidades de escalabilidad y de tolerancia a fallos de la capa de datos.

Al igual que en el caso de RAID, los creadores de RAIDb identifican tres tipos de agrupamiento: RAIDb-0, RAIDb-1 y RAIDb-2. RAIDb-0 es un modelo en el que las bases de datos se particionan pero no se distribuyen (no hay redundancia), RAIDb-1 implica un mirrorring completo de las bases de datos (redundancia completa); mientras que RAIDb-2 define un escenario de replicación incompleta de las bases de datos.

Adicionalmente los autores identifican distintos subtipos: RAIDb-1ec, RAIDb-2ec

En el documento mencionado no solo se explica y define todo lo dicho hasta ahora, sino que también recoge información acerca de un conjunto de benchmarks realizados por los autores (concretamente han utilizado el benchmark TCP-W) y que ilustran las capacidades de escalado de las distintas alternativas dependiendo del número de nodos en el cluster.

Como os decía antes os recomiendo la lectura del documento original.

Google Desktop es una aplicación que he echado de menos desde que hace ya más de 6 meses me pasé definitivamente en el trabajo a Ubuntu. Desde entonces solo he arrancado MS Windows XP en una o dos ocasiones.

Ubuntu incluye Beagle al que, he de ser sincero, no he dado muchas oportunidades. No recuerdo haberlo usado nunca y cuando he visto cómo se usa no me parece tan sencillo y potente como Google Desktop. Además cuando monitorizo cómo se está utilizando la CPU de mi portátil Beagle siempre aparece muy arriba en la lista.

Voy a bajarme Google Desktop para Linux y darle una oportunidad, a poco bien que lo haga sustituirá a Beagle en mi escritorio. Ya os contaré.

Actualización. Ya me lo he bajado e instalado y ya está funcionando en mi escritorio. La instalación (me he bajado el deb) no ha supuesto ningún problema e inmediatamente tenía disponible en la barra de menú el icono de Google Desktop. Igual que en MS Windows pulsando dos veces la tecla Ctrl aparece el cuadro de búsqueda.

Literalmente extraido de la página web de OpenXava…

OpenXava es un marco de trabajo para desarrollar aplicaciones web basadas en bases de datos, como Ruby on Rails, pero OpenXava produce aplicaciones J2EE / JavaEE estándars que pueden ser desplegadas en cualquier servidor de aplicaciones Java estándar (o portal Java estándar)

OpenXava es una iniciativa ¿española? (no estoy seguro de que esta afirmación tenga ningún sentido en el mundo Internet) por lo que toda la información al respecto está disponible en castellano, además de en inglés.

Es muy refrescante ver que proyectos iniciados en nuestro país crecen y llegan a tener un impacto importante en los medios internacionales de peso en el mundo Java.

Todavía no he tenido oportunidad de echar un vistazo al producto, pero si acerca algo el desarrollo de aplicaciones Java 2 EE a la facilidad de Ruby On Rails seguro que me gusta. También tengo en mi lista de tareas pendientes revisar Groovy, que también pretente el mismo objetivo: simplificar (enormemente) la construcción de aplicaciones Java.