jueves, noviembre 05, 2009

New Languages. Building IDE's

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

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

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

  • Utiliza AspectJ añadiendo puntos de unión al modelo JDT
  • Se encapsula en puntos de extensión de Eclipse, haciéndolo extensible a terceras partes.
  • Utiliza un proyecto de Eclipse conocido como Equinox Aspects que soporta el proceso de tejido en tiempo de carga en un entorno OSGI.
La construcción de entornos de desarrollo para otro tipo de lenguajes, que podríamos denominar de scripting, como puede ser JavaScript,Python,Tcl o Ruby se puede basar en un enfoque diferente al anterior, mediante el uso del proyecto DLTK de Eclipse (www.eclipse.org/dltk).

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

Hasta pronto!

viernes, octubre 16, 2009

Modelo de Joint Point (y II)

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

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

A continuación esbozamos, de manera esquemática, los pasos que se deberían seguir:
  • Identificar los puntos del sistema que necesitan ser protegidos, comprobando, antes de realizar el acceso, que el usuario que está realizando el acceso está autenticado y tiene los privilegios necesarios para hacerlo. En resumen, estamos identificando los "joint point" que requieren ser securizados.
  • Construiremos un pointcut (o varios, todos los que sean necesarios), que permitan la selección de los "joint point" descritos en el punto anterior.
  • Construiremos un aspecto que encapsule toda la lógica de seguridad requerida.
Esto es un mera introducción a los conceptos que componen un sistema orientado a aspectos, concretamente AspectJ. En el siguiente post analizaremos las categorías de joint points expuestas por AspectJ y el modo en el que podemos realizar la definición de los pointcuts que las capturen.

jueves, octubre 08, 2009

Modelo de Joint Point (I)

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

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

  • Identificar los puntos del sistema que necesitan ser protegidos, comprobando, antes de realizar el acceso, que el usuario que está realizando el acceso está autenticado y tiene los privilegios necesarios para hacerlo. En resumen, estamos identificando los "joint point" que requieren ser securizados.
  • Construiremos un pointcut (o varios, todos los que sean necesarios), que permitan la selección de los "joint point" descritos en el punto anterior.
  • Construiremos un aspecto que encapsule toda la lógica de seguridad requerida.
Los conceptos anteriores son sumamente importantes dado que componen la base de AOP. A lo largo de los siguientes postz profundizaremos en cada uno de ellos.

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

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

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

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

Hasta pronto,

Migue

domingo, octubre 04, 2009

AOP en el mundo real

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

  • Aplicaciones empresariales .Gestión de transacciones, seguridad, auditoría, monitorización, gestión de la concurrencia, manejor de errores y un largo ecétera son funcionalidades transversales en la mayoría de aplicaciones empresariales. Aquellas aplicaciones que usen Spring como base de su arquitectura ya estarán utilizando algunos de los aspectos que vienen facilitados por el framework. Gracias a las anotaciones, concretamente @Aspect, la construcción de aspectos se ha convertido en una tarea habitual.
  • Web y servidores de aplicaciones. Aplicación de políticas, FFDC, recolección de contextos,trazabilidad o monitorización son algunas de las funcionalidades basadas en AOP que podemos encontrar en los servidores de aplicaciones. Spring Source DM Server y TC Server son un claro ejemplo de estas funcionalidades.
  • Frameworks. Gestión de transacciones y seguridad son habitualmente implementadas mediante aspectos. Asimismo, otras utilizaciones de los aspectos podría ser la inyección de dependencias en en objetos de dominio. Para obtener un amplio abanico de posibilidades de uso de los aspectos, el usuario podría visitar los proyectos de Spring Roo o Apache Magma.
  • Herramientas de monitorización. El uso de aspectos facilita también la construcción de herramientas de monitorización. Muchas herramientas utilizan AspectoJ como tecnología subyacente: Glassbox,Perf4J,Contract4J,JXInsight o MaintainJ son algunos de los ejemplos.
  • Compiladores e integración de IDE's.La propia gente de AspectJ utiliza la propia tecnologia para extender el compilador de JDT de manera que sea capaz de sopotar las nuevas construcciones. AJDT utilizan un proceso de weaving a través de una implementación basada en OSGI ofrecida por el proyecto Equinox. Scala IDE en Eclipse utiliza un enfoque similar para la construcción de su entorno de desarrollo.
En el desarrollo de nuestros productos software nosotros también hacemos uso de AOP para arquitectar nuestras soluciones (además de las enumeradas anteriormente), así por ejemplo, utilizamos AspectJ para la gestión del estado "dirty" de un metamodelo, o para la generación de las licencias de uso de nuestros productos.

jueves, octubre 01, 2009

Great ebook

An amazing reading about software developement.


Ebook link

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


I think it's a recommended reading!

miércoles, septiembre 30, 2009

Hype Cicle

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


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


La interpretación de la curva Hype Cicle implica cinco fases diferentes las cuales analizaremos a continuación.
  • Activación de la tecnología: Este es el momento en el que la tecnología aparece con la intención/promesa de solucinar un conjunto determinado de problemas. Podría ser el anuncio de un nuevo producto o la liberación de una nueva versión de un produco ya existente.
  • Expectativas irreales ("peak"):Durante esta fase la tecnlogía se hace muy popular. Todo el mundo quiere conocerla y tiene una opinión sobre ella aunque muy poca gente la utiliza en aplicaciones reales.
  • Desilusión: Esta es la fase de ciclo Hype en la que la tecnología comienza a perder toda la atención que se le había prestado hasta el momento.
    Mientras que los equipos que la adoptaron desde sus inicios continuan utilizándola con el objetivo de obtener una ventaja competitiva, muchos otros comienzan a observar con cierto escepticismo. Nuevas tecnologías aparecen en escena aportando soluciones diferentes al mismo problema. Resulta interesante destacar que muchos de estos nuevos competidores están en la fase de "expectativas irreales".
  • Viendo la luz:Numerosos factores intervienen en el desarrollo de esta fase: maduración de la tecnología, cambios en la misma para acercarse a la realidad, búsqueda de un contexto de uso en el que realmente se cause impacto o la "desilusión" con otras alternativas, que en su momento fueron competidores, son algunas de ellas.
  • Plena productividad:La última fase definida en el ciclo Hype. En esta situación la tecnología está ampliamente difundida y se utiliza en las solución de problemas para los que ofrece una gran respuesta. Será en esta fase cuando se produzca una aceptación mavisa de la tecnología.
Si a alguien le interesa, Harvard Business Press publicó el libro Mastering the Hype Cycle: How to Adopt the Right Innovation at the Right Time.

Hasta pronto

Migue

sábado, septiembre 12, 2009

El puto amo

Hay cosas que no cambian nunca:







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

Un abrazo!

sábado, agosto 22, 2009

C++ Singleton Pattern (y II)

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

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

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

static singletonPattern & getInstance();


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

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

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

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

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

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

C++ Singleton Pattern (I)

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

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

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

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

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

public:
/*!
Returns the reference
to the unique instance of the object

(if it's the first time create de reference)
*/
static singletonPattern * getInstance(){
if(instance == NULL)
instance = new singletonPattern();
return instance;
}
};

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

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

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

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

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

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

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

Hasta pronto!

viernes, agosto 07, 2009

Vigo & Madrid


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






Bye!

Frameworks

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


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!

sábado, julio 11, 2009

Groovy Metaclass

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

We can define a new class

class SampleClass {
// class field
def propertyOne
// one sample Closure
def closureOne = {
println "I´m the closure one"
}
}

Now we add a new method at runtime

SampleClass.metaClass.runtimeAddedMethod = {
println "I´m runtimeAddedMethod"
}

Declare a new instance an test all the methods

def instance = new SampleClass()

Call to the closure declared in class definition

instance.closureOne()

Call to the method added at runtime

instance.runtimeAddedMethod()

We add a method to the "instance" too

instance.metaClass.instanceRuntimeAddedMethod = {
println "I´m the method added at runtime to a single instance"
}

instance.instanceRuntimeAddedMethod()

Bye!!

viernes, julio 03, 2009

Amsterdam Photos

Some photos of our last trip to Amsterdam:




Chihi: Art essence (trying to become famous jajajaja)

i amsterdam

all the travelers (I was tooking the photo)

Ita

Dam Place


Dam Place

Ita again


Bye!