Año viejo. Año nuevo

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

1. Pasar mucho más tiempo con la gordita (esta es la más importante)
2. Viajar a Japón
3. Regresar a Alemania (para ésto ya tenemos billetes :) )
4. Intentar quedar lo máximo posible con los amigos que ahora no están tan cerca (esto también es muy importante)
5. Comenzar las clases del Máster (esto no depende de mi directamente, sino de la Politécnica de Madrid)
6. Continuar con la construcción de R-Eclipse: soporte para intérpretes remotos y construcción de un depurador.
7. 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.
8. 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)
9. Leer todos los libros que tengo pendientes. No los enumero porque se me haría un post eterno :)
10. 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)

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

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

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

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

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

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

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

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

Muchas gracias a todos!!

Hasta pronto

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

Análisis de Redes Sociales

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

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

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

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

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

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

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



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

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

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

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

Hasta pronto!

JDT Weaving Service (y II)

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

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

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

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


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

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

Hasta pronto!

JDT Weaving Service

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

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

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

• Eclipse 3.5 o superior.
  

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

• Servicio JDT de weaving debe estar activado.
  

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

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

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

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

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

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

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

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

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

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

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

Hasta pronto!

Definición de DSL

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

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

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

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

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

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

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

En próximos post intentaremos profundizar en el tema.

Hasta pronto!

New Languages. Building IDE's

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

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

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

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

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

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

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

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

Hasta pronto!

Modelo de Joint Point (y II)

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

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

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

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

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

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

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

Modelo de Joint Point (I)

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

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

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

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

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

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

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

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

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

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

Hasta pronto,

Migue

AOP en el mundo real

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

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

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

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

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

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

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

Great ebook

An amazing reading about software developement.


Ebook link

Interviewers with 15 of the most interesting programmers:

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

I think it's a recommended reading!

Hype Cicle

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


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

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

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

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

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

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

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

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

Hasta pronto

Migue

El puto amo

Hay cosas que no cambian nunca:

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

Un abrazo!

C++ Singleton Pattern (y II)

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

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

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

static singletonPattern & getInstance();

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

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

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

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

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

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

C++ Singleton Pattern (I)

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

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

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

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

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

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

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

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

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

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

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

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

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

Hasta pronto!

Vigo & Madrid

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

Bye!

Frameworks

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

Practical API Design. Confessions of a Java.Framework Architect

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

Bye!

Groovy Metaclass

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

We can define a new class

class SampleClass {

// class field

def propertyOne

// one sample Closure

def closureOne = {

println "I´m the closure one"

}

}

Now we add a new method at runtime

SampleClass.metaClass.runtimeAddedMethod = {

println "I´m runtimeAddedMethod"

}

Declare a new instance an test all the methods

def instance = new SampleClass()

Call to the closure declared in class definition

instance.closureOne()

Call to the method added at runtime

instance.runtimeAddedMethod()

We add a method to the "instance" too

instance.metaClass.instanceRuntimeAddedMethod = {

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

}

instance.instanceRuntimeAddedMethod()

Bye!!

Amsterdam Photos

Some photos of our last trip to Amsterdam:

Chihi: Art essence (trying to become famous jajajaja)

i amsterdam

all the travelers (I was tooking the photo)

Ita

Dam Place

Dam Place

Ita again

Bye!

Amsterdam Trip

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

Bye!

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

AOP Benefits

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

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

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

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

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

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

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

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

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

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

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

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

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

Hasta pronto!

Some New York Photos (I)

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

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

Some of my favourite last reads:

• Clean Code, A handbook of Agile Software Craftsmanship
• Programming Erlang: Software for a Concurrent World (i am reading it now)
• Refactoring in Large Software Projects: Performing Complex Restructurings Succesfully

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!

Maven next generation

Presentación sobre Maven 3 de Jason van Zyel en el Maven Meetup del 19 de Marzo de este año.

Son 28 transparencias acerca del futuro de Maven, la verdad que no tienen desperdicio

Aquí os dejo también el video de la presentación:

Jason van Zyl on Maven 3 from Sonatype on Vimeo.

Plataformas, herramientas y métodos

Uno de los principales problemas de la industria del software, en comparación con otro tipo de industrias, es que las herramientas y las metodologías no han seguido la misma evolución que las plataformas tecnológicas que sirven de base para la construcción del software. Podemos conectar sistemas heterogéneos separados cientos de miles de kilómetros a través de las últimas tecnologías de servicios web, ubicar nuestros procesos en la "nube", ofrecer nuestro software como un servicio a través de internet (SaaS), . . . Sin embargo, en la mayoría de las ocasiones, siempre es necesaria la intervención "manual" en las nuevas construcciones, como si cada una ellas fuese la primera que se realiza bajo esa tecnología.

Imaginemos por un momento que la industria del hardware utilizase un enfoque similar al anteriormente descrito. En ese caso, la construcción de circuitos integrados se realizaría mediante el soldado de transistores en lugar del método actual (utilización de software específico encargado de generar las implementaciones). ¿Podría la industria del software aplicar un enfoque similar?

Otras industrias han resuelto problemas similares a los que nos ocupan descubriendo cómo, de manera ágil, se pueden personalizar y ensamblar componentes estándar de modo que se puedan construir productos iguales pero distintos, mediante la integración, estandarización y automatización de sus líneas de producción, mediante el desarrollo de herramientas altamente extensibles, configurándolas de modo que puedan realizar tareas repetitivas y minimizando el riesgo y los costes en las relaciones con los clientes y proveedores. Partiendo de este punto se han construido líneas de producción para las variantes de los productos, se han generado cadenas de suministros distrubuyendo los costes y los riesgos a lo largo de diferentes suministradores especializados y relacionados entre si, habilitando de este modo la producción de una variada gama de productos capaces de satisfacer las necesidades de un amplio abanico de clientes. En resumen, industrialización.

Mi intención no es sugerir que la construcción de software es un proceso mecánico capaz de ser llevado a cabo por trabajadores no cualificados sino que, al contrario, no se debe malgastar el tiempo de los buenos desarrolladores realizando tareas automáticas y repetitivas, de modo que dichos trabajadores puedan pasar más tiempo pensando y no realizando tareas que podrían estar automatizadas. Deberíamos de ser capaces de encapsular el conocimiento en lenguajes, patrones, dsl, herramientas, frameworks, etc de modo que se puedan aplicarl de manera sistemática, automatizando de este modo el ciclo de vida del software.

La construcción de componentes software reutilizables es un reto apasionante, y posiblemente no sea tan sencillo ensamblarlos como los circuitos integrados, aunque, personalmente, creo que la industria del software debería moverse en esa dirección.

De nuevo Natch

Para mi gusto, una de las mejores canciones de rap en español: