Objective: to improve my English

I need to improve my written English (okay, the spoken as well :) ) so i have decided to change the language of blog posts for a while. I am not clear how long i will be able to do this but i am going to try it. All kind of corrections are (and will be) welcome.

It's true that i should increase my post's frequency in order to achieve it :)

Next blog post: OSGI in the enterprise.

Cheers!

Retomando la lectura

Estas últimas semanas he retomado, por fin, un hábito que desgraciadamente tenía demasiado oxidado: la lectura :). Aprovechando los trayectos en transporte público al trabajo y a la facultad he logrado leer algunos libros con los que me he divertido mucho:

• Assassini, de Thomas Gifford. Intrigas y asesinatos en el seno de la Iglesia ambientado en el año 1982.
• El nombre del viento de  Patrick Rothfuss. Una fantástica historia de aventuras y fantasía. Completamente recomendable. Esperando con ganas la siguiente entrega :).
• Releyendo El segundo mundo de Parag Khanna.

Hace poco le regalé el Kindle a la gordita así que puede que se lo robe en alguna que otra ocasión :) ¿Alguna sugerencia de algún libro interesante?

Adicionalmente tengo una pila de "otro tipo de libros/articulos" :) que sigue creciendo por momentos y no tengo ni idea de cuando podré ir dando salida a alguno de ellos. Me gustaría sacar algo de tiempo libre pero la verdad que últimamente no lo estoy haciendo demasiado bien. Puede que realmente tenga mi agenda demasiado ocupada o que no me estoy organizando todo lo bien que debería. No lo tengo claro.

Hasta pronto!

Migue

¿De regreso?

Intentar actualizar el blog de con una regularidad mínimamente aceptable se ha convertido en una tarea prácticamente imposible: mi nueva situación profesional, las clases (con sus correspondientes exámenes y trabajos), el inicio de mi tésis doctoral (que primero tendrá que ser tésis de máster :) si todo marcha como es debido), un par de ideas que me rondan la cabeza desde hace tiempo, . . ., bueno, bueno, ya vale, que acabo de releer desde el principio y ya me estoy agobiando.

En muchas ocasiones me pregunto que es lo que me motiva a escribir, aunque sea de vez en cuando, alguna entrada en este espacio (uno más entre los cientos de millones de bitácoras disponibles que circulan por la red) ; y siempre llego a la misma conclusión: me divierte.

Así es, sencillamente me divierto durante la escritura de un post. Posiblemente mucha gente no lo entienda, pero el tiempo que dedico a  contar cualquiera de las cosas que he escrito o escribiré (esperemos que así sea) en este blog hace que me lo pase bien. 

¿Y a qué viene ésto me pregunto ahora? Pues a nada en particular; estaba estudiando un poquito, no me concentraba demasiado y aprovechando que hace una buena temporada que no escribo pues . . . 

¿Y ahora? Pues no prometo nada. En la medida que mi tiempo libre me lo permita intentaré añadir nuevas entradas con temáticas relativas a algunas de las cosas a las que me estoy dedicando, por un motivo u otro, durante esta última temporada.

Un abrazo! 

Tiempo de cambios

Mañana por la mañana pasaré mis últimas horas como integrante de la plantilla de Neo Metrics; ha sido una decisión meditada y espero que el paso del tiempo demuestre que también ha sido acertada. Me marcho dejando grandes compañeros, pero creo que lo más importante de todo, me marcho dejando grandes amigos

He decidido dar un paso adelante y probar suerte así que a partir del próximo día 22 de Agosto comenzaré una nueva etapa profesional como integrante de INSA; creo que es un tren que no podía dejar pasar así que allí me voy con toda la ilusión del mundo.

La verdad que no me apetece seguir escribiendo :) así que ya postearé una entrada con un poco más de detalle dentro de unos días (a la vuelta de mis vacaciones que comienzan mañana mismo).

Hasta pronto!

Migue  

Platform as a Service overview

A sample overview of the main features of PaaS

Platform as a Service overview

View more presentations from Miguel Pastor.

HadoopDB: a brief overview

Not enough free time, so posting here is becoming a difficult task :(

HadoopDB

View more presentations from Miguel Pastor.

Aspect Oriented Programming Intro Guide

Hace tiempo que habíamos comenzado una serie de post relativos a la programación orientada a aspectos y los tenemos dispersos a lo largo de diferentes entradas. He decido recolectar todos los post publicados junto a los que estaban por venir y hacer una sola entrega.

Espero que os guste:

Está escrito en docbook por lo que si alguien está interesado en los fuentes no tiene más que pedírmelos.

Hasta pronto!

AOP: crosscutting (II)

Durante la última entrada de la serie relacionada con la programación orientada a aspectos analizamos el modo en el que se puede alterar el comportamiento de un sistema, analizando las categorías de advices y realizando una comparativa con los métodos de una clase. A lo largo de esta entrada realizaremos un análisis en profundidad de los advices.

Before advice
Este tipo de advices se ejecutan antes de la ejecución del joint point sobre el que actúan. En el siguiente ejemplo:

              before():execution(@Secured * * (..)){

            // asegurarse de que el usuario puede realizar la operación

              }                   

el advice realiza una comprobación de seguridad antes de que se produzca la ejecución de cualquier método anotado con Secured.

En caso de que el advice dispare un excepción, el joint point no se ejecutará. Este tipo de advices son comúnmente utilizados en aspectos tales como seguridad o trazabilidad.

After advice

Se ejecutan después de la ejecución del joint point sobre el que actúan.Dentro de esta categoría, AspectJ ofrece tres tipos de advices:

• Ejecución del advice independientemente del resultado de la ejecución del joint point.
• Ejecución del advice única y exclusivamente si el joint point ha finalizado correctamente.
• Ejecución del advice después que el joint point haya disparado una excepción.

Veamos en detalle cada uno de los tres tipos anteriores:

1.- Advice After
Este tipo de advices se ejecutan independientemente del resultado de la ejecución del joint point sobre el que actúan.Habitualmente se conoce a este tipo de advices como after finally puesto que su semántica es similar a la de un bloque finally.

El siguiente advice:

                after(): call(@Logging * ServiceManager.*(..)){

                   // registrar el resultado de la operación

               }

registra el resultado de todas las operaciones de la clase ServiceManager que estén marcadas con la anotación Logging, independientemente si retornan correctamente o terminan su ejecución de forma inesperada mediante el disparo de una excepción.

2.-Advice After Returning
En muchas ocasiones,será necesario ejecutar el código de nuestro advice única y exclusivamente cuando la ejecución del joint point haya terminado de forma correcta. Continuando con el ejemplo anterior:
               

            after () returning: call(@Logging * ServiceManager.*(..)){

              // registrar el resultado de la operación

            }

se seguirá registrando el resultado de las operaciones, siempre y cuando, la ejecución haya terminado correctamente, sin el disparo de ninguna excepción.

AspectJ ofrece una pequeña variante para este tipo de advices:

after() returning (ReturnType returnObject)

gracias a la cual se permite recuperar el objeto retornado por la ejecución del joint point dentro del advice. Veamos un pequeño ejemplo ilustrativo:
                           

        after() returning (java.sql.Connection connection):

            call(java.sql.Connection DriverManager.getConnection(..)){

                    System.out.println("Se ha recuperado la conexión "

                                   + connection);

       }

Es importante tener claro que no se puede retornar un objeto nuevo (sí puede ser modificado pero no retornar uno nuevo).

3.- Advice After Exception
Este tipo de advices son similares a los descritos en el apartado anterior. En este caso, el advice se ejecutará única y exclusivamente cuando el joint point dispare una excepción. Presentan la siguiente estructura:
                            

after() throwing:execution (* ServiceManager+.*(..))

                       
El advice del ejemplo anterior se ejecutará siempre y cuando algún método de la clase ServiceManager (o alguna de sus subclases) dispare una excepción. En el supuesto de que la ejecución del joint point termine correctamente, este tipo de advices no serán ejecutados.

Al igual que los advices del apartado anterior, AspectJ ofrece un modo de recuperar la excepción que ha sido disparada por el joint point de manera que esté disponible en el cuerpo del advice. Siguiendo una sintaxis similar a la anterior, tendríamos:
                          

after() throwing (ExceptionType exceptionObject):

                       
Un after throwing advice nunca podrá tragarse la excepción, por lo que seguirá subiendo por la pila de llamadas hasta llegar al objeto que realizó la invocación del joint point.

Around advice
Este clase de advices engloban al joint point, pudiendo ejecutar la lógica del mismo un número indefinido de veces. Incluso pueden omitir la ejecución del propio joint point. Algunos de los usos principales de este tipo de advices son los siguientes:

• Ejecución de lógica adicional antes y después de la ejecución de un joint point, como por ejemplo, acciones de profiling.
• Omitir la ejecución original, y realizar otra en su lugar, como por ejemplo, operaciones con cachés.
• Envolver la operación con el objetivo de aplicar una política de gestión de excepciones. Un ejemplo de este uso sería la gestión de transacciones.

Este advice ofrece una potencia superior a todos los advices vistos hasta el momento, puesto que podrían sustituir a los anteriores. De todos modos, se considera una buena práctica utilizar el advice más sencillo que cumpla las necesidades de la tarea que necesita ser llevada a cabo.

Si desde el around advice se desea llevar a cabo la ejecución del joint point, será necesario hacer uso de la palabra reservada proceed() dentro del cuerpo del advice. Recuérdese que, puesto que la invocación de proceed() ejecuta el joint point, deberán pasarse el mismo número de argumentos que han sido recolectados por el advice.
Asimismo, puesto que la invocación de proceed() supone la ejecución del joint point, el valor de retorno será el retornado por éste último.

A continuación se adjunta un pequeño ejemplo de utilización de advices de este tipo:
                          

        void around(User user,int credits)

                   throws InsufficientCreditsException:

                call(* User.pay*(int)) && target(user) & &  args(credits){

                    try

                    {

                        proceed(user,credits);

                    }catch(InsufficientCreditsException ex){

                        if(!processException()){

                            throw ex;

                        }

                    }

Analicemos en detalle la construcción anterior:

1. El pointcut selecciona cualquier llamada a los métodos de la clase User cuyo nombre comience por pay y disparen una excepción de tipo InsufficientCreditsException.
2. La segunda parte del pointcut recolecta el contexto del joint point: el usuario sobre el que se está realizando la llamada y el número de créditosque se están pasando como argumento del método que se está ejecutando.
3. En el cuerpo del advice, se engloba la ejecución del método con un bloque de gestión de excepciones, para realizar una protección adicional en caso de que se produzca una excepción. En el caso de que la protección adicional no sea correcta, la excepción será disparada de nuevo.

Todos los around advices deben declarar un valor de retorno (pudiendo ser void). Habitualmente el tipo de retorno de éstos se corresponde con el tipo de retorno de los joint points sobre los que está actuando.
En algunas ocasiones, todos los joint points sobre los que actúa el advice no presentan el mismo tipo de retorno, como puede ocurrir cuando estamos añadiendo soporte transaccional a diferentes  operaciones. En estas situaciones el tipo de retorno que debe declarar el advice será Object. AspectJ acomodará el valor de retorno de acuerdo a las  siguientes reglas:

• Si se está retornando un tipo primitivo, AspectJ realizará el boxing/unboxing correspondiente. Esta característica es similar a la incluida a partir de Java 5, pero AspectJ no precisa de dicha versión de Java para realizar la operación.
• En el caso en el que el tipo de retorno no sea primitivo, AspectJ realizará los casts oportunos antes de retornar el valor.

Muchas ocasiones es necesario acceder a los objetos que conforman la ejecución del joint point para que el advice pueda llevar a cabo la lógica correspondiente. Por tanto, los pointcuts, necesitan exponer el contexto disponible en la ejecución del joint point de modo que pueda estar disponible en el cuerpo del advice. Dicho contexto puede definirse de dos modos diferentes:

• Objetos (incluyendo los tipos primitivos) que conforman el joint point.
• Anotaciones asociadas al joint point.

La siguiente tabla describe el conjunto de pointcuts que AspectJ ofrece para recuperar el contexto en los joint points.

Table 1.14. Pointcuts para recuperar el contexto en un joint point

Pointcut	Contexto recuperado
this(obj)	Objeto this en el joint point que se está ejecutando
target(obj)	Objetivo de la llamada en el joint point que se está ejecutando. En el caso de un joint point de una llamada a un método, el target será el objeto que realiza la llamada. Para la ejecución de un método, el target será el objeto this. En los accesos a campos, el target será el objeto que se está accediendo. En el resto de joint points no existe un target disponible
args(obj1,obj2,...)	Objetos que representa los argumentos en el joint point. Para las llamadas/ejecuciones de métodos/constructores, recupera los argumentos de los mismos. En el caso de los manejadores de excepciones, recupera la excepción producida. Para los accesos en modo escritura a un campo, recupera el nuevo valor del campo.
@this(annot)	Anotación asociada con el tipo del objeto this del joint point
@target(annot)	Anotación asociada con el tipo del objeto target del joint point
@args(annot1, annot2, ...)	Anotación asociada con el tipo de los argumentos del joint point
@within(annot)	Anotación asociada con el tipo "enclosing" del joint point
@withincode(annot)	Anotación asociada con el método "enclosing" del joint point
annotation(annot)	Anotación asociada con el asunto actual del joint point.

Durante la próxima entrada analizaremos el concepto de Aspecto.

Hasta pronto!

Measuring layered architectures adherence

Software measure-slides

View more presentations from Miguel Pastor.

Resérveme esa mesa por favor

Os habréis dado cuenta de que he cambiado la apariencia del blog; no es más que una prueba. Blogger ha liberado una nueva herramienta para personalizar la apariencia y he estado jugando un poco :).

De manera habitual, cuando tengo un poco de tiempo libre, algo que no suele ser demasiado habitual, intento escribir por aquí acerca de algunas de las cosas que más me gustan, las nuevas tecnologías y el mundo del desarrollo de software. Otra de las cosas a las que soy aficionado es a la cocina, y también a los restaurantes :), así que hoy vamos a cambiar un poquito la línea habitual que veníamos siguiendo en las últimas entradas.

Mibu, ubicado en el lujoso barrio de  Ginza (Tokio) y regentado por Hiroyosi y Tomiko Ishida, es uno de los restaurantes más peculiares del mundo: tiene una única mesa a la que solamente pueden acceder sus 300 socios, junto con sus acompañantes. Ocho personas en dos o tres turnos diarios que pagan unos 25000 yenes (225 euros aproximadamente) son sometidos a un ritual que ha enamorado a algunos de los cocineros españoles más sobresalientes. Todavía es demasiado pronto para saber si Ferrán Adriá está barajando la posibilidad de incluir la mesa única como el nuevo formato del Bulli tras su reapertura en 2014.

A continuación os dejo las referencias a algunos de los 'private cooking' de un solo mantel que podréis encontrar en Madrid:

• Taller Inhova. Paco Roncero realiza las pruebas de sus platos para su restaurante La Terraza del Casino. El precio del menú degustación son 250€. Capacidad para seis comensales.
• Chefs Lab. En este caso el cocinero es Sergio Pérez y el número de comensales oscila entre 8 y 16. El precio del menú degustación es de uns 120€.
• Sergi Arola-Gatro. Menú degustación de unos 160€ presenta una capacidad de 2 a 14 comensales.
• Astrid & Gastón. Los cocineros Gastón Acurio y Kike Ceballos ofrecen un menú degustación por unos 95€ y una capacidad de hasta cuatro comensales.
• Estadu Puro. De nuevo Paco Roncero ofrece un espacio en el que los menús degustación comienzan desde 45€ para un máximo de ocho comensales.

La lista anterior únicamente incluye los restaurantes disponibles en Madrid, aunque a lo largo de la geografía española podréis encontrar alguno más como pueden ser El Cenador de Amós en Villaverde de los Pontones (Cantabria), la Cuina de los Angels en Mahón (Menorca) o El Rincón del Chef en Barcelona.

Para terminar, os dejo un enlace en el que habla de todo ésto que os acabo de contar y, además, analiza si el modelo de negocio adoptado por este tipo de negocios puede resultar rentable.

Bueno chic@s, voy a ver si aprovecho el domingo y continuo estudiando un rato que todavía me quedan muchísimas cosas por terminar :(.

Hasta pronto!

AOP: crosscutting (I)

A lo largo de las entradas anteriores hemos analizado el modelo de joint point de AspectJ y la manera de definir las reglas que permitan seleccionar aquellos joint points de nuestro interés. 

Durante esta entrada analizaremos el modo en el que se puede alterar el comportamiento de un sistema en los joint points seleccionados mediante la definición de los pointcuts.

Descripción general


Las reglas de tejido están compuestas de dos partes:

• advice: qué deseamos hacer.
• pointcuts: dónde aplicamos el advice anterior.

AspectJ soporta el crosscutting dinámico mediante el concepto de advices, construcciones similares a los métodos gracias a los cuales se permiten definir las acciones a ejecutar en los joint points seleccionados por un pointcut.

Categorías de advices


Dependiendo de las funcionalidades que se estén implementando será necesario llevar a cabo la lógica en un determinado lugar del flujo de ejecución original; así por ejemplo, si se está construyendo la seguridad de un sistema, el código tendrá que verificar dicha seguridad antes de la ejecución del joint point. En un sistema de cachés, la nueva funcionalidad tendría que ejecutarse alrededor del joint point original, intentando recuperar el valor de la caché, y en caso de que no exista, ejecutar el código real y añadirlo a la misma para futuras invocaciones. AspectJ ofrece tres categorías de advices que satisfacen los escenarios anteriores (y alguno más):

• Before Advice: se ejecutan anteriormente a la ejecución del joint point
• After Advice: se ejecutan posteriormente a la ejecución del joint point. Existen tres variantes diferentes
• After finally: se ejecuta tras la ejecución del join point independientemente del resultado de la misma.
• After returning: se ejecuta tras la ejecución del joint point siempre y cuando ésta última haya finalizado correctamente, es decir, sin lanzar ninguna excepción.
• After throwing: se ejecuta tras la ejecución fallida de un joint point, es decir, después de que dicho joint point dispare una excepción.
• Around Advice: rodean la ejecución del joint point.

Sintaxis de los advices


Aunque la sintaxis varía ligeramente dependiendo del tipo de advice que se esté escribiendo, se podría dividir su estructura general en tres partes claramente diferenciadas:

• Declaración del advice. En esta parte de la declaración se especifica el momento de ejecución del advice, es decir, si se ejecutará antes, después o alrededor de los joint points.
• Definición de los pointcuts. Se especifican los pointcuts sobre los que se desea actuar.
• Cuerpo del advice. Definición del código a ejecutar una vez se haya alcanzado el joint point indicado.

Veamos, por partes, un ejemplo sencillo de definición de un advice:

•  En primer lugar se define un sencillo pointcut :

pointcut secureOperation(User user): call( * User.*(..)) && target(user)

• En el pointcut anterior estamos capturando todas las llamadas a cualquier método de la clase User, y, adicionalmente estamos recogiendo el objeto que actúa como target de la llamada. A continuación veremos un around advice para ilustrar la sintaxis:

            Object around(User user):secureOperation(user){

System.out.println("Securing operation on user " 

+ user.toString());

                Object retValue = proceed(user);

System.out.println("Finished secured operation on user " 

+ user.toString());

return retValue;

           }

• En la definición anterior se puede ver la estructura de la declaración de un advice descrita anteriormente:
• La parte que precede a los dos puntos indica el momento de ejecución del advice (after,before,around). En este caso, se ejecutará alrededor del joint point seleccionado.
• La parte que sigue a los dos puntos representa el pointcut, es decir, la definición de los criterios que determinan cuándo se ejecutará el advice.
• La última parte representa el cuerpo del advice, es decir, el código que se ejecutará cuando alguno de los joint point definidos por el pointcut sea alcanzado.

Advices y métodos

Al igual que los métodos de una clase, los advices se utilizan para definir comportamiento. La sintaxis de éstos últimos es similar a la de los métodos aunque existen algunas diferencias dado que los advices son aplicados de manera automática, sin la necesidad de realizar explícitamente la invocación del mismo.

A continuación se analizan las similitudes entre ambos en tres categorías diferentes: declaración, cuerpo y comportamiento. La declaración de un advice es similar a la signatura de un método tradicional en que:

• Opcionalmente puede asignarse un nombre al advice mediante el uso de la anotación @AdviceName.
• Recibe argumentos a través del contexto del joint point, que posteriormente podrán ser utilizados en el cuerpo para implementar la lógica necesaria.
• Puede declarar el lanzamiento de una excepción.
• El cuerpo de los advices también es muy parecido al de los métodos puesto que:
• El código del cuerpo del advice sigue las mismas reglas de acceso a miembros de otros tipos y/o aspectos.
• Se puede referenciar a la propia instancia del aspecto mediante el uso de this.
• Los advices de tipo around pueden retornar un valor.
• Los advices deben declarar las excepciones que sean checked que la implementación podría disparar.
• En la categoría relativa al comportamiento, los advices :
• No pueden declarar el disparo de una excepción que no está declarada en TODOS los joint points sobre los que actúa.
• Pueden omitir algunas de las excepciones de tipo checked que han sido declaradas por alguno de los joint point sobre los que actúa.
• Pueden declarar el disparo de excepciones más específicas (de tipo checked) que las definidas por los joint point sobre los que está actuando.
• Pueden lanzar cualquier tipo de excepción de tipo runtime. 

En comparación con los métodos, los advices presentan las siguientes diferencias:

• La declaración de un nombre es opcional.
• No pueden ser invocados directamente.
• No presentan especificadores de acceso (relacionado con la característica de que no pueden ser invocados directamente).
• No presentan un tipo de retorno en los advices de tipo before y after.
• Tienen acceso a unas cuantas variables dentro del propio aspecto: thisJointPoint, thisJointPointStaticPart, thisEnclosingJointPointStaticPart.
• Se puede utilizar la palabra reservada proceed en los advices de tipo around para ejecutar el joint point sobre el cual se está realizando el advice.

La siguiente entrada realizará un análisis más detallado de los advices y cómo se puede acceder a los contextos del joint point.


Hasta pronto!!

MMOG Architectures

El poco tiempo libre que tengo no me permite realizar una actualización mínimamente interesante; así que os vais a tener que conformar con ésto; lo siento!

Es una pequeña presentación que sirve como introducción a las principales arquitecturas software subyacentes en los populares MMOG.

Arquitecturas MMOG

View more presentations from Miguel Pastor.

Hasta pronto!

PD: por fin esta semana ha llegado la hora; nos toca comer en el Diverxo!! bien !!!!! Prometo un post con la crítica!

Luces y sombras

Hace medio año que decidí a Madrid y me parece un buen momento para hacer un pequeño balance de como han trasncurrido las cosas hasta este momento.

En el terreno personal las cosas marchan genial; sobre todo con la gordita, mucho más ahora que nos estamos comprando un piso (eso dará lugar para otra serie de entradas :) ). Intentamos aprovechar el poco tiempo que tenemos libre para divertirnos, viajar, conocer nuevos restaurantes :), y retomar el contacto con gente a lo que no veíamos con demasiada frecuencia.

Otra de las cosas buenas que me ha pasado tras mi regreso a Madrid ha sido mi admisión en los estudios de doctorado de la politécnica de Madrid. Me está suponiendo un gran esfuerzo (pocas horas de sueño y mucho trabajo, quizás demasiado) pero la verdad que, al menos hasta este momento, la experiencia está siendo gratificante; las clases son interesantes además de que estoy conociendo a gente que presenta mis mismos intereses. Puede que dentro de poco tiempo tenga alguna novedad respecto a este tema pero tampoco quiero adelantarme a los acontecimientos.

Sin embargo estar en Madrid también tiene sus cosas "malas", principalmente porque estás mucho más lejos de la gente con la que has vivido muchos años de tu vida y a la que quieres: tu familia  y  amigos. Esta entrada quedaría imcompleta si no me acordase de mis padres y mi hermana o de Fer,Rube, Andre,Vicio,Yudi,Miguel, el Mono, Héctor, Marta,. . . (lo sé, lo sé, me estoy dejando a gente en la lista ).

Visto así, podría parecer que todo está genial, pero la otra pieza del puzzle, que, por desgracia, también es una parte importante de nuestras vidas, no termina de encajar. Si, es lo que todos estamos pensando, el maldito trabajo.

Siempre he dicho que me gusta a lo que me dedico, pero la verdad que cada día que pasa me voy desilusionando (o quizás siendo realista) un poquito más. Regresé a Madrid con la idea de intentar seguir creciendo profesionalmente pero, hasta el momento, lo único que estoy haciendo es ir hacia atrás. Falsas promesas, mentiras, . . . se están convirtiendo en tónica habitual. Prefiero no seguir porque me enciendo y me tengo que ir a la cama :)

¿Y entonces? Pues lo único que tengo claro es que estoy firmemente convencido de darle un giro de 180º a mi carrera y dedicarme a algo completamente diferente. Os mantendré informados :).

Estoy un poco espeso así que voy a dejarlo aquí.

Keep walking :)

PD: A partir de ahora comenzaré a escribir el inglés porque necesito practicar. Os agradecería, a los pocos que frecuentais este blog, todo tipo de correcciones

Sexie Sadie: A scratch in my skin

No sabría decir cual es el motivo, pero esta es una de mis canciones favoritas (en conjunción con el videoclip :) )

AOP: non kinded pointcuts

En la entrada anterior analizábamos aquellos tipos de pointcuts en los que los joint point seleccionados encajaban en una determinada categoría (de ahí su nombre).

El mecanismo implementado mediante non-kinded pointcuts permite la selección de joint points basados en criterios adicionales a las signaturas vistas anteriormente. Por ejemplo, podremos seleccionar todos los joint point donde el objeto this es de un determinado tipo. Dicho joint point incluiría las llamadas a métodos, ejecuciones, manejadores de excepciones, etc.

A continuación, a través de ejemplos, veremos los diferentes tipos de non-kinded pointcuts ofrecidos por AspectJ.

Non-kinded pointcuts basados en control de flujo

Pointcut	Descripción
cflow( execution(* TransactionManager. commit() ))	Selecciona todos los joint points en el flujo de la ejecución de cualquier operación commit de la clase TransactionManager, incluyendo la ejecución del propio método.
cflowbellow( execution(* TransactionManager. commit() ))	Selecciona todos los joint points en el flujo de la ejecución de cualquier operación commit de la clase TransactionManager, excluyendo la ejecución del método.
cflow(execution(@Secured * * (..)))	Todos los joint points en el flujo de la ejecución de cualquier método anotado con la anotación Secured
cflow(transacted())	Cualquier joint point en el flujo de ejecución de los joint points seleccionados por el pointcut transacted()

Non-kinded pointcuts basados en la estructura léxica

Dentro de este tipo de pointcuts tenemos dos categorías:

• within(TypeSingnature): selecciona cualquier joint point que aparece en el cuerpo de las clases y aspectos que concuerden con el tipo especificado.
• withincode(ConstructorSignature),withincode(MethodSignature): selecciona cualquier joint point que aparezca dentro de un método o un constructor, incluyendo la definición de cualquier clase local que pudiera aparecer en los mismos.

Pointcut	Descripción
within(User)	Selecciona todos los joint points que aparecen dentro de la clase User
within(User+)	Selecciona todos los joint points que aparecen dentro de la clase user y cualquiera de sus clases derivadas
within(@Transactional *)	Selecciona todos los joint points que aparecen dentro de cualquier clase que se encuentre marcada con la notación Transactional
withincode(* TransactionManager. retrieve*(..))	Selecciona todos los joint points que parecen dentro de cualquier método de la clase TransactionManager cuyo nombre comience por retrieve

Non-kinded pointcuts de ejecución

Este tipo de pointcuts permite seleccionar joint points en base al tipo de los objetos en tiempo de ejecución. De este modo se dispone de:

• this(). Acepta dos formas diferentes: this(ObjectIdentifier) o this(Type). Seleccionará aquellos joint points cuyo objeto this sea del tipo (o el objeto) indicado.
• target(). Similar al concepto anterior, aunque en este caso, se utilizar el target del joint point en lugar del this.

Pointcut	Descripción
this(User)	Selecciona cualquier joint point en que la expresión this instanceof User sea cierta. Así por ejemplo, seleccionará las llamadas a métodos o accesos a campos donde el objeto actual sea de tipo User o cualquier de sus subclases.
target(User)	Selecciona cualquier joint point en el que el objeto sobre el que se realiza la llamada al método es instanceof User

Non-kinded pointcuts sobre argumentos

Este tipo de pointcuts permite seleccionar joint points en base al tipo de los argumentos en tiempo de ejecución. Veamos los distintos tipos de argumentos, en función del tipo del joint point :

• En el caso de los joint points manejadores de excepciones el argumento será la excepción manejada.
• En los métodos y constructores, los argumentos serán los argumentos del método y constructor.
• En los accesos de modificación de un campo, el argumento será el nuevo valor que va a tomar dicho campo.

Pointcut	Descripción
args(User, . . , String)	Selecciona cualquier joint point de tipo método o constructor en el que el primer argumento es de tipo User (o cualquiera de sus subclases), y el último argumento es de tipo String.
args (SqlException)	Selecciona cualquier joint point con un único argumento de tipo SqlException. Seleccionaría cualquier método o constructor que esperase un único argumento de tipo SqlException, un acceso de escritura a un campo estableciendo un nuevo valor de tipo SqlException, y también seleccionaría un manejador de excepciones de tipo SqlException

Non-kinded pointcuts condicionales

Este tipo de pointcuts permiten seleccionar joint points basados en una expresión condicional.

Pointcut	Descripción
if(debug)	Selecciona cualquier joint point donde el campo estático debug (en la definición del aspecto) toma el valor cierto

Poco a poco vamos completando, de manera sencilla, una idea general de los mecanismos que nos ofrece la orientación a aspectos en general, y AspectJ en particular. En la siguiente entrada analizaremos los conceptos de crosscutting dinámico y los mecanismos disponibles para la modificación del comportamiento de un programa en un determinado joint point.

AOP: kinded pointcuts

Continuando la serie de posts relativos a la programación orientada a aspectos y, concretamente, el lenguaje AspectJ, durante esta entrada analizaremos la implementación que este último hace de los pointcuts.

AspectJ ofrece dos mecanismos diferentes que permiten a los pointcuts realizar la selección de los joint points:

• Kinded pointcuts. En este caso, los pointcuts seleccionan categorías de joint points (de ahí su nombre). Así, por ejemplo, se ofrece la posibilidad de realizar matching sobre la ejecución de un método.

• Non-kinded pointcuts. Se seleccionan los joint point en base a la información de la que disponen, como los tipos en tiempo de ejecución o su contexto. En esta situación se seleccionan joint points de cualquier clase, siempre y cuando satisfagan la condición descrita.

A continuación analizaremos los kinded pointcuts y dejaremos para la siguiente entrada la segunda categoría.

• Kinded Pointcuts

Joint Points expuestos y tipos de pointcuts

Categoría de Joint Point	Sintaxis del pointcut
Ejecución de un método	execution(MethodSignature)
Llamada a un método	call(MethodSignature)
Ejecución de un constructor	execution(ConstructorSignature)
Llamada a un constructor	call(ConstructorSignature)
Inicialización de una clase	staticinitializaction(TypeSignature)
Acceso de lectura a un campo	get(FieldSignature)
Acceso de escritura a un campo	set(FieldSignature)
Ejecución de un manejador de excepciones	handler(TypeSignature)
Inicialización de un objeto	initialization(ConstructorSignature)
Pre-inicialización de un objeto	preinitialization(ConstructorSignature)
Ejecución de un advice	adviceexecution()

Por ejemplo, si deseamos seleccionar todas las llamadas a los métodos públicos commit() de la clase TransactionManager, escribiríamos un pointcut similar al siguiente:

call(public void TransactionManager.commit(..))

En la siguiente entrada analizaremos en detalle la segunda categoría de pointcuts ofrecida por AspectJ

Some signatures examples

En la última entrada dedicada a AOP (podeis verla aquí ) analizamos de manera teórica las características básicas del lenguaje de definición de pointcuts. A continuación realizaremos una serie de ejemplos que intentarán clarificar los conceptos teóricos vistos en anteriores entradas.

• Signaturas de tipos

Table 1.2. Ejemplos de signaturas de tipos

Patrón de la signatura	Descripción	Ejemplos de tipos concordantes
AstVisitor	El tipo AstVisitor	Sólo el tipo AstVisitor concuerda (ni tipos base ni derivados)
*AstVisitor	Cualquier tipo cuyo nombre termine en AstVisitor	Por ejemplo, HighlightingAstVisitor o SemanticAstVisitor concuerdan con el patrón
java.*.Date	El tipo Date en cualquier subpaquete directo del paquete java	java.util.Date o java.sql.Date son ejemplos de tipos concordantes
javax..*	Cualquier tipo en el paquete javax y en sus subpaquetes (tanto directos como indirectos)	Cualquier tipo en el paquete javax.security así como cualquiera de sus subpaquetes indirectos como javax.security.auth.login
javax..*Model	Todos los tipos en el paquete javax (subpaquetes directos e indirectos) cuyo nombre termine en Model, y todos los subtipos de estos.	TableModel, TreeModel y sus subtipos como DefaultTreeModel oDefaultTableModel.

• Signaturas de tipos: anotaciones

Table 1.3. Ejemplos de signaturas de tipos: anotaciones

Patrón de la signatura	Descripción	Ejemplos de tipos concordantes
@Secured User	El tipo User anotado con la anotación Secured	@Secured class User{. . .}
@Entity *	Cualquier tipo anotado con la anotación Entity	@Entity class Section {. . .},@Entity class Report {. . .}
@Transactional* Manager+	El tipo Manager y cualquiera de sus clases derivadas que estén anotados con una anotación cuyo nombre comience por Transactional	@TransactionalDefault class Manager{},@TransactionalOracle class OracleManager extends Manager{}

• Signaturas de tipos: generics

Table 1.4. Ejemplos de signaturas de tipos: generics

Patrón de la signatura	Descripción	Ejemplos de tipos concordantes
Map	El tipo Map cuyo primer argumento genérico está fijado a Integer y el segundo aString	En este caso únicamente concordará el tipo Map
*	Cualquier tipo genérico cuyo único argumento genérico sea de tipo User	Collection,List, . . .
Collection	El tipo Collection con un parámetro de tipo User o derivado	Collection, Collection, . . .
Collection	El tipo Collection, cuyo parámetro será uno de los tipos base de User	Collection, Collection, asumiendo que, User extiende o implementa, directa o indirectamente, Serializable y BaseUser

• Combinando pointcuts: operadores

Table 1.5. Signaturas de tipo: operadores

Patrón de la signatura	Descripción	Ejemplos de tipos concordantes
!Collection	Cualquier tipo excepto Collection	User,Model, List (aunque sea subclase de Collection)
Set || Map	Los tipos Set o Map	Los tipos Set y Map únicamente
!@Transactional	Cualquier tipo que se encuentre anotado por la anotación Transactional	class NonTransactionalManager{}
@Serializable @Encrypted *	Cualquier tipo que se encuentre anotado por las dos anotaciones	@Serializable @Encrypted class UserCredentials{}
(@Serializable || @Encrypted) *	Cualquier tipo que esté anotado por alguna de las dos anotaciones	@Serializable class User {}

• Signaturas de métodos y constructores

Table 1.6. Signaturas de métodos

Patrón de la signatura	Descripción	Ejemplos de métodos concordantes
public void User.set*(*)	Cualquier método público de la clase User cuyo nombre comience por set, cuyo tipo de retorno sea void, y que espere un único argumento	class User{ public void setName(String name){} }
public void User.*()	Cualquier método público de la clase User cuyo tipo de retorno sea void y que no espere argumentos	class User { public void updateInfo(){}}
public * User.*()	Cualquier método público de la clase User que no espera argumentos y retorna cualquier tipo	class User{ public UserInfo getUserInfo(){}}
public * User.*(..)	Cualquier método público de la clase User que retorna cualquier tipo, y espera cualquier número y tipo de argumentos (incluido cero)	class User{ public UserInfo getUserInfo(){},public Date updatesBetween(Date first,Date last){}}
* *.*(..) o * * (..)	Cualquier método independientemente de su tipo, del tipo de retorno, de su nombre y de los argumentos que espere	Cualquier método del sistema
!public * User.*(..)	Cualquier método que no sea público (privado,protegido o paquete)	class User {protected getUserInfo(){}}
* * (..) throws Recognition Exception	Cualquier método que declare que puede lanzar una excepción de tipoRecognitionException	class AntlRBasedParser { public void parser(String file) throws RecognitionException}
* User+.*(..)	Cualquier método en la clase User y sus subclases	class UserDetails extends User {}
User UserService.*(..)	Cualquier método del tipo UserService cuyo tipo de retorno sea User. Si alguna de las subclases sobrescribe el tipo de retorno con un subtipo de User (mediante el tipo de retorno covariante introducido en Java 5) también será seleccionado.	class UserService{public User retrieveUser(String name){}} class DetailUserService extends UserService{public DetailedUser retrieveUser(String name){}}

La signatura en el caso de los constructores difiere de la signatura de métodos en los siguientes aspectos:

• Los constructores no tienen tipo de retorno por lo que no se permite utilizar el valor de retorno en la especificación de un pointcut de este tipo.
• Dado que los nombres de los constructores no pueden ser libres (tienen que utilizar el mismo nombre de la clase), la parte de la signatura destinada al nombre será sustituida con la palabra new.
• Por último, puesto que los constructores no pueden ser estáticos, no se podrá utilizar la palabra reservada static

• Signaturas de campos

Table 1.7. Signaturas de campos de clase

Patrón de la signatura	Descripción	Ejemplos de campos concordantes
private String User.username	Campo privado (tanto campo de una instancia como estático) de la clase User	class User { private String username;}
* User.*	Cualquier campo de la clase User independiente de sus calificadores, tipo y nombre.	class User{private String username;protected int credits;private UserDetails details;}
* User+.*	Cualquier campo de la clase User y todas sus subclases, independientemente de sus calificadores, tipo y nombre.	El ejemplo de la fila anterior o class SpecificUser extends User {private String address;}

Software Disasters

De sobra es sabido por todos que algunos desastres históricos han sido ocasionados por errores en el software.

La siguiente presentación resume alguno de los más conocidos y describe, de manera concreta, dos ejemplos: un fallo de división en un chip de Intel, y un fallo en un sistema de detección de misiles americano.

Hasta pronto!

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.