jueves, 10 de febrero de 2011

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

http://www.flickr.com/photos/mightyohm/3986677172/

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.

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.

 

viernes, 4 de febrero de 2011

Agiles @ Buenos Aires: Coding Dojo

Coding DojoEl 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.