Aparte de ser un lenguaje dinámico, una característica que diferencia mucho a javascript de lenguajes como C# y Java es el mecanismo de herencia. En lugar de utilizar un sistema de herencia basado en clases, se usa herencia basada en prototipos.

Una buena forma de entender como funcionan las cosas es intentar implementarlas. No se trata de realizar una implementación “usable”, sino de utilizar cosas que ya conocemos para entender mejor cosas nuevas. Voy a dedicar un par de posts para ver cómo simular con C# la herencia prototípica de javascript.

Clases vs Prototipos

No voy a entrar en conceptos complicados como sistemas de tipos, teoría de categorías y cosas por el estilo, pero vamos a intentar definir “más o menos” cómo funciona cada sistema.

En un lenguaje basado en clases se definen clases que agrupan datos y operaciones. A partir de esas clases, se crean objetos (instancias) que contendrán los datos y operaciones definidos en la clase a la que pertenecen. Además, podemos definir subclases, es decir, clases que heredan de otras clases y en las que podemos añadir o modificar el comportamiento de la clase base.

En la lenguaje basado en prototipos no existen las clases. Existen sólo objetos, pero cada objeto tiene un prototipo asociado. Este prototipo no es más que otro objeto (con su respectivo prototipo). Al invocar una operación sobre un objeto, primero se mira si el objeto ha definido esa operación. Si la ha definido, se invoca la operación y ya está. Si no, se intenta invocar la operación definida en el objeto que actúa como prototipo, y si no en el prototipo del prototipo y así sucesivamente.

Una consecuencia de esta diferencia es que en el caso de una lenguaje basado en clases el comportamiento del objeto queda definido por la clase a la que pertenece y, por tanto, queda definido en el momento de su creación, mientras que con prototipos el comportamiento del objeto puede cambiar siempre que cambiemos su prototipo, cosa que podríamos hacer en cualquier momento (incluso después de crearlo).

Insisto, ésta no es una definición en absoluto rigurosa y puede haber lenguajes que se comporten de manera diferente, pero para nuestro objetivo, que es entender cómo funciona la herencia en javascript con respecto a C# o Java, nos sirve.

Simulando un objeto Javascript con C#

Para nuestro experimento, lo primero que necesitamos es simular un objeto javascript usando C#. El objetivo es pasar este test:

dynamic p = new ProtoObject();
p.Name = "Lucas";
Assert.That(p.Name, Is.EqualTo("Lucas"));

Esto lo podríamos hacer directamente con un ExpandoObjet, pero desgraciadamente Microsoft tiene la mala costumbre de hacer muchas clases sealed (cuando no internal) y no podemos heredar de él, así que vamos a crear una clase que herede de DynamicObject y use un diccionario para almacenar las propiedades:

public class ProtoObject : DynamicObject
{
  private readonly IDictionary<string, object> properties = new Dictionary<string, object>();

  public override bool TrySetMember(SetMemberBinder binder, object value)
  {
    properties[binder.Name] = value;
    return true;
  }

  public override bool TryGetMember(GetMemberBinder binder, out object result)
  {
    return properties.TryGetValue(binder.Name, out result);
  }
}

Aunque el ejemplo sea con una propiedad, podríamos añadir métodos usando proiedades de tipo Acion o Func y funcionaría igual (aunque la sintaxis es un poco desagradable):

dynamic p = new ProtoObject();
p.Sum = new Func<int, int, int>((a, b) => a + b);
Assert.That(p.Sum(2, 3), Is.EqualTo(5));

Ahora que tenemos creado nuestro objeto dinámico, vamos a implementar la propiedad __proto__ de javascript.

Añadiendo una cadena de prototipos a través de __proto__

Al explicar las diferencias de un sistema basado en clases y uno basado en prototipos, decía que en el segundo cada objeto tiene un prototipo y, cuando no podemos resolver una propiedad dentro de un objeto, tratamos de hacerlo en su prototipo. Pues bien, en javascript el prototipo se almacena como una propiedad más del objeto, llamada __proto__.

Vamos intentar simularlo pasando este test:

dynamic p = new ProtoObject();

p.__proto__.Name = "Lucas";
Assert.That(p.Name, Is.EqualTo("Lucas"));

p.Name = "Tengo preferencia";
Assert.That(p.Name, Is.EqualTo("Tengo preferencia"));

Para pasar este test, necesitamos modificar nuestra clase ProtoObject:

public class ProtoObject : DynamicObject
{
    private readonly IDictionary<string, object> properties = new Dictionary<string, object>();

    private ProtoObject lazyInitializedProto;

    public ProtoObject __proto__
    {
        get { return lazyInitializedProto ?? (lazyInitializedProto = new ProtoObject()); }
        set { lazyInitializedProto = value ?? new ProtoObject(); }
    }

    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
        properties[binder.Name] = value;
        return true;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        var hasMember = properties.TryGetValue(binder.Name, out result);
        return hasMember || __proto__.TryGetMember(binder, out result);

    }
}

Hemos añadido una propiedad __proto__ y hemos hecho que cuando no se pueda resolver la propiedad en el diccionario de objetos local, se intente resolverla a través de __proto__. La parte más extraña es tener que inicializar de forma perezosa el prototipo, pero eso es únicamente para evitar una recursión infinita al crear el objeto (se crearía el __proto__, que a su vez crearía su __proto__ que a su vez…).

Conclusión

Aunque sólo sirva para fines didácticos (que a nadie se le ocurra intentar usar esto en el mundo real), esta implementación permite comprender fácilmente cómo funciona de forma aproximada el sistema de prototipos en javascript.

Falta un aspecto fundamental, que es el this, puesto que no tenemos una limpia de definir operaciones en los prototipos que actúen sobre las propiedades definidas en el propio objeto, pero sirve para hacernos una idea de qué es esa misteriosa propiedad __proto__ que encontramos en los objetos javascript cuando los inspeccionamos con un depurador.

Es muy atractiva la simplicidad de la idea. En el fondo todo se basa en composición y delegación, pero empleando únicamente esos dos conceptos se pueden conseguir resultados realmente interesantes.

Posts relacionados:

1. Mixins en Javascript
2. Swiftcore.js: un contenedor IoC para Javascript
3. Modificar una clase en Javascript: Eliminar los markers de Google Maps

En este post voy a tratar de sintetizar lo que más y lo que menos me ha gustado de angular.

Como siempre, este tipo de cosas son bastante personales, por lo que cualquier opinión (especialmente si es distinta) será bienvenida en los comentarios.

Un poco de contexto antes de empezar

Angular es una solución completa que incluye prácticamente todos los aspectos que puedes necesitar para crear una aplicación cliente en javascript. Esto incluye la generación de vistas, el uso de databinding, las rutas, la organización de componentes en módulos, la comunicación con el servidor…

Eso quiere decir que no tiene sentido compararlo con librerías como jQuery, Knockout, Handlebars o PagerJs. Eso son librerías orientadas a resolver un problema concreto, pero no proporcionan una solución global para desarrollar aplicaciones.

No hay que olvidar que angular está diseñado para desarrollar aplicaciones, no páginas web. Si lo que estás desarrollando es una página web, donde prime el contenido, necesites una buena indexación y un html limpio y cristalino, angular no es una buena solución, pero no porque sea un mal producto, simplemente no está diseñado para ello.

Las partes buenas

El sistema de databinding es muy completo y potente. De serie permite hacer casi cualquier cosa que necesites, pero además se trata de un sistema de databinding fácilmente extensible mediante directivas y filtros, lo que permite a crear pequeños componentes que facilitan que la capa de presentación sea algo organizado y no el típico jaleo que acaba siendo muchas veces.

La idea de poder anidar los $scopes (ViewModels), aunque al principio parezca un poco extraña, acaba resultando bastante natural y posibilita crear diseños bastante interesantes.

Aunque al principio era un poco reticente al uso de un contenedor de inversión de control en javascript (no así a la inyección de dependencias), después de trabajar con angular tengo que reconocer que he cambiado de opinión.

Es cierto que hay que definir explicítamente las dependencias y la sintaxis es un poco desagradable para evitar problemas con los minifiers y uglifiers, pero al final compensa porque te permite concentrarte en la clase que estás desarrollando sin tener que preocuparte de la implementación y el ciclo de vida de sus dependencias.

Desde el principio, angular está diseñado para ser fácilmente testeable. Teniendo en cuenta lo imporantes que son los tests en javascript, esto es una cosa muy de agradecer. A través de karma se pueden crear tanto tests unitarios (ayudados por los mocks que se incluyen en angular) como tests de extremo a extremo, y eso es un factor crítico para mantener la estabilidad de la aplicación.

Las partes malas

Una de las cosas que más confusas me han resultado al trabajar con angular es la nomenclatura elegida para las cosas. La mayoría de los conceptos que se manejan con angular son conceptos habituales que ya conocía, pero la forma de llamarlos es un poco rara.

La mayoría de los filtros no filtran nada, sino que formatean. El estado se mantiene a través de servicios. Los ViewModel se convierten en los $scope. No soy muy bueno poniendo nombres a las cosas, pero yo los hubiera llamado algo así como Components, Transformers y ViewModels.

Esto además nos lleva a otro problema muy frecuente en proyectos opensource y especialmente en la comunidad javascript, que está evolucionando tan rápido: la falta de documentación.

La documentación oficial de angular no es que esté mal, pero no es todo lo completa que a uno le gustaría, muchas veces falta ejemplos y no siempre está actualizada. Es verdad que es fácil encontrar documentación en forma de videos, tutoriales y posts, pero la velocidad a la que se desarrolla angular hace que se queden obsoletos muy pronto. En cuanto sales de los ejemplos típicos y encuentras problemas, no encuentras mucha ayuda.

Por último, hay que tener en cuenta que si decides usar angular, te casas con angular. Esto está motivado por la propia concepción de angular como solución “todo incluido”, por lo que tampoco es muy achacable al propio angular, pero no deja de ser un factor importante.

Me parece complicado desarrollar una aplicación completa con angular y luego tratar de migrarla a otro framework, porque la mayoría de la funcionalidad va a estar muy integrada con clase que dependen de angular.

Es un riesgo que puede merecer la pena asumir, pero que hay que tener presente.

Conclusión

Ante la pregunta de si usaría angular para mi próximo aplicación con javascript, la respuesta es, a día de hoy sí (de hecho lo estoy haciendo).

La curva de aprendizaje se hace un poco dura, sobre todo por la falta de documentación y la elección de nombres, pero luego resulta bastante productivo gracias a cosas como el databinding y el contenedor de inversión de control.

El aspecto más preocupante de utilizar angular es el mismo de utilizar cualquier framework de estas características: te atas mucho a él y asumes un riesgo grande al ligar tu aplicación al destino de angular.

La parte positiva de esto es que se trata de un proyecto opensource y con un código relativamente fácil de seguir, por lo que en caso de apuro, siempre podrás meterlo mano para solucionar los problemas que te vayan surgiendo.

Posts relacionados:

1. AngularJS: Servicios, Inyección de Dependencias y Módulos
2. AngularJS: Directivas y Filtros
3. AngularJS: Conceptos Básicos

Este es el cuarto post de una serie en la que estoy explicando las características más destacadas de angularjs. Hasta ahora hemos visto los conceptos básicos, la forma en que se trabaja con servicios, inyección de dependencias y módulos, y cómo mejorar la capa de presentación usando directivas y filtros.

Hoy quiero analizar algo que, por desgracia, para muchos será irrelevante, pero que para mi es fundamental antes de decidirme a utilizar un framework: el soporte para testearlo.

En este blog que hablado mucho sobre tests automatizados (ya fuera aplicando TDD o no) y he insistido en la importancia de los tests en javascript.

Si ya considero que los tests automatizados son una de las cosas que más calidad aporta a un proyecto, en el caso de un lenguaje dinámico como javascript creo que su importancia aumenta enormemente al perder al seguridad que ofrece la comprobación de tipos que realiza el compilador.

En ese sentido, angular está diseñado desde el principio para poder ser fácilmente testeable y para ello cuenta con dos tipos de tests diferenciados, tests unitarios y tests de extremo a extremo.

OJO: en estos post no vas a encontrar información detallada sobre cómo trabajar con angular ni mucho código fuente, si estás buscando ese tipo de detalles, te recomiendo que eches un vistazo a la documentación oficial o sigas el tutorial.

Karma

Los sistemas de tests empleados por defecto en angular, tanto unitarios como extremo a extremo, se basan en el uso de Karma, un lanzador de tests que se integra con distintos frameworks (Jasmine, QUnit, Mocha, etc.) para ejecutar tests en navegadores reales (Firefox, Chrome, Phantom, e incluso Internet Explorer).

Esto nos permite comprobar que la aplicación funciona realmente sobre los motores de javascript que la van a ejecutar, lo que nos ayudará a detectar posibles problemas por incompatibilidades de javascript entre ellos.

La configuración de Karma no es todo lo sencilla que me gustaría y su integración con herramientas como grunt a veces resulta un poco complicada, sobre todo por la gestión de versiones (algo demasiado frecuente en el cambiante mundo de las librerías javascript). Un buen punto de partida para configurarlo es el proyecto angular-seed, que ofrece una plantilla de proyecto ya configurada.

Aun así, una vez que lo tienes configuarado es bastante estable y se puede usar sin demasiados problemas con un servidor de integración continua.

Tests Unitarios

Con angular podemos escribir tests unitarios que nos permitan definir y comprobar el funcionamiento de los componentes de la aplicación por separado.

Aprovechando el sistema de inyección de dependencias es sencillo modificar las dependencias de los componentes para inyectar mocks/stubs/fakes/lo-que-más-te-guste y poder aislar el componente que estamos testeando.

No soy muy partidario de los tests de interacción con mocks, y en el caso de javascript todavía menos, pero a veces no queda más remedio que utilizarlos para testar cosas concretas.

Aun así, siguiendo los mismos principios para escribir tests unitarios que aplicaríamos en otros lenguajes es posible conseguir una buena suite de tests en la que podamos confiar.

Tests de Extremo a Extremo

Usando Karma podemos también ejecutar tests de integración de extremo a extremo. Estos tests levantan un servidor web de verdad e interactúan con nuestra aplicación desde un browser como lo haría un usuario. Para ello angular ofrece un DSL no demasiado complicado de manejar que nos permite indicar cosas como “navega a esta página”, “pulsa este botón”, “comprueba el texto de este <p>”…

Este tipo de tests es bastante más lento de ejecutar que los tests unitarios y normalmente suele haber muchos menos tests de extremo a extremo que tests unitarios. No obstante, en mi caso, en este tipo de aplicaciones escribo más tests de extremo a extremo que los que escribiría en otros entornos.

En un lenguaje estático los tipos ayudan mucho a mantener la estructura de la aplicación en pie. Si modificas el interfaz de una clase y no actualizas los clientes, la aplicación no compilará, tendrás que revisar los clientes y por lo menos tendrás una oportunidad de corregir el comportamiento. Si además tienes tests unitarios que comprueben el funcionamiento de cada clase por separado… tienes una cierta seguridad.

En javascript, si cambias el comportamiento de una clase, los clientes no se van a enterar. No hay un compilador que te diga que la llamada es incorrecta. Si tienes tests unitarios te pueden ayudar a detectar problemas, pero si la clase cliente ha sustituido la dependencia por un mock/fake/stub, todos los tests seguirán pasando sin errores pese a los cambios (esto en un lenguaje estático no ocurriría porque al cambiar el interface del componente tendrías que actualizar el mock/fake/stub y tendrías una pista de que hay algo que ajustar).

Si a esto le unimos la cantidad de configuración que va en el propio HTML a través de directivas y filtros aplicados, los tests de extremo a extremo se convierten en algo indispensable para garantizar el comportamiento del sistema.

Resumen

Por suerte, angular está bien diseñado para permitirnos testear nuestras aplicaciones. Ya he dicho antes que para mi es un factor crítico a la hora de elegir un framework y en este caso estoy muy contento con el soporte que da angular para ello.

Con este post termino el repaso a las características que me parecen más interesantes de angular. Aprovecharé el último post de la serie para hacer una pequeña valoración (aun) más personal de este framework que está tan de moda (ahora).

Posts relacionados:

1. Cómo NO escribir tests unitarios: Resumen final
2. Cómo NO escribir tests unitarios: Todos a la vez
3. Cómo NO escribir tests unitarios: Replicando cálculos en el test

En esta serie de posts estoy haciendo un repaso de muchas de las características de angularjs. En el primer post explicaba los conceptos básicos en que se fundamenta angular, y especialmente la capa de presentación, mientras que en el segundo profundizaba un poco en la organización interna basada en módulos, servicios e inyección de dependencias.

Esta vez toca volver a la capa de presentación para hacer hincapié en dos herramientas que ofrece angular para desarrollar la capa de presentación de forma lógica y sencilla.

OJO: en estos post no vas a encontrar información detallada sobre cómo trabajar con angular ni mucho código fuente, si estás buscando ese tipo de detalles, te recomiendo que eches un vistazo a la documentación oficial o sigas el tutorial.

Directivas

En el primer post expliqué que angular utiliza un sistema de databinding declarativo bidireccional para enganchar el $scope, es decir el ViewModel en terminología de angular, con la vista. Para ello se emplean lo que en angular se conoce como directivas.

Las directivas tienen el aspecto de elementos o atributos en el código HTML, pero son interpretadas por angular al generar las vistas, lo que nos permite modificar el DOM o añadir nuevos comportamientos.

Podéis ver bastantes ejemplos de directivas en el proyecto UI Boostrap, que permite utilizar los componentes de Twitter Bootstrap en angular, pero para hacernos una idea de cómo funcionan vamos a ver un par de ejemplos.

Una directiva de atributo se utiliza como si fuese un atributo más de un elemento HTML y puede llevar parámetros o no, pero además tiene la ventaja de que desde ella podemos referenciar el $scope (el ViewModel) para realizar acciones o leer datos:

<div ng-controller="SampleController">
  <input ng-model="person.name"/>
  <button ng-click="save()"/>
</div>

En este ejemplo aparecen las directivas ng-controller, ng-model y ng-click, que nos permiten enlazar un Controller a un elemento HTML, enlazar la propiedad person.model a un cuadro de texto e invocar la función $scope.save() al pulsar un botón.

Las directivas de elemento se utilizan como cualquier otro elemento HTML y simplifican los procesos de creación de fragmentos HTML. Por ejemplo, podemos tener una directiva que nos permita generar pestañas:

<tabs>
  <pane heading="Static title">Static content</pane>
  <pane ng-repeat="pane in panes" 
        heading="{{pane.title}}" 
        active="pane.active">
    {{pane.content}}
  </pane>
</tabs>

Aquí estamos usando las directivas tabs y pane para generar la estructura de HTML necesaria para implementar un sistema de pestañas.

Lo mejor de las directivas es que es muy sencillo crear nuevas directivas para encapsular pequeños fragmentos de funcionalidad y poder así mantener unas vistas más limpias y claras. Podríamos considerar las directivas como algo similar a los controles de usuario de ASP.NET o los HTML helpers de ASP.NET MVC.

Filtros

Los filtros en angular son los encargados de procesar la información antes de mostrarla en pantalla. Permiten hacer muchas cosas, pero lo más habitual es utilizarlos para modificar los valores a presentar o aplicarles formato.

Se aplican dentro de las expresiones de databinding y se indican con el caracter |. Al igual que las directivas, los filtros pueden recibir parametros que modifiquen su comportamiento.

El ejemplo más típico de uso de un filtro que modifica lo que estamos presentando es el filtro filter que permite seleccionar elementos de un array:

<ul>
  <li ng-repeat="c in customers | filter:{region: 'Madrid'}">{{c.name}}</li>
</ul>

En este ejemplo estaríamos filtrando los elementos del array customers antes de pasárselos a la directiva ng-repeat para mostrar sólo los clientes cuya region es Madrid.

En el caso de formatear valores, podríamos tener un filtro que tradujese cadenas de texto antes de mostrarlas al usuario y su uso sería similar a este:

<p>{{'SAMPLE_KEY' | localize}}</p>

El filtro localize se encargaría de traducir, seguramente usando algún servicio, la expresión a la que se aplica el filtro, en este caso 'SAMPLE_KEY'.

Al igual que las directivas, es fácil definir nuevos filtros que permitan reutilizar comportamiento entre distintas partes de la aplicación. Además, angular permite aplicar secuencialmente filtros, por lo que es sencillo crear muchos filtros focalizados y luego componerlos para obtener el resultado final:

<p>{{message | pluralize | toUpperCase}}</p>

Seguramente lo más confuso de los filtros es que el primer ejemplo que se ve es el de filtro filter, por lo que parece que únicamente sirven para filtrar colecciones, pero en realidad, como hemos visto pueden utilizarse para otro tipo de cosas, como formatear valores o incluso realizar otras transformaciones (por ejemplo, agregados sobre colecciones).

Resumen

Los filtros y las directivas son de las cosas que más me gustan de angular. En la mayoría de aplicaciones el código más feo, más enrevesado y más difícil de mantener está en la capa de presentación y, sobre todo, en las vistas, por lo que contar con herramientas como estas es de mucha ayuda para que la aplicación no se haga inmanejable con el paso del tiempo.

Todavía no he dicho nada en esta serie sobre otro factor que está bastante bien trabajado en angular, que son las herramientas para realizar tests, pero eso queda para el próximo post.

Posts relacionados:

1. AngularJS: Servicios, Inyección de Dependencias y Módulos
2. AngularJS: Conceptos Básicos

En el anterior post sobre angularjs explicaba la forma en que se organiza la capa de presentación alrededor de los conceptos de Views, Controllers, ViewModels y Routes. Siguiendo con mi política de conocer los frameworks sobre los que trabajo, en este post vamos a bajar de nivel y vamos a ver qué hay por debajo de la capa de presentación.

OJO: en estos post no vas a encontrar información detallada sobre cómo trabajar con angular ni mucho código fuente, si estás buscando ese tipo de detalles, te recomiendo que eches un vistazo a la documentación oficial o sigas el tutorial.

Servicios

Con los elementos que veíamos en el post anterior tenemos herramientas suficientes para construir una aplicación, pero cuando la aplicación se complica, tener toda la lógica metida entre los Controllers y los ViewModels (a.k.a. $scopes), no es una buena idea.

Los servicios son un concepto importante en angular. Igual que podemos definir Controllers, podemos definir servicios en los que agrupemos funcionalidad que luego estará disponible para ser usada en los Controllers, mejorando la claridad del código y favoreciendo la reutilización.

Hasta aquí, nada nuevo. Es un concepto manejado por todos desde hace mucho tiempo y resulta familiar. La parte que puede resultar más extraña es que en angular los servicios se utilizan también para mantener estado.

En la mayoría de arquitecturas que he utilizado los servicios suelen ser objetos stateless (sin estado), que implementan operaciones pero no mantienen el estado de la aplicación. Sin embargo, en angular los servicios son la herramienta básica para mantener el estado de la aplicación (hablo siempre de la capa cliente) y compartir información entre los Controllers.

En una aplicación web MVC típica, del estilo ASPNET MVC o Rails, la información fluye entre los Controllers a través de las peticiones http, pero en una aplicación con angular no se emplea ese concepto, sino que un Controller modifica el estado de un servicio y el siguiente Controller utiliza ese servicio para acceder al nuevo estado.

En realidad, la existencia de este tipo de objetos no es algo raro, pero catalogarlos como servicios resulta un tanto confuso cuando empiezas a trabajar con angular.

Inyección de dependencias

Hace tiempo escribí de la utilidad de la inyección de dependencias en javascript y una de las cosas que me gusta de angular es que hace un uso intensivo de ella usando un contenedor de inversión de control.

Esto quiere decir que a la hora de definir cualquier componente, ya sea un Controller, un Service o lo que sea, debemos indicar de qué otros componentes depende y angular se encargará de proporcionárselos a través de la función constructura (o de la función factoría que lo construya, que para el caso es lo mismo).

Todos los componentes registrados en angular son singleton, es decir, sólo existe una instancia de ellos en la aplicación y si hay varios componentes que dependen de un mismo objeto, todos recibirán la misma instancia del objeto. Esto es lo que permite utilizar fácilmente los servicios para almacenar estado, ya que dos Controllers que dependan de un mismo servicio estarán utilizando el mismo objeto y, por tanto, podrán compartir información a través de él.

El mayor inconveniente de usar un contenedor de inyección de dependencias en un lenguaje dinámico como javascript es que necesitamos definir explicítamente las dependencias ya que no existen un sistema de tipos que permita inferirlas automáticamente. Hace tiempo explicaba cómo funcionaba switfcore.js, un contenedor IoC para javascript, y, aunque el API es distinta, las mismas pegas que comentaba en aquel post se puede aplicar a angular.

Módulos

Con todo lo que llevamos visto hasta ahora es fácil imaginarse que una aplicación con angular puede crecer bastante y gestionar las dependencias puede complicarse.

Para solucionar esto y permitirnos organizar un poco mejor el código, angular implementa un sistema de módulos de tal forma que siempre que se define un componente, se hace (o mejor dicho, se debería hacer) dentro de un módulo. Podemos asimilar estos módulos a namespaces, y podemos establecer dependencias entre módulos para que angular sepa qué componentes utilizar en cada momento.

Resumen

En estos dos posts hemos visto ya gran parte de los conceptos fundamentales que maneja angular. Quedan todavía algunas cosas más que me gustaría destacar, como el uso de directivas y filtros para encapsular pequeños bloques de comportamiento en la capa de presentación, pero eso será tema de otro post.

Posts relacionados:

1. Inyección de dependencias en Javascript (y otros lenguajes dinámicos)
2. AngularJS: Conceptos Básicos
3. Dependencias binarias y dependencias de código fuente

Para facilitar el desarrollo de este tipo de aplicaciones han ido surgiendo multitud de frameworks e incluso en este blog ya he escrito sobre algunos de ellos como Knockout y jQuery Mobile.

Últimamente he estado trabajando con angularjs, un framework desarrollado por Google y, como creo que es importante conocer los frameworks que se utilizan, en estos post voy a intentar explicar los conceptos básicos sobre los que se asienta la filosofía de angular.

OJO: en estos post no vas a encontrar información detallada sobre cómo trabajar con angular ni mucho código fuente, si estás buscando ese tipo de detalles, te recomiendo que eches un vistazo a la documentación oficial o sigas el tutorial.

Arquitectura de la Capa de Presentación

Angular ha sido definido como un framework Model-View-Whatever, es decir, Modelo-Vista-Lo-que-sea. Pretende de esta forma huir de la discusión entre MVVM vs MVC vs MVP, pero lo cierto es que desde mi punto de vista tiene un marcado estilo MVVM.

Pese a este estilo MVVM, la aplicación se organiza entorno a Controllers responsables de construir los ViewModels que se enlazarán a las vistas. El papel que juegan los Controllers es un tanto limitado, por lo que no creo que se puedan comparar a los Controllers de la típica arquitectura web MVC, donde construyen un modelo “tonto” y luego se encargan ellos de gestionar las operaciones. En angular el controller puede construir un ViewModel que luego toma el control completo de las operaciones realizadas en la vista, por lo que básicamente actúan como factorías de ViewModels.

El enlace entre vistas y ViewModels se realiza mediante un sistema de databinding declarativo bidireccional. Para ello se “decoran” los elementos html con directivas (de las que hablaremos más adelante) y se usa un sistema de plantillas parecido a handlebars:

<div ng-controller="PhoneCtrl">
  <ul>
    <li ng-repeat="phone in phones">{{phone.name}}</li>
  </ul>
</div>

Una cosa que resulta extraña al principio es que no existe una definición del ViewModel como tal, sino que cada Controller tiene asociado un objecto $scope sobre el que construirlo. En el ejemplo anterior, el controller PhoneCtrl añadiría a su objeto $scope una lista de teléfonos, cada uno de ellos con una propiedad name, y eso sería lo que se enlaza a la vista.

Otro aspecto curioso es que los $scopes, es decir, ViewModels, están jerarquizados. Es decir, en una misma página podemos tener $scopes anidados unos con otros, y los $scope hijos pueden acceder a las propiedades y funciones de los $scope padre.

La raíz del árbol de $scopes es el $rootScope y podríamos considerarlo como el ViewModel global en el que colocar datos como el usuario loggeado actualmente o funciones de utilidad que queramos tener accesibles en cualquier otro $scope.

La jerarquía de Controllers/$scopes se corresponde con la jerarquía de elementos html en la página. Puesto que los Controllers están asociados a elementos html, si el elemento asociado a un Controller contiene un elemento asociado a otro Controller, el $scope del segundo podrá acceder a las propiedades del primero.

Para navegar entre las páginas de la aplicación se utilizan rutas, que podemos asociar a Controllers y fragmentos de html. Cuando se accede a una ruta, se carga ese fragmento de html (que puede residir en un archivo externo) mediante ajax y se inserta en la página actual en el elemento que esté marcado con la directiva ng-view:

<body ng-app="MyApp">
  <div ng-view>
	<!-- 
	  Aquí se irán cargando las vistas asociadas a las rutas
	  de la aplicación MyApp definida en el elemento body
	  con la directiva ng-app
	-->
  </div>
</body>

Angular se encarga de mantener el historial de navegacion y todas esas cosas básicas, por lo que el manejo es bastante sencillo.

Resumen

Este post presenta una visión general de la forma en que se organiza la capa superior de angularjs, donde encontramos elementos conocidos (Views, Controllers, ViewModels, Routes), pero también algunas particularidades, como la jerarquización de los ViewModels o el reducido papel que juegan los Controllers en esta historia.

En próximos posts veremos más cosas interesantes de angular, como su organización en módulos, los servicios, el sistema de inyección de dependencias o el uso de directivas para encapsular comportamiento del interfaz de usario.

No hay posts relacionados.

Para este ejemplo vamos a tener una solución de Visual Studio con dos proyectos: nuestra aplicación y un proyecto de tests, y nuestro script se va a encargar de realizar los siguientes pasos:

1. Limpiar los resultados de ejecuciones anteriores.
2. Compilar la solución.
3. Ejecutar los tests.
4. Generar un paquete NuGet con el resultado.

El objetivo será que alguien que se baje el proyecto desde el control de código fuente pueda realizar todos estos pasos ejecutando un único comando, sin necesidad de instalar manualmente ningún componente adicional en la máquina (más allá el SDK de .NET). De esta forma conseguiremos que la compilación siempre se realice en un entorno controlado, con versiones adecuadas de cada dependencia y sin posibilidad de introducir errores en el proceso por saltarnos algún paso manual.

Estructura de Carpetas

Cuando diseñamos un script de estas características, es importante definir una estructura de carpetas razonable. Esto, además de ayudarnos a crear el script, nos permitirá adaptarlo fácilmente a nuevos proyectos siempre que mantengamos la misma estructura de carpetas.

La estructura de carpetas que vamos a utilizar es la siguiente:

La carpeta src será la carpeta donde se encontrará la solución de Visual Studio y los paquetes NuGet utilizados. Toda la gestión de paquetes NuGet la haremos desde Visual Studio, donde además de instalarlos deberemos hablitar la opción de Restaurar Paquetes NuGet (Enable NuGet Package Restore). Podríamos hacerlo desde el propio script de compilación usando NuGet por línea de comandos, pero resulta más cómodo hacerlo desde Visual Studio.

En la carpeta build generemos los archivos compilados (.exes y .dlls) y la usaremos como carpeta de trabajo durante la compilación.

La carpeta results contendrá en resultado final del proceso. En nuestro caso será un paquete NuGet y un fichero xml con los resultados de la ejecución de los tests.

En la carpeta raíz del proyecto tendremos el script de compilación propiamente dicho (sample.build) y un fichero build.cmd para lanzar el proceso cómodamente.

MSBuild: Targets y Tasks

MSBuild utiliza archivos XML para configurar el proceso de compilación. Estos ficheros se organizan alrededor del concepto de Targets. Un Target representa un proceso que se puede invocar de forma independiente y que, a su vez, puede depender de otros procesos.

En nuestro ejemplo, cada una de las fases de la compilación (limpiar, compilar, empaquetar, etc.) será un Target. Además crearemos un Target que dependa de todos los demás de manera que al invocarlo se ejecute el proceso completo.

La estructura del fichero incluyendo sólo los Targets es la siguiente:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Default">
  
  <Target Name="Default" DependsOnTargets="
          Clean;
          Build;
          RunTests;
          CreatePackage"/>
    
  <Target Name="Clean">...</Target>
  <Target Name="Build">...</Target>
  <Target Name="RunTests">...</Target>
  <Target Name="CreatePackage">...</Target>

</Project>

Para invocar un Target concreto por línea de comandos, debemos usar el parámetro /t. Si no indicamos nada, se ejecutará el Target por defecto (en este caso Default). Esto nos permite probar el script paso a paso:

msbuild.exe sample.build ← Esto ejecuta el target por defecto
msbuild.exe sample.bulid /t:RunTests ← Esto sólo ejecutaría el target RunTests

Para definir las acciones a realizar en cada Target se utilizan las Tasks. Las Tasks son operaciones que nos ofrece MSBuild para manejar archivos y directorios, compilar proyectos, ejecutar comandos externos, etc. Además de la que incluye MSBuild puedes crear tus propias Tasks o usar alguna de las librerías existentes, como MSBuild Extension Pack o MSBuild Community Tasks).

Al crear el script podemos definir propiedades y grupos de ficheros usando los elementos Property e ItemGroup. Las propiedades funcionan de manera similar a las variables, y podemos utilizarlas para almacenar la ruta hasta ficheros, parámetros de compilación, etc. Los grupos de ficheros sirven, como era de esperar, para indicar un conjunto de ficheros que luego podremos referenciar en las Tasks.

Aunque no voy a entrar en detalles para no alargar mucho el post, veamos cómo se implementa uno de los pasos: la ejecución de los tests:

<PropertyGroup>
  <BuildDir>$(MSBuildProjectDirectory)\build\</BuildDir>
  <ResultsDir>$(MSBuildProjectDirectory)\results\</ResultsDir>
  <NUnit>$(MSBuildProjectDirectory)\src\packages\NUnit.Runners.2.6.2\tools\nunit-console.exe</NUnit>
</PropertyGroup>  
  
<Target Name="RunTests">
  <Exec Command='"$(NUnit)" "$(BuildDir)\Tests.dll"' WorkingDirectory='$(ResultsDir)'/> 
</Target>

En el PropertyGroup declaramos una serie de propieades con la ruta hasta el ejecutable de NUnit-Console.exe que se encargará de lanzar los tests, la carpeta donde se encuentran los ficheros compilados y la carpeta donde se almacenan el resultado de los tests.

El Target RunTests utiliza la Task Exec para ejecutar NUnit-Console.exe pasándole como parámetros el assembly con los tests e indicando como carpeta de trabajo la carpeta de resultados. Como podéis ver, podemos usar string interpolation con las propiedades que hemos definido antes para construir los argumentos de la Task.

En el script de compilación completo podéis ver cómo se implementan el resto de Targets.

Resumen

Espero que este post haya servidor para desmitificar un poco el uso de MSBuild, podéis encontrar el código completo del proyecto en mi cuenta de github para jugar con él y ver cómo funciona.

Es importante tener una buena estructura de carpetas que podamos reutilizar de proyecto a proyecto, porque eso nos ayudará también a reutilizar el propio script de compilación. Lo normal es acabar con un script bastante genérico que luego se pueda adaptar a otros proyectos mediante la definición de propiedades y nuevos targets.

MSBuild es una herramienta muy potente y con él podemos automatizar muchas más cosas de las que se ven en este ejemplo. El mayor inconveniente que tiene (para mi gusto) es el uso de XML, que hace que resulte todo un poco más lioso, pero una vez que te acostumbras merece la pena.

Posts relacionados:

1. Testear Javascript con PhantomJS, QUnit y MSBuild

Sin embargo, hay tres herramientas básicas que uso en todos los proyectos: un sistema de control de versiones (desde git hasta subversion), un gestor de bugs/tareas (aunque sea una hoja Excel) y un servidor de integración continua.

Las dos primeras herramientas de la lista están muy extendidas y no conozco ningún equipo de desarrollo que trabaje sin ellas, pero lo del servidor de integración continua es menos conocido y no se usa tanto.

¿Qué es la integración continua?

La integración continua es una practica ligada a la programación extrema que consiste en automatizar el proceso de integración de código para poder realizarlo de la manera más continuada posible.

Cuando llega el momento de liberar una nueva versión de una aplicación hay que realizar un proceso de integración de todos los componentes que forman parte de la aplicación. Esto implica realizar varios pasos, como obtener el código fuente, compilarlo, ejecutar los tests, etc.

En muchos proyectos este es un proceso completamente manual, en el mejor de los casos documentado en forma de checklist en alguna parte, pero a fin de cuentas, siempre que haya pasos manuales, antes o después habrá algún error y pondremos en producción una aplicación con el número de versión incorrecto, que no ha pasado las pruebas automatizadas o que no estará correctamente etiquetada en el control de código fuente.

Si queremos mejorar este proceso, el primer paso es automatizarlo. Para ello contamos con diferentes herramientas, generalmente basadas en algún tipo de script de compilación. En .NET se suele utilizar MSBuild, en Javascript hay opciones como Grunt, en Ruby existe Rake… Al final todas se basan en lo mismo, poder definir de una manera más o menos cómoda las tareas a ejecutar para poder lanzarlas en un único paso.

Un ejemplo de script de compilación para una aplicación de escritorio podría contar con los siguientes pasos:

1. Obtener la última versión del código fuente.
2. Actualizar la información de versión en el fichero AssemblyInfo.cs basándose en la convención que se haya establecido (número de compilación, fecha, etc.).
3. Ejecutar una herramienta de análisis estático como FxCop o SourceMonitor para detectar defectos en el código.
4. Compilar los proyectos.
5. Ejecutar las suites de tests automatizados.
6. Generar la documentación (manuales, guías de instalación, etc.).
7. Crear los paquetes de instalación.
8. Etiquetar en el control de código fuente la versión del código usada para generar estos instaladores, de forma que luego podamos trazar exactamente qué codigo fuente se uso para generar cada versión de la aplicación.

Preparar este script puede llevar un tiempo y no es una tarea fácil la primera vez que lo haces, pero una vez que has aprendido es bastante sencillo adaptarlo para nuevos proyectos, por lo que la inversión de tiempo se recupera rápidamente.

¿Qué aporta un servidor de integración continua a este proceso?

Una vez que contamos con este script, cada vez que queramos realizar una integración completa (potencialmente liberable) del código, podremos hacerlo en un sólo paso ejecutándolo desde cualquier equipo; entonces, ¿para qué hace falta un servidor de integración continua?

El servidor de integración continua se encarga de ejecutar este script automáticamente según la programación que establezcamos, por ejemplo cada vez que se se realiza un commit/checkin/push al control de código fuente.

Además, podemos establecer distintas configuraciones para un mismo proyecto. Por ejemplo, podemos crear una configuración que realice una compilación “rápida”, ejecutando sólo los test unitarios cada vez que realizamos un commit, y programar una compilación “completa”, que ejecuta también los tests de integración y genera los instaladores todas las noches (las típicas nightly builds).

Realizar el proceso de integración de continuamente en un servidor tiene varias ventajas:

Por una parte, evita discrepancias entre las versiones utilizadas para generar los entregables. Al realizar la compilación en el servidor se garantiza que siempre se usa la misma versión del compilador, SDKs, librerías de terceros, etc. Eso es difícil de conseguir si la compilación se realiza cada vez en equipo distintos donde podría haber distintas versiones de cosas instaladas globalmente (assemblies en el GAC, módulos node instalados con npm install -g, etc.), provocando cambios en el comportamiento final de la aplicación dependiendo del equipo en que se ha compilado. Este tipo de errores son complicados de diagnosticar y pueden hacerte perder mucho tiempo.

Además, permite detectar rápidamente errores introducidos por cambios en el código. Aunque se supone que antes de hacer un commit cada desarrollador debería asegurarse de que todo funciona y ejecutar los tests en su equipo, a veces las suites de tests tardan más tiempo del que nos gustaría en ejecutarse (especialmente si tenemos tests de integración) o directamente al desarrollador se le olvida. Al hacer que el código se compile cada vez que se hace el commit en el servidor de integración continua, los errores se detectan en cuestión de minutos en lugar de hacerlo varios días después cuando alguien intenta liberar una nueva versión.

Otra ventaja de usar un servidor de integración continua es que podemos mantener un histórico de los resultados de las compilaciones. Dependiendo de los análisis que estemos realizando sobre nuestro código, esto nos permite conocer como ha evolucionado la cobertura de código de los tests, la complejidad ciclomática media y todas esas métricas que tanto nos gustan (otra cosa es que sirvan para algo, pero eso lo dejamos para otro día).

En teoría, si este proceso se lleva al extremo cada vez que se hace un commit al control de código fuente el servidor de integración continua sería capaz de detectar si todo es correcto y en ese caso hacer un despliegue automático. Eso es lo que se conoce como entrega continua (continuous delivery o continuous deployment) y hay proyectos que son capaces de hacerlo, aunque no siempre es viable (ni recomendable).

Conclusiones

Montar un servidor de integración continua puede resultar un poco complicado al principio. Hay muchas opciones disponibles, algunas más sencillas y otras más complejas, pero donde realmente reside la complicación es en estructurar tu proyecto para que todas las tareas sean fácilmente automatizables.

Aunque pueda parecer que este tipo de técnicas sólo son aplicables a equipos muy grandes que hacen aplicaciones muy complejas, no es así. Yo lo he utilizado en proyecto con un único desarrollador en los que lo único que se hacía era compilar el código y generar un instalador, y aun así merece la pena. Tener la seguridad de que lo que has compilado es lo que se debía compilar, que la versión está correctamente asignada y que el instalador lo has generado con los binarios correctos (y no con otros que compilaste dos horas atrás), te permite vivir mucho más tranquilo.

Es verdad que el coste inicial es alto, pero lo bueno es que las técnicas necesarias son muy fáciles de reutilizar de un proyecto a otro, por lo que una vez que has automatizado la integración del primer proyecto, si sigues una estructura común en todos tus proyectos, el resto es cuestión de ajustar un par de rutas en los scripts de compilación y los tienes listos en minutos (literalmente).

No hay posts relacionados.

Sobre esto del código abierto hay posiciones muy extremas, tanto en un sentido como en otro (me atrevería a decir que hay mayor extremismo entre los defensores del código abierto), pero dejando a un lado fanatismos, creo que es posible realizar un análisis más pragmático del asunto.

OJO: no voy a entrar en discusiones ético-filosóficas sobre las bondades de uno u otro sistema. Tampoco voy a meterme en las diferencias entre código abierto, software libre y software gratis, porque aunque creo que son importantes, prefiero mantener un enfoque más “práctico” en este post.

Un mundo guiado por un único fabricante

Los que trabajamos con plataformas de Microsoft hemos estado muy acostumbrados a utilizar únicamente lo que nos proporcionaba Microsoft que, por otra parte, no era poco y cubría bastante bien la mayoría de situaciones a las que nos teníamos que enfrentar.

Si necesitabas hacer una aplicación web, tirabas de WebForms (o ahora de ASP.NET MVC). Si querías un ORM, Entity Framework. Para bases de datos, SQL Server, y si tenía que ser embebida, SQL CE. Esa era la forma de hacer las cosas y mucha gente no se la cuestionaba.

Recuerdo que hace unos 6 años empecé a introducir en mi trabajo del mundo real librerías “no Microsoft”. Primero log4net, luego Castle Windsor, después NHibernate, …

Al principio tuve que vencer cierta reticencia entre algunos compañeros de trabajo, pero el tiempo me ha dado la razón y hoy en día usamos muchas librerías “de terceros”, la mayoría de ellas open source, y debo decir que han mejorado considerablemente nuestros procesos de desarrollo (tanto a nivel de productividad como a nivel de calidad).

Aún hoy hay empresas en que plantear usar tecnologías no Microsoft dentro de un proyecto .NET se considera una mala idea y existen directores técnicos que directamente vetan el uso de estas tecnologías.

Es como el viejo dicho de “nunca despidieron a nadie por comprar IBM“, parece que si te ciñes al uso de tecnologías soportadas por Microsoft, nada puede salir mal, o al menos si sale mal, la culpa no será de tu elección tecnológica.

Sin embargo, gracias a la exposición constante que tenemos los desarrolladores a otras comunidades y a la mezcla de ideas procedentes de otros lenguajes, ya no es tan raro emplear herramientas de código abierto en proyectos de .NET.

De hecho, en los últimos años la propia Microsoft ha abrazado ese concepto con herramientas con Nuget y las últimas librerías desarrolladas por Microsoft están siguiendo este modelo de desarrollo (ahí tenemos Entity Framework aceptando pull requests de desarrolladores externos como Unai).

Una cuestión de confianza

En realidad, el problema que tiene mucha gente con el software de código abierto no tiene nada que ver con que el código sea abierto o cerrado o con que la licencia y el modelo de desarrollo sea más o menos libre, sino con quién está detrás del código.

Existe una sensación demasiado habitual de que un proyecto de código abierto que no está dirigido por una organización comercial es algo en lo que no se puede confiar, pero el tiempo nos ha enseñado que esto no es cierto.

Hay proyectos realizados por voluntarios que llevan mucho tiempo funcionando bien y tienen bases de usuarios tan grandes que los convierten en soluciones mucho más sólidas que sus equivalentes comerciales. Los más extendidos han conseguido además el apoyo de grandes empresas, lo que les da ese plus de confianza que parece necesario para usarlos en ciertos entornos (estoy pensando en casos como jQuery).

Al final, lo más importante para que una librería o plataforma tenga un buen soporte es que cuente con un número suficiente de usuarios. Si una tecnología alcanza el suficiente grado de adopción, siempre será más fácil encontrar alguien dispuesto a soportarla, ya sea de manera altruista respondiendo preguntas en Stack Overflow o de forma comercial cobrando por servicios de consultoría.

En ese sentido, a la hora de decidir si una librería determinada o una plataforma concreta son confiables, me parece más importante tener en cuenta la base de usuarios que quién está detrás de ella. De hecho, hay ocasiones en que tener una empresa detrás puede llegar a ser contraproducente porque puede que mantener esa tecnología viva vaya en contra de los objetivos económico/estratégicos de la empresa (preguntádselo a los que decidieron usar Linq2SQL para ver cómo en poco tiempo era descontinuado y reemplazado por Entity Framework).

También es cierto que existen empresas capaces de garantizar la supervivencia de un producto y el soporte del mismo durante un tiempo prefijado. Ahí están casos como Canonical (una empresa tan “comercial” como Microsoft) y sus releases de Ubuntu con soporte extendido o los ciclos de vida que ofrece Microsoft para productos como SQL Server.

Conclusiones

Este post no pretende ser un alegato a favor del movimiento Open Source y en contra de Microsoft. Nada más lejos de mi intención. Como he dicho al principio, creo que hay demasiado fanatismo en ambos bandos y se tiende a perder de vista el objetivo real: generar valor desarrollando software.

A la hora de elegir sobre qué plataforma desarrollar o qué librería utilizar hay muchos factores a tener en cuenta y, sin duda, el soporte que podamos obtener es uno de ellos, pero también lo es la facilidad para desarrollar sobre ella, el rendimiento que podamos conseguir y la disponibilidad de buenos desarrolladores.

Los típicos argumentos de “código cerrado malo porque no lo puedo tocar”, “código abierto malo porque nadie me lo va a mantener” suelen caerse por su propio peso. Todos conocemos ejemplos de productos comerciales que han sido descontinuados dejando de dar soporte a sus usuarios, y todos usamos un montón de código abierto que no sabríamos tocar ni en un millón de años.

Lo que cuenta es resolver un problema y buscar las mejores herramientas para ello, que a veces serán open source y a veces no. No dejes que eso sea lo único que te guíe a la hora de elegir las herramientas más adecuadas para tu próximo proyecto. El código (abierto o cerrado) importa, pero el contexto más.

No hay posts relacionados.

Cuando estamos trabajando con una aplicacion web existen herramientas como Google Analytics que nos permiten recabar todo tipo de información (también podemos usar Google Analytics con aplicaciones de escritorio) , pero hay veces que necesitamos conocer detalles como la ubicación del usuario en el momento de interactuar con él, y no sólo a posteriori para realizar análisis estádísticos.

Una de las cosas que nos puede ayudar a mejorar la experiencia de usuario es conocer el lugar en el que se encuentra el usuario.

En HTML5 existe un api de geolocalización, pero no siempre está disponible y, además, requiere del consentimiento del usuario.

Otra opción es utilizar lo que se conoce como geolocalización de IP, que consisten en tratar de averiguar la ubicación del usuario basándonos en su dirección IP. Esto no es completamente fiable porque el usuario puede acceder a través de un proxy o usar una IP que está físicamente alejada de su ubicación real (la IP está realmente asociada al ISP no al equipo del usuario), pero en muchas ocasiones es suficiente.

Geolocalizando una IP

Para conocer la ubicación del usuario existen muchos servicios, pero en este post vamos a ver uno muy simple y, además, gratuito (con ciertos límites): IPInfoDB.

El servicio ofrecido por IPInfoIDB requiere que nos registremos para conseguir un API KEY, pero este registro es completamente gratuito.

Una vez completado el registro, el código necesario para geolocalizar una IP en C# es muy sencillo:

public Location GeoLocate(string ip)
{
    const string API_KEY = "YOUR_API_KEY";

    var url = "http://api.ipinfodb.com/v3/ip-city/?key={0}&ip={1}&format=xml";
	
    var doc = XDocument.Load(string.Format(url, API_KEY, ip));

    return new Location
    {
        CountryCode = doc.Descendants("countryCode").First().Value,
        CountryName = doc.Descendants("countryName").First().Value,
        Region = doc.Descendants("regionName").First().Value,
        City = doc.Descendants("cityName").First().Value,
        ZipCode = doc.Descendants("zipCode").First().Value,
        Latitude = decimal.Parse(doc.Descendants("latitude").First().Value, CultureInfo.InvariantCulture),
        Longitude = decimal.Parse(doc.Descendants("longitude").First().Value, CultureInfo.InvariantCulture)
    };
}

Como véis no hay mucha complicación, cargamos en un documento XML los datos devueltos por el servicio y construimos un objeto Location a partir de la información contenida en el documento XML.

No tan rápido

Antes de empezar a usar este código en tu próxima aplicación, hay que tener en cuenta algunas limitaciones:

• El código anterior es código de demo. No hay ningún tipo de control de errores, y lo último que querrías es que tu aplicación dejase de funcionar porque el servicio de IPInfoDB está caído. Una buena opción cuando uno se integra con este tipo de servicios es aplicar el patrón disyuntor (circuit breaker).
• Utilizar esta técnica para geolocalizar IPs requiere una llamada a un servidor externo, y esa llamada puede ser más lenta de lo que nos gustaría. Es importante tenerlo en cuenta y sería muy recomendable realizarla de forma asíncrona (y con un timeout, por cierto) para evitar bloquear nuestra aplicación eternamente.

Conclusiones

Geolocalizar una IP usando C# es muy sencillo con servicios como IPInfoDB y puede ayudarnos a hacer aplicaciones más inteligentes que resulten más agradables de utilizar para nuestros usuarios, pero no hay que olvidar que estamos introduciendo una dependencia sobre un servicio externo y hay infinidad de cosas que pueden salir mal, por lo que nuestra aplicación deberá estar preparada para tratar con estas contingencias.

No hay posts relacionados.