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.

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.

El más reciente gran paso es WebGL: un API OpenGL ES 2.0 para JavaScript. Es decir: gráficos 3D acelerados por hardware en el navegador. Estamos hablando del mismo tipo de tecnología con la que se desarrollan los juegos normales y corrientes. Y si bien JavaScript es más lento que el lenguaje C/C++ que utilizan los juegos, el hecho de que cada vez se haga más proceso en la GPU y menos en la CPU es una tendencia muy conveniente para hacer WebApps 3D competitivas.

WebGL no es un proyecto de especificación que algún dia verá la luz. Ya está aquí. Las últimas versiones de los principales navegadores ya lo implementan (lo que pone de manifiesto que Internet Explorer cada vez cumple menos su labor como navegador, ya que és la única excepción). Y las aplicaciones web que lo utilizan también están ya aquí. Por ejemplo:

Google Body Browser (http://bodybrowser.googlelabs.com/): un atlas anatómico completo en 3D.

Quake WebGL: por si teníamos alguna duda de si esto iba a servir para juegos. Hay una versión completa de Quake 2 (http://playwebgl.com/games/quake-2-webgl/) y visores de niveles de Quake 3 (http://media.tojicode.com/q3bsp/). Seguramente WebGL diera para portar juegos más modernos, si el código de estos estuviera disponible, claro.

Y otros muchos ejemplos de todo tipo: http://www.chromeexperiments.com/webgl

Moodle cuenta con una función grade_get_grades() capaz de proporcionarnos cualquier nota EXCEPTO las notas de curso, de categorías y las manuales. Por tanto, no nos queda más remedio que buscarnos esas notas de otra manera.

En el caso de moodle 1.8 / 1.9, podemos obtenerlas con una simple consulta a la base de datos:

$grades = get_record_sql("SELECT g.finalgrade,
                                 g.rawgrademin,
                                 g.rawgrademax
                          FROM ".$CFG->prefix."grade_grades g,
                               ".$CFG->prefix."grade_items i
                          WHERE i.itemtype='course' AND
                                i.id=g.itemid AND
                                i.courseid='".$COURSE->id."' AND
                                g.userid='".$USER->id."'");

En versiones más antiguas, en cambio, no disponemos de estas notas ya calculadas en la base de datos. Cada vez que se utilizan, el módulo de gradebook obtiene las notas parciales, invoca a las funciones de evaluación de notas de los módulos pertinentes y pondera los resultados para terminar con una nota global. Nuestras dos únicas opciones son replicar ese comportamiento a mano o bien intentar reaprovechar el código del gradebook. Esto último es lo que hemos hecho en Factorsim en el siguiente ejemplo para Moodle 1.6:

require_once($CFG->dirroot.'/grade/lib.php');
$grades = grade_get_formatted_grades();
$grade = $grades[0][$USER->id]['student_data'];

Esta última solución es un buen ejemplo de “matar mosquitos a cañonazos”, porque la función grade_get_formatted_grades() nos devuelve todas las notas de todos los alumnos del curso. Nosotros después las descartamos todas excepto las del alumno que nos interesa.

Pues drupal tiene un módulo así, y no es ninguna broma. Se trata de un módulo para penalizar a usuarios con comportamientos menos que ejemplares. Es una medida menos drástica que borrarle la cuenta de un plumazo.

En cualquier caso, estoy seguro de que es una práctica muy polémica y demostrar su efectividad o la ausencia de ella promete ser complicado.

El módulo podeis encontrarlo aquí: http://drupal.org/project/misery

El recuadro sobre estas lineas es el primer gadget de iGoogle que hemos creado desde Factorsim. Sirve para vincular cualquier site de Moodle (configurable) desde una página iGoogle… o… desde prácticamente cualquier otra página, en realidad. Por ejemplo: aquí.

No se trata de un screenshot. Funciona. Podeis probarlo. Si teneis una cuenta de http://www.aprendizajeonline.es, podeis utilizar este gadget para entrar directamente.

Con el siguiente enlace podeis añadir este gadget a vuestro iGoogle.

Ilustración por Cristina

Hay ya muchos textos escritos sobre Subversion, pero hoy no hablaré de sus características, de lo que puede hacer ni de cómo lo hace. Hoy me centraré en qué es lo que le encontramos interesante para utilizarlo como herramienta en una empresa. En otras palabras: por qué lo utilizamos.

• Ha llamado un cliente. Dice que tiene un problema con la versión j29rc20. ¿Alguien sabe de dónde puedo conseguir esa versión para hacer unas pruebas?

• Uffff… j29rc20 significa “jueves 29, versión que estaba en el discoduro de Ricardo Cano a las 2:00”. ¡A saber dónde estará esa versión ya ahora!

Subversion guarda todas las versiones que pasan por sus manos. Además, permite dar un nombre (etiquetas, en nomenclatura SVN) a cualquiera de esas versiones. Así, si j29rc20 fuese una etiqueta SVN, obtener esa versión seria trivial.

• ¡Ostras! ¡He copiado esta versión encima de la antigua pensando que no tenía nada importante y me he cargado todo mi trabajo de la última semana!

En un repositorio SVN, la incorporación y mezcla de los cambios hechos por los diferentes usuarios (o incluso de copias de trabajo distintas de una misma persona) se realiza de manera automática, garantizando que nadie sobreescribe el trabajo de otro. Y si has borrado un archivo que no debías o has hecho cambios que no son correctos, siempre puedes recuperar cualquiera de las versiones anteriores que hay guardadas.

• ¿Cuando corregimos la alineación de las imágenes para IE6 lo hicimos mediante CSS o JS?

Subversion permite comparar fácilmente cualquier par de versiones de cualquier archivo. Si unimos a esto la posibilidad de explicar en los comentarios qué es lo que hemos modificado en cada versión, responder a esta pregunta es tan fácil cómo ojear la lista de comentarios e inspeccionar las diferencias de la versión relevante con la anterior. Además, nos vendrá de regalo la información sobre quién hizo ese cambio y cuándo.

• Queremos implementar una funcionalidad experimental que va a afectar la estabilidad del proyecto pero incluirla en la siguiente versión sólo si está ya suficientemente estable. Nos arriesgamos a ir haciendo los cambios o cómo lo hacemos?

En el mundo SVN la respuesta es única: mediante una rama. En cada rama que creemos podremos tener una evolución independiente del mismo código, de manera que no se interfieran entre ellas. Crea una rama nueva para implementar allí la funcionalidad experimental. Cuando el código esté maduro podrás integrar fácilmente los cambios en la rama principal antes de hacer la nueva versión. Si esa integración de cambios no llega a tiempo, la rama principal incorporará otros cambios no desestabilizadores pero nada de la rama experimental.

• Tenemos un directorio JS que es común a todos estos proyectos, pero ahora ha llegado una versión nueva del JS. ¿Tenemos que copiarlo a todos los proyectos uno por uno?

En SVN, no. Separa el directorio JS en un apartado del repositorio y vincúlalo al resto de proyectos. De esta manera, los cambios de cualquiera de los proyectos se trasladarán al JS común y de ahí a todos los demás proyectos. Modifica el JS común o la copia vinculada a cualquiera de los proyectos y todos los demás sitios se actualizarán por arte de magia. Todo lo que dijimos antes sobre la seguridad de no sobreescribir cambios de otros y las versiones se aplica aquí también, por supuesto.

Pero no todo es de color de rosa…

Subversion al fin y al cabo es sólo una herramienta. Que resulte beneficiosa o nociva depende del uso que se le dé. Hay algunos problemas muy comunes:

Subversion permite tener todos los archivos de un proyecto muy bien ordenados e indentificados. Pero no obliga a ello. De hecho, con etiquetas, ramas, vínculos y una estructura de directorios mal definida SVN puede llevarnos a un nuevo nivel de caos desconocido hasta la fecha.

Por otro lado, como cualquier otra tecnología, requiere un aprendizaje. Trabajar con una copia de trabajo en SVN es muy similar a trabajar con archivos normales. Demasiado parecido. Pero quienes acostumbren a copiar proyectos (o partes de ellos) de un directorio a otro se encontrarán con unas cuantas sorpresas desagradables al intentar sincronizar su trabajo con SVN, sin ir más lejos. También hay que aprender a crear archivos nuevos, borrarlos o incluyo renombrarlos o cambiarlos de sitio cuando residen en un proyecto SVN. Es igual de sencillo que hacer esas operaciones sobre archivos normales, pero hay que recordar que la manera concreta de hacerlo cambia.

Por último, para aprovechar los proyectos organizados que nos posibilita un repositorio de código lo mejor es tener una gestión organizada. Una gestión que establezca claramente las entregas, las versiones, los objetivos de cada una de ellas, las iteraciones de testeo y corrección de errores, etc…

Pero todo esto es ya material para otro post (sí: es una amenaza).

Lo más interesante es cómo está hecho. Y es que este ejemplo combina los dos elementos que considero fundamentales en drupal: CCK y vistas. Cada punto marcado en el mapa es un nodo de drupal, de un tipo GoogleMaps Marker. Este tipo contiene sólamente un título y un campo CCK para introducir las coordenadas.

De esta manera, cualquiera que cree un nodo de este tipo, hará aparecer un nuevo punto en el mapa. El mapa no es otra cosa más que una vista. Es decir: una lista de todos los nodos de tipo GoogleMaps Marker, sólo que con un formato algo diferente de la típica tabla mostrando los campos de cada entrada. El resto son unas cuantas llamadas al API de GoogleMaps, que está todo lo bien diseñada que cabía esperar.

MoodleMoot, la reunión de usuarios de Moodle, celebrará su próxima edición en Octubre en Barcelona. Ya están abiertas las incripciones y el proceso de “call for papers”. El énfasis de esta edición se quiere poner en ofrecer más talleres prácticos y menos clases magistrales.

FactorSIM ya está preparándose para asistir.Si algún lector del blog se anima a ir y le gustaría tomar un café…