El otro día escribía una anotación sobre HTML5 y criticaba un poco el “buzz” que se le está dando. Sin embargo, HTML5 tiene algunas características totalmente nuevas y geniales.
Como músico aficionado que soy, una de las que más me ha llamado la atención es la posibilidad de incorporar audio de forma nativa (tag <audio>) y poder controlar el audio mediante Javascript.
En la siguiente página he puesto un sencillo metrónomo como prueba de concepto:
Lo primero es cargar el fichero de audio. No todos los navegadores soportan todos los formatos, así que hay que dar alternativas (me faltaría un OggVorbis).
Desde Javascript podemos acceder al elemento audio y controlarlo (invocando play, stop, etc) En este ejemplo he utilizado jQuery. Por ejemplo, para lanzar la reproducción:
$('#down').trigger('play');
Así de sencillo. El resto del código Javascript se limita a establecer un temporizador para ir lanzando periódicamente la reproducción del audio.
Es sólo un experimento, para hacer esto realmente útil tendríamos que controlar bien que la ejecución de un Javascript no fluctúe.
Cliente: [...] y quiero que la web corporativa se haga en HTML5. Desarrollador: ¿Necesita algún elemento nuevo de HTML5 en concreto? Cliente: Uh… Esto… Bueno, quiero que tenga vídeo, gráficas interactivas, todo lo que trae HTML5. Desarrollador: Sin problema, pero el precio del desarrollo subirá. Los gráficos en HTML5 hay que programarlos igualmente, lo único que en vez de Flash utilizaremos Canvas. Si queremos que el vídeo se vea en todos los navegadores, habrá que hacer diferentes codificaciones: necesitaremos más almacenamiento y hardware más potente para la codificación si hay mucho volumen de vídeos. Cliente:¿Pero eso no viene ya de serie con el HTML5 ése? Desarrollador: No, hay que hacerlo igualmente.
Reconozco que esta esta conversación ficticia está un poco traída por los pelos, pretende ser más satírica que otra cosa, pero ilustra un poco la sensación que tengo respecto al HTML5: parece que es la panacea y la solución a todo, la tecnología que finalmente hará de la web un lugar idílico, normalizado y estandarizado,… pero sigue haciendo falta alguien que programe.
Hay muchas novedades y aportaciones en HTML5 que ya han analizado en multitud de sitios, así que no voy a decir nada nuevo. Lo que quiero transmitir con este artículo es que HTML5 no es un milagro tecnológico ni nada similar (se oye demasiado a menudo “¡… y está hecho con HTML5…!”, como si fuese lo más de lo más de la innovación y la solución a todos los problemas). Es una evolución (con muchos aciertos y posiblemente, limitaciones) del HTML y así es como los técnicos debemos verla. No nos dejemos llevar por el “hype” de las siglas y de los departamentos de Marketing
Algunas cosas que me parecen interesantes (en la Wikipedia viene un buen resumen):
Mejoras semánticas (en mi opinión, casi la novedad más importante). En versiones anteriores, cada bloque en una página no tenía sentido semántico. Es decir, la cabecera, menú, pie de página, etc… eran siempre un <div>. Con HTML5 tenemos <header>, <footer>, <nav>, …
Esto parece una tontería, pero es muy importante y tiene muchas aplicaciones:
Los buscadores pueden identificar rápidamente qué partes de la página son relevantes.
Los agentes de usuario (navegadores) pueden presentar la página de acuerdo a las instrucciones que le de el usuario, por ejemplo: “ocultar la barra de menús” o “destacar el contenido del artículo”, etc.
Imaginemos un navegador/lector para personas con problemas de visión: cada vez que pasen de página no les leerá el interminable menú de navegación, ni la cabecera, etc. Directamente les leerá el contenido del artículo.
Se facilita enormemente el intercambio de contenidos entre sitios web (y el “robo” también, todo hay que decirlo). Nuestros scripts ya sabrán qué hay que recoger en una página y qué no.
Por fin se puede mostrar vídeo en el navegador sin necesidad de utilizar un plugin (típicamente, Flash). El problema está en los navegadores: cada uno soporta un formato/codec diferente. Si queremos garantizar que todos los navegadores podrán tratar con nuestro vídeo, hay que preparar múltiples fuentes. Ejemplo (c&p de la Wiki
Si queremos dar soporte a navegadores antiguos que no entiendan el tag <video>, debemos preparar un mecanismo para mostrarles el vídeo a través de un plugin.
Lo mismo es aplicable para el audio. Cada navegador funciona diferente.
Gráficos 2D: se estandariza el tag <canvas> y su API. Un bloque canvas sólo define una región que puede ser “pintada” a través de un script (típicamente Javascript). Nada más (y nada menos).
Últimamente se ven algunas maravillas como juegos, pruebas de concepto, etc, “programados en HTML5″. Error de concepto: están programados en Javascript y se muestran en una página HTML5.
Hacer cosas en un <canvas> no es una tarea trivial. En la especificación se definen funciones o métodos de bajo nivel y nada más. Existen bastantes “librerías” de Javascript que facilitan la tarea, pero no son parte de la especificación.
Por fin se simplifican los DOCTYPE (se queda un simple <!DOCTYPE html>) y los atributos del tag <html>.
Llevaba un tiempo pensando cómo se podía hacer esto, es decir, que un anuncio tipo “iframe” pudiese contener en sus URLs el código de seguimiento de Google DFP.
Antecedentes:
Supongamos que tenemos una “creatividad” (que poco me gusta este término) del tipo “terceros” en nuestra cuenta de DFP. El código corresponde a un iframe que sale de nuestro servidor:
Si creamos en DFP el banner del tipo “terceros” y ponemos el iframe, DFP podrá controlar las impresiones del banner, pero no los clicks, puesto que en ningún sitio hemos insertado la macro correspondiente, típicamente %%CLICK_URL_ESC%%
La solución:
Al llamar al iframe, añadimos como parámetro la macro, esto es:
Cuando DFP lance una impresión de nuestro banner, la macro será sustituida por el correspondiente código de seguimiento y desde el script que genera el banner, capturar el la url de seguimiento de DFP.
Supongamos que trabajamos con PHP, la modificación sería la siguiente en la página http://miservidor.com/anuncios/anuncio1:
Y eso es todo. En enlace que sale en el iframe ahora tendrá el código de seguimiento de Google DFP, contabilizará el click y redigirá al enlace final, http://miservidor.com/articulos/articulo1
Por supuesto, hay que tomar todas las medidas de seguridad oportunas para evitar problemas (comprobar y sanear el parámetro que llega, etc).
Tiene un montón de características interesantes: estadísticas de todo tipo, búsqueda de claves, consola de comandos. La instalación y configuración es trivial.
Eso sí, seguridad, ninguna. No es una herramienta que deba estar expuesta, sólo debería utlizarse desde el “backend”.
Primero fue cayó Google Wave, ahora cierran Google Buzz. En el blog oficial de Google lo comentan.
Según la entrada, en Google están centrando todos sus esfuerzos en Google+, su buque insigna en las redes sociales y están “reciclando” lo aprendido.
En muchos productos de Google se van incorporando innovaciones. Cuando se está editando un documento en Google Docs entre varias personas se muestra quién está editando cada parte, como en las conversaciones de Wave.
Otros desarrollos en Buzz presumiblemente también se están incorporando en Google+.
Se aproxima una interesante “batalla” entre Facebook y Google+
Llevaba tiempo buscando un plugin para symfony 1.4 que permitiese cachear en Memcache en vez de en ficheros.
Encontré este, sfMemcachePlugin, pero parece que no está mantenido y no me he atrevido a instalarlo.
En mi aplicación sólo necesitaba cachear los resultados de una consulta especialmente pesada (es una cartelera de cine, la consulta consiste en cruzar todas las películas con todas las poblaciones donde hay cines que la tengan en cartelera).
Mi solución ha sido un tanto rudimentaria pero funciona muy bien:
Primero defino un método estático en una clase “Utilidades” que me devuelve un objeto memcache:
class Utilidades {
public static function getMemcache() {
$objMemcache = new Memcache;
$objMemcache->addServer('servidor1',11211);
$objMemcache->addServer('servidor2',11211);
/* etc */
return $objMemcache;
}
}
Después, en la clase que hereda de Doctrine_Table, defino el método que devuelve los resultados cacheados:
Haría falta código adicional para controlar errores, etc, pero la idea básica es ésta. Se puede añadir algún parámetro al método como public static function getConsultaCacheada($nocache=false) para poder hacer consultas “frescas” sin tirar de Memcache si es necesario.
Expose Midi Streaming capability of Sonivox Synthesizer
Y no parece que haya avances. ¿Por qué?
Por esto:
¡No se pueden hacer aplicaciones de este tipo en Android! No es posible enviar secuencias MIDI al sintetizador interno. El sistema iOS lo tiene resuelto hace mucho. Consecuencia: hay muchas aplicaciones para músicos muy buenas y bien hechas para iOS y para Android, algún afinador, caja de ritmos y poco más.
Una pena.
