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.