Probando aplicaciones web con Zombie.js

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

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.

Mono en Android disponible para todos

Después de un tiempo bajo un programa beta limitado, el equipo de Mono ha abierto finalmente la versión preliminar de MonoDroid para todo el mundo.

Con esta nueva versión preliminar, además, agregaron soporte para desarrollo en Mac OS utilizando MonoDevelop con el AddIn corespondiente.

Mono en Android instala la máquina virtual de Mono, con una versión reducida de las bibliotecas conteniendo sólo lo que tiene sentido en un dispositivo Android.

Además de permitir de esta manera programar en C# en lugar de Java (el único lenguaje completamente soportado por Google en Android), MonoDroid incluye una adaptación completa de las APIs de Dalvik (la máquina virtual de Android) con una interfaz mucho más familiar para desarrolladores C#, incluyendo propiedades, eventos, tipos genéricos, y realizando conversiones de manera automática cuando es necesario.

Más detalles en el post de anuncio de Miguel de Icaza (en inglés).

Aprovechando que se ha liberado y agregaron soporte completo para Mac, les dejo unas imagenes capturadas tras actualizar mi entorno y probar la aplicación que viene como plantilla (estilo Hello, World).

Así se ve la solución y la actividad principal inmediatamente después de crear un nuevo proyecto Android:

Se puede hacer debugging en emuladores o dispositivos reales. El SDK de Android trae emuladores genéricos y se pueden generar otros para modelos específicos obteniendo el kit del fabricante para Android. Motorola, por ejemplo, los provee para mi Milestone y otros dispositivos con Android.

En la práctica es muchísimo más rápido probar contra el teléfono. La primera vez tarda un poco más porque instala el runtime, pero las siguientes va mucho más rápido. Los emuladores me dan la impresión de ser unas 5 o 6 veces más lentos (al menos que mi teléfono). La ventaja de los emuladores es que se pueden capturar más fácilmente las pantallas, como en el ejemplo debajo, que muestra uno genérico recién iniciado:

Y finalmente, la emocionante aplicación de ejemplo, funcionando en el emulador. Cada vez que tocamos el botón incrementa el número de clicks. No está tan mal para ser algo que el entorno  genera solo, sin tener que modificar un solo caracter:

 

Ronda de editores de texto para Mac

Un compañero de trabajo que desembarcó recientemente en territorio Mac me preguntaba el otro día sobre editores de texto, que es algo que todo programador necesita tener a mano. Como mencionan en el clásico libro de nuestra profesión, The Pragmatic Programmer, así como un buen leñador invierte gran parte de su tiempo afilando el hacha, que es lo que lo mantiene productivo, nosotros deberíamos siempre seleccionar con cuidado y luego dominar esta herramienta que usamos permanentemente. Incluso es difícil quedarse con un único editor de texto (sin contar además con una IDE, en muchos casos).

En particular soy más amigo de los buenos editores que de las IDEs, así que después de comentarle brevemente a mi amigo algunos de los editores que uso, decidí preparar este post con una lista (incompleta) de los más interesantes que he visto o usado en OS X.

Cuando llegué ya estaba ahí: TextEdit

Este es el editor que viene como parte del sistema operativo, y aunque muchos no lo saben, este pequeño editor tiene algunas características interesantes, como soporte no solo para ASCII plano sino también para Unicode UTF-8 o 16, Rich-Text Format (RTF), .doc ó -docx (si, formato Word XML).

Otro detalle interesante es que los fuentes de este editor están incluidos como muestra en la IDE de Mac OS: XCode.

El más popular: TextMate

TextMate es el editor más popular en este ambiente, basado en mi propia experiencia, incluso a pesar de ser un producto comercial.

Algunos de los motivos más importantes detrás de su éxito son su flexibilidad y extensibilidad, a través de los bundles: extensiones que permiten no sólo dar soporte a coloreo de sintaxis y operaciones específicas para cada lenguaje, sino también para automatizar operaciones alrededor del sistema operativo, los browsers, compiladores y demás piezas de infraestructura.

Un buen ejemplo de esa flexibilidad es el meta-bundle llamado GetBundles que permite actualizar los cientos de bundles disponibles y que la comunidad sigue generando activamente. Y la comunidad, casualmente, es otra característica muy importante. Basta con buscar en GitHub para ver la cantidad de extensiones, y ver que hay bundles como el de Ruby mantenidos por gente como David Heinemeier Hansson, el creador mismo de Ruby on Rails.

Fuerte en Proyectos: BBEdit

Este es otro editor sumamente popular, que parece haber sido sobrepasado por TextMate sobre todo por el soporte para Ruby/Rails. Sin embargo, BBEdit sigue siendo un favorito, también comercial, aunque casi al doble de precio de TextMate.

El fuerte de este editor, además de muchas características avanzadas similares al anterior, es en el manejo de proyectos, que permite utilizar múltiples carpetas, filtros por tipos de archivo, etc. En el ambiente C++ y Objective C sigue siendo muy utilizado.

Todoterreno: UltraEdit para Mac

Para quienes usan o usaron este poderoso editor comercial en Windows o Linux, ahora está disponible la versión para Mac, lo que puede darles la ventaja de la familiaridad y supuestamente portabilidad de macros y algunas extensiones.

Para quienes no lo utilizaron antes, la interfaz, aunque re-escrita en Cocoa, parece aun un poco extraña en Mac OS, notándose su procedencia de ora plataforma.

Sus características más famosas son macros, poderosa búsqueda y reemplazo incluso entre múltiples archivos, y la capacidad de trabara directamente sobre servidores via FTP.

Clásico de clásicos: Vim y Aquamacs

Como Mac OS es un Unix maquillado, Vi / Vim siempre fueron opciones importantes y gratuitas. Este clásico editor tiene una personalidad fuerte y no es para quienes están acostumbrados a menúes o interfaces gráficas. Es super-eficiente en el uso de combinaciones de teclas pero para mucha gente parece una vuelta atrás en el tiempo.

Hace poco publiqué un post con una cartilla para facilitar el uso. Mi recomendación es darle una oportunidad, sobre todo si uno es más usuario de un editor que de una IDE.

Por supuesto, respetando la diversidad religiosa, también hay una versión de Emacs para Mac OS (modo totalmente regular estilo texto) o una versión más adaptada, con fonts, menúes y uso de las clásicas secuencias de teclas de Mac, llamada Aquamacs.

Más opciones gratuitas interesantes: Kod y TextWrangler

Para cerrar, otro par de editores gratuitos muy buenos:

Sobre Kod escribí un post reciente, así que no voy a repetir mucho.

TextWrangler es como el hermano menor, freeware (no de código abierto) de BBEdit, y funciona muy bien. Soporta múltiples lenguajes con coloreo de sintaxis y acceso directo al shell del sistema operativo, extensibilidad y varias otras funciones interesantes.

 

Como cierre, repito que la lista está obviamente incompleta, y si les parece que hay otras opciones buenas o quieren destacar alguna característica buena o mala, o sus experiencias, los invito a dejar comentarios.

Finalmente, recomiendo a cualquier programador invertir un tiempo en probar algunos de los editores, y después de selecionar uno o dos, dedicarle un poco más a aprenderlo a fondo. Ahorrar tres o cuatro horas de investigación del poder de un editor puede significar perder ese mismo tiempo todos los meses haciendo cosas que podemos automatizar.

 

Raros Lenguajes Nuevos: Ela

Sobre el final del año inicio una serie que espero continuar desarrollando durante el incipiente 2011: Raros Lenguajes Nuevos.

La idea es dedicar cada tanto un post a algún nuevo lenguaje que aparezca en el radar, no necesariamente de los esotéricos, si no generalmente aquellos con posibilidades interesantes de ganar adopción o servir de campo experimental en ciertas áreas, aportando ideas que se incorporen en otros lenguajes más populares, como ocurre todo el tiempo en este campo.

 

Ela

En palabras de su creador, Vasily Voronkov: "Ela is a strict dynamically typed impure functional language" (un lenguaje funcional impuro, estricto y dinámicamente tipado). Y está implementado para correr sobre el CLR de .NET ó Mono. Analicemos estas características:

Dinámico se refiere a que los tipos se definen y verifican en tiempo de ejecución, no de compilación, y estricto se refiere a que las asignaciones (por omisión) no se difieren, sino que ocurren en el momento. Los tipos son además fuertes, es decir que no hay conversiones implícitas (no se pueden sumar números y strings, por ejemplo).

Exactamente al revés que en Haskell, que es funcional pero no-escricto (o lazy) por omisión, en Ela esta característica es opcional y debe ser explícita. Por ejemplo:

let x =(&2+2)
let y = x *2//La expresión '2 + 2' se evalúa recién en este momento

El motivo de esto es que Ela está diseñado para ser funcionalmente impuro, también al contrario de Haskell. Esto significa que un programa puede tener efectos colaterales, o más simplemente, mantener estado (usar variables). Los lenguajes funcionales puros solamente admiten constantes y funciones, y no hay estado variable, lo que permite muchas cosas interesantes, pero implica un enorme cambio de mentalidad para cualquier programador que no proviene del mundo de las matemáticas.

Finalmente, la sintaxis general de Ela es relativamente parecida a ML (o el reciente F#), utilizando secuencias, líneas de ejecución y comparación de patrones. Un ejemplo para asustarse (aunque en realidad no es difícil de entender después de algunas reglas básicas, sería:

let filter f x::xs | f x  = x :: filter f xs;
                   |else= filter f xs;
           _ []           =[]

Esto define una función filter que recibe un predicado, es decir una función que evalúa cada elemento en una lista para filtrarla. El uso de esta función para filtrar los elementos mayores que 5 es tan sencillo como:

let filter' = filter (>5)

Como siempre en programación funcional, se trata principalmente de describir el resultado a obtener más que detallar los pasos a seguir para obtenerlo, y Ela sigue bien esta tradición.

¿Qué diferencia a Ela de otros lenguajes?

Además de características funcionales típicas como funciones anónimas (lambdas) y closures, y aplicación parcial.

Sin embargo, Ela toma un decisión interesante respecto de cualquier otro lenguaje (que yo haya visto), y es que toda función debe recibir un único parámetro. No cero ni más de uno. Esto que parece bastante restrictivo se resuelve en forma general haciendo que una función reciba otra, generando encadenamiento, como en:

let res = sum 23// por supuesto, devuelve 5

pero no recibe dos parámetros, sino que sum recibe como entrada 2 y devuelve una función anónima que recibe como parámetro el 3. Veamos la definición de sum:

let sum x y = x + y

Esta es una técnica conocida como currying(que toma su nombre del matemático Haskell Curry, al igual que el lenguaje Haskell que toma la otra mitad). En programación funcional esta es una técnica muy usual para componer funciones, pero no es obligatoria.

A primera vista parece raro, si, pero el hecho de pensar que toda función recibe un único parámetro cambia por completo la sintaxis del lenguaje, ya que no hacen falta más paréntesis ni separadores, y esto tiene un montón de consecuencias interesantes de analizar (y obviamente plantea varios desafíos).

Otra interesante decisión de diseño es que todos los operadores son identificadores únicos, con lo que no hay posibilidad de utilizar un símbolo con diferente semántica en dos contextos. Por ejemplo, el operador "-" (signo menos) significa resta, por lo que el operador unario para indicar un número negativo es "--" (por ejemplo: --2). Raro otra vez, pero hay algunas razones válidas relativas a la capacidad de validación de expresiones en cualquier contexto.

Es importante destacar que aunque el intérprete es totalmente funcional y puede ser embebido en código .NET o Mono, el proyecto está aún en nivel experimental.

Para los interesados, la documentación más completa por ahora es la Wiki en Google Code (en inglés), o este artículo del autor (en ruso).