Field, arte algorítmico

Field es un proyecto para la creación de trabajos artísticos digitales. Es un entorno para escribir código rápidamente (Python) y ensamblar y explorar sistemas algorítmicos experimentalmente. Es visual, es híbrido, y está basado en código. Está pensado para ofrecer algo distinto a programadores y artistas. Basado en ideas del MIT Media Lab, Field ha sido desarrollado a lo largo de 6 años hasta publicarse recientemente como fuente abierta. La primera beta está disponible para Mac OS X 10.5.


Vimeo



Documentación, más vídeos.

La hora de "acabar" con IE6

Traduciendo de Ajaxian:

Una nueva resistencia en nuestra lucha contra el mal se ha iniciado en Noruega:

Ayer, una de los sitios comerciales más grandes de Noruega, finn.no, ha empezado a mostrar avisos a todos los usuarios que naveguen con IE6 diciéndoles que actualicen sus navegadores. Hoy, muchos sitios noruegos de gran tamaño están haciendo lo mismo. ¡La campaña para terminar con el uso de IE6 está en marcha!

El mensaje que muestran es el siguiente:

Aviso: Estás usando una versión anticuada de Internet Explorer.

Con el fin de obtener lo máximo de nuestra página web, puedes conseguir una actualización gratuita de Internet Explorer. Si estás usando un ordenador de trabajo, debes contactar con tu administrador de TI.

¿Se difundirá la campaña? ¿Conseguirá acelerar el declive de IE6?

Personalmente, si tienes algún sitio bajo control, sugiero que consideres la posibilidad de mostrar un aviso similar. Aporta tu granito de arena, que ya va siendo hora. Addendum: Hoy, Douglas Crockford pone el dedo en la llaga acusando a muchas compañías estúpidas con aplicaciones web desarrolladas por incompetentes que obligan a sus empleados a navegar con tecnología del 2001, el equivalente a hace 120 años si atendemos a quien afirma que un año de la Red equivale a 15 años reales.

Web Hooks

Gracias al sistema de fuentes de noticias (feeds) basado en RSS o en Atom, es posible conocer los cambios realizados a una página web, o las novedades de una agenda, entre otras muchas aplicaciones. Pero el estándar tiene el problema de estar basado en tecnología de polling (hay que estar preguntando constantemente por el recurso para comprobar si hay cambios), con todos los problemas que ello conlleva: actualizaciones periódicas pero no en tiempo real y alto consumo de ancho de banda en el servidor donde está publicada la fuente.

Por otro lado, las ventajas de los sistemas push son muchas. De hecho, antes incluso de que se usasen las fuentes de noticias el correo electrónico ha venido usándose para informar a un usuario, y en ocasiones a un sistema, de los cambios producidos. Se ha hablado mucho de Comet como el siguiente paso después de Ajax, de forma que se mantiene un canal de comunicación persistente entre el navegador o cliente y el servidor que se usa para notificaciones en ambos sentidos (como una aplicación de chat).

Pero faltaba una pieza: ¿cómo notifica un servidor a otro de un cambio al que el usuario quiere suscribirse? Por ejemplo, ¿no sería interesante poder indicar en un servicio de alojamiento, que se avise a nuestro servidor por medio de una URL justo después de haber realizado un cambio? ¿Acaso no tenemos ya la tecnología para hacerlo (una simple petición HTTP)? La respuesta son los Web Hooks. Las posibilidades que esta opción abre son inmensas, recordando las que los pipes de las consolas Unix han ofrecido siempre.

La siguiente presentación explica de forma impecable esta nueva propuesta que viene a complementar las ya existentes: Web Hooks and the Programmable World of Tomorrow en SlideShare.net


Servicios como Switchub.com, gnip.com o RSSFwd.com ya se están preparando para el previsible crecimiento exponencial de la tecnología (Aunque siempre habrán herramientas como Microsoft PopFly o Yahoo! Pipes para diseñar visualmente un procesado de datos como trate en este artículo).

Por cierto, resulta un inmejorable momento para recomendar servidores de aplicaciones gratuitos como appjet.com (Javascript, y que podemos descargar) o Google App Engine (Python) para programar pequeñas aplicaciones que traten con las notificaciones recibidas. Eso o usar las herramientas habituales en un dominio que gestionemos.

Reconsiderando la etiqueta table para el diseño

Hace unos días se desató la polémica por el artículo de Ron Garret titulado Why CSS should not be used for layout al que siguió CSS and the meaning of life y luego On the semantics of HTML.

El artículo puede resumirse con las frases:

Mientras que el CSS debe ser usado para dar estilo, las tablas deben ser usadas para el diseño (layout)

Si algo inherentemente simple resulta difícil de plasmar, es porque algo falla.

Y su justificación...

Aparentemente el orden importa. La razón por la que el orden importa es que este diseño, como todos los diseños CSS multicolumna, se consigue con floats y la forma en la que los floats son distribuidos depende del orden en el que aparecen. Por ello no hemos conseguido separar el contenido de la presentación. La forma en la que las cosas aparecen en pantalla aún depende del órden con el que aparecen en el contenido. Peor aún, con el fin de ser distribuidos adecuadamente, el órden en el que los elementos deben aparecer es diferente del flujo natural en el diseño.

Aunque los puristas le acusarán de no conocer suficiente el CSS, lo cierto es que todos hemos pasado por las molestias descritas. Y después de pegarse un rato, con el agravante de que cada navegador reacciona de una forma distinta, consigues por fin la apariencia que quieres. Pero sin saber dónde estaba el problema, por lo que volveremos a caer una y otra vez en el mismo desesperante proceso.

Su justificación de que el significado de las etiquetas HTML no la da la W3C sino la forma con la que los navegadores muestran dichas etiquetas resulta dolorosamente cierta. De hecho en ese tercer artículo hay muchos menos comentarios. Sin duda necesitamos algo mejor para el diseño y estamos ignorando años de experiencia con este tema. Seguramente resultaría mucho más sencillo con una especie de GridBagLayout (de Java), pero mientras tanto, lo más parecido son, ciertamente, las viejas tablas de siempre.

Via Ajaxian.

La herencia como anti-esquema

Aún existe demasiada gente que considera que la herencia es algo bueno. Justo la misma gente que, acostumbrados a ella en lenguajes como Java, está presionando para que Javascript la adopte. Pero ¿tan positiva es?

Tal y como afirman Kas Thomas, Joshua Bloch o Bernard Sumption, la herencia viola el principio de encapsulación y tiende a convertirse en un anti-esquema (antipattern) ya que requiere que los hijos conozcan el funcionamiento de los padres. Además la polución en las clases heredadas resulta evidente: la clase JMenu de java contiene 433 métodos, la inmensa mayoría heredados. Un cambio en un método ancestro puede romper los hijos de forma inesperada. Y para muestra, un botón de la propia documentación de Java para la clase Properties:

Puesto que Properties hereda de Hashtable, los métodos put y putAll pueden ser aplicados también a un objeto Properties. Su uso, sin embargo, está fuertemente desaconsejado ya que permiten que el llamante inserte entradas cuyas claves o valores no sean Strings. El método setProperty debe usarse en su lugar. Si los métodos store o save son llamados sobre un objeto Properties "comprometido" que contiene una clave o valor que no sea String, la llamada fracasará.

Si Brendan Eich optó por los prototipos fue por algo. Pero sus motivaciones son totalmente desconocidas para toda esa horda de programadores (provenientes de Java en su mayor parte) que insisten en que Javascript soporte este imperfecto o polémico mecanismo. Gosling, Eich, Bloch, Holub, saben de lo que hablan.

Bespin, editando en la nube

Bespin es la última creación de Mozilla Labs. Resultaba curioso que se hayan portado aplicaciones tan complejas como hojas de cálculo o procesadores de texto y algo tan básico para un programador como un entorno de programación siguiese sin tener su versión basada en web.


Usando la propiedad canvas, se puede ver un prototipo funcional de un entorno básico pero atractivo orientado a la edición de archivos tal y como se haría con un editor tradicional de escritorio. Entre sus cualidades:

• Fácil de usar
• Permite edición compartida (varios programadores) en tiempo real
• Línea de comandos integrada (como la consola de Firebug o Ubiquity)
• Extensible y auto-alojado
• Rápido y reacciones sin retardos
• Accesible desde cualquier sitio

Todo el proyecto está creado sobre Thunderhead un experimento para crear un toolkit para el soporte de interfícies de usuario sobre Canvas que explicarán en breve. Aún se trata de una beta, por ejemplo no soporta la combinación de teclado CTRL-SHIFT-FLECHAIZQ que utilizo habitualmente para seleccionar texto palabra a palabra.

Lo cierto es que personalmente echaba en falta esta herramienta, y pensaba que lo lógico hubiese sido optar por XUL y crear una herramienta más compacta. Pero parece que las posibilidades de Canvas son muchas, y en breve vamos a ver aparecer aplicaciones mucho más avanzadas, de las que hasta ahora estaban condenadas a utilizarse en el escritorio.



Bespin. Pruébalo aquí.

Un experimento esperanzador con OpenID

Simon Willison comenta el reciente experimento realizado por Plaxo junto con Google para facilitar las altas en su página usando el estándar OpenID.

Es bien sabido que los usuarios son reacios a reutilizar una cuenta OpenID o, directamente, no comprenden los beneficios de no tener que ir dando de alta cuentas en cada una de las páginas que les ofrecen un servicio. Si bien se han mejorado ciertos aspectos como el de permitir usar una dirección de email (algo mucho más estándar para identificar una persona) en lugar de una URL, la adopción por el usuario medio es casi anecdótica.

A esto hay que añadirle que las webs sociales, tan de moda, han tomado la mala costumbre de solicitar el nombre de usuario y contraseña de otros sitios con el fin de acceder (scraping) a la información de los contactos existentes del usuario. El estándar OAuth se creó con la idea de dar el control al usuario de lo que quiere compartir. Pero la adopción está siendo lenta y, de nuevo, el usuario no entiende las ventajas.

Por todo ello, el experimento llevado a cabo por Plaxo resulta ciertamente esperanzador: un 92% de los usuarios consiguieron registrarse correctamente y un 84.6% facilitó su lista de contactos a Plaxo. Todo ello con dos simples clics y sin tocar el teclado. ¿Cómo?

Lo cierto es que resulta extraño que no se hiciese antes. El 73% de los usuarios tiene abierta una sesión con Google, Yahoo!, Microsoft o AOL. En Plaxo detectan el primer caso (Google) y ofrecen al usuario registrarse directamente con sólo confirmar en una página de Google qué se quiere compartir (el nombre de usuario o también la lista de contactos). Internamente Google ofrece a Plaxo la información que el usuario ha aceptado compartir, creando Plaxo automáticamente la cuenta para dicho usuario sin que haya tenido que hacer nada más. Un clic de ida (hasta Google) y otro de vuelta (hasta Plaxo) con la cuenta ya creada y el usuario ingresado.

No hace falta decir que el experimento que debería haber durado un tiempo limitado ha sido prolongado indefinidamente por orden directa de la directiva de Plaxo ante unos resultados mucho más positivos de lo esperado. Esperemos que el ejemplo se difunda rápidamente.

Ver la presentación de los resultados del experimento en SlideShare.

Designing Web Interfaces

Este libro de O'Reilly no trata sobre arquitectura de la información (aunque se mencionen sus principios con cierta frecuencia) ni sobre diseño visual (aunque se reconozcan patrones de buen diseño) sino sobre el diseño interactivo para aplicaciones web.

Seis principios de diseño subyacen en los más de 70 patrones que se explican en el libro:

1. Hacer las cosas directas
2. Mantener la ligereza
3. Permanecer en la página
4. Facilitar una invitación
5. Usar transiciones
6. Reaccionar inmediatamente

Explorar el libro. Comprar en Amazon ($31.49). designingwebinterfaces.com.

Un par de trucos usando operadores

Via Dreaming in Javascript:

i=12.34;
k=~~i; // k==12, que es mucho más rápido que:
k=Math.floor(i); // k==12
// también se pueden usar los siguientes métodos:
k= i^0;
k= i<<0

// dividir un número de 16 bits (0-65535) en dos bytes:
lo = i & 255;
hi = i >> 8;
// que resulta mucho más rápido que el tradicional:
lo = i % 256;
hi = (i-lo)/256;

Otras opciones pueden surgir leyendo la referencia sobre operaciones lógicas a nivel de bits.

Brainfuck y Core War

Gracias a Trivium (un excelente blog de enlaces, hoy he descubierto ES, un proyecto para crear un sistema operativo creado totalmente sobre JavaScript y también Brainfuck (Wikipedia/Español, un lenguaje de programación esotérico con tan sólo 8 instrucciones:

Código	Significado	Equivalente en C
>	incrementa el puntero de datos para que apunte a la siguiente casilla (a la derecha).	++ptr
<	decrementa el puntero de datos para que apunte a la anterior casilla (a la izquierda).	--ptr
+	incrementa (+1) el byte señalado por el puntero de datos.	++*ptr
-	decrementa (-1) el byte señalado por el puntero de datos.	--*ptr
.	muestra el valor del byte señalado por el puntero de datos.	putchar(*ptr)
,	acepta un byte de entrada y almacena su valor en el byte señalado por el puntero de datos.	*ptr=getchar()
[	si el byte señalado por el puntero es cero, en lugar de mover el puntero de instrucciones adelante al siguiente comando, salta hasta el comando detrás del ] correspondiente.	while (*ptr) {
]	si el byte señalado por el puntero no es cero, en lugar de continuar la ejecución con el siguiente comando, salta de vuelta al [ correspondiente.	}

Me recuerda exageradamente a Core Wars (aunque hay otros: Ook!, Tink). Constaba de un conjunto reducido de instrucciones con el que se confeccionaba un programa que combatía contra otro en una memoria circular con el objetivo de hacer que el otro programa ejecutase una instrucción DAT prohibida. Algunos lo vinculan con el primer gusano de la historia y el precedente de los virus. En cualquier caso, se trata de una forma excelente de despertar el gusanillo de la programación.

En este artículo se relata la experiencia que va adquiriendo un nuevo usuario conforme va experimentando con las posibilidades del entorno. El lenguaje especificado anteriormente permite crear un simple programa que tiene como objetivo capturar la bandera (poner un byte en una posición específica a cero) del oponente dificultando que haga lo mismo con la propia.

El tamaño de la memoria de juego es aleatorio (entre 135 y 167 bytes) y está inicializada a cero. Ambas banderas se marcan con un 128. La bandera propia está en la casilla de más a la izquierda y la del oponente en cualquier posición hacia la derecha. Se gana cuando se consigue marcar la bandera del oponente con un cero, y se pierde cuando el oponente hace lo mismo o el puntero de programa se sale de la memoria en alguno de los extremos.

Una estrategia simple sería moverse hacia la derecha poniendo a 0 cualquier byte que no lo sea:

[>[-]-]

Pero este consigue muy poca puntuación. Probando con un señuelo se puede frenar al adversario:

>+>->+>->+>->+>->+>-[>[-]-]

Este programa marca las primeras casillas (junto a la bandera) con una secuencia de 1 y -1 (que equivale a 255 por ser un byte). Eso hace que no importa si el adversario utiliza incrementos o decrementos para conseguir poner a cero un byte. En cualquier caso se retrasará centenares de ciclos.

Para evitar que el adversario nos haga lo mismo a nosotros, podemos incrementar una posición la casilla antes de entrar en un bucle que decremente hasta cero el valor. Con esto conseguimos que si la casilla contiene un -1, conseguiremos ponerla a cero enseguida sin entrar en un costoso bucle (254 iteraciones).

>+>->+>->+>->+>->+>-[>+[-]-]

También podemos prevenir que el adversario se beneficie de esta técnica usando +3 y -3 como valores de guarda cerca de la bandera:

>+++>--->+++>--->+++>--->+++>--->+++>---[>+[-]-]

Por último, sabiendo que la bandera enemiga está en el rango 135-167, podemos saltar rápidamente hasta la posición 135:

>+++>--->+++>--->+++>--->+++>--->+++>---
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>
+[>+[-]-]

Con cada versión hemos mejorado la puntuación obtenida al hacer combatir el programa con los mejores 15 adversarios de esta página.

Opera también actualiza su motor Javascript

Tal y como anuncian en su blog, Carakan es el nombre de un nuevo motor que promete multiplicar la velocidad del motor actual en 2.5 veces. Sus características son la generación de bytecodes (código semi-compilado) basado en registros en lugar de uno basado en pilas, lo que implica menos código al no tener que lidiar con operaciones de entrada y salida de la pila; generación de código nativo para partes sensibles del lenguaje; y clasificación automática de objetos, de forma que cada objeto tiene asignada una clase que reune la información sobre dicho objeto (prototipo y propiedades).

También anuncian Vega, su nueva librería gráfica (SVG, Canvas, ...)

Via Ajaxian.

Prácticamente el único navegador que queda por "actualizar" es el travieso Internet Explorer. Personalmente creo que el cambio de prioridades en el seno de Microsoft está perjudicando seriamente el avance que tecnológicamente deberíamos ya estar experimentando. Si Microsoft no quiere (o no puede) estar a la altura de otras iniciativas de fuente abierta, debería abrir el código fuente de su navegador para que la comunidad sea la que se encargue de hacer ese trabajo de "actualización".

JSINQ o Linq para Javascript

Linq es una propuesta de Microsoft para su .NET que facilita la especificación consultas o procesos de datos mediante un lenguaje sencillo (casi natural), que recuerda a SQL.

Wikipedia: LINQ define operadores de consulta estándar que permiten a lenguajes habilitados con LINQ filtrar, enumerar y crear proyecciones de varios tipos de colecciones usando la misma sintaxis. Tales colecciones pueden incluir arreglos, clases enumerables, XML, conjuntos de datos desde bases de datos relacionales y orígenes de datos de terceros.

Con el proyecto de Kai Jäger, es posible utilizar expresiones como la siguiente para realizar consultas que afectan a objetos Javascript:

from customer in $0
group customer by customer.lastname into g
select {lastname: g.getKey(), count: g.count()}
into r
orderby r.count descending
select r

traducible a grosso modo por:

de cliente en $0
agrupa cliente por cliente.apellido en g
selecciona {apellido:g.getKey(), cuenta:g.count() }
introducir en r
ordenar por r.cuenta descendente
seleccionar r

Como extra, el proyecto ofrece la posibilidad de compilar a Javascript las consultas de forma que se puedan utilizar directamente sin necesidad de parsearlas y ganando así en velocidad...



Entorno de prueba.

Via Ajaxian.