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).

 

Node.js: simplicidad y eficiencia

Desde hace tiempo tenía pendiente escribir sobre Node.js (Node para los amigos). Hago una breve introducción primero para que se entienda por qué me parece importante:

Hace ya un par de años escribí un post hablando del resurgimiento de Javascript como lenguaje en todos lados, y la tendencia que veía entonces está empezando a ser notoria este año y creo que se va a afianzar el próximo.

El primero paso hacia un mayor uso de Javascript del lado del servidor fue la aparición de CommonJS como iniciativa para unificar detalles de las diferentes implementaciones, y es algo que está ganando bastante aceptación, especialmente en el soporte para los modules.

Node inició fuera de este estándar, pero luego se adaptó a CommonJS, y es un motor de Javascript del lado del servidor fuertemente basado en eventos y orientado principalmente a un manejo eficiente de comunicaciones en red. Se basa a su vez en el motor de Javascript V8, creado por Google y utilizado en Chrome, pero publicado como código abierto. Node también es código abierto con ncia MIT.

Lo notable de Node es que aprovecha la característica de Javascript como lenguaje y cultura, que a diferencia del resto del universo de la programación, siempre vio como algo natural el hacer llamadas no-bloqueantes.

Veamos la diferencia. Mientras en otros lenguajes cosas triviales como una consulta tienden a escribirse naturalmente como:

resultado = query( 'select * from Tabla');

en Javascript lo usual sería expresar esto como:

query( 'select * from Tabla', function (resultado) {
   // y aquí vemos qué hacemos con el resultado...
});

¿Cuál es la diferencia principal? Que la primer manera de llamada es bloqueante; es decir que mientras el resultado de la consulta no llega, el programa está detenido. En el segundo ejemplo, la llamada es no bloqueante, por lo que el resultado no se asigna a una variable sino que se pasa como parámetro a un callback (una función que será llamada al terminar la ejecución de la consulta, en este caso). En el ejemplo el callback se define en el mismo lugar para abreviar, pero podría ser una función definida en otra parte.

Lo importante de esta diferencia es que el estilo bloqueante de llamadas consume muchísimos recursos mientras se produce esa espera, que al involucrar acceso a disco o recursos de red puede ser por un tiempo importante, sobre todo al considerar una ambiente de alta concurrencia.

El modelo no-bloqueante o asincrónico, permite además manejar el procesamiento de esos callbacks dentro de un bucle de atención de eventos en lugar de necesitar threads separados para cada instancia. Y los threads son costosos y cuello de botella a la hora de escalar con mucha concurrencia.

Node aprovecha esta diferencia cultural de Javascript y brinda un entorno donde podemos realizar la mayor parte de las conexiones de red en forma no-bloqueante.

Veamos un ejemplo rápido que puede ilustrar la sencillez y eficiencia de Node en acción:

http = require('http');
Buffer = require('buffer').Buffer;
mega = 1024 * 1024;
bloque = new Buffer(mega);
for (var i=0; i<mega; i++) bloque[i] = 65; // Letra "A"
// SERVIDOR
http.createServer( function (pedido, respuesta) {
   respuesta.writeHead(200);
   respuesta.end(bloque);
}).listen(8000);

Las últimas cuatro líneas son la versión más básica de un web server en Node. ¿Sencillo, verdad?

Las primeras dos líneas utilizan el mecanismo de CommonJS de inclusión de módulos. El módulo HTTP permite acceso completo al protocolo como cliente o servidor y soporta cosas interesantísimas como la capacidad de devolver contenido como streaming. El módulo Buffer se utiliza para preparar bloques de datos binarios o crudos, no Unicode.

Las siguientes tres líneas solamente crean ese bloque de 1 Megabyte exacto de largo.

Lo más interesante son esas últimas cuatro (una sola sentencia, como se puede apreciar). Allí creamos una instancia del servidor web que atenderá en el puerto 8000 y al recibir cualquier pedido (HTTP request) responderá el bloque lleno con 1 Mb de letras A con status Ok (200) en la cabecera.

Pero lo más interesante es la manera en que se comporta el servidor si lo sometemos a una prueba de alta concurrencia. En pruebas con 100 requests concurrentes, Node llega a responder más de 800 requests por segundo (respondiendo 1 Mb para cada uno), lo que es un rendimiento asombroso. Estas características brillan en servicios de chat, presencia, colaboración o cualquier otro escenario donde típicamente deban soportarse muchas conexiones concurrentes.

Node tiene muchas otras ventajas, pero espero que hasta acá alcance para interesarlos. Lo ideal para conocer más sobre Node, además del sitio oficial, es la comunidad de artículos sobre usos y extensiones How to Node.