digitta

Las aplicaciones web en 2010. Thin Server Architecture

2010-01-25T22:09:00.003+01:00

Aviso que se trata de un artículo un poco largo en el que trato las tecnologías web más actuales relacionadas con Javascript y el cambio de paradigma que se está produciendo con la capa de presentación en las aplicaciones web.

Hay algunos artículos (por ejemplo 1,2,3) que hacen hincapié en la que probablemente constituya la nueva plataforma web más importante de la década. La combinación de las mejoras y los estándares que rodean a ECMAScript (Javascript) junto con los nuevos motores que han multiplicado en varios factores la velocidad del lenguaje, el interés por AJAX y nuevas formas de comunicación (Comet, Google SPDY, websockets nativos), y los proyectos emergentes que no dejan de aparecer para usar el lenguaje en el lado del servidor, se están uniendo para empujar el desarrollo web basado en Javascript hacia la vanguardia de la tecnología web. Puede que los entornos corporativos tarden más en aceptar la simplicidad, flexibilidad y del lenguaje, al igual que resisten con XML respecto a JSON o con Java respecto a Ruby o Python, pero es cuestión de tiempo que la fuerza que alberga un lenguaje extremadamente simple y a la vez extremadamente potente salga a flote y por fin se le haga justicia. Recordemos que JS parte con una resistencia adicional y es que muchos programadores, especialmente de Java, mantienen cierto grado de odio hacia el lenguaje, procedente de la falta de distinción entre el lenguaje en sí, que apenas varía entre navegadores, y la patética implementación del DOM en cada navegador.

La capa de presentación ahora en el navegador

Gmail supuso un antes y un después en la tecnología web. Sigue siendo la aplicación modelo, la que demuestra que es posible tener un aplicativo casi tan rápido como el de escritorio. Tradicionalmente, la presentación se ha generado en el servidor escupiendo una secuencia HTML que debería ser interpretada por el navegador. Esto es así porque se tiene un control de la salida desde el punto en el reside la lógica de negocio. Recientemente se ha extendido el paradigma MVC (Modelo-Vista-Controlador) que permite separar de forma lógica estas tres capas de una aplicación de forma que el código pueda crecer fácilmente sin que la mantenibilidad de ésta se resienta. Sin embargo, la forma tradicional de generar ese código HTML a enviar al navegador ha sido mediante templates o lo que es mucho peor: entrelazando código del servidor de aplicaciones con el de presentación hasta alcanzar límites como el siguiente (fuente):

<select name="type">
<c:forEach items="${types}" var="type">
<option value="${type.id}"
<c:if test="${item.defaultType == type.id}">
 selected</c:if>>
<c:out value="${type.name}"/>
</option>
</c:forEach>
</select>
<input type="button" value="Add <c:out
value="${item.name}"/> to cart"
onClick="addItem('<c:out value="${item.guid}"/>')"/>

Los problemas que esta arquitectura, utilizada ampliamente en la actualidad, presenta son innumerables, entre ellas:

Mala distribución de la potencia de procesamiento. Prácticamente todo el trabajo lo realiza el servidor, a pesar de que los clientes a los que se sirve la aplicación tienen potentes máquinas que apenas se aprovechan.
Modelo de programación complicado, ya que toda interacción con el servidor implica una interfície de petición/respuesta, que además genera esperas al usuario.
Mayor vector de ataque y, por tanto, menor seguridad. Entremezclar lógica de negocio con la presentación supone que el crecimiento de la aplicación genere nuevos puntos débiles en la seguridad por la que ésta puede ser atacada.
Consumo elevado de memoria en el servidor para mantener estructuras de datos sobre las sesiones abiertas por los usuarios.
Uso ineficiente de los recursos de conexión al requerir que documentos relativamente extensos en HTML (o sea, poco optimizados para el ancho de banda) sean enviados al navegador para cualquier cambio de estado en la aplicación.
Complicación a la hora de generar la versión offline de las aplicaciones web. Una capa de presentación generada por el servidor necesita de conexión para ser accesible desde el navegador. Readaptar la aplicación para ello implicará, probablemente, reescribir entera dicha capa a parte de la lógica propia del funcionamiento offline.

La aparición de frameworks como jQuery, MooTools, Prototype o Dojo han eliminado la parte de peor fama que injustamente cargaba Javascript: la de las incompatibilidades con el modelo de objetos del documento o DOM. Y con ello han aparecido las mejores partes del lenguaje. Además, una serie de proyectos están facilitando no ya la manipulación de los elementos generados en las que destacan las frameworks anteriores, sino la creación de dichos elementos para constituir complejas interfícies de usuario desde el mismo navegador. Por ejemplo:

El estándar E4X (ECMAScript for XML) permite definir elementos directamente como variables JavaScript:

var sales = <sales vendor="John">
  <item type="peas" price="4" quantity="6"/>
  <item type="carrot" price="3" quantity="10"/>
  <item type="chips" price="5" quantity="3"/>
</sales>;

alert( sales.item.(@type == "carrot").@quantity );
alert( sales.@vendor );
for each( var price in sales..@price ) {
alert( price );
}

JAML permite definir elementos usando una sintaxis muy sencilla basada en llamadas a funciones:

div(
h1("Un titulo"),
p("Un texto o parrafo cualquiera"),
br(),
ul(
 li("Primer item"),
 li("Segundo item"),
 li("Tercer item")
)
);

JSONML es una aplicación del formato JSON que puede representar XHTML perfectamente:

[ "ul", { style : "list-style-type:none"},
 [ "li",
   "Primer item"],
 [ "li",
   "Segundo item"],
 [ "li",
   "Tercer item"],
 ];

El Zen-coding es un formato pensado para generar código XHTML rápidamente en un editor de texto, pero más de uno ha adaptado a jQuery o Mootools la misma sintaxis permitiendo, por ejemplo, generar el mismo código XHTML del ejemplo anterior con la cadena ul>jQuery('ul li:3[innerHTML="item"]').satisfy(); o $('body').zen('ul>li*3>span');

Una de las ventajas de dejar la parte de presentación exclusivamente al navegador es que es posible utilizar fácilmente distintas opciones para reescribir la interfície sin tocar la parte del servidor. Por ejemplo, una aplicación web 2.0 pura puede convertirse fácilmente en una aplicación XUL para navegadores Mozilla, o Flash, o Flex, o OpenLaszlo, o un applet Java, o Air, o Titanium, o un framework como Ext.js o Ajax.org, o una aplicación para Android, Palm Pre o iPhone con PhoneGap. Además los clientes web están en medio de un profundo proceso de mejora en el que tendrán disponibles una cantidad de nuevas opciones impensables hasta hoy:

WebSockets que les permitirá mantener una conexión abierta bi-direccional con el servidor, optimizando así la información transmitida, el tamaño de los datos, el tiempo de respuesta y posibilitando la nuevas aplicaciones web en tiempo real (chats, información de bolsa o juegos multijugador, por ejemplo) y dejando AJaX desfasado ante la llegada, por fin, de Comet.
WebWorkers que permitirá que las aplicaciones web puedan disponer de un sucedáneo de la programación concurrente en el navegador, de forma que procesos pesados no hagan más lenta la respuesta de la interfície de cara al usuario.
Web SQL Database para ofrecer el lenguaje SQL en el cliente y posibilitar trabajar offline con una aplicación web.

Javascript en el servidor

Como comentaba al principio, JavaScript está escapando del navegador con una fuerza destacable, sólo achacable a la potencia de un lenguaje bastante viejo que sólo unos pocos han sabido reconocer. No sólo aparece en la capa del servidor de aplicaciones, también lo está haciendo en la base de datos. Dos estándares CommonJS y JSGI están cubriendo rápidamente la falta de acuerdo en un terreno tan cambiante. EL primero define una serie de APIs críticas para construir módulos reutilizables en el entorno del servidor. Por ello cubre facetas como la interacción con la base de datos, el acceso al sistema de archivos, el servidor web o la generación de formatos. El segundo define la forma Javascript con la que interactuar desde el servidor web con las conexiones HTTP, definiendo una representación del protocolo mediante un objeto JSON/Javascript. Entre lo más puntero de la tecnología web en el servidor se encuentra la utilización de bucles asíncronos de eventos para tratar con las conexiones entrantes en lugar de usar hilos del sistema operativo para ello. En las comparaciones entre los servidores NginX y Apache, que siguen precisamente cada una de esas técnicas, se puede ver que no sólo NginX consume mucha menos memoria sino que también es capaz de soportar muchas más conexiones concurrentes. Siguiendo esa misma filosofía han aparecido proyectos como Twisted para Python, EventMachine para Ruby y ahora Node.js para Javascript. Los tres han sido creados de forma que no contienen llamadas bloqueantes como las que se realizan al sistema operativo para leer un archivo. Para ello se basan en un mecanismo que JavaScript ya incorpora de forma natural: las funciones callback que son llamadas cuando el trabajo solicitado ha sido completado, dejando que mientras tanto el sistema siga ejecutando otros procesos del bucle de eventos y, por tanto, incrementando exageradamente el rendimiento. Muchos incorporan un mecanismo llamado promises que permiten escribir código de la forma más parecida al sistema procedimental tradicional (en secuencia) y evitar así romper una misma función como bloque conceptual en varias funciones distintas cada vez que se necesite una llamada bloqueante (acceso a disco, base de datos o nueva conexión). Helma NG es la nueva versión del proyecto activo más antiguo que, siguiendo el estilo MVC ofrecía la posibilidad de usar el motor Rhino de Java y el servidor web Jetty para generar aplicaciones con JS. Pero en relativamente poco tiempo han aparecido muchas más opciones:

Persevere es un servidor de aplicaciones que ofrece una arquitectura REST para intercambiar datos (preferentemente en JSON) con un cliente rico posibilitando así aplicaciones complejas. Así mismo ofrece persistencia de datos, gestión de la seguridad, notificaciones Comet y capacidades avanzadas de comunicación para múltiples plataformas. Con la aparición de nuevas plataformas CommonJS, este proyecto probablemente ofrecerá opciones para instalarse sobre ellos (por ejemplo sobre Node.js).
Flusspferd es un proyecto que aúna SpiderMonkey (el motor de JS en C++) con una serie de módulos (SQLite,GMP,Zest,Juice,cUrl...) para ofrecer un entorno de ejecución muy rápido aunque está un poco verde.
En la misma situación se encuentra EJScript, que además añade algunas extensiones de JavaScript que fueron eliminadas del estándar. Su principal baza es el rendimiento que se acerca al de Node.js pero con una décima parte del consumo de memoria de aquel.
Narwhal es la implementación de CommonJS más avanzada y madura ya que incluye todos sus módulos, ofreciendo soporte completo de entrada/salida, una colección de módulos de librería, un sistema de gestión de paquetes llamado tusk y se ha diseñado para funcionar sobre varias plataformas Javascript.
node.js está generando una auténtica riada de reacciones en la comunidad web. Básicamente porque mata tres pájaros de un tiro: consigue un rendimiento escandaloso para tratarse de Javascript aunando el motor V8 y su filosofía asíncrona; su tratamiento de bajo nivel de las conexiones permite usarlo como servidor HTTP pero también Comet adelantándose al futuro; y aprovecha el mecanismo de funciones callback al que estamos más que acostumbrados los programadores. Actualmente está muy bien posicionado para coronarse en el rey de los servidores de aplicaciones basados en lenguajes dinámicos. Además se espera que Narwhal funcione sobre Node con las ventajas adicionales de un sólido software orientado totalmente a la gestión segura de datos en el servidor. Como limitaciones: es demasiado inmaduro porque acaba de ser publicado; de momento sólo implementa el sistema de módulos de CommonJS y no el resto de APIs; aún no puede aprovechar los servidores con varios núcleos; no soporta la especificación JSGI.
appjet.com era un entorno de ejecución de aplicaciones JS basado en Rhino/Java. Por desgracia ha sido comprado por Google y el enlace de descarga del archivo .jar que contenía todo el entorno ya no está accesible.
Aptana Jaxer también se adelantó en unos meses a su tiempo. Enfocaron el desarrollo en incorporar el motor de renderizado Mozilla Gecko en el lado del servidor y en reutilizar el mismo código en cliente y servidor en un sistema que quizá no resulte demasiado intuitivo para el programador tradicional y que fomenta la generación de la presentación en el servidor. Por desgracia, aunque no ha desaparecido, este proyecto también ha sido relegado por la empresa que lo desarrolla.

Futuro

Con todo ello, es fácil plantearse si sería posible realizar hoy día una aplicación web conociendo únicamente JavaScript. La respuesta obvia es que no, pero ya son muy pocas las piezas que quedan:

Datos. Existen ya servidores de bases de datos que hablan JS como CouchDB con su revolucionario enfoque a la hora de realizar consultas de datos basadas en el sistema MapReduce. También MongoDB ofrece una interfície REST para tratar con sus documentos JSON, el formato de datos propio de Javascript. No es casualidad que ambas pertenezcan al ámbito de la las nuevas bases de datos conocidas como NoSQL, donde el paradigma relacional que se ha demostrado como problemático para la escalabilidad es dejado atrás a favor de otras opciones menos rígidas. Se echa en falta un estándar para definir consultas basadas en el lenguaje Javascript. SQL está muy extendido, pero estoy seguro que se puede hacer lo mismo que CouchDB ofrece con menos complejidad. Quizá al estilo de Microsoft Linq pero siguiendo la sintaxis de Javascript, o bien basándose en la base de datos para navegador TaffyDB.
Servidor de aplicaciones. Son muchas las opciones, como he mencionado antes. Pero la amplia adopción de CommonJS crea un rico ecosistema de opciones que otros lenguajes no cubren. Esa variedad que ha aparecido en muy poco tiempo es la mejor prueba de que, probablemente, esta nueva década sea la de la amplia adopción de Javascript. Otros estándares que ya están en el cliente, como los Web Workers o el ya famoso y estudiado XMLHTTPRequest que mueve a AJaX, serían de mucha utilidad en el servidor.
En el navegador se echa en falta un sistema de empaquetado de aplicaciones al estilo los .jar de Java que optimizaría la descarga al no exigir varias conexiones para obtener todos los datos. Otro estándar que echo en falta es un lenguaje basado en JSON, que equivalga a HTML y que sea aceptado por los navegadores. Que index.jsml empezase a sustituir al omnipresente index.html sería un buen paso. Ya hay proyectos que sustituyen el CSS y al XHTML, pero un estándar que, al igual que XUL, permitiese crear formularios optimizados para aplicaciones web podría dar un empuje definitivo que arrinconase más a las aplicaciones tradicionales de escritorio...

Conclusiones

El abanico de estándares, plataformas, bases de datos, motores de interpretación y mecanismos de interoperación que se ha abierto en relativamente poco tiempo abre una cantidad de opciones inmensa que hace posible lo que hasta hace poco era impensable: que la lingua franca de la web gane terreno en el servidor con soluciones de tecnología punta vetadas hasta ahora a plataformas mucho más extendidas como PHP, Java o ASP.NET. Resulta sorprendente como tres pares de símbolos: [] arrays/listas/pilas, {} objetos y () funciones permiten componerse con tanta flexibilidad como para dar cabida a todos estos proyectos y además desafiar el statu quo.

Empezando con Kohana, ¿mejor que CodeIgniter?

2009-12-15T10:03:00.001+01:00

He traducido este tutorial de NetTuts+ creado por Cristian Gilè sobre el framework PHP Kohana, al igual que hice en su día con el de CodeIgniter.

Kohana es un framework de PHP5 que sigue la arquitectura MVC (Modelo-Vista-Controlador). Hay varias razones por las que deberías elegir Kohana, pero las principales son seguridad, ligereza y simplicidad. En este tutorial, introduciré sus características principales y, con una simple demostración, mostraré cuánto tiempo Kohana puede ahorrarte potencialmente.

Paso 1: ¿Qué es Kohana?

Kohana es un framework de PHP5 que sigue la arquitectura MVC. MVC mantiene separadas la lógica de la presentación. Esto permite crear un código más limpio y ahorrar tiempo en la búsqueda de errores. Para los que no estén familiarizados con esta arquitectura:

Un modelo representa datos sobre los que la aplicación opera. Normalmente es una base de datos.
Una vista contiene el código de presentación como HTML, CSS y JavaScript.
Un controlador interpreta la entrada del usuario y redirige al modelo y/o vista.

Kohana era originalmente una escisión de CodeIgniter (CI), que es un producto open source de la empresa EllisLab. Hay muchas similitudes entre CI y Kohana, pero todo el código es nuevo o ha sido completamente reescrito. Tal y como puedes leer en la página oficial de Kohana, las características principales son:

Altamente seguro
Extremadamente ligero
Breve curva de aprendizaje
Utiliza el patrón MVC
100% compatible con la codificación UTF-8
Arquitectura débilmente acoplada
Extremadamente fácil de extender

Paso 2: Descargando Kohana

Empecemos. Visita la página oficial de Kohana y haz click sobre la caja verde de la esquina derecha para descargar la última versión. Todas las bibliotecas, asistentes y vistas de Kohana están incluidos en el paquete de descarga por defecto, pero puedes seleccionar módulos extra, herramientas de terceros, y los lenguajes que desees. Para el propósito de este tutorial, el paquete por defecto será suficiente. Haz click en "Download Kohana!" para iniciar la descarga.

Paso 3: Instalando Kohana

Una vez que se ha terminado la descarga:

Descomprimir el zip
Renombrar la carpeta "Kohana_vx.x.x" (x.x.x=número de versión) a "kohana" y súbela a la carpeta raíz de tu servidor web.
Edita el fichero de configuración global application/config/config.php de esta forma:
$config['site_domain'] = 'localhost/kohana';
Si estás usando un sistema unix (linux, MacOSX), las subcarpetas de la instalación podrían haber perdido sus permisos durante la descompresión del zip. Haz un chmod a 755 de todas ellas ejecutando find . -type d -exec chmod 755 {} \; desde la carpeta raíz de la instalación de Kohana.
Asegúrate de que application/logs y application/cache no sean de sólo lectura. Haz chmod a 666 sobre ellas.
Ahora, apunta el navegador a http://localhost/kohana/ . Automáticamente, el framework llamará a install.php y comprobará los requerimientos con el servidor.

Kohana se ejecutará en prácticamente cualquier entorno que cumpla la configuración mínima:

Servidor con soporte de Unicode
PHP con una versión igual o posterior a la 5.2.3
Un servidor HTTP. Sugiero XAMPP, que es una herramienta sencilla todo-en-uno para instalar MySQL, PHP y Perl.
Una base de datos (MsSQL, MySQL, MySQLi, PostgreSQL, PDOSqlite).

También hay extensiones necesarias:

PCRE
iconv
mcrypt
SPL

Si la instalación se completa con éxito, serás dirigido a esta página de prueba:

Si alguna de las pruebas falla, deberás corregirla antes de continuar.

Si todas las comprobaciones tienen éxito, dirígete a la carpeta de Kohana y elimina o renombra el archivo install.php. Recarga la página en el navegador y verás una página de bienvenida como esta:

Paso 4: Configurando Kohana

Kohana está preparado para funcionar. No se necesita realizar ninguna configuración. Este framework es genial, ¿no te parece? Vamos a ver un poco de código, sígueme.

Paso 5: El primer proyecto con Kohana

Los tutoriales de programación tradicionales empiezan con el ejemplo "hello world". Pero yo creo que una aplicación simple puede dar una idea clara de cómo funciona el framework. Vamos a construir un gestor de colecciones de CDs -- sólo como divertida demostración. Antes de empezar a escribir código es necesaria una introducción breve a la distribución de carpetas de Kohana.

Nuestra aplicación se ubicará en la carpeta application. En esta carpeta hay varias subcarpetas pero sólo necesitamos lo siguiente para nuestro proyecto:

config guarda los archivos de configuración codificados como simples arrays estáticos.
controllers guarda nuestra clase de controladores personalizada
models guarda nuestra clase de modelos personalizada
views guarda nuestro archivos personalizados escritos en HTML (o cualquier lenguaje de markup o scripts necesarios para mostrar los datos y los controles de interfície para el usuario)

El resto de subcarpetas no se necesitan para este tutorial, por lo que te invito a aprender más posteriormente sobre ellos en la página de Kohana.

La carpeta system guarda el núcleo de Kohana y herramientas como bibliotecas (library), asistentes (helper) y archivos de configuración predefinidos. En este proyecto vamos a usar algunas bibliotecas y algunos asistentes - buenas herramientas para acelerar tu trabajo.

La carpeta assets no pertenece a Kohana por defecto. Yo la he creado para guardar archivos estáticos como CSS, JS o imágenes. Después mostraré como incluirlos en el proyecto.

La carpeta modules es el lugar donde guardar las colecciones reusables de archivos relacionados que unidos aportan una funcionalidad particular a una aplicación. El módulo de autenticación de usuarios, ofrecido por el equipo Kohana, es un ejemplo de módulo.

Ésta es una muy breve introducción al sistema de archivos de Kohana, pero es suficiente para los propósitos de este tutorial. No quiero aburrirte con más teoría.

Paso 6: La base de datos del proyecto

He seleccionado MySQL para mi proyecto, pero recuerda que Kohana soporta igualmente MsSQL, MySQLi, PostgreSQL, o PDOSqlite. Crea una base de datos llamada "cd_collection" o elige el nombre que prefieras, y ejecuta la siguiente SQL mediante phpMyAdmin o cualquier herramienta para administrar la base de datos.


CREATE TABLE `albums` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) collate utf8_bin NOT NULL,
  `author` varchar(50) collate utf8_bin NOT NULL,
  `genre_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `genre_id` (`genre_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=19 ;

INSERT INTO `albums` (`id`, `name`, `author`, `genre_id`) VALUES
(2, 'Lines, Vines And Trying Times', 'Jonas Brothers', 16),
(3, 'The E.N.D.', 'The Black Eyed Peas', 16),
(4, 'Relapse', 'Eminem', 18),
(5, 'Monuments And Melodies', 'Incubus', 1),
(6, 'Thriller', 'Michael Jackson', 16),
(7, 'Back in Black', 'AC/DC', 4),
(8, 'The Dark Side of the Moon', 'Pink Floyd', 4),
(9, 'Bat out of Hell', 'Meat Loaf', 4),
(10, 'Backstreet Boys', 'Millennium', 16),
(11, 'Rumours', 'Fleetwood Mac', 4),
(12, 'Come on Over', 'Shania Twain', 16),
(13, 'Led Zeppelin IV', 'Led Zeppelin', 4),
(14, 'Jagged Little Pill', 'Alanis Morissette', 4),
(15, 'Sgt. Pepper''s Lonely Hearts Club Band', 'The Beatles', 16),
(16, 'Falling into You', 'Cv©line Dion', 16),
(17, 'Music Box', 'Mariah Carey', 16),
(18, 'Born in the U.S.A.', 'Bruce Springsteen', 4);

CREATE TABLE `genres` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) collate utf8_bin NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=22 ;

INSERT INTO `genres` (`id`, `name`) VALUES
(1, 'Alternative Rock'),
(2, 'Blues'),
(3, 'Classical'),
(4, 'Rock'),
(5, 'Country'),
(6, 'Dance'),
(7, 'Folk'),
(8, 'Metal'),
(9, 'Hawaiian'),
(10, 'Imports'),
(11, 'Indie Music'),
(12, 'Jazz'),
(13, 'Latin'),
(14, 'New Age'),
(15, 'Opera'),
(16, 'Pop'),
(17, 'Soul'),
(18, 'Rap'),
(20, 'Soundtracks'),
(21, 'World Music');

ALTER TABLE `albums`
  ADD CONSTRAINT `genre_inter_relational_constraint` FOREIGN KEY (`genre_id`) REFERENCES `genres` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

Como puedes ver, el SQL crea dos tablas, álbumes y géneros, y los puebla con algunos datos. La última sentencia SQL agrega una restricción para la clave ajena "genre_id".

La estructura de la base de datos es muy simple y no necesita mayor explicación:

Ahora, debes decirle a Kohana dónde está tu base de datos y cómo acceder a ella. Edita el archivo de configuración global system/config/database.php de esta forma:


$config['default'] = array
(
    'benchmark'     => TRUE,
    'persistent'    => FALSE,
    'connection'    => array
    (
        'type'     => 'mysql',    
        'user'     => 'root',    
        'pass'     => 'root',    
        'host'     => 'localhost',    
        'port'     => FALSE,        
        'socket'   => FALSE,        
        'database' => 'cd_collection'
    ),
    'character_set' => 'utf8',
    'table_prefix'  => '',
    'object'        => TRUE,
    'cache'         => FALSE,
    'escape'        => TRUE
);

Este código le dice a Kohana que se conecte a una base de datos MySQL llamada "cd_collection" en localhost con el nombre de usuario "root" y la clave "root". Debes cambiarlas de acuerdo con tu configuración de servidor de base de datos.

Paso 7: Creando el controlador

Creémos nuestro primer controlador. Recuerda estas convenciones:

el nombre de archivo del controlador debe estar en minúsculas, por ejemplo album.php
la clase controlador debe coincidir con su nombre de archivo pero iniciada con mayúscula y debe añadir _Controller, por ejemplo Album_Controller
Debe tener la clase Controller como padre

Igualmente, recuerda cómo Kohana estructura sus URLs y cómo puedes llamar a un método de controlador; por ejemplo http://hostname/carpeta_de_kohana/index.php/controller/function

Echa un vistazo a este simple controlador.


<?php defined('SYSPATH') OR die('No direct access allowed.');

class Album_Controller extends Controller
{ 
    public function __construct()    
     { 
        parent::__construct();
    }
     
    public function index()
     {
           echo "My first controller";    
    }
}

PHP5 OOP (programación orientada a objetos) es un prerrequisito. Para aprender más sobre ello, puedes leer aquí.

La función constructor, llamada __construct, inicializa la clase y llama al constructor padre. La función index es la función por defecto, por lo que será usada si llamamos al controlador sin especificar una función (por ejemplo, http://localhost/index.php/kohana/album. Tras el nombre del controlador no hay ninguna función, la función de índice será llamada por defecto).

Dadas estas reglas básicas, enfoquémonos en la aplicación. El controlador de album implementa todas las acciones para la gestión de colección de álbumes. Este controlador nos permite crear un nuevo álbum, mostrar los álbumes guardados en la base de datos, actualizar un álbum o borrar un álbum.

Crea un archivo llamado album.php en application/controllers/ y pega los siguiente:


<?php defined('SYSPATH') OR die('No direct access allowed.');
    
class Album_Controller extends Controller
{
     private $album_model; 
     private $genre_model;
     
     private $list_view;
     private $create_view;
     private $update_view;
 
    public function __construct()    
     { 
        parent::__construct();
        $this->album_model   = new Album_Model;
        $this->genre_model      = new Genre_Model;
          $this->list_view       = new View('list');
          $this->update_view      = new View('update');
          $this->create_view      = new View('create');
    }
 
     public function index()
     {
          $this->show_albums_list();
     }
        
    private function show_albums_list()
    {
        $albums_list = $this->album_model->get_list(); 
        $this->list_view->set('albums_list',$albums_list);
        $this->list_view->render(TRUE); 
    }
    
     public function show_create_editor()
     {
         $this->create_view->set('genres_list',$this->get_genres_list());
           $this->create_view->render(TRUE);
     }
 
     public function show_update_editor($id)
     {
        $album_data = $this->album_model->read($id);
        $this->update_view->set('album_id',$album_data[0]->id);
        $this->update_view->set('name',$album_data[0]->name);
        $this->update_view->set('author',$album_data[0]->author);
        $this->update_view->set('genre_id',$album_data[0]->genre_id);
        $this->update_view->set('genres_list',$this->get_genres_list());
        $this->update_view->render(TRUE);
     }
 
     public function create()
     { 
        $album_data=array(
        'name'        => $this->input->post('name'),
        'author'      => $this->input->post('author'),
        'genre_id'  => $this->input->post('genre_id')
        );
        $this->album_model->create($album_data);
        url::redirect('album');
     }
 
    public function update()
    { 
        $album_data = array(
            'name'        => $this->input->post('name'),
            'author'      => $this->input->post('author'),
            'genre_id'  => $this->input->post('genre_id')
        );
        $this->album_model->update($this->input->post('album_id'),$album_data);
           url::redirect('album');
     }
  
      public function delete($id)
     {
        $this->album_model->delete($id);
        url::redirect('album');
     }
 
    private function get_genres_list()
    {
        $db_genres_list  = $this->genre_model->get_list(); 
        $genres_list  = array();
        
        if(sizeof($db_genres_list) >= 1)
        {
            foreach($db_genres_list as $item)
            {
                $genres_list[$item->id] = $item->name;
            }
        }
        return $genres_list;
     }
}

Déjame explicar lo que hace este código.

Se declaran cinco variables miembro al inicio:


  private $album_model; 
  private $genre_model;

  private $list_view;
  private $create_view;
  private $update_view;

Estos miembros son privados porque quiero limitar su visibilidad sólo a esta clase.

En el método construct los objetos de modelo y vista son creados usando los cinco miembros:


  $this->album_model   = new Album_Model;
  $this->genre_model      = new Genre_Model;
  $this->list_view       = new View('list');
  $this->update_view      = new View('update');
  $this->create_view      = new View('create');

Para crear un objeto modelo usa esta sintaxis:

$obj_name = new Name_Model;

Para crear un objeto vista, usa esta sintaxis:

$obj_name = new View('view_filename_without_extension');

Ahora hay dos objetos para acceder al modelo de álbum y género, y tres objetos para acceder a las vistas necesarias para generar la presentación.

El método index llama al método show_albums_list que lista todos los álbumes guardados en la base de datos.

$albums_list = $this->album_model->get_list();   
$this->list_view->set('albums_list',$albums_list);  
$this->list_view->render(TRUE);

En este método puedes ver cómo el modelo y la vista objeto son usada para acceder a métodos relativos. "get_list" es un método del modelo (lo veremos luego) que devuelve todos los álbumes guardados en la base de datos. El resultado se guarda en el array "$album_list". Para pasar el array de resultados del controlador a la vista, el método "set" del objeto vista es llamado. Este método requiere dos parámetros: una nueva variable vacía (album_list) contiene datos de una variable existente ($album_list). Ahora la nueva variable vacía "album_list" contine el array $album_list (veremos después como mostrar su contenido en la vista). El método "render", con el parámetro TRUE, es necesario para generar datos para el navegador.

El método show_create_editor muestra la interfície de usuario para insertar un nuevo álbum.

   1. $this->create_view->set('genres_list',$this->get_genres_list());
$this->create_view->render(TRUE);

La lista de géneros es pasada a la vista.

El método show_update_editor muestra la interfície de usuario para actualizar un álbum existente.


$album_data = $this->album_model->read($id);  
$this->update_view->set('album_id',$album_data[0]->id);  
$this->update_view->set('name',$album_data[0]->name);  
$this->update_view->set('author',$album_data[0]->author);  
$this->update_view->set('genre_id',$album_data[0]->genre_id);  
$this->update_view->set('genres_list',$this->get_genres_list());
$this->update_view->render(TRUE);

"read" es un método del modelo (lo veremos después) que devuelve datos ($album_data) del álbum con un identificador igual a $id. Entonces, cada elemento del álbum de datos devuelto es pasado a la vista.

El método create recibe datos para un nuevo álbum a partir de la vista y guarda los datos recibidos en la base de datos.

$album_data=array(  
'name'      => $this->input->post('name'),  
'author'    => $this->input->post('author'),  
'genre_id'  => $this->input->post('genre_id')  
);  
$this->album_model->create($album_data);  
url::redirect('album');

$album_data es un array que contiene los datos POST de la vista. Para guardar el álbum, el array se pasa al método del modelo create. La última línea es una llamada a un método asistente. Los asistentes (helpers) son funciones que te asisten en el desarrollo. Las clases asistente son automáticamente cargadas por Kohana. Los asistentes se declaran como métodos estáticos de una clase, por lo que no hay necesidad de instanciar la clase. En este caso, el método "redirect" del asistente "url" es llamado y le dice a Kohana que redirija el navegador al controlador de álbum. Esto evita una nueva inserción (por ejemplo, al pulsar F5).

Los métodos update (actualizar) y delete (borrar) funcionan de la misma forma que create.

El último método get_genres_list obtiene la lista de géneros del modelo ($db_genres_list) y construye un nuevo array ($genres_list) para el control de selección (select) en las vistas.

$db_genres_list  = $this->genre_model->get_list();   
$genres_list  = array();  
  
if(sizeof($db_genres_list) >= 1)  
{  
    foreach($db_genres_list as $item)  
    {  
        $genres_list[$item->id] = $item->name;  
    }  
}  
return $genres_list;

Paso 8: Creando el modelo para el proyecto

Creemos los modelos para nuestra aplicación web. Conviene recordar las convenciones indicadas anteriormente a la hora de crear las clases. A continuación está el código para el modelo del álbum. Crea un archivo llamado album.php en application/models/ y pega en él el siguiente código:


<?php defined('SYSPATH') OR die('No direct access allowed.');

class Album_Model extends Model
{
     private $album_table;
     private $genre_table; 
 
      public function __construct()
        {
              parent::__construct();
          $this->album_table = 'albums';
        $this->genre_table = 'genres';
      }
  
      public function read($id)
      {
        $this->db->where('id', $id);
        $query = $this->db->get($this->album_table); 
          return $query->result_array();
     }
      
    public function delete($id)
      {
        $this->db->delete($this->album_table, array('id' => $id));
      }
  
      public function update($id,$data)
      {
        $this->db->update($this->album_table, $data, array('id' => $id));
      }
      
    public function create($data)
      {
           $this->db->insert($this->album_table, $data);
      }
     
    public function get_list()
     {
          $this->db->select('albums.id as id,albums.name as name,albums.author as author, genres.name as genre');  
          $this->db->from($this->album_table);  
          $this->db->join($this->genre_table,'genres.id','albums.genre_id');
           $query = $this->db->get();
          return $query->result_array();
    }
}

Todos los métodos de los modelos usan la sintaxis del constructor de consultas (Query builder). Esta herramienta de Kohana acelera el tiempo de desarrollo con bases de datos y simplifica la creación de consultas.

Dos variables miembro son declaradas al inicio de la clase:

private $album_table;  
private $genre_table;

Estos miembros son privados porque quiero limitar la visibilidad sólo a esta clase. Son los contenedores de los nombres de las tablas de la base de datos.

La primera línea en el método del constructor carga la biblioteca de base de datos de Kohana en $this->db. En las dos siguientes líneas, se inicializan las dos variables miembro.

parent::__construct();  
$this->album_table = 'albums';  
$this->genre_table = 'genres';

La consulta en el método read recupera los registros de álbum que tengan un cierto identificador ("$id").

$this->db->where('id', $id);  
    $query = $this->db->get($this->album_table);   
        return $query->result_array();

La consulta en el método delete elimina la fila de la tabla de álbumes que tenga un cierto identificador ("$id").

$this->db->delete($this->album_table, array('id' => $id));

La consulta en el método update actualiza la fila de la tabla de álbumes que tenga un cierto identificador ("$id") con los nuevos valores del array "$data".

$this->db->update($this->album_table, $data, array('id' => $id));

El array "$data" debe contener nombres de registros como claves del array, y sus valores como valores del array. El array debe tener esta forma:

$data = array(  
    'name'          =>   'album_name',  
    'author'        =>   'author_name',  
    'genre_id'      =>   'genre_id'    
    );

La consulta en el método get_list recupera todas las filas de álbumes.

$this->db->select('albums.id as id,albums.name as name,albums.author as author, genres.name as genre');    
$this->db->from($this->album_table);    
$this->db->join($this->genre_table,'genres.id','albums.genre_id');  
$query = $this->db->get();  
return $query->result_array();

Ahora el modelo para los géneros. Crea un archivo llamado genre.php en application/models/ y pega el siguiente código en él:

<?php defined('SYSPATH') OR die('No direct access allowed.');

class Genre_Model extends Model
{
  private $genre_table;

  function __construct()
  {
    parent::__construct();
    $this->genre_table = 'genres';
  }

  function get_list()
  {
    $query = $this->db->get($this->genre_table);
    return  $query->result_array();        
  }
}

Este modelo es muy simple, por lo que no malgasteré tiempo comentándolo. Los modelos y el controlador están preparados para funcionar. Ahora trabajemos sobre las vistas.

Paso 9: Creando la vista del proyecto

Las vistas son archivos que contienen la capa de presentación de la aplicación. Su propósito es mantener esta información separada de la lógica de la aplicación para facilitar la reusabilidad y mantener el código limpio. Para este proyecto se necesitan tres vistas: una para listar la colección de álbumes, otra para crear un nuevo álbum, y otra para editar un álbum existente.

Crea un archivo llamado list.php en application/views/ y pega el siguiente código en él:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<?php
    echo html::stylesheet(array
        (
         'assets/css/style'
        ),
        array
        (
         'screen'
        ), FALSE);
?>
        <title>CD COLLECTION</title>
        </head>
        <body>
        <?php 
                echo html::image('assets/images/add.png');
                echo html::anchor('album/show_create_editor', 'Add new album'); 
        ?>
        <table class="list" cellspacing="0">
        <tr>
            <td colspan="5" class="list_title">CD Collection</td>
        </tr>    
        <tr>
            <td class="headers">Album name</td>
            <td class="headers">Author</td>
            <td colspan='3' class="headers">Genre</td>
        
        </tr>    
        <?php
            foreach($albums_list as $item)
            {
                echo "<tr>";
                echo "<td class='item'>".$item->name."</td>";
                echo "<td class='item'>".$item->author."</td>";
                echo "<td class='item'>".$item->genre."</td>";
                echo "<td class='item'>".html::anchor('album/delete/'.$item->id,html::image('assets/images/delete.png'))."</td>";        
                echo "<td class='item'>".html::anchor('album/show_update_editor/'.$item->id,html::image('assets/images/edit.png'))."</td>";        
                echo "</tr>";
            }
        ?>
        </table>
        </body>
        </html>

Esta vista muestra una página html que contiene una lista de todos los álbumes. Esta lista ha sido creada usando un bucle foreach que imprime la información en una tabla html. Para cada fila de álbum, hay dos imágenes: una "cruz roja" y una "libro de bolsillo". Enlazan respectivamente al método delete y al método update del controlador. Ambos pasan el identificador del álbum al controlador usando una petición GET. Sobre la lista hay un botón para crear un nuevo álbum. En este código también se usa un asistente html ofrecido por Kohana que acelera las operaciones para escribir páginas html.

Creémos ahora un archivo llamado create.php en application/views/.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<?php
    echo html::stylesheet(array
    (
        'assets/css/style'
    ),
    array
    (
        'screen'
    ), FALSE);
?>
<title>CD COLLECTION</title>
</head>
<body>
<?php echo form::open('album/create'); ?>
<table class='editor'>
<tr>
    <td colspan='2' class='editor_title'>Create new album</td>
</tr>
<?php
    echo "<tr>";
    echo "<td>".form::label('name', 'Name: ')."</td>";
    echo "<td>".form::input('name', '')."</td>";
    echo "</tr>";
    
    echo "<tr>";
    echo "<td>".form::label('author', 'Author: ')."</td>";    
    echo "<td>".form::input('author', '')."</td>";    
    echo "<tr/>";
    
    echo "<tr>";
    echo "<td>".form::label('genre', 'Genre: ')."</td>";    
    echo "<td>".form::dropdown('genre_id',$genres_list)."</td>";
    echo "<tr/>";
    
    echo "<tr>";
    echo "<td colspan='2' align='left'>".form::submit('submit', 'Create album')."</td>";
    echo "</tr>";
?>
</table>
<?php echo form::close(); ?>
</body>
</html>

La última es la vista de actualización. Crea un archivo update.php en application/views/.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<?php
    echo html::stylesheet(array
    (
        'assets/css/style'
    ),
    array
    (
        'screen'
    ), FALSE);
?>
<title>CD COLLECTION</title>
</head>
<body>
<?php echo form::open('album/update'); ?>
<table class='editor'>
<tr>
    <td colspan='2' class='editor_title'>Update album</td>
</tr>
<?php
    echo "<tr>";
    echo "<td>".form::label('name', 'Name: ')."</td>";
    echo "<td>".form::input('name', $name)."</td>";
    echo "</tr>";
    
    echo "<tr>";
    echo "<td>".form::label('author', 'Author: ')."</td>";    
    echo "<td>".form::input('author', $author)."</td>";    
    echo "<tr/>";
    
    echo "<tr>";
    echo "<td>".form::label('genre', 'Genre: ')."</td>";    
    echo "<td>".form::dropdown('genre_id',$genres_list, $genre_id)."</td>";
    echo "<tr/>";
    
    echo "<tr>";
    echo "<td colspan='2' align='left'>".form::submit('submit', 'Update album')."</td>";
    echo "</tr>";
    
?>
</table>
<?php 
    echo form::hidden('album_id',$album_id);
    echo form::close(); 
?>
</body>
</html>

El primero es un editor simple que permite al usuario insertar información sobre un nuevo álbum. Los campos como autor y nombre serán insertados usando una entrada html y el género usando un combo. Una vez que el usuario hace click en el botón create, toda la información se pasa como una petición POST al método create/update del controlador de álbum. Cuando el controlador recibe estas variables posteadas llama al modelo que inserta un nuevo álbum en la base de datos. Los formularios de ambas vistas hacen uso del asistente de formularios.

Para dar un poco de estilo a nuestra aplicación, crea la carpeta assets en la carpeta raíz de Kohana al mismo nivel de la carpeta de aplicaciones. Ábrelo y crea dos nuevas carpetas: css e images.

En la carpeta css crea un nuevo archivo llamado style.css y pega lo siguiente en él:

a {
    font-family: Verdana, Geneva, Arial, Helvetica, sans-serif ;
    font-weight: normal;
    font-size: 12px;
    color: #00F;
    vertical-align:text-top;
}

img {
    border: 0;
}

label {
    font-family: Verdana, Geneva, Arial, Helvetica, sans-serif ;
    font-weight: normal;
    font-size: 12px;
}

input {
    border: 1px solid #000;
}

select {
    width:185px;
}

table.editor
{
    text-align: center;
    font-family: Verdana, Geneva, Arial, Helvetica, sans-serif ;
    font-weight: normal;
    font-size: 11px;
    color: #fff;
    width: 280px;
    background-color: #666;
    border: 0px;
    border-collapse: collapse;
    border-spacing: 0px;
}

table.editor td.editor_title
{
    background-color: #666;
    color: #fff;
    padding: 4px;
    text-align: left;
    font-weight: bold;
    font-size: 16px;
} 

table.editor td
{
    padding: 4px;
} 

table.list
{
    text-align: center;
    font-family: Verdana, Geneva, Arial, Helvetica, sans-serif ;
    font-weight: normal;
    font-size: 11px;
    color: #fff;
    width: 280px;
    background-color: #666;
    border: 0px;
    border-collapse: collapse;
    border-spacing: 0px;
}

table.list td.item
{
    background-color: #CCC;
    color: #000;
    padding: 4px;
    text-align: left;
    border: 1px #fff solid;
}

table.list td.list_title,table.list td.headers
{
    background-color: #666;
    color: #fff;
    padding: 4px;
    text-align: left;
    border-bottom: 2px #fff solid;
    font-weight: bold;
} 

table.list td.list_title
{
    font-size: 16px;
} 

table.list td.headers
{
    font-size: 12px;
}

Ahora copia las siguientes imágenes en la carpeta images:

Eso es todo. Apunta el navegador a http://localhost/kohana/index.php/album y deberías ver algo parecido a esto:

Si intentas crear un nuevo álbum o editar uno existente, deberías ver algo similar a esto:

Paso 10: Pensamientos finales

Desde luego, algunas mejoras son necesarias para esta aplicación, pero con muy poco código has creado una pequeña aplicación web. Ahora, sabes cómo usar el patrón MVC con Kohana, y cómo usar las bibliotecas y asistentes de la base de datos. Para aprender más, lee la documentación oficial.

Gracias a Kohana, el mantenimiento de código se convierte en una tarea fácil, y añadir nuevas características es pan comido. Espero que hayas disfrutado del tutorial.

No toquéis el "with"

2009-12-05T00:38:00.000+01:00

En los últimos tiempos se ha satanizado la orden with, por parte de personas de renombre como el mismo Douglas Crockford. En su artículo With statement considered harmful explica que, a pesar de ser similar a otros lenguajes, la falta en JavaScript de que un bloque tenga un ámbito propio puede fomentar errores difíciles de detectar. Si dentro del bloque del with se asigna un valor a una variable, no hay forma de saber si se está haciendo sobre un miembro del objeto pasado con el with o si se está modificando una variable global:

var bing=1;
with(ooo.eee.ooo.eee.ooo) {
  bing=2;
}
// en este punto, que toma el valor 2? 
// bing==2 o ooo.eee.ooo.eee.ooo.bing==2

De hecho propone en sus recomendaciones para la próxima versión de ECMAScript que está orden sea declarada obsoleta. Sin embargo las cosas no son tan sencillas como parecen. De nuevo, Andrea Giammarchi le saca punta al asunto como ya hizo con la polémica del desconocido segundo parámetro de eval, acusando a los que lo quitaban del lenguaje de perder una oportunidad perfecta de generar un entorno controlado para ejecutar secuencias en las que no se confía. Y también pasó con la propuesta de eliminar callee ante la que Andrea defendió que no se hiciese. Con esta sencilla estructura se consigue mucha más potencia que con el uso tradicional pasando al with una variable con un objeto:

with({o:myreference}){
    o.doStuff();
    o.var1 = "loquesea";
    // etc etc ...
};

También se facilita construcciones commo la siguiente que resulta extremadamente compacta y, por tanto, poco susceptible de ganar espacio con una compresión de código tradicional:

with(document)
  with(documentElement)
    insertBefore(
      createElement("script"),
      firstChild
    )
    .text = "alert(1)"
;

Sólo que además permite aprovechar esa definición en línea del parámetro-objeto para realizar llamadas a funciones, usar el operador terciario ( condicion ? cierto : falso ), o especificar parámetros por defecto:

// ejemplo de argumentos con nombre y sin usar closures
with({
  obj:myObject,
  // valores por defecto en línea por si acaso
  collection:collection || [],
  callback:myCaseAnalyzer,
  // variables locales
  i:0,
  length:collection ? collection.length : 0,
  // variable local no inicializada
  tmp:null
}){
  for(;i < length; ++i){
    tmp = callback.call(obj, collection[i]);
    if(tmp){
      tmp.doStuff();
      collection[i] = tmp;
    };
  };
};

Que resulta ser equivalente a los típicos closures tan utilizados. Otro uso interesante sería la tradicional llamada Ajax:

with(this.XMLHttpRequest ?
  new XMLHttpRequest :
  new ActiveXObject("Microsoft.MSXML")
){
  open("get", "?ajax=true", true);
  onreadystatechange = function(){
    if(readyState === 4)
      // realiza acciones con responseText/XML
      alert(responseText)
    ;
  };
  send(null);
}

Empezando con las extensiones de Chrome

2009-11-26T13:25:00.004+01:00

En breve aparecerá la primera versión de Chrome/Chromium con soporte de extensiones. Es el mecanismo ofrecido por el navegador para modificar y mejorar la funcionalidad, personalizándola al gusto del usuario. En el caso de Chromium, bastará con tener conocimientos de HTML, CSS y JavaScript para poder escribirlas. Por ejemplo:

Mostrar iconos en la barra de direcciones al visitar ciertas páginas:
Añadir botones a la barra de herramientas (con opción a mostrar un desplegable con más acciones):
Modificar la apariencia y comportamiento de las páginas web mostradas

Tutorial: Hola mundo!

Nota: traducido de aquí. Vamos a crear un nuevo botón en Chrome que al ser pulsado mostrará una página generada automáticamente. Algo así:

Para empezar, necesitarás la versión de Chrome del canal de desarrolladores, ya que aún no está disponible (al menos a fecha de hoy 26/nov/09) en los canales estable o beta. Los pasos para crear la extensión son los siguientes:

Crea una carpeta llamada "hola".

Crea un archivo llamado manifest.json con este contenido:

{
  "name": "Mi Primera Extension",
  "version": "1.0",
  "description": "Esta es la primera extension.",
  "browser_action": {
    "default_icon": "icon.png"
  },
  "permissions": [
    "http://api.flickr.com/"
  ]
}

Descarga el siguiente icono a la misma carpeta.
Carga la extensión:
- Abre la página de gestión de extensiones pulsando el menú y seleccionando Extensiones...
- Si el modo desarrollador tiene un símbolo +, púlsalo para añadir información sobre el desarrollador. El símbolo + cambia a - y aparecerán más botones e información.
- Pulsa el botón Carga extensión... y aparecerá un diálogo de selección de archivo.
- En el diálogo selecciona la carpeta "hola" y pulsa OK.
Si la extensión es válida, aparecerá el icono junto a la barra de direcciones y la información sobre la extensión en la página de gestión, tal y como se ve en la siguiente imagen:
Añade código a la extensión. Edita el archivo manifest.json y agrega la siguiente línea:
```
...
"browser_action": {
  "default_icon": "icon.png",
  "popup": "popup.html"
},
...
```
Dentro de la carpeta "hola", crea un archivo de texto llamado popup.html y añade el siguiente código: Sigue este enlace para ver el código
Vuelve a la página de gestión de las extensiones y recárgala para ver la nueva versión de la extensión.
Pulsa el icono de la nueva extensión que aparece en la barra de herramientas. Debería aparecer una ventana emergente con el contenido de popup.html:

Si no ves la ventana, sigue las instrucciones de nuevo prestando atención. No intentes cargar un HTML que no esté dentro de la carpeta de la extensión porque no funcionará.

Esta ha sido una introducción básica al sistema de extensiones de Chrome/Chromium. Puedes continuar leyendo sobre las opciones disponibles y sobre cómo realizar tareas más concretas en la Developer's Guide. Intentaré publicar un tutorial más completo enfocando más en el código JavaScript y la API ofrecida para acceder a las opciones del navegador.

Persevere, Node.JS y HelmaNG

2009-11-21T00:13:00.000+01:00

Se trata de tres servidores de aplicaciones basados en JavaScript. Cada uno de ellos tiene sus propias características que lo hacen apto para un tipo de solución particular:

Persevere 1.0

Proyecto perteneciente a la Dojo Foundation, autores del framework cliente de JavaScript
Usa una interfície basada en estándares: HTTP/REST, JSON-RPC, JSONPath, y canales REST
Está basado en el motor Rhino (Java) al igual que Helma
Ofrece almacenamiento persistente de datos JSON dinámicos (objetos, arrays y funciones)
Operaciones de creación, lectura, actualización y borrado a través de una interfície web HTTP/REST con JSON como formato
Ejecución remota de funciones JavaScript en el servidor usando JSON-RPC
Capacidad de consultas indexadas flexible y rápida mediante JSONQuery/JSONPath
Capacidades de monitorización basadas en Comet a través de canales HTTP con transporte Bayeux
Seguridad a nivel de objeto basada en reglas de datos y con gestión de usuarios
Soporte de Json Referencing y JSON Schema (Validación e integridad de datos)
Jerarquía de datos basada en clases para facilitar consultas y herencia
Arquitectura de fuentes de datos conectables: servicios web remotos, tablas SQL y archivos XML pueden ser usados como almacenes de datos
Versiones de objetos con histórico transaccional de estados de los registros

En definitiva, la idea de Persevere es ofrecer la mayor cantidad de opciones en el lado del servidor para almacenar los datos y ofrecerlos óptimamente a los clientes web, de forma que se pueda desplazar el peso de la aplicación web al cliente manteniendo en el servidor la seguridad y la persistencia de los datos. Ver documentación.

La siguiente versión estará basada en Pintura, que es una nueva abstracción del núcleo JavaScript de Persevere, de forma que respeta los estándares de JavaScript en el servidor (CommonJS y JSGI) para permitir el soporte de motores compatibles (V8, JSCore, y Spidermonkey).

Node.JS

Node.js es un framework de entrada/salida basado en eventos y construido sobre el motor de JavaScript de Google V8. Facilita la creación de aplicaciones escalables y altamente eficientes sin necesidad de saber sobre hilos, procesos, semáforos, depuración concurrente, ... gracias a que está basado en el mismo modelo de programación basada en eventos que Twisted de Python o EventMachine de Ruby.

La idea principal detrás de Node.js es la simplicidad. Aprovechando las funciones típicas callback de JavaScript (lanzadas cuando ocurre un evento) con las que cualquier programador está familiarizado, se ha implementado una tecnología revolucionaria basada en el potente motor V8. Las llamadas a la API son, generalmente, asíncronas, por lo que nunca bloquean la ejecución. Resulta fácil para principiantes generar aplicaciones complejas sin preocuparse de las complejidades típicas de aplicaciones concurrentes.

Por ejemplo, para implementar un servidor HTTP totalmente funcional sobre el puerto 8000 que responde a las peticiones con un documento "Hello World", harían falta ocho líneas de código perfectamente comprensible:

var sys = require("sys"),
   http = require("http");
http.createServer(function (request, response) {
  response.sendHeader(200, {"Content-Type": "text/plain"});
  response.sendBody("Hello World\n");
  response.finish();
}).listen(8000);
sys.puts("Server running at http://127.0.0.1:8000/");

En la llamada a la función http.createServer se pasa como parámetro la función callback que será llamada cuando se reciba una petición de conexión. Más simple imposible. De hecho Simon Willison ha cambiado en el último momento el asunto de su charla en Full Frontal '09 para hablar de los resultados que está obteniendo con esta revolucionaria herramienta.

HelmaNG

Es la última versión del más veterano de los servidores de aplicación basados en JavaScript. NG quiere decir Next Generation y es una versión de Helma empezada de cero, con un código Java mucho más pequeño y ligero (principalmente el código en tiempo de ejecución, la consola y el cargador de módulos y recursos). Sigue el estándar de interoperabilidad CommonJS.

Consta de un entorno de ejecución JavaScript basado en Rhino, un sistema de carga de módulos compatible con CommonJS, una consola interactiva, y una biblioteca implementada JavaScript que cubre funcionalidades básicas como extensiones a objetos predefinidos, entrada/salida de archivos, persistencia, tests unitarios, soporte HTTP de cliente y servidor y una framework web construida sobre los elementos anteriores y con código JavaScript 100%.

Helma sigue una filosofía de programación un tanto peculiar basada en objetos y similar al paradigma MVC, pero que puede resultar extremadamente eficaz una vez pasado el proceso de aprendizaje inicial. Su estructura modular permite mantener la aplicación dividida desde el principio según el modelo de objetos y las acciones que se permiten sobre éstos, lo que facilita mucho su crecimiento posterior. El equipo de programadores es principalmente centro-europeo, donde cuenta con una importante base de usuarios.

spdy://

2009-11-13T00:14:00.001+01:00

Los responsables del navegador Chromium proponen la adopción de un nuevo protocolo llamado spdy (por SPeeDY, veloz) para sustituir al omnipresente HTTP y optimizado para una carga rápida y óptima de contenidos. En sus experimentos han logrado mejoras de hasta un 64% en el tiempo de carga. HTTP es un protocolo a nivel de aplicación que funciona sobre el protocolo a nivel de red TCP. Con 10 años de historia, mejorar la latencia no era precisamente una de las preocupaciones de sus diseñadores. Entre sus limitaciones:

Una sola petición por conexión, suplido en parte por el HTTP pipelining o conexiones múltiples en el navegador
Peticiones iniciadas exclusivamente por el cliente, aunque el servidor tenga información que deba ser recibida por el cliente, no puede avisar a éste
Las cabeceras de petición y respuesta no se comprimen a pesar de alcanzar los 2KB fácilmente por las cookies, lo que afecta sobre todo a las líneas lentas
Cabeceras redundantes se repiten en cada petición debido a que para el servidor el cliente siempre es "nuevo"
La compresión de datos es opcional y no obligatoria

Otros enfoques han intentado resolver esas carencias, por ejemplo, intentando optimizar el protocolo TCP, pese a los problemas que podría generar en la infraestructura existente. spdy, por su parte, persigue los siguientes objetivos:

Reducir el 50% en los tiempos de carga
Aprovechar el protocolo TCP existente para evitar requerir una infraestructura de red distinta a la actual
Evitar modificaciones en el contenido existente (HTML)
Conseguir varias peticiones concurrentes sobre una misma sesión TCP
Comprimir las cabeceras y reducir campos innecesarios
Simplificar el protocolo para facilitar su implementación y a la vez optimizarlo
Mantener SSL como protocolo subyacente para aumentar la seguridad a pesar del incremento en latencia
Permitir que el servidor envíe información al cliente cuando lo desee

Características

spdy permite crear una conexión TCP con el servidor sobre la que una serie de flujos concurrentes y entrelazados permiten una comunicación bidireccional (desde el cliente o desde el servidor).

Flujos multiplexados sobre una sola conexión TCP. Al no necesitar múltiples conexiones TCP, con lo que ello implica, y al estar mejor aprovechada ésta con mayor densidad de información, la eficiencia es mucho mayor.
La priorización de peticiones permite que el cliente identifique la información más importante y evitar que contenido de baja prioridad bloquee al resto.
Compresión de las cabeceras HTTP
El servidor puede enviar información al cliente mediante una cabecera X-Associated-Content que informa al cliente de nueva información disponible antes de que el éste la solicite.
El servidor usa la cabecera X-Subresources para sugerir al cliente que solicite ciertos recursos aunque no se los envíe directamente al cliente.

Más información en el borrador de la especificación, en este artículo de Alex Russell (Dojo Toolkit) y en el artículo introductorio. En él se explica la implementación de un servidor y un cliente Chrome modificado para realizar las pruebas del protocolo con los resultados indicados anteriormente, y que son expuestos con detalle.

NodeJS

2009-11-10T15:45:00.002+01:00

“Evented I/O for V8 JavaScript”— es un entorno JavaScript construido sobre el rapidísimo motor V8 que provee funcionalidad de entrada y salida basada en eventos para construir servidores TCP y HTTP altamente concurrentes. El diseño de la API es soberbio — todo se consigue usando eventos y llamadas callback de JavaScript (incluso el acceso típico a archivos) y la pequeña librería estándar ya contiene soporte completo de HTTP y DNS.

En general es muy similar a Twisted (Python) y otras por el estilo, pero la sintaxis de funciones anónimas de JavaScript parece más natural que su equivalente en Python.

El protocolario "Hola mundo":

var sys = require('sys'), 
   http = require('http');
http.createServer(function (req, res) {
  setTimeout(function () {
    res.sendHeader(200, {'Content-Type': 'text/plain'});
    res.sendBody('Hello World');
    res.finish();
  }, 2000);
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');

O un servidor que escucha en el puerto 7000 y devuelve lo mismo que recibe (echo):

var tcp = require('tcp');
var server = tcp.createServer(function (socket) {
  socket.setEncoding("utf8");
  socket.addListener("connect", function () {
    socket.send("hello\r\n");
  });
  socket.addListener("receive", function (data) {
    socket.send(data);
  });
  socket.addListener("eof", function () {
    socket.send("goodbye\r\n");
    socket.close();
  });
});
server.listen(7000, "localhost");

El objetivo de Node es proporcionar una manera fácil de crear programas escalables para redes. En el ejemplo anterior, los dos segundos de retraso no impiden que el servidor gestione solicitudes nuevas. Node indica al sistema operativo (a través de epoll, kqueue, /dev/poll, o select) que debe ser notificado cuando los 2 segundos de arriba pasen o si se hace una nueva conexión, y entonces entra en suspenso. Si alguien nuevo se conecta, entonces se ejecuta la función callback, si el tiempo de espera se termina, se ejecuta la llamada callback interna. Cada conexión consume sólo una pequeña parte del heap.

Esto contrasta con el modelo de concurrencia más común hoy en día en el que se usan hilos del sistema operativo. La gestión de redes basada en hilos es relativamente ineficiente y muy difícil de usar. Node mostrará una mejor eficiencia del uso de la memoria bajo altas cargas que los sistemas que asignan pilas de hilos de 2mb para cada conexión. Además, los usuarios de node no deben preocuparse de bloquear el proceso - no hay locks. Casi ninguna función en node usa directamente la entrada/salida, por lo que el proceso nunca se bloquea. Debido a que nada bloquea, los programadores menos expertos pueden desarrollar sistemas rápidos.

Node es similar en diseño a sistemas como la Event Machine de Ruby o Twisted de Python, y está influido por ellos. Node lleva el modelo de eventos un poco más lejos - presenta el bucle de eventos como una construcción del lenguaje en lugar de como una biblioteca. En otros sistemas, siempre hay una llamada bloqueante para iniciar el bucle de eventos. Normalmente se define el comportamiento a través de llamadas callback al comienzo de un script, y al final se inicia un servidor a través de una llamada bloqueante como EventMachine::run(). En node no existe esa llamada bucle-de-inicio-del-evento. node simplemente entra en el bucle de eventos después de ejecutar el script de entrada. node sale del bucle de eventos cuando no hay más llamadas callback a realizar. Este comportamiento es como el del Javascript del navegador — el bucle de eventos está oculto para el usuario.

HTTP es un protocolo de primera clase en node. La Biblioteca HTTP de node ha crecido a partir de las experiencias del autor desarrollando y trabajando con servidores web. Por ejemplo, enviar datos por streaming a través de la mayoría de frameworks web es imposible. node intenta corregir estos problemas con su parser HTTP y su API. La infraestructura puramente basada en eventos de node constituye una buena base para crear bibliotecas web o frameworks.

Pero ¿qué pasa con la concurrencia de múltiples procesadores? Los procesos son necesarios para escalar a ordenadores multi-núcleo, sin hilos con memoria compartida. Los fundamentos de los sistemas escalables son conexiones de red rápidas y diseño no bloqueante - el resto es intercambio de mensajes. En futuras versiones, node podrá generar nuevos procesos (usando la API de Web Workers), pero eso es algo que ya encaja muy bien en el diseño actual.

Via Simon Willison.

Herramientas de Google Closure

2009-11-09T09:49:00.003+01:00

He traducido el artículo de presentación y otros de la documentación sobre las nuevas herramientas presentadas por Google hace unos días:

Millones de usuarios de Google en todo el mundo usan aplicaciones JavaScript intensivas, como Gmail, Google Docs y Google Maps. Al igual que los desarrolladores de todo el mundo, los Googlers (empleados de Google) queremos grandes aplicaciones web que sean más fáciles de crear, por lo que hemos construido unas cuantas herramientas para ayudarnos a desarrollar estas aplicaciones (y muchas otras). Estamos contentos de anunciar la publicación en código abierto de estas herramientas, y estamos orgullosos de ponerlos a disposición de la comunidad de desarrollo web.

El compilador de Closure

El compilador de Closure es un optimizador de JavaScript que compila aplicaciones web en código JavaScript compacto y de alto rendimiento. El compilador elimina el código muerto, a continuación, reescribe y minimiza lo que queda para que se ejecute rápido en los motores de JavaScript de los navegadores. El compilador también comprueba la sintaxis, las referencias a variables, y los tipos, y advierte sobre otros problemas comunes de JavaScript. Estos controles y optimizaciones ayudan a escribir aplicaciones más depuradas y fáciles de mantener. Puedes utilizar el compilador con el inspector de Closure, una extensión de Firebug que hace que la depuración del código ofuscado casi tan fácil como la depuración de código legible por humanos.

Los beneficios de usar el compilador son:

Eficiencia. El compilador reduce el tamaño de los archivos JavaScript y al mismo tiempo los hace más eficientes, ayudando a que las aplicaciones carguen más rápido y necesiten menos ancho de banda.
Comprobación de código. El compilador genera avisos sobre JavaScript ilega y sobre operaciones potencialmente peligrosas, ayudándote a producir JavaScript más depurado y fácil de mantener.

Debido a que los desarrolladores de JavaScript son un grupo diverso, hemos creado una serie de formas distintas de ejecutar el compilador de Clausure. Hemos publicado a fuente abierta una herramienta de línea de comandos. Hemos creado una aplicación web que acepta código para compilación a través de un cuadro de texto o de una API REST. También estamos ofreciendo una extensión de Firefox que puede utilizar con Page Speed para ver convenientemente los beneficios en rendimiento de las páginas web.

Para probar el compilador:

Descarga el paquete del compilador de Closure.

Crea un directorio llamado closure-compiler.

Descarga el compilador del archivo compiler.jar y guárdalo en el directorio closure-compiler.
Crea un archivo JavaScript

Crea un archivo llamado hello.js que contenga el siguiente código:
```
// Una función sencilla.
function hello(longName) {
  alert('Hola, ' + longName);
}
hello('Nuevo usuario');
```
Guárdalo en el directorio closure-compiler.
Compila el archivo JavaScript.

Ejecuta el siguiente comando desde el directorio closure-compiler:

java -jar compiler.jar --js hello.js --js_output_file hello-compiled.js

Este comando crea un nuevo archivo llamado hello-compiled.js, que contiene el siguiente JavaScript:
```
function hello(a){alert("Hola, "+a)}hello("Nuevo usuario");
```
El compilador ha eliminado los comentarios, el espacio en blanco y un punto y coma innecesario. El compilador ha reemplazado el nombre de parámetro longName por el más corto a. Esto genera un archivo mucho más pequeño que el original.

Para confirmar que el código JavaScript compilado aún funciona, incluye hello-compiled.js en un archivo HTML como este:
```
<html>
  <head>
    <script src="closure-library-read-only/closure/goog/base.js"></script>
    <script src="hello.js"></script>
  </head>
  <body onload="sayHi()">
  </body>
</html>
```
Ahora carga el HTML en el navegador y deberías ver una bienvenida amigable. Para aprender más visita este documento sobre compilación avanzada y con archivos externos.

El inspector de Closure

El compilador de Closure modifica el código JavaScript original y genera código más pequeño y más eficiente, pero más difícil de leer y depurar. El inspector ayuda ofreciendo un mapeo del código fuente que identifica las líneas del código original y el compilado. De esa forma es posible ver el código original en tu editor preferido indicado en la variable de entorno $EDITOR.

Sigue estos pasos para habilitar el mapeo de código fuente al usar el inspector:

Instala Firebug y el inspector.
Compila tu código JavaScript con el compilador de Closure y añade el parámetro --create_source_map. Por ejemplo, si tu archivo JavaScript se llama example.js, ejecuta este comando desde el directorio closure-compiler para crear un mapa de código fuente en el fichero example-map:
```
$ java -jar compiler.jar --js example.js --create_source_map ./example-map --js_output_file example-compiled.js
```
Para depurar tu código en Firebug, abre una página web en Firefox que incluya example.js. Abre una ventana de Firebug y carga el archivo JavaScript compilado example-compiled.js en el panel izquierdo. Selecciona la pestaña Source Mapping del panel derecho y especifica la localización del archivo de mapa de código fuente example-map introduciendo la URL o haciendo clic en Open Local File y seleccionándolo.
Tras cargar el mapa de código fuente, puedes encontrar el código original de cualquier código en los fuentes compilados. Para hacer esto, pulsa el botón derecho del ratón sobre cualquier código compilado y selecciona Show Original Source, tal y como se muestra a continuación:

Si has indicado la variable de entorno $EDITOR al editor de tu elección, el archivo original se abre en ese editor en la línea que corresponde a la que has hecho el click. Si no lo has indicado, verás el nombre de fichero y el número de línea mostrados en un pop-up, así:

Traza mejorada de pila

Firebug incluye una representación de la traza de pila que puedes ver pulsando Stack en la parte derecha de la ventana.
El inspector de Closure mejora la representación de la traza de pila mediante:

Mostrando los nombres de función originales si se ha cargado el mapa del código fuente.
Mostrando el archivo que contiene cada función.
Facilitando un botón Copy Stack de forma que se pueda copiar el texto de la traza de pila.

A continuación hay un ejemplo de traza mejorada de pila del inspector Closure:

Integración de Tests Unitarios

El inspector de Closure soporta la integración con el Framework de test de Closure. Para habilitar esta característica, pulsa la flecha en el menú Script de Firebug y habilita Handle JSUnit Failures. Si una aserción falla en el Framework de testeo, el Inspector de Closure establece un punto de ruptura sobre la aserción y pausa la ejecución.

Aquí hay un ejemplo de punto de ruptura sobre una aserción:

La Biblioteca de Closure

La biblioteca de Closure es una amplia colección de código JavaScript modular, bien probada y multi-navegador. Los desarrolladores Web pueden coger solamente lo que necesiten de un amplio conjunto de widgets reutilizables y controles de interfície de usuario, así como de utilidades de bajo nivel para el DOM, comunicación con el servidor, animación, estructuras de datos, pruebas unitarias, edición de texto rico, y mucho, mucho más. (De verdad. Echa un vistazo a la documentación.)

JavaScript carece de una biblioteca de clases estándar como STL o JDK. En Google, la biblioteca de Closure hace el papel de "nuestra biblioteca estándar de JavaScript" para la creación de grandes aplicaciones web complejas. Es intencionadamente agnóstica en cuanto a servidor y destinada para ser usada con el compilador de Closure. Puedes hacer un proyecto grande y complejo (con espacios de nombres y comprobación de tipos), y aún así, pequeño y rápido a través del cable (con compilación). La Biblioteca de Closure proporciona utilidades para tareas comunes de manera que pases el tiempo escribiendo la aplicación en lugar de escribir utilidades y abstracciones de navegador.

Si estás desarrollando una aplicación grande o creciente, podrías beneficiarte de la amplitud de la biblioteca. Una biblioteca bien probada puede aislarte de los problemas de compatibilidad entre navegadores y ahorrar tiempo de programación en el lado del cliente, permitiendo que te dediques a la parte divertida.

Empezando con la biblioteca de Closure

Este ejercicio de "Hola Mundo" te introduce en el proceso de usar la biblioteca en una página web. Para hacer este ejercicio necesitas estar familiarizado con JavaScript, y con un cliente de Subversion. Podrías tener ya uno. Lo sabrás intentando ejecutar el comando del paso 1.

Hola Closure

Para empezar con la librería Closure, utiliza funciones JavaScript de Closure en una página web simple siguiendo estos pasos:

Paso 1: Descargar la biblioteca

Descarga la biblioteca de Closure desde el repositorio de Subversion ejecutando siguiente comando desde consola:

svn checkout http://closure-library.googlecode.com/svn/trunk/ closure-library-read-only

Podrías necesitar un cliente de Subversion para ejecutar el comando, aunque podrías tener ya uno. Prueba el comando, y si no funciona, descarga e instala un cliente de Subversion.
Tras ejecutar el comando deberías tener un directorio llamado closure-library-read-only que contenga el código de la librería.

Paso 2: Crear un archivo JavaScript que use la biblioteca de Closure

Guarda el siguiente JavaScript en un archivo llamado hello.js. Pon este archivo junto al directorio closure-library-read-only.

goog.require('goog.dom');

function sayHi() {
  var newDiv = goog.dom.createDom('h1', {'style': 'background-color:#EEE'},
    'Hola Mundo!');
  goog.dom.appendChild(document.body, newDiv);
}

Paso 3: Crea un archivo HTML

Guarda el siguiente HTML en un archivo llamado hello.html. Pone este archivo junto al directorio closure-library-read-only y el archivo hello.js.

<html>
  <head>
    <script src="></script>
    <script src="hello.js"></script>
  </head>
  <body onload="sayHi()">
  </body>
</html>

Paso 4: Dí Hola a la biblioteca

Abre el archivo HTML en el navegador. Deberías de ver las palabras "Hello world!":

¿Cómo funciona el ejemplo?

El JavaScript de hello.js usa dos funciones que no define: goog.dom.createDom() y goog.dom.appendChild(). ¿De dónde vienen esas funciones?

Esas funciones están definidas en la biblioteca de Closure que descargaste en el paso 1, dentro del archivo closure-library-read-only/dom/dom.js.
Para hacer uso de esas funciones, el ejemplo hace dos cosas:

Incluye la orden goog.require('goog.dom') al principio del JavaScript del paso 2.
Incluye el archivo de arranque de la biblioteca base.js en el HTML del paso 3.

El archivo base.js define la función goog.require(). La llamada de función goog.require('goog.dom') carga el archivo JavaScript que define las funciones del espacio de nombres goog.dom, junto con otros archivos de la biblioteca de Closure que esas funciones necesitan.
La biblioteca de Closure carga esos archivos agregando dinámicamente una etiqueta script al documento por cada archivo necesitado de la biblioteca. Así, por ejemplo, la orden goog.require('goog.dom') hace que la siguiente etiqueta sea agregada al document, donde path-to-closure es el camino desde el archivo HTML hasta el directorio que contiene base.js:

Normalmente una sola orden goog.require() cargará sólo una fracción de la base de código de la biblioteca.
Incluir base.js no es la única forma de incluir el código de la librería, pero es la forma más fácil de empezar. En cualquier caso, no importa como cargues el código de la librería, siempre usarás goog.require() para declarar las partes de la librería que necesitas.

Construir una aplicación con la biblioteca de Closure

Este otro tutorial te introduce en la experiencia de usar la biblioteca dando un paseo por la construcción de una aplicación simple.
Usa estos enlaces para descargar los dos archivos de código fuente usados en el tutorial:

Este tutorial explica las diferentes partes de estos archivos paso a paso. Fíjate que el archivo notepad.html no funcionará hasta que no descargues y enlaces tu copia de la biblioteca, tal y como se describe a continuación.

La aplicación de Notas

Este tutorial ilustra el proceso de construir una simple aplicación para mostrar notas. El ejemplo:

crea un espacio de nombres para la aplicación,
usa la función de la biblioteca goog.dom.createDom() para crear la estructura de Document Object Model (DOM) para la lista, y
usa una clase de la biblioteca en la lista de notas para permitir al usuario abrir y cerrar elementos de la lista.

Creando un espacio de nombres con goog.provide()

Cuando usas bibliotecas JavaScript de fuentes distintas, siempre existe la posibilidad de que algún archivo Javascript redefina una variable global o un nombre de función que ya uses en tu código. Para minimizar el riesgo de este tipo de colisión de nombres, usa la función goog.provide() de la librería para crear un espacio de nombres para tu código.

Por ejemplo, la aplicación de Notas usa objetos Note creados por una función constructor Note(). Si cualquier otro archivo JavaScript define una función global o una variable Note, sobreescribiría al constructor. Por tanto, el ejemplo crea un espacio de nombres para este constructor con la siguiente llamada a goog.provide:

goog.provide('tutorial.notepad.Note');

La función goog.provide() se asegura de la existencia de la estructura de objeto JavaScript indicada por su argumento. Comprueba si existe cada propiedad de objeto en la ruta de la expresión y si no existe la inicializa. La función anterior es equivalente a:

tutorial = tutorial || {};
tutorial.notepad = tutorial.notepad || {};
tutorial.notepad.Note = tutorial.notepad.Note || {};

Puesto que goog.provide() sólo inicializa propiedades si no existen previamente, nunca sobreescribirá una propiedad.
Fíjate que las órdenes goog.provide() tiene la ventaja añadida de que el script de resolución de dependencias calcdeps.py puede usarlas. Echa un vistazo a Usar el script de cálculo de dependencias para aprender cómo usar calcdeps.py

Una vez que la estructura de objeto tutorial.notepad.Note exista, el ejemplo asigna la función constructor a la propiedad Note.

tutorial.notepad.Note = function(title, content, noteContainer) {
  this.title = title;
  this.content = content;
  this.parent = noteContainer;
};

El constructor Note está ahora en el espacio de nombre tutorial.notepad creado con goog.provide().

Creando una estructura DOM con goog.dom.createDom()

Para mostrar una Note en el documento HTML, el ejemplo facilita a la clase Note el siguiente método:

tutorial.notepad.Note.prototype.makeNoteDom = function() {
  // Crea la estructura DOM que representa la nota.
  this.headerElement = goog.dom.createDom('div', 
      {'style': 'background-color:#EEE'}, this.title);
  this.contentElement = goog.dom.createDom('div', null, this.content);
  var newNote = goog.dom.createDom('div', null,
      this.headerElement, this.contentElement);

  // Agrega la estructura DOM de la nota al documento.
  goog.dom.appendChild(this.parent, newNote);
};

Este método usa la función de la biblioteca goog.dom.createDom(). La siguiente orden goog.require() incluye el código para esta función:

goog.require('goog.dom');

Para incluir una función como goog.dom.createDom() que no sea un constructor, pasa el espacio de nombres que contenga la función a goog.require (en este caso solamente goog.dom). No necesitas incluir el nombre de la función en la orden goog.require() a menos que requieras de una clase. Usando una clase de la biblioteca ilustra una órden goog.require() para este caso.

La función goog.dom.createDom() crea un nuevo elemento DOM. Por ejemplo, la siguiente órden de makeNoteDom() crea un nuevo elemento div.

this.headerElement = goog.dom.createDom('div', 
      {'style': 'background-color:#EEE'}, this.title);

El segundo argumento en esta llamada a createDom() especifica los atributos a agregar al elemento, y el tercer argumento especifica un hijo que añadir al elemento (una cadena en este caso). Ambos, el segundo y el tercer parámetro, son opcionales. Mira la referencia de la API para más información sobre createDom().

El método makeNoteDom() simplemente crea un argumento de una sola Note. Para crear una lista de notas, el ejemplo incluye una función makeNotes() que toma un array de de datos de notas e instancia un objeto Note por cada uno, llamando al método makeNoteDom() de Note.

tutorial.notepad.makeNotes = function(data, noteContainer) {
  var notes = [];
  for (var i = 0; i < data.length; i++) {
    var note = 
      new tutorial.notepad.Note(data[i].title, data[i].content, noteContainer);
    notes.push(note);
    note.makeNoteDom();
  }
  return notes;
};

Usando una clase de la biblioteca

Con sólo dos líneas de código, el ejemplo hace de cada nota un Zippy. Un Zippy es un elemento que puede ser plegado y desplegado para ocultar o mostrar contenido. Primero el ejemplo agrega una nueva orden require() para la clase Zippy:

goog.require('goog.ui.Zippy');

Entonces añade una línea al final del método makeNoteDom :

tutorial.notepad.Note.prototype.makeNoteDom = function() {
  // Crea la estructura DOM para representar la nota.
  this.headerElement = goog.dom.createDom('div', 
      {'style': 'background-color:#EEE'}, this.title);
  this.contentElement = goog.dom.createDom('div', null, this.content);
  var newNote = goog.dom.createDom('div', null,
      this.headerElement, this.contentElement);

  // Agrega la estructura DOM de la nota al documento.
  goog.dom.appendChild(this.parent, newNote);

  // NUEVA LINEA:
  return new goog.ui.Zippy(this.headerElement, this.contentElement);
};

La llamada al constructor new goog.ui.Zippy(this.headerElement, this.contentElement) asigna un comportamiento al elemento nota que conmutará la visibilidad de contentElement cuando el usuario haga clic sobre headerElement. Para más información sobre la clase Zippy, echa un vistazo a la documentación de la API de Zippy.

Usando el Notepad en un documento HTML

A continuación se puede ver el código JavaScript completo para esta aplicación de ejemplo:

goog.provide('tutorial.notepad');
goog.provide('tutorial.notepad.Note');

goog.require('goog.dom');
goog.require('goog.ui.Zippy');

/**
 * Itera sobre una lista de objetos de datos de nota, crea una instancia de Nota
 * para cada uno, y le dice a la instancia que construya su estructura DOM.
 */
tutorial.notepad.makeNotes = function(data, noteContainer) {
  var notes = [];
  for (var i = 0; i < data.length; i++) {
    var note = 
      new tutorial.notepad.Note(data[i].title, data[i].content, noteContainer);
    notes.push(note);
    note.makeNoteDom();
  }
  return notes;
};

/**
 * Gestiona los datos e interfície de un solo nodo
 */
tutorial.notepad.Note = function(title, content, noteContainer) {
  this.title = title;
  this.content = content;
  this.parent = noteContainer;
};

/**
 * Crea la estructura DOM para la nota y la agrega al documento.
 */
tutorial.notepad.Note.prototype.makeNoteDom = function() {
  // Create DOM structure to represent the note.
  this.headerElement = goog.dom.createDom('div',
      {'style': 'background-color:#EEE'}, this.title);
  this.contentElement = goog.dom.createDom('div', null, this.content);
  var newNote = goog.dom.createDom('div', null,
      this.headerElement, this.contentElement);

  // Agrega la estructura DOM de la nota al documento
  goog.dom.appendChild(this.parent, newNote);
  return new goog.ui.Zippy(this.headerElement, this.contentElement);
};

Puedes tener este código descargando el archivo notepad.js. El siguiente HTML usa este código de bloc de notas para mostrar una lista de notas en una página web:

<html>
<head>
<title>Notepad</title>
<script src="closure-library/base.js"></script>
<script src="notepad.js"></script>
</head>
<body>

<div id="notes">
</div>

<script>
function main() {
  var noteData = [
    {'title': 'Note 1', 'content': 'Content of Note 1'},
    {'title': 'Note 2', 'content': 'Content of Note 2'}];

  var noteListElement = document.getElementById('notes');
  var notes = tutorial.notepad.makeNotes(noteData, noteListElement);
}
main();
</script>
</body>
</html>

Puedes tener esta página descargando el archivo notepad.html, Esta página:

incluye una etiqueta script para el archivo base.js de la biblioteca. El atributo src de esta etiqueta es el camino desde el archivo HTML hasta el archivo base.js de la biblioteca.
incluye una etiqueta script para el archivo que contiene el código para el bloc de notas.
incluye un script en la página que inicializa la lista de notas con una llamada a makeNotes(). La función makeNotes() toma dos argumentos: un array de Objetos, cada uno conteniendo los datos de una nota, y el elemento DOM bajo el que construir la estructura DOM de la lista de notas

Plantillas de Closure

Las plantillas de Closure surgieron de un deseo de tener plantillas web que estén precompiladas para ser ejecutadas de forma eficiente por JavaScript. Las plantillas de Closure tienen una sintaxis simple y natural para programadores. A diferencia de los tradicionales sistemas de plantillas, puedes pensar en las plantillas de Closure como pequeños componentes que se unen para formar una interfície de usuario, en lugar de tener que crear una gran plantilla por cada página. Las plantillas de Closure se aplican para JavaScript y para Java, así que puedes usar las mismas plantillas en el servidor y en el cliente. El compilador, la biblioteca, las plantillas y el inspector de Closure se iniciaron como proyectos de 20% del tiempo de Googlers y cientos de ellos han contribuido con miles de parches. Hoy en día, cada herramienta de Closure se ha convertido en una parte clave de la infraestructura de JavaScript detrás de las aplicaciones web en Google. Por eso estamos particularmente entusiasmados de abrir su código para fomentar y apoyar el desarrollo web fuera de Google. Queremos saber lo que piensas, pero más importante aún, queremos ver que podéis hacer con ellas. Así que bájatelo y diviértete!

Addendum: Parece que Andrea Giammarchi no está muy de acuerdo con las ventajas ofrecidas por el nuevo proyecto de Google. Ha encontrado fácilmente un ejemplo en el que el compilador hace que el código deje de funcionar (aunque hay que decir que hace mal uso de las variables globales que un buen estilo de programación debería evitar). Por otro lado analiza el código de la librería y encuentra distintos problemas de rendimiento que una librería orientada a la velocidad no debería tener. Quizás tenga razón y todo se deba a que detrás de esas herramientas hay programadores expertos en Java y no en JavaScript...

Incrustación automática de URIs de datos en archivos CSS

2009-11-03T21:49:00.000+01:00

Traduzco la continuación del artículo de Nicholas Zakas en el que presenta dos herramientas para facilitar la adopción de esta tecnología:

La semana pasada posteé sobre URIs de datos y por qué son una característica interesante de los navegadores web. En conclusión, mencioné que el mejor uso de URIs de datos es incrustarlos en archivos CSS para que tuviesen la mejor oportunidad de ser cacheados por el navegador. Recibí un montón de respuestas en este blog y por otros medios que demostraban que la gente estaba muy entusiasmado con las URIs de datos y estaban listos para dar el salto y usarlos en CSS. This left me with me believing that an interesting time is upon us. Esto me hizo pensar que estamos viviendo en un momento interesante.

El problema

Aunque Internet Explorer anterior a la versión 8 no es compatible con los URIs de datos, la mayoría de la gente parece dispuesta a servir contenido alternativo para los navegadores menos capaces y servir el contenido más óptimo para aquellos que pueden manejarlo. El problema es que millones de sitios web están utilizando actualmente archivos CSS que referencian archivos de imagen a la manera tradicional, y todos ellos que tendrían que ser convertidos para usar URIs de datos. Nadie quiere mantener varias versiones de los archivos CSS, por lo que sería mejor si este proceso de conversión pudiera ser automático.

Presentación de CSSEmbed

Pasé los últimos dos días programando y estoy orgulloso de introducir CSSEmbed, una herramienta para integrar automáticamente imágenes dentro de archivos CSS como URIs de datos. Esta es una sencilla herramienta muy pequeña que lee un fichero CSS, identifica las imágenes referenciadas en su interior, las convierte a URIs de datos, y genera una hoja de estilos resultante. La hoja de estilos recién creada es una copia exacta del original, con comentarios y sangrías intactos, la única diferencia es que todas las referencias a archivos de imagen han sido sustituidos por URIs de datos. Because it preserves the original formatting of the style sheet, it can be used both on nicely-formatted source code and crunched source code without worry. Debido a que preserva el formato original de la hoja de estilo, puede ser utilizado tanto con código fuente bien formateado como con código compactado sin problemas.

CSSEmbed requiere Java 1.5+ para funcionar. Para empezar, descarga el archivo JAR. Todas las dependencias están incluidos en el archivo JAR, así que no hay necesidad de ocuparse de la creación de classpaths o de descargar otras dependencias. El uso básico es el siguiente:

java -jar cssembed-xyzjar -o <output filename> <input filename>

Por ejemplo:

java -jar cssembed-xyzjar -o styles_new.css styles.css

When the -o flag is omitted, the output ends up on stdout , thus you can direct the output to a file directly: Cuando se omite el parámetro -o el código se genera sobre la salida estándar, por lo que se puede dirigir a un archivo directamente:

java -jar cssembed-xyzjar styles.css > styles_new.css

Las instrucciones de uso completas están disponibles mediante el parámetro -h


Usage: java -jar cssembed-x.y.z.jar [options] [input file]

Global Options
   -h, --help           Muestra esta información
   --charset            Codificación de carácteres del archivo de entrada
   -v, --verbose        Muestra mensajes de informacion y avisos
   -root                Antepone a todas las URLs relativas
   -o                   Genera la salida en . Por defecto a stdout.

CSSEmbed es inteligente en la forma en que identifica las imágenes. Si la ubicación de la imagen comienza con "http://", entonces la herramienta descarga automáticamente el archivo y lo convierte a una URI. Si la ubicación de la imagen es una ruta relativa (por ejemplo, contiene "../"), CSSEmbed busca el archivo local en relación a la ubicación del archivo de hoja de estilos. Si los archivos indican una ruta absoluta, sin especificar "http://", como "/images/image.png", tendrás que proporcionar una raíz a través de la opción --root. Cuando se especifica, la raíz se antepone a todas las ubicaciones de imágenes que no comiencen por "http://".

Para obtener más información acerca de CSSEmbed, echa un vistazo a la documentación. También puede descargar el código fuente (Licencia MIT) del proyecto GitHub. CSSEmbed se encuentra en etapas muy tempranas, por lo que se agradecerán opiniones. Si encuentras errores, por favor usa el seguimiento de incidencias para informar sobre ellos.

...y presentamos DataURI

When I was researching data URIs, I didn't come across any simple data URIs generators. Cuando estaba investigando URIs de datos, no encontré ningún generador simple de URIs de datos. Está la cocina de URIs de datos de Hixie, pero sólo está disponible online. Lo que realmente buscaba era algo para ser ejecutado en la línea de comandos para poder crear CSSEmbed. Por eso he creado DataURI, que es una sencilla herramienta que lee un archivo y muestra su representación como una URI de datos. DataURI es el motor subyacente utilizado por CSSEmbed para crear sus URIs de datos.

DataURI is also written in Java and requires Java 1.5+ to run. DataURI también está escrito en Java y requiere Java 1.5 o superior para funcionar. Al igual que con CSSEmbed, hay un archivo JAR que contiene todas las dependencias. Las mismas opciones generales de línea de comandos están disponibles, por lo que el uso básico es muy similar a CSSEmbed:

java -jar datauri-xyzjar -o <output filename> <input filename>

Por ejemplo:

java -jar datauri-xyzjar -o output.txt image.png

Los archivos a codificar no tienen por qué ser locales, se pueden incluir URLs en la línea de comandos y se descargan y codifican:

ava -jar datauri-xyzjar -o output.txt http://www.your.domain.com/image.png

Cuando se omite la opción -o, la salida termina en stdout con lo que se puede redirigir a un archivo directamente:

java -jar datauri-xyzjar styles.css > styles_new.css

Las instrucciones de uso completas están disponibles mediante -h:

Usage: java -jar datauri-x.y.z.jar [options] [input file]

Global Options
   -h, --help            Displays this information.
   --charset    Character set of the input file.
   -v, --verbose         Display informational messages and warnings.
   -m, --mime      Mime type to encode into the data URI.
   -o              Place the output into . Defaults to stdout.

DataURI es capaz de crear URIs de datos de URIs de las imágenes y de algunos archivos de texto (para la lista completa, consulta la documentación). El código fuente está disponible (Licencia MIT) del proyecto GitHub y puedes informar de errores igualmente.

Agradecimientos

I was inspired to create these tools after reading, Me inspiré para crear estas herramientas después de leer Not Just a Pretty Face: Performance and the New Yahoo! de Ryan Grove, Stoyan Stefanov, y Venkateswaran Udayasankar del equipo de búsquedas de Yahoo!. La sección sobre las URIs de datos me llevó a investigar más y, finalmente, a la creación de CSSEmbed y de DataURI.

Estoy lejos de ser tan bueno en Java como lo soy con JavaScript, así que tener un gran ejemplo funcionando ha hecho este desarrollo más fácil. Debo agradecer a Julien Lecomte porque he utilizado el código fuente del YUI Compressor como una guía sobre cómo organizar mi código. El código de Julien es tan limpio que era fácil configurar mis proyectos de la misma manera. También utilicé su archivo Ant como base para el mío.

Seguimiento

Las URIs de datos son definitivamente excitantes como medio para mejorar el rendimiento de sitios web. Cada gran impulso hacia adelante en las técnica de desarrollo necesita de un buen conjunto de herramientas para aumentar su adopción. Espero sinceramente que CSSEmbed y DataURI puede ayudar a la gente a empezar con la creación y el uso de URIs de datos.

URIs de datos (Data URIs)

2009-10-29T16:30:00.012+01:00

He traducido el artículo de Nicholas C. Zakas sobre URIs de datos por su interés.

Explicando las URIs de datos

Uno de las peticiones más frecuentes para características de los navegadores es el soporte de URIs de datos. Ha habido bastante literatura últimamente sobre URIs de datos: mi colega Stoyan Stefanov ha escrito un par de artículos sobre ellos, y mi ex colega Hedger Wang también escribió otro acerca de cómo utilizar URIs de datos en IE. Sorprendentemente, todavía hay un montón de malentendidos y confusión sobre las URIs de datos, qué son, cómo funcionan, y por qué querrías usar una.

URI, no URL

URL es la abreviatura de Uniform Resource Locator, que es una combinación de protocolo (cómo recuperar los datos) y la dirección donde se puede encontrar un recurso determinado. Todos los recursos públicos accesibles, como una imagen, un archivo JavaScript, archivo HTML, o una hoja de estilo CSS, tienen una dirección URL que indica al navegador desde donde descargar el archivo. Entonces el navegador establece una conexión y empieza a descargar y / o ejecutar el archivo. Cada URL también es una URI, que es la abreviatura de uniform resource identifier. Una URI indica un protocolo para recuperar información, así como información adicional sobre el recurso. Esa información adicional puede ser una dirección (si lo es, entonces la URI es una dirección URL) o no serla, pero siempre está relacionada con el protocolo especificado. Por lo tanto, las URIs de datos no son direcciones URL, ya que no contienen información de dirección.

Formato de URI de datos

El formato de datos URI es bastante simple y se explica en el RFC 2397 (que en realidad es lo suficientemente corto para que se puede leer todo). El formato básico es el siguiente:

data:[<mime type>][;charset=<charset>][;base64],<encoded data>

En este formato, data: es el protocolo de la URI, que indica que ésta es una URI de datos. La segunda parte, el tipo MIME, indica el tipo de datos que se representa. Para imágenes PNG, por ejemplo, éste sería image/png. Cuando no se especifican, el valor predeterminado para el tipo MIME es text/plain. El conjunto de caracteres generalmente puede ser omitido sin problemas y no se utiliza para imágenes. La próxima sección indica la codificación utilizada. Contrariamente a la creencia popular, no se está obligado a usar la codificación Base 64. Si el contenido no está codificado en base 64, los datos se codifican mediante la norma de codificación de URLs (caracteres ASCII seguros para URLs representados directamente y todos los demás representados como una codificación hexadecimal en formato %xx). Los datos codificados pueden contener espacios en blanco, el cuál no se considera significativo.

Base 64

Base 64 es un sistema de codificación mediante el cual los datos se convierten en bits y luego se agrupan numéricamente en un conjunto de dígitos en base 64. Los dígitos de Base 64 incluyen de la A a la Z, mayúsculas y minúsculas, los números y los símbolos más (+) y barra (/). El signo igual (=) se utiliza para indicar que se ha producido relleno (por favor lee el artículo de Wikipedia para más información sobre esto). Todo lo que realmente necesitas entender es que la codificación en base 64 hace que los datos codificados sean mucho más pequeños. He aquí un ejemplo de una imagen GIF como una URI de datos codificados en base 64 (via):

data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge
8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1h
LnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g
77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7

La misma imagen puede ser representada sin la codificación de base 64 de la siguiente forma:

data:image/gif,GIF89a%22%00%1B%00%F7%00%00lll%D6%D6%D6%FF%EB%85
%FF%E0%7B%FF%F7%91%FF%D4o%DF%DF%DF%F6%F6%F6%87%87%87%FE
%CBf%FF%F4%8E%E6%B3NKKK%C5%92-%FF%FF%99%FF%FF%FF%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00
%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%2C%00%00
%00%00%22%00%1B%00%00%08%A9%00%1F%08%1CH%B0%A0%C1%83%08
%13*%5C%C8%B0%A1%C3%87%10%23J%9CH%91%60%83%8B%0D%0C%1C
%A8h%B0%81%C5%00%1B9%0A%F4%E8%A0%A4%83%07%181j%9C%D8%80
%80%82%97%2F%0B6%40%60%80%A5%00%01)s%AA%94%D8%60%80G%84
%02P%22%E0Y%A0%81%C9%A3%25%138h%00%80g%02%A3%04%A2J%8D
%BA%60i%D3%88%0D%9E%3A%B8%C9%95kU%A6N%8D%0E%18Kv%EC%D7
%AB%10%B3%1A-%C0%B6-%5B%A3%60%23%1A%D0I%97%C1%D0%88%07
%02%20%00%C0%B7%AF_%00%08%02L%3C%60%20%80%E1%C3%88%03
%AC%14%C9%B8%B1%E3%C7%90%23K%9EL0%20%00%3B

El claro ganador en tamaño es la versión codificada en base 64 de la imagen, que es significativamente menor. Nota: La codificación en Base-64 hace que las imágenes sean más grandes en realidad. Sin embargo, si estás utilizando compresión HTTP, probablemente no notarás la diferencia, porque los datos codificados en base 64 comprimen muy bien. Si por alguna razón no puedes usar la compresión HTTP, puede que desees comprobar la cantidad de bytes que estás enviando para determinar si el compromiso vale la pena.

No sólo para imágenes

Aunque la mayoría de la gente habla de URIs de datos como la forma de incluir imágenes dentro de un archivo HTML o CSS, no hay nada aquí que lo haga específico para imágenes. Puedes codificar e incorporar cualquier tipo de archivo, incluso HTML mismo. Ian Hickson, conocido por HTML 5, tiene una herramienta que te permite jugar con URIs de datos. El ejemplo por defecto es un archivo HTML que puede convertirse en una URI de datos ya sea con o sin codificación en Base 64. Jugando con este generador de datos URI un rato realmente ayuda a solidificar los conceptos básicos. Nota: Internet Explorer 8 tiene restricciones de seguridad sobre las URIs de datos que las hacen menos útiles para datos que no sean imágenes.

Implicaciones de rendimiento

La parte más interesante de la historia sobre URIs de datos es que te da la capacidad de insertar archivos dentro de otros archivos. La mayoría de artículos se centran en incorporar URIs de datos en archivos CSS como una forma de mejorar el rendimiento. De hecho, ha habido una gran cantidad de investigaciones que indican que las peticiones HTTP son uno de los principales agujeros de rendimiento para sitios web, y la disminución del número de solicitudes resulta en un mejor rendimiento de página. "Minimizar las peticiones HTTP" es en realidad la primera regla de las "mejores prácticas para un rendimiento excepcional" de Yahoo!, y se mencionan específicamente las URIs de datos:

Las imágenes en línea usan el esquema de URIs data: para integrar los datos de imagen en la página. Esto puede aumentar el tamaño de tu documento HTML. La combinación de imágenes en línea en tus hojas de estilo (en caché) es una manera de reducir las peticiones HTTP y evitar el aumento del tamaño de tus páginas. las imágenes en línea no son todavía compatibles con todos los principales navegadores.

Este es un buen consejo para el uso de URIs de datos: úsalos donde se almacenen en caché con más frecuencia. Las imágenes regulares descargadas se almacenan en caché a través de HTTP de acuerdo con sus cabeceras y / o con la configuración específica del navegador de modo que no será necesario volver a descargarlas cada vez. Las URIs de datos se consideran parte del archivo que los contiene, por lo que son parte del código HTML o CSS archivo en el que están insertadas. Esto significa que las URIs de datos no tienen una política independiente de control de la caché. Incrustar URIs de datos en los archivos los hace más grandes, y si el archivo cambia con frecuencia (como la página principal de un blog), entonces ese archivo más grande debe ser descargado con frecuencia. Eso ralentiza tu sitio. La forma más fácil de usar URIs de datos es incrustarlos en hojas de estilos externas que se almacenan sistemáticamente en caché. De esta manera, la experiencia con el caché vacío es más rápida (debido a las se generan menos peticiones) y la experiencia con el caché cargado es la misma.

Soporte en navegadores

La mayoría de los navegadores actuales son compatibles con las URIs de datos:

Firefox 2+
Opera 7.2+ - las URIs de datos no deben ser superior a 4.100 caracteres
Chrome (todas las versiones)
Safari (todas las versiones)
Internet Explorer 8+ - Las URIs de datos deben ser menores de 32k

Puesto que las URIs de datos no están soportadas en Internet Explorer anteriores a la versión 8, necesitas decidir si vale la pena servir contenido alternativo para esos navegadores (Leer post Stoyan).

Conclusión

Las URIs de datos son un concepto interesante y único en la Web, y es probable que obtengan una mayor cobertura en el futuro. Por el momento, parece que se adaptan mejor a las tareas relacionadas con el rendimiento, pero quién sabe qué nos deparará el futuro. En el corto plazo, puedes ver algunos ahorros en rendimiento mediante la utilización de las URIs de datos para eliminar solicitudes HTTP adicionales de descarga de imágenes. Las URIs de datos también abren la posibilidad de generar imágenes dinámicamente usando JavaScript, aunque el creciente soporte a <canvas> puede hacer que este caso de uso quede obsoleto.

El fin de la asimetría de HTTP en la web

2009-09-19T13:42:00.003+02:00

Aunque la web original estaba pensada de forma que los navegadores iban a funcionar también como servidores, dicha simetría no tardo en perderse y pronto una web destinada a lectura y escritura se volvió en un sistema de visionado de documentos de hipertexto (enlazados entre sí) ofrecidos por lo que conocemos como servidores web. Es decir, la funcionalidad que iba a ser ofrecida por programas que interpretaban y servían se dividió en dos: los navegadores interpretaban y los servidores web servían. Al principio, no existían documentos dinámicos, es decir, generados al vuelo, sino más bien, y al igual que con FTP, se trataba de documentos estáticos que se actualizaban y se subían al servidor. Mucho después llego el CGI y con él el ecosistema de servidor de aplicaciones y las posibilidades de las aplicaciones web.

El protocolo HTTP, además, no tiene estado. Cada consulta que recibe un servidor es totalmente nueva para él. Por ello son necesarias las cookies (o mantener un id en la URL) para que el servidor rescate la información de una sesión de un mismo usuario.

Pronto apareció la necesidad de no tener que recargar una página entera para actualizar una parte de ella, lo que conocemos hoy como AJAX. Microsoft inventó el Remote Scripting en 1998 seguido pronto por la librería JSRS de Brent Ashley, pero no fue hasta 2005 cuando Jesse James Garrett acuñó el termino en Ajax: a new approach to Web Applications con el que conocemos a esta técnica basada en aprovechar una conexión desde JavaScript para solicitar datos al servidor y actualizar la página visualizada en cuanto llegue la respuesta.

¿Qué tenemos? Una web asimétrica en la que aplicaciones web en un navegador realizan peticiones (de una página o parciales) a un servidor web. ¿Qué nos falta? Un método para que un servidor nos realice notificaciones (cuando algo cambia). Es lo que se conoce como PUSH y es idéntico a los sistemas de notificación de llegada de correo electrónico en los móviles: con una BlackBerry necesitamos una conexión continua con un servidor para que éste nos notifique las novedades.

Existen tres formas para conseguir que el navegador se entere de que hay novedades:

Consultar insistentemente al servidor. Es la forma más ineficiente. Consume muchos recursos y la mayor parte de las veces la respuesta va a ser que no hay nada nuevo. Es el sistema que se utiliza con las fuentes RSS o ATOM sobre novedades en una web. Es equiparable al niño en el asiento de atrás del coche preguntando cada 10 segundos: "¿Cuánto queda?"
Comet. Abrir una conexión permanente/persistente con el servidor web. También consume recursos y origina un problema al obligar a que el servidor mantenga abiertas un número elevado de conexiones. Es posible implementarla sobre HTTP de forma que el servidor web no cierre una conexión y vaya ofreciendo la información en pequeñas dosis con las actualizaciones. O bien se puede montar un servidor paralelo dedicado a ellas. Es el sistema que se utiliza en los chats web.
Finalmente, y he aquí la novedad, se puede rescatar la idea original de Tim Berners-Lee y añadir un pequeño servidor a cada navegador. ¿Con qué finalidad? Permitir que un servidor nos haga una petición directamente al navegador. Si no lo has visto aún, echa un vistazo a esta demo. Esa página web, crea una conexión persistente con un servidor, a través de la cuál puede recibir peticiones que la propia página web en el navegador se encarga de contestar (mediante una petición HTTP con la respuesta al mismo servidor). Funciona y permite hacerse una idea de las posibilidades, aunque no haya un servidor realmente en el navegador. El principal inconveniente de implementar un servidor como tal es que por la arquitectura de Internet resulta muy complejo conseguir que éste reciba peticiones desde el exterior saltándose proxies y firewalls. Por ello en el ejemplo anterior, conocido como ReverseHTTP, la conexión de servicio la inicia el navegador, porque en ese sentido (navegador -> servidor web) la conexión no es un problema. La idea que intento transmitir es vencer la asimetría del HTTP (el servidor no puede enviar información al navegador) creando una infraestructura idéntica a la existente pero en sentido contrario (el servidor se convierte en cliente/navegador y realiza peticiones HTTP al servidor incorporado en el navegador del visitante). Se trata de una solución extremadamente elegante que permite la que esta empezando a conocerse como web en tiempo real. Al mecanismo por el que un servidor notifica a otro mediante una petición HTTP a una URL acordada entre ambos se conoce como WebHook. Actualmente se empieza a usar entre servidores de Internet y permite, por ejemplo, que un nuevo artículo de una web sea enviado a nuestro móvil en el instante en que es publicado. Términos como PushButton, RSSCloud o PubHubSubBub están ahora mismo en pleno auge, pero sigue necesitándose un estándar en el mismo navegador que permita convertirlo en una especie de servidor que reciba notificaciones y actúe en consecuencia. Y estamos a un solo paso: HTML5 Server-sent Events.

Addendum: Añado la definición de Real-Time Web hecha por ReadWriteWeb:

La Web en Tiempo Real es un paradigma basado en enviar información a los usuarios tan pronto como esté disponible - en lugar de requerir que éstos o su software compruebe periódicamente si hay actualizaciones. Puede ser habilitada de diferentes formas y puede requerir una arquitectura técnica distinta. Se está implementando en redes sociales, búsquedas, noticias, y otros sitios - haciendo esas experiencias más parecidas a la Mensajería Instantánea (chat) y facilitando innovaciones imprevisibles. Los primeros beneficios incluyen un compromiso mayor de los usuarios ("flujo") y cargas más reducidas en los servidores, pero esto es sólo el principio. La entrega de información en tiempo real probablemente se haga ubicua, un requisito para casi cualquier website o servicio.

URLPacks, grupos de páginas en el navegador

2009-08-18T20:33:00.000+02:00

Tengo la mala costumbre de abrir más y más pestañas con páginas a las que quiero dedicar tiempo en algún momento y que se van acumulando hasta que se llena la barra de pestañas. Entre otros problemas, esta mañana me ha pasado que Google Chrome ha dado un error justo cuando intentaba restaurar todas las que tenía abiertas anteriormente y se ha cerrado. Al volverlo a abrir, ha aparecido una triste pestaña en blanco, algo que, por desgracia, ya me ha pasado anteriormente con Firefox. Aunque he conseguido restaurar las páginas abiertas gracias al historial, me he prometido que iba a resolver de una vez por todas el maldito problema de las pestañas y me he puesto manos a la obra.

La idea es tener una aplicación web muy ligera que acumule URLs relacionados con un tema y que se muestre como si fuese una barra de sub-pestañas. La aplicación está incluida en un único archivo PHP que realiza todas las funciones:

mostrar la página del grupo (get). Se muestra como una barra horizontal de enlaces que al ser pulsados cargan la página en la parte inferior, justo como si se tratase del mismo navegador. Además hay botones para limpiar la parte inferior, crear un marcador del grupo o agregar una nueva URL
crear un grupo nuevo (post)
agregar una nueva url a un grupo existente (put)
eliminar una URL del grupo (delete)
listar los grupos disponibles (list)
mostrar un favicon personalizado para un grupo mostrando las primeras 6 letras del título

Para almacenar la información sobre los grupos, he decidido usar un archivo ZIP de nombre "urlpacks.zip" alojado junto al archivo "urlpacks.php" que aparece a continuación. El ZIP contiene un archivo comprimido por cada grupo; el nombre coincide con el título del grupo; y el contenido son las URLs separadas por un salto de línea: Más sencillo imposible.

<?php
$id= $_GET['id'];
$action= $_GET['action'];
$url= $_GET['url'];

if($action=='') {
 if (!empty($url)) $action="post";
 else $action="list";
}

$zip = new ZipArchive();
if ($zip->open('urlpacks.zip')!==TRUE) {
    exit("cannot open urlpacks.zip\n");
}

switch ($action) {
case 'favicon':
 header('Content-type: image/png');
 $im= imagecreate(16,16);
 $color= imagecolorallocate($im, 255,255,255);
 $string= str_replace(' ','',$id);
 $font = imageloadfont('./terminal9.gdf');
 imagestring($im, $font, 1, -1, $string, imagecolorallocate($im, 0,0,0));
 imagestring($im, $font, 1, 6, substr($string,3), imagecolorallocate($im, 90,90,90));
 imagecolortransparent($im,$color);
 imagepng($im);
 imagedestroy($im);
 exit;
case 'put':
 $data= explode("\n", $zip->getFromName($id));
 array_push($data,$url);
 $zip->addFromString($id, implode("\n",$data));
 header("location:?action=get&id=".$id);
 exit;
case 'post':
 if (!$zip->getFromName($id)) $zip->addFromString($id, $url);
 header("location:?action=get&id=".$id);
 exit;
case 'delete':
 $data= explode("\n", $zip->getFromName($id));
 $key= array_search($url, $data);
 if ($key!==FALSE) array_splice($data,$key,1);
 $zip->addFromString($id, implode("\n",$data));
 header("location:?action=get&id=".$id);
 exit;
case 'list':
 echo "index
";
 for ($i=0; $i<$zip->numFiles;$i++) {
  $item= $zip->statIndex($i);
  echo '',$item['name'],' ';

  $data= explode("\n", $zip->getFromName($item['name']));

  if (count($data)>0) {

   echo '';
   foreach($data as $link) echo '',$link,'';
   echo '
';

  }

  echo '';
 }
 echo '';
 exit;
default:
}
$zip->close();
$zip->open('urlpacks.zip');
$data= $zip->getFromName($id);
$data= explode("\n", $data);
if (!is_array($data)) $data= Array($zip->getFromName($id));
?>
<head>
<title><?=$id?> :: URLPacks</title>
 <link rel="shortcut icon" href="urlpacks.php?action=favicon&id=<?=$id?>" type="image/png" />
</head>
<body>
<style>
body {
 font: 9px verdana, arial, sans-serif;
 margin:0;
 background:url(/images/grid.gif);
 overflow:hidden !important;
}
.action{
 text-decoration:none;
 color:red;
 font-size:15px;
 font-weight:bold;
}
li {
 padding:0 3px;
 white-space:nowrap !important;
 width:150px;
 overflow:hidden !important;
 border:1px outset gray; border-bottom-width:0;
 float:left;
 margin-right:2px;
 background:white;
}
li a { text-decoration:none; }
li a:focus { background: yellow; }
ul {
 top:25px;
 left:5px !important;
 position:absolute;
 padding-left:0 !important;
}
.icon {
 position:absolute;
 top:3px;
 width:22px;
}
.titulo {
 margin-left:90px;
 margin-top:-16px;
 font: bold 50px calibri, tahoma, verdana, arial, sans-serif ;
 letter-spacing:-1px;
 position:absolute;
}
iframe { border-top:1px solid black; background:white; }
img { border:0; }
</style>

<a title="marcador para grupo <?=$id?>" href="/urlpacks.php?&id=<?=$id?>"><img src="http://www.iconfinder.net/data/icons/oxygen/22x22/actions/bookmark.png" class="icon" /></a>
<a href="about:blank" target="page"><img src="http://www.sonicvisualiser.org/doc/reference/1.3/en/images/icons/erase.png" title="vaciar marco inferior" style="margin-left:24px;" class="icon" /></a>
<a title="agrega nuevo enlace" class="action" href="#" onclick="if (newurl=prompt('URL','')) {location.href='?id=<?=$id?>&action=put&url='+newurl; }"><img src="http://academia.usbbog.edu.co/imagenes/add.png" style="margin-left:50px;" class="icon" /></a>
<span class="titulo"><?=$id?></span>
<ul><?php
foreach($data as $link) {
 echo ' ',$link,' ';
}
?></ul>
<iframe name="page" src="about:blank" style="width:100%;height:100%;margin-top:50px;" frameborder=0></iframe>
</body>
<?php

$zip->close();
?>

Para crear un nuevo grupo a partir de la página actual, tengo un bookmarklet en el navegador con el siguiente código:

javascript:id=prompt('nom',Math.random().toString().substr(2));location.href='http://servidor/urlpacks.php?id='+id+'&url='+location.href;

En mi servidor de alojamiento funciona perfectamente y he reducido notablemente las pestañas abiertas. Espero que le sea útil a alguien más. Por cierto, he probado varias extensiones de Firefox para conseguir lo mismo, pero ahora mismo estoy usando Chrome y quería mantener yo la información de los grupos (fácilmente descargable mediante http://servidor/urlpacks.zip)

La web del Pushbutton (3)

2009-08-17T18:07:00.001+02:00

Traduzco El "tiempo real" se vuelve "real" de Anil Dash. Con este artículo termino la serie de tres aunque continuaré publicando sobre estos temas por su interés. Posiblemente "pushbutton" se convierta en un término tan familiar como "Ajax" en un futuro cercano. Pushbutton es el nombre para lo que creo que será una actualización para la web, en la que cualquier sitio o aplicación pueda entregar mensajes en tiempo real a una audiencia a la escala de la web, usando tecnologías gratuitas y abiertas de bajo coste y sin confiar en una sola compañía como Twitter o Facebook. Las piezas de esta plataforma acaban de unirse para hacer posible un conjunto de nuevas características y aplicaciones que habrían sido casi imposibles de desarrollar en el pasado para un desarrollador web medio. El área más interesante de nuevo desarrollo en la web es la innovación que tiene lugar alrededor de la mensajería en tiempo real, la habilidad de entregar actualizaciones a un sitio web o a una aplicación en uno o dos segundos. Mientras que varios sistemas como Yahoo News Alerts o lectores de fuentes (feeds) como Google Reader han ofrecido formas simples de entregar notificaciones relativamente rápidas, aún están construidas sobre infraestructuras que confían en solicitar repetidamente una página web. Estos sistemas hacen el equivalente a pulsar repetidamente el botón "actualizar" del navegador. Mientras que esos sistemas han estado usando estos métodos ineficientes para entregar actualizaciones, plataformas más modernas como Twitter, Facebook y FriendFeed se han enfocado en construir la infraestructura para la entrega eficiente a gran escala de actualizaciones usando sus propias redes propietarias. Se ha prestado mucha atención al límite de 140 carácteres de Twitter, o al News Feed de Facebook, pero la impresionante tecnología que permite esa experiencia de usuario en estas plataformas es la inmediatez con la que las actualizaciones son entregadas. Los sistemas anteriores, como la mensajería instantánea o el chat, permitían mensajería a tiempo real a cualquiera de uno a uno o a pequeños grupos, pero ha sido difícil entregar esos mensajes en tiempo real a todo el mundo que quería recibirlos a menos que se tuviese mucho dinero, conocimientos e infraestructura. Otra barrera es que, mientras que hay diferentes programas y clientes que te dejan conectarte a Twitter o Facebook con tus propias aplicaciones, no ha habido opciones abiertas y gratuitas para entregar mensajes en tiempo real a una audiencia mayor si no podías, o no querías, confiar en dichas compañías. Pero recientemente, unas pocas piezas clave han encontrado su sitio y que hacen relativamente fácil y económico añadir mensajería en tiempo real como una mejora incremental a sitios y aplicaciones web. Este conjunto de tecnologías relacionadas, que estoy llamando plataforma Pushbutton, producirá un amplio conjunto de nuevas capacidades para usuarios, editores y desarrolladores en la web. Y lo mejor, las tecnologías Pushbutton son gratuitas, abiertas y descentralizadas, significando con ello que la llegada del tiempo real a la web no será dominado por una sola compañía.

Definiendo Pushbutton

El concepto y potencial de Pushbutton es como el de Ajax - no es una sola tecnología o invención, es una familia entera de tecnologías, algunas de las cuales han estado en desarrollo o en producción cerca de una década, que juntas permiten esta nueva web en tiempo real. La base de Pushbutton está construida sobre estos sistemas:

Atom y RSS: Los formatos de fuente más comunes para sindicación en la web
PubSubHubBub y RSSCloud: potentes nuevos distribuidores de mensajes
Web Hooks: Simples servicios web para recibir mensajes en lugar de enviarlos

Los sistemas Pushbutton usan HTTP, el protocolo fundamental de la web, para la comunicación entre estos componentes. La arquitectura de la entrega de mensajes en Pushbutton es fácil de comprender. Antes de Pushbutton, en los sistemas modernos, cuando creas un mensaje (un artículo de un blog, un tweet u otra actualización) se publica en tu fuente RSS o Atom, cada aplicación o sitio que quiere recibir las actualizaciones tiene que solicitar repetidamente la fuente para saber cuando ha cambiado. Opcionalmente se puede notificar ("ping") a algunas aplicaciones para indicarles que ha llegado el momento de recoger las nuevas actualizaciones, pero esto resulta pesado en tiempo y recursos para ambos lados, especialmente si quieres notificar a un montón de gente. En el mejor caso, el sistema que tenemos ahora es análogo a una persona que viene a tu casa y te dice "eh, hay una nueva edición de tu periódico favorito. Debes ir a por ella". Y entonces tienes que ir a la fábrica donde se imprime el periódico a recoger tu copia. En la web Pushbutton, esa persona entrega la noticia entera en tu casa en el instante en el que es publicada. Eso es así porque las aplicaciones que implementan Pushbutton mejorarán el sistema actual entregando no sólo la notificación de que hay un nuevo mensaje, sino el contenido del mismo. Y en lugar de requerir que todas las aplicaciones vengan al sitio a leer la actualización, usan un servidor distribuidor (hub) en la nube para pasar el mensaje directamente a todos los receptores que estén interesados.

Tú, el emisor, creas un mensaje a ser entregado via RSS o Atom
Tu aplicación da el mensaje a uno o más distribuidores PubSubHubBub o RSSCloud que residan en la "nube"
Los distribuidores PubHubSubBub o RSSCloud entregan el mensaje a todos los receptores, las aplicaciones o sitios que hubiesen solicitado actualizaciones de tu sitio

De esta forma, cada vez que creas un mensaje, un gran numero de receptores pueden consumir ese mensaje casi en tiempo real (normalmente menos de un segundo) sin apenas complejidad. Este tipo de mensajería ha sido posible con tecnologías propietarias o más oscuras, pero el ecosistema Pushbutton supone un gran avance por las siguientes razones:

Enviar mensajes requiere solo un cambio pequeño a una fuente RSS o Atom, y una notificación simple y bien definida en lugar de cambios importantes a la aplicación donde creas tus mensajes
Recibir mensajes es también muy simple requiriendo sólo que un desarrollador programe la gestión de notificaciones de actualizaciones
La mayoría de la complejidad del sistema la gestionan los servidores de distribución, que están bien documentados, implementables en una variedad de lenguajes de programación y construido alrededor de código abierto que probablemente atraiga a una gran comunidad de desarrolladores
La mayoría del esfuerzo de escalado y de los costes tienen lugar a nivel de distribuidor, y todos los distribuidores actuales están diseñados para ejecutarse sobre sistemas "nube" económicos como Google App Engine o Amazon EC2
El software para enviar, recibir o ejecutar un distribuidor es gratuito, de fuente abierta y está disponible en casi cualquier plataforma
Los mensajes enviados sobre plataformas Pushbutton son entregados via HTTP, que es familiar a cualquier desarrollador web y funciona bien sobre cualquier entorno de alojamiento. Todas las peticiones entre las diferentes capas del sistema Pushbutton pueden ser realizadas como simples llamadas REST
Las tecnologías Pushbutton pueden ser adoptadas incrementalmente, de forma que las características pueden ser añadidas poco a poco en el lado del receptor o del emisor, sin requerir una actualización completa a la arquitectura de la infraestructura o de la aplicación

Quién está detrás de Pushbutton

Las tecnologías Pushbutton han sido creadas y defendidas por algunos de los desarrolladores más creíbles y experimentados de las tecnologías web sociales. A continuación puede verse un breve resumen de la experiencia de dichos componentes:

PubHubSubBub fue co-creado por Brad Fitzpatrick y Brett Slatkin de Google. Brad fue el fundador de LiveJournal, y creó tecnologías web sociales tan fundamentales como Memcached u OpenID
Las ideas de los pings de actualización XML-RPC, RSS y la RSS Cloud fueron promovidas por Dave Winer, que ha estado desarrollando activamente implementaciones abiertas de estas tecnologías
Los Web Hooks han sido evangelizados por Jeff Lindsay, y han sido desplegados por una variedad de distintas compañías y plataformas que desarrollaron dicha técnica por su cuenta

Además Google ha apoyado el desarrollo por Brad y Brett de PubSubHubBub, y ha permitido su uso sobre el servicio Google FeedBurner. Varias compañías más pequeñas están desplegando grandes partes de esta infraestructura. En breve, algunas de las mejores reputaciones en el desarrollo de sistemas web abiertos han hecho posible Pushbutton, desde las compañías tecnológicas más grandes hasta los desarrolladores independientes más firmes de la web.

Ideas relacionadas y proyectos anteriores

Hay un montón de tecnologías existentes que han influenciado la creación y evolución de las tecnologías Pushbutton; Si estás familiarizado con alguno de esos sistemas probablemente ya estés avanzado en comprender parte de lo que Pushbutton intenta conseguir.

Twitter Firehose, FriendFeed SUP, el flujo de actualizaciones de TypePad: Estos sistemas de entrega en tiempo real ofrecen el contenido de sus respectivas plataformas como un flujo interminable que los desarrolladores pueden consumir y usar en sus aplicaciones. Actualmente, todos tienen licencias y grados de apertura distintos, y formatos ligeramente diferentes para entregar las actualizaciones, pero han probado la utilidad de la "parte de envío" de la funcionalidad en tiempo real de Pushbutton
XMPP (Jabber), NNTP (Usenet), IRC: Estos viejos protocolos de internet han ofrecido varios grados de mensajería en tiempo real y capacidades de distribución de mensajes, y pueden formar una base de experiencia muy útil de la que los desarrolladores de Pushbutton pueden aprender. En algunos casos, elecciones fundamentales de arquitectura sobre seguridad, autenticación o arquitectura fueron hechas cuando la Internet estaba menos poblada y era menos compleja, haciendolas inapropiadas para las aplicaciones de hoy. En todos los casos, estos protocolos son menos conocidos por los desarrolladores web más contemporáneos, y por ello se echan en falta toolkits y recursos de desarrollo, que hace que resulte muy complejo desplegarlos en entornos comunes.
TrackBack y Pingback: Estos sistemas de entrega de actualizaciones entre sistemas de publicación (blogs) fueron muy efectivos en permitir conversaciones ricas distribuidas en los primeros días de la blogosfera. Estos han ido disminuyendo en utilidad debido a las implementaciones deficientes o nulas de un sistema de autenticación que han llevado a problemas de spam, y a una falta general de comprensión de su utilidad por parte de los nuevos bloggers. Pushbutton podría ofrecer una oportunidad de restaurar algo del valor de la idea que originó estos sistemas
Reverse HTTP podría terminar siendo un componente útil de algunas implementaciones de Pushbutton, como complemento o como compañía a Comet y técnicas relacionadas

Posibles problemas:

¿Una guerra de formatos? Si estás familiarizado con las comunidades que discuten de tecnologías como fuentes (feeds) sabrás que tienen una merecida reputación de ser contenciosas e, incluso, de abrir acaloradas disputas sobre detalles arcanos. No creo que sea probable que esto pase aquí, ya que sólo hay uno o dos formatos viables para cada capa de la plataforma y los creadores de cada parte han mostrado esfuerzos consistentes y de buena fé para promover la interoperabilidad donde sea posible y la coexistencia pacífica donde sea necesario. En la comunidad Ajax, por ejemplo, la "X" de Ajax a menudo significa JSON en lugar de XML, pero esto no ha dificultado su amplia adopción. También estoy deseando comprometerme personalmente para intentar prevenir cualquier tipo de conflicto interpersonal que pudiera inhibir la adopción de dichas tecnologías. ¿Preocupado? No
¿Temas de escalado? Inevitablemente habrá aprender cosas sobre cómo escalar una capa de distribución intensiva en recursos de un sistema Pushbutton. Pero puesto que los distribuidores trabajan en sistemas de "la nube" que hacen fácilmente disponibles enormes cantidades de recursos computacionales, puesto que los programadores que creen las implementaciones de referencia del software de distribución tienen una gran experiencia haciendo sistemas a escala web y puesto que es relativamente simple introducir nuevos distribuidores conformes se necesite, esto probablemente no resulte un factor importante para la adopción de Pushbutton. ¿Preocupado? No
¿Inquietudes sobre propiedad intelectual? No soy abogado y esto no es consejo legal. Pero ya ha habido un gran interés sobre estos sistemas y es probable que si aparecen malos actores interesados en lanzar sus abogados de patentes sobre esta clase de sistema, probablemente ya estarían demandando a diestra y siniestra. Y los jugadores principales que ya se han implicado han mostrado un deseo consistente en crear sistemas verdaderamente abiertos que no tengan impedimentos de propiedad intelectual. Dicho de forma simple, creo que cualquier lo suficientemente listo para inventar esta clase de tecnologías es lo suficientemente listo para no querer parecer estúpidos demandando a alguien por usarlas. ¿Preocupado? Probablemente no
¿Competición por parte de sistemas centralizados? Las tecnologías Pushbutton no son sólo gratuitas y abiertas, son descentralizadas, por lo que resultan una seria amenaza al modelo "trampa de langostas" del software social. Podemos esperar competición seria de las redes centralizadas que están actualmente construyendo esta clase de sistemas. Si hay una amenaza para la adopción de Pushbutton, esta será probablemente la causa. ¿Preocupado? Sin duda
¿Mala experiencia de usuario? Una de las peores cosas que podemos hacer para usar las nuevas tecnologías es ignorar las implicaciones sociales, personales e incluso políticas de dicho uso. Mensajes que sean entregados inmediatamente no pueden, por su propia naturaleza, ser borrados de todos los sitios en los que aparezcan. La idea de archivar permanentemente estos tipos de mensajes no es familiar para muchos de los usuarios menos familiarizados tecnológicamente. Y cuando vemos algo brillante y nuevo, tenemos la tentación de usar tecnologías porque sí, estemos o no resolviendo un problema real u ofreciendo un valor real. Si Pushbutton recibe un mal golpe pronto a pesar de su potencial tremendo, esta será la razón. ¿Preocupado? Por descontado, sí

Conclusión

Tengo una excitación tremenda sobre la nueva era en tiempo real de las aplicaciones web. Mientras que me considero fundamentalmente un persona optimista, tengo un gran escepticismo cuando se trata de dar bombo publicitario sin sentido sobre tecnologías nuevas, de forma que si me permito algo de ese bombo publicitario aquí lo hago con algo de desgana. Pero creo que la web con Pushbutton tiene la oportunidad de dar, a los individuos y a las organizaciones con voces distintas y apasionadas, la habilidad de ser aún más inmediato y expresivo en la web, y después de diez años de publicación en la web, esa es la parte que más me gusta. No tengo dudas de que algunos escépticos dirán que "Pushbutton es sólo PubSubHubBub pero con otro nombre", justo como dijeron en su día "Ajax es XMLHttpRequest pero con otro nombre", y si eso es lo que los chicos super-geeky quieren creer, me parece bien. Y estoy seguro de que aún habrán algunos detalles técnicos por resolver. Pero creo que dando al concepto general una nombre comprensible y dando una explicación comprensible por cualquiera con interés, puede catalizar interés en una nueva área de innovación en la web. Y para ser honesto, cuando veo chicos como Brad Fitzpatrick y Dave Winer trastear sobre el mismo conjunto de problemas, no puedo evitar pensar que algo interesante saldrá de ello. Sobre los próximos días, perfilaré las oportunidades de Pushbutton, exponiendo más de la filosofía que tiene el potencial de darle a Pushbutton algo más de significado que la mayoría de nuevas tecnologías web, y proviendo algunas explicaciones simples de como puedes empezar aprendiendo sobre cómo sacar ventaja de estas tecnologías. Sobre todo espero que ofrecerás tus críticas meditadas, correcciones detalladas e incluso mejores ideas. Seguiré la conversación en los comentarios, en la blogosfera y en un Twitter con el tag #pshb.

Reverse HTTP (2)

2009-08-14T12:08:00.006+02:00

Una de las novedosas técnicas que están apareciendo para resolver el problema de la asimetría de HTTP (que el servidor web notifique a los navegadores sobre nuevas actualizaciones como los mensajes de un chat) pasa por aprovechar la tecnología Comet (una conexión persistente entre navegador y servidor que permite que el servidor le envie datos al navegador en cuanto los tenga disponibles y sin que el navegador los haya solicitado explícitamente).

La idea es que el navegador abre una conexión persistente con el servidor, el cual le asigna una URL (generalmente un subdominio) propia cuyas peticiones son respondidas por el Javascript residente en la página del navegador. De esa forma, la página estática mostrada en el navegador se convierte a todos los efectos en un servidor web capaz de responder a las peticiones entrantes como un servidor web tradicional.

Traduzco la página reversehttp.net donde se explica con más detalle el funcionamiento de esta técnica.

Realizar solicitudes para averiguar si hay actualizaciones es malo. Sabemos esto desde que existen los ordenadores. Pero si es así, ¿por qué hay tantos servicios basados en web (SUP, fuentes RSS y Atom, Twitter, etc.) basados en esas solicitudes?

La respuesta está, en primer lugar, en la asimetría de HTTP. La web está dividida en dos piezas: programas que realizan peticiones y programas que las manejan. Es muy raro ver un mismo programa comportándose a la vez como cliente y como servidor.

Para arreglar esta asimetría necesitamos ser capaces de actuar como si poder responder a las peticiones HTTP fuese fácil para los programas, de forma que podamos notificar los cambios a las partes interesadas simplemente enviándoles una petición HTTP. Esta es la idea principal de los web hooks.

Necesitamos hacer fuerza para empujar los procesos que traten con long-polling (Comet) lejos del núcleo de la web y hacia sus límites que es donde tiene que estar.

Necesitamos hacer que los programas pidan dinámicamente un pedazo del espacio de URLs usando un viejo cliente HTTP y gestionar las peticiones enviadas a las URLs en ese espacio usando ese mismo cliente HTTP.

Una vez que eso esté hecho, la notificación asíncrona de eventos estará al alcance de cualquier programa que tenga acceso a una librería cliente de HTTP, y los protocolos y servicios sobre HTTP no tendrán que contorsionarse para tratar con la asimetríá de HTTP. Pueden suponer que todo el mundo es un servidor y solicitar y enviar contenidos desde y hacia donde quieran.
La solución
Crear un túnel HTTP sobre HTTP de una forma estructurada, controlable y segura. Deja que los programas pidan una parte del espacio de URLs y sirve HTTP, todo por medio de una librería ordinaria cliente de HTTP.
Lee el borrador de la especifición.
Comprueba implementación.
Prueba las demos.
Incluso los programas que se ejecutan en entornos muy restrictivos, como Javascript en el navegador, pueden sacar ventaja del servicio ReverseHTTP. La implementación actual provee librerías sencillas y pequeñas para Python, Java y para el Javascript del navegador.
¿Por qué no se ha hecho esto antes?
Esta no es una idea completamente nueva, como parece, aunque no parece haberse usado ampliamente hasta el momento.

Prácticamente al mismo tiempo que estaba escribiendo ReverseHttp (hacia Mayo de 2008), Donovan Preston de Second Life escribía su versión de la misma idea, que también llamó Reverse HTTP (también conocida como "PTTH"). Su idea es usar la cabecera Upgrade de HTTP 1.1 para intercambiar la dirección del protocolo, lo que funciona bien para entornos distintos del navegador. Él también tiene una solución basada en Comet muy similar a la mía, excepto que la suya usa objetos JSON para describir las peticiones y respuestas HTTP mientras la mia usa los formatos de los mensajes HTTP. Donovan Preston escribe más sobre la variante Second Life aquí, y ha producido, junto a Mark Lentczner, un borrador (Internet-Draft) para el protocolo basado en la cabecera Upgrade.

Descargas y enlaces

Addendum

Es posible comprender mejor la potencia de esta técnica con la demo online disponible en http://www.reversehttp.net/demos/demo.html

Web Hooks (1)

2009-08-13T11:04:00.001+02:00

Este es la primera de una serie de tres traducciones de artículos que presentan tres tecnologías relacionadas y novedosas en el ámbito de la programación web. Web Hooks, Reverse HTTP y Pushbutton. La idea principal para habilitarla se describe en este primer artículo sobre webhooks: hacer disponible un script en una URL de forma que un servidor envie ahí información sobre cambios a los que se ha suscrito. Usa el famoso HTTP que siempre han usado los navegadores pero internamente entre servidores web para mandarse información.

Visita webhooks.org para información más actualizada sobre esta tecnología o el Grupo de Google para debatir

¿Qué son los web hooks?

Los web hooks (enganches web) permiten personalizar, extender e integrar las aplicaciones web que uses con todo lo que puedas acceder programaticamente. Para los desarrolladores web, los web hooks son un patron de diseño simple que sólo requiere la habilidad de hacer peticiones web y almacenar algo de información extra sobre los usuarios. Para los usuarios, los web hooks son una forma de obtener eventos y datos en tiempo real desde sus aplicaciones web. A partir de esto pueden usar esos datos como deseen, permitiéndoles extender e integrar, y empezar a obtener una verdadera visión de la web programable.

¿Cómo funcionan?

Dejando que el usuario especifique una URL para varios eventos, la aplicación hará un POST con los datos a esas URLs cuando esos eventos se produzcan. Con la disponibilidad económica del alojamiento con PHP y con almacenamiento de aplicaciones o scripts aún más simple como el de AppJet o Scriptlets, gestionar los datos del POST se convierte en trivial. Cómo usarlo depende de ti y de lo que quieras conseguir. Entre otras cosas puedes:

crear notificaciones para ti o para cualquiera via email, IRC, Jabber, ...
poner los datos en otra aplicación (sincronización de datos en tiempo real)
procesar los datos y reenviarlos usando la API de la aplicación
validar los datos y potencialmente prevenir su uso por la aplicación

¿Por qué me debe importar?

Tan integrada como percibimos la web, la mayoría de aplicaciones operan en silos. Con la aparición de las APIs hemos visto mashups (combinaciones) y algun grado de integración entre aplicaciones. En cualquier caso, no hemos visto la visión de una web programable: una web donde tú como usuario puedes encauzar los datos entre aplicaciones de forma parecida a como se hace en la línea de comandos Unix. Algunos dicen que la respuesta es RSS. Están equivocados. El corazón está en el sitio correcto pero la implementación es errónea. RSS es útil, pero no va a traernos la verdadera web programable.

Necesitamos una forma simple de extraer datos en tiempo real para dejar que el usuario haga lo que quiera con ellos. Eso significa que nada de consultas repetitivas, nada de restricciones en el contenido, y nada de parsear el XML. Eso significa no usar RSS. Usar HTTP es más simple y más fácil de usar. PHP es un entorno de programación accesible y muy popular, por lo que es probable que se utilice a menudo para programar hooklets... obtener los datos de una petición POST en PHP es tan sencillo como $_POST['algo']. Y hacer la petición al script del usuario es tan simple como realizar una petición HTTP tradicional, algo que los entornos de programación tradicionales ya permiten. De hecho, los web hooks son más fáciles de implementar que una API.

Ejemplos de implementaciones pueden encontrarse en Sitios como shopify, SurveyGizmo, ZenDesk, GitHub, o Google Code.

Para saber más

Un plan de estudios para la web

2009-07-17T12:46:00.004+02:00

He traducido este interesante artículo de Tim Bray ( Web Curriculum ) sobre un plan de estudios basado enteramente en tecnologías web.

Propongo que el World Wide Web sirva también como esquema para estructurar gran parte del currículo académico de informática. Un estudio de la teoría y la práctica de las tecnologías web alcanzaría muchas áreas clave de nuestra disciplina. Es más, hay una forma natural de estructurar ese conocimiento para crear un curso de estudios que cubra varios semestres.

(Un efecto colateral de tal propuesta es que los graduados entrarían en la población activa con una exposición significativa al conjunto de tecnologías que probablemente sería muy valiosa para sus carreras profesionales. Pero ese no es el argumento que estoy defendiendo aquí).

En la siguiente distribución, la numeración de los cursos implica una primera estimación de los niveles y prerequisitos. Ya que nunca he diseñado un currículo y mis propios estudios universitarios han quedado ya décadas atrás, es bastante posible que mis sugerencias respecto al número de cursos y los niveles por semestre necesiten mejorar.

Web 101: Introducción a la arquitectura. Idea-núcleo: Enseñar lo que pasa cuando haces click en un enlace y una página con multimedia y personalizaciones es generada para el usuario.

Cobertura: Qué es un navegador y un servidor. Qué son HTML, CSS, HTTP y URIs. Qué son servidores CGI y de aplicacion. Un vistazo inicial a la arquitectura subyacente.
Ejercicios de ejemplo: Desplegar un servidor web. Escribir páginas simples HTML/CSS con un editor de textos. Escribir scripts CGI en un lenguaje de alto nivel para producir páginas personalizadas.

Web 210/310/410: Estructuras de datos y algoritmos. Idea-núcleo: El centro clásico del currículo de informática.

Cobertura: Todas las cosas habituales. La dimension web viene del uso de la implementación del modelo de objetos de documento (DOM) como ayuda para la docencia.
Ejercicios de ejemplo: Construir incrementalmente una implementación del DOM, probablemente en un lenguaje de bajo nivel como C o Java. Una amplia variedad de estructuras de datos y algoritmos importantes puede ser bien usada en dicha implementación.

Web 220: Principios de redes. Idea-núcleo: Visión clásica de lo básico de las redes.

Cobertura: Este es un curso directo de redes de ordenadores, haciendo un recorrido convencional de la pila.
Ejercicios de ejemplo: La implementación de un pequeño servidor web ligero que acepte conexiones y sirva peticiones de archivos desde su sistema de archivos.

Web 230: Interfícies de usuario. Idea-núcleo: Inspección de temas de UI, pero suponiendo al navegador como plataforma de entrega, para poner el foco en el contenido y no en la tecnología.

Cobertura: Principios de usabilidad, diseño de la experiencia de usuario, breve introducción a la tipografía y a problemas de diseño, técnicas de evaluación. En el lado de la implementación, MVC (modelo-vista-controlador).
Ejercicios de ejemplo: Construir (en grupos) una interfície web de usuario para un sistema que mantenga las puntuaciones de algún deporte, evaluar su usabilidad y mejorarla.

Web 320: Protocolos de aplicación. Idea-núcleo: las aplicaciones distribuidas están basadas en varios sabores del patrón de intercambio de mensajes. Este sería un recorrido de las opciones.

Cobertura: Protocolos de flujo (streaming), protocolos orientados a sesión, protocolos de intercambio de mensajes al estilo HTTP.
Ejercicios de ejemplo: implementar porciones seleccionadas de WebDAV, XMPP y AtomPub.

Web 340/440: Persistencia. Idea-núcleo: Estudiar los problemas que rodean el almacenamiento persistente de datos.

Cobertura: Sistemas de archivos. Almacenamiento orientado al registro y al byte. Bases de datos relacionales. Bases de datos documentales y tablas de hash distribuidas.
Ejercicios de ejemplo: Construir algunas de las piezas de una aplicación como Twitter o Facebook, implementando almacenamiento eficiente y recuperación de diferentes tipos de recursos de información.

Web 350: Parsing - Análisis sintáctico. Idea-núcleo: estudiar métodos para extraer estructuras de entradas de texto.

Cobertura: Lo usual, incluyendo gramáticas, autómatas, y otras estrategias de parseo. Representación textual, especialmente Unicode.
Ejercicios de ejemplo: Construir parseadores para cabeceras HTTP, para JSON, para XML y para ECMAScript(JavaScript) por ese orden.

Web 351: Diseño de formatos de datos. Idea-núcleo: Estudiar las técnicas y compromisos que aparecen en el diseño de formatos de datos.

Cobertura: formatos de datos multimedia (JPG, PNG, vídeo), formatos de datos binarios (ASN.1, buffers de protocolo), formatos de datos textuales (JSON, XML). Compresión.
Ejercicios de ejemplo: implementar un lector de PNG, diseñar (en grupo) un lenguaje XML no trivial.

Web 360: Seguridad. Idea-núcleo: estudiar técnicas para implementar programas de ordenador suponiendo la presencia de un gran número de usuarios maliciosos con conocimientos técnicos.

Cobertura: introducción a las firmas digitales y tecnologías de encriptación. Análisis de amenazas. Ingeniería social. Virus, gusanos, botnets, y otros villanos.
Ejercicios de ejemplo: implementar un ataque de fuerza bruta sobre una tecnología de encriptación obsoleta. Escribir una recomendación sobre cómo algunos exploits criminales con éxito y bien conocidos podrían haber sido evitados.

Web 470: Temas de grandes sistemas distribuidos. Idea-núcleo: estudiar los problemas que aparecen en sistemas demasiado grandes para un solo ordenador.

Cobertura: REST, nombrado de objetos (DNS, URIs y otros esquemas de nombrado). Caché. Particionado de cargas de trabajo. Rastreo (crawling) de webs. Programación funcional. Gestión de errores.
Ejercicios de ejemplo: Implementar algo que use DNS. Aprender ideas detrás de Erlang y Map/Reduce. Escribir un rastreador (crawler) de web de pequeña escala.

Web 480: Sistemas concurrentes. Idea núcleo: estudiar las opciones para hacer uso de modernas plataformas altamente concurrentes de ordenadores.

Cobertura: hilos, procesos, actores, paso de mensajes.
Ejercicios de ejemplo: Implementar la infraestructura de paso de mensajes en un lenguaje de "sabor funcional" (Scala, Erlang) y en uno convencional procedimental (Java, Ruby).

¿Qué falta? El currículo web no cubre toda la informática. Aquí hay una lista (sin duda no exhaustiva) sin ningún orden en particular, de temas importantes donde un enfoque académico centrado en web obviamente no sería de ayuda:

Gráficos de ordenador.
Orientación a objetos.
Software en tiempo real.
Aritmética y representación numérica.
Inteligencia artifical.
Arquitectura de sistemas de ordenadores.
Análisis de algoritmos.

Google Chrome Operative System (segundo OS de Google)

2009-07-08T09:44:00.001+02:00

Empieza a ponerse divertido. Muchos vimos como Android, un sistema operativo abierto dirigido a dispositivos móviles empezaba a ser utilizado por algunos fabricantes de netbooks como alternativa a Windows ante la probabilidad de que se convierta en un estándar para Linux. Google nunca se ha manifestado al respecto, pero es un uso válido dada su licencia abierta.

Pero hoy, Google ha anunciado el nuevo Chrome OS. Un sistema operativo basado exclusivamente en su propio navegador Chrome.

Recordemos que cuando Apple optó por WebKit como motor para su Safari, mucha gente se extraño del movimiento. Aunque ya entonces resultaba apreciablemente más rápido que cualquier otro disponible. Después Google hizo lo mismo con Chrome, mejorado con su motor de JavaScript V8. Una plataforma extremadamente potente que tiene entre sus cualidades el haber empezado de cero y haber repensado muchas de las cosas que damos por sentadas sobre cómo debe ser un navegador.

Con esa misma filosofía, repensar cómo debe ser un sistema operativo, Google anuncia ahora que a mediados de 2010 publicará su projecto como fuente abierta: un sistema operativo ligero dirigido a aquellos que ya pasan cada vez más tiempo en el navegador, cuyo objetivo serán precisamente los netbooks (aunque también podrá ser usado por equipos convencionales) y que hará hincapié en la velocidad, la simplicidad y la seguridad.

Google indica que han estado basándose en las quejas tradicionales de los usuarios: quieren tener acceso al correo electrónico instantáneamente, sin esperar a que arranque el ordenador y pongan en marcha el navegador; quieren que sus equipos funcionen siempre tan rápido como cuando lo compraron (touché Microsoft); quieren que sus datos estén siempre ahí sin preocuparse de perder el ordenador o de tener que hacer copias de seguridad; y lo más importante: no quieren tener que pasar horas configurando sus equipos para que detecten cada elemento hardware (los odiados drivers) o actualizando el software.

La arquitectura es simple: Chrome corriendo sobre un sistema de ventanas montado sobre un núcleo mínimo Linux. Recordemos que Chrome ya incluye Gears (geolocalización, base de datos local, ...) Por tanto, los desarrolladores sólo deben continuar haciendo lo que ya hacen: usar las tecnologías web disponibles en este momento. Definitivamente, JavaScript se posiciona, pese a los desprecios de muchas comunidades de programadores, como una seria opción de cara al futuro.

Sólo una apreciación: Con este movimiento, Google dispondrá de dos sistemas operativos abiertos basados en Linux y con Chrome sobre ellos. Los conflictos posiblemente acabarán llegando.

Via Ajaxian.

El señor del HTML 5

2009-07-01T12:21:00.001+02:00

En CSS Squirrel, Kyle Weems explica el significado de su última viñeta. Como comentaba en un post anterior, Ian Hickson (o Hixie) es la persona que está coordinando el proyecto de redacción del nuevo estándar HTML 5. Sin embargo, Hickson trabaja para Google, lo que evidencia un posible conflicto de intereses.

Muchos de los participantes en la lista de correo acusan a Hickson de seguir una política que puede resumirse con las palabras: Negar, Retrasar, Desechar por llegar tarde.

Aunque un estándar tan importante como el que regirá el comportamiento de todos los navegadores (la cursiva es por Internet Explorer) durante los próximos años debería estar gestionado por un comité, el poder de decisión se centra en una única persona que se ha erigido como editor, y cuyas decisiones vienen muchas veces respaldadas por datos que, pese a proceder de Google, no son públicos ni se tiene la intención de que lo sean.

Estamos hablando de un esfuerzo de repercusiones casi inimaginables: miles de millones de páginas web escritas con este estándar, accesibilidad para usuarios con discapacidades, censura en países sin democracia, compartición de documentos multimedia sin la dependencia de plugins cerrados (flash)...

Estas críticas nacen de lo absurdo que resulta que una única persona sustituya a un comité de expertos, sino que además, y sin resultar una crítica a su capacidad que parece más que sobrada, el proceso -en el que muchas propuestas interesantes son rechazadas sin más o se hace mucho más caso a esos datos "secretos" que a la opinión de los expertos en cada área- dista mucho de ser transparente.

En este contexto no resulta extraño que se empiecen a alzar voces que pongan en duda la capacidad de Hickson para generar un HTML5 que cumpla con las expectativas de todos y no sólo las de Google, más cuando las críticas por el trato con los participantes (sean individuos, expertos o grupos de trabajo del W3C) no dejan de aumentar.

En esta entrevista a Hickson, sus palabras llaman poderosamente la atención:

Si respondo a comentarios sobre algo que acabo de publicar, me encuentro a veces que tengo un añadido para esa sección, por lo que si alguien sugiere un cambio total, no suele gustarme mucho esa idea. Pero si ha transcurrido un tiempo, encuentro que mi añadido ya no tiene tanta vigencia, y estoy ansioso por cambiar mi vieja estúpida idea por esa otra mejor.

Así que tengo que juzgar sobre lo que vale la pena añadir y lo que no, y eso es duro

Programación con singletons y árbitros de eventos

2009-06-25T17:00:00.002+02:00

He traducido el más que interesante artículo de Aaron Newton, Singletons and Event Arbiters:

¿Cuál es la mejor forma de definir código, asignarlo a una variable global y conseguir que se ejecute todo a la vez?

Usamos MooTools en el servidor en mi código ASP por medio de JScript y necesitamos objetos singleton globales como el de inicio de sesión. Puesto que no hay una forma estándar clara de hacerlo, lo he intentado y he generado algo como esto:
var LoggerObject = function() {
  // código de inicio de sesión
} 
var Logger = new LoggerObject() 
Está bien, pero parece que me estoy dejando algo. ¿Cómo lo hacen los profesionales? ¿Cuáles son las ventajas y desventajas de otros métodos?

Para los que no estén familiarizados con el concepto, un singleton (traducido literalmente sería "hijo único") es una clase diseñada para tener sólo una instancia (o un número limitado de ellas). En JavaScript, cualquier objeto puede heredar de cualquier otro objeto y no se puede prevenir que esto pase, por lo que en el sentido más estricto de la expresión, no es posible tener un singleton en JavaScript.

MooTools ofrece una función llamada "Class" que nos ayuda a gestionar la herencia entre objetos. Crear un objeto que es una instancia de una clase se consigue con el operador new:

var myWidget = new Widget()

Si lo que se desea es crear una clase e inmediatamente convertirla en una instancia, es posible hacer los siguiente:

var myInstance = new new Class({...})

El doble new invoca una función devuelta por la clase y que devuelve un objeto (una instancia de esa clase). Raramente se puede encontrar una razón para hacer esto así. De hecho, la única razón que se me ocurre es si se quiere que esa clase extienda a otra:

var myInstance = new new Class({
    Extends: SomeOtherClass,
    // nuevas propiedades aquí
});

El problema con este esquema es que no consigue mucho. JavaScript trata sobre todo con objetos, y hay mejores formas de hacer esta tarea.

Yo uso objetos (como singletons) continuamente para mi código de aplicación (obviamente casi nunca para plugins, que se supone que deben extenderse e instanciarse). Uso objetos "site" para apuntar métodos para gestionar el estado (como por ejemplo si el usuario ha iniciado sesión, su nombre de usuario, etc). Simplemento hago un objeto JavaScript básico, así:

var mySite = {
    login: function(username){ this.username = username; },
    showWelcome: function(){
        $("welcome").set("html", "Welcome " + this.username);
    }
};

No hay nada especial aquí - JavaScript funciona así. Es importante fijarse que las clases en MooTools existen para darnos funcionalidad y dejarnos derivarla a través de la herencia. Si creo una clase llamada Widget y luego quiero crear una versión llamada Widget.Ajax, puedo extender Widget y añadir sólo las partes ajax. Con los singletons el tema está en que no vas a crear más que uno.

En cualquier caso, hay algunas otras cosas que la Class de MooTools nos ofrece, como mixins (clase que ofrece cierta funcionalidad para ser heredada por una subclase, pero no está ideada para ser autónoma). Ejemplos de esto serían Event y Option que ofrecen a las instancias métodos como setOptions o addEvent. En estos casos aún puedes usar la declaración de objeto de arriba y extenderlo:

var mySite = {
    login: function(username){
        this.username = username;
        this.fireEvent("login");
    },
    showWelcome: function(){
        $("welcome").set("html", "Welcome " + this.username);
    }
};
$extend(mySite, new Events());

Aunque generalmente yo hago justo de la otra forma porque creo que es un poco más limpio (aunque se consigue el mismo efecto):

var mySite = new Events();
$extend(mySite, {
    login: function(username){
        this.username = username;
        this.fireEvent("login");
    },
    showWelcome: function(){
        $("welcome").set("html", "Welcome " + this.username);
    }
});

Con esta forma se evita la necesidad del tosco patrón new new Class y resulta más legible en mi opinión.

Árbitros de eventos

Lo que me lleva a una práctica común que suelo usar cuando construyo aplicaciones. Cuando construyo un sitio o aplicación, intento hacer las cosas lo más modulares posible. Lo hago de forma que primero mi sitio funcione sin JavaScript, y entonces empiezo a añadir los elementos de la interfície con ajax y animaciones y tablas ordenables y todo esa fiesta. También hago que el JavaScript mismo sea modular. Todo lo que pueda ser una clase, hago que sea una clase. Lo que queda es el código que instancia esas clases.

Pero ¿qué pasa si el código que instancia un widget necesita información de otro widget? Por ejemplo, ¿qué hacer si nuestro widget welcome (bienvenida) necesita saber el estado del widget de inicio de sesión? Bueno, si nuestro widget de inicio de sesión almacena su estado en el objeto mySite, entonces el widget de welcome puede inspeccionarlo, ¿no? Eso está bien; si la página carga y mySite.username no está inicializado (undefined) entonces el widget de welcome sabe que el usuario no ha iniciado sesión. Todo correcto.

Pero ¿qué pasa cuando el estado cambia? ¿Qué pasa cuando el usuario inicia sesión? Ahora necesitamos un evento - onLogin o similar, pero eso significa que Welcome necesita apuntarse al widget de inicio de sesión y entonces hemos perdido algo de modularidad al introducir una dependencia. Welcome no puede funcionar sin el inicio de sesión. En este caso, no parece que se trate de una mala dependencia - después de todo, un mensaje de bienvenida sin una funcionalidad de inicio de sesión no tiene mucho sentido - pero podría haber docenas de otros widgets que necesiten hacer cosas cuando el usuario inicia sesión y podríamos queere que esos widgets funcionen incluso si el usuario no ha iniciado la sesión. Es más, podríamos querer cargar el widget de inicio de sesión bajo demanda - cuando el usuario intente iniciar sesión por ejemplo. No es posible hacer eso si todos nuestros widgets necesitan apuntar eventos al widget de inicio de sesión.

Esta es la razón por la que hago que mySite sea una instancia de Events. mySite realmente no tiene eventos nativos en sí mismo. En su lugar, otras clases le apuntan eventos y disparan eventos por ella. Así, en nuestro puzzle de arriba sobre nuestro widget de inicio de sesión, en lugar de que todos los widgets se apunten a un evento onLogin, pueden apuntarse a mySite, y entonces nuestro widget de inicio de sesión dispara ese evento pero no sobre sí mismo sino sobre mySite:

var mySite = new Events();
var Login = new Class({
    //...login logic and stuff
    loginSuccess: function(username){
        mySite.username = username;
        mySite.fireEvent("login");
    }
});
var Welcome = new Class({
    initialize: function(){
        this.showMessage();
        mySite.addEvent("login", this.showMessage.bind(this));
    },
    showMessage: function(){
        $("welcome").set("html", mySite.username ? "Welcome " + mySite.username : "Please log in");
    }
});

Ahora nuestras clases ya no dependen entre ellas. Todas dependen ahora de mySite pero eso ya pasaba antes. Ahora pueden venir y marcharse cuando quieran sin preocuparse por las demás. Este incremento de la modularidad se agradece cuando el sitio crece en complejidad. Algunas páginas podrían tener algunos widgets y algunos podrían tener otros. Puede apuntar la lógica al objeto mySite sin tener que lidiar realmente con esas dependencias.

La desfachatez de la E azul

2009-06-20T00:24:00.006+02:00

Está mal abandonar a los usuarios de Internet Explorer durante cinco años (Agosto 2001-Octubre 2006), lo que podríamos equiparar a que un fabricante de automóviles no diseñe un nuevo vehículo durante 30 años. Y está mal despertar del letargo sólo porque la competencia ha estado haciendo los deberes hasta el punto de conseguir arrancar un pedazo del pastel pese a la integración de Windows con el sistema operativo y su ya famoso icono azul titulado "Internet" sin más.

Las versiones 7 y 8 se han sucedido más rápidamente, pero el camino que ahora debe recorrer Microsoft para ponerse al día con los estándares es, todavía, muy largo. Con una tendencia muy marcada a inventar por su cuenta, su último navegador queda muy atrás en cuanto a velocidad o respeto a esos estándares, a los cuales, por cierto tiende a menospreciar tal y como indica claramente Ian Hickson (el responsable de la especificación HTML5) en esta entrevista:

Personalmente me gustaría que Microsoft se implicase más con HTML 5. Han enviado muy pocas respuestas a lo largo de los años, muchísimas menos que el resto de fabricantes. Incluso cuando se les ha solicitado su opinión sobre características que estan implementando, raramente recibo una respuesta. Es muy triste. Si les envío un e-mail con una pregunta sobre qué puedo hacer para ayudarles, normalmente no recibo respuesta; como mucho recibo una promesa de que me contestarán más adelante, pero eso es todo.

En este contexto en el que siguen manteniendo una más que importante cuota de mercado (recordemos que para muchos usuarios, "Internet" sigue siendo ese icono con una "E" azul) al tiempo que mantienen un desprecio evidente ante los estándares acordados por todos, resulta especialmente provocativo lo que ha sucedido esta semana.

Mentiras para vender: Firefox viejo, Safari aburrido y Chrome oxidado

Hace relativamente poco que la versión 8 de su navegador está disponible para descargar, y Microsoft no deja de ser una casa de software con un departamento tradicional de márketing. Está demostrado que la inmensa mayoría de internautas no sabe distinguir el navegador de un motor de búsqueda como Google. Sin embargo, su nueva campaña está basada en insultos a la competencia (Genbeta, Ajaxian, WebReflection) y falsedades para encubrir las enormes carencias del navegador de Microsoft.

Probablemente Microsoft se encuentra en la incómoda situación en la que no quiere invertir en un producto que no le genera beneficios y que además amenaza a Windows, pero tampoco desea que la competencia siga en esa vorágine de mejoras continuas en la que está sumida y que poco a poco están desplazando su producto gratuito. Con esos precedentes, quizá pueda entenderse la decisión de atacar a la competencia como un intento desesperado de conservar cuota de mercado con un navegador que no quiere evolucionar.

Por ello resulta enormemente ofensiva la página de promoción del nuevo Internet Explorer y la comparativa con la competencia, plagadas de incorrecciones, medias verdades y, ¿por qué no decirlo?, auténticas mentiras para intentar demostrar lo indemostrable: que IE no sólo está a la altura del resto (recordemos que llevan 5 años de retraso) sino que además es mucho más mejor que ellos. Aunque para "demostrarlo" tachen de mitos...

la lentitud (más que demostrada con todas las comparativas de estos últimos meses)
la seguridad (todos hemos visto instalarse "software" automáticamente al visitar una página con IE)
la menor riqueza respecto a Firefox (ya quisieran tener una décima parte de las extensiones de éste)
y que su navegador no respeta los estándares, ante lo que tienen la enorme desfachatez de afirmar que "Internet Explorer 8 pasa más casos de prueba del W3C que cualquier otro navegador".

Lo peor de todo es la sensación de que, conscientes de que no van a alcanzar el nivel al que ahora mismo están Chrome, Safari, Opera o Firefox, optan por la opción más fácil: invertir en desprestigiar a la competencia, aunque con ello detengan el progreso de las tecnologías web durante unos cuantos años más. Quizá legalmente toque callar, pero moralmente merecen que su flamante E azul deje para siempre de estar unida a la palabra Internet. Lástima que sólo siga siendo un deseo...

Opera Unite, no tan buena idea

2009-06-17T00:50:00.003+02:00

Han habido otros intentos anteriores de introducir un servidor en el mismo navegador. ¿Para qué nos puede servir eso? Pues entre otras cosas para obtener una aplicación web que se ejecute en el mismo equipo, sin conexión... pero ¡espera! ¿No era eso lo que promete Gears y buena parte del estándar HTML5? Visto desde este punto de vista, Opera no ofrece más que Chrome que ya incluye Gears.

Por otra parte, Opera lleva innovando desde hace años y muchas de las características que hoy día traen los navegadores (pestañas, página personalizada de nueva pestaña, bloqueos de popups o sesiones) fueron inventados por ellos. Incluso en la versión anterior osaron integrar un cliente de BitTorrent. En este contexto, el de compartir, el nuevo Opera Unite puede ser un invento importante: compartir fácilmente información residente en nuestro propio equipo sin tener que preocuparse de proxies y otros problemas tradicionales (algo ya resuelto por no-ip.com). ¿Pero no hay otras tecnologías más apropiadas para ello como FTP o el propio BitTorrent? En cualquier caso tampoco es una idea nueva.

Instalado la beta de Opera 10 y activado el servicio a través del registro de una cuenta, obtenemos una página de inicio con la forma unite://equipo.usuario.operaunite.com/_root/content/ que resulta accesible desde cualquier punto de Internet cambiando el protocolo de unite:// a http://. Pero para evitar tener que pelearse con configuraciones de routers y demás, la información viaja a través de los servidores de Opera, aunque se esté sirviendo desde el mismo equipo desde el que se accede, lo que reduce sensiblemente la velocidad de respuesta. Luego hay otros puntos por resolver, como la seguridad y la disponibilidad, que evidentemente depende de que el equipo esté funcionando y con Opera corriendo en todo momento.

Los servicios que ofrece son:

Compartición de archivos: se selecciona una carpeta local con el contenido a compartir. Permite seleccionar quién tiene acceso y cómo (público, limitado con contraseña o sólo para el equipo local)
Nevera: para dejar notas al propietario del servidor (no deja de ser como el e-mail)
Reproductor de multimedia: para acceder a la librería de música y películas remotamente con las mismas posibilidades que la compartición de archivos
Compartición de fotos: ídem que el anterior pero con fotos
Un chat de grupo con control del propietario y alojado en el propio equipo
Servidor web: permite indicar una carpeta que contendrá proyectos web que pueden ser publicados para wur otros usuarios los visiten. Sin embargo, hay que tener en cuenta que los servicios ofrecidos son muy limitados (páginas estáticas)
La idea es que otros servicios sean añadidos en el futuro, por parte de Opera o de terceros mediante JavaScript ejecutado en el servidor en forma de Widgets

Personalmente no me gusta la idea tal y como Opera la ofrece. Sin duda es mucho más potente y con muchas más posibilidades que la tecnología de almacenamiento local y utilización del navegador sin conexión que ofrece HTML5/Gears. Igualmente hay que tener en cuenta que se trata de una beta. Pero quizá algunas de las decisiones técnicas tomadas se alejan un poco de los estándares que han estado proponiéndose en los últimos tiempos, desde el W3 Database API hasta la idea de empaquetar en un mismo archivo todo el código, evitando absurdamente una de las mayores ventajas del desarrollo web: usar un simple editor de texto para modificar el código, guardarlo y ver los cambios en el navegador.

Andrea Giammarchi coincide en su decepción de la implementación de la idea y de su utilidad.
Referencia de Simon Willison
Artículo en el blog de Opera Labs
API de desarrollo
introducción para el desarrollador
API JavaScript del servidor Unite

El proyecto Vice-versa

2009-06-04T11:29:00.001+02:00

He traducido la introducción del Proyecto Vice-versa presentado en este post de Andrea Giammarchi. Se trata de una librería que nace con la idea de aproximar las implementaciones de las características JavaScript disponibles desde cada navegador.

El proyecto Vice-versa

Cada navegador tiene alguna característica deseable: puede ser su rendimiento, puede ser algo que "aún no se ha estandarizado", puede ser una característica preparada para ECMAScript 5. El proyecto Vice-versa pretende traer lo bueno de cada navegador a un único archivo JavaScript ligero y que valga para todos los navegadores.

Filosofía

Array.forEach(document.all, function(node, i, all){
    // proyecto vice-versa
});

Como un Ninja JavaScript tengo que tratar diariamente con centenares de problemas diferentes a causa de "esta o aquella" implementación por parte de un navegador. La web está llena de librerías pero a menudo lo que necesitamos hacer requiere usar el navegador "tal cual" y estas librerías puede ayudar o simplemente pueden hacer más lentas las aplicaciones a causa de sobrecargas innecesarias sobre tareas simples o comunes. Estudiando el DOM, que es caótico, a menudo "viajo" entre los sitios de MDC y de MSDN para resolver un problema específico que puede causar muchos dolores de cabeza a causa de "alguna" implementación del estándar W3C que alguien ha olvidado realizar. Al mismo tiempo, teniendo en cuenta que el navegador más usado es el que tiene el motor de JavaScript más lento, siempre intento encontrar soluciones que puedan completar una tarea sin afectar al rendimiento. En la mayoría de los casos, he notado que, ya que otros navegadores son más rápidos y más potentes, tiene sentido traer funcionalidades no estándar a esos navegadores en lugar de implementar, cuando sea posible, una funcionalidad omitida en Internet Explorer. Como ejemplo básico, para convertir un documento XML en una cadena, nos gustaría usar una instancia de XMLSerializer, pero ¿qué problema hay con el atajo del atributo xml de Microsoft?

// al estilo de otros navegadores (estándar)
var xmls = new XMLSerializer;
var string = xmls.serializeToString(myXMLDocument);

// al estilo de Internet Explorer (no estándar)
var string = myXMLDocument.xml;

Es más, document.evaluate es una característica muy buena, pero la llamada más común a esta función es la siguiente:

var xpresult = document.evaluate(XPathSelector, myXMLDocument, null, 0 /* as ANY_TYPE */, null);

// En internet explorer hay una función ligeramente diferente: selectNodes
var xpresult = myXMLDocument.selectNodes(XPathSelector);

La diferencia principal es el número de caracteres necesarios para llamar al método estándar en lugar de el de IE, aunque el resultado es exactamente el mismo durante las iteraciones (donde IE usa nextNode, el resto usa iterateNext). De nuevo, si estamos en Internet Explorer podemos confiar en la propiedad más fea que hayamos visto nunca desde la primera implementación de JScript sonbre el DOM: document.all. Ahora, ¿por qué demonios nos encanta la "miniaturización" de YUICompressor más gzip pero preferimos una sintaxis sin sentido como document.getElementsByTagName("*") en lugar de document.all ?

La lista podría seguir con execScript para evaluar código en el ámbito global (relacionado con tiempo de ejecución y con Ajax) y con Object.defineProperty, pero al mismo tiempo tenemos carencias con Array.prototype desde hace una eternidad, algo relativamente aburrido ya que el prototipo del constructor global debe permanecer "intocable" por razones de compatibilidad ... Ya es hora de comprender que nadie hace un bucle for in sobre listas o colecciones, así que Array.prototype ha de ser estandarizado, no hay "puede ser" o "quizá", especialmente ahora que se ha implementado como estándar en ECMAScript 5. Como resumen, estos son conceptos dentro del proyecto vice-versa: especialmente si estos comportamientos pudieran enlentecer el rendimiento general de las aplicaciones, o si estos comportamientos no son estándares.

Características vice-versa provenientes de Internet Explorer

Object.defineProperty (IE 8 o superior)
document.all, como atajo a document.getElementsByTagName("*")
document.createElement con soporte html para cada navegador (a veces simplifica las cosas p.e. document.createElement('<em class="test"></em>'))
HTMLElement.attachEvent y detachEvent
objeto global window.event poblado via attachEvent con las propiedades cancelBubble y returnValue
HTMLElement.outerHTML con set y get (la forma más simple de leer un elemento del DOM como una cadena)
HTMLElement.innerText con set y get (la forma más rápida en IE de insertar un nodo de texto)
HTMLElement.outerText con set y get (la forma más rápida en IE de reemplazar un nodo genérico por uno de texto)
execScript para evaluar en un ámbito global cualquier tipo de cadena (sin soporte a un segundo argumento)
XPath selectNodes y nextNode via documentos XML
propiedad xml, sólo get, para recuperar una cadena de un XMLDocument/XMLNode
insertAdjacentElement, insertAdjacentHTML, y insertAdjacentText, la forma más rápida de poner algo antes de un nodo, como firstChild, como lastOne, o tras el mismo nodo

Características vice-versa principalmente para Internet Explorer

Array.slice, para trocear todo sobre una colección genérica (compatible con DOM)
Array.forEach, para recorrer una colección genérica via callback (compatible con DOM)
Array.prototype, actualizado a la última revisión de Mozilla/FireFox (sin la especificación completa, versión enfocada en rendimiento)
XMLHttpRequest, para el antiguo IE6 (desfasado, será eliminado tan pronto como se pueda, pero debemos esperar primero hasta el final de este navegador)
setInterval y setTimeout con argumentos extra como los demás

Características vice-versa de ECMAScript 5

Object.getPrototypeOf, para recuperar el prototipo heredado por un objeto genérico
Object.keys, compatible (incluyendo toString), para recuperar un Array de claves a partir de un objeto
Object.create, compatible (incluyendo toString), para crear una nueva instancia a partir de otro objeto
Array.isArray, para conocer si un objeto genérico es un Array
String.prototype.trim, una implementación rápida de recorte para cada cadena
Function.prototype.bind, un método para asegurar el ámbito this en una llamada a función

Características extra en vice-versa

document.query, librería esencial de selectores para obtenere resultados genéricos mediante consultas comunes de tipo dolar (función $)
Object.forIn, para recorrer una instancia genérica sin considerar al prototipo heredado y sin olvidar las propiedades predefinidas (toString, valueOf, etc)

Metas de vice-versa

Pronto llegarán más funcionalidades, esperando mantener por debajo de 10KB de tamaño total minificado y comprimido (actualmente está en 4KB). Esta es sólo una implementación parcial de mi idea original. Las librerías de terceras partes serán bienvenidas, y los colaboradores de otros equipos de librerías serán más que bienvenidos. La idea principal es crear un híbrido completo del escenario JavaScript haciendo que los rendimientos sean similares en cada navegador y ofreciendo una estructura de bajo nivel para construir librerías complejas, aplicaciones, ... respetando donde sea posible a Internet Explorer, y trayendo sus características dentro de otros navegadores rápidos y potentes. ¿Estoy loco?

Wave reinventa la comunicación en la red

2009-05-31T17:40:00.002+02:00

Hace unos meses me gustaba seguir a Jon Udell al respecto de posibles herramientas que permitiesen evolucionar el omnipresente correo electrónico martirizado por el spam. Proyectos como Zoë, Yammer o Groove han intentado ya mejorar ese gigante.

Google Wave es una nueva idea experimental y abierta que pretende rediseñar el futuro de la comunicación en tiempo real sobre la web. "Es lo que parecería el correo electrónico si se inventase hoy".

Wave es a partes iguales conversación y documento. Es posible comunicarse y trabajar juntos sobre texto con formato, fotos, vídeos, mapas y, prácticamente, cualquier cosa que pueda representarse sobre un navegador. Un documento wave puede compartirse. Puede responderse desde cualquier lugar en el que el mensaje esté publicado (por ejemplo un artículo en blogger, en el que los comentarios se introducen automáticamente en la conversación), editar su contenido o añadir nuevos participantes en cualquier momento. Y puede reproducirse su evolución para ver cómo ha ido evolucionando el documento a lo largo del tiempo, viendo quién ha dicho qué y cuando. Además permite la transmisión de información en tiempo real, de forma que puede verse cómo los demás teclean, agilizando las conversaciones y facilitando enormemente el trabajo sincronizado.

Wave ha sido diseñado como un estándar similar al e-mail, es abierto, y puede ser usado en cualquier servidor. Y puesto que el estándar define un protocolo, distintos servidores pueden entenderse entre ellos aunque no pertenezcan a Google.

Aunque aún no está disponible, en la presentación se muestra cómo Wave consigue mejorar enormemente el correo electrónico y la mensajería instantánea, los dos pilares básicos sobre los que se asienta. Y construye sobre ellos una plataforma de innovación totalmente abierta en la decenas de detalles e ideas han sido implementados para mejorar la experiencia de los usuarios cuando quieren comunicarse. Por ejemplo, contestar un mensaje es tan simple como escribirlo en el área prevista para ello (no hay que pulsar un botón y esperar que la aplicación cargue un formulario... simplemente "ya está ahí"); o la implementación de múltiples atajos basados en "arrastrar y soltar" convierten la experiencia en mucho más intuitiva. Aunque no deja de recordar a un cliente de correo electrónico tradicional pero optimizado, puede convertirse en un chat de forma transparente si los usuarios están conectados (de hecho los mensajes los ve el otro lado conforme se teclean, aunque esta opción puede desactivarse).

Cosas que pueden hacerse con wave:

reproducir la conversación paso a paso para que alguien incorporado pueda entender completamente el tema
mensajes privados dentro de la conversación que sólo ven los interesados
compartición rápida de archivos/fotos
aprovecha Gears si está instalado para permitir algo tan intuitivo como arrastrar y soltar archivos desde el escritorio
funcionalidades basadas en contactos/robot como "bloggy" para publicar la conversación, de forma que el mismo artículo del blog se convierte en parte de la conversación: cualquier comentario allí se incorpora automáticamente, convirtiendo la conversación en pública. O un traductor simultáneo.
edición y control de cambios al estilo wiki (resaltados como novedad)
posibilidad de ver la conversación como un documento, de forma que se pueda aprovechar para la creación de documentos en equipo
posibilidad de trabajar con equipos sobre subdocumentos del documento original, de forma que se trate de una parte del documento principal hasta su versión definitiva, que vuelve al original y así puede ser usado o modificado por otros equipos o subdocumentos
posibilidad de enlazar desde la actual conversaciones simplemente arrastrando y soltando
todo sincronizado en tiempo real, una nueva conversación puede aparecer en los resultados de una búsqueda después de haberla lanzado
ortografía basada en diccionarios pero también en contexto. Especialmente espectacular: "icland is an icland" se convierte en "Iceland is an island".
sistema de extensiones similar al del propio navegador (instalables)
extensiones como realizar votaciones o juegos de red de competición (ajedrez) o colaborativos (sudoku) donde los eventos son reconocidos por wave y por tanto se puede reproducir una partida como si fuese una conversación
conversaciones que muestran formularios de configuración con opciones que pueden rellenar más de un usuario a la vez. Es la respuesta a la pregunta de siempre: ¿Cómo creo una encuesta rápidamente?
integración de otros sistemas de comunicación (email, twitter) o con sistemas de depuración de errores (bugtrack) para equipos
posibilidad de traducción simultánea (al vuelo) de una conversación para usuarios que hablen en distintos idiomas

Otro "detalle" es que se exige un navegador moderno con soporte de HTML5. La consecuencia inmediata es que, aunque aún no está disponible, si los internautas en masa quieren disponer de esta herramienta, deberán decir adiós a Internet Explorer a menos que Microsoft, por fin, se tome en serio su trabajo.

Página oficial
Explicación en TechCrunch.com
Presentación en inglés (1 hora, 20 minutos). Versión reducida a 10 minutos.
API
Web oficial del protocolo abierto (open-source) de Wave.

2009-05-28T14:18:00.005+02:00

A partir de JS PlaceMaker que es un script que permite identificar lugares a partir de un texto y que devuelve objetos con su ubicación, he creado el siguiente ejemplo:

http://jsbin.com/abumi/

El código es sencillo:

function callback(e) {  
  if (e.match.length) e= e.match; else e=[e.match]; 
  var gmapsApi= "ABQIAAAAGoC4gjFriF0K4FcpSOhWDhTWx8njL9qYLnq46LoOVGM6mIGTuxR2yPgKzvzjHKLSfLHgjUC0vi45-Q"; 
  var imgs=''; 
  console.dir(e); 
  for (loc in e) { 
    center=e[loc].place.centroid.latitude+','+e[loc].place.centroid.longitude; 
    imgs+= '<img src="http://maps.google.com/staticmap?center='+center+'&markers='+center+'&zoom=13&size=350x250&key='+gmapsApi+'" style="float:left;"/>'; 
  } 
  document.getElementById('map').innerHTML=imgs; 
  window.called=false; 
} 
 
window.called=false; 
function changed() { 
  if (window.called) return; 
  setTimeout(function(){ 
    Placemaker.config.appID = "jPkyQyTV34Fi4qlev38PC_eXLDQYqVPkQ5N1aZDxVUSpw3MKOUWD9AHzcVkLFkM-"; 
    Placemaker.getPlaces(document.getElementById('text').value,callback,document.getElementById('locale').value); 
    window.called=true; 
    }, 
  1000); 
}

Puedes probar con el texto: "I'm Jack London and I live in Barcelona but I work at Amsterdam and my parents live in Oslo", (nótese que detecta que la palabra London no se está usando como ubicación) aunque hay un selector para indicar el lenguaje del texto introducido. La detección se produce al salir del campo de texto, aunque también se puede forzar con el botón. Las claves son para el dominio del contenedor de código jsbin.com

Compresión JSON con JSON.hpack

2009-05-26T19:58:00.004+02:00

JSON.hpack es un compresor de conjuntos de datos JSON. Es capaz de reducir hasta un 70% el número de bytes necesarios para representar una colección genérica y homogénea (entendiendo por homogénea la que suele ser producida por una consulta a una base de datos relacional en la que se repite una serie de filas con el mismo número de campos).

Así como un resultado con XML como el siguiente...

  <result>
    <item>
      <name>Andrea</name>
      <age>31</age>
      <gender>Male</gender>
      <skilled>true</skilled>
    </item>
    <item>
      <name>Eva</name>
      <age>27</age>
      <gender>Female</gender>
      <skilled>true</skilled>
    </item>
    <item>
      <name>Daniele</name>
      <age>26</age>
      <gender>Male</gender>
      <skilled>false</skilled>
    </item>
  </result>
  <!-- 286 caracteres (sin contar espacios) -->

... puede ser compactado con JSON a la cadena siguiente...

[
  {
    "name":"Andrea",
    "age":31,
    "gender":"Male",
    "skilled":true
  },
  {
    "name":"Eva",
    "age":27,
    "gender":"Female",
    "skilled":true
  },
  {
    "name":"Daniele",
    "age":26,
    "gender":"Male",
    "skilled":false
  }
]
// 177 caracteres (sin contar espacios)

... podemos ver fácilmente que JSON admite una compresión aún mayor, puesto que cada registro repite los nombres de los campos.

El nivel 0 de compresión con JSON.hpack propone reunir los nombres de los campos en un primer registro:

[["name","age","gender","skilled"],["Andrea",31,"Male",true],["Eva",27,"Female",true],["Daniele",26,"Male",false]]
// 115 caracteres

Aún así, se repiten valores (como true, false, male y female) que podrían ser sustituidos por índices para ahorrar aún más espacio (aunque en este ejemplo con 3 registros el resultado no es mejor que el anterior):

[["name",["Andrea","Eva","Daniele"],"age","gender",["Male","Female"],"skilled",[true,false]],[0,31,0,0],[1,27,1,0],[2,26,0,1]]
// 167 caracteres

Como se puede ver en este nivel 1 de compresión, en el primer registro se indican los nombres de los campos y los posibles valores que pueden adoptar siempre que no sean numéricos (el autor cree que no vale la pena realizar la conversión de unos números por otros (índices)). Por ejemplo, Male o True se sustituyen por 0 y Female o False por 1.

Esto aún puede optimizarse más con el nivel 2 de compresión, comparando si vale la pena enumerar los valores en la cabecera y sustituirlos en los datos por índices o si es mejor mantener los datos (en el siguiente caso, los nombres no se enumeran):

[["name","age","gender",["Male","Female"],"skilled",[true,false]],["Andrea",31,0,0],["Eva",27,1,0],["Daniele",26,0,1]]
// 119 caracteres

Esta comprobación se realiza a nivel de la colección entera. Es posible realizarla a nivel de cada campo, comparando la longitud de la enumeración más los índices que serán necesarios con los de indicar directamente los valores:

// Comparando "gender":
  ["Male","Female",0,1,0] < ["Male","Female","Male"] (23 caracteres es menos que 24)
// comparando "skilled" :
  [true,false,0,0,1]      > [true,true,false]        (18 caracteres es menos que 17)

Según esto, el resultado de aplicar el nivel 3 de compresión será:

[["name","age","gender",["Male","Female"],"skilled"],["Andrea",31,0,true],["Eva",27,1,true],["Daniele",26,0,false]]
// 116 caracteres

Y aún se puede extraer un último nivel 4 de compresión comparando todos los anteriores y seleccionando el que menos ocupe. Es posible hacer pruebas en la página de ejemplos.

Aunque parece que la compresión es importante, hay que tener en cuenta que si el contenido se está comprimiendo con gzip desde el servidor, la reducción real en información enviada será mucho menor. Para conjuntos grandes de datos, sí que puede haber una diferencia importante, aunque se pague el precio del procesamiento necesario para comprimir y descomprimir los datos.
Existen librerías para JavaScript, PHP y C#, aunque según el wiki del proyecto, es posible que se amplíe a Python, Ruby o plugin PHP mediante C.

En concreto, la versión JavaScript cuenta con los siguientes métodos:

hpack( Array[, Int[0-4]] ):HArray, convierte una colección homogénea a otra comprimida con hpack
hunpack( HArray ):Array, convierte una colección hpack a su original (no es necesario indicar qué compresión se usó)
hbest( Array ):Int[0-4], devuelve el nivel de compresión ideal para la colección homogénea especificada