Just my thoughts

Algunos libros para comenzar el año

2012-01-02T17:55:00.000+01:00

Unos cuantos libros para comenzar el año de la mejor manera posible: aprendiendo cosas nuevas.

The Garbage Collection Handbook. Este libro ofrece una visión actualizada del estado del arte de los sistemas de recolección de basura y la gestión automática de memoria. He leido varias críticas de Gil Tene (CTO de Azul Systems) y en todas ellas pone al libro por las nubes.

No he tenido ocasión de leerlo, todavía, pero está en las primeras posiciones de la lista de libros que me gustaría leer este comienzo de año.

Para aquellos que estéis interesados en los sistemas distribuidos y/o trabajeis con ellos aquí podréis encontrar una magnífica y extensa referencia sobre este tipo de sistemas: fundamentos, algoritmos , etc.

No estoy seguro si ya he hablado de este libro con anterioridad pero la verdad es que se trata de una magnífica y reconfortante lectura en la que se pueden aprender infinidad de cosas.

Excelente lectura si os gusta conocer los "internals" del sistema operativo Linux y cómo funcionan la mayoría de sus principales subsistemas: gestión de procesos, gestión de memoria, etc. Posiblemente nunca escribamos ni una línea de código relacionada con el núcleo de este sistema operativo pero estoy convencido de que esta lectura puede ayudarnos como desarrolladores a escribir mejores programas.

Hasta pronto!

Propósitos para 2012

2012-01-02T12:12:00.000+01:00

Un año nuevo que comienza cargado de ilusiones, apasionantes retos personales y profesionales y grandísimas noticias. Al igual que el año anterior me gustaría escribir esta pequeña entrada en la que plasmar todas las buenas intenciones para este nuevo año que acaba de comenzar. Sobra decir que, tal y como ha ocurrido con las intenciones de hace doce meses, algunas se cumplirán y algunas no; esperemos que con tesón, perseverancia y muchas muchas ganas muchas de ellas sean algo más que meras intenciones.

Algunas de las cosas que tengo en mente:

Pasar el máximo tiempo posible con mi hijo y mi novia. Como tod@s ya sabéis el pasado mes de noviembre hemos sido padres por primera vez y quiero disfrutar al máximo del niño y de todo lo que lo rodea.

Casarme. La única duda que tengo respecto a este tema es el tipo de celebración que vayamos a realizar aunque todo indica que no llevaremos a cabo una "boda tradicional" cientos de invitados sino que será algo extremadamente simple.

Retomar el tema del doctorado. Acontecimientos de diversa índole como la parálisis facial, la operación de corazón de mi suegra, el nacimiento de Sergio y algunas cosas más hicieron que durante el segundo semestre del año pasado me costara mucho más poner orden y determinación. Esperemos que en este año que comienza sea capaz de organizarme de manera mucho más eficaz y pueda retomar las diferentes cosas del doctorado que ahora mismo tengo en un estado de abandono absoluto.

~~Ponerme en forma~~ Practicar algo de deporte. Creo que practicar algo de deporte es algo muchto más realista. Soy consciente de que recuperar el estado de forma que tenía cuando jugaba al fútbol y practicaba surf es una utopía con lo que me conformaré con salir a correr de vez en cuando y perder unos cuantos kilillos que he cogido durante el último viaje a EEUU y estas navidades (que todavía no han tocado a su fin y tengo unas cuantas citas pendientes) .

No podía terminar este post sin hacer mención a las cosas ligadas al mundo de la tecnología que me gustaría hacer durante este año:

Asistir a alguna conferencia más que el año anterior. El año pasado estuve hablando en Spring I/O sobre Hadoop y este año tenía medio preparada una presentación sobre los internals de Cloud Foundry aunque finalmente no tuve tiempo de enviarla por lo que este año, en caso de que pueda asistir, será unicamente como oyente.

De momento ya tengo la entrada para los Scala Days 2012 (todavía tengo que gestionar el hotel y el viaje)

Aprender nuevas cosas y mejorar muchas de las que yo conozco. Mejorar mis habilidades con Scala, participar más activamente en algunos proyectos en los que he hecho algunas cosillas, dar "pasos mucho más serios" en otros lenguajes como Go y Haskell, profundizar mis conocimientos de sistemas distribuidos, . . . .

Impulsar el grupo de escalabilidad en español: https://groups.google.com/forum/#!forum/spain-scalability-users

Tenía algunas cosas más en mente pero tengo que cortar aquí porque está el niño llorando y tengo que ocuparme de el.

Feliz año 2012 a tod@s y esperemos que no sea tan malo como lo pintan!

Hasta pronto!

Algunos libros sobre Java y JVM

2011-11-28T22:56:00.001+01:00

Durante estas últimas semanas he tenido la ocasión de terminar varios de los libros que tenía pendientes así como de realizar alguna nueva adquisición que, de momento, está encolada en mi lista de lectura.

Me gustaría aprovechar esta entrada para compartir con vosotros algunos de los libros anteriores que, bajo mi punto de vista, podrían resultar interesantes para tod@s aquell@s que os dediquéis, de algún modo, a trabajar con la plataforma Java (lenguaje y/o máquina virtual).

El primero de ellos es Java Performance from The Java Series. Escrito por Charlie Hunt, JVM performance lead engineer en Oracle, y Binu John, senior performance engineer en Ning. Ha sido mi última adquisición y únicamente he podido leer los dos primeros capítulos pero creo que estamos ante uno de las lecturas obligatorias para tod@s aquell@s que se dedican y/o les gusta el mundo del rendimiento de aplicaciones sobre la JVM.

JVM Tuning, profiling, mediciones, herramientas, escritura de benchmarks, internals de la JVM, algoritmos de recolección de basura y tuneo de los mismos, gestión de la memoria, . . . son sólo algunas de las temáticas tratadas en este magnífico manuscrito.

Otro magnífica referencia relativa al mundo Java: The well-grounded Java developer. Se trata de un early access por lo que sólo he podido leer los capítulos disponibles hasta el momento. Pensado para desarrolladores con unos sólidos conocimientos de Java el libro abarca un amplio espectro de temáticas como pueden ser:

Algunas de las novedades de Java 7
Nuevo mecanismo de IO y concurrencia
Classfiles y bytecode
Inyección de dependencias
Lenguajes alternativos en la JVM: Clojure, Groovy y Scala
Integración continua
. . .

En lineas generales creo que se trata de una lectura recomendada (a la espera de que se publique la segunda mitad del libro). Los capítulos pueden ser leidos de manera independiente, saltándose aquellos en los que ya se conoce de manera profunda la temática tratada en el mismo.

Un libro que había leido hace tiempo y que he vuelto a leer hace unas semanas ha sido Java Concurrency in Practice. Poco puedo decir de este libro que no se haya dicho ya. Otra de las lecturas obligatorias para todos aquellos desarrolladores que trabajen con el lenguaje Java.

Ofrece una visión práctica de cómo se deben escribir programas escalables y seguros aprovechando la capacidad de las nuevas arquitecturas hardware.

Functional Programming for Java Developers. Escrito por Dean Wampler. Es un libro en el que se introducen los conceptos básicos de la programación funcional (que está "renaciendo" gracias a lenguajes como Scala o Clojure, además de sus beneficios a la hora de escribir programas concurrentes entre otras muchas cosas).

Es un libro muy cortito aunque personalmente no me ha entusiasmado demasiado. Si no tenéis ninguna experiencia en programación funcional puede ser un buen punto de partida. No se cubren mónadas, laziness ni combinators.

Escalabilidad, disponibilidad y estabilidad

2011-10-06T23:47:00.000+02:00

En algunas ocasiones hemos hablado de temas de escalabilidad y disponibilidad de sistemas aunque siempre desde un punto de vista muy práctico, haciendo referencia a los problemas que ocupan nuestro día a día. Me gustaría recopilar, a lo largo de una serie de posts, algunos de los patrones y/o tecnologías más populares relacionados con la escalabilidad, la concurrencia o la alta disponibilidad.

Me gustaría dejar claro desde un principio que lo aquí expuesto son simplemente mis ideas, adquiridas a lo largo del tiempo gracias a la experiencia acumulada en la construcción de diversos sistemas software, mis estudios de doctorado, leer y practicar mucho, aprender de los maestros y pasarme muchas, pero muchas muchas, horas aporreando el teclado. Por tanto, las cosas que aquí aparecen podrían ser erróneas y/o incompletas.

Me gustaría comenzar con una tecnología relacionada con la concurrencia: la memoria transaccional (STM en adelante).

Escribir programas concurrentes es una tarea sumamente complicada y, habitualmente, no determinista; ¿cuantas veces habremos probado un programa multihilo en nuestros sistemas de integración continua y , tras poner el sistema en producción, nos hemos encontrado con nuevos errores? Tan real como la vida misma.

Habitualmente las inmutabilidad (hablaremos de ella en el futuro) es un gran aliado a la hora de escribir programas concurrentes dado que resulta mucho más sencillo razonar sobre información cuyo estado permanece estable. Sin embargo, como en la mayoría de las situaciones, la inmutabilidad no es una bala de plata que soluciona todos los problemas por lo que tendremos que lidiar con información cuyo estado puede variar y con toda la problemática asociada a la misma. Llegados a esta situación, y siguiendo con el enfoque con el que estamos más familiarizados, estaríamos peleándonos con bloqueos, granularidad de los mismos, etc.

Un vistazo a la STM

La STM puede ayudarnos a resolver el problema anterior de manera mucho más sencilla visualizando la memoria (heap + pila) como si de un dataset transaccional se tratara. Algunas de las características más relevantes:

Concepto muy similar al de una base de datos tradicional. Se llevan a cabo operaciones como begin, commit o abort/rollback

En caso de que se produzca una colisión la transacción será relanzada de manera automática

Se realiza un proceso de rollback sobre la memoria cuando se produce una operación de abort.

Las transacciones se pueden componer y anidar

Un aspecto sumamente importante que debemos tener en cuenta a la hora de utilizar la memoria transaccional es que todas las operaciones englobadas en el ámbito de una transacción deberán ser idempotentes (anteriormente hablábamos del relanzamiento automático en caso de que se produjera una colisión).

Existen numerosas implementaciones disponibles para la máquina virtual de Java (JVM) entre las que destacan:

Multiverse: http://multiverse.codehaus.org/overview.html
Akka: http://akka.io/docs/akka-1.0/stm-java.html
Clojure STM: http://clojure.org/refs
CCSTM: http://ppl.stanford.edu/ccstm/site/index.html
Deuce STM: https://sites.google.com/site/deucestm/

En la siguiente entrada realizaremos varios ejemplos prácticos de uso de la memoria transaccional y analizaremos cuales son los escenarios más propicios para la utilización de esta solución.

Hasta pronto!

Migue

[Off-Topic] Poniéndome al día y buenas noticias

2011-10-05T00:48:00.002+02:00

Hola a tod@s,

Hace más de un mes y medio de la última entrada en el blog pero es que me está costando mucho más de lo esperado retomar todas las cosas pendientes y/o atrasadas por lo que últimamente me estoy agobiando un poquito. De todos modos el objetivo de la entrada no era aburriros con mis "problemas" sino comentaros una buena noticia, al menos para mi :), aunque seguro que muchos de los que os pasáis por aquí ya lo sabréis: ¡vamos a ser papás!

Así es; si todo sigue como hasta ahora, dentro de cuatro semanas aproximadamente tendremos a nuestro hijo Sergio entre nuestros brazos.

Estos últimos meses han sido, sin lugar a dudas, los mejores meses de mi vida. Meses de cambio, de preparar la casa, de descubrir cosas que ni siquiera sabía que existían o de convertirme en un "manitas".

Con toda seguridad los cambios serán mucho más notables cuando el pequeño nazca pero de momento prefiero no adelantar acontecimientos y centrarnos en disfrutar del "poquito" tiempo de embarazo que nos queda.

Dentro de poco tendré que repartir mimos y cuidados entre mis dos amores aunque mi gordita dice que nada de dividir, que como mínimo duplicar así que . . . difícil tarea me espera.

Hasta pronto!

Migue

De regreso

2011-08-26T23:16:00.000+02:00

Ya estoy de vuelta.

Por suerte ya me he recuperado por completo de mi parálisis facial (finalmente "solo" me duró once días aproximadamente) con lo que de nuevo estoy online.

La entrada no será muy larga :) , simplemente quería que supierais que me encuentro perfectamente.

Espero retomar el blog durante los próximos días aunque con lo que tenemos en camino tengo una agenda en la que el tiempo libre brill a por su ausencia.

Hasta pronto!

Migue

PD: he escrito la entrada desde el iPad y la verdad que se escribe mucho más rápido de lo que uno podría esperar en un principio.

Offline

2011-08-02T13:01:00.000+02:00

Durante los próximos días estaré "offline" por completo. Nada de ordenador, IPad, Internet y similares :). Voy a ver si consigo desconectar por completo durante estos días y termino de recuperarme de mi parálisis facial.

Hasta pronto!

Migue

Parálisis facial

2011-07-30T22:22:00.000+02:00

Hacía muchísimo tiempo que no me ponía enfermo pero esta vez me ha tocado. Será que me estoy haciendo mayor . . . :(. La doctora me ha diagnosticado parálisis facial.

Gracias a Dios suena mucho más aparatoso de lo que es: tengo la mitad de la cara dormida (es una sensación similar a la que se presenta cuando regresas del dentista) y se me cierra un poco el ojo con lo que a veces se me cansa la vista y no puedo enfocar demasiado bien. Las buenas noticias es que no es doloroso aunque si bastante incómodo. Las malas es que me puede durar desde tres días hasta tres meses y que "del mismo modo que viene se va" (palabras textuales de la doctora).

Espero recuperarme cuanto antes y seguir dando un poco de guerra!

Hasta pronto!

Migue

Grupo de escalabilidad: mapa clusterizado

2011-07-19T22:43:00.000+02:00

Tras los resultados de la encuesta que realizamos durante la semana pasada hemos creado un pequeño mapa geográfico en el que se muestran a modo de clúster los distintos miembros que componemos el grupo de escalabilidad en español y dónde estamos ubicados cada uno de nosotros:

Embedded from Google Shared Spaces. Create your own space.

El registro el libre y cada una de las personas que aparece en el mapa anterior se ha registrado de manera propia.

Si estáis interesados en alguna temática relacionada con la escalabalidad de sistemas de información os animo a que os registréis en el grupo y también os apuntéis en el mapa!

Hasta pronto!

Migue

Evento sobre escalabilidad de sistemas

2011-07-13T20:42:00.000+02:00

Desde el grupo de escalabilidad en español hacía tiempo que estábamos barajando la posibilidad de organizar un evento relativo a la escalabilidad de sistemas y finalmente hemos dado un paso adelante.

Es una primera aproximación en la que estamos intentando recabar el mayor conjunto de información posible con el objetivo de llegar al mayor número de gente posible.

No voy a repetir todo el rollo que hemos escrito en otros sitios :) así que simplemente os dejo los enlaces donde podréis encontrar toda la información de la que disponemos hasta este momento:

Topic en el grupo google

Encuesta

Entrada en el blog de Martín Pérez

Estaremos encantados de recibir vuestras críticas, sugerencias y/o propuestas.

Hasta pronto!

Migue

AspectJ y Scala (y III)

2011-06-29T18:31:00.000+02:00

Última entrada (en esta ocasión mucho menos ladrillo) de esta mini-comparativa que estamos llevando a cabo entre AspectJ y Scala (podéis consultar las anteriores entradas en los siguientes enlaces: AspectJ y Scala (I), AspectJ y Scala (II).

Hemos estado revisando cómo llevar a cabo la aplicación de varias funcionalidades como el uso de cachés o la gestión de transacciones mediante el uso de AspectJ y Scala, haciendo hincapié en las ventajas y desventajas de las dos aproximaciones. Nótese que hemos estado hablando de funcionalidad transversal como las transacciones y la caché pero no hemos hablado de otro tipo de funcionalidades las cuales abarcan un espectro mucho más amplio como por ejemplo FFDC (First Faiulure Data Capture), Profiling, gestión de la concurrencia, etc. En este tipo de situaciones el uso de Scala y HFOs resultaría mucho más tedioso que los ejemplos vistos en las entradas anteriores; derivando en los síntomas clásicos de funcionalidad "difuminada" por toda nuestra apliación.

¿Conclusión? El uso de cualquiera de las dos aproximaciones que hemos estado analizando dependerá, como en el 90 por ciento de todas las situaciones, del problema que estemos resolviendo, por lo que tendremos que escoger la "herramienta" más adecuada para el problema que se nos plantea.

¿Y por qué no un mixin de las anteriores? Esta es una de las alternativas que más me convence:

Compilamos nuestros programas Scala de la manera habitual.

Definimos nuestros aspectos para llevar a cabo la funcionalidad transversal deseada.

Realizamos un proceso de binary weaving (ya sea build time o load time)

Mediante el mecanismo anterior estaremos aplicando nuestros aspectos a nuestro código Scala compilado.

En mi cuenta de GitHub podréis encontrar dos proyectos Eclipse (scala-simple-service y aspectj-advice-scala) que deben ser utilizados de manera conjunta. Mediante estos dos pequeños proyectos de ejemplo se ilustra cómo podemos utilizar conjuntamente aspectos escritos en AspectJ que hagan advice sobre código Scala compilado.

Hasta pronto!

AspectJ y Scala (II)

2011-06-28T00:11:00.001+02:00

En la entrada anterior analizamos algunas de las similitudes y diferencias existentes entre Scala y AspectJ, llevando a cabo una implementación de una caché extremadamente simple en ambos lenguajes, describiendo las ventajas y desventajas presentes en cada una de las aproximaciones. Durante esta entrada analizaremos un ejemplo de aplicación de una funcionalidad transversal como la gestión de transacciones.

El ejemplo que aquí nos ocupa no persigue realizar una implementación detallada de control de transacciones sino simplemente ilustrar como podríamos aplicar una funcionalidad transversal mediante el uso de AspectJ o Scala.

Del mismo modo que en el post anterior, comenzamos por la aproximación basada en AspectJ. Para ello en primer lugar definimos una simple anotación que nos sirva como elemento de marcado de aquellas clases y/o métodos que se deben ejecutar bajo un contexto transaccional.

Una vez definida la anotación anterior definiremos un aspecto que sea capaz de detectar aquellos joint point en los que deseamos establecer un contexto transaccional.

pointcut transactionalOperation() : execution(@Transactional * * (..) );

Con el pointcut anterior estaremos capturando las llamadas realizadas sobre cualquier método anotado con nuestra anotación @Transactional. Ahora necesitaremos definir un advice en el que llevamos a cabo la gestión de la transacción (nótese que este gestor de transacciones es completamente absurdo y simplemente imprime por pantalla la funcionalidad real que debería ser llevada a cabo por un gestor de transacciones operativo)

En muchas ocasiones todos los métodos de una clase necesitarán ser transaccionales, y no querremos anotar todos los métodos de dicha clase. En este supuesto podríamos utilizar anotaciones a nivel de clase que nos permitan seleccionar aquellos métodos que deseemos (por ejemplo, todos los métodos públicos).

Adicionalmente, podríamos hacer uso de los ITD y establecer la transaccionalidad a todas aquellas clases que nosotros deseemos. Por ejemplo, supongamos que todos los nombres de nuestros servicios, los cuales deseamos que sean transaccionales, terminan con el sufijo Service. Podríamos, mediante el uso de un aspecto, añadir la anotación @Transactional a todos nuestros servicios.

declare @type : *Service : @Transactional ;

Dicho aspecto, en conjunción con el anterior, provocaría que todos nuestros servicios fueran transaccionales

En Scala, de nuevo, haremos uso de funciones de alto nivel (high order functions) de manera muy similar a la solución de la caché descrita en la entrada anterior:

Si deseamos que un método de uno de nuestros servicios sea transaccional no tendremos más que extender de la clase abstracta y utilizar la HOF anterior:

Si comparamos las soluciones aportadas por cada una de las dos alternativas tendremos que

En el caso de AspectJ no necesitamos anotar cada método de manera independiente puesto que podríamos hacer uso de anotaciones a nivel de clase. El nivel de granularidad que podemos alcanzar está definido a nivel de método (aunque tampoco es un problema excesivamente grande puesto que podríamos utilizar el patrón Extract Method para extraer la funcionalidad transaccional a un método sobre el cual podríamos aplicar nuestro aspecto).
En el caso de Scala necesitaremos recubrir nuestra lógica con la HOF definida en nuestro ejemplo anterior. En esta situación, el nivel de granularidad es notablemente superior puesto que podemos recubrir una simple parte de nuestro método

Durante esta segunda entrada hemos vuelto a confrontar Scala y AspectJ a la hora de aplicar una funcionalidad transversal, intentando plasmar las ventajas y desventajas de cada uno de ellos.

En la siguiente y última entrada de esta serie analizaremos cómo aunar lo mejor de ambos mundos en un ejemplo práctico que nos sirva como base para futuros ejemplos.

Como siempre podéis encontrar el código fuente de todos los ejemplos del blog (o casi todos :) ) en mi cuenta de GitHub, bajo el proyecto blog-examples.

Hasta pronto!

PD: perdón por el ladrillo de entrada :(.

AspectJ y Scala (I)

2011-06-21T00:09:00.000+02:00

¿Podemos establecer alguna conexión entre estos dos mundos? Si nos detenemos por un instante veremos que comparten muchas más cosas de las que a simple vista podría parecer:

Son lenguajes de tipado estático.
Ambos producen código compatible con la máquina virtual de Java (JVM)
Las funciones de alto nivel de Scala comparten algunas características con los advices de AspectJ
Los traits de Scala comparten algunas características con el static crosscuting de AspectJ.

Durante el resto de la entrada que nos ocupa (y la siguiente) realizaremos una pequeña comparativa en la que pondremos de manifiesto el modo en que cada uno de estos lenguajes resuelve determinado tipo de problemas. Pongámonos manos a la obra.

Cachés

A través de este ejemplo se pretende presentar el modo en que ambos lenguajes solucionan el problema de aplicar una funcionalidad transversal en un punto determinado del código. Implementaremos un mecanismos de caché extremadamente sencillo de manera que podamos centrar nuestra atención en los aspectos relevantes de las alternativas que estamos planteando

En el caso de AspectJ se está tendiendo a utilizar las anotaciones como un elemento de marcado (y parece que está siendo recibido con una aceptación más que notable). Nuestro primer paso será definir la anotación con la que realizaremos el "marcado" de aquellos métodos que deseamos establecer como cacheados:

@Retention(RetentionPolicy.RUNTIME)

public @interface Cachable {

String scriptKey () default "";

}

El atributo keyScript de la anotación anterior actuaría (en una caché real), como un pequeño lenguaje de scripting de manera que pudiera ser evaluado por la caché para generar la clave bajo la que se almacenará una determinada llamada (obviaremos esta parte para intentar no distraernos de nuestro principal objetivo).

Una vez definido el elemento de marcado, definiremos nuestro aspecto, el cual será capaz de capturar las llamadas de aquellos métodos anotados con @Cacheable y realizar la lógica necesaria de nuestra sencilla caché

En el caso de Scala llevaremos a cabo nuestra funcionalidad transversal mediante el uso de funciones de primer nivel (high order functions)

Gracias a la funcionalidad anterior, podemos pasar al método cache una función que será ejecutada en caso de ser necesario, devolviendo los valores de la caché en el supuesto de que haya sido calculado en un paso anterior.

Si comparamos las dos alternativas que hemos planteado hasta este momento:

En el caso de AspectJ, cada uno de los elementos que deseamos cachear tendremos que anotarlos con, valga la redundancia, la anotación que hemos definido anteriormente. Mientras tanto, en el caso de Scala, tendremos que recubrir cada uno de los métodos que deseamos cachear con la función de alto nivel (high order function).

En el caso de AspectJ estamos utilizando un "lenguaje" externo que actua como elementos de las claves de nuestra caché mientras que en el caso de Scala estamos utilizando el propio lenguaje de manera nativa, con el consiguiente beneficio que ello conlleva.

Esta ha sido nuestra primera aproximación a Scala y AspectJ. Durante las siguientes entradas analizaremos algunos ejemplos adicionales y veremos como podemos integrar lo mejor de ambos mundos.

Podéis encontrar el código fuente de los ejemplos anteriores en el siguiente repositorio de GitHub, concretamente en los proyectos AspectJCacheExample y ScalaCacheExample.

Hasta pronto!

Mecanismo de Load Time Weaving (LTW)

2011-06-03T21:47:00.000+02:00

Durante la última entrada analizábamos de manera introductoria los diferentes mecanismos de tejido ofrecidos por AspectJ así como las principales características de los mismos. Durante esta entrada nos acercaremos un poquito más al mecanismo de tejido en tiempo de carga, por normal general más desconocido, desde mi punto de vista, que el mecanismo de tejido en tiempo de construcción (durante todos los ejemplos que hemos visto en anteriores entradas siempre hemos utilizado el tejido en tiempo de construcción).

Los pasos que tenemos que seguir cuando utilizamos el tejido en tiempo de carga son los siguientes:

Iniciar nuestra aplicación con el archivo aspectjweaver.jar el actuando como un agente (hablaremos de agentes en otra entrada). Para ello podríamos utilizar una línea como la siguiente

java -javaagent:/aspectjweaver.jar

Durante el proceso de inicialización del agente (llevado a cabo por la máquina virtual) el propio agente recupera aquellos archivos existentes en el classpath que coincidan con META-INF/aop.xml (en el caso de encontrar múltiples llevará a cabo la combinación de los mismos).

Carga de los aspectos indicados.

El agente se registra como un listener del evento de carga de clases de la máquina virtual. Mediante este mecanismo se tiene acceso a la definición de la clase, permitiendo incluso la modificación de la misma.

Continua el proceso normal de carga de nuestro aplicación.

Cada vez que una nueva clase es cargada la máquina virtual notifica al agente dicha situación. En ese momento es posible examinar la clase en cuestión y determinar si algunos de los aspectos cargados con anterioridad necesita ser tejido. En caso afirmativo, la clase será tejida con el aspecto en cuestión, retornando el bytecode resultante a la máquina virtual.

La máquina virtual utiliza el bytecode resultante como elemento de definición de la clase.

Mediante el conjunto de pasos anteriores, aquellas clases que hayan hecho matching con las definiciones de nuestros aspectos tendrán incorporada la funcionalidad definida en éstos últimos.

El agente anterior utiliza un interfaz de la máquina virtual conocido como JVMTI (Java Virtual Machine Tools Interface) que ha sido introducido a partir de Java 5. En el caso de que utilicéis una versión anterior podréis hacer uso de este mecanismo mediante una versión basada en classloaders específicos.

Weaving en AspectJ (I)

2011-05-27T21:29:00.000+02:00

Hace un tiempo escribí una serie de entradas relacionadas con la orientación a aspectos en general y AspectJ en particular (podéis encontrar dichas entradas aquí) que posteriormente agrupé en un documento.

Hasta este momento nos hemos centrado en la teoría de la orientación a aspectos, cómo escribir los mismos y algunas de sus posibles aplicaciones. Sin embargo, no hemos prestado especial atención al modo en el que los aspectos se combinan con las clases para componer nuestro sistema final. Durante esta entrada y las siguientes profundizaremos en diferentes aspectos del proceso de tejido (weaving).

El mecanismo de tejido es aquel que nos permite combinar la definición de nuestras clases y de nuestros aspectos en un ente ejecutable que conforma nuestro sistema final.

Podemos clasificar los diferentes modelos en base al momento en el que llevan a cabo el tejido. En este caso tendríamos:

Build time. Las clases y los aspectos son combinados durante el proceso de construcción de nuestra aplicación.

Load time (LTW). En este caso el tejido se realiza en el momento en el que una clase se carga en la máquina virtual, por lo que en este caso no será necesario llevar a cabo ningún proceso adicional en nuestro proceso de construcción.

Otra posible clasificación podría establecerse en función del los tipos de entrada del proceso de weaving

Source code weaving. La entrada al proceso son archivos de código fuente (clases y aspectos)

Weaving binario (bytecode). La entrada al proceso es el bytecode obtenido como resultado del proceso de compilación de nuestras clases

De manera esquemática, a continuación se reflejan las diferente combinaciones ofrecidas por el weaver de AspectJ:

Tiempo de construcción: las entradas admitidas son tanto código fuente como clases compiladas (bytecode)

Tiempo de carga: las entradas pueden ser bytecode o un archivo xml (lo veremos más adelante)

Con esta pequeña entrada nos hemos aproximado de manera sencilla a los procesos de tejido presentes en AspectJ de una manera teórica. En futuras entradas analizaremos con un poco más de detalle los contenidos aquí presentados, haciendo especial hincapié en los mecanismos de tejido en tiempo de carga.

Hasta pronto!

Libros: últimas y futuras lecturas (II)

2011-05-21T09:25:00.000+02:00

Esta es la primera entrada que escribo desde mi reciente adquisición: un IMac 27''. Lo siento, tenía que decirlo :). A ver si me acostumbro a este, para mi, nuevo sistema operativo y le comienzo a sacar partido.

En la entrada anterior hablaba sobre algunas de las últimas y/o futuras lecturas realizadas durante esta última temporada. Puesto que no quería convertir dicha entrada en un ladrillo, se me quedaron algunos libros en el tintero que analizaremos a continuación.

Este libro llego a mis manos gracias a un profesor visitante de la UPM que estuvo impartiendo un seminario sobre wait free computing. Siento no recordar ahora su nombre (vaya cabeza que tengo).

Los profesores Maurice Herlihy, uno de los precursores de la memoria transaccional, y Nir Shavit nos ofrecen una visión novedosa de los nuevos paradigmas de programación para arquitecturas multinúcleo.

Los primeros capítulos son más teóricos, dejando la parte más divertida para la segunda mitad del libro. No he tenido ocasión de leérmelo de principio a fin pero si que me he leído capítulos independientes y he de reconocer que me han parecido mucho mejor de lo que esperaba. Espero sacar un poco de tiempo libre para poder leerlo al completo porque todo apunta que se puede convertir en uno de mis libros favoritos.

Desde que programo en Scala he aprendido muchas cosas nuevas, ya no sólo del lenguaje, sino de la programación funcional en general.

Siempre he querido dar mis primeros pasos en Haskell pero nunca he tenido tiempo y, sinceramente, me parecía un poco complicado. Tras el inicio de mi andadura en Scala creo que lo veo con otros ojos así que, en la medida de lo posible, voy a intentar dar mis primeros pasos en este lenguaje.

Todas las referencias que tengo de este libro son muy buenas pero ni siquiera lo tengo así que, cuando me decida a dar el paso, creo que será mi próxima adquisición.

Mi fascinación por la máquina virtual java crece por momentos (creo que ya quedó patente en la entrada anterior).

Clojure es un lenguaje dinámico (dialecto de Lisp) que se ejecuta sobre la JVM (compila directamente a bytecode). Destaca, y esto es lo que más me gusta, por su eficiente infraestructura para la programación multihilo.

Básicamente es un lenguaje puramente funcional que destaca por su amplio abanico de estructuras de datos inmutables y persistentes. En aquellos casos en los que el cambio es algo necesario, Clojure incluye en el propio lenguaje un sistema de memoria transaccional.

De nuevo se me quedan en el tintero muchos otros libros pero, de nuevo, no quiero que la entrada sea demasiado larga. En futuras entradas apostaré por comentar de uno en uno los libros ya leídos, intentando profundizar un poquito más de manera que si alguien estaba dudando si leérselo o no, puede tener una opinión más al respecto.

Hasta pronto!

Libros: últimas y futuras lecturas (I)

2011-05-14T09:33:00.000+02:00

Durante estos últimos meses mi tiempo libre se ha convertido en un bien escaso (prácticamente nulo) por lo que muchas de las cosas que me gusta hacer las he tenido que ir aplazando hasta encontrar un mejor momento. Una de ellas es actualizar el blog con una frecuencia un poco mayor a la habitual, y aprovechando que estoy en Esslingen (Alemania), que todo el mundo está durmiendo y que llevo rondando por ahí desde las seis y veinte de la maniana he decidido pasarme un rato por aquí :).

En esta ocasión me gustaría compartir con vosotros algunos de los últimos libros que me he leído, estoy leyendo, o tengo intención de leer.

Me he leído la primera edición y ahora estoy terminando la segunda. Creo que se trata de una referencia excelente tanto para aquellas personas que desean comenzar su andadura en Scala así como para desarrolladores más experimentados con conocimientos del lenguaje.

Si nunca habéis programado en Scala os recomiendo que le echéis un vistazo, os aseguro que no os defraudará. En este blog podréis encontrar una pequenia guía de introducción (en espaniol) así como numerosas entradas relacionadas con diferentes aspectos del lenguaje (espero que en un futuro este tipo de entradas puedan ir incrementando, tanto en calidad como en cantidad)

Una de mis últimas adquisiciones. Está en Beta pero ya me lo he leído. Necesitará una lectura completa de nuevo, aunque en esta ocasión tendrá que ser delante de una pantalla de manera que pueda "ensuciarme" :) las manos.

En este libro se tratan algunas de las técnicas/plataformas más novedosas de programación concurrente sobre la máquina virtual java. Nuevos mecanismos de concurrencia en las últimas versiones de Java, análisis de las bondades de Clojure para la programación concurrente, memoria transaccional, modelos de actores, Akka (hablaremos de Akka en futuras entradas), Scala, GPars.

Una lectura recomendable para aquellos que quieran sacarle partido a los procesadores multinúcleo o que quieran actualizar sus conocimientos sobre programación concurrente.

Qué son DSL? Para que se utilizan? Cómo escribo un DSL? En este libro , Debasish Ghosh desgrana hasta el último detalle de un temática tan popular en la actualidad como los lenguajes de dominio específicos. Una visión pragmática sobre la creación y utilización de lenguajes de dominio específicos ante la que ninguno se quedará indiferente.

A lo largo del libro se desarrollan numerosos ejemplos (complejos en muchas ocasiones) de diversa índole. Scala, Groovy, Clojure, Ruby y Java son los lenguajes utilizados en el desarrollo de los ejemplos por lo que, este libro, además de la temática principal, puede servir como una primera toma de contacto con alguno de los lenguajes de la máquina virtual Java que están adquiriendo una notable popularidad en estos días.

En este caso de trata de una recomendación de Matín Pérez a la que hacía tiempo que tenía ganas de meterle mano. No tengo una opinión forjada porque sólo llevo leídos dos capítulos pero la verdad que hasta el momento me está gustando mucho, tanto por la temática como por la manera que está escrito.

Recientemente he tenido la suerte de hacer algunas "cosillas" con la JVM pero por lo que he podido ver hasta el momento, este libro adquiere un nivel de detalle notable.

Prometo un post independiente cuando lo termine por completo pero me quedo con la idea de que este libro puede ayudar a escribir mejor código.

No quiero convertir esta entrada en un ladrillo (si no lo he hecho ya :) ) así que vamos a detenernos aquí. Continuaremos en la siguiente entrada con alguno que se ma quedado en el tintero.

Hasta pronto!!

PD: Espero que no haya demasiadas faltas de ortogafía; me está costando escribir desde este teclado alemán.

Parser Combinators: Parsing simple bytecode

2011-05-07T17:40:00.002+02:00

Anteriormente, http://miguelinlas3.blogspot.com/2011/03/parser-combinators-un-poco-de-teoria.html, introducíamos de manera somera el concepto de parser combinators y parte de la teoría relacionada con los mismos. Durante esta entrada vamos a construir un sencillo parser que nos permita analizar un conjunto mínimo de instrucciones de la máquina virtual java (simplemente permitiremos la definición de funciones y la capacidad de ejecución de las mismas).

No analizaremos en detalle el funcionamiento de la máquina virtual java ni el conjunto de instrucciones de la misma (podríamos llevarnos algo más que unos cuantos posts :) ) dado que el objetivo principal de esta entrada es profundizar en el concepto de parser combinators y presentar un ejemplo de uso real de los mismos. Pongámonos manos a la obra.

El código fuente que nos servirá como conductor de la entrada será el de la función factorial mostrado a continuación:

static int fact(int);

Code:

Stack=2, Locals=3, Args_size=1

0: iconst_1

1: istore_1

2: iconst_1

3: istore_2

4: iload_2

5: iload_0

6: if_icmpgt 19

9: iload_1

10: iload_2

11: imul

12: istore_1

13: iinc 2, 1

16: goto 4

19: iload_1

20: ireturn

Podréis objener el código desensamblado como el mostrado anteriormente mediante el comando javap -v Class donde Class represente un archivo bytecode.

El proceso de parsing se lleva a cabo mediante el uso de parser combinators (no perdamos de vista el objetivo de nuestra entrada ;) ) y presenta las siguientes características

Para cada una de las diferentes tipos de instrucciones soportadas definimos un parser combinator que es el encargado de parsear este tipo de instrucciones.
Cada uno de los parsers anteriores sabe cómo generar un objeto del tipo correspondiente. Se utiliza una jerarquía de tipos en la que cada una de las instrucciones bytecode soportadas está representada mediante una clase Scala.
El parser global construye un AST (en este caso es un simple lista de objetos) y un conjunto de infraestructura adicional con el objetivo de implementar un intérprete que ejecute la secuencia de instrucciones obtenida (fuera del ámbito de esta entrada podéis echarle un vistazo al código fuente)

¿Cómo actúan nuestros diferentes parsers? Analicemos por ejemplo el componente encargado de parsear las instrucciones ISTORE

lazy val beginInstructionFragment: Parser[Int] = integer <~ ":" ^^ { _.toInt}

lazy val iStoreBytecode: Parser[List[BytecodeInstruction]] = beginInstructionFragment ~> "istore_" ~ integer ^^ {

case name ~ value => new IStoreInstruction(name,value) :: List()

}

El parser beginInstructionFragment es el encargado de parsear la primera parte de la instrucción, la que corresponde al lugar que ocupa la instrucción en el array de instrucciones.

El segundo parser hace uso del primero y además sabe cómo parsear el texto restante de manera adecuada. En este caso nuestro este analizador es capaz de parsear las instrucciones istore_N donde N representa un número entero positivo cualquiera y devolver un objeto (dentro de una lista) de tipo IStoreInstruction en el que se incluyen el nombre de la instrucción y el entero correspondiente.

Como seguramente a muchos de los lectores de este post el fragmento de código anterior les suene un poco raro intentaremos analizar las diferentes opciones de combinaciones de parsers disponibles:

Si escribimos un parser en el que utilizamos una cadena, como por ejemplo "istore", el resultado es la propia cadena.
Podemos utilizar expresiones regulares, como por ejemplo, "[A-Z]".r . En este caso el resultado también sería la propia cadena
Si utilizamos el símbolo ~ (composición secuencial) el resultado del proceso de parseo será la combinación de ambos resultados. Por tanto, si A devuelve "X" y B devuelve "true", el resultado de A~B sería ~("X","true") (el tipo de este resultado sería una case class de tipo ~ . Adicionalmente podemos hacer uso de los operadores <~ y ~> los cuales mantienen los valores a la izquierda y a la derecha respectivamente.
Otro elemento de combinación de parsers sería | . En este caso el valor de retorno sería el de aquel parser que pudiera parsear la entrada con éxito.
rep(P) o rep(P,separator) retornan una lista de las múltiples ejecuciones de P.
opt(P) retorna una instancia de tipo Option.

Adicionalmente a la combinación de los parsers, necesitaremos un mecanismo que nos permita reescribir la salida de los mismos, en nuestro caso para instanciar los objetos de tipo necesario y configurar nuestro AST. Para ello tendremos que hacer uso del operador de transformación ^^.

Una definición formar del operador anterior sería: Dado un parser P y una funcion f cualesquiera, una expresión del tipo P^^f implica que para cada resultado R de P el resultado de la expresión global es f(R)

En el ejemplo que estamos tratando nuestra función es un simple pattern matching que transforma la case class retornada por nuestra combinación de parsers en un objeto de tipo IStoreInstruction.

No me ha resultado sencillo ponerlo por escrito y tampoco estoy seguro de que me haya explicado con la mayor claridad posible. Si estáis interesados os recomiendo que clonéis el repositorio alojado en GitHub

git://github.com/migue/parser-combinators.git

Hasta pronto!

Nuevo disco de Natch

2011-04-29T18:58:00.000+02:00

El nuevo disco de Natch Scratch, Mejor que el silencio, únicamente puede calificarse como algo ABSOLUTAMENTE INCREÍBLE.

Una de las canciones que más me gusta:

Hasta pronto!

PD: este finde intentaré continuar con el tema de los combinator parsers en Scala

Parser Combinators: un poco de teoría

2011-03-30T00:02:00.002+02:00

Puede que en algunas ocasiones os hayais tenido que enfrentar con la necesidad de escribir un pequeño lenguaje que realice una tarea muy concreta (profundizaremos en el tema de los DSLs en un post futuro): como, por ejemplo, procesar determinados archivos de configuración de vuestra aplicación o la definición de interfaces de usuario de manera sencilla.

Independientemente de las razones por las que estamos desarrollando este componente, necesitaremos un parser que nos ayude a transformar el lenguaje de entrada en una estructura de datos que nuestro programa pueda comprender y procesar. Algunas de las alternativas que se nos plantean son:

Escribir nuestro propio parser (conllevaría escribir también el analizador léxico). Si no somos expertos en la materia estaremos enfrentándonos a una tarea relativamente complicada.

Utilizar herramientas para la generación de parsers como Antlr,Bison o JavaCC entre otras muchas. En este caso la dificultad estriba en la necesidad de aprender a manejar una nueva herramienta/lenguaje e integrarlo en nuestro desarrollo y ecosistema.

Durante esta entrada, y posiblemente la siguiente, vamos a presentar un enfoque alternativo a las dos opciones anteriores. En lugar de utilizar un DSL externo como podría ser el ofrecido por Antlr, vamos a utilizar un DSL interno. Dicho DSL estará formado por parser combinators (funciones y operadores definidos en Scala que servirán como base para la construcción de nuestros futuros parsers).

Siendo originales :), imaginemos que deseamos cosntruir un parser de expresiones aritméticas de números enteros. En primer lugar, definamos la gramática de nuestro lenguaje:

expr ::= term {"+" term | "-" term}.

term ::= factor {"*" factor | "/" factor}.

factor ::= integer | "(" expr ")".

El fragmento de código anterior representa una gramática libre de contexto (no vamos a profundizar en este tema porque tendríamos que escribir miles de posts) que modela nuestro lenguaje de expresiones aritméticas de números enteros. ¿Y ahora?

Una vez definida la gramática anterior hemos llevado a cabo la tarea más complicada de todas. Si utilizais los parser combinators ofrecidos por Scala tendremos casi todo el trabajo sucio realizado. A modo de ejemplo:

import scala.util.parsing.combinator._

class IntegerArithmetics extends JavaTokenParsers {

def expr: Parser[Any] = term~rep("+"~term | "-"~term)

def term: Parser[Any] = factor~rep("*"~factor | "/"~factor)

def factor: Parser[Any] = integer | "("~expr~")"

}

Si comparamos el código Scala con la definición en notación EBNF de nuestra gramática observaremos que podríamos inferir nuestro código fuente Scala sin más que realizar una serie de reemplazos en nuestra notación EBNF:

Cada regla se convierte en un método por lo que tendremos que prefijarlas con def.
El tipo de retorno de cada uno de los métodos anteriores es Parser[Any] (veremos en la siguiente entrada que significa esto) por lo que tendremos que cambiar el símbolo "::=" por ":Parser[Any] ="
Insertar el símbolo ~ entre todos los elementos de cada una de las reglas (en la notación EBNF esto es implícito)
La repetición se refleja mediante el uso de rep(...) en lugar de {...}
El punto al final de cada regla no es necesario (podríamos poner ; si lo deseamos)

Esto no ha sido más que una toma de contacto con el mundo de los parser combinators en Scala. En la siguiente entrada descubriremos cómo realizar construcciones más complejas, formatear la salida de manera que podamos construir las estructuras de datos requeridas para nuestro procesamiento o ejecutar nuestros parsers.

Para todo ello diseñaremos y construiremos un pequeño parser que nos permita analizar el bytecode de la máquina virtual una vez desemsamblado (para los más inquietos javap -v ClassFile (sin .class))

Introducción a Scala

2011-02-23T08:27:00.000+01:00

El siguiente documento es un pequeño resumen (introductorio) sobre el lenguaje de programación Scala y alguno de sus beneficios. No es nada nuevo que no podáis encontrar en los libros de referencia :) pero a lo mejor a alguien le sirve para dar sus primeros pasos en este genial lenguaje de programación.

Espero que os guste:

DDD, Spring y AspectJ: inyección de depencias (II)

2011-02-21T22:44:00.000+01:00

En la entrada anterior analizabamos el uso de la anotación Configurable y cómo esta nos ayudaba a realizar la inyección de dependencias en nuestro objetos de dominio, ayudándonos de esta manera a realizar nuestro diseño siguiendo una filosofía orientada al dominio (podréis encontrar mucha información, artículos, referencias, ponencias, . . ., relativas a este tema en http://domaindrivendesign.org/).

Como ya comentamos anteriormente el uso de la anotación Configurable era beneficioso aunque si la clase anotada se instancia un gran número de veces podríamos incurrir en una notable pérdida de rendimiento puesto que la anotación anterior hace uso de la reflectividad. Adicionalmente, indicábamos que otro de los "problemas" era que nuestro código estaba acoplado a la plataforma, en este caso, Spring. Durante esta entrada plantearemos otro mecanismo de inyección de dependencias en nuestros objetos de dominio: inyección basada en interfaces de dominio.

Partiendo del ejemplo analizado en el ejemplo anterior, definiremos un nuevo interface PricingStrategyClient que presentará el método setPricingStrategy(PricingyStrategy pricingStrategy) . Todas aquellas entidades de nuestro dominio que necesiten esta funcionalidad deberán implementar el interfaz anterior.

Hasta el momento no hemos anotado nuestra clase con ningún artefacto adicional (@Configurable) por lo que ahora tendremos que escribir nuestro propio aspecto para inyectar las dependencias en nuestra clase de dominio. Para llevar a cabo este trabajo extenderemos un aspecto abstracto disponible en spring-aspects-3.0.5.jar (los ejemplos de estas entradas están desarrollados con la versión 3.0.5 de Spring) de tipo GenericInterfaceDrivenDependencyInjectionAspect. De manera resumida, este aspecto base determina cuando se crea una nueva instancia (o serializa) de nuestra clase e invoca al método configureBean. Nosotros únicamente deberemos implementar el método configure tal y como se muestra en el siguiente fragmento de código:

public aspect PricingStrategyDIAspect extends
GenericInterfaceDrivenDependencyInjectionAspect {
protected PricingStrategy pricingStrategy;
public PricingStrategy getPricingStrategy() {
return pricingStrategy;
}
public void setPricingStrategy(PricingStrategy pricingStrategy) {
this.pricingStrategy = pricingStrategy;
}
@Override
protected void configure(PricingStrategyClient bean) {
bean.setPricingStrategyClient(pricingStrategy);
}
}

Como último paso de nuestra nueva solución sólo tendremos que definir nuestro nuevo aspecto en el contexto de aplicación:

<bean class="com.blogspot.miguelinlas3.springexamples.ddd.domain.interfacedibased.PricingStrategyDIAspect"

factory-method="aspectOf">

</bean>

Una posible mejora sería incluir el aspecto anterior como un aspecto estático dentro del interfaz PricingStrategyClient de modo que estaríamos enfatizando la relación entre ambos aunque esto os lo dejo como ejercicio ;)

Spring I/O 2011: Hadoop, Cloud y Spring

2011-02-19T09:02:00.000+01:00

Las slides utilizadas en mi presentación del Spring I/O Madrid 2011. Muchas gracias a todos los asistentes (no me imaginaba que fueran a venir tantos :) ) por aguantarme durante una hora.

A lo largo del finde intentaré hacer un resumen de lo que ha sido para mi la Spring I/O Madrid 2011.

¡De nuevo muchas gracias a todos por asistir a la charla!

Grupo sobre escalabilidad en español

2011-02-14T18:51:00.000+01:00

El otro día, mientras revisaba alguno de los artículos y libros que tengo a medio leer, me "di cuenta" de que muchas de las cosas que me gustan están relacionadas con temas de programación distribuida, escalabilidad de sistemas y temáticas similares.

Pues bien, me he movido un poquito por la red y he intercambiado unos cuantos correos electrónicos con dos auténticos cracks: Martín Pérez y Marc de Palol en los que hemos estado hablando,un poco, sobre la posibilidad de crear un grupo relacionado con temáticas de escalabilidad.

¿Qué cosas tendrían cabida en el grupo os estaréis preguntando? Pues me imagino que las inquietudes y conocimientos de todos los participantes irán marcando un poco el devenir del mismo.

Nosotros, en un principio (Marc, plagio y añado alguna pincelada a tu correo inicial :) ) habíamos pensado en temas relacionados con la computación distribuida y escalabilidad en general: problemática, soluciones, frameworks, arquitecturas, alternativas, etc utilizados (o que podrían ser utilizados) en el desarrollo software de aquellas aplicaciones en las que el soporte a millones de usuarios concurrentes, el manejo de cantidades ingentes de datos o los tiempos de respuesta son requisitos altamente importantes.

La idea del grupo, al menos inicialmente, ya veremos si la cosa evoluciona y cómo evoluciona, no es ceñirse a ninguna tecnología en particular sino tratar los temas anteriores desde una perspectiva un poco más abierta.

Las tecnologías que podrían aparecer en el grupo, tal y como decía antes, vendrán marcadas por el interés que demuestre la gente por el mismo así como la orientación que se le quiera dar. A modo de "brainstorming" dejo algunas de los temas/tecnologías que, desde mi punto de vista, podrían aparecer:

Hadoop y todo su ecosistema: HBase, Hive, Zookeeper, Hive, . . . (aquí iría un largo ecétera : )
Modelos de actores: una alternativa "diferente" a la computación distribuida. Aquí habría cabida para hablar largo y tendido: Erlang y OTP, Scala, Akka, . . .
Temáticas relacionadas con el cloud (desde un punto de vista de sistemas escalables, no de usuario): ¿cómo se lleva a cabo la elasticidad de recursos en las plataformas PaaS como GAE, Amazon Beanstalk o Heroku? ¿Cuáles son las arquitecturas que utilizan este tipo de sistemas? ¿Qué técnicas utilizan para dar soporte a tantos usuarios y aplicaciones? . . .
Movimiento NoSQL: CouchDB, Cassandra, Riak, etc y otras alternativas diferentes como pueden ser las aportadas por plataformas como Greenplum o Vertica.
Seguro que muchísimas cosas más . . . .

¿Os animáis?

Martín ha comentado algo en su blog

http://brigomp.blogspot.com/2011/02/hadoop-y-hbase-en-lastfm.html

DDD, Spring y AspectJ: inyección de depencias (I)

2011-02-07T18:27:00.001+01:00

El paradigma de orentación a objetos promueve que los objetos deberían tener datos y comportamiento. Sin embargo, en la realidad esto no se cumple en muchas ocasiones; especialmente en los objetos de dominio, donde habitualmente las clases se convierten en meros contenedores de información que se van pasando de unas capas a otras, delegando la funcionalidad en capas de servicio externas, creando un modelo anémico (para más información podéis acudir a http://www.martinfowler.com/bliki/AnemicDomainModel.html).

A lo largo de las siguientes entradas promoveremos el paradigma de diseño dirigido por dominio y analizaremos como podremos enriquecer nuestros objetos de dominio mediante la inyección de dependencias. Para aquellos que estéis familiarizados con las últimas versiones de Spring, estas entradas no serán más que un paseo por los internals de @Configurable (anotación que podemos encontrar las versiones más recientes de este popular framework) unidos a un poco de teoría.

Imaginemos por un momento que estamos desorrollando una tienda online para la venta de libros electrónicos y que la siguiente clase modela nuestra entidad de dominio libro. Como podemos observar estamos delegando el cálculo del precio del libro en una clase independiente la cual será la encargada de realizar los cálculos necesarios (de este modo podremos configurar el precio del libro en función de nuestras necesidades). Y ahora: ¿cómo llevamos a cabo la inicialización del atributo pricingStrategy ?

Desde aquí vamos a promover el uso de inyección de dependencias, de manera que añadiendo la infraestructura necesaria (en ese caso un simple setter para el atributo en cuestión) podremos delegar en un contenedor la responsabilidad de inyectar las dependencias necesarias en el momento en el que se instancie nuestro objeto. Siguiendo esta filosofía podríamos intercambiar las estrategias de cálculo de precios sin más que realizar una ligera modificación en la configuración, sin la necesidad de modificar nuestro código fuente. Este enfoque también nos permite llevar a cabo nuestras pruebas unitarias de manera extremadamente sencilla.

Antes de comenzar a escribir nuestros propios aspectos (lo dejaremos para la próxima entrada) veamos cómo podríamos inyectar las dependencias en nuestro objeto de dominio mediante el uso de spring y un poco de configuración.

En primer lugar tendremos que indicarle a spring que nuestra clase de dominio Book necesita que sus dependencias sean inyectadas: para ello anotamos la definición de nuestra clase con @Configurable y añadimos un setter para nuestro atributo de clase pricingStrategy. Adicionalmente, anotaremos el setter anterior (o la propiedad) con @Autowired. Finalmente, definiremos en el contexto de aplicación de spring una implementación concreta del interfaz PricingStrategy e indicamos que estamos haciendo uso @Configurable mediante la instrucción

.

Con la sencilla configuración anterior, cada vez que instanciemos un objeto de la clase Book mediante el operador new: Book book = new Book() el atributo pricingStrategy será inyectado con la referencia adecuada.

El uso de @Configurable hace uso de la reflectividad por lo que en aquellos objetos que se instancian muy a menudo podríamos incurrir en un serio problema de rendimiento. Adicionalmente, el uso de esta anotación acopla nuestro código a Spring, creando una dependencia hacia el framework.

En la siguiente entrada analizaremos el uso de interfaces de dominio y escribiremos nuestros propios aspectos como alternativa a la solución presentada a lo largo de esta entrada.

Scala: Clases y objetos

2011-01-28T17:05:00.000+01:00

Durante esta entrada analizaremos algunas de las características básicas del paradigma orientado a objetos presentes en Scala. Pongámonos manos a la obra:

Del mismo modo que en todos los lenguajes orientados a objetos Scala permite la definición de clases en las que podremos añadir métodos y atributos:

class MyFirstClass{
val a = 1
}

Si deseamos instanciar un objeto de la clase anterior tendremos que hacer uso de la palabra reservada new

val v = new MyFirstClass

En Scala existen dos tipos de variables, vals y vars, que deberemos especificar a la hora de definir las mismas:

Se utilizará la palabra reservada val para indicar que es inmutable. Una variable de este tipo es similar al uso de final en Java. Una vez inicializada no se podrá reasignar jamás.
De manera contraria, podremos indicar que una variable es de clase var, consiguiendo con esto que su valor pueda ser modificado durante todo su ciclo de vida.

Uno de los principales mecanismos utilizados que garantizan la robustez de un objeto es la afirmación de que su conjunto de atributos (variables de instancia) permanezca constante a lo largo de todo el ciclo de vida del mismo. El primer paso para evitar que agentes externos tengan acceso a los campos de una clase es declarar los mismos como private. Puesto que los campos privados sólo podrán ser accedidos desde métodos que se encuentran definidos en la misma clase, todo el código podría modificar el estado del mismo estará localizado en dicha clase.

Por defecto, si no se especifica en el momento de la definición, los atributos y/o métodos, de una clase tienen acceso público. Es decir, public es el cualificador por defecto en Scala

El siguiente paso será incorporar funcionalidad a nuestras clases; para ello podremos definir métodos mediante el uso de la palabra reservada def:

class MyFirstClass{
  var a = 1
  def add(b:Byte):Unit={
a += b
  }
}

Una característica importante de los métodos en Scala es que todos los parámetros son inmutables, es decir, vals. Por tanto, si intentamos modificar el valor de un parámetro en el cuerpo de un método obtendremos un error del compilación:

def addNotCompile(b:Byte) : Unit = {
  b = 1 // Esto no compilará puesto que el
// parámetro b es de tipo val
  a += b
}

Otro aspecto relevante que podemos apreciar en el código anterior es que no es necesario el uso explícito de la palabra return, Scala retornará el valor de la última expresión que aparece en el cuerpo del método. Adicionalmente, si el cuerpo de la función retorna una única expresión podemos obviar la utilización de las llaves.

Habitualmente los métodos que presentan un tipo de retorno Unit tienen efectos colaterales, es decir, modifican el estado del objeto sobre el que actúan. Otra forma diferente de llevar a cabo la definición de este tipo de métodos consiste en eliminar el tipo de retorno y el símbolo igual y englobar el cuerpo de la función entre llaves, tal y como se indica a continuación:
class MyFirstClass {
  private var sum = 0
  def add(b:Byte) { sum += b }
}

En la siguiente entrada introduciremos el concepto de singleton objects. También intentaré que la apariencia de las entradas sea un poquito más atractiva utilizando el genial servicio ofrecido por http://pastie.org

Scala: Primeros pasos (cont)

2011-01-27T23:14:00.000+01:00

En la entrada anterior comenzabamos nuestra pequeña aventura en Scala analizando las características principales del paradigma orientado a objetos y revisando alguna de las contribuciones que este lenguaje presenta al modelo. Durante la entrada que nos ocupa revisaremos brevemente los fundamentos del paradigma funcional y analizaremos cómo Scala incorpora y unifica lo mejor de ambos paradigmas en un lenguaje estáticamente tipado.

La programación funcional es un paradigma en el que se trata la computación como la evaluación de funciones matemáticas y se evitan los programas con estado y datos que puedan ser modificados. Se adopta una visión más matemática del mundo en el que los programas están compuestos por numerosas funciones que esperan una determinada entrada y producen una determinada salida y, en muchas ocasiones, otras funciones.

Otro de los aspectos de la programación funcional es la ausencia de efectos colaterales gracias a los cuales los programas desarrollados son mucho más sencillos de comprender y probar. Adicionalmente, se facilita la programación concurrente, evitando que se convierta en un problema gracias a la ausencia de cambio.

Los lenguajes de programación que soportan este estilo de programación deberían ofrecer algunas de las siguientes características:

Funciones de primer nivel
Closures
Asignación simple
Evaluación tardía
Inferencia de tipos
Optimización del tail call
Efectos monadic

Es importante tener claro que Scala no es un lenguaje funcional puro dado que en este tipo de lenguajes no se permiten las modificaciones y las variables se utilizan de manera matemática (un ejemplo de lenguaje funcional puro sería Haskell).

Durante las dos últimas entradas hemos centrado nuestra atención en algunos de los aspectos más teóricos por lo que posiblemente a los (pocos) que hayáis leído esto se os haya hecho demasiado aburrido.

Esperemos que la siguiente entrada sea más entretenida.

Scala: Primeros pasos

2011-01-18T22:07:00.001+01:00

Me gustaría comenzar una serie de post relativos al lenguaje de programación Scala para que, si alguien se pasa por aquí y tiene interés, pueda dar sus primeros pasos en este fantástico lenguaje. Dejar claro desde el principio que no soy, ni por asomo, un experto :) , aunque intentaré explicarme con la mayor claridad que me sea posible.

Para comenzar, un poquito de teoría e historia:

Scala es un lenguaje de propósito general diseñado para expresar los patrones de programación más comunes de una manera sencilla, elegante y segura. Integra de manera sencilla características de orientación a objetos y lenguajes funcionales, permitiendo de este modo que los desarrolladores puedan ser más productivos. Su creador, Martin Odersky, y su equipo comenzaron el desarrollo de este nuevo lenguaje en el año 2001, en el laboratorio de métodos de programación en EPFL (École Polytechnique Fédérale de Lausanne)

Scala hizo su aparación pública sobre la plataforma JVM (Java Virtual Machine) en enero de 2004 y unos meses después haría lo propio sobre la plataforma .NET. Aunque se trata de un elemento relativamente novedoso dentro del espacio de los lenguajes de programación, ha adquirido una notable popularidad la cual se acrecenta día tras día.

Orientación a objetos

Un lenguaje orientado a objetos "puro" debería presentar las siguientes características:

Ocultación de información.

Herencia.
Polimorfismo/Enlace dinámico.
Todos los tipos predefinidos son objetos.
Todas las operaciones son llevadas a cabo mediante en envío de mensajes a objetos.
Todos los tipos definidos por el usuario son objetos.
Scala da soporte a todas las características anteriores mediante la utilización de un modelo puro de orientación a objetos muy similar al presentado por Smalltalk (lenguaje creado por Alan Kay sobre el año 1980).

De manera adicional Scala añade algunas innovaciones en el espacio de los lenguajes orientados a objetos:

Composición modular de mixin. Mecanismo que permite la composición de clases para el diseño de componentes reutilizables evitando los problemas presentados por la herencia múltiple. Similar a los interfaces Java y las clases abstractas. Por una parte se pueden definir múltiples "contratos" (del mismo modo que los interfaces). Por otro lado, se podrían tener implementaciones concretas de los métodos.
Self-type. Los mixin no dependen de ningún método y/o atributo de aquellas clases con las que se está entremezclando aunque en determinadas ocasiones será necesario hacer uso de las mismas. Esta capacidad es conocida en Scala como self-type
Se ha optado por mantener el término original disponible en la documentación del lenguaje.
Abstracción de tipos. Existen dos mecanismos principales de abstracción en los lenguajes de programación: la parametrización y los miembros abstractos. Scala soporta ambos estilos de abstracción de manera uniforme para tipos y valores

Vamos a dejar la entrada en este punto para no convertirla en un ladrillo (más aun de lo que ya es) y en el próximo post analizaremos, de manera general, las características generales del paradigma funcional.

2011: Propósitos

2011-01-04T21:36:00.000+01:00

2010 ha sido un año complicado en muchos sentidos y creo que, en la medida de lo posible, hemos hecho todo lo posible para que las cosas nos hayan ido bien.

Aunque no soy excesivamente partidario de los propósitos de año nuevo voy a hacer una excepción. Voy a hacer una lista de cosas que me gustaría realizar durante este nuevo año que acabamos de comenzar:

Pasar mucho más tiempo con mi futura esposa. Soy consciente de que a veces me enfrasco en muchas cosas que no deberían quitarme tanto tiempo. Es algo en lo que tengo mejorar y por eso está en la primera posición de mi lista

Casarme. Si señores, como bien habréis deducido del punto anterior, este año me caso. Creo que no necesita mayor explicación :)

Retomar el deporte.

Leer, leer y leer. Terminar la interminable lista de libros y artículos que tengo pendientes además de todos los que están por venir :)

Comenzar mi tésis doctoral. Estoy empezando a escribir la tesina, la cual si todo va bien, servirá como base para mi tésis doctoral. Ligado con el mundo investigador este año me esforzaré por publicar algún artículo.

Programar, programar, y programar. Reactivar mi participación en alguno de los proyectos de software libre en los que participaba hace tiempo y en los que, por diversos motivos, he tenido que reducir mi participación a la mínima expresión.

. . .

Seguramente muchas de las anteriores tareas se quedarán en el tintero por diversos motivos aunque esperemos que con muchas ganas y esfuerzo algunas de ellas salgan adelante.

Un abrazo y feliz 2011 para tod@s!

Objective: to improve my English

2010-12-19T13:56:00.000+01:00

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

2010-11-04T23:44:00.000+01:00

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?

2010-10-26T00:21:00.000+02:00

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

2010-08-11T23:49:00.000+02:00

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

2010-08-01T10:17:00.001+02:00

A sample overview of the main features of PaaS

Platform as a Service overview

View more presentations from Miguel Pastor.

HadoopDB: a brief overview

2010-07-27T09:14:00.001+02:00

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

HadoopDB

View more presentations from Miguel Pastor.

Aspect Oriented Programming Intro Guide

2010-06-22T10:29:00.000+02:00

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)

2010-06-19T11:03:00.000+02:00

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:

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.
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.
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

2010-06-16T07:47:00.000+02:00

Software measure-slides

View more presentations from Miguel Pastor.

Resérveme esa mesa por favor

2010-06-13T11:02:00.000+02:00

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)

2010-05-30T20:03:00.000+02:00

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

2010-05-21T06:33:00.000+02:00

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

2010-05-12T00:21:00.001+02:00

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

2010-05-07T06:56:00.002+02:00

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

2010-05-03T23:48:00.000+02:00

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).

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()

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

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

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

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

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

2010-05-02T13:26:00.000+02:00

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

2010-04-18T11:05:00.001+02:00

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

2010-04-10T15:56:00.000+02:00

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

2010-03-31T17:25:00.000+02:00

Ú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

2010-03-25T23:16:00.000+01:00

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

2010-03-16T20:21:00.001+01:00

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

2010-03-15T23:54:00.000+01:00

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

2010-03-15T15:06:00.000+01:00

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

2010-03-08T22:36:00.000+01:00

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.

La vuelta al cole

2010-02-14T16:51:00.001+01:00

Como ya os comentaba en el post anterior (si es que se puede llamar así :( ) últimamente el tiempo se ha convertido en un bien escaso. No sé cómo demonios me las apaño pero nunca tengo tiempo a hacer/terminar todas las cosas que me he propuesto.

El motivo principal de esta entrada era contaros que me han aceptado en un posgrado de la politécnica de Madrid y que a partir del miércoles 17 de febrero regresaré a las clases de manera oficial. Si alguien me preguntase cuáles son las motivaciones que me han llevado de nuevo a la facultad no estoy seguro cuál sería la respuesta; puede que algo tan simple como un "me apetece". En principio parece muy interesante y, aunque compaginarlo con el trabajo implicará grandes esfuerzos, estoy dispuesto a intentarlo. Ya os iré contando qué tal son las clases y cómo me voy defendiendo.

Cambiando de tema, había estado pensando en comprarme un netbook (no es una necesidad imperiosa, es más bien un capricho :) ). ¿Alguno me puede dar alguna recomendación? Había pensado en un DELL pero me da rabia tener que pagar la licencia de Windows. Agradecería cualquier tipo de consejo y/o sugerencia.

Hasta pronto!

Sin demasiado tiempo

2010-02-05T09:04:00.000+01:00

Estos últimos días he estado bastante atareado y no he tenido ocasión de escribir nada en el blog. Espero que esta tarde y el fin de semana tenga un hueco para redactar alguna entrada nueva.

Tendré que sacar tiempo de algún sitio :).

Hasta pronto!

Desilusión

2010-01-22T06:15:00.000+01:00

Llevo un par de días en los que no estoy durmiendo demasiado bien (algo muy raro en mi :) ) así que aquí estoy leyendo un poco y viendo la tele hasta que llegue la hora de ir a trabajar.

Últimamente tengo un montón de cosas en la cabeza: la posible vuelta a la Universidad (cuando lo tenga decidido escribiré otro post relativo a este tema), la búsqueda de una casa, . . . y el trabajo. Y creo que es este último el que me está quitando el sueño. Cuando decidí regresar a Madrid lo hice con la firme convicción de seguir creciendo, tanto personal como profesionalmente, y de momento las cosas no están siendo como yo pensaba ni muchísimo menos, es más, creo que en lugar de caminar hacia adelante estoy retrocediendo.

¿Y por qué tengo esta sensación me pregunto? Básicamente porque no se están cumpliendo ninguna de las cosas que me habían dicho; tengo menos responsabilidades y capacidad de decisión que cuando estaba en Gijón así que . . . .

La primera medida es que no pienso hacer ni un minuto de más, pero ni uno solo. En otras ocasiones hemos hecho horas y horas de más (fines de semana incluidos) que no han tenido ningún tipo de recompensa. Lo que no de tiempo a hacerse no es mi problema, que se las apañen.

Voy a centrarme en las cosas que me interesan y que me permitan seguir creciendo haciendo lo que más me gusta: puede que regrese a la Universidad y voy a poner en marcha un par de proyectos que tenía en mente.

Por último, voy a considerar seriamente una interesante oferta que tengo sobre la mesa.

Ya sé que no son horas de estar levantando, ni mucho menos de soltar este auténtico rollo, pero simplemente me apetecía escribirlo, y para eso el blog es mío :).

No os preocupéis, enseguida volverán las cosas aburridas: más Groovy (AST Transformations, DSL, ...), una serie de posts dedicados a la construcción de aplicaciones web basadas en OSGI, intentaré continuar con la serie de post dedicados a AspectJ comenzada hace tiempo, . . . y alguna cosilla más.

Bueno, voy a ir duchándome y esas cosas que dentro de un rato tengo que salir para ir cogiendo el metro.

Hasta pronto!

PD: esta tarde la gordita y yo iremos a una feria de la vivienda de segunda mano que se celebra en el palacio de congresos. Los pisos que allí se expongan deben presentar un precio reducido entre un 30 y un 40% respecto a su valor de tasación máximo en 2006. Ya os contaré a la vuelta.

El segundo mundo

2010-01-21T19:15:00.000+01:00

Este es el título del libro que estoy leyendo actualmente. Un viaje a lo largo de todo el mundo mostrando cómo el dominio estadounidense se está viendo reemplazado por un mercado geopolítico en el que tanto China como la Unión Europeoa compiten con Estados Unidos para configurar el nuevo orden mundial en sus propios términos. Todavía no he terminado de leerlo pero la verdad que hasta el momento me está gustando bastante.

Aquí os dejo un enlace al libro: El Segundo Mundo, y un enlace a la bibliografía del autor: Parag Khanna.

Hasta pronto!

AIGUANTULIVINAMERICA

2010-01-17T11:44:00.000+01:00

Ayer por la noche la gordita y yo estuvimos en el teatro de La Chocita del Loro para ver en directo uno de los últimos monólogos de Goyo Jiménez, AIGUANTULIVINAMERICA. Sinceramente, no tengo palabras para describir el arte que tiene el tío: gracioso, ameno, espontáneo, interactuando con el público, infinidad de recursos, . . ., en fin, un fuera de serie. Lo conocía de ver sus monólogos en YouTube, pero, desde luego, el directo supera con creces todos los vídeos que había visto hasta el momento.

A lo largo de su actuación realiza una comparativa de las vidas españolas respecto a sus homólogas americanas, explicando los motivos por los que éstas últimas son mucho mejores. Dos horas de diversión ininterrumpida altamente recomenbables.

Por si a alguien le interesa, nosotros compramos las entradas en Atrápalo con unos diez días de antelación aproximadamente, y nos costarón 16€/persona. El próximo martes iremos a la sala Joy Slava para ver en directo a varios de los monologuistas de Paramount Comedy.

Hasta pronto!

PD: Ayer he conocido una tienda de gominolas en la calle Fuencarral para quitar el hipo. La tienda es muy cara (creo que a 1.80€ los 100 gramos) pero desde luego son las mejores gominolas que he comido en la vida.

Primer post del año

2010-01-06T15:12:00.000+01:00

Día de Reyes y aquí estoy sentado en el sofá leyendo uno de los múltiples libros que tengo pendientes. Parece ser que este año me he portado bastante bien porque los Reyes Magos me han dejado unos cuantos regalos: chaqueta y jersey de G-Star, un pijama, un máquina para cortar el pelo ( y la barba :) ), un juego de sumiller, un lector de DNIe ( y varios tipos de tarjetas) y algo de dinero; la verdad es que no me puedo quejar.

Como ya os había comentado en una entrada anterior, he pasado las Navidades en casa de mis padres, intentando aprovechar al máximo los pocos días disponibles: he pasado bastante tiempo con mi familia y los peques, he quedado con Andre,Moreno y Vicio, con mis amigos de Lastres (por fin he conocido el Rancho Chico), . . . no sé, realmente me han resultado fructíferas estas vacaciones.

Y ahora que las Navidades ya se han terminado comienzo el año con energías renovadas y ganas de poner en marcha alguna de las ideas que me rondan por la cabeza. Puede que dentro de poco se avecinen cambios pero tampoco quiero adelantarme a los acontecimientos.

Para terminar os dejo alguna foto que Ita y yo hicimos con los peques cuando estuvimos en Mercaplana:

Hasta pronto!

Año viejo. Año nuevo

2009-12-23T00:30:00.000+01:00

Posiblemente este sea el último post del año puesto que mañana me quedo de vacaciones y en casa de mis padres no dispondré de conexión a Internet. Si alguien me necesita que recurra al viejo truco del teléfono móvil.

Antes de continuar con el post me gustaría deciros que ya he recibido mi regalo de Papa Noel que me ha hecho la gordita: Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages

No se ha liberado todavía (posiblemente en Enero) pero de esta manera iré recibiendo todas las actualizaciones del libro a medida que se vayan realizando. Tengo que terminar un par de lecturas que tengo a medias aunque no se si podré esperar para comenzar a leerlo :).

En primer lugar quería desearos desde aquí una Feliz Navidad y año nuevo, que disfruteis mucho de estos días de vacaciones (aquellos que podais disfrutar de ellos) en compañía de vuestra gente.

No suelo hacer los típicos propósitos de año nuevo, aunque si voy a dejar por escrito las cosas que me gustaría hacer el próximo año. Si logro cumplirlas, bienvenido sea, aunque si no las realizo tampoco pasará nada :).

Pasar mucho más tiempo con la gordita (esta es la más importante)
Viajar a Japón
Regresar a Alemania (para ésto ya tenemos billetes :) )
Intentar quedar lo máximo posible con los amigos que ahora no están tan cerca (esto también es muy importante)
Comenzar las clases del Máster (esto no depende de mi directamente, sino de la Politécnica de Madrid)
Continuar con la construcción de R-Eclipse: soporte para intérpretes remotos y construcción de un depurador.
Comenzar el desarrollo de Visual-R, una herramienta gráfica para el desarrollo de aplicaciones R. La idea es que se complemente con R-Eclipse de manera sencilla. Estará basada en EclipseRCP, GMF,EMF, GEF,Spring,Maven, etc. Lo voy a liberar así que si alguien se anima y quiere participar no tiene más que decírmelo.
Terminar de darle caña a Erlang que cada día que pasa me gusta más. (también debería continuar con Scala que hace tiempo que lo tengo parado)
Leer todos los libros que tengo pendientes. No los enumero porque se me haría un post eterno :)
Ver todos los videos que me he bajado de InfoQ, para ello el Itouch será un inestimable compañero de viaje.

Repaso la lista y me parece que son demasiadas cosas (más algunas que no he puesto). Esperemos que dentro de un año me pueda sentar frente al ordenador y pueda revisar cuáles he llevado a cabo y cuáles se han quedado en el tintero.

Ya me despido que es demasiado tarde y mañana, bueno hoy :), tengo que madrugar. Desearos de nuevo unas felices fiestas y todo lo mejor para el próximo año.

Un abrazo!

Migue

Groovy Metaprogramming: Categories (I)

2009-12-20T18:24:00.002+01:00

Groovy nos ofrece un amplio conjunto de técnicas de metaprogramación: Categories, Interceptors, metaclases, etc. A lo largo de una serie de posts analizaremos en detalle algunas de las características anteriores: comencemos por las Categories.

En muchas ocasiones es necesario que alguna clase que no está bajo nuestro control disponga de métodos adicionales. Gracias a las Categories, Groovy introduce esta funcionalidad en el lenguaje (la ha tomado prestada de Objective-C). El propio lenguaje incorpora alguna Category como DOMCategory o ServletCategory, de la cual vamos a ver algún sencillo ejemplo.

El principal objetivo de ServletCategory persigue que los atributos de objetos que implementan el Servlet API puedan ser tratados como properties dado que no siguen las convenciones establecidas por JavaBeans.

En el ejemplo de GroovyServlet visto en un post anterior (Groovlets), analizamos cómo nuestros scripts Groovy podían actuar como servlets, permitiéndonos realizar accesos mediante properties contra el objeto de la request. Para conseguir ésto, desde el código Java, se invoca a GroovyCategorySupport de un modo similar al siguiente:

Closure closure = new Closure(gse) {
   public Object call() {
       try {
           return ((GroovyScriptEngine) getDelegate()).run(scriptUri, binding);
       } catch (ResourceException e) {
           throw new RuntimeException(e);
       } catch (ScriptException e) {
           throw new RuntimeException(e);
       }
   }
};
GroovyCategorySupport.use(ServletCategory.class, closure);

Gracias al código anterior podríamos acceder mediante su nombre a diversos componentes como la session o la request:

if (session.count == null) session.count = 1;

en lugar de acceder a través del API:

if (session.getAttribute("count") == null) then session.setAttribute("count", 1);

Con este pequeño ejemplo hemos visto qué son y cómo podemos utilizar las Categories proporcionadas por el lenguaje pero . . . ¿Cuáles son los pasos a seguir si deseamos crear nuestras propias Categories?
Asentemos los conocimientos que hemos adquirido en esta entrada para generar nuestras propias construcciones en el siguiente post :).

Hasta pronto!

Un paso atrás

2009-12-18T00:20:00.000+01:00

Ya han pasado quince días desde que he regresado a Madrid y me gustaría hacer un pequeño balance en voz alta de cómo están siendo las cosas hasta este momento.

La nueva vida aquí con la gordita no dista mucho de la que hacíamos en Gijón e intentamos aprovechar al máximo el poco tiempo que tenemos disponible: un finde en Valencia, una cata de cacique 500 en casa de unos amigos, de cañitas siempre que podemos, nos hemos comprado unos billetes para Berlín y Stuttgart por Semana Santa, el otro día estuvimos comiendo en el Viavélez, . . . seguro que se me olvida algo :) .

También es cierto que regresar a Madrid ha tenido cosas sus efectos "negativos", y ahora tenemos un poco más lejos al "Fori" y a Martita, a Andre y Moreno, a Vicio, . . .. Será algo a los que nos tendremos que ir acostumbrando con el paso del tiempo. ¡Os echo de menos!

Por último, y es el tema por el que estoy un poco preocupado, el trabajo. Uno de los motivos por los que decidí regresar a Madrid fue la de intentar darle un nuevo empujón a mi carrera e intentar seguir mejorando al máximo. Pues bien, tal y como reza el título del post, me parece que estoy caminando hacia atrás y las cosas no están siendo ni mucho menos como yo esperaba. Me siento engañado y eso es algo que no soporto en absoluto. No voy a extenderme demasiado respecto a este tema porque, sinceramente, estoy bastante, decepcionado y sé que si continuo escribiendo me voy a poner de más mala leche todavía si cabe.

Para terminar, que se está haciendo tarde, voy a hacer un propósito de intenciones :). Voy a intentar escribir todos los días en el blog sobre las cosas que más me gustan: arquitectura de software, lenguajes de programación, libros, frameworks, diseño, calidad, etc. De vez en cuando haré algún post de este calibre para contaros como continuan las cosas o si tengo alguna novedad.

Un abrazo!

Migue

Groovlets

2009-12-16T23:36:00.002+01:00

Me imagino que la gente dedicada al desarrollo web estará acostumbrada al concepto de servlet, y posiblemente, hayan escrito muchos de ellos.

Voy a mostraros una forma sencilla de escribir y configurar servlets en el lenguaje Groovy. Esta funcionalidad compilará nuestros archivos .groovy en el bytecode correspondiente, cargará la clase, y la cacheará, hasta que se produzca un cambio en el archivo groovy inicial.

El primer paso que vamos a dar es añadir el soporte para los Groovlets, para lo que necesitaremos añadir en el archivo web.xml de la aplicación web el siguiente fragmento de código:

<servlet><servlet-name>Groovy</servlet-name>

<servlet-class>groovy.servlet.GroovyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Groovy</servlet-name>
<url-pattern>*.groovy</url-pattern>
</servlet-mapping>

Ahora estamos en disposición de escribir un servlet en el lenguaje Groovy (llamemoslo hello.groovy). Veamos un ejemplo sencillito:








if (!session) {
  session = request.session(true)
}

if (!session.counter) {
      session.counter = 1
}

html.html {    // utilizamos del MarkupBuilder 
               // para construir una página tonta de respuesta
  head {
      title("Esto es un Groovy Servlet")
  }
  body {
    p("Bienvenido, ${request.remoteHost}: ${session.counter}! ${new Date()}")
  }
}


// incrementamos el contador en la sessionsession.counter = session.counter + 1

En el servlet (groovlet) anterior existen una serie de variables implícitas tales como, request, response, context, application, session, params, headers, out, sout y html.

Un paso adicional de configuración, sumamente importante, para poner nuestro groovlet en marcha, consiste en incluir las dependencias necesarias. La opción más sencilla es incluir el archivo groovy-all-XXX.jar en el directorio WEB-INF/lib de la aplicación web.

Si, por ejemplo, colocamos los archivos .groovy en el raiz de nuestra aplicación el servlet de groovy se encargará de compilar los archivos. En el caso de tomcat podríamos editar el archivo tomcat/conf/server.xml del siguiente modo:

<Context path="/groovy" docBase="c:/groovy-servlet-base"/>

Podríamos acceder al archivo creado anteriormente mediante la siguiente ur:l http://localhost:8080/groovy/hello.groovy

Hasta pronto,
Migue

No Internet

2009-12-01T18:14:00.001+01:00

Estoy a la espera de que nos instalen la conexión ADSL y el teléfono fijo en casa así que hasta que no llegue dicho momento sólo podré postear alargando un poco la estancia en la oficina. Esperemos que nos hagan pronto la instalación.

Por si a alguien no se lo había comentado, he regresado a Madrid, a ver que pasa. De momento las cosas no han empezado demasiado bien, y me parece que me han tomado por tonto, ya veremos a ver que pasa . . .

Hasta pronto!

Por fin

2009-11-28T09:41:00.000+01:00

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

2009-11-23T17:11:00.004+01:00

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)

2009-11-20T17:17:00.006+01:00

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

2009-11-18T21:55:00.004+01:00

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

2009-11-13T09:38:00.003+01:00

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

2009-11-05T21:41:00.005+01:00

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)

2009-10-16T18:18:00.004+02:00

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)

2009-10-08T23:19:00.002+02:00

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

2009-10-04T21:49:00.003+02:00

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

2009-10-01T15:00:00.004+02:00

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

2009-09-30T07:52:00.003+02:00

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

2009-09-12T12:19:00.003+02:00

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)

2009-08-22T12:14:00.003+02:00

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)

2009-08-22T12:03:00.003+02:00

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

2009-08-07T11:07:00.004+02:00

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

Bye!

Frameworks

2009-08-07T10:43:00.003+02:00

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

2009-07-11T11:29:00.004+02:00

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

2009-07-03T19:44:00.005+02:00

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

Ita again

Bye!

Amsterdam Trip

2009-06-25T22:32:00.002+02:00

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

2009-06-16T23:09:00.003+02:00

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!

Some New York Photos (I)

2009-06-03T21:01:00.008+02:00

Some of our New York pictures:

Murrays bagel: ummmmm!!! Our favourite breakfast :-)

M&M´s store:

Central Park from TOR:

St Pauls Chapel
Manhattan:

New York night from Empire State:

The SDHC card has more than 750 pictures :) ; i´ll upload some of them in future posts!

Bye!!

New York Holidays

2009-05-18T07:57:00.002+02:00

Next few days i will be in New York with my girlfriend :).

I´ll tell you to the back!

See you soon!!

My last favourite ebooks

2009-05-13T22:27:00.003+02:00

Some of my favourite last reads:

Incoming . . .

Equinox and Osgi: The power behind Eclipse (noy yet published)
Eclipse Modeling Project: A domain-specific language (DSL) Toolkit
AspectJ in Action,Second Edition (MEAP available)
. . . . . .

I´m trying to practice my poor English :)

Bye!