Aplicaciones: Exploradores Flex

Cualquier persona que haya trabajado con Flex se da cuenta enseguida de lo arduo que es tener que compilar y ejecutar la aplicación cada vez que se realiza un pequeño cambio de estilo un componente, etc. Estas pequeñas acciones suponen un pérdida de productividad a lo largo de la jornada de trabajo y por tanto son situaciones que deberíamos evitar a toda costa.

Para mejorar esta situación podemos usar algunas peuqeñas herramientas desarrolladas por y para la comunidad que nos permiten indagar en los componentes, cambiar sus estilos. Por esto mi intención es crear un directorio de herramientas de este estilo que sirva de referencia para encontrarlas. Por ahora tengo conocimiento de tres herramientas:

• Adobe Flex 3 Component explorer: Desarrollado por Adobe. Es un catálogo de componentes básicos de Flex 3 que permite navegar por los componentes viendo ejemplos tanto visuales como de código. Es muy útil para hacernos a la idea de que componente usar o mostrarlos para que sean elegidos.
  
• Adobe Flex 3 Style Explorer: Desarrollado por Adobe. Similar al anterior, pero en este caso nos brinda la posibilidad de aplicar estilos CSS a los componentes y comprobar el resultado en tiempo de ejecución, además va generando el CSS y permite exportarlo, con lo cuál podemos reutilizarlo en nuestra aplicación directamente. Es muy útil a la hora de crear estilos para nuestras aplicaciones.
• Flex 3 Regular Expression Explorer: Desarrollado por Ryan Swanson. Es un navegador que nos permite crear y probar expresiones regulares. Asimismo, permite almacenar las expresiones para compartilas con el resto de la comunidad.

Probablemente ya conozcáis alguna o todas estas herramientas ya que algunas son muy conocidas. Si conocéis alguna otra herramienta de este estilo podéis comunicarlo e iremos confeccionando un listado.

Espero que os sea de utilidad, Saludos.

Site para el proyecto con Maven

Una buena práctica a la hora de publicar nuestros proyectos es, sin duda, crear un site para el proyecto en el que podamos añadir toda la información sobre el proyecto, desarrolladores, código fuente (en caso de desear compartirlo), informes sobre test, "issue tracking" y un sin fin de cosas. Es lógico que crear un site con toda está información desde cero es muy costoso, por tanto voy a proponer un sistema automático.

Para llevar a cabo esta automatización podemos usar el plugin de maven "Maven Site Plugin", el cuál generará el site automáticamente con toda la información que definamos en su configuración. Lo primero que debemos hacer es añadir el plugin en nuestro fichero pom.xml:

<project>
...
<build>
<!--Para usar las metas del plugin-->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
...
</plugins>
</build>
...
</project>

Si queremos definir el plugin en el pom padre para que sea usado por todos los proyectos hijos podemos usar esto:

<project>
...
<build>
<!-- Para definir el plugin en el POM Padre-->
<pluginManagement>
<plugins>
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-site-plugin</artifactId>
  <version>2.0.1</version>
</plugin>
...
</plugins>
</pluginManagement>
...
</build>
...
</project>

Una vez que tenemos esto podemos ejecutar el comando mvn site para crear nuestro site, por defecto lo creara en la carpeta {basedir/target/site}. Obviamente el site generado tendrá la configuración por defecto y creará el contenido por defecto, estando la mayoría de la información sin rellenar. Algunos apartados puedes tener datos, como las dependencias o la información del proyecto y los desarrolladores, que serán extraídas del pom.


Configurar el site.
Para configurar el site a nuestro gusto e ir añadiendo la información que deseemos. En la carpeta src debemos crear la siguiente estructura:

+- src/
+- site/
+- apt/
|  +- index.apt     (versión por defecto)
|
+- site.xml         (descriptor de la versión por defecto)

Para cambiar el ábol de navegación debemos configurar nuestro descriptor del site (site.xml), podemos ver como se crea un descriptor del fichero en la página oficial del plugin.


Configurar los informes
Podemos añadir los informes que generamos con otros plugins de maven. Hay muchos informes estándar disponibles que obtienen información del POM. Actualmente los que se proveen por defecto son los siguientes:

• Informe de dependencias
• Listas de correo
  
• Integración Continua
  
• Repositorio de código fuente
  
• Seguimiento de errores (Issue Tracking)
• Equipo del proyecto
  
• Licencia.

Para añadirlos tan sólo debemos configuralos en la sección del POM y añadir las entradas correspondientes en el fichero site.xml, si esté ha sido modificado, ya que en el fichero por defecto se incluyen dichas secciones.

<project>
...
<reporting>
<plugins>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-project-info-reports-plugin</artifactId>
    <version>2.0.1</version>
  </plugin>
</plugins>
</reporting>
...
</project>

Internacionalización.
La internacionalización de nuestro site es muy sencilla, tan sólo debemos configurar el plugin para que admita varios locales, añadiendo en la configuración del plugin:

<project>
...
<build>
<plugins>
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-site-plugin</artifactId>
  <version>2.0.1</version>
  <configuration>
          <locales>en,es</locales>
        </configuration>
</plugin>
</plugins>
</build>
...
</project>

Y luego crear una carpeta para el contenido para cada idioma, el contenido del idioma por defecto irá en la carpeta raíz y crearemos una carpeta para cada idioma extra. Asimismo crearemos un descriptor del site en cada idioma, sería algo así:

+- src/
+- site/
+- apt/
|  +- index.apt     (versión por defecto)
|
+- es/
|  +- apt/
|     +- index.apt  (versión en español)
|
+- site.xml         (descriptor de la versión por defecto)
+- site_es.xml      (descriptor de la versión española)

Ejecución y despliegue del Site.
Una vez que tenemos nuestro site, podemos ejecutarlo usando nuestra máquina como servidor con el comando mvn site:run y podemos acceder a él en el puerto 8080 del localhost (http://localhost:8080/). Si disponemos de un dominio y almacenamiento para nuestro site podemos publicarlo automáticamente, para ello debemos añadir en nuestro POM la la información de la URL a la que subiremos el site, en la configuración del distributionManagement:

<project>
...
<distributionManagement>
<site>
<id>www.yourcompany.com</id>
<url>scp://www.yourcompany.com/www/docs/project/</url>
</site>
</distributionManagement>
...
</project>

y luego ejecutar el deploy, para ello tenemos dos opciones:

• mvn site:deploy : Este comando sólo despliega el site, por tanto el sitio debe haberse generado antes.
  
• mvn site-deploy : Si queremos ejecutar todo el proceso desde generarlo hasta su publicación debemos ejecutar la fase site-deploy del ciclo de vida.
  

Os dejo un proyecto de prueba vacío en el que se aplica todo esto, para generar un site.

Como vemos, con esta herramienta podemos ahorrar mucho tiempo y generar un site con toda la información del proyecto, en otra ocasión continuaremos con más buenas prácticas.

Saludos.

Preview de Bonita Studio 5.0

BonitaSoft ha puesto en circulación la preview de BonitaStudio 5.0, la nueva versión de su herramienta BPM (Bussines Process Management), por ahora solo está disponible como preview privada, y solo pueden acceder a ellas los usuarios registrados en el nuevo site de BonitaSoft antes del 10 de Octubre de 2009.

Por la información expuesta en el site podemos decir que han rediseñado la interfaz y la funcionalidad, cosa que se agradece bastante ya que la versión 4.0 me desencanto un poco.

Particularmente he trabajado con la versión 3 y 4 de Bonita y entre ellas hubo una gran diferencia. La versión 4 de Bonita es relativamente nueva y quiso cambiar completamente el esquema de la antigua Bonita, y esta nueva versión 5.0 viene a cubrir todos los huecos que la versión 4 dejo descubiertos, como la Interfaz gráfica y la API que era bastante limitada si se compara con la de la versión 3.

Yo ya le he descargado pero desafortunadamente no he tenido tiempo de probarla, en cuanto la pruebe comentaré mis primeras impresiones. Realmente espero que con está nueva versión se solvente algunos de esos pequeños problemas ya que estamos ante una de las mejores soluciones BPM del momento.

Acceder a servicio SOAP tras un proxy con CXF

Si queremos acceder, con CXF, a un servicio SOAP a través de un Proxy puede suceder que falle la llamada, ya que el resultado que nos devuelve es "troceado", y por tanto al recibir el mensaje de retorno, este no cumple con el formato SOAP.

Nos mostrará un error al acceder a la URL en la que se encuentra el servicio, indicándonos el mensaje "Método de la petición y protocolo no soportados". En el caso de que el proxy sea Squid nos mostrará también el siguiente mensaje "Squid no admite todos los métodos para todos los protocolos de acceso. Por ejemplo, no se puede hacer un POST a un servidor Gopher".

El stackTrace provocado por el error es algo similar a similar a este:


Para solucionar este problemas debemos configurar el CXF para desactivar el "chunking" (troceado), para ello crearemos/modificaremos el fichero de configuración de CXF (por defecto cxf.xml), consistente en un conjunto de beans de Spring, en el que añadiremos o descomentaremos, si ya existe el fichero, lo siguiente:

Podemos ver como configurar el CXF en la sección de configuración de la página oficial de Apache.

Ocultar pestañas en TabNavigator

Hoy veremos como se pueden ocultar las pestañas en un TabNavigator de Flex 3. Es un problema que parece trivial (en otros entornos realmente lo es), pero en Flex dado el manejo interno que hace Flex del TabNavigator no es tan directo, o por lo menos la forma de añadir pestañas en un mxml puede llevar a un uso incorrecto.

Cuando tenemos un TabNavigator, para añadir una pestaña tan sólo debemos añadir como hijo un contenedor, es decir cualquier clase que herede de la clase mx.Container (Box, Container, viewStack, etc...). Veamos un ejemplo:
Una vez que tenemos el TabNavigator creado, podemos decidir ocultar ciertas pestañas en determinadas circunstancias, o bien usando estados (mx:States) o con código actionScript. Para tratar de ocultar una pestaña la tendencia natural es usar el atributo visible y el includeInLayout (para no dejar huecos entre las pestañas) sobre los hijos que hemos añadido en el TabNavigator, con lo que obtendremos un resultado erróneo, ya que se mostrará el TabNavigator con la pestaña vacía en su interior.

A grosso modo, cuando nosotros añadimos un hijo en el TabNavigator internamente crea una pestaña (tab), en la que incluye el botón con el que se representa la pestaña y añade el contenido que nosotros hemos especificado. Por tanto, si queremos hacer que la pestaña desaparezca completamente debemos acceder al tab y establecer las dos propiedades mencionadas antes: visible e includeInLayout a valor false. Para acceder al tab debemos hacer uso de la función getTabAt del TabNavigator, con la que obtendremos la pestaña (un objeto de tipo mx.Button). Usando el ejemplo anterior, el código para ocultar la "pestaña 2, " resultante sería algo así:

 ...
var pestana:Button = tabNavigator.getTabAt(1);
 pestana.visible = false;
 pestana.includeInLayout= false;
 ...

Cómo vemos de esta forma simple podemos jugar con las pestañas para ocultarlas y visualizarlas, y no sólo eso, sino que podemos acceder a las pestañas (tabs), para cambiar cualquiera de sus propiedades.

Aplicaciones modulares en Flex

Hola, despues de un pequeño descanso ya hemos vuelto. Hoy quería hablar de un tema que tenía en el tintero desde hace un tiempo. las aplicaciones modulares en Flex.

La primera cuestión que nos viene a la cabeza es ¿Por qué una aplicación modular?, por que hemos de complicar el desarrollo para desarrollar modulos y tener que añadir cierta lógica extra para manejarlos. En efecto, el desarroollo modular supone cierto coste en tiempo de desarrollo y de ejecución de la aplicación, por tanto no todas las aplicaciones son susceptibles de desarrollarse de forma modular. En mi opinión es una cuestión de tamaño y/o complejidad, para desarrollar una pequeña aplicación muy simple quizás no sea recomendable, dado la carga extra que supone. La modularidad empieza a mostrar sus ventajas conforme el proyecto crece y se complica, pudiendo observar grandes beneficios:

• Reducción del tiempo de compilación --> Dado que trabajamos con módulos, sólo recompilaremos los módulos en los que hay acambios.
• Reducción del tamaño de los archivos compilados (SWF y SWC).
• Reutilización --> Podemos reutilizar dicho módulo en otras aplicaciones.
• Simplifica la adición de nuevas funcionalidades mediante la adición de nuevos módulos.
• Carga/descarga de módulos dinámicamente--> Liberación de recursos.
• Desarrollo entre distintos grupos de trabajo.

La realización de programas modulares en Flex podríamos englobarla básicamente en 4 categorías:

• Uso de Módulos.
• Uso de Librerías.
• Uso de RSL (Runtime Shared Libraries).
• Uso de librerías, RSL y módulos de forma conjunta.

Modulos
Los módulos son archivos SWF que pueden ser cargados dinamicamente y que no pueden ejecutarse independientemente, sino que deben ejecutarse dentro de una o varias aplicaciones. Un módulo puede interactuar con la aplicación padre o con otros módulos.

Podemos definir un módulo usando la clase Module.

Librerías
Como en cualquier otro lenguaje, una librería es un conjunto de funcionalidades y/o recursos que se encapsulan, en este caso se encapsulan en un fichero SWC.

RSL (Resource Shared Library)
Como su nombre indica es la una librería de recursos compartidos. La importancia de este tipo de librerías es que dicha librería se carga una sola vez en el arranque de la aplicación (se puede ver la barra de carga al principio), de forma que desde ese momento podemos utilizar todos los recursos de la librería sin necesidad de cargar la librería. Como es lógico este proceso puede ralentizar el proceso de startup de la aplicación, así hay que decidir con cuidado que librerías se cargarán como RSL (basándonos en la utilización de la librería).
Otro punto importante del uso de RSL, es que usando lo adecuadamente podemos reducir el tamaño de nuestros módulos/aplicaciones, ya que la librería se compilara en un fichero aparte que será reutilizado, y no se incluirá el código especifico que se usa de la librería en cada archivo compilado SWF.

Desde mi experiencia, recomiendo encarecidamente el uso de aplicaciones modulares para aplicaciones de cierta envergadura, ya de esta manera se puede disfrutar de un conjunto de ventajas muy interesantes a un coste relativamente pequeños, ya que sólo requiere el coste inicial de la gestión de módulos y una vez que se tenga implementada dicha gestión se pueden añadir funcionalidades facilmente.

Flex Builder BluePrint

Hace unas semanas un compañero me comento acerca de este plugin y lo he estado probando. BluePrint es un plugin para el Flex Builder que te permite consultar diversas fuentes en busca de documentación, ejemplos, etc... sin salir del entorno de desarrollo.

Su uso es bastante simple, simplemente seleccionamos el elemento del cuál queremos obtener información (en nuestro código), por ejemplo una clase o atributo, y picamos el botón ,que aparece al instalar el plugin. El plugin realizará la búsqueda y nos devolverá un listado de posibles resultado, seleccionado alguno de ellos lo veremos en el navegador interno del eclipse.

El plugin y su información relacionada podemos obtenerlo en adobe labs. También encontraremos los pasos para su instalación, la cuál es muy sencilla ya que se realiza con el update Manager del Eclipse.

Maven Surefire Plugin

Si queremos ejecutar test unitarios de nuestras aplicaciones gestionadas con Maven, podemos usar el plugin Surefire. Este plugin se usa durante la fase de test y genera informes en dos formatos: archivo de texto plano(*.txt) y archivos XML (*.xml). Por defecto dichos informes se generan en la carpeta ${basedir}/target/surefire-reports.

El plugin solo posee una meta (goal) , surefire:test, que se encarga de ejecutar los test, podemos ver todos los atributos de configuración de la meta aquí.

Para poder usar el plugin debemos configurar nuestro fichero POM para que incluya el plugin:

Por defecto, el plugin Surefire incluirá todas las clases de test que cumplan los patrones:

• "**/Test*.java" - Incluye todas las clases de su subdirectorio cuyo nombre comience por "Test".
• "**/*Test.java" - Incluye todas las clases de su subdirectorio cuyo nombre termine por "Test".
• "**/*TestCase.java" - Incluye todas las clases de su subdirectorio cuyo nombre termine por "TestCase".

Podemos definir otros patrones para las clases de test que se usarán, tan solo debemos añadirlo en la configuración usando los tags <>< /includes>. También podemos excluir los ficheros que cumplan cierto patrón usando los tags <>< /exludes>. Por ejemplo:

Asimismo podemos definir si queremos pasar de la ejecución de los test añadiendo en la configuración el tag <>true< /skiptests>, o bien si usamos un comando añadiéndole -DskipTest.

mvn install -DskipTest

Si lo que queremos es que ni siquiera se compilen los test usaremos -Dmaven.test.skip=true.

mvn install -Dmaven.test.skip

Al comenzar comentabamos que los informes que genera el plugin se generan en texto plano o XMl, pero podemos tener los informes en formato HTML,para ello debemos usar Maven Surefire ReportPlugin.

Nota: El uso del reporting lo veremos en el futuro en otro artículo.

Simulador de examen para certificación Flex

Hoy como extra añado esta noticia.

Buceando por ahi he encontrado un simulador de examen para la certificación Flex llamado Attest, es gratuito y esta deasrrollado con Flex (es una aplicación AIR).

Se puede descargar aquí.

Que lo disfruten.

Frameworks Flex

En el mundo Flex podemos encontrar numerosos Framerworks que nos ayudaran al desarrollo de nuetra aplicación y harán que sigamos unas pautas bien definidadas, para un deasrrollo con calidad. Existen numerosos Frameworks, pero algunos de lo más conocidos son :

• Cairngorm (oficial de Adobe).
• PureMVC.
• Guasax (este es español).
• Slide
• ARP
• ServerBox
• MVCS
  
• etc...
  

La gente de assertTrue realizó hace un tiempo una comprativa sobre los diferentes frameworks que existían a esa feccha. Dicha comparativa podemos verla aquí y es muy recomendable su lectura y visualización (esta en video) antes de decidirse por usar alguno.

Estos frameworks han seguido evolucionando e incorporando nuevas funcionalidades. Asimismo, he de decir que actualmente existen más frameworks para Flex, algunos de los que tengo conocimiento de su existencia (no los he probado aún), son:

• Swiz -> Proeve inversión de control (IoC) , manejo de eventos y no imponen ningún patrón J2EE.
  
• Mate -> Framework orientado a mandejo de eventos y que posee inyección de dependencias para poder obtener los objetos de datos que necesitemos.

Por mi parte, hoy quiero dejarles una presentación que sirve de introducción al PureMVC, el cuál es según mi experiencia el mejor framework para desarrollo con clientes Flex de cierta envergadura. Para el desarrollo de un aplicación pequeña podría usar tambíen el Cairngorm, pero seguramente me decantaría por usar aqui tambien el PureMVC.

Nota: La presentación ya tienen un tiempo y el framework ha evolucionado mucho, con lo cuál puede servir de introducción pero quizás no se ajuste completamente al modelo actual. Por jemplo, actualmente existen dos versiones una normal y otra multiCore que mantiene varias fachadas.

Espero que todo esta información les sirva a la hora de eligir que framework utilizar.

Integración de BlazeDS con Spring

Siguiendo el hilo de noticias sobre el "Spring BLazeDS Integration" decir que Spring ha anunciado su primera release, podemos ver el anuncio aqui.

En el blog del equipo de Spring podemos ver una introdución al uso de la libería, muy detallada y bien explicada (ver aquí).

Parece que el proyecto sigue mejorando, cosa que se agaradece al equipo de Spring.

Obtener la SQL generada por una Criteria de Hibernate en runtime

Recientemente he necesitado obtener la consulta SQL que genera una Criteria de Hibernate en tiempo de ejecución. La primera opción, obviamente, es leer la documentación de Hibernate Criteria, pero Hibernate no posee ninguna funcionalidad para obtener la SQL en su clase Criteria, ni en las clases relacionadas. Esto me resulto extraño, dado que con Hibernate Criteria se pueden volcar las consultas al log usando por ejemplo log4j, para ello hay que:

• Asignar el valor "true" a la propiedad "hibernate.show_sql" en el sessionFactory.
• Añadir en el fichero de configuración del log4j dos appenders:
  
1. org.hibernate.SQL = DEBUG --> Para ver las consultas.
   
2. org.hibernate.type = TRACE --> Para ver los valores de los parámetros.

Dado que la información está almacenada dentro de la Criteria, tan solo es necesario "sacarla", y para ello usaremos la introspección de Java. El código para obtener la consulta SQL con sus parámetros es el siguiente:

Como vemos en el código usamos la introspección para inspeccionar el contenido de algunos atributos privados del Loader y así obtener la información que queremos.

Tengo que decir que esta forma de utilizar las criterias e Hibernate no es muy ortodoxa, y que en caso de usarse debe hacerse de forma muy controlada, no debe ser una práctica habitual, ya que nada nos asegura el correcto funcionamiento de este tipo de artificios. Eso si por una necesidad imperiosa necesitamos obtener la consulta SQL que genera en tiempo de ejecución es un alternativa.

Introducción a Flex Profiler

Hoy quiero hablarles del "Flex Profiler", una herramienta incluida en el Flex Builder que nos permite realizar sesiones de profiling (para optimizar el rendimiento y el uso de recursos).

Para utilizarlo tan sólo debemos crearnos un perfil de "profile", esto se realiza de la misma forma que un perfil para ejecutar o para depurar la aplicación. Tan solo debemos picar en el botón teniendo seleccionado el proyecto o bien picando en el mismo botón en la opcion otros. Al hacer esto nos mostrara la pantalla de configuracion del perfil.


Como vemos en la pantalla podemos seleccionar el proyecto, el fichero principal del proyecto (el que contiene el tag Application) y las URLs que se usarán para lanzar la aplicación. Ahora ya podemos lanzar la sesión de profiling desde el boton profile. Al lanzarlo se nos abrirá la perspectiva "Flex Profiling" mostrandonos la pantalla de conexión.

Desde dicha pantalla podemos seleccionar si queremos ejecutar el profiling de memoria, de rendimiento o de ambos. Asimismo, para el profiling de memoria podemos indicar:

• Si queremos ver los objetos vivos en memoria ("watch live memory data"), que nos muestra el panel "Live Objects" con información de que clases se han instanciado, cuantas instancias existen, la memoria que consume etc.
  
• Si queremos generar la traza de asignación de los objetos ("Generate object allocation stacktraces"), que capturará la traza cada vez que se genere un objeto. Tenemos que tener mucho cuidado con esta opcion ya que puede ralentizar el profiler y usar mucha mas memoria.
  

Es mejor fijarnos ciertos objetivos en cada sesion y no tratar de mejorar el rendimiento y el uso de memoria en la misma sesión.

Garbage Collector
Antes de meternos en harina con el profiling de la memoria, tenemos que entender como funciona el garbage collector de la máquina Flash Player. El garbage collector se basa fundamentalmente en dos técnicas el "Reference Counting" y el "Mark and Sweep".

El "reference counting" basicamente consiste en que cada objeto mantiene un contador de referencias, cada vez que un objeto hace referencia a otro se incrementa el contador de referencia del objeto apuntado. Cuando el contador de referencias es cero el objeto puede ser eliminado. El reference counting presenta un problema serio, y es que si se forma una referencia circular (por ejemplo: A apunta a B y B apunta a A) el objeto nunca será liberado. En el caso concreto de Flex, debemos tener mucho cuidado con esto ya que es muy probable que creamos que un objeto no esta siendo referenciado por nadie y aun así tenga referencias, en este caso debemos echarle un ojo a los listener que pueda tener asociados el objeto, una buena precaución es definir siempre los listeners como weak references, que crean la referencia pero no incrementan el contador de referencias.

El "Mark and Sweep" es una técnica de recolección en la que cuando el garbage collector realiza una pasada (recorriendo el arbol de referencias de los objetos) , comprueba si el objeto puede ser liberado (contador de referencias a cero) si es así lo marca y a su vez, en la misma pasada, si el objeto esta marcado lo elimina.

Otra cosa a tener en cuenta es la frecuencia con la que se ejecuta el garbage collector, cosa que es impredecible, ya que en mi opinión se ejecuta cuando le parece. En teoría, hay un sofisticado algoritmo, que comprueba cuando debe ejecutarse el garbage collector, que se ejecuta cuando se asigna memoria, pero no he encontrado a nadie que lo haya sabido explicar XD.

Profiling de Memoria
Empezaremos con una sesión para mejorar el uso de la memoria. Es muy importante realizar estas sesiones ya que en ellas podremos detectar posibles "memory leaks" (fugas de memoria, es decir memoria que se asigna pero que nunca se recupera). Por lo general para esta sesión, suelo activar la opcion "watch live memory data". Veremos esta pantalla:

Arriba a la izquierda se muestra la pestaña con los datos del profile y los datos guardados. Tenemos varios botones que nos permiten forzar la ejecución del garbage collector, tomar una instantanea de la memoria, etc. (ya iremos hablando de los botones según los usemos).

Arriba a la derecha se muestra una gráfica con el consumo de memoria, donde se ve el consumo de memoria actual y los picos de memoria.

Abajo tenemos la pantalla de "Live Objeccts", con información de que clases se han instanciado, cuantas instancias existen, la memoria que consume. Tenemos que tener que también muestra datos acumulativos ("cumulative instances" y "cumulative memory") y que eston son la suma total de todo durante la ejecución de la aplicación.

Para realizar el profiling debemos tomar una o varias "memory snapshots" en momentos determinados en los que la aplicación haya ejecutado cierta funcionalidad que queremos comprobar. Comparando dichas instantaneas de la memoria podemos identificar instancias de objetos que no se hayan eliminado cuando deberían haberse eliminado. Las snapshots cuando se toman van apareciendo en la pestaña "Profile" (arriba a la izquierda). con un doble click en la snapshot nos muestra la pestaña "Memory Snapshot" , en la que veremos la informacion de los objetos y sus referencias, con doble click ira a la pestaña "Object References", donde vemos las referencias del objeto. De esta forma podemos ir navegando por los objetos para identificar con quien se relaciona y ver porque no ha sido eliminado por el garbage collector.

Profiling de rendimiento
En segundo lugar podemos ejecutar una sesión de profiling para comprobar el rendimiento. en este caso Flex Profiler nos mostrará una pantalla en la que podemos ver el número de funciones y/o procedimientos que se han ejecutado, el número de llamadas, el tiempo que ha tardado y su media.

Con esta información podemos detectar secciones del código que puedan suponer un cuello de botella y que estén ralentizando la aplicación. Por tanto podremos optimizar dichas secciones para mejorar su rendimiento, en este caso la mejora la mediremos por el tiempo que tarde el método. Sobra decir, que es importante fijarse tanto en los procesos que tardan mucho en ejecutarse como en aquellos proceso que se ejecutan muchas veces.

Bueno, creo que ya es bastante información para asimilarla de una sola vez así, que lo voy dejando por hoy para que vayais digiriendolo.

P.D: podemos encontrar mucha información sobre esto en el sitio web de adobe (aqui).
Saludos.

Noticias de Spring

Hoy tenemos una ración de noticias sobre Spring:

En primer lugar, tenemos el anuncio de la primera Release Candidate de "Spring BlazeDS Integration", podemos verlo aquí. Parece que el proyecto va por buen camino, ya hace poco hablabamos de la milestone 2. En esta "release candidate", a parte de corregir ciertos bugs, se han añadido ciertas funcionalidades muy interesantes:

• Configuración basada en anotaciones para los destinos remotos.
• Añade numerosas opciones para personalizar los hooks para cosas tales como la traducción de excepciones o añadir adaptadores de terceras partes. Todo aquel que haya tenido que lidiar con el BlazeDS sabrá apreciar esto, ya que la serialización/deserialización de algunos objetos Java a Actionscript y viceversa puede dar problemas. Asimismo, el tratamiento de excepciones requería de cierta lógica adicional para crear un MesasgeException que encapsulara la excepción Java. Aún no lo he probado, pero parece que simplificar bastante este proceso.
• Integración completa con el servicio de mensajes de BlazeDS, incluyendo soporte para AMF, JMS y la interacción con transportes de mensaje de Spring. El servicio de mensajería permite la comunicación entre clientes, sin tener que codificar nada en el servidor, dicho servicio de mensajería se basa en el modelo publisher-subscriber, en el que el "message service" actúa como enrutador para ambos clientes Flex y JMS.
  

La segunda noticia de hoy es la liberación de "SpringSource Tool Suite" (STS), cumpliendo la promesa de Rod Johnson en el "SpringOne Europe". SpringSource Tool Suite es un IDE desarrollado sobre eclipse para desarrollo de aplicaciones con Spring, provee un completo conjunto de herramientas para facilitar el desarrollo de aplicaciones que se ejecuten sobre la mayoría de servidores de aplicaciones (como Apache Tomcat, IBM WebSphere, Oracle WebLogic, JBoss, SpringSource tc Server y SpringSource dm Server).

De entre todas las características y herramientas que ofrece, la que más me ha llamado la atención es la "orientación a tareas" que le han dado al desarrollo. Incluyendo una interfaz de Mylyn, en la que se muestran tareas, recursos abiertos, etc.

Podemos ver más información y descargar la suite aquí. También podemos ver en el blog de Christian Dupuis el listado de características de STS.

Plugin de Jetty para Maven 2

Usando Maven 2 tenemos la opción de usar este plugin que nos permite ejecutar nuestra aplicación web en un servidor Jetty de forma simple, con las "metas" (goals) run y/o run war. Un servidor Jetty es un servidor HTTP y contenedor de Servlets, mucho más ligero que otros servidores (Tomcat, JBoss, etc) lo que hace que sea ideal para pequeñas aplicaciones y entornos de desarrollo.

La meta run compilará el proyecto y lo ejecutará desde la carpeta que contiene los ficheros compilados, mientras que la meta run-war empaquetará el proyecto en un war y lo ejecutará. Por defecto el jetty se ejecutara en el puerto 8080 con el contexto app/.

Configuración
Podemos configurar algunos parámetros opcionales:

• port: Puerto que usará el servidor jetty, valor por defecto 8080 (opcional).
• contextPathSpec: El contexto de la aplicación web, por defecto /app (opcional).
• webApp: Localización del archivo war, por defecto $project.build.directory/$project.build.finalName.war. Podemos definir el finalName en el tag build del pom (opcional).
• jettyConfig: La localización del fichero XML de configuración del Jetty, sobreescribirá el resto de parámetros. (opcional).

Para usar este plugin tan sólo debemos añadir en el pom lo siguiente:

Como vemos en el fichero pom.xml de ejemplo hemos definido que el war que genera tenga el nombre fraguaDigitalExample.war. Asimismo, se ha configurado el servidor jetty para que arranque en el contexto fraguaDigital.

Para Arancar el servidor y así poder probar nuetra aplciación, tan solo debemos ejecutar el comando:

mvn jetty:run
o
mvn jetty:run-war

Si arrancamos el naveagdor y vamos a la URL http://localhost:// (en nuestro ejemplo http://localhost:8080/fraguaDigital/) deberíamos ver la aplicación web.

Optimización de bucles

Para comenzar nuestro periplo con la optimización de aplicaciones vamos a comenzar por algo fácil, muy probablemente ésto le parecerá obvio a muchos desarrolladores pero para todo aquel que empieza no vien mal una ayuda.

La primera medida a tener en cuenta es que debemos sacar del bucle todo aquellos valores invariables, ya que su computo no cambiará en las iteraciones (es lo que se suele llamar "invariantes del bucle").

 int r = 10;
for (int i=0; i<100; i++){
  pi =3.14159;
  float dist = pi*r*r;
}

En el ejemplo puede verse claramente que la variable pi debería situarse fuera del bucle, ya que de dejarlo así la asignación se ejecutará 100 veces en lugar de 1. Además de esto es importante sacar del bucle todo el código que no se usae estrictamente para el calculo que se quiere realizar en el bucle.

Otro aspecto importante que suele pasarse por alto es el calculo del limite en el bucle, muchas veces este limite se calcula mediante una función que ponemos en el mismo bucle, esto implica que dicha función se invoca una vez para cada iteración con su correspondiente coste.

 List lista = new ArrayList()
// inicializacion del list con 100 elementos.
lista.put("1");
...
 lista.put("100");
 for (int i=0; i<lista.size();i++){
   ...
}

Como vemos en el ejemplo la función size se invocará una vez por cada iteración. Una forma más optima para hacer esto es calculando el tamaño del bucle antes, como vemos a continuación:

 List lista = new ArrayList();
// inicializacion del list con 100 elementos.
lista.put("1");
...
 lista.put("100");
 int size = lista.size();
 for (int i=0; i<size;i++){
   ...
}

Por último, otro aspecto a tener en cuenta al utilizar bucles es que usando las palabras reservadas continue y break podemos finalizar una iteración o el bucle completo. El uso de continue es interesante cuando dentro del blucle se comprueban ciertas condiciones que nos indicarán si el dato tratado en la iteración nos interesa o no, en caso de no quere tratarlo podemos ejecutar la instrucción continue para seguir con la siguiente iteración ahorrandonos el coste computacional del resto del cuerpo del bucle. El uso de break es muy útil en situaciones en las que buscamos un elelmento determinado dentro de una colección, en el momento que lo encontremos ejecutaremos un break y abortaremos la ejecucion del resto de iteracioen del bucle.

 List lista = new ArrayList();
// inicializacion del list con 10 elementos.
lista.put("1");
...
 lista.put("10");
 int size = lista.size();
 for (int i=0; i<size;i++){
   String element = lista.get(i);
  if (element.equals("1")){
     continue;
  }
   if (element.equals("5")){
     break;
  }
 }

Como vemos inicialmente el bucle debería ejecutarse 10 veces, pero como estamos buscando el elemento 5 solo se ejecutara cinco veces, además de eso el primer elemento no comprobará la segunda condición ya que nos saltamos la iteración.

Optimización de código

Durante el tiempo que llevo desarrollando software uno de los aspectos que mejor se me ha quedado grabado en la mente. En los inicios todo desarrollador novato se siente contento tan sólo con que su código funcione y "haga lo que debe". Pero con el transcurso del tiempo uno se va dando cuenta que una aplicación informática no sólo debe hacer lo que debe sino que debe hacerlo rápido y con el menor consumo de recursos de la máquina posible.

Personalmente los retos importante de optimización a los que me he enfrentado los he encontrado en dos aplicaciones de naturaleza distinta. La primera de ellas una aplicación de tratamiento de imágenes ecográficas desarrollada en C++. La segunda una aplicación web RIA (Rich Internet Application) desarrollada en Flex y que usa servicios Java. En ambos casos casos le hecho de tener un código ineficiente puede suponer que la aplicación no sea usable. En el primer caso, puedo decir que el tratamiento de imágenes es muy costoso y se basa en convoluciones de matrices, por lo tanto optimizar dichas operaciones puede suponer una disminución del coste y sobre todo del tiempo de espera para obtener los resultados. En el segundo caso el problema es obvio, si hemos decidido desarrollar una aplicación rica es porque queremos que la "experiencia del usuario" (User Experience o UX) sea de calidad. Un código poco optimizado puede arruinar esa "experiencia de usuario". Por tanto, en adelante trataré de describir mis experiencias optimizando código así como el uso de algunas herramientas para dicha labor.

A la hora de optimizar el código tenemos dos grandes bloques principalmente: la optimización de la velocidad y la optimización de los recursos

Optimización de velocidad
Se basan en optimizar el código eliminando código inútil y/o redundante para que las operaciones se realicen los más rápidamente posible.

Las técnicas más básicas y obvias de este tipo son:

• Eliminar código innecesario. Muchas veces se deja código que no hace nada pululando por ahí.
  
• Encapsular la funcionalidad en Funciones/procedimientos adecuadamente.
• No realizar llamadas innecesarias.
  
• Optimización de bucles. Controlar el número de iteraciones, para no iterar innecesariamente y sacar el código que no sea especifico del bucle.
  
• Restringir el uso de operaciones de Strings. Las concatenaciones y extracciones de string son bastante costosas.
  
• Pasar objetos por referencia mejor que por valor, ya que nos ahorramos copiar el objeto.
  
• Minimizar el acceso a disco.

Optimización de recursos
En este caso lo que queremos es que la funcionalidad se desempeño usando el mínimo numero de recursos como la memoria y liberando todos los recursos no usados al finalizar evitando fugas de memoria (memory leaks), que progresivamente ralentizarán la aplicación y pueden llegar a colgarla.
Las técnicas más básicas y obvias de este tipo son:

• Liberar los recursos (memoria) una vez se termina de usar. Dicho así puede parecer fácil, pero dependiendo del lenguaje que usemos la cosa puede complicarse, más adelante explicare las complicaciones que pueden darse en un entorno Flex al tratar con componentes de la interfaz gráfica.
• Intentar que nuestros módulos/librerías tengan el menor tamaño posible.
• Si usamos librerías/módulos parcialmente no tenemos por que cargar todo, cargaremos sólo lo que usaremos.

En adelante iré publicando algunos artículos sobre mis vivencias con la optimización de código, espero que les ayude.

Iniciación a Maven 2 (Parte 2)

Retomamos la iniciación a Maven donde la habíamos dejado, hablando del fichero POM.

El Fichero POM
Como ya habíamos comentado anteriormente el fichero POM (Project Object Model) es un fichero XML donde podemos configurar nuestro proyecto con Maven. El fichero pom.xml más básico sería algo así:


Como vemos, hemos configurado el proyecto para crear un Jar cuyo nombre es ejemploMaven y que se encuentra en el paquete fraguaDigital.ejemplos, además hemos definido que se trata de la versión 1.0-SNAPSHOT (una versíón snapshot es una versión Beta que no es definitiva). Asimismo, hemos definido un nombre para el proyecto y una url.

El otro apartado interesante de este pom.xml inicial son las dependencias, en este caso de ejemplo hemos añadido una dependencia con la librería JUnit en su versión 3.8.1. Maven intentará resolver esta dependencia desde nuestro repositorio local (usualmente en C:\Documents and Settings\Usuario\.m2\repository, pero puede ser configurado para que este en otra ubicación). Como es obvio la dependencia debe encontrarse en el repositorio, ya sea por que la hemos instalado manualmente (usando mvn install) o porque la ha descargado de un repositorio de internet. Podemos definir los repositorios de internet que usaremos añadiendo en el pom.xml:

Existen muchos repositorios maven en internet, incluso podremos crearnos uno propio (esto lo trataremos más adelante). Algunos de los repositorios Maven que más he usado son:

• Ibiblio
  
• Maven Central Repository
  
• Flexmojos

Y para buscar las dependencias y sus versiones concretas podemos usar Maven Repository

Compilar el proyecto
Para compilar el proyecto tán sólo debemos situarnos en el directorio principal del proyecto (el que contiene el pom.xml) y ejecutar el comando:

   mvn compile

Con esto generará una carpeta target que contendrá las classes y recursos.

Si lo que queremos es generar el paquete (Jar, War, etc...) ejecutaremos:

   mvn package

Integración con IDEs
Todo esto está muy bien para gestionar la creación de los paquetes dependenicas, etc, pero a la hora de trabajar lo usual es usar un IDE tipo Eclipse o IDEA. Maven nos permite generar un proyecto para estos IDEs usando los comandos:

   mvn eclipse:eclipse
  mvn idea:idea

Pero para poder hacer esto previamente debemos definir en el pom.xml que usaremos el plugin adecuado, por ejemplo si usamos eclipse añadiremos:

En este caso hemos definido en la configuración que el la naturaleza del proyecto es Spring, pero eso puede cambiarse en la configuración. La configuración para el plugin podemos verla aquí.

Con esto creo que ya está bien por hoy, en articulos futuros hablaremos de los plugins, que dan gran funcionalidad a Maven.

Saludos.

Iniciación a Maven 2 (Parte 1)

Maven es una herramienta para gestíón y construcción de proyectos creada por Jason van Zyl, de Sonatype, en 2002. Inicialmente se concibio como una herramienta para gestionar proyectos Java, pero actualmente podemos gestionar también otro tipo de proyectos (personalmente la he usado con proyectos Java y Flex).

Puede que estén pensando que es otra herramienta tipo ANT (Apache), inicialmente era así, pero actualmente Maven 2 es una herramienta mucho más evolucionada y posee una gran cantidad de plugins que permiten hacer todo tipo de cosas (ya hablaremos de los plugins más adelante). La versión actual de Maven es la 2.1.0.

Una de las mayores ventajas de Maven es la posibilidad de usarlo en red, es decir, podemos definir una serie de repositorios a los que acudir cuando nuestro proyecto necesite algún recurso. Estos recursos pueden ser de terceros o propias plugins para maven , como librerías (Jar para Java y Swc para Flex). Incluso podremos definir un repositorio propio en la que desplegar nuestras librerías y así compartirlas con los miembros de un grupo de trabajo.

Las partes del ciclo de vida principal del proyecto Maven son:
1. compile
2. test
3. package
4. install
5. deploy

La idea es que al ejecutar una meta (goal) se ejecutarán todas las anteriores, si alguna de ellas fallará se pararía el proceso informando del error.
Por ejemplo, cuando se ejecuta mvn install Maven verificará si mvn package ha sido ejecutado exitosamente (el archivo jar existe en target/), en cuyo caso no será ejecutado otra vez.

Existen otras metas fuera del ciclo de vida de Maven y se puede ir añadiendo más metas mediante la configuración de plugins en el fichero de configuración. Una de estas metas de bastante importanciós es clean.

Instalación de Maven
Instalar Maven es extremadamente fácil, tan sólo es necesario ir a la sección de descargas de la página oficial de Maven (http://maven.apache.org/download.html)
y descargarlo (en zip o tar). Lo descomprimimos en una carpeta (P.Ej: C\Tools\Maven-2.1.0) y a continuación hemos de añadir la
carpeta bin de Maven en la variable de entorno PATH. Con esto ya estaría instalado. Para comprobar que todo ha ido bien podemos ejecutar el comando "mvn --version"

Creación de un proyecto
Una característica muy destacable de Maven es que nos permite crear un proyecto a partir de un arquetipo previamente definido, pero no necesariamente por nosotros. la lista de arquetipos podemos verla en aquí. Si nos fijamos en la lista podemos ver que con un simple comando podemos crear toda la estructura de un proyecto JSF, Spring, Struts y/o otros muchos más, y con cierta funcionalidad.
Por ejemplo, el comando para crear proyecto con el arquetipo de Spring es el siguiente:

mvn archetype:create -DgroupId=org.appfuse.archetypes -DartifactId=appfuse-basic-spring 

Ésto no implica que no podamos partir desde cero, pero si tenemos en mente un cierto tipo de aplicación la puesta en marcha del proyecto será mínima.

Para crear un proyecto tán solo es necesario crear a mano la estructura de directorio que deseemos y crear el fichero POM en el directorio padre. La estrcutura típica es la siguiente

EjemploMaven
+---src
¦    +---main
¦    ¦   +---java         //Para nuestros fuentes
¦    ¦       +--- paquetes
¦    ¦           +---...
¦    ¦               +---App.java
¦    +---test
¦    ¦   +---java         //Para test de Junit
¦    ¦       +---paquetes...
¦    ¦           +---...
¦    ¦               +---AppTest.java
+---pom.xml

En paralelo a estos directorios y si lo necesitamos, podemos crear otros directorios. El nombre de estos nuevos directorios es standard en maven, el estandar lo podemos ver aquí.

El Fichero POM
Para usar maven en un proyecto tán sólo es necesario definr un fichero POM (Project Object Model), que es un fichero XML. Es el fichero de configuración de Maven donde inicialmente definiremos:
* El tipo de empaquetamiento (Jar, War, etc).
* Los directorios de fuentes y test.
* Los directorios de recursos para la aplicacion y los test.
* Las dependencias de nuestro proyecto

Además en este fichero definiremos todos los plugins, metainformación sobre desarrolladores, propiedades del proyecto etc.
--------

Como vemos Maven es un mundo muy interesante, pero muy extenso y como veo que el post esta cerciendo demasiado dejaré la configuracón del fichero pom y los comandos para la siguiente vez.

Saludos, nos vemos en la segunda parte.

Integración BlazeDS con Spring

Una muy buena noticia, para todos los desarrolladores Flex que usamos BlazeDS para comunicarnos con un servidor Java, Spring esta desarrollado "Spring BlazeDS Integration".

Este proyecto nos simplificará enormemente la vida a la hora de conectar una aplicación Flex a un servidor Java desarrollado con Spring. Simplificará mucho los ficheros de configuración, la cuál la realizaremos creando beans (sintaxis < bean>).

Aún esta en Milestone 2, pero ya se plantea liberala como RC1 (Release Candidate 1). Entre otras cosas permitirá definir el messageBroker, los remote objects, pero sin lugar a dudas el aspecto que más me ha gustado viendo la documentación de referencia es que también incluirá la configuración para Spring Security (anteriormente conocido como Acegi Security). Con lo cuál podremos asegurar de forma simple nuestras aplicaciones Flex.

Podemos ver el anunció en la página oficial de Spring. En dicha página también podemos encontrar este enlace a adobeTV, en el que Christophe Coenraets hace una gran introducción a Spring BlazeDS Integration.

P.D: Spring security nos da funcionalidades de autorización y autentificación para el uso de nuestros servicios, pero eso ya lo explicaremos en otros post.

Saludos.

Vistas materializadas en Hibernate

Recientemente he descubierto las posibilidades de una característica de Hibernate que puede parecer obvia para todos aquellos usuarios avanzados, pero que no lo es tanto y que además puede pasarse por alto fácilmente en la documentación.

Hibernate permite crear vistas de datos (una query precalculada) en el mapping de un objeto, pero la gran virtud que le encuentro a este mecanismo es la posibilidad de crear vistas materializadas (en Oracle se llama así), que no es otra cosa sino una vista de datos que crea una tabla que se actualiza al trabajar con la vista.

En el mapping podemos definir la vista como una consulta SQL en el tag subselect y user el tag synchronize para definir las tablas con las que sincronizaremos la vista.

Veamos un ejemplo extraido de la documentación de hibernate (apartado 5.1.3)

Flex Code Formatter

Parece ser que "Gumbo" (Flex 4) llevará integrado un "formateador" de código, pero hasta entonces tenemos la opción de usar flexformatter. Se trata de un plugin para formatear el código ActionScript o MXML (algo que ya se echaba en falta).

Posee muchas opciones de parametrización, pero no es necesario parametrizar todo, si tan solo queremos organizar el código lo podermos hacer igual que con otros formateadores para Java (Ctrl+I)

El plugin puede descargarse de sourceForge aquí.
También podemos ver la documentación aquí.

TODO/FIXME extension para Flex Builder

Exite un plugin que permite usar tags TODO y FIXME en sus aplicaciones Flex (algo muy corriente en entornos Java) . El plugin en cuestion ha sido desarrollado por Dirk Eismann (richinternet.blog), y podemos descargarlo aquí

El plugin está desarrollado para FlexBuilder 2 pero funciona correctamente en Flex Builder 3, doy fe de ello.

Para instalarlo tan sólo es neecesario descargar el zip, y descomprimirlo en la carpeta plugins de nuestro FlexBuilder / Eclipse.

Inauguración del blog

Este primer post sirve de inauguración. Tras mucho tiempo con la idea en mente, he decidido ponerla en práctica y crear un blog con contenidos sobre el desarrollo de aplicaciones informáticas. Muy probablemente se centrarán en aplicaciones web en entornos RIA (Rich Internet Applications) , pero no se cerrará la puerta a ningún aspecto del desarrollo de software.

La intención de este blog es publicar artículos relacionados con el desarrollo de aplicaciones informáticas, de la ingeniería del software y como no de los problemas que nos encontramos diariamente y sus soluciones.

Saludos a todo@s, y espero que lo que aquí se publique les sea de utilidad.