Precisamente en esta linea, hoy he estado evaluando una utilidad que cubre un vacío importante: Selenium IDE. Se trata de unos plugins y un programa servidor que permiten grabar o crear guiones de testeo (habeis grabado alguna vez una macro con word/openoffice? Pues algo muy similar) para después poder ejecutarlos en masa de manera automática y en diferentes navegadores.

Los comandos que ofrece para usar desde los guiones son muchos y potentes. La principal limitación que le veo a primer vistazo es que no es posible interactuar con plugins (flash, java, etc…), aunque parecería que la tendencia hacia HTML5 va a hacer esto cada vez un problema menos importante.

Nuestro objetivo es utilizar esta herramienta para instaurar una cultura de testeo automatizado (“un bug no se da por corregido hasta que no tenga un guión de testeo”), lanzar tests automáticos cada noche y así no volver a tener una regresión sin enterarnos.

Para realizar el análisis seleccionamos 4 herramientas (de un total de 10 candidatas) y se estudiaron en detalle 4 entornos (Docuwiki, Mediawiki, Tikiwiki y Google sites). El objetivo del informe  era identificar una herramienta que permitiera crear contenidos de forma visual, con gestión de roles, permisos, y altas posibilidades de exportación a web y PDF.

Durante este período, hemos revisado decenas de módulos, se han estudiado las posibilidades técnicas, limitaciones y fortalezas de cada herramienta, y al final hemos llegado a la conclusión que hoy en día, la aplicación wiki más versátil y con más posibilidades de trabajo es la Docuwiki.

En la siguiente tabla resumen se pueden ver los diferentes puntos analizados y qué grado de idoneidad tienen las diferentes herramientas analizadas. En verde marcamos aquellas funcionalidades que están bien implementadas, en naranja las que tienen fallos o la implementación no es la adecuada y en rojo aquellas que no están desarrolladas o de forma muy deficiente para utilizarlas como entorno de trabajo.

Ahora toca analizar de qué manera conseguimos que en el caso de la Docuwiki los puntos naranjas sean verdes. Os iremos informando.

Las imágenes PNG individuales ocupan unos 950 bytes cada una. Parece poco, pero juntando las 100 salen 94.989 bytes. El sprite con las 100 imágenes dispuestas en una cuadrícula de 10×10 ocupa 14.384 bytes: un 15% del tamaño total de las imágenes individuales. Y de cara al navegador, en lugar de ser 100 peticiones es sólo una única carga (evitando latencia de cada imagen, su overhead, el hecho de que ningún navegador en su sano juicio lanzaría 100 peticiones en paralelo contra el mismo servidor, etc, etc…) .

Tal vez este sea un caso un poco extremo y habitualmente no nos encontremos con cosas tan evidentes, pero creo que esto explica por qué todos “los grandes” (google, yahoo, etc…) recomiendan el uso de sprites.

El resultado? Un linda pelotita que rueda y rueda cuando javascript le sopla…
Cómo se hace? En mi caso, con este script tan bonito:

1
2
3
4
5
6
7
8
9
10
11
12
13

#! /bin/sh
 
mkdir -p imgs
for i in `seq 1 100`; do
	sed -e s/##ENDANGLE##/`echo "scale=20; ( $i - 25 ) * 2 * 3.1415926535897932384626433832795 / 100" | bc`/g < drawing.svg > drawing_t.svg
	echo "$i..."
	"/cygdrive/c/Archivos de programa/Inkscape/inkscape.exe" -e 'C:\Documents and Settings\DaniM\Escritorio\sprites\imgs\'$i'.png' 'C:\Documents and Settings\DaniM\Escritorio\sprites\drawing_t.svg'
done
 
echo "Final sprite..."
sq=`seq 1 100`
names=`for i in $sq; do ( echo imgs/$i.png ) done`
/cygdrive/c/Archivos\ de\ programa/ImageMagick-6.4.0-Q8/montage.exe -background transparent -tile 10x10 -geometry +0+0 $names progress_sprite.png

El funcionamiento es sencillo: uso inkscape para crear un archivo vectorial SVG con el gráfico, utilizo sed para modificarle el ángulo final del arco y lo convierto a PNG invocando inkscape desde la linea de comandos. Una vez tengo las 100 imágenes, utilizo montage (parte de ImageMagick) para juntarlas en un sprite.

Como podeis ver, utilicé cygwin. Si hubiera usado un sistema operativo de verdad, no tendría que haber puesto toda esa marabunta de rutas en dos formatos diferentes.

Una opción interesante hubiera sido procesar el fichero SVG mediante xsltproc en lugar de mediante sed. Para casos más complejos seguramente sería una muy buena opción. Pero eso… lo dejo como ejercicio para el lector.

Lista de premiados:

Ganador General:

1. WordPress
2. MODx
3. SilverStripe

Open Source CMS más prometedor:

1. ImpressCMS
2. Pixie
3. Pligg

Mejor PHP Open Source CMS:

1. Drupal
2. WordPress
3. Joomla!

Mirando el histórico desde el 2006 se ve una progresión de Drupal que ha logrado por segundo año consecutivo ganar el premio al Mejor PHP Open Source CMS y está entre los mejores CMS.

Recientemente se ha publicado la notícia que La Casa Blanca (http://www.whitehouse.gov/) ha migrado los contenidos de su web a Drupal lo cual indica que es un CMS con la suficiente estabilidad, funcionalidad y seguridad para llevar a cabo sites tan complejos como este.

Tanto Drupal como WordPress son los CMS que habitualmente implementamos en proyectos, por su potencia y versatilidad en el caso de Drupal y por la facilidad de uso en WordPress. Coincide que en dos semanas saldrá publicado en MOSAIC, un artículo que compara Drupal, Joomla, WordPress y Plone.

Varios ejemplos de sites que ha realizado FactorSim con Drupal son:

Las webs segmentadas por países de Roca, entre ellos Roca protugal (http://www.roca-sa.com/):

Una web autogestionada para Clic-Austral (http://clic-austral.com/):

A nosotros, esta noticia nos ha traido una nueva tarea. Probar MODx y SilverStripe para evaluar porqué han sido elegidos entre los mejores CMS del mundo.