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

Primero probaron con este nombre http://www.twitter.com/gencat_cat

Twitter de la Generalitat 1

Según parece no les convencía y cambiaron a http://www.twitter.com/gencatcat

Twitter de la Generalitat 2

Al final, alguien pensó que la mejor opción era dejar el twitter en el nombre más corto sin añadir la extención cat http://www.twitter.com/gencat

Twitter de la Generalitat 3

Un camino accidentado para conseguir la identidad digital…

Salud 2.0 intro

Web 2.0 y Salud 2.0.

Web 2.0 y Salud 2.0. Gestionar la información.

Els blogs i el seu ús en la tasca docent

Entorns personals d’aprenentatge (PLE)

Las posibilidades eran hacerlo mediante código en el servidor o que los usuarios de la aplicación enviaran directamente los archivos html.

El método más “cómodo” para usuarios no técnicos es guardar el archivo en formato html desde el propio word. Haciéndolo de esta forma se introduce una cantidad exagerada de tags html, unas que solo sirven para poner estilos y que se podrían poner de forma más cómoda y las que corresponden a la estructura del html están en un formato que, como no, no sigue el estandard.

Así que buscando por la red al final se optó por hacer la conversión directamente en el servidor mediante php y openoffice de la siguiente forma:

En el editor de textos de openoffice (writer) crear una macro como la que sigue:

REM  *****  BASIC  *****

Sub odttohtml (Path)
Dim Url as String
Url = convertToUrl(Path)

Set oDesk = CreateUnoService( “com.sun.star.frame.Desktop” )
Dim OpenParam(1) As New com.sun.star.beans.PropertyValue ‘Parameters to open the doc
OpenParam(0).Name=”Hidden” : OpenParam(0).Value=True
Dim Doc
Doc = oDesk.loadComponentFromURL(Url, “_blank”, 0, OpenParam())

Dim outputfile as String
outputfile = Left( Path, Len( Path ) – 3 ) + “html”

Dim SaveParam(0) As New com.sun.star.beans.PropertyValue
SaveParam(0).Name=”FilterName” : SaveParam(0).Value=”HTML (StarWriter)”

Url = convertToUrl(outputfile)
Doc.storeAsURL(Url, SaveParam() )
Doc.close( True )
End Sub

Con la función odttohtml se consigue pasar un documento doc a html con un formato “casi” estricto (algunos tags no se cierran).

Una vez guardada la macro, ya se puede invocar mediante php con el siguiente código:

shell_exec(‘soffice -headless “macro:///Standard.Module1.odttohtml(doc_file.doc)”‘);

Esto nos da como resultado un documento html bastante aceptable para poder ser usado por “humanos” y que sigue el estandard.

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.

Dejo aquí las presentaciones que hemos empleado, por si a alguno le resultan de utilidad.

Version 4.0. Otoño 2009

Versión 3.0. Octubre 2008

Versión 2.0.

Versión 1.0

Aquí os dejo el orden del día: