Mostrando entradas con la etiqueta javascript. Mostrar todas las entradas
Mostrando entradas con la etiqueta javascript. Mostrar todas las entradas

miércoles, 22 de junio de 2011

MediaElement.js: el mismo player de audio/video para todos

MediaElement

Uno de los objetivos de HTML5 es unificar el manejo de media para todos los navegadores y plataformas, pero hasta ahora, por cuestiones de indefinición de estándares, por temas de apertura, licenciamiento o comodidad tecnológica entre los jugadores del mercado, esto no ha sido sencillo.

Para solucionar este problema, el prolífico John Dyer escribió (y liberó bajo licencia GPL v2/MIT) MediaElement.js

Se trata de un reproductor de audio/video en JavaScript, como su nombre indica, que soporta una multitud de navegadores (los que soportan HTML5 y los que no) y unifica mucho más el soporte de codecs para diferentes formatos de video.

Para simplificar el uso manteniendo el soporte entre plataformas, el reproductor utiliza el mismo API en todas, basado en los tags <audio> y <video> de HTML5, implementándolos en los navegadores que no los reconocen, delegando el soporte a reproductores en Flash o Silverlight, pero que emulan exactamente el reproductor nativo.

De esta manera, el uso de estos elementos es idéntico en todos los navegadores para el productor del contenido, y la adecuación se produce en el cliente, que probablemente ya tenga los complementos necesarios descargados. La ventaja principal es que la manera de interactuar con los activos de audio o video es siempre igual.

El siguiente cuadro muestra el soporte para todos los navegadores, y la manera en que se soportan dependiendo de la plataforma:

MediaElement por plataforma

Como siempre, el soporte se limita más en los dispositivos móviles, sobre todo en iOS, pero nótese que los navegadores de escritorio están cubiertos por completo.

La instalación de MediaElement es muy sencilla y está bien descripta en el sitio. Del lado del cliente, básicamente se reduce a incluir esta biblioteca y hoja de estilos:

<script src="jquery.js" />
<script src="mediaelement-and-player.min.js" />
<link rel="stylesheet" href="mediaelementplayer.css" />

Y para incluir el reproductor, utilizando el caso más extremo para dar soporte completo a todo, este es el marcado HTML (obviamente sin necesidad de incluir todos los comentarios):

<video width="320" height="240" poster="poster.jpg" controls="controls" preload="none">
    <!-- MP4 en Safari, IE9, iPhone, iPad, Android, y Windows Phone 7 -->
    <source type="video/mp4" src="myvideo.mp4" />
    <!-- WebM/VP8 en Firefox4, Opera, y Chrome -->
    <source type="video/webm" src="myvideo.webm" />
    <!-- Ogg/Vorbis en versiones viejas de Firefox y Opera -->
    <source type="video/ogg" src="myvideo.ogv" />
    <!-- Opcional: Agregar subtitulos para diferentes lenguajes -->
    <track kind="subtitles" src="subtitles.srt" srclang="en" />
    <!-- Opcional: Agregar capítulos -->
    <track kind="chapters" src="chapters.srt" srclang="en" /> 
    <!-- Ante-último recurso: sólo para navegadores sin HTML5 ni JavaScript -->
    <object width="320" height="240" type="application/x-shockwave-flash" data="flashmediaelement.swf">
        <param name="movie" value="flashmediaelement.swf" />
        <param name="flashvars" value="controls=true&poster=myvideo.jpg&file=myvideo.mp4" />
        <!-- El peor de los casos: dejo una imagen -->
        <img src="myvideo.jpg" width="320" height="240" title="No tiene manera de reproducir video" />
    </object>
</video>

El reproductor en si soporta diferentes estilos, puede controlarse programáticamente desde JavaScript, tiene montones de opciones como tamaño para el marco de video o audio, volumen, reproducción en bucle, subtítulos (incluyendo traducción automática via Google translate), y más.

Creo que para cualquiera trabajando seriamente en media en este momento este reproductor es una de las soluciones más completas disponibles.

lunes, 6 de junio de 2011

Video: DHH en la RailsConf 2011

Este post contiene básicamente el video de la sesión de David Heinemeier Hansson (DHH) en la RailsConf 2011 a mediados del mes pasado en Baltimore, Maryland, EEUU.

El video, por supuesto, está en inglés, pero me parece interesante compartirlo porque en la sesión DHH comparte sus ideas acerca de los objetivos en los cambios en Rails 3.1, incluyendo la idea de más carpetas y archivos vacíos (para ayudar en la organización), y los motivos de la cuestionada inclusión de CoffeeScript y SCSS (comentada previamente en otro post).

Específicamente menciona que Rails seguirá siendo una plataforma con opiniones fuertes, donde las configuraciones por omisión serán las que el equipo considera las más relevantes y útiles en el momento, aunque siempre podrán cambiarse (por ejemplo, basta comentar las dos líneas que incluyen saas y coffee-script en el gemfile).

Sobre el final, menciona pjax, una biblioteca que maneja el contenido completo de una página estática como si fuese ajax pero manteniendo las url apropiadas, dejando que el botón BACK del navegador funcione perfectamente. Esa puede ser una de las próximas inclusiones en Rails.

miércoles, 1 de junio de 2011

Raros lenguajes nuevos: ColdRuby

ColdRuby

En este caso no se trata realmente de un lenguaje nuevo, si no de una implementación interesante de Ruby.

ColdRuby es un motor compuesto por tres partes:

  • Un intérprete de Ruby escrito en JavaScript
  • Un traductor de bytecode YARV (basado en Ruby 1.9)
  • Una máquina virtual basada en V8 (el motor de código abierto de Google) conectando las partes

Sin embargo, estas tres partes pueden ser utilizadas en forma independiente o reemplazadas por otras. Así, ColdRuby puede compilar código Ruby a JavaScript para que lo ejecute un browser, o ser ejecutado directamente en Node.js (que utiliza V8 por debajo).

Para los que todavía suponen que hacer algo así en JavaScript es una locura porque puede ser muy lento, los invito a mirar este emulador de completo de una PC escrito en JavaScript por Fabrice Bellard (autor de QEMU entre otras cosas), que bootea un Linux (funciona bien en versiones actualizadas de FireFox y Chrome, al menos).

ColdRuby tiene unos cuantos detalles "raros" que surgen de las diferencias de diseño entre ambos lenguajes, como el modelo de herencia prototípica de JavaScript contra el usual, basado en clases, de Ruby. También hay detalles como la manera en que se mapean algunos tipos de datos, pero en todos esos sentidos se ha tratado de mantener la alternativa más pragmática para usos generales.

La promesa es poder ejecutar Ruby dentro del browser (algo que hasta ahora era posible solamente con la combinación de IronRuby y Silverlight), e interactuar entre ambos lenguajes.

El proyecto es temprano y todavia un tanto experimental, pero interesante.

miércoles, 4 de mayo de 2011

CoffeeScript: el libro (más un video)

El libro de CoffeeScriptYa hablé antes en este blog sobre CoffeeScript y las ediciones de Pragmatic Programmers, y hoy quería combinar ambas cosas comentando el nuevo libro de Trevor Burnham que ya está disponible en Beta, y comencé a leer ayer.

Por supuesto, el libro está en inglés, y no está terminado, pero me parece otro indicio, junto con la decisión de incluir CoffeeScript por omisión en Rails, del auge que está tomando este dialecto simplificado para JavaScript.

Pero vamos al libro. En el prologo, Jeremy Ashkenas, el creador de CoffeeScript, explica entre otras cosas (la traducción es mía):

..."Afortunadamente para nosotros, el JavaScrit de hoy disfruta de un merecido renacimiento. Gracias al incansable esfuerzo de los implementadores de los navegadores, es actualmente el más rápido de los lenguajes dinámicos populares; está presente en todos lados, desde servidores hasta Photoshop; y es el único lenguaje que se puede usar para programar desde todos los ángulos de la web.

CoffeeScript es un pequeño lenguaje que apunta a brindar fácil acceso a las partes buenas de JavaScript: las funciones de primer clase, los objetos como hash, incluso la poco comprendida cadena de herencia por prototipos. Si hacemos bien nuestro trabajo, ustedes terminarán escribiendo un tercio del código para escribir el mismo JavaScript que hubiesen escrito de otra forma. CoffeeScript pone un alto valor a la legibilidad del código y a eliminar mucho del ruido sintáctico.Al mismo tiempo, hay una correspondencia prácticamente uno-a-uno entre CoffeeScript y JavaScript, lo que significa que no hay degradación de rendimiento -de hecho, muchas biblitoecas JavaScript terminan corriendo más rápido después de ser migradas a CoffeeScript debido a algunas optimizaciones que el compilador puede realizar."

El prólogo termina elogiando al autor del libro por sus colaboración con CoffeeScript desde los primeros días, lo que asegura que el tema está tratado desde un profundo conocedor.

El juego del 5x5

El libro recorre el lenguaje y compilador en detalle, incluyendo instalación y ejecución, integración en otros ambientes e interoperabilidad con bibliotecas populares como jQuery. Y a medida que recorre los diversos capítulos, utiliza como ejemplo la construcción de un juego sencillo para dos jugadores, llamado 5x5, del que puede verse la interfaz a la derecha.

Comparto el índice general para que se den una idea del alcance:

  • Prólogo y Agradecimientos
  • Prefacio (historia, audiencia y organización del libro, proyecto de ejemplo y comunidad)
  • Comenzando (instalación, editores, ejecución y depuración)
  • Funciones, alcance y contexto
  • Colecciones e Iteraciones
  • Módulos y clases
  • Interactividad web con jQuery
  • Aplicaciones del lado del servidor con Node.js
  • Respuestas a los ejercicios
  • Maneras de ejecutar CoffeeScript (consolas web, dentro de una aplicación web, en Rails, via middleware, en Node.js, usando Middleman, en scripts del sistema operativo)
  • Cartillas
  • Bibliografía

 

Para terminar, dejo un video de Ashkenas presentando (en inglés) CoffeScript en la JSConf de hace un año. Es interesante ver la presentación de parte del propio padre de la criatura, pero tengan en cuenta que los doce meses transcurridos han cambiado la situación (para mejor) y ampliado las características del compilador.

 

lunes, 18 de abril de 2011

Rails 3.1 incluirá jQuery, CoffeeScript y Saas

Ruby on Rails

La próxima entrega de Ruby on Rails, la versión 3.1, incluirá por omisión estas librerías como parte de todo nuevo proyecto.

Por supuesto que ya ha habido mucha discusión al respecto en la comunidad Rails, pero como siempre, la decisión está tomada por DHH y sus secuaces, y al fin y al cabo, cambiar los defaults no es complejo (basta alterar un par de líneas en el gemfile).

Pero repasemos un poco de que se tratan estos cambios:

Hasta ahora la librería estándar de Javascript que Rails agregaba por omisión era Prototype, pero como la mayor parte de la gente hoy día utiliza jQuery (lo que demuestra que no es tan complejo cambiar estas cosas), decidieron hacer oficial el cambio.

Saas

Los otros cambios son más dramáticos para algunos, y es la inclusión por omisión de CoffeScript y Saas.

Sobre CoffeeScript escribí un post hace poco, así que voy a evitar repetirme, pero básicamente es una sintaxis simplificada de Javascript, que facilita escribir la parte cliente de aplicaciones web (aunque también se usa a veces del lado del servidor, en conjunto con Node.js).

Saas, por su parte, es una sintaxis alternativa para hojas de estilo en cascada (CSS).

Históricamente tuvo dos sintaxis, la original es la indentada (con archivos de extensión .saas), inspirada en el lenguaje de templates Haml (también muy difundido en el ambiente Ruby), y en lugar de usar llaves y punto y comas para delimitar bloques, se basa en indentación, como en este ejemplo:

#main
  color: blue
  font-size: 0.3em

  a
    font:
      weight: bold
      family: serif
    &:hover
      background-color: #eee

La nueva sintaxis se llama SCSS y es un superset de la sintaxis CSS3 que utiliza archivos de extensión .scss. Esta es la que impulsan desde Rails, y en este caso no se remueven las llaves y punto y comas, sino que el foco está en mejorar las posibilidades de definición, por ejemplo, soportando anidamiento de estilos:

#navbar {
  width: 80%;
  height: 23px;

  ul { list-style-type: none; }
  li {
    float: left;
    a { font-weight: bold; }
  }
}

Y también variables, como en:

$main-color: #ce4dd6;
$style: solid;

#navbar {
  border-bottom: {
    color: $main-color;
    style: $style;
  }
}

a {
  color: $main-color;
  &:hover { border-bottom: $style 1px; }
}

Pero también hay soporte para mixins (a la Ruby), herencia de selectores, y más características.

Al igual que en el caso de CoffeeScript, Saas va a estar integrado al framework, de manera que nosotros editamos los archivos en estos lenguajes y automáticamente se generan sus equivalentes .js y .css sin mayores inconvenientes. En ambos casos, llegado el momento de tener que depurar el código directamente en el navegador (utilizando FireBug o herramientas similares) la distancia entre los lenguajes reales y estas sintaxis alternativas nunca es tan grande como para convertirse en un problema.

 

jueves, 14 de abril de 2011

Node.js, Ruby y Python en... Windows Azure? (video)

smarx

Esta semana esta desarrollándose en Las Vegas, EEUU, la conferencia MIX11, en la que Microsoft realiza gran parte de sus anuncios para desarrolladores y diseñadores. A diferencia de PDC, que es la conferencia general para desarrolladores, MIX se orienta específicamente al desarrollo web o de aplicaciones cliente en general.

Como siempre, el criterio se amplía y aparecen, además de muchas presentaciones y anuncios esperables, algunas sesiones sumamente interesantes, como ésta de Steve Marx, uno de los personajes más innovadores dentro de Microsoft en los últimos tiempos.

En esta sesión, @smarx se dedica a subvertir Windows Azure, la plataforma de cloud computing, de la que él es el estratega técnico, para ejecutar sobre ella Node.js, Ruby, Python y también cosas como Cassandra o Tornado.

Veamos porque Steve me parece innovador:

Diagramas de smarx

  • No usa Powerpoint (y todavía no lo echaron): estos son sus slides de la charla (puro html+css)
  • Todos estos ejemplos están disponibles en su cuenta de GitHub
  • De hecho, tiene construido un workflow que hace el deploy en Azure de algunas aplicaciones después del git push
  • Sus diagramas son muy buenos (sólo comparables con los de @eugenio_pace, como se aprecia a la derecha).
  • Y fundamentalmente, entiende y divulga la necesidad de soportar múltiples plataformas y alternativas para que Azure sea un ambiente exitoso, en contra del discurso preponderante de que se lo utilice solo en .NET o PHP.

En la sesión se muestra cómo utilizar estas herramientas sobre la infraestructura pelada de Azure, sin utilizar ni el SDK, aprovechando algunas de las características que se habilitaron recientemente a este fin como:

  • Privilegios elevamos, para poder correr procesos como admin
  • Startup tasks: tareas que se pueden ejecutar antes de que un rol o instancia arranque
  • Control completo del IIS, incluyendo proxy reverso y FastCGI

Les dejo el video (en inglés) por si quieren entender un poco más el tema, especialmente los motivos por los cuales alguien querría hacer esto en Azure en lugar de otras plataformas. Si por alguna razón no se ve el video en este post (los mecanismos de incrustación de Channel 9 no parecen muy estables) pueden ver la sesión en la página original.

martes, 5 de abril de 2011

Recursos gratuitos para empezar con Node.js

Libro sobre Node

A través de un tweet de mi amigo Juancho Ladetto encontré este post de ReadWrite Hack comentando una series de recursos sobre Node.js.

Para los que no saben o no recuerdan de que se trata Node, hice una breve introducción en un post anterior, y los demás sabrán que es una de las tecnologías que me parece más prometedora entre las últimas apariciones, y creo que este año va a crecer muchísimo.

Uno de los recursos más interesantes es este libro (en progreso) de Tom Hughes-Croucher que O'Reilly, que puede leerse (en inglés) por ahora libremente en su versión previa (e incluso colaborar en la revisión).

El libro por ahora cubre los conceptos fundamentales, con buenas explicaciones incluyendo simpáticos dibujos como este:

Event Stack

También cubre las interfaces de programación principales como el EventEmitter, la sintáxis de Callbacks, servidores y clientes HTTP, peticiones GET, POST y PUT, el objeto ClientResponse y el uso de URLs, query strings, Streams de lectura, el FileSystem y Buffers.

Está iniciado también el capítulo cubriendo interfaces de ayuda, por ahora solo DNS, y el de documentación general que cubre varias clases, el depurador, marco de pruebas unitarias, sub-procesos, consola de comandos REPL, y mucho más (todo esto en formato de referencia).

Otro recurso interesante y en progreso es la guía de Felix (también en inglés), que cubre varias partes similares pero a distinta profundidad y con otro enfoque, y tiene una sección dedicada a "convencer al jefe" que apunta a resaltar las características principales de Node para poder explicarlo a otros.

miércoles, 30 de marzo de 2011

Akshell: Una IDE completa en línea

Akshell

Hace rato vengo esperando ver algo como esto. Hubo intentos anteriores auspiciosos, pero esta vez creo que se aproxima mas a mis expectativas porque además plantea un flujo de trabajo bastante completo.

Publico la reseña antes de hacer muchas pruebas porque me entusiasmó el proyecto: Akshell

Se trata de un entorno de desarrollo en línea completo, para Javascript, incluyendo integración directa con Git y GitHub, y despliegue automatizado (incluyendo un entorno de pruebas provisto, pero que puede enviar a cualquier dominio).

Soporta (por ahora) PostgreSQL utilizando un API de Javascript, e incluye un framework propio de pruebas unitarias basado en la biblioteca unit test de Python.

Veamos rápidamente un pantallazo del entorno, con una mínima aplicación de prueba:

Akshell IDE

Como se ve, hay manejo de proyectos, y en el navegador de la izquierda se ven los diferentes entornos (release y debug por omisión).

El editor tiene coloreo de sintáxis, y también por omisión hay un motor simple de templates para manejar el HTML de la aplicación y hacerlo interactuar con los scripts, como en este ejemplo:

{% extends 'base.html' %}

{% block title %}{{ entry.title }}{% endblock %}

{% block content %}
  {{ entry.title }}
  {{ entry.author }}
  {{ entry.message }}
{% endblock %}

Por ahora esto apunta a un modelo de aplicación bastante específico, pero bastante bien documentado y no lejano a cualquier framework web moderno.

Espero probar un poco más el entorno y poder compartir más datos, y ojalá otros compartan sus experiencias si hacen la prueba.

jueves, 17 de marzo de 2011

El juego de la vida en HTML5 usando Canvas

El juego de la vida de Conway (también conocido simplemente como "Life") es un ejemplo clásicos de Autómatas Celulares creado por John Horton Conway en los 70.

Consiste en una grilla de puntos (el universo) donde cada punto puede contener un individuo o célula (un punto de la grilla que está encendido o vivo (los puntos tienen estado binario: vivos o muertos).

El juego funciona sólo (se lo conoce como un juego de cero jugadores), y lo único que se puede hacer es preparar el estado inicial y luego echarlo a correr. La corrida involucra generaciones, o pasadas por la grilla completa para analizar el estado y calcular el de la siguiente pasada. El cálculo se hace analizando para cada punto su estado y el de los ocho que lo rodean (sus vecinos):

Celula y Vecinos

Para determinar si la célula analizada vive o muere, se aplican las siguientes reglas:

  • Una célula viva con menos de dos vecinos vivos se muere (de soledad)
  • Una con dos o tres vecinos vivos sobrevive
  • Una con más de tres vecinos vivos se muere (por sobrepoblación)
  • Una célula muerta con exactamente tres vecinos vivos, nace (por reproducción)

La grilla debe considerarse como un toroide, o sea que los puntos de la última fila continúan en la superior, y los de la última columna derecha continúan en la primera de la derecha y viceversa.

Parece sencillo, pero ha sido estudiado durante todos estos años no solamente como un interesante Code Kata, sino como un interesante ejercicio de simulación de ecosistemas.

Como no hay mejor manera de entenderlo que verlo en acción, les recomiendo ver esta versión implementada en HTML 5, utilizando el tag Canvas.

Cosas interesantes que ocurren con este juego es que espontáneamente aparecen configuraciones estables (que permanecen constantes durante muchas generaciones, variando entre un número determinado de estados. Es un interesante ejemplo de comportamiento emergente, y aunque parezca un oximorón, un ejemplo sencillo de sistemas complejos.

Juego de la Vida

Por supuesto, una de las cosas muy interesantes de ver es código fuente. Son sólo 234 líneas de JavaScript y aunque parece un poco largo para un post, creo que vale la pena pegarlo completo, aunque recomiendo que si alguien lo quiere tocar baje siempre la última versión disponible en GitHub.

 

/*
 * Copyright 2011 Julian Pulgarin 
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0

 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

var Point = function(x, y) {
    this.x = x;
    this.y = y;
};

var graphics = function() {
    var canvas;
    var ctx;
    var canvasId;

    var cellSize = 10; // pixels
    var onColour = 'rgb(0, 200, 0)';
    var offColour = 'rgb(200, 0, 0)';
    var gridColour = 'rgb(50, 50, 50)';

    var initCanvas = function(canvasId) {
        this.canvas = $(canvasId).get(0);
        this.ctx = this.canvas.getContext('2d'); 
        this.canvasId = canvasId;
    }

    var drawCell = function(x, y, alive) {
        var g = graphics;
        g.ctx.fillStyle = (alive)? onColour : offColour;
        g.ctx.fillRect(x * cellSize + 1, y * cellSize + 1, cellSize - 1, cellSize - 1);
    }

    var handleMouse = function(e) {
        var l = life;
        var g = graphics;
        var that = this;
        var cell = getCellPointUnderMouse(e);
        var state;
        processCell(cell);
        $(g.canvasId).mousemove(function(e) {
            cell = getCellPointUnderMouse(e);
            processCell(cell);
        });
        function getCellPointUnderMouse(e) {
            return new Point((e.pageX - that.offsetLeft) / g.cellSize | 0, ((e.pageY - that.offsetTop) / g.cellSize) | 0);
        }
        function processCell(cell) {
            var x = cell.x;
            var y = cell.y;
            if (x > l.xCells - 1 || y > l.yCells - 1) {
                return;
            }
            if (typeof state == 'undefined')
            {
                state = !l.prev[x][y];
            } 
            l.prev[x][y] = state;
            drawCell(x, y, state);
            // TODO: Consider setting next as well
        }
    }

    function paint() {
        var g = graphics;
        var l = life;

        for (var x = 0; x < l.xCells; x++) {
            for (var y = 0; y < l.yCells; y++) {
                g.drawCell(x, y, l.prev[x][y]);
            }
        }
    }

    return {
        canvas: canvas,
        ctx: ctx,
        canvasId: canvasId,
        cellSize: cellSize,
        onColour: onColour,
        offColour: offColour,
        gridColour: gridColour,
        initCanvas: initCanvas,
        drawCell: drawCell,
        handleMouse: handleMouse,
        paint: paint,
    }
}(); 

var life = function() { 

    var yCells; 
    var xCells;
    var prev = []; // previous generation
    var next = []; // next generation

    var _timeout;
    var _alive = false;

    var initUniverse = function(canvasId) {
        var l = life;
        var g = graphics;
        g.initCanvas(canvasId);
        l.xCells = ((g.canvas.width - 1) / g.cellSize) | 0;
        l.yCells = ((g.canvas.height - 1) / g.cellSize) | 0; 
        g.ctx.fillStyle = g.offColour;
        g.ctx.fillRect(0, 0, l.xCells * g.cellSize, l.yCells * g.cellSize);
        g.ctx.fillStyle = g.gridColour;

        for (var x = 0; x < l.xCells; x++) {
            l.prev[x] = [];
            l.next[x] = [];
            g.ctx.fillRect(x * g.cellSize, 0, 1, l.yCells * g.cellSize);
            for(var y = 0; y < l.yCells; y++)
            {
                l.prev[x][y] = false;
            }
        }
        g.ctx.fillRect(l.xCells * g.cellSize, 0, 1, l.yCells * g.cellSize);
        for(var y = 0; y < l.yCells; y++)
        {
            g.ctx.fillRect(0, y * g.cellSize, l.xCells * g.cellSize, 1);
        }
        g.ctx.fillRect(0, l.yCells * g.cellSize, l.xCells * g.cellSize, 1);
        $(canvasId).mousedown(g.handleMouse);
        $('body').mouseup(function(e)
        {
            $(g.canvasId).unbind('mousemove');
        });
    }

    var nextGen = function() {
        var l = life;
        var g = graphics;

        for (var x = 0; x < l.xCells; x++) {
            for (var y = 0; y < l.yCells; y++) {
                l.next[x][y] = l.prev[x][y];
            }
        }

        for (var x = 0; x < l.xCells; x++) {
            for (var y = 0; y < l.yCells; y++) {
                count = _neighbourCount(x, y);

                // Game of Life rules
                if (prev[x][y]) {
                    if (count < 2 || count > 3) {
                        next[x][y] = false;
                    }
                } else if (count == 3) {
                    next[x][y] = true;
                } 
            }
        }

        for (var x = 0; x < l.xCells; x++) {
            for (var y = 0; y < l.yCells; y++) {
                l.prev[x][y] = l.next[x][y];
            }
        }

        g.paint();
    }

    var toggleLife = function() {
        var l = life;

        if (!l._alive) {
            l._alive = true;
            l._timeout = setInterval("life.nextGen()", 100);
        } else {
            l._alive = false;
            clearInterval(l._timeout);
        }
    }

    var clear = function() {
        var l = life;
        var g = graphics;

        for (var x = 0; x < l.xCells; x++) {
            for (var y = 0; y < l.yCells; y++) {
                l.prev[x][y] = false;
            }
        }
        g.paint();
    }

    var _neighbourCount = function(x, y) {
        var l = life;
        var count = 0;
        var neighbours = [
            l.prev[x][(y - 1 + l.yCells) % l.yCells],
            l.prev[(x + 1 + l.xCells) % l.xCells][(y - 1 + l.yCells) % l.yCells],
            l.prev[(x + 1 + l.xCells) % l.xCells][y],
            l.prev[(x + 1 + l.xCells) % l.xCells][(y + 1 + l.yCells) % l.yCells],
            l.prev[x][(y + 1 + l.yCells) % l.yCells],
            l.prev[(x - 1 + l.xCells) % l.xCells][(y + 1 + l.yCells) % l.yCells],
            l.prev[(x - 1 + l.xCells) % l.xCells][y],
            l.prev[(x - 1 + l.xCells) % l.xCells][(y - 1 + l.yCells) % l.yCells],
        ];

        for (var i = 0; i < neighbours.length; i++) {
            if (neighbours[i]) {
                count++;
            }
        }
             
        return count;
    }

    return {
        yCells: yCells,
        xCells: xCells,
        prev: prev,
        next: next,
        initUniverse: initUniverse,
        nextGen: nextGen,
        toggleLife: toggleLife,
        clear: clear,
    }
}();

miércoles, 16 de marzo de 2011

En el jardín del buen y del mal JavaScript

Better JS Docs

Dos especialmente dedicados miembros de la comunidad de desarrolladores StackOverflow, Ivo Wetzel (23 años, trabajando en Zynga Alemania) y Yi Jiang (17 años, estudiante de Singapur) , han construido el sitio JavaScript Garden, dedicado a corregir errores de interpretación y mejorar el entendimiento sobre este fantástico lenguaje.

Además de ser un ejemplo de sobriedad y buen diseño (noten la fluidez de la navegación desde el menú a la derecha), me parece un gran trabajo de difusión, cubriendo por áreas las particularidades de JavaScript que suelen confundir a algunos programadores proveniendo de entornos bastante diferentes.

Algunos ejemplos que tomo del sitio:

Objetos y propiedades

En JS todo es u objeto, excepto null y endefined.

false.toString() // 'false'
[1, 2, 3].toString(); // '1,2,3'

function Foo(){}
Foo.bar = 1;
Foo.bar; // 1 

Es común pensar que los números literales no pueden tratarse como objetos porque no se puede acceder a sus miembros de la manera tradicional, pero esto es un defecto histórico del parser, que puede subsanarse fácilmente utilizando doble punto o espacios, como se muestra aquí:

2.toString(); // arroja SyntaxError

2..toString(); // el segundo punto hace que se interprete bien
2 .toString(); // o se puede dejar un espacio antes
(2).toString(); // o el uso de paréntesis también

En JS los objetos están implementados como hashmaps, o listas de elementos clave-valor, con lo que es posible crear objetos utilizando esta notación:

var foo = {}; //  objeto vacío (hereda de object.prototype)

// un nuevo objeto con la propiedad 'test' y valor 12
var bar = {test: 12}; 

Y las propiedades también pueden accederse como tales o como índices. Incluso al usar la notación con corchetes se pueden soportar propiedades que no serían posibles utilizando puntos, como en:

var foo = {name: 'Mafalda'}
foo.name; // Mafalda
foo['name']; // Mafalda

var get = 'name';
foo[get]; // Mafalda

foo.1234; // SyntaxError
foo['1234']; // funciona

Prototipos

Esta es una de las facetas más "raras" para muchos programadores provenientes de una cultura de orientación a objetos "canónica. De hecho escuché varias veces el argumento de que "JavaScript no es orientado a objetos porque no tiene clases ni herencia". Esto es totalmente falaz: JS es orientado a objetos, sólo que tiene herencia por prototipos, y no por clases. En este sitio tienen estos buenos ejemplos de cómo mantener una jerarquía tradicional utilizando cadenas de prototipos.

Hay mucha más información y no es mi objetivo repetir todo el sitio, por lo que les recomiendo dedicarle una hora a leerlo y hacer algunas pruebas. No lleva mucho más que eso y para muchos ahorrará muchos dolores de cabeza, o les permitirá valorar JavaScript como el lenguaje merece.

lunes, 28 de febrero de 2011

Mejorando aplicaciones web con Chrome Developer Tools (video)

Google Chrome

Una de las características que el navegador de Google tuvo desde el inicio fue la integración de un buen juego de herramientas para desarrolladores.

Y estas herramientas siguen progresando a lo largo del tiempo, ayudándonos en el desarrollo web (por supuesto sin importar qué navegador usen los usuarios finales). Para quienes quieran aprovechar las últimas características, es recomendable utilizar la versión disponible en el Chrome Beta Channel.

Algunas de las funciones principales incluyen:

  • Edición en vivo del DOM y las plantillas CSS (ideal para retocar sobre el navegador y experimentar hasta ajustar las páginas)
  • Depuración de JavaScript utilizando un depurador gráfico y pudiendo marcar breakpoints, o incluso editar scripts sobre la marcha, agregando sobre el navegador datos de depuración o ayudas.
  • Analizar el tiempo de ejecución de cada función para optimizar el rendimiento.
  • Seguir el flujo y proceso de pintado de las páginas mientras cargan.
  • Explorar el almacenamiento en bases de datos locales de HTML5.

Es interesante saber que estas herramientas están escritas por completo usando JavaScript y CSS, y cualquiera puede revisar el código fuente e incluso postularse para contribuir al proyecto.

Dejo un video corto (4 minutos y medio) en el que un ingeniero de Google demuestra cómo usar estas herramientas. El video está en inglés, pero la explicación es muy clara y ver las herramientas en acción seguramente les permita descubrir algún recurso que todavía no aprovechaban.

viernes, 25 de febrero de 2011

Brunch: aplicaciones HTML5 desde los hombros de gigantes

Brunch

"Parado sobre los hombros de gigantes" es una frase típica de la cultura anglosajona, famosamente usada por Isaac Newton, que refiere a construir sobre el trabajo de quienes nos han precedido.

Esta idea es la base de Brunch, un framework compuesto de varias partes preexistentes para facilitar la construcción de aplicaciones web modernas.

Incluso si uno no va a usarlo directamente, es bueno recorrer y entrar en contacto con algunos de sus componentes, todos ellos de código abierto, no todos tan conocidos. Veamos cuáles son:

  • CoffeeScript
    Es un lenguaje que compila a Javascript, simplificando mucho la sintaxis, como se puede leer en este post previo.
  • Backbone.js
    Es una librería para aplicaciones JavaScript que brinda estructura para utilizar modelos y vistas con eventos de uso declarativo, un API para colecciones con mucha funcionalidad, y capacidades de conexión utilizando JSON con interfaces REST. Pueden ver un ejemplo en línea con el código completamente documentado a un link de distancia.
  • Underscore.js
    Es otra librería, que Backbone utiliza, y que provee más funciones para manejo de estructuras de datos a mas bajo nivel, incluyendo colecciones, arrays,  extensión sobre funciones (como memorización, diferimiento, composición, etc), objetos, utilidades y cadenas.
  • Eco
    Es un motor de plantillas que permite embeber CoffeScript dentro del markup de una página, como si fuese EJS o ERB.
  • Stylus
    Es un lenguaje de declaración de hojas de estilo en cascada (CSS) con una sintaxis simplificada, como CoffeScript hace con JavaScript. Es básicamente CSS sin llaves ni otros signos de puntuación, mucho más legible.
  • Docco
    Genera documentación de código en formato HTML, soportando Markdown y colorero de sintaxis. Unos cuantos de los proyectos anteriores utilizan Docco en su documentación.
  • jQueryZepto.js
    jQuery no requiere presentación para los lectores de este blog, pero Zepto es un framework minimalista compatible con jQuery y orientado a navegadores de dispositivos móbiles basados en WebKit.

En suma, más allá de Brunch mismo, puede verse un ecosistema creciente de librerías que trabajan en conjunto y con buen nivel de compatibilidad.

 

lunes, 7 de febrero de 2011

Cómo acelerar nuestras aplicaciones web

High Performance Web Sites

Desde hace ya tiempo la mayoría de las aplicaciones que desarrollamos son aplicaciones web. Incluso el límite entre aplicaciones web y de escritorio es cada vez más difuso, entre nuevas tecnologías basadas en plugins como Flash, Silverlight o Unity, y el incremento de poder del lado de HTML y Javascript, incluyendo también soporte offline y otras características.

Sin embargo, la web, por las maravillas de la diversidad que la hacen fabulosa, también es un océano de calamidades desde el punto de vista del diseño e implementación de las aplicaciones que encontramos en ella.

A esta altura la mayoría de nosotros debería conocer las recomendaciones y herramientas básicas para optimizar los tiempos de respuesta de nuestras aplicaciones, pero nunca está de más repasarlas.

La mayor parte de estas recomendaciones surgen del trabajo de Steve Souders, iniciado cuando era el Chief Performance en Yahoo!, antes de continuar esta labor desde Google, y compilado en dos libros que ya debería considerarse como obligatorios para cualquier desarrollador que tenga que tocar algo en la web:

Even Faster Web Sites

High Performace Web Sites (de 1997) y Even Faster Web Sites (de 2009)

La mayoría de estas reglas pueden verse en detalle en el sitio para desarrolladores de Yahoo, especialmente en la sección de Mejores Prácticas para acelerar un Sitio Web o su equivalente en Google, Mejores prácticas de rendimiento Web.

Dejo un resumen rápido de algunas recomendaciones, para que se den una idea antes de zambullirse en la lectura de todo ese material.

Minimizar peticiones HTTP

  • Combinar archivos es una manera de reducir peticiones, por ejemplo, unificando las hojas de estilo y scripts
  • Utilizar Sprites CSS para combinar muchas imagenes en una sola y descomponerla en la página

Utilizar redes de distribución de contenido (CDNs)

Esto no aplica a cualquier sitio, porque implica un costo, pero cada vez aparecen más alternativas económicas o embebidas directamente sobre alguna plataforma más amplia.

Agregar expiración o control de cache en la cabecera

Tanto en contenido estático como dinámico, manejando apropiadamente estos mecanismos podemos lograr que el browser descargue una única vez los recursos que no varían. Esto es particularmente efectivo en cosas como imágenes, hojas de estilo, scripts, etc, pero también se puede lograr mantener la mayor parte del HMTL utilizando mecanismos de fragmentación para separar el contenido que realmente varía.

Comprimir componentes con Gzip

Esta es una de las recomendaciones que es casi gratuita. La mayoría de los navegadores modernos soportan este tipo de compresión que es estándar, lo mismo que casi todos los servidores web. Sólo implica indicar que debe ser utilizada al hacer las peticiones.

Ubicar las hojas de estilo arriba de la página

Ubicar los estilos en la cabecera del HTML hace que la carga de la página se perciba más rápida porque permite que suceda progresivamente.

Ubicar los scripts al final de la página

La descarga de los scripts genera muchas veces un freno a la descarga en paralelo de otros elementos, porque supo que parte del código puede estar escribiendo parte del contenido de la página. Hay varias técnicas para evitar el problema y mejorar el rendimiento general.

Evitar expresiones CSS

Estas expresiones permiten asignar valores dinámicos a propiedades de los estilos, pero esta es una operación peligrosa y lenta, por lo que se la convirtió en obsoleta.

Los scripts y hojas de estilo deberían ser externos

Independizar estos recursos mejorar usualmente el rendimiento porque además de poder paralelizarse la descarga, estos son recursos ideales para permanecer mucho tiempo en la cache del navegador.

Reducir la cantidad de búsquedas en los DNS

Esto es algo en lo que hay que mantener un balance. Las búsquedas en los servidores de nombres son mantenidos en cache por los navegadores por varios minutos, porque son una operación relativamente costosa. De todas maneras, cierta distribución de recursos en diferentes dominios también ayuda a paralelizar las descargas, ya que los navegadores tienen un límite de cantidad de descargas en paralelo por cada dominio.

Minificar JavaScript y hojas de estilo

Esta práctica implica compactar en ambos casos la cantidad de caracteres en uso para todos los recursos internos como estilos, variables y nombres de funciones, al igual que reducir la cantidad de espacios opcionales e indentación. Esto hace que el resultado parezca críptico, pero puede resolverse en una etapa posterior al desarrollo, como parte del despliegue (utilizando JSMin y YUI Compressor, por ejemplo), de modo que dentro del ciclo de vida de un proyecto nadie tenga que leer las versiones minificadas.

Evitar redirecciones

Aunque este es un recurso útil en ciertos casos, su abuso genera demoras y una experiencia poco prolija, que es difícil de optimizar.

Remover scripts duplicados

Aunque parezca obvio, la cantidad de sitios que incluyen mas de una vez el mismo script en una página es enorme. En parte, si se trabaja fuertemente en la unificación de los scripts, las posibilidades de que esto suceda disminuyen inmediatamente.

Configurar ETags

A pesar de que los ETags son un mecanismo para evitar transferir recursos ya existentes, implementaciones divergentes de este estándar en distintos servidores terminan generando que algunos recursos se descarguen siempre, sin importar si ya están actualizados en el navegador. Es importante revisar la manera en que funcionan y estar seguro que lo hacen correctamente.

Hacer que las llamadas AJAX utilicen la cache

Aunque esta técnica de pedir datos de manera asincrónica sin tener que reenviar toda la página está pensada para minimizar el tráfico, es importante aplicar muchas de las recomendaciones anteriores a estos casos también. Esto implica hacer que las respuestas generalmente dinámicas de estos servicios utilicen los mismos mecanismos para evitar el reenvío de respuestas que ya llegaron antes al navegador y cuyo contenido no cambió.

 

¿Cómo controlar y validar estas reglas?

Aunque la lista pueda amedrentarnos en principio, ya hay varias herramientas disponibles para ayudarnos en este camino, como la clásica YSlow (un plugin de FireBug, que a su vez es un plugin para FireFox). Va como muestra una captura del análisis de YSlow en este blog (para que vean que todos cometemos pecados).

Analisis de YSlow

Google, por su parte, tiene también una extensión similar pero con algunas características particulares, llamada PageSpeed, producto de la mudanza de Souders. Notablemente esta extensión también es para FireBug, por lo que corre en FireFox, no en Chrome.

Finalmente, Google ha publicado también el módulo mod_pagespeed para Apache, que aplica muchas de las reglas automáticamente, al preprocesar scripts y hojas de estilo, unificando y minificándolas, optimizando imagenes, etc.

Es interesante ver que GoDaddy, el principal registrador de domininos y una de las principales empresas de hosting en el mundo, ha empezado a activar este módulo en todos sus servidores Apache, produciendo mejoras significativas en muchísimos de sus cliente de manera casi mágica.

 

miércoles, 2 de febrero de 2011

Leisure Suit Larry en HTML5

En la puerta de Lefty's

La aparición de nuevas librerías para gráficos y animación en HTML5 / JavaScript han posibilitado una avalancha de regresos a juegos clásicos que se adaptan bien a ser ejecutados en el browser.

Y aunque ya se pueden encarar estilos más ambiciosos, los clásicos siguen volviendo. Esta vez encontré una versión sumamente fiel de un clásico de los 80: Leisure Suit Larry. Para quienes lo jugaron en aquella época o m's tarde, ya que su popularidad lo mantuvo vivo bastante tiempo, he aquí una oportunidad de revivir esos momentos sin tener que recurrir a la virtualización.

Algo interesante de este juego y otros clásicos disponibles en el mismo sitio, es que están autorizados por las compañías que mantienen los derechos de los juegos originales, Activision y CodeMasters.

Pero además están construidos sobre un par de componentes  para juegos licenciado bajo GPL o MIT, y disponibles en Google Code:

  • El intérprete Sarien.Net, que es una implementación sobre el browser del motor original usado por Sierra On-Line para los juegos originales Space Quest, Police Quest y el de Larry.

  • El motor multiplayer Q42 es una plataforma multi-usuario sumamente liviana para juegos basados en el browser, siempre por puerto 80. El API cliente son 5K de JavaScript, y el servidor es una clase en C# que puede embeberse o referenciarse como una DLL externa (imagino que probablemente pueda correr en Mono, pero habría que probarlo).

    El motor implementa básicamente un mecanismo de chat con salas separadas, escalamiento automático, liberación de salas vacías, propiedades por usuario como nombre y posición (x,y), mensajería y soporte para múltiples usuarios por sesión, lo que permite mantener usuarios distintos en tabas separados del mismo browser, por ejemplo.

Espero que alguno se divierta con esto, jugando o programando.

martes, 1 de febrero de 2011

Meditación programática: Koans

Zen (http://www.flickr.com/photos/josefeliciano/3849557951)

Los Köan (pronunciación japonesa del chino 公案) o Koan, son ejercicios mentales de la meditación Zen, consistentes en diálogos o preguntas que plantean un problema que muchas veces no tiene respuesta directa. El objetivo de un Koan es el aprendizaje durante el proceso de elaboración de la respuesta, más que la respuesta en sí.

Un ejemplo clásico es la pregunta: "Cuando dos manos aplauden hay un sonido. ¿Cuál es el sonido de una sola mano?".

Tomando esta idea como base, de manera similar a la idea de los Code Katas que comentaba en un post reciente, diferentes personas empezaron a generar Code Koans para diferentes lenguajes. Como siempre, la adaptación es libre y no sigue exactamente los mismos principios, sino que e inspira en la idea motora.

Los Koans dentro del campo de la programación parten del objetivo de comenzar con conceptos sumamente básicos y realizar ejercicios generalmente abiertos, pero que frecuentemente llevan a la necesidad de experimentar o investigar un poco más allá del alcance mismo del planteo.

Hay colecciones de Koans para varios lenguajes, entre ellos Ruby Koans (Jim Weirich y Joe O'Brien), JavaScript Koans (Liam McLennan), .NET Koans (Cory Foy) y los Clojure Koans (Aaron Bedra).

La mayoría de estos proyectos están inspirados en el primero, los Ruby Koans, de los que incluyo algunos ejemplos para que se entienda el concepto general.

Los Koan suelen estar agrupados por temas, por ejemplo en los de Ruby, hay series para arrays, blocks, clases, excepciones, módulos, strings, y muchas más.

Los Koans se basan siempre en la práctica de Test-Driven Development (curso gratuito en español disponible), donde las "preguntas" están formuladas como tests, que el aprendiz debe implementar y pasar. La diferencia con TDD tradicional es que el test principal ya está escrito (lo que no significa que no podamos agregar más).

Lo primero a ejecutar en los Ruby Koans es (desde la línea de comandos):

$ ruby path_to_enlightenment.rb

y el resultado es algo como:

AboutAsserts#test_assert_truth has damaged your karma.

The Master says:
  You have not yet reached enlightenment.
  Do not lose hope.

The answers you seek...
  Failed assertion, no message given.

Please meditate on the following code:
  /Users/ . . . /koans/about_asserts.rb:10:in `test_assert_truth'

mountains are merely mountains
your path thus far [X_________________________________________________] 0/274

El mensaje juega con el estereotipo del Maestro Zen y el estilo de los consejos, pero más allá de eso, nos da un indicio: nos dice que meditemos en el método test_assert_truth dentro del archivo about_asserts.rb. Si abrimos este archivo y lo miramos, encontramos este test donde el motivo de la falla es más que obvio:

  # We shall contemplate truth by testing reality, via asserts.
  def test_assert_truth
    assert false                # This should be true
  end

Al cambiar a assert true y ejecutar de nuevo, obtenemos un mensaje similar sobre el siguiente test que falla, y otra frase Zen diferente para inspirarnos. Por supuesto, a medida que avanzamos la respuesta es menos evidente que cambiar un false a true. El primer ejercicio solamente sirve para que entendamos el procedimiento.

En varios casos, la manera de resolver el test no es evidente y tenemos que buscar más información en libros o en la web, pero esto es lo que buscan los Koans: forzarnos a aprender algo, pero siguiendo baby steps.

jueves, 20 de enero de 2011

Raros Lenguajes Nuevos: CoffeeScript

CoffeeScript

CoffeeScript es un lenguaje que compila a JavaScript, y mantiene una premisa fundamental: sigue siendo JavaScript.

El código es compilado a su equivalente, y es posible utilizar cualquier librería o extensión como en el ambiente original. El código final generado es prolijo y entendible, pasa las validaciones de JavaScript Lint y funciona en cualquier motor de JavaScript.

Lo que CoffeeScript aporta es una sintaxis simplificada, inspirada en Ruby y Python, despojada de llaves y puntos y comas, bastante más legible pero con exactamente el mismo poder y características del JavaScript tradicional.

Veamos algunos ejemplos:

# Asignación:
number   = 42
opposite = true
# Condiciones:
number = -42 if opposite

Esto genera el siguiente JavaScript:

var number, opposite;
number = 42;
opposite = true;
if (opposite) {
number = -42;
}

Y aunque estos ejemplos suenan triviales, ya pueden notarse algunas abreviaturas importantes. Pero veamos un ejemplo más extremo, que utiliza declaración de funciones, espacios de nombre y comprensión de arrays:

# Declaración de funciones
square = (x) -> x * x

# Declaración de un array:
list = [1, 2, 3, 4, 5]

# Funciones dentro de un espacio de nombres:
math =
  root:   Math.sqrt
  square: square
  cube:   (x) -> x * square x

# Comprensión de Arrays: cubes = (math.cube num for num in list)

Y su equivalente en JavaScript:

var cubes, list, math, num, square;
var __slice = Array.prototype.slice;

square = function(x) {
  return x * x;
};

list = [1, 2, 3, 4, 5];

math = {
  root: Math.sqrt,
  square: square,
  cube: function(x) {
    return x * square(x);
  }
};

cubes = (function() {
  var _i, _len, _results;
  _results = [];
  for (_i = 0, _len = list.length; _i < _len; _i++) {
    num = list[_i];
    _results.push(math.cube(num));
  }
  return _results;
})();

¿No es notoriamente más clara la versión en CoffeeScript?

La sintaxis completa y referencia está disponible en línea.

¿Cómo funciona? El compilador está escrito en CoffeeScript (en la mejor tradición geek) utilizando Jison Parser Generator. La versión de línea de comando funciona sobre Node.js, aunque el compilador en si puede correr en cualquier motor de JavaScript.

Algo muy interesante es que cualquiera que quiera jugar un poco no necesita instalar nada. Simplemente puede ir al sitio de CoffeeScript dentro de GitHub y elegir “Try CoffeeScript” en el menú superior para acceder a un editor en línea que permite escribir código CoffeeScript del lado izquierdo y va mostrando cómo se compila (en tiempo real, letra por letra) en JavaScript, como se ve en la figura:

 

Try CoffeeScript

jueves, 13 de enero de 2011

YUI 3.3.0 - Nueva versión de la librería de Yahoo!

YUI Autocomplete

Recién salida del horno, la versión 3.3.0 de YUI (Yahoo! User Interface) trae unas cuantas novedades para pulir la interfaz de las aplicaciones web sin costo del lado servidor.

Entre las principales características:

  • Soporte para FireFox 4, Internet Explorer 9 y Android 2.2.
  • Abstracciones más dulces para manipulación de nodos, como show y hide para controlar la visibilidad de nodos completos (o listas de nodos), o wrap, unwrap y otros métodos.
  • Un widget para auto-completar entradas de texto (como se ve en la figura a la derecha).
  • Gráficos estadísticos (usando una combinación de SVG, Canvas y VML).
  • Un widget para tablas de datos, incluyendo paginado y ordenamiento dinámico de manera extensible. Al pie, los interesados pueden ver este video de Tilo Mitra presentando este componente en el evento YUIConf 2010.
  • Otro widget para incluir diales de valores (similares a una perilla de volumen) con una granularidad muy fina.
  • Y.ResizeUtilidad de resize, que activa la posibilidad de cambiar el tamaño de elementos en el browser utilizando los típicos ganchos en las esquinas y lados (ver imagen a la derecha).

Esta librería sigue creciendo y agregando mucha funcionalidad interesante. Mientras escribo esto estoy charlando con Juampi que es más fanático de JQuery (admito que yo también). Sin embargo, no hay que perder de vista que el mundo de Javascript es hospitalario y cuida la convivencia con el uso de recursos como espacios de nombres y pruebas extensivas con elementos externos.

Para quienes quieran aprovechar lo mejor de ambos lados, recomiendo pegar una leída a especialmente a la documentación de JQuery en relación a su uso con otras librerías.

Les dejo el video sobre las tablas de datos (en inglés):

 

martes, 11 de enero de 2011

Json.Net 4.0 acerca el lado dinámico y estático de las aplicaciones web

Json

Json.Net es una librería de alto rendimiento para manejar el protocolos Json (JavaScript Object Notation) desde .NET.

Json es el mecanismo de comunicación más utilizado hoy día en aplicaciones web modernas. La revolución inicial de AJAX (Asynchronous JavasScript And XML) implicaba, como su nombre lo indica, intercambiar XML desde el browser y el servidor, manipulando el DOM de las páginas para refrescar datos, en lugar de volver a traer el HTML completo. Desde hace tiempo esto dejó de hacerse serializando a XML, pasando en cambio a Json porque es más compacto, lo que implica menos tráfico, pero también porque es muchísimo más JSON.parse (en JavaScript puro) o $.getJSON (en JQuery).

Sin embargo, volviendo a .NET, tradicionalmente la convivencia entre el mundo estático y el paradigma eminentemente dinámico que propone Json no fue sencilla. Existe dentro del framework el espacio System.Web.Script.Serialization que contiene un JavaScriptSerializer, pero utilizarlo es una tarea ardua y bastante propensa a errores.

Entre las alternativas abiertas, Json.Net es una de las más populares, y en su reciente versión 4.0 (release 1), aprovecha las nuevas características dinámicas del .NET Framework 4. Más que ninguna otra cosa, el uso de esta librería se simplificó enormemente a partir de aprovechar el nuevo tipo dynamic en .NET (que irónicamente, es un tipo estático más), y el agregado de LINQ to Json.

Veamos el uso de Json.Net con tipos dynamic:


dynamic value = new DynamicDictionary();

value.Name = "Juan Perez";
value.Enabled = true;
value.Roles = new[] {"Admin", "User"};

string json = JsonConvert.SerializeObject(value, Formatting.Indented);
// {
// "Name": "Juan Perez",
// "Enabled": true,
// "Roles": [
// "Admin",
// "User"
// ]
// }

¿No es elegante? Y mucho más sencillo que cualquier cosa tradicionalmente en .NET. Consumamos ahora el Json, a la inversa que en el ejemplo anterior:


dynamic newValue = JsonConvert.DeserializeObject(json);

string role = newValue.Roles[0];
// Admin

Finalmente, LINQ to Json permite (entre otras cosas) realizar consultas directamente sobre un resultado Json de manera simple y eficiente, como en este ejemplo:


var categories =
from c in rss["channel"]["item"].Children()["category"].Values()
group c by c into g
orderby g.Count() descending
select new { Category = g.Key, Count = g.Count() };

foreach (var c in categories)
{
Console.WriteLine(c.Category + " - Count: " + c.Count);
}

Algunas otras características de la nueva versión incluyen mejoras en la serialización binaria BSon, Json Schema, e inminentemente estará actualizado el paquete NuGet para instalar esta nueva versión desde Visual Studio directamente o desde la línea de comandos, manejando todas las dependencias que hubiese.

 

miércoles, 5 de enero de 2011

Probando aplicaciones web con Zombie.js

http://www.flickr.com/photos/tohoscope/5086711384/Probar aplicaciones web modernas, con mucho scripting del lado cliente, es cada vez más complejo. El hecho de que la interfaz de usuario cambie dependiendo de las interacciones sin necesidad de pasar por el servidor genera la necesidad de realizar pruebas sobre el lado cliente.

El problema de esto es que la mayor parte de las herramientas para efectuar este tipo de pruebas requiere de una instancia de un browser real, lo que genera una dependencia fuerte y sobre todo, implica que cada prueba tarde más porque un browser demora un montón de tiempo en cargar y dibujar los elementos y tiene en cuenta montones de cosas que en realidad no necesitamos en la mayoría de los escenarios para hacer pruebas automatizadas.

Zombie.js se llama así porque es un entorno de prueba headless (sin cabeza; en realidad sin browser), y es muy rápido, además de brindar un API muy cómoda para escribir las pruebas.

La plataforma hace uso nuevamente de las ventajas de Node.js (más detalles en un post anterior) para recrear el entorno de un browser, incluyendo el DOM y características de HTML5, pero sin la necesidad de dibujar realmente nada, lo que le permite alcanzar velocidades totalmente diferentes.

Para lograr este entorno, Zombie combina varias librerías abiertas como JSDOM para emular el DOM, HTML5 para parsing, Sizzle para los selectores CSS y AJAXSLT para el soporte a XPath. Y el proyecto a su vez, también está abierto a quien quiera meter mano, alojado en GitHub.

Veamos un brevísimo ejemplo de cómo instanciar el entorno de un browser, navegar a una página, identificarse y verificar que la operación sea exitosa al llegar a una siguiente página de bienvenida.

var zombie = require("zombie");
var assert = require("assert");


// Carga la página desde el localhost
zombie.visit("http://localhost:3000/", function (err, browser) {


  // Completa email y password y confirma el formulario
  browser.
    fill("email", "zombie@underworld.dead").
    fill("password", "eat-the-living").
    pressButton("Sign Me Up!", function(err, browser) {


      // Al procesar el form, ve si fue a la página correcta
      assert.equal(browser.text("title"), "Welcome To Brains Depot");
    })
});

Como se ve, el API es muy sencilla y natural, y como siempre en Node, no hay llamadas bloqueantes; todo lo que pasa se maneja con callbacks, lo que hace también que correr una batería importante de pruebas sea más rápido en total, facilitando la ejecución más frecuente, lo que siempre eleva la calidad del proceso de desarrollo.

 

Javascript ya no es lo que era

Mario Kart

Siguiendo con las pruebas de cuánto se puede llegar a hacer con Javascript (más características de HTML5 como Canvas), aquí hay otra implementación de un juego clásico: Mario Karts. Por ahora sólo se trata de la carrera, sin obstáculos especiales ni armas, pero no está mal para 11 Kb, sobre todo porque lo impresionante es la velocidad a la que se mueve la pista.

Pero no me crean a mi. Veanlo ustedes mismos, con algún navegador moderno que tenga buen soporte para HTML5 y un motor rápido de Javascript. Firefox 3.x en adelante, Chrome o Safari funcionan. No probé con Internet Explorer 9 Beta, pero debería funcionar bien (espero reportes).

Y como verán en la página, pueden ver detalles sobre la implementación, y si piensan que es un ejemplo aislado, vean todos los juegos que hay en esta colección hechos a puro Javascript.