Skip navigation

Category Archives: profesional

Investigaciones, experiencias, artículos y/o ideas que tengan que ver con mi ámbito profesional

Kent Beck estará dando una conferencia online sobre metodologias Agiles.
Es un poco tarde para los interesados en escucharla pero en compensación voy a tratar de resumir lo visto en el siguiente post.
La conferencia es libre y gratuita gracias a una colaboración entre IEEE Computer Society, Blackduck Software y Wiley-Blackwell.

Extracto
:
Agile software development is generally most valuable when used to reduce the release cycle. The key advantage of agile development is being able to more closely track changing business and market needs. The costs and risks of applying agile development are most productively applied to becoming more responsive.

Assuming you are going to release more frequently, what is likely to happen? In this talk I present sketch quarterly deployment, monthly deployment, weekly deployment, daily deployment, and finally hourly deployment, including the technical, social, and business implications.
Fecha: Tuesday, November 3, 2009
Hora: 19:00 GMT
Duración: 1 hour

Anuncios

En la semana del 6 al 9 octubre tuve la oportunidad de presenciar las charlas de la jornada latinoamericana de Agiles 2009 y el curso de TDD dictado por Naresh Jain. Fue una excelente experiencia, no solo por el valor técnico si no también por la calidad humana y disposición de cada uno de los disertantes y organizadores para satisfacer cada una de las inquietudes.

El curso de TDD fue muy bueno, Naresh demostró la importancia de tener un mecanismo de evaluación constante y automatizado para tener siempre una retroalimentación del estado del producto, aplicó el concepto de TDD con analogías sencillas sin alejarse de los casos reales de desarrollo de software y fue muy pragmático todo el tiempo.
Al finalizar el curso, salí con una idea mucho más clara sobre el significado de Unit Testing, sus beneficios, mitos y limitaciones. Los temas que se tocaron fueron en un principio XP, Pair Programing, Metodologías Agiles, Test Driven Development, Test Driven Design, Code Smells y Automated Refactoring, para después sumar herramientas para aplicar tanto TDD como BDD. Entre cada tema se plantearon cuales son los errores comunes, los patrones de diseño y las implementaciones en diferentes lenguajes: Java, .Net principalmente, pero sin dejar de lado Python, C/C++, Ruby entre otros. Cabe destacar que por la cantidad de los temas tratados, todos los participantes concluimos que el título designado “Test Driven Development (TDD) and Refactoring” no era el adecuado, puesto que el mismo no daba a conocer la totalidad de la temática del curso. Seguir leyendo

Quiero compartir un muy buen post en JBUG sobre porque hay que usar Maven, y porque tendrías que dejar de ir todos los Domingos a alabar a tu IDE preferido.

Disfruten.

El próximo 21 estaré dando una charla sobre desarrollo web usando herramientas de JBoss.

La charla es una introducción y estará orientada a programadores Jrs con contenido teórico y ejemplos prácticos pero invito a cualquier PyME interesada en conocer las últimas tendencias de los frameworks J2EE, el desarrollo orientado a componentes.

Contenido

 

            

Introducción

Este artículo intenta acercar al lector a la práctica de desarrollo orientado a la calidad utilizando la técnica de BDD, a partir de la descripción conceptual de su utilización, beneficios, casos de uso y un ejemplo.

Objetivos

Brindar la información y los beneficios sobre esta técnica para que el lector tenga la facultad de evaluar y decidir si dicha práctica es conveniente para el proyecto en el que está trabajando.  

Seguir leyendo

Uno rapidito.

Situacion:
Tenés un proyecto hecho con Ant con build.xml, properties y directórios obscuros por todos lados y resulta que desde que te pusistes a utilizar _ese_ desktop que tenés ( que ademas tiene windows ) nunca instalaste Ant ( bien ahí ), en cambio fuistes por más y utilizaste siempre Maven 2

Opciones:
1.- Lo que te dice la lógica y Alejandro Wiebe: bajar 11 megas de la Red por el proxy feo que tenés.
2.- DeSSScompilás un proyecto parecido a Ant y te armás uno parecido que cumpla con tu necesidad
3.- Vas por el camino fácil y escribís esto en un pom.xml dentro del mismo directório

Destapar tapa

Increíble que haya que dar tantas vueltas para algo tan simple. El problema radica en que no hay manera de terminar una conversación “manualmente” sumando a que cada request dispara crea una nueva conversación.

Perdón, pensando en ‘voz alta’… ahora los voy a introducir al problema. Imaginen esto, tienen una página que muestra el estado de tu transacción… viva imagen del estado de un SFSB en la conversación en curso. Ahora, cuando termina la transacción ( sea por cancelación o confirmación ) el SFSB desaparece llevándose consigo su información, por ende esta será inaccesible para la siguiente vista. Salvo… que uses Seam.

Caso 1: dentro de una conversación larga ( o long running conversation ( aka conversaciones manuales ) )

Cuando terminamos una transacción cerramos la operación con un método anotado con @End. La conversación por defecto no termina ( o mejor dicho ‘el contexto conversacional no se destruye’ ) cuando finaliza el método de la aplicación si no que se mantiene hasta que el último componente de la página haya sido renderisado. Por ende hay un instante, entre que finalizó la operación y la próxima página se está renderisando en que la conversación tiene un SFSB accesible pero invalido.

Seguir leyendo y viendo las imágenes

Construido por usuarios y desarrolladores de proyectos de la comunidad JBoss y dedicado para cada uno de los miembros de la comunidad. 

He aquí… con ustedes… les presento…

Desplegar cortinas

Tengo un post en el hornito listo para salir, pero primero algunas curiosidades.

Estuve trabajando un poco con reflection, una de las características mas fuerte de Java y poco explotadas que si son bien manejadas pueden construirse lindos frameworks como Spring, Seam o implementar el stack de EJB. Por el otro lado, el exceso del uso impacta directamente en la performance de la aplicación y si estamos haciendo cosas complejas utilizando Proxies podemos perdernos y el flujo de ejecución termina lejos de donde esperabamos.

Vamos a ver de que hablamos cuando hablamos de reflection. Aclaro que lo que vallan a leer es solo por la experiencia de uso, no soy ningún experto en la materia, así que cualquier corrección es bienvenida.

Supongamos que tenemos una tarea simple, le queremos listar todas las posibles acciones que nuestro EJB puede hacer al consumidor. Obviamente la primera respuesta es tenerlo en archivo de configuración posiblemente un xml blah blah blah… pero la verdad es que toda esta información ya está escrita y está en la interfaz del EJB. La pregunta es como hacemos para transformar este código en información visible, y no voy a dar mas vueltas.

Seguir leyendo

Buenas, habrán notado que tuve un pico de blogs y ahora bajo un poco… no crean que esto va a terminar tan rápido. Simplemente estuve trabajando en algunas cosillas que por supuesto tienen que ver con esta bitácora. 

Una de ellas es tener un mirror del blog en inglés, también en wordpresss.

Y otra es que me envicié portando la implementación de Sun de JSF para J2SE =D . See, hay una nueva moda, cuestionar JEE y preguntar porque estas funcionalidades no lo puedo tener en mis aplicaciones. Esto empezó con Context and Dependecy Injection for Java ( aka jsr-299 ( aka WebBeans ) ) que con mucha lógica dijeron “Gavin, ¿Qué tiene que ver contextos y DI con JSF y EJB?” o algo similar, ahora me toca a mi seguir con la moda.

Me hice la pregunta ( hace tiempo ya, pero no tengo pruebas =P ) ¿Por qué no puedo utilizar las ventajas de la programación declarativa en mis aplicaciones desktops y dejar de romperme la cabeza ( aka marote ) en pensar si voy a usar Swing, SWT o similares? Por cierto para tener en cuenta, parece que Sun bajó los brazos en este area.

Y el proyecto está avanzando, ayer casi logro levantar un ejemplo pero el spec de JSF parece estar muy ligado al paquete javax.servlet.http y voy a tener que hacer un poco de magia negra, pero de la buena. En cuanto tenga un ejemplo se los muestro, la idea es definir las vistas con JSF/Facelets y implementar un RenderKit para dibujar con la tecnología que queramos. Una vez superado eso agregar Seam, aunque sería óptimo tener una versión GA de OWB ó WB para entonces.

 

Salut

Buenas, ya más de una vez me preguntaron y varias veces escuche definiciones no del todo exactas acerca de…

qué es Seam?

Antes de escuchar de mis palabras que es Seam, veamos un poco que dice el sitio oficial.( con mis comentarios )

“Seam is a powerful open source development platform…” ( de lo que solo se desprende que es una plataforma =D )

“Seam integrates technologies such as …. “ ( integra tecnologías )

“… has been designed from the ground up to eliminate complexity at both architecture and API levels.”

Si vamos al doc oficial, en la introducción nos cuentan que:

  • [Seam is] One kind of “stuff” ( no nos dice mucho )
  • Integrate JSF with EJB 3.0 ( integración de tecnologías )
  • Integrated AJAX ( integración de tecnologías )
  • Business process as a first class construct ( integración de tecnologías )
  • Declarative state management ( programación declarativa utilizando meta-información )
  • Bijection ( motor de dependency injection ( … que sirve para integrar ) )
  • Workspace management and multi-window browsing ( producto del nuevo manejo de contextos )
  • Prefer annotations to XML ( marketing )
  • Integration testing is easy ( … marketing )
  • y un par de cosas mas…

Seguir leyendo

Como había comentado en el anterior post, mas de un grupo está trabajando en una implementación de Java Context and Dependency Injection ( aka jsr-299 ) por un lado lo tenemos al grupo de Apache con Gurkan Erdogdu a la cabeza y por otro al grupo de JBoss con Pete Muir.

Lo que no esperaba encontrarme es que ambos tengan diferencias en los fuentes de la interfaces, y no me refiero a la implementación lo cual es completamente entendible, pero si no nos ponemos de acuerdo en las interfaces de entrada… stamo fritos stamo.

Importante, tener en cuenta las versiones que tomé como referencia:

  • De la implementación de referencia ( RI ) de Pete Muir utilicé la version 1.0.0.BETA1 ya que es la última que cerraron
  • De la RI de Gurkan Erdogdu tomé la última revisión trunk del SVN público al día de la fecha

Pero ¿Qué tipo de diferencias podemos llegar a tener en las interfaces, clases y anotaciones ( teniendo un documento q regule esto ) que influyan en el comportamiento? Hasta ayer me animaba a decir ninguna, pero no es este el caso. Veamos las diferencias:

*Nota: Cuando quiera referirme a la diferencia de códigos voy a utilizar “gurkan” para el código de de OpenWebBeans y “pete” para el código de WebBeans.

 

En las clases

Es lo mas difícil de analizar, ya que no solo tienen que mantener el mismo contrato público ( nombre de métodos, cantidad y tipo de parámetros ) si no que su implementación, sin necesidad de tener las mismas lineas de código debe tener el mismo resultado. Por suerte, solo tenemos dos clases y son fácil de analizar :D.

javax.inject.AnnotationLiteral

Esta clase ayuda a representar una anotación en forma de una instancia para poder usarla como parámetro de un inyección manual de un componente.

public boolean equals(Object other)

gurkan – tiene mejores validaciones
pete – posible NullPointerException en linea 141 cuando el método de una anotación devuelva un valor nulo.

Seguir leyendo

Una buena noticia para mi, una muy buena para todos los que seguimos de cerca la JSR-299 y que solo conocían de la implementación del equipo de JBoss de esta especificación.

Navegando por la web encontré que Gurkan Erdogdu viene trabajando este tema desde hace rato en su blog y hasta tiene su propia implementación: OpenWebBeans

Habrá que seguirla de cerca para ver como evoluciona, groso.

P.D.: Al parecer tiene otro blog

Salut

Para no perder el camino/idea del blog y para darle un poco mas de forma a esto que crece ( tampoco para que me sirva de machete =D ) voy a hacer un resumen de los  temas quiero tratar acá:

  • Dependency Injection and Contexto for Java (aka WebBeans)
  • Stress testing en aplicaciones web utilizando  Seam ( JSF, EJB, Seam )
  • DynamicDTO, un mini proyecto abandonado que revive desde lo obscuro
  • JBoss 5 y OSGi
  • Seam en general

Quizás me olvide de algo, pero mas o menos es eso y hasta con ese orden de importancia.

Así que ya saben, por si estos temas no les interesa/gustan los temas ;)

Salut

 

Un patrón muy utilizado dentro del mundo JEE es el conocido Service Locator, sobre todo para acceder a instancias de EJBs como vamos a ver en el ejemplo mas adelante.

Lamentablemente, aunque se detecta la necesidad de un componente que resuelva el problema de acceder ciertos servicios no siempre la solución implementada cumple con los requisitos o la manera de resolverlo tiene resultados no esperados, como por ejemplo hacer que dicho patrón sea estático o mezclarlo con un Singleton y sumar al caldo un cache _global_ de Stateful Session Bean (aka SFSB), aunque irónicamente se haga cache de Stateless Session Bean (aka SLSB) con el mismo fin. Está bien, en ciertas ocasiones un cache no vendría mal pero vale la pena analizarlo a fondo porque, como _toda_ solución de cache ( deberían anotarlo si no lo saben ), trae muchos efectos colaterales… muchos.

Primer problema, supongamos que decidimos hacer a la instancia del Service Locator (desde ahora SL) estática porque observamos que no importa el estado del SL, para un nombre de SB queremos que nos devuelva dicho SB sea SF o SL. Si la instancia del Service Locator es única los SFSB que quedan asociados van a ser los mismos para cada llamado dentro de la aplicación, haciendo a nuestro SFSB un servicio estático también.

Segundo problema, si la referencia que tenemos a cada SFSB se mantienen abierta durante mas tiempo de lo que necesitamos y tenemos un problema de conexión o cualquier otro imprevisto ya no hay manera de volver a usar dicho servicio si no renovamos la referencia, esto va sobretodo para aquellos que usan los SFSB con “métodos estáticos” o sin estados como por ejemplo “int sumarDos(int base)”. Para que se entienda, si tenemos un SFSB asociado a la sesión y el servidor de EJBs se reinicia entro dos llamados, el segundo llamado va a fallar porque el id de SFSB que tiene el cliente que consume dicho servicio no existe en el servidor de EJBs, tirando la siguiente excepción:

javax.ejb.NoSuchEJBException: Could not find stateful bean: <super_id_largo_y_horrible>

Los problemas, o mejor dicho las causas de perder la referencia a un SFSB pueden ser varias ( no siempre un problema ), las mas comunes:

  • Reinicio del servidor de EJBs, si tenemos el cliente y los ejbs en diferentes máquinas virtuales
  • Inactividad por un tiempo prolongado. Recuerden que los SFSB son uno por cliente, por lo que el contenedor de EJBs destruirá cualquier SFSB que esté inactivo por mas tiempo que por configuración se le indica.
  • Si llamamos a un método con la anotación @javax.ejb.Remove pero mantenemos la referencia al SFSB.
  • etc..

Solución: NO guardar ninguna instancia de Session Bean en un Service Locator, por mas tentadora que parezca la idea, por mas creamos que sea una buena optimización. En el único caso que vale la pena es cuando sabemos que vamos a consumir solo SLSB, pero como el cliente supuestamente no sabe nada sobre la implementación de los servicios esta solución nos puede traer mas dolores de cabeza mas tarde.

 

Dicho esto y como el titulo prometía hablar de JBoss Seam vamos a ver que les parece mi propuesta. Mi Service Locator, si bien van a ver que las clases tienen dependencias de runtime en Seam, la idea principal se puede usar sin este framework.

Empecemos por el principio, el punto de vista del usuario del patrón. ¿Cuál es el mejor Service Locator que conocen? Yo el @EJB, vamos a ver que tan parecido lo podemos hacer.

Hay una anotación de Seam muy parecida, @org.jboss.seam.annotations.In que nos permite inyectar dependencias, el problema es que no queremos hacer un componente diferente por cada implementación que valla a utilizar el cliente, a lo sumo llamaremos al SL con el nombre del EJB que queremos utilizar. Y como hacemos eso con Expression Language (EL) ? Un mapa de ejbs :D

Sería algo como esto:

    @org.jboss.seam.annotations.In("#{locator['myEJBImplBean']}")
    private MyEjbInterface mei;

Excelente, entonces _locator_ es nuestro componente encargado de encontrar los servicios, nuestro Service Locator. Pero como que es un Mapa? Veamos la implementacion

@Name("locator")
@Scope(ScopeType.APPLICATION)
public class EjbLocator implements Serializable {

    public Object locate(String name) throws RuntimeException {
        try {
            String jndi = Init.instance().getJndiPattern();
            return new InitialContext().lookup( jndi.replace("#{ejbName}", name) );
        } catch (NamingException ex) {
            log.error("Error inicializando el ejb " + name , ex);
        }
        return null;
    }

    @Unwrap
    public Map<string ,Object> getResource(){
        return new Map</string><string ,Object>(){

            public Object get(Object key) {
                return locate((String)key);
            }

            /* .... muchos metodos que no tiene sentido agregar ... */

            public Object put(String key, Object value) {
                throw new UnsupportedOperationException("Not supported yet.");
            }

        };
    }

}

Nota:

  • Todas las anotaciones están bajo el paquete org.jboss.seam.annotations
  • La instancia de InitialContext se podría generar menos seguido
  • Obviamente quite código q no venia al caso :)

Entonces, tenemos un componente Singleton que nos sirve como Service Locator que cuando hacemos referencia a él lo que obtenemos es un mapa. Cuando busquemos un objeto dentro del mapa con la key X, el SL intentará encontrar una referencia a un EJB con el nombre X.

Claramente, los métodos pueden ser estáticos pero la verdad en este caso no hace la diferencia, la magia está en como esto se mezcla con Dependency Injection y Expression Language. Sientanse libres de mandar sugerencias, ideas, correcciones o simples comentarios.

Y como decían en Nivel-X, bueeeno.. esto fue todo y espero q les haya gustado. ( espero que no tenga copyright =P )