martes, 25 de mayo de 2010

La integración de la base de datos. Una cura definitiva para esta enfermedad crónica.

Martín Gargiulo Una colaboración de Martín Gargiulo (*).


Es muy común que los equipos de desarrollo trabajen sobre un ambiente de base de datos compartido. ¿Quién no ha sufrido las consecuencias de los desfasajes entre *la* base de datos y el resto del proyecto? ¿Quién no ha sido víctima –o victimario– de algún improperio cuando, en pleno desarrollo, un cambio en alguna propiedad u objeto de la base deja al resto del código pataleando en el aire?

Nunca, desde mis tempranos inicios, a través de diferentes proyectos en varias compañías, tuvieron estas cuestiones la suficiente importancia como para quitarle el sueño a nadie. Siempre, esto es lo realmente grave, parecieron ser lo normal. Estaba ante una enfermedad crónica.

Desarrollar implica agregar código, depurar, refactorizar y repetir estas operaciones un número de veces hasta obtener una determinada pieza de software. A nadie se le ocurre, hoy en día, que no se disponga de un sistema de control de código fuente, que permita a cada integrante del equipo trabajar localmente y luego, una vez concluida la construcción de la pieza, incorporar sus cambios al repositorio común.

Cada desarrollador debe trabajar en su propio espacio. Siguiendo esta premisa, ¿por qué la base de datos, siendo parte esencial del producto, no se incluye en él? ¿Por qué no es natural que cada desarrollador trabaje sobre su propio ambiente de base de datos?

Surge un problema. Si cada programador opera sobre su propio ambiente, ¿cómo obtienen los demás integrantes del equipo las modificaciones al esquema realizadas localmente? Del mismo modo que lo hace con el resto del código de la aplicación: mediante el repositorio de código fuente.

Por ello es indispensable que los scripts de base de datos estén incluidos en el controlador de código fuente, al igual que todo el resto del código. Es a través de estos scripts que se deben formalizar los cambios en la base que completan la programación de una pieza de software.

La base de datos, a diferencia de una pieza de código común, contiene estado (para eso está). Por eso, además del código para la creación de sus objetos, se deben tener en cuenta scripts de inserción de datos básicos para la aplicación (tablas paramétricas, tablas maestras) y, eventualmente, algún pequeño set de datos de prueba.

…continuará…


(*) Andrés dice: por fin, y luego de dos años de arrastrarme, alguien ha escuchado mis ruegos, dignándose a brindar… ¡una colaboración! Y en buena hora, que en este lugar ya se empezó a juntar el polvo. Esperemos que sea la primera de una larga serie y dé comienzo a una maratón de talentosos desarrolladores ansiosos por ayudarme a mantener vivo este humilde espacio (esperar es gratis, dicen).

jueves, 15 de abril de 2010

Frases: Lo que sobra.

[…] como verás, arquitectura y diseño es lo que sobra... sobra porque todos somos arquitectos y diseñadores y hacemos lo que se nos da la gana, no hay directivas.

Un amigo”, hablando sobre esas cosas lindas que tienen los sistemas.

miércoles, 31 de marzo de 2010

Frases: Liderazgo.

86283.strip.zoomLeadership is the art of trading imaginary things in the future for real things today”.

Dilbert es genial.

viernes, 19 de marzo de 2010

Jueguitos de Viernes: Home Sheep Home.

Home Sheep Home es un muy buen juego en el que tenemos que combinar las habilidades y propiedades de tres ovejas para ayudarlas a atravesar la pantalla.

home-sheep-home

Me hizo recordar bastante al Lost Vikings (que por cierto se pueden bajar en Abandonia).

Visto en Juegos Microsiervos.

jueves, 18 de marzo de 2010

Visibilidad.

Gran Proyecto (con mayúscula), muy “visible” para la gerencia de Megaempresa, vital para la subsistencia de NoTanGranPeroGranConsultoraOSoftwareFactory, y por tanto muy “visible” también para la gerencia de ésta última.

Desde nuestro punto de vista (de sistemas) no es más que otra aplicación de formularios que le pegan una y otra vez a una base de datos, más un sinfín de reportes que vienen a sacar lo que los formularios pusieron.

Otra gran, torpe, enmarañada, traicionera, e incansable generadora de un aburrido caudal de incidentes de fácil solución técnica, y que serían de fácil solución a secas si no fuera por el hecho de que más o menos la mitad de ellos contradice lo que indica la otra mitad.

Así que una horda de programadores armada con papel secante intenta contener ese río, resuelve uno y otro y alterna entre “A” y “no A” en un proceso que arroja tanta agua como recoge.

Hay otro caudal que lo alimenta, un caudal de programadores, analistas, managers y demás sacos de carne “recursos” que van pasando, pasando y pasando a ritmo creciente. Si no fuera por este otro caudal que aporta toda la energía desperdiciada en aquél ida y vuelta inútil el proceso descrito sería el santo grial del movimiento continuo.

Los gerentes, como esto es importante, están en contacto con “el equipo”, los conocen, interactúan con ellos más que con el resto. Es a esto a lo que se le llama “visibilidad” y que consiste en que, de vez en cuando, se abre un espacio en esos cielos y asciende alguno, (probablemente aquél con más habilidad para el alpinismo que para la programación) dejando al proyecto, que es realmente importante, en manos del resto que ahí queda, papel secante en mano (mientras el alpinista saluda desde lo alto).

Así es que, gracias a la “visibilidad” del proyecto los otros reman, reman y reman hasta que, hartos y sin esperanza, abandonan en busca de algún horizonte en donde sus entrenados brazos sean mejor recibidos. Aquellos en los que el entrenamiento no hace efecto y que por lo tanto carecen de otras expectativas (que los hay), esperan pacientemente su turno para el ascenso.

Unos y otros son reemplazados velozmente, así que eso que llamamos “equipo” (y que no es más que un fotograma de una película interminable) apenas puede acumular una muy vaga idea del negocio que el sistema viene a sostener, ya que el escaso conocimiento penosamente adquirido por prueba y error se va tan rápido como se acumula. Del negocio se sabe que es grande y millonario y que no es una verdulería ni un almacén de ramos generales, pero eso no alcanza para dividir las aguas y tomar la mitad de correcciones que corresponde para parar la rueda.

En fin… cualquiera que trabaje en sistemas un tiempo es expuesto a una de las más generosas fuentes de fina ironía que esta vida puede dar: el trabajo y, sobre todo, el trabajo en sistemas y, sobre todo, el trabajo “corporativo”. Si este tiempo es más o menos largo el sistémico, si sobrevive y lo sigue siendo (o mejor dicho, para sobrevivir y seguir siéndolo) habrá desarrollado un fino sentido de la ironía y del humor, o un cinismo a toda prueba, o todo eso junto. Por suerte algunos explotan genialmente esos efectos colaterales esas habilidades, y así tenemos a Dilbert (adivinen de dónde sacó Scott Adams la inspiración para sus personajes), o a Sinergia Sin Control, o al mayor repositorio de esfuerzo sin sentido y desperdicio de inteligencia jamás creado, TDWTF.

Porque lo más irónico de todo es que funciona y que buena parte de nosotros hemos vivido o viviremos de ello, y que es lo que termina financiando los juguetes (lenguajes, metodologías, herramientas, patrones, arquitectura) con los que nos entretenemos mientras, distraídamente, hacemos girar la rueda. En fin…

…que al mundo nada le importa
yira…
yira…

lunes, 15 de marzo de 2010

VS 2010: Crear versiones optimizadas (minified) de archivos javascript con T4 text templates.

Una de las vetas más productivas que encontramos al utilizar los Text Templates en Visual Studio 2010 tiene que ver con la posibilidad de acceder al modelo de objetos de Visual Studio (EnvDte).

Este modelo de objetos nos permite analizar e incluso modificar no sólo la estructura de archivos del proyecto que estamos construyendo (archivos y proyectos incluidos, referencias, propiedades…) sino también del código (namespaces, clases, propiedades, métodos, variables…).

Cierto es que es algo que ya podíamos hacer programando un plug-in o un diseñador, pero estas opciones conllevan cierta complejidad. Veremos, a través de este ejemplo, que el uso de T4 para las tareas que antes requerían ese tipo de soluciones simplifica mucho las cosas, si bien el resultado es un poco menos… elegante (que un diseñador, por ejemplo).

El ejemplo consiste en crear una plantilla T4 que recorra los archivos javascript de un proyecto y cree y agregue versiones optimizadas de ellos utilizando la librería Microsoft Ajax Minifier. Empecemos.

Crear una plantilla preprocesada.

Como ésta es una plantilla que podríamos reutilizar en varios proyectos, vamos a crear una preprocesada (Preprocessed Text Template) y ubicarla en una librería separada que luego podamos distribuir.

Así que comenzamos creando una solución de prueba (“T4Sample”), agregando un proyecto de tipo Class Library (“JavascriptCruncher”) y un proyecto de tipo Web Application (“SampleWebApplication”). En el proyecto de librería insertamos un nuevo ítem de tipo “Preprocessed Text Template” (“JavascriptCruncherTemplate”) y una clase en la que ubicaremos los métodos auxiliares que vayamos necesitando (“EnvDteHelper”). La solución debería quedar así:

JsCruncher01

Obtener una referencia a EnvDte.

El disparador de todo esto ha sido un excelente post de Oleg Sych, al que le vamos a pedir prestado el código para obtener la referencia al modelo de objetos de Visual Studio. Ubicaremos este código en nuestra clase auxiliar, como un método estático:

using System;
using System.Collections.Generic;
using System.IO;
using EnvDTE;
using Microsoft.VisualStudio.TextTemplating;

namespace JavascriptCruncher
{
    public class EnvDteHelper
    {
        public static Project GetProject(ITextTemplatingEngineHost host)
        {
            IServiceProvider hostServiceProvider = (IServiceProvider)host;
            if (hostServiceProvider == null)
                throw new Exception("Host property returned unexpected value (null).");

            DTE dte = (DTE)hostServiceProvider.GetService(typeof(DTE));
            if (dte == null)
                throw new Exception("Unable to retrieve EnvDTE.DTE");

            Array activeSolutionProjects = (Array)dte.ActiveSolutionProjects;
            if (activeSolutionProjects == null)
                throw new Exception("DTE.ActiveSolutionProjects returned null.");

            Project dteProject = (Project)activeSolutionProjects.GetValue(0);
            if (dteProject == null)
                throw new Exception("DTE.ActiveSolutionProjects returned null.");

            return dteProject;
        }
    }
}

Para que lo anterior funcione necesitamos referencias a las librerías “EnvDte” y “Microsoft.VisualStudio.TextTemplating.Interfaces.10.0”. Esta última (creo) no se incluye en la distribución del VS 2010. Si no la encuentran, pueden obtenerla bajándose el Visual Studio 2010 SDK.

Obtener todos los archivos javascript incluidos en el proyecto.

En el paso anterior obtuvimos una referencia al proyecto en donde corre el template. El próximo paso es obtener una lista de todos los objetos ProjectItem (una interfaz que representa cada archivo y carpeta en el proyecto) que corresponden a archivos javascript.

El proyecto está representado como una jerarquía de ProjectItems que debemos recorrer recursivamente. Necesitamos todos los archivos “.js”, pero excluyendo aquellos “.min.js”, entendiendo que éstos ya están optimizados (“minificados” podríamos decir maltraduciendo “minified”).

Agregamos entonces las siguientes funciones a nuestra clase EnvDteHelper.

public static List<projectitem> GetJsProjectItems(Project project)
{
    List<projectitem> jsProjectItems = new List<projectitem>();

    foreach (ProjectItem projectItem in project.ProjectItems)
    {
        GetJsProjectItems(projectItem, jsProjectItems);

        if (projectItem.Name.EndsWith(".js") && !projectItem.Name.EndsWith(".min.js"))
            jsProjectItems.Add(projectItem);
    }

    return jsProjectItems;
}

private static void GetJsProjectItems(ProjectItem parentProjectItem, List<projectitem> jsProjectItems)
{
    foreach (ProjectItem projectItem in parentProjectItem.ProjectItems)
    {
        GetJsProjectItems(projectItem, jsProjectItems);

        if (projectItem.Name.EndsWith(".js") && !projectItem.Name.EndsWith(".min.js"))                    
            jsProjectItems.Add(projectItem);                
    }
}
Optimizar o minificar los archivos.

Este es el momento (si no lo han hecho ya) de bajar e instalar el Microsoft Ajax Minifier y agregar una referencia a la librería ajaxmin.dll en el proyecto (JavascriptCruncher).

Ésta librería es muy simple. La clase ScriptCruncher contiene el método “Crunch”, que recibe el código javascript a optimizar (minificar) y una instancia de la clase CodeSettings con las opciones deseadas y devuelve el código minificado como una cadena.

Combinando lo visto en el punto anterior con esta librería, podemos comenzar a escribir el template propiamente dicho. Sería algo así (lo siguiente no es el template completo, sólo un ejemplo del avance hasta ahora):

EnvDTE.Project project = EnvDteHelper.GetProject(this.Host);
List<envdte.projectitem> jsProjectItems = EnvDteHelper.GetJsProjectItems(project);

ScriptCruncher cruncher = new ScriptCruncher();
CodeSettings crunchSettings = new CodeSettings();
crunchSettings.CollapseToLiteral = true;
crunchSettings.LocalRenaming = LocalRenaming.CrunchAll;	
crunchSettings.StripDebugStatements=true;

foreach( EnvDTE.ProjectItem item in jsProjectItems)
{	
	string itemFileName = item.FileNames[0]; 
	string jsCode = File.ReadAllText(itemFileName);
	string jsMinified = cruncher.Crunch(jsCode, crunchSettings);
	
	this.WriteLine(itemFileName);
	this.WriteLine(jsMinified);
	this.WriteLine("--------------------");	
}

El ejemplo anterior solamente muestra el código minificado. Pero tenemos que…

Crear un archivo con el código minificado y agregarlo al proyecto programáticamente.

Vamos a recurrir otra vez al bueno de Oleg Sych para ver cómo se lleva a cabo esta tarea. Mirando un poco sobre el código de su ejemplo llegamos a que agregar un archivo es tan simple como utilizar el método AddFromFile de la colección ProjectItems del objeto ProjectItem correspondiente al archivo javascript con el código original.

Como se ve, le pasamos el ProjectItem del archivo javascript original -que utilizará como referencia- y el código minificado. Lo único que hace es cambiar la extensión, grabar (o sobreescribir) el archivo minificado existente y agregarlo al proyecto (si es que no estaba ya agregado). Ubicamos este nuevo helper junto a los demás en EnvDteHelper

public static void SaveMinifiedCode(ProjectItem originalJsItem, string minifiedCode)
{
    string outputFileName = Path.ChangeExtension(originalJsItem.FileNames[0], ".min.js");
    File.WriteAllText(outputFileName, minifiedCode);

    ProjectItem parentProjectItem = originalJsItem.Properties.Parent;
    parentProjectItem.ProjectItems.AddFromFile(outputFileName);
}
Juntando las piezas en la plantilla.

Hasta ahora venimos trabajando sobre nuestra clase EnvDteHelper. Suelo recomendar esto ya que, por ahora, el soporte de Intellisense en las plantillas es bastante limitado. Es mucho más fácil, entonces, trabajar dentro de lo posible en estos helpers, que son clases comunes y silvestres, para luego juntar todo en el template en un último paso.

Una vez terminado el trabajo, la plantilla (“JavascriptCruncherTemplate.tt”) debe quedar así:

<#@ template language="C#" hostSpecific="true" #>
<#@ import namespace="System.Collections.Generic" #>
<#@ import namespace="Microsoft.Ajax.Utilities" #>
<#@ import namespace="System.IO" #>
<# 
EnvDTE.Project project = EnvDteHelper.GetProject(this.Host);
List<EnvDTE.ProjectItem> jsProjectItems = EnvDteHelper.GetJsProjectItems(project);

ScriptCruncher cruncher = new ScriptCruncher();
CodeSettings crunchSettings = new CodeSettings();
crunchSettings.CollapseToLiteral = true;
crunchSettings.LocalRenaming = LocalRenaming.CrunchAll;	
crunchSettings.StripDebugStatements=true;

foreach( EnvDTE.ProjectItem item in jsProjectItems)
{	
	string itemFileName = item.FileNames[0]; 
	string jsCode = File.ReadAllText(itemFileName);
	string jsMinified = cruncher.Crunch(jsCode, crunchSettings);
	
	EnvDteHelper.SaveMinifiedCode(item, jsMinified);
	this.WriteLine( "Processed: {0}", itemFileName);
}
this.WriteLine("done!");
#>

Para destacar: noten, en el tag inicial de la plantilla, que se especifica la opción “hostSpecific=true”. Esto es importante ya que le indica al generador que la clase resultante debe tener la propiedad Host. Si no lo hacemos obtendremos un error de compilación luego (¡me costó un rato darme cuenta de eso!). Vean también la declaración de los “import” (el equivalente a “using” en los templates).

El resto del código es simple dadas las herramientas que nos construimos:

  • obtenemos la referencia al proyecto,
  • luego la lista de ProjectItems que corresponden a archivos javascript.
  • Inicializamos un objeto ScriptCruncher y otro CodeSettings. Especificamos algunas propiedades que hacen al método de minificación (¿inventé una palabra?).
  • Luego recorremos la lista de ProjectItems (archivos javascript) y los vamos minificando utilizando el “cruncher”).
  • Y grabamos cada uno de ellos utilizando el helper que creamos (“SaveMinifiedCode”).
  • Utilizamos el output del template en sí como un log, escribiendo el nombre de cada archivo que procesamos. Este output es informativo y no se compilará.
Utilizar la plantilla en un proyecto.

Nuestra librería JavascriptCruncher está lista para ser utilizada en un proyecto de prueba. ¿Cómo la referenciamos?

Lo que debemos hacer es crear una plantilla en cada proyecto en el que querramos utilizar nuestro JavascriptCruncherTemplate que haga referencia a éste.

Hice un proyecto de prueba muy tonto, que tiene dos páginas iguales, una en la carpeta principal y otro en una subcarpeta (para verificar que el template genere ambos archivos). También agregué, en la carpeta principal un elemento de tipo “Text Template” (JavascriptCruncher.tt) que hará referencia al template precompilado que acabamos de crear. La estructura, en resumen, queda así:

JsCruncher02

JavascriptCruncher.tt referencia al template con este código:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".log" #>
<#@ assembly name="JavascriptCruncher" #>
<#@ import namespace="JavascriptCruncher" #>
<#
    JavascriptCruncherTemplate t = new JavascriptCruncherTemplate();
	t.Host = this.Host;
    this.Write(t.TransformText());
#>

Noten que simplemente crea una instancia de JavascriptCruncherTemplate, establece la propiedad host (recuerden nuevamente que es importante la propiedad hostspecific="true" de la primera línea) e invoca al método TransformText.

Referencia a la librería de templates utilizando la GAC.

La línea en JavascriptCruncher.tt de nuestro proyecto de prueba que hace referencia a la librería de templates que acabamos de crear es la que dice:

<#@ assembly name="JavascriptCruncher" #>

Puedo hacerlo de esta manera -sin indicar el path a la dll- ya que previamente incluí a JavascriptCruncher.dll y ajaxmin.dll en la GAC.

Hay otras opciones, como indica Oleg Sych en Understanding T4: <#@ assembly #> directive, pero la realidad es que por uno u otro motivo no pude hacer funcionar ninguna de ellas limpiamente, así que yo recomiendo ésta de agregar la librería a la GAC, ustedes experimenten por su cuenta y después me dicen.

Para esto primero hay que firmar JavascriptCruncher.dll, lo que es muy sencillo. En propiedades del proyecto vamos a la solapa “Signing”. Indicamos que firme el ensamblado y elegimos un nombre de archivo, más una password (opcional):

JsCruncher03

Tenemos que compilar y luego utilizar gacutil para registrar las dos librerías (la otra es ajaxmin.dll que es referenciada por la nuestra, y que tampoco está en la gac). En la línea de comandos de Visual Studio 2010 (“Menú de Inicio / Todos los programas / Microsoft Visual Studio 2010 / Visual Studio Tools / Visual Studio Command Prompt (2010)”):

gacutil -i "[path completo]\JavascriptCruncher.dll"

y no nos olvidemos de ajaxmin.dll, que también deberá estar en la GAC:

gacutil -i "[path completo]\ajaxmin.dll"

Probando el template.

Si corremos el template (grabándolo o utilizando la opción “Run Custom Tool” del menú contextual que aparece al hacer click con el botón de la derecha sobre el template) veremos cómo se agregan los archivos javascript minificados:

JsCruncher04

Código fuente del ejemplo.

Pueden descargarse el código fuente de este ejemplo desde el repositorio de desdesarrollo en google code (no se olviden de registrar las librerías en la GAC).

domingo, 7 de marzo de 2010

100 impresionantes publicidades al servicio de grandes causas.

Son 100 excelentes publicidades gráficas que apelan a imágenes chocantes para llamar la atención sobre el hambre, el cambio climático, la prostitución, abuso infantil, abuso de drogras y tabaco, entre otros graves flagelos.

Algunas de mis preferidas:

pubs-grandes-causes-054 pubs-grandes-causes-028 pubs-grandes-causes-082 pubs-grandes-causes-071 pubs-grandes-causes-068 pubs-grandes-causes-046

Éstas y el resto de las imágenes en resolución original, en la entrada de Le Blog de Bango.

(Gracias a @Cerebrado).

sábado, 6 de marzo de 2010

Visual Studio 2010: T4 Text Templates. Una introducción y recursos para empezar.

Creo que hace ya un par de semanas que ha salido Visual Studio 2010 RC. En el trabajo comenzamos a prepararnos hace ya un tiempo, utilizando la beta, y recién ayer actualizamos a esta última versión.

Mi percepción es que está sobre todo más estable. Han habido más correcciones que cambios, lo que es esperable dado el grado de madurez del producto. Por lo que hizo a mi trabajo en estas semanas (.Net MVC, mucho $(javascript), templates) noté muchas mejoras en el intellisense y la depuración en javascript -que hasta ahora era imposible de utilizar por lo limitado- aunque sigue sin ser la gran cosa comparado con FireBug, mi caballito de batalla.

Pero volvamos al tema del título. Las plantillas T4 para generación de código. De las novedades del 2010, ésta es la que más impacto real (y positivo) ha tenido en los proyectos, automatizando infinidad de pequeñas tareas tediosas y repetitivas.

Dije “pequeñas” porque, para las “grandes” tareas automáticas y repetitivas (generación de entidades, table gateways, row gateways, manejo de recursos de texto, etc.) teníamos ya infinidad de opciones, desde herramientas propias de .Net (como los recursos incrustados o los archivos .resx con sus clases asociadas), frameworks (Entity Framework, NHibernate), diseñadores (como los clásicos diseñadores de Datasets), plugins (no soy de utilizarlos, así que ni ejemplos puedo dar), hasta otros sistemas de generación automática de código, muy similares a T4 (CodeSmith).

Pero el tema con las herramientas mencionadas es que requieren mantenimiento, instalación, depuración, y una inevitable y nada despreciable curva de aprendizaje… pero sobre todo, que son pesadas y abarcativas (para utilizarlas razonablemente tenemos que seguir su paradigma, adaptando nuestro esquema desarrollo a éste en mayor o menor medida). Son muy buenas herramientas, pero nadie va a meterse con CodeSmith (sólo por dar un ejemplo), si no lo está ya utilizando para otra cosa, sólo para actualizar una lista de constantes o una enumeración de ciertos recursos.

Las ventajas de T4 en el Visual Studio 2010 tienen que ver justamente con ésto: están integradas al entorno de desarrollo y su sintaxis es muy intuitiva (a cualquier desarrollador le alcanzará con saber que “es como hacer una página .aspx” para empezar), perfectas para automatizar esas pequeñas, molestas, y usualmente numerosas tareas de copiar, pegar y modificar.

No voy a seguir con mucho detalle, ya que hay mucho (y mejor) escrito sobre el tema. Pero sí los voy a dejar con algunas recomendaciones de punto de partida:

T4: Text Template Transformation Toolkit: este post de Oleg Sych es un muy buen lugar para arrancar velozmente, y tiene además su propia (y extensa) lista de recomendaciones.

La documentación en MSDN es enrevesada y difícil de seguir, como toda la de Microsoft, pero está bueno pegarle una leída, no para empezar sino para conocer más en detalle.

Punto aparte y mención especial para este otro post de Oleg Sych, en el que hace referencia desde el template al modelo de objetos de Visual Studio (EnvDTE) que abre la puerta a posibilidades realmente interesantes.

miércoles, 3 de marzo de 2010

Tostitos: And Then There Was Salsa.

Mmmm… no parece la gran cosa. Pero eso es porque no lo han visto en su página original.

La verdad que un video así los hace merecedores de una compra al por mayor.

Visto en FayerWayer.

martes, 2 de marzo de 2010

.Net MVC + jQuery: manejo de excepciones. IV: el lado del cliente.

Finalizamos el post anterior de esta serie con la infraestructura necesaria para atrapar en javascript los errores y excepciones que puedan producirse del lado del servidor y “canalizarlos” hacia tipos conocidos con una codificación similar a la que utilizamos en c#.

Recordemos el ejemplo final. Teníamos, en javascript, una excepción base:

ExceptionBase = function (type, message) {
    this.Type = type;
    this.Message = message;
};

De la que luego derivamos dos excepciones más específicas, una para excepciones de negocio (la que arrojaría nuestro código en el caso de que una operación supere cierto monto permitido, por ejemplo):

ProgramException = function (message, netException) {

    this.Reasons = [];
    this.NetException = netException;

    if (typeof message != "undefined" && message != null)
        this.Message = message;

};
ProgramException.prototype = new ExceptionBase("ProgramException", "Operation Error");

y la otra para errores “fatales”, es decir todos aquellos que indican que la aplicación ha arribado a un estado no contemplado y que por lo tanto no puede seguir utilizándose (que ha cascado, vamos):

FatalException = function (message, netException) {
    this.NetException = netException;
    if (typeof message != "undefined" && message != null)
        this.Message = message;
}

FatalException.prototype = new ExceptionBase("FatalException", "Unexpected Error");

Para ver cómo utilizamos estas clases veamos nuestro ejemplo de llamada $.ajax, donde se establece la diferencia entre errores de negocio y fatales, lanzándose una excepción u otra dependiendo el caso. Más concretamente la sección “success” (lo siguiente es sólo el fragmento correspondiente a “success” dentro de la llamada a $.ajax):

  //... (etc) ....

  success: function (response, status, xhr) {

   //Exception handling.
   var responseStatus = xhr.getResponseHeader("RESPONSE_STATUS");
   var ex = null;
   if (responseStatus == "ApplicationException") 
   {
      var netEx = JSON.parse(response);
      ex = new ProgramException(netEx.Message, netEx);
      ex.Reasons = netEx.Reasons;
   }
   else if (responseStatus == "UnexpectedException") 
   {
      var netEx = JSON.parse(response);
      ex = new FatalException(netEx.Message, netEx);
   }

   if(ex!=null)
   {
      if (async)
         ShowException(ex)
      else
         throw ex;     
   }

   //...(continúa)...

Esta infraestructura de excepción base y derivadas sería una complejidad decorativa y sin sentido si no tomamos, en algún lugar del código, una decisión en base a ese tipo que tanto esfuerzo nos lleva determinar.

La diferencia entre una excepción y otra, desde el punto de vista del front-end, radica en cómo se le presenta al usuario. En nuestro ejemplo, esa tarea le corresponde a la función ShowException:

ShowException = function (exception) {
    //non-fatal exceptions
    if (exception.Type == "ProgramException") {
        var $messageBox = GetMessageBox();
        $messageBox.find("#MessageBoxReasons").html(exception.Reasons.join( "<p/>" ));
        var buttons = {};
        $messageBox.dialog({
            autoOpen: true,
            modal: true,
            buttons: { "Ok": function () { $messageBox.dialog("destroy"); } },
            closeOnEscape: true,
            title: exception.Message,
            close: function () { $messageBox.dialog("destroy"); }
        });
    }
    //fatal exceptions.
    else if (exception.Type == "FatalException") {
        var displayHtml = "<h1>" + exception.Message + "</h1>";
        var doc = window.top.document;
        doc.open();
        doc.write(displayHtml);
        doc.close();
    }
}

Esta función simplemente evalúa el tipo de excepción que recibe y toma las decisiones necesarias. En este ejemplo, muy simple y esquemático, tenemos dos secciones: la primera parte del if crea una ventana utilizando $.dialog para mostrar prolijamente las excepciones de negocio, y la segunda parte (luego del else) “rompe” la pantalla, limpiando todo el html y dejando solamente el mensaje de error.

La función auxiliar “GetMessageBox” simplemente construye el html necesario para mostrar el cuadro de diálogo:

GetMessageBox = function () {
    var top$ = window.top.$;

    var $messageBox = top$("#MessageBoxContainer");
    if ($messageBox.length > 0)
        return $messageBox;

    var $messageBoxContainer = top$("<div />").appendTo(top$("body"));
    $messageBoxContainer.attr("title", ""); 
    $messageBoxContainer.css("display", "none");

    var $innerTable = top$("<table/>").appendTo($messageBoxContainer);
    $innerTable.css("width", "100%");

    var $innerTableFirstRow = top$("<tr/>").appendTo($messageBoxContainer);

    var $innerTableFirstRowFirstCell = top$("<td/>").appendTo($innerTableFirstRow);

    var $messageBoxImage = top$("<img/>").appendTo($innerTableFirstRowFirstCell);
    $messageBoxImage.attr("alt", "");
    $messageBoxImage.attr("src", ""); //TODO: set src.

    var $innerTableFirstRowSecondCell = top$("<td/>").appendTo($innerTableFirstRow);
    $innerTableFirstRowSecondCell.addClass("messageBoxMessage");

    var $messageBoxMessage = top$("<div/>").appendTo($innerTableFirstRowSecondCell);
    $messageBoxMessage.attr("id", "MessageBoxMessage");

    var $innerTableSecondRow = top$("<tr/>").appendTo($innerTable);

    var $innerTableSecondRowFirstCell = top$("<td/>").appendTo($innerTableSecondRow);
    $innerTableSecondRowFirstCell.attr("colspan", "2");
    $innerTableSecondRowFirstCell.addClass("messageBoxDescription");

    var $messageBoxDescription = top$("<div/>").appendTo($innerTableSecondRowFirstCell);
    $messageBoxDescription.attr("id", "MessageBoxDescription");

    var $innerTableThirdRow = top$("<tr/>").appendTo($innerTable);

    var $innerTableThirdRowFirstCell = top$("<td/>").appendTo($innerTableThirdRow);
    $innerTableThirdRowFirstCell.attr("colspan", "2");
    $innerTableThirdRowFirstCell.addClass("messageBoxReasons");

    var $messageBoxReasons = top$("<div/>").appendTo($innerTableThirdRowFirstCell);
    $messageBoxReasons.attr("id", "MessageBoxReasons");

    return $messageBoxContainer;
};

Notarán que en la sección en la que se muestra el error fatal no se utiliza jQuery. En estas situaciones tenemos que evitar cualquier referencia externa al código que se está ejecutando, ya que sólo sabemos que ha ocurrido un error inesperado y no conocemos el estado de los demás componentes de la aplicación (como por ejemplo el plugin de jQuery. El error podría deberse a que el cliente no pudo descargar el script de jQuery). Aquí tenemos que esforzarnos en codificar, siempre dentro de lo posible, código que funcione en circunstancias extremas… y la mejor manera es que sea extremadamente simple.

Hasta aquí hemos abarcado las situaciones más comunes, y sólo en el marco de llamadas $.ajax al servidor:

  • Excepciones de negocio generadas del lado del servidor.
  • Errores producidos en del lado del servidor.

Parece una estructura demasiado compleja para, finalmente, hacer un “if” y determinar si rompemos la pantalla o mostramos un cuadro de diálogo, cubriendo apenas los dos puntos de arriba. Es un buen momento para repasar sus ventajas:

  • El código y la metodología en javascript es asimilable a lo que estamos acostumbrados a hacer en c#. Esto hace que la implementación sea natural,  fácilmente “explicable” y “recordable”. Verán que el resto de los puntos aquí presentados se aplican tanto a nuestra solución de javascript como al manejo de excepciones en c#.
  • Modularidad/Desacoplamiento: su único punto de anclaje con respecto al código correspondiente a la funcionalidad de negocio del sistema son los bloques try…catch en las funciones de manejo de eventos.
  • Reutilización: cualquier excepción que requiera el mismo tratamiento que las ya implementadas puede representarse con alguna de las clases ya existentes.
  • Extensibilidad: si queremos que el sistema reaccione a un nuevo tipo de excepción sólo tendremos que codificar “en las puntas”: allí donde se lanza la excepción (el lugar del throw) y allí donde se maneja (ShowException).

Por otro lado hay mucho para explorar de aquí en más. Recordemos que ni siquiera cubrimos los casos mínimos para una aplicación “aceptable”. Veremos que al contemplar más situaciones (errores y excepciones de lado del cliente, en la comunicación, etc.) y al integrar más funcionalidad (por ejemplo mostrando un mensaje de error especial en ambientes de desarrollo o testing), en el manejo de “pequeños detalles” y casos especiales, será cuando este esquema muestre sus verdaderas ventajas.

domingo, 28 de febrero de 2010

Frases: imaginación.

La mente es como un paracaídas, sólo funciona si se abre.

Albert Einstein (Buzzeado –nace un nuevo verbo- por Sebas).

jueves, 25 de febrero de 2010

Frases: olvidar, recordar, entender.

Díme, y olvidaré,
muéstrame, y recordaré
involúcrame, y entenderé.


Tell me, and I will forget,
show me, and I may remember,
involve me, and I will understand.

Confucio (450 a.C.).

miércoles, 24 de febrero de 2010

Simulador BitTorrent.

Un simulador o visualizador del funcionamiento de una red p2p, en este caso bajo el protocolo BitTorrent. Podemos agregar peers y seeds a voluntad (la visualización aguanta bastante bien una buena cantidad de nodos) y removerlos (aleatoriamente). Está hecho en javascript, por cierto, aunque –dice la página, no lo probé- no funciona en IE.

bitTorrent

Me entretuve bastante dejando un solo seed con un montón de peers y viendo cómo de a poco la red se saturaba de paquetes.

Visto en Microsiervos.

lunes, 22 de febrero de 2010

.Net MVC + jQuery: manejo de excepciones. III: Atrapar errores del lado del servidor y comunicarlos controladamente al cliente.

[Continuación de .Net MVC + jQuery: manejo de excepciones. II: El problema.]


works-on-my-machine Espero que se haya entendido el planteo desarrollado en los posts anteriores de esta serie (preguntar es gratis, de cualquier manera)… lo que sin duda ha quedado claro es que el problema es retorcido.

Lo que sigue ahora es mi resolución del tema, más que perfectible por cierto (si alguien tiene sugerencias…), pero lo suficientemente funcional y probada como para ostentar orgullosamente el sello que he aplicado a esta entrada.


El primer paso es poder diferenciar, del lado del cliente, si el error o excepción se produjo durante la ejecución del código que procesa una respuesta o si la comunicación en sí fue fallida.

La importancia de lo anterior radica en que en el primer caso manejaremos la excepción del lado del servidor y podemos devolver al cliente información detallada y en un formato conveniente sobre cómo proceder:

  • si es un error de sistema o una excepción de negocio o un error de validación, si mostrar información detallada o no, si bloquear la aplicación y obligar al usuario a reiniciar (o a joderse), etc.
  • si es un error en la comunicación el cliente deberá tomar sus propias decisiones, de acuerdo con la información que posea en ese momento, pero ya contamos con un dato fundamental: la operación no llegó al servidor, por lo que podemos estar seguros de que nada ha sucedido “del otro lado”.

Recordemos que de forma predeterminada el servidor devolverá un error 500 y el código HTML de la pantalla de error asignada a ese código (por defecto aquella tan bonita de .Net con las letras en rojo catástrofe y el cuadro amarillo con detalles, más las inútiles indicaciones que todos conocemos). Esto no es precisamente un formato fácil de interpretar desde el código a la hora de tomar decisiones en el front-end.

Necesitamos interpretar desde el código la excepción porque tenemos que tener en cuenta que muchos tipos de errores “de aplicación” diferentes. Cada situación puede requerir diferentes propiedades en el objeto Exception para transmitir la información relevante del caso. Consideremos por ejemplo:

public class ShowCaseException : ApplicationException
{
   private List<string> reasons = new List<string>();

   public ShowCaseException()
      : base() { }

   public ShowCaseException(string message)
      : base(message) { }

   public ShowCaseException(string message, Exception innerException)
      : base(message, innerException) { }

   public List<string> Reasons
   {
      get { return reasons; }
   }
}

La excepción anterior contiene una propiedad extra (“Reasons”) con una lista de mensajes para presentar al usuario. Esto es algo que suelo utilizar bastante, ya que si durante una operación se producen varios problemas de validación es bueno presentárselos al usuario todos juntos y no solamente el primero y obligarlo a resolverlo antes de probar de vuelta y encontrarse con otro y así, multiplicando la cantidad de intentos.

Pero no podemos tratar con cada tipo de excepción en particular, viendo en cada caso qué información devolver y cómo. Una solución más práctica es devolver la excepción serializada en formato JSON, más un flag en el header de la respuesta que la diferencie de las respuestas “normales”:

internal static class ExceptionHandlingHelper
{
 public enum ResponseStatusEnum
 {
  Normal,
  ApplicationException,
  UnexpectedException
 } 

 internal static void ApplicationInstance_Error(object sender, EventArgs e)
 {
  Exception exception = HttpContext.Current.Server.GetLastError();
  if (exception is ApplicationException)
   ResponseHeadersHelper.CurrentHeaders.Add("RESPONSE_STATUS", ResponseStatusEnum.ApplicationException.ToString());
  else
  {
   Log.WriteException(exception);
   ResponseHeadersHelper.CurrentHeaders.Add("RESPONSE_STATUS", ResponseStatusEnum.UnexpectedException.ToString());
   if (![DEBUG_MODE])
    HttpContext.Current.Session.Abandon();
  }

  HttpContext.Current.Response.Clear();
  HttpContext.Current.Response.Write(ExceptionHandlingHelper.SerializeException(exception));
  HttpContext.Current.Server.ClearError();
 }
 //.... etc ....
}

Tenemos entonces tres estados posibles para una respuesta:

  • Error de negocio: ResponseStatusEnum.ApplicationException, son las excepciones lanzadas mediante un throw en nuestro código, y que deben derivar, por convención, de ApplicationException.
  • Error inesperado: ResponseStatusEnum.UnexpectedException, son todas las demás, originadas en throws por validaciones de consistencia en nuestro código o directamente desde el framework.
  • Normal: todo bien.

Así que lo primero que hacemos en nuestra rutina de manejo de excepciones es conseguir la excepción y determinar de qué tipo es, agregando un header en la respuesta (“RESPONSE_STATUS”) para que el cliente javascript pueda diferenciarlas fácilmente de las respuestas normales. Si es un error inesperado podemos, adicionalmente, registrarlo en el log y limpiar la sesión del usuario.

Luego se modifica la respuesta que por defecto enviaría el servidor, utilizando Response.Clear(), Server.ClearError() y escribiendo en el objeto Response la excepción serializada en JSON.

La serialización de la excepción es un poco molesta dado que el uso común de JavascriptSerializer arroja una excepción por culpa de la propiedad TargetSite, que se vuelve recursiva en cuanto al tipo. Pero, por otro lado, habíamos establecido que en un ambiente de producción no es conveniente enviar toda la información de la excepción ya que puede exponer datos internos a un ocasional atacante. Así que tenemos que implementar nuestra propia serialización para esta clase.

Una forma sencilla es recorrer el primer nivel de propiedades del objeto Exception y dejar que JavascriptSerializer se encargue del resto. El siguiente ejemplo es una prueba de concepto –no pretende ser una guía de lo que es o no seguro enviar al cliente-, solamente omite en la serialización las propiedades “InnerException”, “StackTrace” y “Source”. Tal vez habría que agregar más restricciones, probando siempre qué información estamos enviando en cada caso.

private static string SerializeException(Exception ex)
        {
            JavaScriptSerializer serializer = new JavaScriptSerializer();

            StringBuilder exSerialized = new StringBuilder("{");
            PropertyInfo[] exProperties = ex.GetType().GetProperties(BindingFlags.Public | BindingFlags.FlattenHierarchy | BindingFlags.Instance);
            foreach (PropertyInfo property in exProperties.Where(p => p.Name != "TargetSite"))
            {
                if (![DEBUG_MODE] &&                    
   (property.Name == "InnerException" || property.Name == "Source" || property.Name == "StackTrace"))
                    continue;

                exSerialized.AppendFormat("\"{0}\":", property.Name);
                serializer.Serialize(property.GetValue(ex, null), exSerialized);
                exSerialized.Append(", ");
            }

            if ([DEBUG_MODE]) 
            {
                exSerialized.AppendFormat("\"ToString\":");
                serializer.Serialize(ex.ToString(), exSerialized);
                exSerialized.Append(", ");
            }

            exSerialized.Remove(exSerialized.Length - 2, 2);
            exSerialized.Append("}");
            return exSerialized.ToString();
        }

La información así serializada es fácil de acceder desde el cliente ya que se convierte automáticamente en un objeto similar a Exception, pero en javascript.

Notarán que en el ejemplo incluí, para entornos de desarrollo, una propiedad extra que contiene la cadena devuelta por el método ToString de Exception, que es lo que se suele mostrar por pantalla en caso de errores. Tendremos, en resumen, disponibles en javascript casi todas las propiedades del objeto Exception más una propiedad “ToString” que contiene una cadena con toda esa información en un formato legible para el usuario/desarrollador.

Volvamos a javascript para ver cómo manejamos la respuesta ahora. Partimos del ejemplo del post anterior completando algunos de los “placeholders” que habíamos dejado, ya que ahora sabemos exactamente cómo llega la información desde el servidor:

function Save( data, callback )
{
 var async;
 if( typeof callback == "undefined")
  async=false;
 else
  async=true;
 
 var returnValue = null;
 
 $.ajax({
  url: "Comments/Save",
  data: data,
  async: async,
  success: function (response, status, xhr) {

   //Exception handling.
   var responseStatus = xhr.getResponseHeader("RESPONSE_STATUS");
   var ex = null;
   if (responseStatus == "ApplicationException") 
   {
      var netEx = JSON.parse(response);
      ex = new ProgramException(netEx.Message, netEx);
      ex.Reasons = netEx.Reasons;
   }
   else if (responseStatus == "UnexpectedException") 
   {
      var netEx = JSON.parse(response);
      ex = new FatalException(netEx.Message, netEx);
   }

   if(ex!=null)
   {
      if (async)
         ShowException(ex)
      else
         throw ex;     
   }

   //Normal response handling.
   if (async)
    callback(response)    
   else
    returnValue = response;
  }
  error: function(XMLHttpRequest, textStatus, errorThrown) {
   var ex = [GET_EXCEPTION_INFO];
   if(async)
    ShowException(ex)
   else
    throw ex;
  }
 });

 //async => returnValue == null;
 //sync  => returnValue == response;
 return returnValue;
}

La parte modificada es la de la sección “success” -previa al “Normal response handling”-. Verán que ahora, para determinar si hubo una excepción se consulta el encabezado de la respuesta que incluimos en el manejo de excepciones del lado del servidor -xhr.getResponseHeader("RESPONSE_STATUS")-. No importa qué excepción de negocio se haya producido, este header aparecerá siempre que ésta derive de ApplicationException. En la serialización JSON se devolverán todas las propiedades del tipo específico –en un entorno de desarrollo, recordémoslo siempre- ya que utilizamos JsonSerializer.

Por ejemplo, si la excepción lanzada es aquella ShowCaseException de la que hablamos al principio, sabremos por el header que deriva de ApplicationException y al mismo tiempo conservaremos la propiedad “Reasons”, específica del tipo, al serializar. Si prueban verán que aparece en el objeto netEx cuando se ejecuta var netEx = JSON.parse(response);

Cuando deserializamos la excepción la encapsulamos en un objeto conocido para el cliente. Esto es para reflejar el hecho de que para el cliente de javascript sólo existen dos objetos derivados de Exception relevantes: los de negocio (excepciones “de programa” y los de sistema (“fatales”). Para ello creamos sus clases correspondientes, inspiradas un poco en las de .Net (una excepción base y dos derivadas), pero en estilo javascript. Esto no es necesario, pero me resultó muy cómodo (veremos luego):

//Exception base
ExceptionBase = function (type, message) {
    this.Type = type;
    this.Message = message;
};

//Program Exception
ProgramException = function (message, netException) {

    this.Reasons = [];
    this.NetException = netException;

    if (typeof message != "undefined" && message != null)
        this.Message = message;

};
ProgramException.prototype = new ExceptionBase("ProgramException", "Operation Error");

//Fatal Exception
FatalException = function (message, netException) {

    this.NetException = netException;

    if (typeof message != "undefined" && message != null)
        this.Message = message;

}

FatalException.prototype = new ExceptionBase("FatalException", "Unexpected Error");

Son estas dos clases las que nos permiten codificar luego este tipo de instrucciones:

var netEx = JSON.parse(response);
ex = new ProgramException(netEx.Message, netEx);
ex.Reasons = netEx.Reasons;

Hasta aquí, un paso más en la batalla. Nos resta:

  • Determinar cómo tratar los errores en la comunicación.
  • Determinar cómo mostrar toda esta información (hasta ahora no hicimos nada con el método “ShowException”).

Hasta la próxima, nos leemos. (Actualización: sigue en .Net MVC + jQuery: manejo de excepciones. IV: el lado del cliente.)

viernes, 19 de febrero de 2010

¿Exteriores o efectos especiales?

Una impresionante demo reel de Stargate Studios a partir del trabajo realizado para muchas de las series más conocidas de la televisión americana.

Visto en Alt1040

miércoles, 17 de febrero de 2010

.Net MVC + jQuery: manejo de excepciones. II: El problema.

[Continuación de .Net MVC + jQuery: manejo de excepciones. I: Requerimientos.]


Tengamos presente nuestro ejemplo de manejo de errores y excepciones en $javascript (jQuery):

$("#Save").click(function () {
 try {
  $("#CommentForm").valid();
  Save({
   User: $("#User").val(),
   Date: $("#Date").val(),
   CommentText: $("#CommentText").val()
  });
 }
 catch (ex) {
  ShowException(ex);
 }
});

Por el lado de las excepciones, tenemos en principio aquellas generadas por nuestro código. En el ejemplo, serían aquellas que arroje la función valid() luego de verificar los datos ingresados por el usuario.

Luego tenemos aquellas que se generen durante la llamada al servidor. Asumiendo que Save() hace una llamada $.ajax para enviar los datos al servidor, tenemos en realidad dos escenarios posibles: sincrónico y asincrónico.

Si la llamada al servidor es sincrónica Save() debe hacer un throw en algún punto del código con la información necesaria para que sea atrapado por el catch del código de arriba y ShowException muestre un mensaje al usuario.

Si la llamada es asincrónica deberíamos pasarle a Save() un parámetro callback, una función a ser invocada cuando el servidor responda. Por ejemplo (muy esquemáticamente):

Save({
 User: $("#User").val(),
 Date: $("#Date").val(),
 CommentText: $("#CommentText").val(),
 function(response){
  alert(response);
 }
});

En este segundo caso es el método Save() el que debe internamente contemplar la posibilidad de excepciones y decidir, de acuerdo con la respuesta, si invoca al callback o a ShowException.

Creo que en algunas situaciones es necesario el uso de llamadas asincrónicas, pero que en general es más fácil manejar la lógica sincrónica, por algo es por lo que se empieza al aprender a programar. Así que personalmente prefiero que cada función javascript que se comunica con el servidor dé la opción de pasar o no una función de callback.

Si juntamos estas dos opciones y hacemos un boceto de Save() quedaría algo por el estilo de:

function Save( data, callback )
{
 var async;
 if( typeof callback == "undefined")
  async=false;
 else
  async=true;
 
 var returnValue = null;
 
 $.ajax({
  url: "Comments/Save",
  data: data,
  async: async,
  success: function (response, status, xhr) {

   //Exception handling.
   if( [RESPONSE_IS_EXCEPTION] )
   {
    var ex = [GET_EXCEPTION_INFO];
    if (async)
     ShowException(ex)
    else
     throw ex;     
   }

   //Normal response handling.
   if (async)
    callback(response)    
   else
    returnValue = response;
  }
  error: function(XMLHttpRequest, textStatus, errorThrown) {
   var ex = [GET_EXCEPTION_INFO];
   if(async)
    ShowException(ex)
   else
    throw ex;
  }
 });

 //async => returnValue == null;
 //sync  => returnValue == response;
 return returnValue;
}

En el ejemplo se asume que si se pasa un parámetro de callback la llamada debe ser asincrónica. En este caso se ejecuta $.ajax, el flujo sigue en la línea siguiente y returnValue será null cuando Save() termine. En algún momento posterior, cuando el servidor responda, jQuery invocará al código que se pasa en el parámetro success de $.ajax. De ser una llamada sincrónica se ejecutará $.ajax e inmediatamente el código del parámetro success.

Si se produce un error o una excepción no controlada del lado del servidor $.ajax invocará a la función especificada en el parámetro “error”. Lo mismo sucederá ante errores en la comunicación en sí.

Tanto en error como en success debemos determinar, de alguna manera (que también veremos luego, en el ejemplo estos agujeros blancos están entre corchetes), si hubo una excepción o error. Si la hubo armamos un objeto “ex” con la información que necesite ShowException. Si no, devolvemos el valor.

La diferencia entre sincrónico y asincrónico en este punto es que en el caso de ser una llamada sincrónica hacemos un throw (que atrapará el catch de Save) o llamamos a la función callback o devolvemos el valor a través del retorno de la función, mientras que en el caso de la llamada asincrónica debemos manejar aquí mismo la excepción o llamamos a la función callback. Si hiciéramos un throw en este punto, durante una llamada asincrónica, la excepción sería atrapada por el navegador y el usuario vería un error de javascript (en el mejor de los casos. En el peor, no vería nada y pensaría que sus datos fueron grabados correctamente).

Hasta aquí las excepciones. Vamos ahora a contemplar la posibilidad de errores. Si no tienen en claro la diferencia les recomiendo –otra vez- hacer un paréntesis y leer este post.

A modo de resumen de ese post, recordemos que si al momento de grabar los datos “La fecha del comentario ingresado corresponde a un informe ya aprobado”, eso es una excepción (una situación contemplada en el código en forma de validación, un throw en nuestro código del lado del servidor. Es un mensaje que tiene utilidad para el usuario, que debe indicar que él ha cometido un error y no el sistema). Pero si al momento de grabar el sistema intenta insertar un valor nulo en donde no se puede, eso es un error (una excepción para el framework o la base de datos, pero una situación no contemplada en nuestro código).

¿Dónde deberíamos esperar errores? Fácil, en todos lados. Lo inesperado puede por definición aparecer en cualquier momento. Pensemos qué situaciones pueden darse y qué hacer en cada caso:

  • Un error en el código de negocio del lado del servidor: en este caso podríamos enviar una respuesta que le indique al código javascript (en success) que se ha producido un error de sistema y a ShowExceptions que debería “romper” la pantalla impidiendo que el usuario continúe utilizando la aplicación o mostrar información detallada, dependiendo de si estamos en un ambiente de desarrollo o testing.

    Un ejemplo sería el intento de utilizar una variable que está en nulo, pero también que la base de datos no esté disponible o muy ocupada, o un timeout de base de datos. Para este caso tendríamos una excepción del lado del servidor, pero que no deriva de ApplicationException.

  • Un error en la infraestructura del lado del servidor: en este caso el problema no está en nuestro código y no es atrapado por él. Es el que se daría si el servidor web está muy ocupado. Puede ser antes o después de la operación, pero en todo caso no es controlado por nosotros.

    Aquí no tendríamos una excepción de .Net del lado del servidor, sino que éste, sin que podamos evitarlo, devolvería un error HTTP (típicamente un error 500, aunque podría ser otro). En este caso es jQuery el que atraparía el error e invocaría a la función especificada en el parámetro “error” de la llamada $.ajax.

  • Un error en la llamada, del lado del cliente: en este caso la llamada $.ajax jamás llega al servidor (por ejemplo si la url es incorrecta o está mal formada).

    Aquí hay un punto de debate: dado que el error se produce enteramente del lado del cliente no tenemos posibilidad de registrarlo, sólo nos enteraremos de él a través de una comunicación del usuario (por mail, teléfono, o como sea). La única información de la que dispondremos será aquella que le mostremos por pantalla… pero no es una buena práctica mostrar detalles internos al usuario final… Pero esto es último es discutible, ya que si vamos a suponer un error provocado por un usuario malicioso es de todas maneras información a la que él puede acceder, ya sea que se la hagamos más fácil o más difícil.

    Lo que es seguro, volviendo al tema, es que ShowExceptions tiene que manejar también esta situación y, por lo menos, asimilarla a la indicada en los puntos anteriores y darle el mismo tratamiento.

  • Un error en el código javascript, del lado del cliente. Es decir, un error de javascript ya sea en la función Save() o en el manejador del evento click. Este tipo de errores sería atrapado por el catch más externo de todos, el de la función que asociamos al evento click.

    En este caso el objeto “ex” que ShowExceptions recibirá como parámetro no estaría armado por nosotros sino por el motor de javascript (y lo que es peor, será ligeramente diferente entre navegadores, e incluso entre distintas versiones del mismo navegador). Así que tenemos que contemplar también la posibilidad de que a ShowExceptions le llegue este otro objeto “más o menos desconocido” proporcionado por el motor de javascript.

  • Un error en el código de manejo de errores. Es decir, un error de javascript adentro de ShowExceptions. Créanme que el andamiaje necesario para todo este control es lo suficientemente complejo como para que tenga sus propios errores, y éste es el peor escenario: el error en ShowExceptions nos estaría ocultando aquél que le dio origen, y deberemos resolverlo antes de enfrentarlo. Dado que ShowExceptions es la última fortaleza del funcionamiento del sistema deberá ser a prueba de balas: ya no importa cómo ni en qué situación, su misión es mostrarnos todos los errores que se hayan producido (propios y ajenos) sin perder información y asegurarse de que la pantalla del lado del cliente quede bloqueada. Tarea ingrata si las hay, pero alguien tiene que hacerlo.

Resumamos, como para ir terminando este post ya demasiado extenso, las situaciones que debemos contemplar:

  • Excepciones generadas desde nuestro código en javascript (las que se generen en la función valid() de validación de datos ingresados por el usuario).
  • Llamadas sincrónicas y asincrónicas. La diferencia está en hacer un throw o llamar a ShowExceptions en la función que se comunica con el servidor.
  • Errores o excepciones generados del lado del servidor. En este caso la comunicación ha sido exitosa.
  • Errores en la comunicación en sí, provocados por la conexión (“se cayó la red”) o por el código (“url mal formada).
  • Errores en el código javascript que implementa una funcionalidad específica.
  • Errores en el código javascript de control de errores.

La vida no es fácil… luego seguimos. (Actualización: sigue en .Net MVC + jQuery: manejo de excepciones. III: Atrapar errores del lado del servidor y comunicarlos controladamente al cliente.)

lunes, 15 de febrero de 2010

.Net MVC + jQuery: manejo de excepciones. I: Requerimientos.

Me pasé las últimas semanas trabajando sobre la beta de Visual Studio 2010 (acaba de salir el Visual Studio 2010 RC) armando un esquema de trabajo (un mini-framework) para proyectos MVC, en un intento de materializar la experiencia acumulada en otros proyectos en la forma de herramientas encapsuladas, probadas y listas para reutilizar.

Uno de los puntos que más trabajo me ha llevado es el manejo de excepciones. Un tema traicionero, simple a primera vista pero complicado y retorcido a medida que se avanza. Siempre lo tuve cubierto (es decir, sin graves problemas) con un poco de alambre, pegamento y parches aquí y allá, y quise aprovechar este nuevo comienzo en limpio para pensar un esquema más consistente y por lo tanto más sólido y fácil de mantener.

Comencemos, como corresponde, por los requerimientos. ¿Qué pretendo de a la infraestructura de un proyecto en cuanto a manejo de errores y excepciones (teoricé sobre la diferencia hace un tiempo, en Errores y excepciones)?

En principio, un uso estándar y transparente. Por ejemplo, en el botón “Save” de una vista, el programador debería codificar, en javascript (+jQuery, por supuesto):

$("#Save").click(function () {
 try {
  $("#CommentForm").valid();
  Save({
   User: $("#User").val(),
   Date: $("#Date").val(),
   CommentText: $("#CommentText").val()
  });
 }
 catch (ex) {
  ShowException(ex);
 }
});

En el ejemplo anterior, el bloque try…catch captura los errores de validación disparados por la instrucción $("#CommentForm").valid(); (es el plugin jQuery Validation) y la función ShowException los muestra en una forma amigable al usuario. Este no es el comportamiento “normal” de la función valid() de jQuery Validation, hay que codificarlo.

Pero no sólo eso. La función Save del ejemplo debe enviar los datos al servidor y el servidor debe pasarlos al modelo de negocio y esperar excepciones. Excepciones del tipo “La fecha del comentario ingresado corresponde a un informe ya aprobado” y cosas por el estilo, tan molestas para nosotros como necesarias para nuestros clientes. Es decir que se comunicará con una acción en un controlador, supongamos:

namespace ShowCase.Web.Controllers
{
    public class CommentsController : Controller
    {
  public bool SaveComment(CommentsModel model)
  {
   model.Save();
   return true;
  }
    }
}

Vemos que la acción devuelve siempre true. Esto es porque espera que los problemas se comuniquen a través de las excepciones. Un ejemplo esquemático para el método Save del modelo sería:

public class CommentsModel
{
 public void Save()
 {
  FinancialReport financialReport = FinancialReports.GetByDate(this.Date);
  if(financialReport.Status == ReportStatus.Approved)
   throw new ApplicationException("The comment's date points to an approved report.");
  
  FinancialReports.SaveComment(financialReport, this);
 }
}

El manejo de este tipo de excepciones generadas del lado del servidor debería ser, para el programador de la funcionalidad, idéntico al de las generadas del lado del cliente. Así que tenemos que llegar, de alguna manera, desde el throw en el método Save de CommentsModel, al catch en nuestra función de javascript.

Para complicar las cosas, agreguemos los errores. Estamos hablando ahora de verdaderos errores del sistema: errores de codificación, de conexión con la base de datos, de conexión entre el cliente y el servidor web, de javascript, etc. Errores del tipo que solemos llamar catastróficos, pero que yo prefiero denominar inesperados, como para restarle dramatismo al asunto (un cliente que no llamaría a las 3 de la mañana por un error “inesperado” tal vez sí lo haga por uno “catastrófico”).

Es el tipo de errores, en definitiva, que deberían “romper” o “cerrar” la aplicación, puesto que se ha arribado a un estado no contemplado, y cualquier acción posterior podría derivar en datos corruptos, inconsistentes, o –por lo menos, y más probablemente- en nuevos, más molestos y más extraños errores.

La función ShowException del ejemplo debería diferenciar entre las excepciones de negocio y los errores. Para los primeros mostrará un mensaje al usuario, y para los segundos deberíamos grabar un archivo de log, y podríamos establecer dos comportamientos posteriores:

  • uno para desarrollo o pruebas, mostrar por pantalla toda la información disponible acerca del error, y dejar que la aplicación siga abierta (el desarrollador o tester decidirá por sí mismo si puede continuar o no sin problemas),
  • y otro para producción, limpiar completamente la pantalla y mostrar un mensaje de error escueto invitando al usuario a reiniciar la aplicación o a llamar al administrador del sistema (siempre y cuando no seamos nosotros).

Es importante que, en entornos de producción, no sólo la función ShowException no muestre más de lo que debe, sino que el servidor mismo no envíe más información que la estrictamente requerida.

Todos estos requerimientos deben implementarse, dentro de lo posible, en una forma transparente al programador de la funcionalidad. Personalmente considero esta transparencia como algo muy importante, y la resigno (obligando al programador a derivar de ciertas clases, a implementar o a invocar ciertas funciones especiales) sólo cuando la alternativa es imposible o extremadamente más complicada. Cuando programamos una funcionalidad tenemos la cabeza puesta en facturas, aprobaciones, balances, fechas de cierre… en ese contexto, dónde fue generada la excepción o qué tipos de excepción hay y cómo deben transmitirse desde su origen hacia el cliente, son sutilezas que de requerir tratamiento especial serán seguramente pasadas por alto.

Pero, en definitiva, qué tan importante es esta transparencia o cuándo una alternativa es “imposible” o “extremadamente complicada” dependerá de cada uno. El hecho es que gracias a .Net MVC y jQuery podemos lograr un nivel muy aceptable de transparencia a través de diferentes puntos de intercepción y extensión convenientemente ubicados en la infraestructura del proyecto.

Suficiente para una primera entrega. En la próxima –en breve- analizaremos más en detalle los requerimientos en busca de las situaciones más comunes y los problemas que deberemos enfrentar al momento de picar el código.

Continúa en .Net MVC + jQuery: manejo de excepciones. II: El problema.

domingo, 14 de febrero de 2010

sábado, 13 de febrero de 2010

Frases: jQuery.

Javascript ha muerto, ha nacido $(javascript).

Una de mi cosecha para la posteridad.

viernes, 12 de febrero de 2010

Jueguitos de viernes: Batea al pingüino.

Batea al pingüino es uno más en la categoría “clickea a tiempo”. Un juego tonto de gráficos mediocres que consiste de un sólo nivel en el que rápidamente el jugador depende más de su suerte que de su habilidad… Por suerte es lo suficientemente sangriento como para compensar todo eso y brindarnos largos minutos de estúpida diversión.

BateaAlPinguino

(gracias Matías por el dato)

miércoles, 10 de febrero de 2010

Frases: principios y prioridades.

Los que sobreviven en este oficio son los que tienen prioridades y no principios.

Leída en El Juego del Angel, de Carlos Luis Zafón, novela que empecé a leer hoy para sacarme de encima el polvo de tanto picar código y que ya puedo recomendar tranquilamente (espero que siga tan bien como empieza).

Esto viene a reforzar aquello de que quien está atento encuentra máximas en cualquier lado, que es buen alumno aquel que busca un maestro, y cosas por el estilo.

Por cierto, paciencia, paciencia que ya voy a postear algo consistente… espero.

viernes, 29 de enero de 2010

Frases: Participación y compromiso.

¿Cuál es la diferencia entre participación y compromiso? Digamos que si el objetivo es preparar huevos con jamón la gallina participa, pero el cerdo está comprometido.

(me la recordó un reciente twit de @Yoriento)

jueves, 28 de enero de 2010

Frases: $.noop()

“$.noop returns the sound of one hand clapping.”

$.noop devuelve el sonido de una sola mano aplaudiendo.”

- Karl Swedberg comentando la documentación de $.noop() de jQuery.

Para los despistados: $.noop() es una función de jQuery que -como su nombre indica- no hace nada.

martes, 12 de enero de 2010

Desafíos.

Un desafío es el deseo de alcanzar un objetivo ubicado un poco más allá (no demasiado, porque si no ya sería un sueño) de nuestras capacidades actuales. Implica mejora, autosuperación.

Para mí, lo motivador de mi trabajo es lo desafiante que puede llegar a ser. Frecuentemente se nos plantean proyectos parecidos a aquellos que enfrentamos en el pasado pero con algún matiz, algún punto oscuro, alguna particularidad especial que nunca hemos implementado. Estas particularidades representan nuevos problemas y son las que hacen al proyecto desafiante en esa medida justa que nos permite enfrentarlo con cierta confianza sin llegar al extremo de la sensación del salto al vacío.

Cuando no es así simplemente me aburro, y no tolero bien el aburrimiento. A mediados del 2009 di el salto y cambié de trabajo. En su momento actué guiado más por esos sentimientos –de aburrimiento- racionalizados que por razones objetivas. De alguna manera ese creciente aburrimiento ante los problemas y situaciones han alimentado este blog -inmejorable vía de escape- en la primera parte de este año (y a cuya ausencia se debe, en cierta medida, la poca producción bloggera de la segunda).

Finalmente el tiempo puso las cosas en perspectiva y el nuevo entorno me da un punto de comparación. Me llama la atención lo nimio, lo poco importantes que eran los problemas y situaciones que ponía como excusa del cambio. Ahora es claro que esa necesidad de cambio no estaba dada por el entorno sino que provenía de mí mismo, que su origen no era la gravedad o repetición de algún problema o situación sino el nulo desafío que éstos representaban para mí. Pareciera que “nulo desafío” implica que todo era “fácil”. Nada más lejos de lo que quiero decir, aquí vamos.

El punto central de toda esta cantinela es que uno no sólo “es parte de” sino que también construye la situación que lo rodea. Decir “no habrán nuevos desafíos” es, en realidad, una vuelta retórica por la que esquivamos la responsabilidad en la construcción de esa situación al ubicar a los desafíos en el entorno cuando en realidad están en nosotros.

Los desafíos no están allí, uno no los encuentra sino que los crea. Es decir que constantemente enfrentamos los desafíos que nos hemos creado, como Don Quijote contra los molinos de viento.

Un entorno de trabajo desafiante no es, por si queda alguna duda, algo objetivo. Lo que para unos es tierra fértil es desierto para otros, no por la dificultad o no de los problemas objetivos a resolver –finalmente el único problema objetivo lo constituyen los requerimientos de un cliente-, sino por la predisposición o no de cada uno a crear desafíos en ese entorno en un momento determinado.

Pareciera ser, entonces, que a nivel institucional hay poco que se pueda hacer para crear un entorno desafiante, dado que esta característica reside en cada persona y no en ese espacio creado grupalmente.

En alguna medida es así. No se pueden “crear” desafíos institucionalmente. Pongamos un ejemplo: se plantea “ser referencia en el uso de la tecnología X” como un “desafío en el que todos tenemos que estar comprometidos”. Esto es en realidad apenas un objetivo y una expresión de deseo que puede ser origen de un desafío motivador para algunos pero indiferente o incluso fuente de sentimientos negativos –inseguridad, presión, rechazo- para otros.

Lo que sí se puede hacer institucionalmente es ubicar a cada integrante en un puesto en donde los problemas objetivos –los requerimientos de sus clientes externos o internos- estén alineados con su predisposición a crear desafíos en torno de esos problemas y proporcionar los recursos, la libertad de acción o la guía que necesite cada uno para superarse. Esto será mucho más productivo que el vano intento de imponer desafíos a diestra y siniestra como si todos fuéramos iguales y nos interesaran las mismas cosas.

Pero esto implica un conocimiento muy personal de cada integrante del equipo por parte de la institución… mejor dicho por parte de las personas que definen los puestos en las instituciones y que –erróneamente o no- generalmente están muy alejados del resto de la empresa, si no física por lo menos profesionalmente.

La solución común, dado que a nivel institucional no puede haber un conocimiento personal profundo de cada uno, es dividir la responsabilidad entre persona e institución: la responsabilidad institucional es de abrir las puertas, proporcionar los caminos para que cada uno busque o cree ese lugar desafiante, y está en cada uno la responsabilidad y el esfuerzo de motorizar esa búsqueda. Motorizar es buscar, proponer, convencer, buscar alternativas, concretar.

Es tan común en sistemas la queja constante sobre las posibilidades de desarrollo profesional (“de encontrar nuevos desafíos”) como la inacción de quien las enuncia en cuanto a la creación o búsqueda de ese espacio fértil en desafíos profesionales.

De ser sincero el deseo, de existir esa búsqueda y de ser infructuosa, debería continuar por fuera (pero ya basta de quejarse), la posibilidad de que no haya intersección entre lo que una persona encuentre como desafiante y las necesidades de una institución en particular existe, y no hay más que hacer que seguir buscando.

viernes, 8 de enero de 2010

Jueguitos de Viernes: Basketball

Simplemente apuntar y tirar. ¿La gracia? Que todos los jugadores online juegan al mismo tiempo y vamos viendo nuestra posición en tiempo real. Además podemos formar grupos para competir con amigos.

basketball-online

Link: Basketball (visto en Juegos Microsiervos).

jueves, 7 de enero de 2010

Palabras del general sobre metodologías ágiles…

peron  ….útiles para convencer a los compañeros (nunca mejor utilizada la palabra) del equipo de desarrollo.

- Pongan el carro en movimiento que los melones se acomodan solos.

- La única verdad es la realidad.

- Mejor que decir es hacer, mejor que prometer es realizar.

- Gobernar es fácil, lo difícil es conducir.

- Para conducir un pueblo la primera condición es que uno haya salido del pueblo, que sienta y piense como el pueblo.

- La organización vence al tiempo.

- Es evidente que en todos los movimientos revolucionarios existen tres clases de enfoques: el de los apresurados, que creen que todo anda despacio, que no se hace nada porque no se rompen cosas ni se mata gente. El otro sector está formado por los retardados, esos que quieren que no se haga nada... Entre esos dos extremos perniciosos existe uno que es el equilibrio y que conforma la acción de una política, que es el arte de hacer lo posible...

miércoles, 6 de enero de 2010

Curiosidades en los lenguajes de programación.

A veces la lógica sobre la que se asienta un lenguaje de programación (cosa “estricta” –con comillas- si las hay) tiene algún extraño efecto colateral. Otras veces un mal momento (¿demasiado temprano por la mañana? ¿demasiado tarde por la noche? ¿resaca?) de aquél que debe dar una definición queda inmortalizado por las consecuencias de ésta.

Cuestión que en todo lenguaje hay ciertas curiosidades, puntos oscuros, cosas que no parecen todo lo claras, lógicas o esperables que deberían. Es el tipo de cosas que se han ido destapando en Stack Overflow bajo el título Strangest language feature con la consigna “What is, in your opinion, the most surprising, weird, strange or really "WTF" language feature you have encountered?”

Por ejemplo…

Javascript se lleva las palmas en la categoría "sutilezas tramposas":

return
{
    id : 1234,
    title : 'Tony the Pony'
};

//devuelve undefined, ya que el salto de línea luego del return implica
//(implícitamente) el final de la instrucción. Por eso esto sí funciona:

return {
    id : 1234,
    title : 'Tony the Pony'
};

//Y esto también (grrr....)

  return /*
*/{
    id : 1234,
    title : 'Tony the Pony'
  };

...su tabla de verdad tiene algunas cositas impresentables:

''        ==   '0'           //false
0         ==   ''            //true
0         ==   '0'           //true
false     ==   'false'       //false
false     ==   '0'           //true
false     ==   undefined     //false
false     ==   null          //false
null      ==   undefined     //true
" \t\r\n" ==   0             //true

Por otro lado, el integer cache en java es un buen ejemplo de esos extraños aunque esperables efectos colaterales:

Integer foo = 1000;
Integer bar = 1000;

foo <= bar; // true
foo >= bar; // true
foo == bar; // false

//pero si los valores de foo y bar están entre 127 y -128 (inclusive)
//el comportamiento cambia:

Integer foo = 42;
Integer bar = 42;

foo <= bar; // true
foo >= bar; // true
foo == bar; // true

Y no es la primera vez que escucho quejas (muy justificadas, según mi propio criterio) sobre el manejo de cadenas en php:

//uno pensaría que
"01a4" != "001a4"
//pero la realidad es que
"01e4" == "001e4"

Captaron la idea, me imagino. El resto en la entrada original de Stack Overflow.

martes, 5 de enero de 2010

La queja.

Soy quejoso por naturaleza. Siempre le encuentro el pelo al huevo y, a falta de errores o problemas más graves, hago de un charquito una inundación…

A veces exagero un poco. Cuando mis compañeros de trabajo están –razonablemente- ya un poco hartos de mis cancioncitas plañideras les recuerdo, como para equilibrar un poco la balanza, que si bien me quejo

a) estoy en general encargándome activamente o lidiando con el problema, así que eso me da cierto derecho a una breve descarga emocional –a veces no es tan breve como debería-, y

b) estoy constantemente pensando y tratando de proponer soluciones –a veces peores que el problema, pero bueno… prueba y error, y sin error no hay prueba- y que

c) soy el primero en ponerle el hombro a cualquier intento de mejora, incluso cuando no crea que vaya a funcionar –probemos, con un poco de suerte me equivoque-.

Sí, a veces exagero y soy demasiado duro con algún temita en una solución que, en general, funciona bien. Pero bueno, es parte mi forma de motivar –correcta o no, efectiva o no, ésa es- y de motivarme a concentrarse no en lo que salió bien sino en lo que salió mal, que es lo que merece más atención.

Lo que es seguro es que es menos probable –a veces se requiere de más de un golpe- que me vuelva a dar con la misma piedra… aunque luego encuentre otra con la que impactar.

Por otro lado, hay personas en las que la queja es sólo eso, una queja. Una enumeración interminable de problemas, errores y malas decisiones que no las mueve a la acción o al cambio en lo más mínimo.

Estas personas piensan en el pelo antes de hacer el huevo. Como el “pelo a futuro” desmotiva, se quedan en la inacción y la queja se vuelve constante –porque sin acción nada cambia-, autosuficiente e inmortal.

Si es la queja la que lleva a la inacción o si es la excusa para la inacción, es imposible de saber. Pero es en todo caso indiferente, si el resultado es el mismo y es la nada.

Pero ojo, porque el quejoso no es mentiroso y no necesariamente tiene malas intenciones. Normalmente los problemas sobre los que la queja se asienta son reales, la práctica de la observación pasiva lo ha vuelto experto en su detección.

Así que –para mí- tampoco es prudente hacer oídos sordos a su cantinela. Lo que debemos evitar –a veces harto difícil- es quedar atrapados girando en la órbita de su parálisis.

Una solución imperfecta es siempre mejor que nada. Incluso una solución equivocada es mejor que nada, es una posibilidad menos en el camino de la prueba y error. Hacemos sistemas, no estructuras de concreto, y siempre podemos volver atrás y buscar otra salida. El tiempo insumido, al que usualmente calificamos de “perdido”, no será tal hasta que nos demos por vencidos.

viernes, 1 de enero de 2010

Jueguitos de Viernes: Air Traffic Chief.

Gracias a Cerebrado, que como siempre sabe qué tirar para arruinar la productividad de un viernes… pero hoy es viernes 1, así que podemos procrastinar sin culpas y combatir la resaca con este adictivísimo juego.

En Air Traffic Chief hacemos las veces de controladores de vuelo y lograr que todas las naves lleguen a destino. Empieza fácil, casi aburrido, pero se complica rápidamente. Yo todavía no logro pasar las 70 naves aterrizadas.

AirChief