Run Web Camp en Buenos Aires

El 15 y 16 de marzo la gente de Microsoft Argentina estará presentando este evento que es parte de una gira internacional sobre desarrollo web dentro de su plataforma.

Es una pena que el sitio del evento parezca estar hecho por gente que no sabe mucho del tema en si, e insiste en publicar el programa como una imagen, haciendo la página muy poco accesible. Para beneficio de quienes no puedan leer una imagen y quieran enterarse de qué temas se presentarán, les dejo un resumen del temario.

Lo mejor del evento para mi es que participan muchos amigos. No se asusten por verme como orador, Daniel Laco que presentará conmigo se va a encargar de levantar el nivel de la charla.

Dia 1 (martes 15 de marzo) - Palais Rouge, Jerónimo Salguero 1441

09:00 Desayuno y Registración

09:30 Bienvenida (Eduardo Mangarelli - Director Regional de Nuevas Tecnologías de Microsoft)

09:45 Keynote: ASP.NET MVC (Phil Haack - Program Manager de ASP.NET MVC)

10:45 Presentando WebMatrix (Miguel Sáez, Programa Desarrolladores de Microsoft)

11:30 break

11:45 Acceso a Datos y Modelado con Entity Framework (Daniel Laco y quien escribe)

12:30 Un cambio de Vista en MVC: Razor Syntax (Drew Robbins)

13:15 almuerzo

14:15 Internet Explorer 9 y HTML 5 (Matias Woloski y Johnny Halife)

15:00 Aplicaciones AJAX con MVC (Rodo Finochietti y Pablo Zaiden)

15:45 break

16:00 Funciones avanzadas con MVC 3.0 (Daniel Cazzulino y Julián Domínguez)

16:45 Administrando paquetes con NuGet (Phil Haack)

Día 2 (miércoles 16 de marzo) - Microsoft de Argentina, Bouchard 710, 4to piso

Nótese que este segundo día es de prácticas con instructor, y es importante llevar notebook.

09:00 Desayuno y Bienvenida

09:30 Apertura: Sesión conjunta

10:00 Sesión Asistida de Desarrollo (parte 1)

13:00 almuerzo

14:00 Sesión Asistida de Desarrollo (parte 2)

17:00 Elección de proyecto

18:00 Cierre

Instructores: Phil Haack, Drew Robbins, Diego Gonzalez, Angel "Java" López

Espero que nos veamos por allá.

Mejorando aplicaciones web con Chrome Developer Tools (video)

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.

Brunch: aplicaciones HTML5 desde los hombros de gigantes

"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.
• jQuery & Zepto.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.

 

Festejando los 20 años de Python con la versión 3.2

La mejor imagen de la celebración es el tweet de hace unos días del creador de Python, Guido van Rossum:

En nuestra industria 20 años parecen dos o tres generaciones de lenguajes, y Python sigue demostrando su relevancia y popularidad.

Mientras que la versión 2.7 será probablemente la última importante de la línea 2.x, la rama 3.x empieza a tomar más impulso.

Siguiendo la PEP 3003, que declaró una moratoria para los cambios en el lenguaje, no hay cambios sintácticos en esta versión tampoco, y las mejoras se concentran en librerías y portabilidad desde 2.x.

Algunas de las principales novedades son:

• mejoras en el módulo unittest (varias provenientes del amigo Michael Foord)
• una nueva librería para programación concurrente
• un GIL mejorado que reduce la contención (uno de los temas más problemáticos de Python en su historia)
• manejo extendido de mails
• mejor soporte para SSL incluyendo contextos y comparación de certificados
• un módulo para acceder a información de configuración
• mejoras al depurador pdb

Pueden leer (en inglés) el detalle completo de la versión, o la lista detallada de las novedades.

 

Ruby Enterprise Edition y las mentes detrás (video)

La gente de Phusion acaba de lanzar una versión actualizada de Ruby Enterprise Edition.

¿De qué se trata? Estos muchachos (Ninh Bui, Hongli Lai y Tinco Andringa) llevan bastante tiempo trabajando en Ruby on Rails, muchas veces en proyectos muy exigidos, y encontraron varios de los problemas más importantes de Ruby (1.8, básicamente) pero en vez de quejarse, con el mejor espíritu de la comunidad de código abierto, crearon un fork donde arreglaron varios de las principales preocupaciones del motor al usarlo en instalaciones de Rails de gran escala.

Para que quede claro, esta distribución está pensada para instalaciones en servidores, y sigue siendo código abierto y gratuito.

La diferencia principal contra el motor de Ruby 1.8 (aunque en 1.9.x muchos de estos temas mejoraron drásticamente) está alrededor del recolector de basura, que logra reducir el uso de memoria de las aplicaciones Rail en un promedio del 33%, y a la vez incluye un mecanismo optimizado de alocación de memoria que aumenta mucho el rendimiento.

Algunos de los usuarios más conocidos de esta distribución son el New York Times, Twitter, Shopify y 37signals (esta última la empresa de David Hienemeier Hansson, el creador de Rails).

Algo muy interesante es que todo esto se logró a través de pura ingeniería aplicada a mejorar proyectos existentes, y el equipo de Phusion lo usa como base de su trabajo de consultoría, pero lo comparte con la comunidad en general.

Dejo debajo el video de Hongli Lai explicando las optimizaciones que hicieron durante un Google Tech Talk (charlas que organiza Google para sus empleados y comparte en video con el resto del mundo).

Al video está en inglés, pero lo que puede resultar más complicado es seguir los detalles técnicos, que no son aptos para principiantes.

SADIO organiza la 40va edición de las JAIIO

(luego de un receso vacacional, este blog vuelve a la carga)

En estos días me llegó el boletín de SADIO, la sociedad decana de nuestra área en Argentina, con más de 50 años de trayectoria. Me parece una buena ocasión para hacer eco de una de sus principales actividades.

Este año volverán como siempre las jornadas argentinas de informática. La edición número 40 (arrancaron en 1961) se llevará a cabo del 29 de agosto al 2 de septiembre en la UTN de Córdoba, Argentina.

La descripción de las jornadas, según los organizadores mismos, es:

En sesiones paralelas se presentan trabajos que se publican en Anales, se discuten resultados de investigaciones y actividades sobre diferentes topicos, desarrollandose también conferencias y reuniones con la asistencia de profesionales argentinos y extranjeros. Las JAIIOs se organizan como un conjunto de simposios separados, cada uno dedicado a un tema específico, de uno o dos días de duración, de tal forma de permitir la interacción de sus participantes.

Como siempre hay amplia variedad de simposios, incluyendo:

• ASAI 2011 - Simposio Argentino de Inteligencia Artificial
• ASSE 2011 - Simposio Argentino de Ingeniería de Software
• AST 2011 - Simposio Argentino de Tecnología
• CAI 2011 - Congreso Argentino de AgroInformática
• CAIS 2011 - Congreso Argentino de Informática y Salud
• HPC 2011 - High Performance Computing
• JII 2011 - Jornadas de Informática Industrial
• JSL 2011 - Jornadas Argentinas de Software Libre
• JUI 2011 - Jornadas de Vinculación Universidad-Industria
• SID 2011 - Simposio Argentino de Informática y Derecho
• SIE 2011 - Simposio de Informática en el Estado
• SIO 2011 - Simposio Argentino de Investigación Operativa
• SSI 2011 - Simposio sobre la Sociedad de la Información
• WSegI 2011 - Workshop de Seguridad Informática
• EST 2011 - Concurso de Trabajos Estudiantiles

Para los interesados en proponer trabajos para cualquiera de estos simposios, ya está abierta la recepción, que cierra el 2 de mayo. Para comprender bien el proceso de presentación (necesario por el enorme volumen de presentaciones), lo ideal es seguir las instrucciones detalladas en la página de cada simposio (por ejemplo, la del de Ingeniería de Software). Implica crear primero credenciales individuales (si no se presentó un trabajo previamente en otras JAIIO), y luego hacer la presentación de la o las propuestas.

Dejo un breve video mostrando el mecanismo para la edición pasada, ya que el proceso sigue siendo igual.

 

 

[Video y Ejercicio] Agiles @ Buenos Aires: Coding Dojo

La semana pasada se realizó la reunión mensual de Agiles @ Buenos Aires, como anuncié en un post anterior.

No voy a repetir todo el detalle, sino a dejar el video de la introducción de Adrián Eidelman, y el arranque del ejercicio con el primer par frente a la computadora.

El resto se los ahorro porque son dos horas en las que no se llega a leer claramente el código y la conversación entre los pares no llega a distinguirse claramente. Es un tipo de actividad que requiere presencia directa para disfrutarla, y recomiendo que estén atentos si les interesa porque ya hay en marcha una iniciativa de Katayunos (desayunos entre tres o cuatro personas para practicar Code Katas), y cualquiera puede organizar algo así con sus compañeros de trabajo o de estudio.

Pero para que no se pierdan el total (aunque la gracia es el camino recorrido más que el punto final), dejo el ejercicio tal cuál como quedó resuelto durante la reunión (sin edición ni retoque), cortesía de Adrián. La plataforma y lenguajes son anecdóticos, pero en este caso se realizó en C# utilizando Visual Studio 2010 y NUnit como framework de testing.

Van primero los tests (un primer ejercicio puede ser tomar los tests y tratar de escribir el código sobre ellos):

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Moq;
using NUnit.Framework;
using NumerosRomanos;

namespace NumerosRomanos.Tests
{
    [TestFixture]
    public class Tests
    {
        Conversor conversor;

        Dictionary<int, string> valores;

        [TestFixtureSetUp]
        public void setUp()
        {
            conversor = new Conversor();
            valores = new Dictionary<int, string>();
            valores.Add(1, "I");
            valores.Add(5, "V");
            valores.Add(10, "X");
            valores.Add(50, "L");
            valores.Add(100, "C");
            valores.Add(500, "D");
            valores.Add(1000, "M");
        }

        [Test]
        [ExpectedException(typeof(ArgumentException))]
        public void El0ArrojaExcepcion()
        {
            int numeroArabigo = 0;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);
        }

        [Test]
        [ExpectedException(typeof(ArgumentException))]
        public void NumeroNegativoArrojaExcepcion()
        {
            int numeroArabigo = -1;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);
        }

        [Test]
        [ExpectedException(typeof(ArgumentException))]
        public void El4000ArrojaExcepcion()
        {
            int numeroArabigo = 4000;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);
        }

        [Test]
        public void El1DeberiaDevolverI()
        {
            int numeroArabigo = 1;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("I", numeroRomano);
        }

        [Test]
        public void El5DeberiaDevolverV()
        {
            int numeroArabigo = 5;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("V", numeroRomano);
        }

        [Test]
        public void El10DeberiaDevolverX()
        {
            int numeroArabigo =10;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("X", numeroRomano);
        }

        [Test]
        public void El2DeberiaDevolverII()
        {
            int numeroArabigo = 2;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("II", numeroRomano);
        }

        [Test]
        public void El3DeberiaDevolverIII()
        {
            int numeroArabigo = 3;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("III", numeroRomano);
        }

        [Test]
        public void El15DeberiaDevolverXV()
        {
            int numeroArabigo = 15;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("XV", numeroRomano);
        }

        [Test]
        public void El4DeberiaDevolverIV()
        {
            int numeroArabigo = 4;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("IV", numeroRomano);
        }
        [Test]
        public void El48DeberiaDevolverXLVIII()
        {
            int numeroArabigo = 48;

            string numeroRomano = conversor.ANumerosRomanos(numeroArabigo);

            Assert.AreEqual("XLVIII", numeroRomano);
        }

        [Test]
        public void RetornaValoreConocidos()
        {
        
            foreach(var i in valores.Keys)
                Assert.AreEqual(valores[i], conversor.ANumerosRomanos(i));

        }
    }
}

Y aquí está finalmente la implementación misma (para quienes quieran hacer trampa):

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace NumerosRomanos
{
    public class Conversor
    {
        List<int> valoresArabigos = new List<int> 
            {1,4,5,9,10,40,50,90,100,400,500,900,1000};
        List<string> valoresRomanos = new List<string> 
            {"I","IV","V","IX","X","XL","L","XC","C","CD","D","CM","M"};
    
        public Conversor()
        {
            valoresArabigos.Reverse();
            valoresRomanos.Reverse();
        }

        public string ANumerosRomanos(int numeroArabigo)
        {
            if (numeroArabigo<=0 || numeroArabigo>3999)
                throw new ArgumentException();


            string resultado="";

            while (numeroArabigo > 0)
            {
                foreach (var i in valoresArabigos)
                {
                    if (i <= numeroArabigo)
                    {
                        resultado += valoresRomanos[valoresArabigos.IndexOf(i)];
                        numeroArabigo -= i;
                    }
                }
            }

            return resultado;
       }
    }
}

IonRuby 1.1.2 - Ruby sobre .NET sigue en marcha

En un mensaje en la lista IronRuby-core, Jimmy Schementi anunció la publicación de IronRuby 1.1.2.

Aunque esta es una versión intermedia para corregir algunos temas menores, es una buena noticia ver que el proyecto sigue en marcha después de que Microsoft lo dejara por completo en manos de la comunidad, al liberar todos los fuentes como código abierto bajo licencia Apache 2.0.

Esta versión básicamente mejora la compatibilidad con Ruby 1.9.2 e incluso corta la compatibilidad con Ruby 1.8.6, lo que es una buena medida para seguir hacia adelante con menores dependencias. Si alguien necesita todavía compatibilidad con 1.8.6 puede seguir utilizando IronRuby 1.0.

Recordemos que tanto IronRuby como IronPython son ahora proyectos en los que Microsoft no participa más, quedando por completo bajo control de la comunidad, y liderados por Jimmy, Miguel de Icaza, Michael Foord, y Jeff Hardy.

El nuevo release mantiene las herramientas de integración con Visual Studio 2010, soluciona algunos problemas con la instalación de Gems, renueva por completo el parser (motivo de la decisión de soportar sólo 1.9.2) y arregla algunos problemas detectados en Windos Phone 7.

 

 

Video: Kata con Números Romanos (Ruby, 15 minutos)

Como comenté el viernes, ayer tuvimos la reunión mensual del grupo Agiles.org en Buenos Aires, dedicada a un Coding Dojo en el que practicamos un ejercicio entre la docena de asistentes, rotando de a pares y avanzando con TDD para resolverlo.

El ejercicio en si consiste en pasar de números arábigos (los que usamos todos los días) a números romanos. Esta antigua forma de numeración tiene la particularidad de ser un poco irregular con sus dígitos que restan antes de llegar a los múltiplos de 5 y 10, como en el caso del 4 (IV) y el 9 (IX).

Lo bueno de este ejercicio en particular es que es bastante corto y las reglas son conocidas por casi todo el mundo. En el Dojo de ayer (del que pronto espero publicar un video con al menos la introducción y algunos momentos) llevó bastante tiempo porque ibamos rotando entre gente con diferente grado de conocimiento de la plataforma y lenguaje elegido (Visual Studio y C#), el teclado era raro para todos (menos para el dueño), y para muchos era la primera vez con ejercicios de este estilo y/o TDD.

Mientras rotábamos practiqué el ejercicio varias veces por mi lado y sobre el final hice una versión bastante parecida a lo que obtuvimos entre todos.

Dejo el video para quien le pueda interesar, con las siguientes aclaraciones:

• La respuesta no es la única correcta. De las que obtuve, es una de las más concisas.
• Lo que grabé es lo que se considera un Kata: hice el ejercicio muchas veces y al final fluyó bastante. Dura 15 minutos incluyendo tiempo de escribir algunos comentarios que representan lo que iba pensando. Probé relatarlo pero el tiempo era más largo porque no puedo escribir el códido tan derecho.
• Como siempre, la elección del entorno es arbitraria. Esta vez lo hice en Ruby usando unit/test que es lo más básico. Hice un uno con Ruby/RSpec pero me parece que va a llamar más la atención el framework de BDD que el ejercicio. Si hay interés puedo publicar otras variantes.
• En un Randori Dojo, aunque el ejercicio es el mismo, la dinámica es totalmente diferente. Lleva mucho más tiempo pero el foco está más en la práctica de las interacciones y el juego de pares que en la técnica misma. Recomiendo mucho hacer las dos cosas. Los katas son ejercicios más individuales, los dojos como ensayos con una banda.
• Espero que les guste la música. Si no, pueden dejar el video mudo. Todo lo demás está en el código.

Cómo acelerar nuestras aplicaciones web

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:

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

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.

 

Agiles @ Buenos Aires: Coding Dojo

El grupo Agiles.org organiza actividades de varios tipos en muchos puntos de América Latina.

Esta comunidad surgió fuertemente tras la primera edición de la conferencia latinoamericana Agiles 2008, y a partir de ahí el grupo en Argentina quedó consolidado, realizando muchas actividades por todo el país (anunciadas en la página Agiles Argentina).

Específicamente en Buenos Aires, se efectúan reuniones todos los meses, que se anuncian en la página Agiles@BsAs.

La próxima reunión es el martes que viene, 8 de febrero, en las oficinas de Southworks (Perú 375, 1er piso).  [disclaimer: es donde yo trabajo]

Lo interesante de esta próxima reunión en particular es que va a ser un Coding Dojo (estilo Randori), facilitado por Adrián Eidelman.

En palabras del propio Adrián:

"Un coding dojo es una sesión de codificación centrada alrededor de un desafío de programación. El desafío es sumamente pequeño en alcance y -en la versión Randori de un coding dojo- la totalidad de la audiencia participa para completarlo. Básicamente la solución se construye utilizando una única computadora y un proyector, en donde los desarrolladores van rotando de a pares cada una cantidad fija y acotada de tiempo, dejando lugar a que otras personas de la audiencia continúen. El objetivo es aprender, enseñar y mejorar nuestras habilidades de programación compartiendo con otros desarrolladores de software en un ambiente relajado."

La actividad como siempre es totalmente abierta y gratuita pero requiere inscripción previa, y vale la pena decidirse rápido porque el espacio no es infinito.

Espero ver a muchos de ustedes la semana que viene, codeando, y espero poder capturar en video todo lo que se pueda de la actividad, para compartir con quienes no puedan asistir.

 

Programando en Windows Azure con el Maestro Angel "Java" López

En la última reunión VAN (Virtual Alt.Net) de Alt.Net Hispano, el Maestro presentó una profunda sesión sobre programación en la plataforma de cloud computing de Microsoft. Para quienes quieran saber más sobre este grupo, pueden leer este post previo.

En esta sesión, como siempre, registrada en video (disponible más abajo), el Maestro @ajlopez recorre los conceptos básicos de Windows Azure, el SDK correspondiente para poder programar aplicaciones para esa plataforma, las opciones de computación (roles web y roles de trabajo), y las alternativas de almacenamiento (tablas, blobs y colas).

Pero lo más jugoso es ver en acción la manera de programar, sobre todo a través de los ejemplos e ideas del Maestro, que sabe mantener el interés con buen nivel de detalles y muy buen humor.

Tras las sesión, hubo en la lista de Alt.Net hispano un mensaje de Eugenio Pace, Sr. Program Manager en Microsoft patterns & practices, que desde Redmond mandó felicitaciones por la sesión y aprovechó para puntualizar algunos detalles que Angel dejó planteados, para beneficio de los asistentes.

Antes de dejarles el video, aviso para todos los que estén interesados en profundizar en el tema y estén alrededor de Buenos Aires, que Angel va a dar un seminario gratuito de dos días sobre Azure, el 15 y 17 de febrero, en el Grupo de Usuarios Microsoft de Argentina.

Que lo disfruten:

Leisure Suit Larry en HTML5

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.

Meditación programática: Koans

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.