Recursos gratuitos para empezar con Node.js

A través de un tweet de mi amigo Juancho Ladetto encontré este post de ReadWrite Hack comentando una series de recursos sobre Node.js.

Para los que no saben o no recuerdan de que se trata Node, hice una breve introducción en un post anterior, y los demás sabrán que es una de las tecnologías que me parece más prometedora entre las últimas apariciones, y creo que este año va a crecer muchísimo.

Uno de los recursos más interesantes es este libro (en progreso) de Tom Hughes-Croucher que O'Reilly, que puede leerse (en inglés) por ahora libremente en su versión previa (e incluso colaborar en la revisión).

El libro por ahora cubre los conceptos fundamentales, con buenas explicaciones incluyendo simpáticos dibujos como este:

También cubre las interfaces de programación principales como el EventEmitter, la sintáxis de Callbacks, servidores y clientes HTTP, peticiones GET, POST y PUT, el objeto ClientResponse y el uso de URLs, query strings, Streams de lectura, el FileSystem y Buffers.

Está iniciado también el capítulo cubriendo interfaces de ayuda, por ahora solo DNS, y el de documentación general que cubre varias clases, el depurador, marco de pruebas unitarias, sub-procesos, consola de comandos REPL, y mucho más (todo esto en formato de referencia).

Otro recurso interesante y en progreso es la guía de Felix (también en inglés), que cubre varias partes similares pero a distinta profundidad y con otro enfoque, y tiene una sección dedicada a "convencer al jefe" que apunta a resaltar las características principales de Node para poder explicarlo a otros.

Page Speed online: una nueva herramienta para medir el rendimiento de sitios web

Parte del desarrollo de sitios web de calidad es hacer un análisis correcto de su rendimiento, sobre todo desde temprano, utilizando recomendaciones y técnicas modernas para asegurar un sitio correctamente optimizado. Esto no quiere decir ir en contra de la famosa máxima de Donald Knuth, quien nos ensenó que "la optimización prematura es la causa de todos los males" en programación.

Cualquier sitio web público con una expectativa mínima de tráfico debería responder a una línea base para garantizar una buena experiencia a sus usuarios, y hoy día no necesitamos aplicar técnicas extravagantes o perder mucho tiempo para esto, sino más bien aplicar recursos estándares y sencillos, disponibles en todas las plataformas.

Entre las herramientas para realizar el análisis de rendimiento frecuentemente mencionamos la clásica Firebug (y su plugin YSlow) para Firefox, y Page Speed para Firefox o Chrome. Ambas son excelentes y complementarias, cada una con sus fortalezas, pero ahora Google aporta una alternativa más que puede ser útil en muchas circumstancias: Page Speed online.

A diferencia de las anteriores, en lugar de un plugin, este es un servicio en línea que realiza el mismo tipo de análisis, con lo que podemos ejecutarlo desde cualquier navegador, pero sobre todo puede orientar el análisis sobre navegadores desktop (corriendo en una computadora) como sobre navegadores móviles (sobre todo corriendo en smartphones), para los que incluye algunas reglas específicas como la de eliminar redirecciones en la página inicial que no puedan mantenerse en cache, o reducir la cantidad de Javascript durante la carga de la página. Estas son todas situaciones que no son tan problemáticas en otro ambiente, pero en un teléfono que tiene usualmente un ancho de banda y procesamiento limitados, hacen mucha diferencia.

Veamos un ejemplo. Realicé un análisis para navegadores desktop sobre un sitio popular como Twitter, ingresando la dirección:

Y el resultado dio 77 sobre 100 (bastante bueno). El detalle es el siguiente:

Prioridad alta: Estas son reglas que pueden generar mayor impacto en el rendimiento del sitio y que uno debería atacar inicialmente. En el caso de Twitter sólo queda en este nivel la regla: Combinar imágenes como sprites CSS.

Prioridad media: En el siguiente nivel las reglas son: entregar imágenes a escala, optimizar imágenes y minificar Javascript.

Prioridad baja: En este nivel ya hay unos cuantos más. Si quieren pueden ver el informe completo.

Para terminar ejecuto el mismo análisis para la versión móvil de Twitter:

... y: ¡Oh, sorpresa! me da 100/100. No es de extrañar que Twitter esté muy optimizado para su acceso desde móviles. Así que pruebo con otro servicio que tiene buena tradición en cuando a rendimiento (es donde se empezó a trabajar en estas áreas): http://news.yahoo.com/

El resultado para móviles es de 79/100, que es bastante bueno.

No hay reglas de alta prioridad para atacar, y en las de media, ambas son muy específicas para teléfonos: diferir la interpretación de Javascript y hacer que las redirecciones de la página de inicio puedan mantenerse en cache.

Como siempre, lo importante de estos análisis es leer con atención la información acerca de cada regla, entender de qué se trata y que prácticas tenemos que adoptar de manera permanente para que no vuelva a producirse.

 

Yoseki Coding Dojo en Kleer

Siguiendo con la buena costumbre de los Coding Dojo, mis amigos de Kleer vienen organizando algunas de estas sesiones abiertas para escribir código entre muchos, como un ejercicio de trabajo en grupo, programación y entretenimiento. Ellos ya tienen un formato bastante definido para estas sesiones, llamadas Yoseki Coding Dojo en las que se van variando el lenguaje y el entorno.

El martes de esta semana me sumé a esta actividad, me encontré con otro amigo asistiendo, Carlos Peix, y me di el gusto de compartir con él la primera ronda de pair programming.

Esta vez trabajamos con Java/Eclipse. Parece que el próximo Yoseki será en Ruby, y si me dejan haremos uno en Javascript.

El problema que planteó el facilitador de turno, Pablito "Pablitux" Tortorella: escribir un contador de puntos de tenis. A continuación dejo las premisas generales para quien quiera practicar este Code Kata. Recuerden que la idea es realizar el ejercicio utilizando TDD, y puede hacerse como una Kata individual, o en un Dojo con varias personas.

La idea es hacer un contador de puntos de tenis. No soy experto en tenis y no me quedaron a mano los detalles que Pablo iba mostrando como historias de usuarios, pero creo que todos sabemos un poco cómo se cuenta: "15 - 0", "30 - 0", "40 - 0"; después los sets; detalles de convención como "30 iguales", etc.

Les dejo debajo los primeros tests (a propósito no dejo todos por si alguno quiere intentar por su lado). Quienes quieran pueden ver los fuentes completos de los tests y de la implementación.

Primeros tests:

package la.kleer.yoseki.tenis.tests;

import junit.framework.Assert;
import la.kleer.yoseki.tenis.Tablero;

import org.junit.Test;

public class TenisFixture {
   
   @Test
   public void tableroTituloConDosJugadores()
   {
      Tablero t = new Tablero("Martin", "Carlos");
      Assert.assertEquals("Martin vs Carlos", t.getTitulo());
   }

   @Test
   public void tableroTituloConDosJugadoresAlReves()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      Assert.assertEquals("Carlos vs Martin", t.getTitulo());
   }
   
   @Test
   public void tableroPuntajeInicial()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      Assert.assertEquals("0 - 0", t.getPuntaje());
   }
   
   @Test
   public void puntosJ1()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador1();
      Assert.assertEquals("15 - 0", t.getPuntaje());
   }
   
   @Test
   public void puntosJ2()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador2();
      Assert.assertEquals("0 - 15", t.getPuntaje());
   }

   @Test
   public void puntosJ1_J1()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador1();
      t.puntoJugador1();
      Assert.assertEquals("30 - 0", t.getPuntaje());
   }

   @Test
   public void puntosJ1_J2()
   {
      Tablero t = new Tablero("Carlos", "Martin");
      t.puntoJugador1();
      t.puntoJugador2();
      Assert.assertEquals("15 iguales", t.getPuntaje());
   }

   // Aquí van más tests

}

Finalmente, les dejo una foto del grupo en acción: