Bienvenidos al blog de FactorSIM.

En Factorsim siempre nos alegra encontrar herramientas de esas que facilitan enormemente la vida. Ya no nos acordamos de lo tedioso que era escribir código javascript antes de jQuery o de debugar código mediante alerts en lugar de usar firebug.

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.

Hoy he estado creando un sprite para el nuevo curso que estamos desarrollando. Bueno, en realidad yo he hecho un script y el script ha hecho el sprite, porque no tenía yo ganas de crear 100 imágenes a mano. Este es el resultado:

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.

Cuando aparecieron las primeras WebApps nos reimos de ellas y nos negamos a llamar aplicación a “eso”. Pero dicen que quien rie el último rie mejor. Mediante ingenio, tecnología y nuevos estándares han superado sus limitaciones iniciales y ya hace tiempo que todos somos conscientes de que las aplicaciones web son aplicaciones de pleno derecho.

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

Consultar la nota del alumno logeado en un curso parece una operación sencilla. Podemos necesitarla para decidir si ha aprovado o no, para decidir nostrarle una actividad de final de curso, un diploma, una felicitación…

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.

Si viésemos anunciado un módulo que promete hacer miserables a los usuarios, redireccionándolos a páginas incorrectas, dándoles errores, introduciendo esperas innecesarias, etc… nos pensaríamos que se trata de una broma, ¿verdad?

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