Cerrado por vacaciones

Últimamente, en la medida que el poco tiempo que tengo me lo permite, había vuelto a postear con una frecuencia que podríamos calificar de "aceptable" :).

Lamentándolo mucho (realmente no, pero queda bien eh?? jejejej) esta misma tarde me marcho de vacaciones a Stuttgart y Berlín hasta la próxima semana por lo que posiblemente no tengais noticias mías hasta finales de la próxima semana.

Hasta pronto!

Migue

Si todo va bien seguiré actualizando twitter y similares para no perder las buenas costumbres :)

AOP Pointcuts Definition

Durante entregas anteriores hemos analizado los beneficios de la orientación a aspectos, su Hype Cicle, o el modelo de joint point entre otras características. El conjunto formado por el post actual y el siguiente analizarán los conceptos básicos de los pointcuts junto una serie de sencillos ejemplos.

Inicialmente, deberíamos tener claros los siguientes conceptos:

• Pointcuts anónimos o con nombre: Se permite la declaración de pointcuts de cualquiera de los dos tipos. Los primeros son similares a las clases anónimas, y por tanto se definen en el lugar en el que se van a utilizar. En el caso de los segundos, podremos referenciarlos desde múltiples lugares, permitiendo de este modo su reutilización.
• Operadores: AspectJ proporciona el operador unario de negación (!) y dos operadores binarios: && y ||, gracias a los cuales se permite construir reglas de matching complejas mediante la combinación de pointcuts más sencillos. Tanto la semántica como la precedencia es la misma que en el lenguaje Java. Así por ejemplo, en el caso del operador binario &&, se seleccionarán aquellos joint points que concuerden con los dos pointcuts que actúan como operando.

Las signaturas son la base de la definición de los pointcuts. El lenguaje debe facilitar una manera sencilla que permita definir criterios de selección sobre los diferentes aspectos transversales que estamos implementando. En el caso de AspectJ, se utilizan expresiones regulares (wildcards) en combinación con las signaturas. Los siguientes wildcards son soportados:

• * especifica cualquier número de caracteres, exceptuando el punto (.). En la signatura de un tipo denota una parte de un tipo o de un paquete. En otros patrones denota una parte del nombre (por ejemplo en métodos o campos).

• .. determina cualquier número de caracteres, incluyendo en este caso cualquier número de puntos (.). En la signatura de un tipo representa cualquier paquete o subpaquete. En la signatura de un método representa cualquier número de argumentos.

• + denota cualquier subtipo de un tipo determinado.

Hasta este momento hemos estudiado, de manera resumida, los elementos básicos para la definición de los pointcuts; en la siguiente entrada describiremos, a través de una serie de ejemplos, los diferentes patrones de signaturas ofrecidos por AspectJ que pueden ser utilizados para seleccionar diferentes joint points.

Hasta pronto!

R-Eclipse: some screenshots

En el post anterior comentaba someramente la arquitectura y componentes de R-Eclipse además de las principales herramientas que he utilizado durante el desarrollo del mismo. En esta entrada os mostraré algunas capturas de pantalla que ilustran el aspecto general del IDE así como alguna de sus funcionalidades más relevantes.

• Inclusión de un nuevo intérprete en el entorno:

• Primera página en la creación de un proyecto R:

• Compleción de código: Intellisense y plantillas

• Outline view

• Script explorer

• Editor de código fuente R

• Ejecuciones de tipo R

Las capturas anteriores dan una idea general de las funcionalidades principales del entorno de desarrollo (podéis acceder a más capturas de pantalla en el módulo de documentación disponible en el sistema de control de versiones).

R-Eclipse 1.0

Hace un tiempo comencé a construir un entorno de desarrollo integrado (IDE) para el lenguaje de programación R, y finalmente he decidido liberar una primera versión. El componente dista mucho de ser perfecto (y completo) pero sinceramente me siento muy orgulloso del trabajo realizado.

La herramienta está basada en la arquitectura de plugins de Eclipse, constando de cinco módulos (plugins/bundles) que a continuación describo de manera muy resumida:

• Plugin r.core: núcleo de la aplicación. Incluye el analizador léxico y sintáctico del lenguaje, infraestructura básica para la construcción y recorrido del AST, indexado, mixin parsers, etc.
• Plugin r.completion: añade a la herramienta la capacidad de realizar la compleción de código.
• Plugin r.formatter: añade a la herramienta la capacidad de ordenación e indentación del código fuente.
• Plugin r.launching: añade a la herramienta la capacidad de ejecución integrada de los programas R.
• Plugin r.ui: contiene la mayor parte de componentes gráficos de la herramienta. Gestión de preferencias de formateo/indexación, editor R, preferencias de compleción de código, resaltado de palabras reservadas, templates, etc
• Adicionalmente existe un módulo de documentación que contiene información de diversa índole

He utilizado maven como herramienta de gestión de dependencias y control del proyecto aunque en este mismo instante está un poco "manga por hombro" puesto que he estado haciendo varias pruebas para la generación de la feature final mediante  Buckminster.

Soy consciente de la existencia de varios bugs (y todos los que yo no habré detectado :) ) y de muchas características que podrían añadirse para mejorar la herramienta. A continuación resumo una pequeña lista de defectos/mejoras:

•  Tal y como indicaba anteriormente, intentaré migrar por completo a Buckminster.
• Añadir más pruebas (tanto unitarias como de integración)
• Mejorar la compleción de código: ampliar los lugares donde se habilita la compleción del mismo y mejorar algunas de las características ya existentes.
• Inclusión de un motor de ejecución remoto, de modo que se permita configurar un intérprete en una máquina diferente que sea capaz de ejecutar nuestros scripts R.
• Inclusión de una consola interactiva. En la actualidad la consola simplemente integra los resultados de las ejecuciones de nuestros scripts, pero no permite la interactividad.
• Incluir un depurador de código. Puede que sea la más complicada, pero, personalmente, creo que es la características más interesante junto con la ejecución remota descrita en el punto anterior.
• Programación visual: diagrama R integrado. Creación de un diagrama que nos permita construir nuestros programas de manera gráfica mediante una paleta de funcionalidades. Estaría basado en Eclipse GMF y puede que entonces también se distribuyera la herramienta como cliente rico (Eclipse RCP)
• . . . . 

Se puede obtener acceso al código fuente en modo lectura desde la siguiente URL: http://reclipse.googlecode.com/svn/trunk/. Si alguien quiere participar le puedo dar acceso al repositorio en modo escritura.

Hasta pronto!

PD: en la siguiente entrada añadiré unas capturas de pantalla para que se pueda tener una perspectiva general de la herramienta

Probando con Marick

El pasado sábado tuve la ocasión, y suerte, de asistir al evento Probando con Marick y, verdaderamente,  resultó muy entretenido.

En la primera parte del evento, y partiendo de una aplicación que había desarrollado para su  mujer, escenificó (mediante alguno de los asistentes que allí nos encontrabamos), un fujo de ejecución de una de las características que ya estaban implementadas, haciendo hincapié en el proceso de testing unitario y hablando acerca de como los mocks resultan de gran ayuda para llevar a cabo este tipo de pruebas. La segunda parte de la charla estuvo más centrada en conversar con él acerca de diferentes enfoques a la hora de llevar a cabo un desarrollo software.

Trabajo de un modo similar al descrito en su charla desde hace tiempo por lo que no me sorprendió nada de lo que contó; aunque nunca está mal oirlo de boca de uno de los gurús de la materia :).

Para quienes no lo conozcan, Brian Marick, es uno de los firmantes del Agile Manifesto y  un miembro activo de la comunidad ágil internacional.

Desde aquí, me gustaría agradecer a José Manuel Beas su esfuerzo por que iniciativas de este tipo prosperen en este país. Desde aquí te brindo mi ayuda para cualquier cosa en la que te pueda echar un cable.

Es una actualización aprisa y corriendo que me tengo que ir a clase!!

Hasta pronto!

AOP Pointcuts theory

Hace tiempo habíamos hablado acerca del modelo de joint point ofrecido por AspectJ, concretamente en estas dos entradas: Joint Point I y Joint Point II.

En los dos posts anteriores indicabamos que un join point no es más que 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 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.

Los pointcuts son construcciones que nos permite seleccionar joint points y recuperar su contexto. Veamos algunas de las características principales:

• Los pointcuts especifican un criterio de selección. Utilizaremos tipos, campos, métodos, anotaciones, etc para generar dichas definiciones. También podremos establecer condiciones en tiempo de ejecución que tendrán que cumplirse en el joint point seleccionado.
• Los joint point disponen de información en tiempo de ejecución. Determinados pointcuts pueden recolectar dicha información y pasársela al advice. Por ejemplo, la llamada a un método de un objeto tendrá disponible el propio objeto que realiza la llamada y los argumentos que se están pasando.
• En el caso del lenguaje Java, todos los elementos que componen un programa tienen una signatura. La utilización de patrones para dichas signaturas permiten a los pointcuts especificar las reglas de selección de los joint point que se desean capturar.

Los párrafos anteriores resumen de manera breve, y teórica, las características principales de los pointcuts. En la siguiente tabla se resumen las categorías principales de joint points expuestos por AspectJ.

Categorías de joint points expuestas por AspectJ (resumen)

Categoría	Joint Point Expuesto	Código que representa
Método	Execution	Cuerpo del método
Método	Call	Invocación del método
Constructor	Execution	Ejecución de la lógica de creación de un objeto
Constructor	Call	Invocación de la lógica de creación de un objeto
Acceso a un campo	Read	Lectura de un objeto o el campo de una clase
Acceso a un campo	Write	Escritura de un objeto o el campo de una clase
Proceso de excepciones	Handler	Bloque catch para manejar una excepción
Inicialización	Class init	Proceso de carga de una clase (class loading)
Inicialización	Object init	Inicialización de un objeto en un constructor
Inicialización	Object pre-init	Pre-inicialización de un objeto en un constructor
Advice	Execution	Ejecución de un advice

En la siguiente entrada (espero que sea lo más pronto posible :) ) analizaremos en detalle la estructura sintáctica de los pointcuts, haciendo especial hincapié en las signaturas.

Hasta pronto!

PD: Últimamente mi tiempo escasea (por llamarlo de alguna manera) pero eso dará para una nueva entrada.