Por fin

Ayer, después de tres largos años que terminé la carrera, por fin entregué el proyecto. Ha sido, y soy sincero, un tiempo en el que no ha habido un único día en el que me fuese a la cama sin pensar en que lo tenía pendiente, que me debería poner en serio, pero por una cosa u otra nunca lo hacía. En unas ocasiones el trabajo, en otras que las ganas escaseaban, de nuevo el trabajo :), etc, etc,etc.

Cuando este verano comenzamos la jornada continua me propuse que, costara lo que costara, me pondría en serio,y, así ha sido; por fin lo he terminado. Además, y a  nadie le amarga un dulce, me han calificado con matrícula de honor, con la que la alegría ha sido un poquito mayor :).

Desde aquí, y aunque ya lo he hecho en persona, me gustaría darle las gracias a mis padres por insistir hasta la saciedad para que terminase; muchas gracias! Y como no a Iratxe, porque sin ella todo estoy seguro de que todo ésto no hubiese sido posible.

También me gustaría agradecer a Luciano, mi director de proyecto, la paciencia que ha tenido conmigo, cambiándole de proyecto cada dos por tres jajaja.

Muchas gracias a todos!!

Hasta pronto

PD: tal y como os comentaba en algún post anterior ahora le dedicaré más tiempo al blog así que a ver si logro hacer de este pequeño sitio en Internet un poquito más interesante

Análisis de Redes Sociales

Las redes sociales y el análisis de la mismas se han convertido en algo muy popular. Asi por ejemplo, aplicaciones como Twitter,Facebook o Linkedin han adquirido una popularidad desmesurada en los tiempos que corren. Personalmente, y esta es mi humilde opinión, creo que debería hacerse un uso controlado de las mismas (del mismo modo que el resto de Internet, claro está), puesto que ,aunque pueden ser una herramienta sumamente beneficiosa, un uso inadecuado de las mismas podría acarrear grandes problemas. De todos modos,aunque relacionado con las redes sociales, éste no era el asunto inicial de esta entrada (podríamos hablar horas acerca de ésto).

Hace poquito, para estrenar de manera oficial el entorno de desarrollo integrado que he construido para R (os contaré alguna cosilla relacionada con dicho entorno en el futuro), he escrito un pequeño programa que realiza un análisis de redes sociales.

El programa es bastante sencillo. Os resumo de manera esquemática lo que realiza:

• Recupera los últimos N twetts que contengan la etiqueta TAG.
• A partir los anteriores N twetts, recupera los usuarios (eliminando repetidos) que han realizado dichos twetts.
• Para cada uno de los usuarios anteriores recupera su red de contactos (siempre y cuando su red no esté protegida).
• Con toda la información anterior, realiza la construcción de una red en la que se pueden como se relacionan entre sí todos los contactos.

Es un análisis bastante sencillo (mis conocimientos de estadística/matemáticas son prácticamente nulos), pero me ha servido para probar el entorno recién construido así como para enseñar un poco las capacidades de R y las ventajas que aporta su utilización.

A continuación os pongo algunas imágenes de los resultados obtenidos.

La siguiente red está construida a partir de los últimos 10 twitts que contenían el tag eclipse:



En esta ocasión la red está construida a partir de los últimos 10 twitts que contenían el tag rstats:

En este último ejemplo la red está construida a partir de los últimos 10 twitts que contenían el tag erlang:

Podeis obtener una copia de trabajo desde la siguiente URL del servidor subversion en el que se encuentra alojado:

https://reclipse.googlecode.com/svn/DemoProject/trunk/demo-r-module/source/twitter/Twitter-SNA.R

Hasta pronto!

JDT Weaving Service (y II)

Tal y como os había prometido en el post anterior, ahora os dejo un pequeño proyecto con un único archivo que contiene un programa de ejemplo del lenguaje que nos hemos inventado en la entrada previa.

Podeis obtener una copia de trabajo desde la siguiente URL del servidor subversion en el que está alojado:

http://reclipse.googlecode.com/svn/trunk/com.blogspot.miguelinlas3.ajdt.demoexample

Gracias al plugin cosntruido en la entrada anterior, el archivo de código fuente obtenido en el checkout anterior se visualizaría del siguiente modo:


Como veis, hemos integrado nuestro lenguaje de ejemplo en el modelo JDT de Eclipse de una manera relativamente sencilla.

Posiblemente ahora comienze a tener algo más de tiempo libre así que intentaré aumentar la frecuencia de los posts. Puede que en las siguientes entradas cambiemos un poco estas últimas entradas dedicadas a los lenguajes y sus entornos y veamos algo más "empresarial".

Hasta pronto!

JDT Weaving Service

Tal y como comentabamos hace uno o dos posts, algunos equipos como AJDT o Scala IDE construyen el entorno de desarrollo para Eclipse basándose en el servicio de tejido de JDT (JDT Weaving Service).

Vamos a realizar un pequeño ejemplo para nuestro lenguaje (ficticio) de programación Demo, que corre sobre la máquina virtual de Java, integrándolo en el modelo JDT (voy a asumir que se disponen de una serie de conocimientos básicos de Eclipse).

En primer lugar necesitaremos tener disponibles las siguientes dependencias en nuestro entorno de desarrollo:

• Eclipse 3.5 o superior.
  

• AJDT 1.6.4 o superior (http://download.eclipse.org/tools/ajdt/35/update).
  

• Servicio JDT de weaving debe estar activado.
  

Con el objetivo de facilitar el seguimiento de este pequeño ejemplo creo que será mejor disponer del proyecto desde el principio, por lo que, desde vuestro cliente subversion preferido obteneis una copia de trabajo desde la siguiente dirección:

http://reclipse.googlecode.com/svn/com.blogspot.miguelinlas3.ajdt.demo/trunk/

(y haceis un Import del proyecto en el Eclipse si habeis obtenido la copia de trabajo desde un cliente externo).

Una vez disponemos del proyecto accederemos al archivo plugin.xml y veremos los siguientes puntos de extensión:

Los puntos de extensión org.eclipse.contribution.weaving.* nos permiten extender el modelo JDT, integrando en él los componentes de nuestro lenguaje.

La clase principal es DemoSourceProvider, la cual contribuye al modelo mediante el punto de extensión org.eclipse.contribution.weaving.jdt.sourcetransformer.

El objetivo principal de la clase anterior consiste en traducir nuestro lenguaje (completamente absurdo :) ). Si la definición de un archivo de código fuente de nuestro lenguaje fuese algo como lo siguiente:

name: MyDemo {
x: 10
y: 5
z: 12
}

el traductor intentará convertirlo en algo como lo que sigue:

class MyDemo {
int x= 10;
int y= 5;
int z = 12;
}

Intentad darle un vistazo al código (son cuatro clases con muy poco código) y mañana os dejaré un proyecto de ejemplo que haga uso de esta construcción para que veais que realmente se integra nuestro absurdo lenguaje!

Hasta pronto!

Definición de DSL

Los DSL's son lenguajes de programación específicos desarrollados para resolver problemas en un dominio especializado.

El dominio anterior podría ser multitud de cosas diferentes, por ejemplo, podría ser relativo a la industria: inteligencia analítica, banca, seguros, marketing, . . . o relativo a la tecnología: JEE,.Net, servicios de mensajes, arquitectura o bases de datos.

Existe tres tipos diferentes de DSL: externos, internos, y workbench languages

donde cada uno de los anteriores tiene una audiencia definida, y, por normal general, no suelen solaparse:

• Los DSL externos utilizan un lenguaje diferente al de la aplicación que los está utilizando. Generalmente tienen un lenguaje específico, aunque en otras ocasiones, utilizan otra sintáxis diferente (XML es el ejemplo más claro). Algunos ejemplos de DSL externos que seguramente os puedan sonar son: SQL,awk o los ficheros xml de configuración de herramientas como Hibernate o Spring.

• Los DSL's internos utilizan el mismo lenguaje de propósito general más utilizado en el sistema, aunque haciendo un uso limitado del mismo. Se utiliza un subconjunto de las construcciones del lenguaje, enfocadas a un aspecto determinado de la aplicación. Tanto Groovy como Ruby han generado una gran cultura en la construcción de DSL's. Mucha gente ve los frameworks más populares asociados a los dos lenguajes anteriores (Grails y Rails) como una colección de DSL's.

• Language Workbenches (este término ha sido acuñado por Martin Fowler) son IDE's diseñados para la construcción de DSL's. Estas herramientas permitirán definir la sintaxis del lenguaje, junto a editores y generadores. Los primeros nos permitirán disponer de sofisticados entornos de programación para los DSL's, de manera idéntica a los actuales IDE's. Ejemplos de este tipo pueden ser los proyectos de eclipse de GMF o las herramientas de ANTLR para Eclipse.

En próximos post intentaremos profundizar en el tema.

Hasta pronto!

New Languages. Building IDE's

En los últimos años han surgido muchos lenguajes similares a Java que se ejecutan sobre la propia máquina virtual de este último (JVM) lo cual es un indicador bastante fiable de cual será el futuro del desarrollo de aplicaciones sobre esta plataforma.

Sin embargo, Eclipse y su solución JDT, no ofrecen soporte para la integración de estos nuevos lenguajes en su modelo subyacente. Por ejemplo, no existe un modo de incluir jerarquías de tipos,jerarquías de llamadas, etc de manera directa.

Una aproximación utilizada por muchos entornos de desarrollo de lenguajes actuales, como por ejemplo el caso de Scala, es la utilización de servicio de tejido de JDT. Las características principales son:

• Utiliza AspectJ añadiendo puntos de unión al modelo JDT

• Se encapsula en puntos de extensión de Eclipse, haciéndolo extensible a terceras partes.

• Utiliza un proyecto de Eclipse conocido como Equinox Aspects que soporta el proceso de tejido en tiempo de carga en un entorno OSGI.

La construcción de entornos de desarrollo para otro tipo de lenguajes, que podríamos denominar de scripting, como puede ser JavaScript,Python,Tcl o Ruby se puede basar en un enfoque diferente al anterior, mediante el uso del proyecto DLTK de Eclipse (www.eclipse.org/dltk).

En próximas entradas analizaremos las claves de la construcción de un IDE para el lenguaje de programación R (www.r-project.org).

Hasta pronto!

Modelo de Joint Point (y II)

El modelo de "joint point" que introducíamos en el post anterior está compuesto de dos partes claramente diferenciadas: los "join point", que no son más que puntos en la ejecución de un programa, y los "pointcuts", un mecanismo de selección de los puntos anteriores.

Imaginemos por un momento que nos encontramos desarrollando un sistema que necesita gestión de la seguridad, algo muy común en el mundo en el que nos movemos, y, que, debido a la naturaleza transversal del mismo, elegimos AOP como enfoque principal nuestra solución. ¿Cuáles son los pasos que deberíamos seguir?

A continuación esbozamos, de manera esquemática, los pasos que se deberían seguir:

• Identificar los puntos del sistema que necesitan ser protegidos, comprobando, antes de realizar el acceso, que el usuario que está realizando el acceso está autenticado y tiene los privilegios necesarios para hacerlo. En resumen, estamos identificando los "joint point" que requieren ser securizados.
  

• Construiremos un pointcut (o varios, todos los que sean necesarios), que permitan la selección de los "joint point" descritos en el punto anterior.

• Construiremos un aspecto que encapsule toda la lógica de seguridad requerida.

Esto es un mera introducción a los conceptos que componen un sistema orientado a aspectos, concretamente AspectJ. En el siguiente post analizaremos las categorías de joint points expuestas por AspectJ y el modo en el que podemos realizar la definición de los pointcuts que las capturen.

Modelo de Joint Point (I)

El modelo de "joint point" está compuesto de dos partes claramente diferenciadas: los propios "join point", que no son más que puntos en la ejecución de un programa, y los "pointcuts", un mecanismo de selección de los puntos anteriores.

Imaginemos por un momento que nos encontramos desarrollando un sistema que necesita gestión de la seguridad, algo muy común en el mundo en el que nos movemos, y, que, debido a la naturaleza transversal del mismo, elegimos AOP como enfoque principal nuestra solución. ¿Cuáles son los pasos que deberíamos seguir?

• Identificar los puntos del sistema que necesitan ser protegidos, comprobando, antes de realizar el acceso, que el usuario que está realizando el acceso está autenticado y tiene los privilegios necesarios para hacerlo. En resumen, estamos identificando los "joint point" que requieren ser securizados.

• Construiremos un pointcut (o varios, todos los que sean necesarios), que permitan la selección de los "joint point" descritos en el punto anterior.

• Construiremos un aspecto que encapsule toda la lógica de seguridad requerida.

Los conceptos anteriores son sumamente importantes dado que componen la base de AOP. A lo largo de los siguientes postz profundizaremos en cada uno de ellos.

Para terminar esta entrada simplemente analizaremos la definición de joint point:

Un join point es un punto de ejecución en un sistema. Así por ejemplo, el acceso al campo de una clase, la ejecución de una función o una sentencia for son ejemplos claros de join points.

AspectJ solamente expone un subconjunto de todos los posibles joint points, limitando de este modo, el acceso a las construcciones más estables.

En el siguiente post analizaremos con un poco más de profundidad los pointcuts,para, posteriormente, analizar las categorías de joint points existentes.

Hasta pronto,

Migue

AOP en el mundo real

Hace tiempo había escrito algún post relativo a AOP y AspectJ y nunca he tenido la ocasión de continuar con aquella de serie de posts, así que . . . . intentando retomar la dinámica de escribir aquí con una frecuencia aceptable; continuemos aquella miniserie con una visión del uso en el mundo real de AOP.

• Aplicaciones empresariales .Gestión de transacciones, seguridad, auditoría, monitorización, gestión de la concurrencia, manejor de errores y un largo ecétera son funcionalidades transversales en la mayoría de aplicaciones empresariales. Aquellas aplicaciones que usen Spring como base de su arquitectura ya estarán utilizando algunos de los aspectos que vienen facilitados por el framework. Gracias a las anotaciones, concretamente @Aspect, la construcción de aspectos se ha convertido en una tarea habitual.
  

• Web y servidores de aplicaciones. Aplicación de políticas, FFDC, recolección de contextos,trazabilidad o monitorización son algunas de las funcionalidades basadas en AOP que podemos encontrar en los servidores de aplicaciones. Spring Source DM Server y TC Server son un claro ejemplo de estas funcionalidades.
  

• Frameworks. Gestión de transacciones y seguridad son habitualmente implementadas mediante aspectos. Asimismo, otras utilizaciones de los aspectos podría ser la inyección de dependencias en en objetos de dominio. Para obtener un amplio abanico de posibilidades de uso de los aspectos, el usuario podría visitar los proyectos de Spring Roo o Apache Magma.
  

• Herramientas de monitorización. El uso de aspectos facilita también la construcción de herramientas de monitorización. Muchas herramientas utilizan AspectoJ como tecnología subyacente: Glassbox,Perf4J,Contract4J,JXInsight o MaintainJ son algunos de los ejemplos.
  

• Compiladores e integración de IDE's.La propia gente de AspectJ utiliza la propia tecnologia para extender el compilador de JDT de manera que sea capaz de sopotar las nuevas construcciones. AJDT utilizan un proceso de weaving a través de una implementación basada en OSGI ofrecida por el proyecto Equinox. Scala IDE en Eclipse utiliza un enfoque similar para la construcción de su entorno de desarrollo.

En el desarrollo de nuestros productos software nosotros también hacemos uso de AOP para arquitectar nuestras soluciones (además de las enumeradas anteriormente), así por ejemplo, utilizamos AspectJ para la gestión del estado "dirty" de un metamodelo, o para la generación de las licencias de uso de nuestros productos.

Great ebook

An amazing reading about software developement.


Ebook link

Interviewers with 15 of the most interesting programmers:

• Frances Allen: Pioneer in optimizing compilers, first woman to win the Turing Award (2006) and first female IBM fellow
• Joe Armstrong: Inventor of Erlang
• Joshua Bloch: Author of the Java collections framework, now at Google
• Bernie Cosell: One of the main software guys behind the original ARPANET IMPs and a master debugger
• Douglas Crockford: JSON founder, JavaScript architect at Yahoo!
• L. Peter Deutsch: Author of Ghostscript, implementer of Smalltalk-80 at Xerox PARC and Lisp 1.5 on PDP-1
• Brendan Eich: Inventor of JavaScript, CTO of the Mozilla Corporation
• Brad Fitzpatrick: Writer of LiveJournal, OpenID, memcached, and Perlbal
• Dan Ingalls: Smalltalk implementor and designer
• Simon Peyton Jones: Coinventor of Haskell and lead designer of Glasgow Haskell Compiler
• Donald Knuth: Author of The Art of Computer Programming and creator of TeX
• Peter Norvig: Director of Research at Google and author of the standard text on AI
• Guy Steele: Coinventor of Scheme and part of the Common Lisp Gang of Five, currently working on Fortress
• Ken Thompson: Inventor of UNIX
• Jamie Zawinski: Author of XEmacs and early Netscape/Mozilla hacker

I think it's a recommended reading!

Hype Cicle

Hype Cycle es una representación gráfica del grado de madurez, adopción y aplicación en el mundo real de una tecnología determinada.


Si comprendemos bien el gráfico anterior, y la posición que la tecnología que estamos considerando ocupa en el mismo, dispondremos de una visión mucho más ajustada de los riesgos y beneficios a los que nos estamos exponiendo.

La interpretación de la curva Hype Cicle implica cinco fases diferentes las cuales analizaremos a continuación.

• Activación de la tecnología: Este es el momento en el que la tecnología aparece con la intención/promesa de solucinar un conjunto determinado de problemas. Podría ser el anuncio de un nuevo producto o la liberación de una nueva versión de un produco ya existente.
  

• Expectativas irreales ("peak"):Durante esta fase la tecnlogía se hace muy popular. Todo el mundo quiere conocerla y tiene una opinión sobre ella aunque muy poca gente la utiliza en aplicaciones reales.

• Desilusión: Esta es la fase de ciclo Hype en la que la tecnología comienza a perder toda la atención que se le había prestado hasta el momento.
  Mientras que los equipos que la adoptaron desde sus inicios continuan utilizándola con el objetivo de obtener una ventaja competitiva, muchos otros comienzan a observar con cierto escepticismo. Nuevas tecnologías aparecen en escena aportando soluciones diferentes al mismo problema. Resulta interesante destacar que muchos de estos nuevos competidores están en la fase de "expectativas irreales".

• Viendo la luz:Numerosos factores intervienen en el desarrollo de esta fase: maduración de la tecnología, cambios en la misma para acercarse a la realidad, búsqueda de un contexto de uso en el que realmente se cause impacto o la "desilusión" con otras alternativas, que en su momento fueron competidores, son algunas de ellas.

• Plena productividad:La última fase definida en el ciclo Hype. En esta situación la tecnología está ampliamente difundida y se utiliza en las solución de problemas para los que ofrece una gran respuesta. Será en esta fase cuando se produzca una aceptación mavisa de la tecnología.

Si a alguien le interesa, Harvard Business Press publicó el libro Mastering the Hype Cycle: How to Adopt the Right Innovation at the Right Time.

Hasta pronto

Migue

El puto amo

Hay cosas que no cambian nunca:

Sintiendolo mucho no tengo mas tiempo para el blog, espero que dentro de poquito pueda dedicarle todo el tiempo que me gustaria.

Un abrazo!

C++ Singleton Pattern (y II)

Y ya que estamos, os dejo la segunda parte que también había escrito hace bastante tiempo :)

Vamos a continuar con el patrón de diseño Singleton que habíamos comenzado en un post anterior. Intentaremos añadir alguna que otra mejora. Vayamos poquito a poquito:

Un primer cambio que podríamos realizar sería el de retornar una referencia en lugar de un puntero en el método getInstance(); de este modo evitaríamos que el usuario que obtiene una referencia del objeto intentase aplicarle el operador delete. El prototipo del nuevo método podría ser algo parecido a lo siguiente:

static singletonPattern & getInstance();

Ahora podríamos pensar en que ocurre cuando se destruye el singleton.Realmente no se trata un memory leak tradicional sino un resource leak. El singleton podría haber adquirido diversos recursos del sistema operativo como un socket,un semáforo,...... Con el objetivo de solucionar este problema, Scott Meyers facilitó una solución sencilla (y muy elegante): en lugar de almacenar un puntero a un objeto de tipo Singleton instancial una variable local estática del siguiente modo:

singletonPattern & getInstance(){
static singletonPattern instance;
return instance;
}

El fragmento anterior se conoce como el singleton de Meyers y se basa en, tal y como describe Alexandrecu en su libro Modern C++ Desing:Generic Programming and Patterns Applied, "some compiler magic": un objeto estático de una función es inicializado, en tiempo de ejecución, en el momento de la primera pasada de la definición.

Este par de soluciones son, aparentemente sencillas, y pueden ayudarnos a construir un Singleton mucho más robusto.

En el libro de Alexandrescu mencionado anteriormente plantea otros problemas tales como las referencias muertas (a las cuales aplica soluciones elegantes e ingeniosas) o los problemas derivados de la interacción de los hilos y los singleton.

Desde mi punto de vista el singleton es un patrón de diseño muy sencillo conceptualmente pero que, llegada la hora de implementarlo, no resulta tan evidente como pueda parecer en un principio.

C++ Singleton Pattern (I)

Os dejo un post que había escrito hace mucho tiempo en otro blog; está dedicado a C++ y a los patrones de diseño.

Os propongo una implementación del patrón de diseño Singleton (uno de los patrones de diseño más simples aunque creo que muchas veces lo utilizamos de forma no demasiado apropiada).

El patrón anterior nos garantiza que, desde el momento en que instanciamos un objeto de dicha clase, será esa la única instancia que exista de dicho objeto. Existen multitud de libros acerca de patrones de diseño y con multitud de aplicaciones de los mismos. Yo desde aquí nada más pretendo dejaros mi experiencia y el uso que yo le he dado en mis aplicaciones. Por ejemplo, este patrón lo he utilizado en el desarrollo de un compilador para representar los builtin type. Vamos allá:

En primer lugar definimos la clase singletonPattern y el método que nos permitira obtener una referencia al mismo (hacemos que el constructor sea privado para que no se puedan crear objetos de ese tipo):

class singletonPattern{
private:
/// unique instance of the object
static singletonPattern * instance;
/// Default Constructor
singletonPattern(){}

public:
/*!
Returns the reference
to the unique instance of the object
(if it's the first time create de reference)
*/
static singletonPattern * getInstance(){
if(instance == NULL)
instance = new singletonPattern();
return instance;
}
};

// init the static member
singletonPattern * singletonPattern :: instance = NULL;

El código anterior no estaría completo dado que nos queremos asegurar de que nuestra instancia sea única por lo que tendremos que implementar el constructor de copia y el operador de asignación (no tiene sentido el operador de asignación en el singleton) como privados dentro de nuestra clase singletonPattern. Algo como lo que sigue:

/// Copy Constructor
singletonPattern(const singletonPattern & sp){}

/// Assignement Operator
singletonPattern & operator=(singletonPattern & sp){
return *this;
}

Si quisieramos utilizar esta clase en uno de nuestros programas no tendríamos más que declarar un objeto tal y como a continuación se muestra:
singletonPattern * singleton = singletonPattern::getInstance();

Y listo. Con esto tendremos nuestro patrón de diseño Singleton listo para disponer de el cuando deseemos.

Desde el siguiente enlace podeis descargaros el código fuente completo junto con un makefile:singletonPatterC++.

Hasta pronto!

Vigo & Madrid

Some weekends ago we have been in Vigo and Madrid (to a company meeting) :)

Bye!

Frameworks

Some weeks ago an interesting book arrives to my personal library :)

Practical API Design. Confessions of a Java.Framework Architect

Althought last weeks my enjoy time is not enought to read the whole book i have been reading the starting chapters. Anyone has read it completely?

Bye!

Groovy Metaclass

One of my favourites Groovy´s features is its MOP architecture. It allow us introducing new methods at runtime thanks to the metaClass.

We can define a new class

class SampleClass {

// class field

def propertyOne

// one sample Closure

def closureOne = {

println "I´m the closure one"

}

}

Now we add a new method at runtime

SampleClass.metaClass.runtimeAddedMethod = {

println "I´m runtimeAddedMethod"

}

Declare a new instance an test all the methods

def instance = new SampleClass()

Call to the closure declared in class definition

instance.closureOne()

Call to the method added at runtime

instance.runtimeAddedMethod()

We add a method to the "instance" too

instance.metaClass.instanceRuntimeAddedMethod = {

println "I´m the method added at runtime to a single instance"

}

instance.instanceRuntimeAddedMethod()

Bye!!

Amsterdam Photos

Some photos of our last trip to Amsterdam:

Chihi: Art essence (trying to become famous jajajaja)

i amsterdam

all the travelers (I was tooking the photo)

Ita

Dam Place

Dam Place

Ita again

Bye!

Amsterdam Trip

Next few days (till next Monday) we are going to be in Amsterdam . I´ll upload some pictures to the back.

Bye!

PD: I have some incoming posts: R grammar and ANTLR (PFC), AspectJ examples, Groovy/Grails introduction and something more.

AOP Benefits

Muchas de las críticas sobre la metodología AOP argumenta que en muchas ocasiones es demasiado complejo.

Personalmente, creo que al igual que cuando otras metodologías dieron el salto, como por ejemplo OOP, la novedad hace de ella su principal handicap.

Algunos de los beneficios del uso de una metodología AOP:

• Responsabilidades claramente diferenciadas . Cada módulo es el responsable de su funcionalidad principal; dejando a un lado los conceptos transversales (croscutting concerns). Así por ejemplo, un módulo cuyo principal cometido es implementar la lógica de acceso a datos de un sistema de ventas por internet, no tendrá que preocuparse de realizar pooling sobre la base de datos o de la transaccionalidad. Gracias a esta clara asignación de responsabilidades conseguimos una alta trazabilidad entre los requisitos y su correspondiente implementación.

• Incremento de la modularidad . Utilizando AOP conseguimos manejar cada uno de los conceptos de manera independiente con un acoplamiento mínimo. Incluso aunque tengamos presentes conceptos transversales que afecten en todos los ámbitos del sistema, la implementación resultante es modular.

• Retraso en las decisiones de diseño . Cuando se arquitecta un nuevo sistema siempre aparece el siguiente dilema: ¿debemos realizar un diseño sumamente complejo y detallado que intente abarcar todas las funcionalidades,incluso las futuras? o, por el contrario, ¿debemos arquiectar una solución que se corresponda con la situación actual?.

  Gracias a AOP, el arquitecto de la solución, puede retrasar la toma de determinadas decisiones de diseño dado que los futuros requerimientos se implementarán en aspectos independientes.

• Mejoras/Evoluciones más sencillas . AOP permite añadir una nueva funcionalidad sin más que desarrollar un nuevo aspecto (el cual no afecta al núcleo del sistema). Gracias a ello, el tiempo de respuesta ante nuevos requerimientos disminuye notablemente puesto que la implentación y diseño de los nuevos requisitos no supondrán, idealmente, una modificación del núcleo del sistema que estamos construyendo.

• Reutilización del código .AOP establece cada uno de los aspectos es un módulo independiente, de modo que resultan independientes entre si. En general, cada uno de ellos no suelen tener conocimiento del resto de elementos que conforman el sistema final.

  El único elemento consciente del acoplamiento entre los diferentes módulos son las reglas de tejido (weaving rules) , de modo que, si cambiamos éstas, podemos componer un sistema final completamente diferente.

• Reducción de costes. Las características descritas en los puntos anteriores generan sistemás desarrollos mucho más rápidos. Asimismo, eliminando la necesidad de modificar múltiples módulos para la implementación de un nuevo concepto que afecta al sistema completo, AOP provoca que dicha implementación sea más barata.

• Areas de conocimiento. Permitiendo que los desarrolladores estén centrados en su especialidad lograremos que el coste del desarrollo disminuya puesto que estaremos concentrando los esfuerzos.

En siguientes post veremos una introducción a AspectJ para adentrarnos un poquito más en el mundo de la orientación a aspectos.

Hasta pronto!