Algo grande se está preparando en el mundo del diseño y la programación web. No exagero. HTML5 se atisba ya como una revolución que puede acabar con tecnologías hoy tan consolidadas como Adobe Flash. Etiquetas tan potentes como < canvas > y sobre todo < video > van a suponer un cambio radical en la forma en que concebimos la web. La primera permitirá generar gráficos vectoriales en tiempo real sin necesidad de ningún elemento externo. El segundo (y para mí más interesante) permitirá insertar vídeos en un documento HTML sin Flash. De momento, por las pruebas que he podido hacer los formatos y códecs admitidos es limitado, pero no podemos olvidar que se trata de una especificación todavía en estado temprano de desarrollo.

Igual que con cualquier otra etiqueta de HTML, la etiqueta < video > puede ser manipulada mediante instrucciones JavaScript llamadas a través de funciones. Esto convierte a JavaScript en otra de las piezas claves de HTML5 y nos hace volver a los “viejos tiempos”. Por ejemplo, mediante JavaScript podemos controlar las características clásicas de un reproductor de vídeo (reproducir, pausar, reiniciar y todo lo que nos imaginemos). Incluso si no queremos, podemos utilizar la botonera estándar que implementa cada navegador mediante el atributo controls="controls". Pero lo mejor es ir con una pequeña muestra de código HTML5 para hacernos una idea. Simplemente con esta línea de código podemos reproducir un vídeo:

< video src="video_de_ejemplo.avi" controls="controls">Tu navegador no soporta HTML5< /video>

Más sencillo imposible. Ya existen versiones experimentales en HTML5 de webs de clips como YouTube o DailyMotion. El futuro ya ha comenzado. ¿El fin de Flash?

El año pasado más o menos a estas alturas, me volvió a entrar el gusanillo de diseñar aventuras conversacionales. Ya sabéis de mis gusto por este tipo de videojuegos. Todo partió de la noticia que llegó a mi ordenador con los resultados de la IFComp 2008, un concurso de aventuras cortas. En la edición de 2009, el podio de ganadores ha estado ocupado por ‘Rover’s Day Out’, ‘Broken Legs’ y ‘Snowquest’ en el primer, segundo y tercer puesto respectivamente. El hecho de que para crear estas piezas de software sea necesaria una dosis extra de creatividad (ya que todo el peso recae sobre las palabras), una parte evidente de técnica de programación y, por supuesto, organizar bien la historia, siempre me llamó mucho la atención. Pero esta fiebre se me fue pasando.

En estos últimos días me estoy empezando a familiarizar con algunas herramientas de creación de aventuras conversacionales como InformATE. Se trata de la versión traducida al castellano de Inform, que es un lenguaje de programación orientado a objetos, un conjunto de librerías y un compilador especializados en el desarrollo de juegos de ficción interactiva. La historia de Inform es ya muy dilatada. Su autor, Graham Nelson, lo creó en 1993 y desde entonces ha sufrido numerosas evoluciones. Después de compilar un videojuego con Inform o InformATE, no nos genera un ejecutable, sino un código intermedio que ha de ser ejecutado o interpretado por una máquina virtual. En este mundillo, los dos intérpretes más utilizados son Máquina-Z y Glulx. La primera de ellas fue diseñada ni más ni menos que en 1979 y fue creada para desarrollar ‘Zork’, una de las primeras aventuras conversacionales de la historia. Glulx es un sistema mucho más evolucionado y con más posibilidades, ya que permite incluso la incorporación de gráficos.

Actualmente existen intérpretes de Máquina-Z, de Glulx y de otros para cualquier plataforma, ya sea Windows, Mac o Linux. En mi caso, con Mac utilizo Spatterlight, que puede leer archivos para todas esas máquinas virtuales. Del mismo modo, también existen compiladores de Inform/InformATE para cualquier sistema operativo. En todos los casos las herramientas son rigurosamente gratuitas. No hay más que darse una vuelta por el repositorio que los chicos de CAAD mantienen en su sitio web y elegir el que mejor se ajuste a nuestras necesidades. También podemos encontrar abundante documentación y ejemplos para aprender este lenguaje.

Inform/InformATE es bastante complejo. Si bien su estructura es similar a la de cualquier lenguaje de programación, es necesario un ejercicio de abstracción para no dejar atrás ninguna de las posibilidades que nos permite. Buena parte de la culpa de esa complejidad se debe a la cantidad de acciones (muchas de ellas combinadas), de tipos de objetos, de situaciones, etc. En cualquier caso es una potente herramienta que nos ahorrará mucho trabajo si queremos programar una buena aventura con un buen vocabulario admitido (recordemos que las acciones se introducen libremente mediante lenguaje natural con el teclado).

Google ha presentado recientemente su lenguaje de programación llamado Go, un lenguaje que según aseguran tiene la eficiencia de un lenguaje de medio nivel como C o C++ junto con la rapidez de compilación y ejecución de los lenguajes interpretados, como Python. A simple vista tiene el aspecto clásico de C++, Java o PHP. A nivel de sintaxis sus estructuras de datos, de control, etc son aparentemente muy similares y no hay nada que me haga pensar que a nivel interno (gestión de memoria, de I/O..) sea muy diferente de C/C++. Si alguien conoce alguna característica bien diferenciada de otros lenguajes por el estilo, por favor que me la diga. Pero no he podido evitar descargármelo e instalarlo. De momento sólo está disponible para Linux y Mac OS X. Para que os hagáis una idea, este es el código del “Hola Mundo” copiado de la página oficial de Go:

package main
import "fmt"

func main()
{
	fmt.Printf("Hola Mundo\n")
}

Una vez dicho esto, me viene una pregunta a la cabeza: ¿Para qué queremos otro lenguaje de programación? ¿No existen ya demasiados? Existen otros “lenguajes de moda” que pasaron por aquí, como Ruby, mucho más revolucionario que Go, pero que tengo la impresión de que ha pasado sin pena ni gloria. Lo mismo pienso de C#, la gran apuesta de Microsoft de hace unos años y que muy poca gente utiliza. Lo único que se consigue con esta diversificación tan gratuita es que los desarrolladores se vuelvan locos, no profundicen en todas sus posibilidades o que sea complicado especializarse en un lenguaje de programación con dudoso seguimiento. Aún así, bienvenido al mundo de la programación.

Desde hace unos meses me ronda en la cabeza reformar profundamente mi web de fotos Cromavista para transformarla en una web de fotos de viajes más que en la “cosa” indefinida medio experimental que es ahora. Este cambio iría desde el logo hasta en el concepto general. Mi intención es añadir muchas más fotos de muchos más lugares que ahora permanecen inéditas y que merecen la pena ser vistas. Como tampoco tengo ganas de dedicarle demasiado tiempo programando o reformando el código del Cromavista actual, lo primero que pensé fue en usar uno de los servicios de fotos que nos ofrece internet.

Flickr es la primera opción. Lo tenía todo: un software para Mac que permite subir cómodamente las imágenes, posibilidad de crear carpetas, comentarios para las fotos y, por qué no, formar parte de la mayor comunidad fotográfica de toda la red. Pero claro, para un usuario básico, el límite está en 200 fotos. Si queremos eliminar estas limitaciones tenemos que actualizarnos a usuario Pro. No es que sea caro (unos 2 dólares al mes), pero teniendo espacio en servidor propio de sobra (me quedan unos 300 Mb libres) para almacenar unas cuantas fotos, me parece una tontería pagar por otro servicio.

Otra opción era usar una de las muchas aplicaciones escritas en PHP y MySQL para gestionar álbumes de fotografías digitales. Hace unos años investigué algo Coppermine, sin duda el más popular. Pero también existen otras opciones menos conocidas y dignas de ser investigadas. El principal inconveniente de estas aplicaciones es su dificultad para ser adaptadas a las necesidades de cada usuario. Hace falta invertir unas cuantas horas trabajando con la plantilla para conseguir unos resultados medianamente aceptables, que es justo lo que no quiero hacer.

La última y más drástica alternativa es crear una web “a la vieja usanza” con HTML estático. De esta forma modificar los álbumes sería más engorroso, pero su desarrollo sería más rápido si se consigue automatizar lo suficiente (me refiero al copiar+pegar). Ahora mismo estoy investigando esta opción, pero todavía no tengo nada concretado ni en cuanto a estructura ni en cuanto a estética. Sólo me queda ponerme manos a la obra cuando tenga tiempo y ganas. Puede ser mañana o dentro de un mes. Ya se verá.

Vivimos en una época donde la información de todo tipo fluye con libertad hasta el exceso. Imágenes, vídeos, sonidos, música, textos… Navegamos por un mar de datos que somos incapaces de digerir y que es ya nuestro ambiente natural. Pareciera que la información, igual que la energía, ni se crea ni se destruye, sino que sólo se transforma en otras cosas. Quizás fue así como surgió el “mashup”, que podríamos traducir en castellano como remezcla o más bien como mezcla. El “mashup” es un agregado de varios elementos para crear uno nuevo con nuevas funcionalidades o un nuevo significado. Este concepto se aplica a muchos y muy diversos campos.

Desde el nacimiento de la llamada “web 2.0″, el concepto de “mashup” se ha convertido en uno de los más populares. El hecho de que las webs intenten ser cada vez más participativas y abiertas han llevado a publicar sus APIs (para los profanos, la “caja de herramientas” y/o el “manual” para modificar y adaptar el sistema a nuestras necesidades) y a permitir su combinación con otros servicios que proporcionan otras webs. Posiblemente los pioneros del “mashup” de la web son Google. Todas sus aplicaciones y servicios están abiertas a todo aquel que quiera manipularlas para su uso particular. A día de hoy son ya miles los sitios que combinan servicios de terceros para ofrecer a sus visitantes un nuevo servicio híbrido que tal vez de otro modo no podría ser posible. Algunos ejemplos son:

• Lastmusicmap = Last.fm + Google Maps
• WikiFM = Last.fm + Wikipedia
• Qué Tiempo = Agencia Estatal de Meteorología + Google Maps
• GoolZoom = Catastro + SIGPAC + Google Maps

Y así podríamos seguir hasta el infinito… Pero sin duda el aspecto más vistoso de los “mashup” es la mezcla de vídeos o de música. Por internet, especialmente en los sitios de vídeos, encontramos auténticas joyas de la mezcla, algunas de ellas de lo más disparatado, como este donde se recrea la cabecera de McGyver con secuencias de Star Wars:

Y si nos metemos con el tema musical, el filón se hace interminable. He elegido un par de ellos que tienen su gracia. El primero de ellos se titula The Escobars y mezcla un tema de nuestro españolísimo Manolo Escobar con unos raperos:

Por último, ¿Cómo sonarían los Beatles + LCD Soundsystem + The Kinks?. Aquí está la respuesta:

Aunque en los últimos años estoy un poco desconectado de la programación, siempre me gusta estar al día de lo que se cuece. Hacía ya tiempo que sabía de la existencia de un lenguaje de programación todavía poco conocido llamado D. Para todos aquellos que saben algo de estos temas podrán deducir que tiene algún parentesco con C y C++. Así es. D lleva desarrollándose ni más ni menos que desde 1995 y su artífice es Walter Bright. A través de una anotación en Barrapunto recupero este tema para traerlo hasta vosotros.

A simple vista, echando una ojeada al código fuente de un programa escrito en D, podría pasar por C++ salvo en algunos detalles. Con esto quiero decir que no es un cambio radical. De hecho, D es una evolución de su predecesor hacia mejor. En su día muchos nos quejábamos de lo complejo que podían llegar a ser algunos aspectos de un programa en C++. Por ejemplo en lo tocante a control de memoria dinámica y punteros, a la portabilidad entre compiladores y plataformas o al acceso al bajo nivel del sistema operativo mediante bloques de ensamblador. D mejora muchas de estas cosas (sobre todo el primero) y las simplifica.

Desarrollar un lenguaje de programación no es ni sencillo ni rápido. Por eso queda mucho tiempo aún para que D sea un lenguaje de programación masivo. Ya se han dado los primeros pasos, con conferencias de expertos y varias ramas en desarrollo (Digital Mars, GDC y LDC) pero el camino que queda por delante es muy largo.

Un programa “Hola mundo” en D tendría este aspecto más o menos:

#!/usr/bin/dmd -run
/* HOLA MUNDO EN D */
import std.stdio;

void main(string[] args) {
       writefln("HOLA MUNDO");
}

Me he enterado a través de Barrapunto que este mes se está celebrando (bueno, no sé si realmente alguien lo celebra) el 25 aniversario de la primera versión de Turbo Pascal. Para quien no lo sepa, se trata de un lenguaje de programación muy sencillo de la compañía Borland y con el que mucha gente aprendió a programar. Este no fue mi caso, porque yo empecé con Basic en 1986. No fue hasta 1995 cuando me adentré (o me adentraron) en el apasionante mundo del Turbo Pascal. Hasta la popularización de los IDE gráficos en Windows (sobre todo con Visual Basic), Turbo Pascal era el rey de los primerizos, los que querían tener un entorno integrado para programar, compilar, enlazar, depurar y ejecutar nuestras pequeñas aplicaciones.

En la carrera dimos a fondo Turbo Pascal y me di cuenta de la cantidad de posibilidades que puede tener. De hecho una de sus principales bazas era su potencia y su sencillez con capacidad para programación orientada a objetos. La herencia de Turbo Pascal la encontramos en Delphi, la versión con IDE para Windows, aunque la verdad es que hoy prácticamente ya no se utiliza.

En un ejercicio de nostalgia me he bajado el Turbo Pascal 5.5 y he programado un pequeñísimo ejemplo. El código fuente en el entorno integrado tenía un aspecto tal que así: