Repitiendo un poco lo que mi compañero Kalle Korhonen comentó en la lista de desarrollo y en la web de Trails: Trails is dead, long live Tynamo!

El titular es un poco amarillista intentando atraer un poco de atención, pero la verdad es que Trails no está muerto, sino que Trails 1.x está en "maintenance mode" y Trails 2 (la nueva versión basada en Tapestry5) ha sido renombrado a Tynamo.

Un resumen (editado de la lista de correos) de las razones del cambio de nombre:

En segundo plano (en realidad en la lista de desarrolladores) hemos estado discutiendo de cual debería ser nuestra estrategia respecto de Tapestry5. Hace más de un año "perdimos" el dominio trailsframework.org (esto es bastante largo de explicar, pero la versión corta es que los committers actuales nunca tuvimos posesión del dominio) y desde ese entonces estamos analizando varias alternativas acerca de como lidiar con esto. Hace un par de meses finalmente decidimos que lo más fácil para nosotros sería renombrar el proyecto y relanzar Trails2 con un nuevo nombre: Tynamo
Esto todavía esta sin publicitar, pero la mudanza ya está en camino, el código ya ha sido trasladado al nuevo repositorio y todos los módulos y paquetes han sido renombrados.
Creemos que hay una gran posibilidad de tener preparada la release inicial de Tynamo para antes de fin de año. Cuando la tengamos haremos el anuncio formal correspondiente.

Así que ya pueden venir a visitarnos a http://tynamo.org/ (esta vez somos los dueños del dominio). El site está prácticamente vacío porque estamos trabajando en él y preparando las releases. Las snapshots ya están disponibles en: http://ci.repository.codehaus.org/org/tynamo/
El repositorio ya está completamente migrado (con log histórico completo), el nuevo dominio funcionando y nuestros continuous integration builds ejecutándose exitosamente, así que estamos nuevamente en carrera con Tynamo. Para el momento en el que anunciemos el proyecto Tynamo a una audiencia más grande, ya deberíamos tener varios nuevos módulos preparados para el release como así también documentación decente (este nunca fue nuestro fuerte) y ejemplos que los acompañen.

Como adelanto puedo comentar que tendremos un nuevo módulo para Envers y uno para RESTeasy. También puedo adelantar que haremos open source la integración con jBPM (tapestry5-jbpm y tynamo-jbpm) que teníamos desarrollada en la empresa.

Como comentaba antes, la versión basada en Tapestry4 está en "maintenance mode" pero nosotros seguimos dando soporte en la lista de usuarios y si se encuentran problemas serios los solucionaremos.

Los desarrolladores queremos agradecer a Codehaus y especialmente a Ben Walding por pacientemente acompañarnos en la transición dándonos soporte y solucionándonos numerosos problemas.

Espero poder comunicarles más novedades pronto.

Stay tuned!

.

El stack de Amneris ha sufrido grandes cambios en los últimos meses. Tenemos 3 nuevas incorporaciones, 2 jubilaciones, y un retiro por invalidez :)

En primer lugar damos la bienvenida oficial a Tapestry5 que si bien ya hacia tiempo que estaba dando vueltas por los alrededores, no había sido debidamente presentado. La adopción de Tapestry5 deja a Tapestry4 relegado al mantenimiento de aplicaciones legacy.

De la misma manera que Tapestry4, se retira con honores Trails 1.x, que ya ha cumplido su ciclo, para dejar paso al todavía en desarrollo Trails 2 basado en Tapestry5. Trails 2 está todavía muy lejos de ofrecer todas las prestaciones que ofrece se hermano menor, pero no tiene sentido seguir invirtiendo tiempo en Trails 1 cuando el framework principal en el que se basa está ya completamente obsoleto. Esto conlleva también el esfuerzo de ir migrando de a poco todos nuestros otros frameworks y librerías que se basaban en Trails.

La incorporación de Tapestry5 al stack desplaza también a Spring como framework de IoC por defecto del stack. Spring (a mi parecer) a dejado de innovar en el espacio de la IoC y en estos momentos hay ofertas muchísimo más interesantes como Guice y Tapestry5 IoC. La cantidad de código basado en Spring IoC que tenemos es tal que reemplazarlo no será tarea fácil, pero de ahora en adelante Spring no será la primer alternativa a la hora de implementar IoC en nuestras aplicaciones. Trails2 será completamente independiente de Spring. Completamente compatible SI, pero independiente al fin.

Ya he mencionado la incorporación de Tapestry5 y Trails2 pero el gran fichaje de la temporada es Magnolia CMS. Trails nos estaba quedando un poco chico para según que cosas y necesitábamos incorporar una solución robusta que nos garantizara estabilidad pero con flexibilidad. Magnolia se usa detrás de los sitios de InfoQ y JBoss.org, así que si puede con la carga de esos dos sitios, podrá manejar nuestra carga sin ningún inconveniente. Otra gran característica de Magnolia es la implementación de Java Content Repository (JCR - JSR-170) que nos da una gran tranquilidad respecto de que nuestros datos son almacenados siguiendo un estándar abierto para la gestión de contenido.

Bienvenidos Magnolia, Tapestry5 y Trails 2!

Me pasé toda la semana pasada trabajando con ObjectiveC, prestando muchísima atención al código, especialmente a la declaración de variables, para no ir dejando memory leaks desparramados por ahí. A buena hora me vengo a enterar que ObjetiveC es muy sensible a los memory leaks. Para un Java adicto GC dependiente como yo, esto de andar contando la cantidad de referencias a un objeto para luego "destruir" (liberar) las variables a mano, es una experiencia completamente nueva.

Después de una semana con ObjetiveC el sábado retome el trabajo con Trails, preparando lo que será el codebase para Trails 2.0.x (el ".x" del final es a propósito para que no parezca un buzzword). La nueva versión de Trails estará basada en Tapestry5 y como este trae su propio contenedor IoC la mayor parte del trabajo fue portar servicios, beans y configuración de Spring al nuevo Tapestry5 IoC. Una de las principales diferencias entre los dos contenedores es que la inyección de dependencias en Tapestry5 se realiza por contructor en lugar de por setters. Esta fue la principal razón que impidió que el port de un IoC a otro fuera completamente automático.

Mientras reescribía los constructores noté que muchos de los servicios tenían variables de instancia con referencias a otros servicios que ahora ya no era necesario mantener como variable de instancia. Saltó la alarma:

Estas variables de instancia tranquilamente podían convertirse a variables internas de métodos (constructores) o simplemente eliminarse. Como consecuencia de esta reducción en variables de instancia se reduce considerablemente la cuenta total de referencias de instancias de varios de los servicios. Llegando en varias ocasiones a tener servicios procesados por el GC y eliminados completamente de la memoria.

La conclusión final es que muchos de los servicios de Spring configurados con "init-method" o que utilizan afterPropertiesSet(), o algún mecanismo similar, terminan conteniendo referencias a servicios que solo son necesarios durante bootstrap y por ende aumentando la cuenta de referencias de esos objetos que no son necesarios para continuar con la ejecución de la aplicación.

Soy consiente de que en un entorno clásico de IoC (Tapestry, Spring o cualquiera), los males provenientes pura y exclusivamente de mantener estos objetos en memoria son despreciables y que seguramente se podría lograr una reducción similar en Spring rediseñando los servicios. Pero este post no se trata de eso, este post es simplemente una reflexión sobre lo que damos por sentado los Java adictos GC dependientes como yo.

Desde hace unos días está disponible la nueva versión de Trails, la 1.2.1. Esta nueva versión está basada en Tapestry 4.1.5 y será la última versión major basada en Tapestry4.

La característica más destacada y notable desde el punto de vista del usuario es el nuevo mapeo de URLs "user/seo friendly".

URLs 1.1.1:

• http://localhost:8080/external.svc?page=DefaultList&sp=Dorg.trails.demo.A...
• http://localhost:8080/DefaultList,$NewLink.link.sdirect
  

URL 1.2.1:

• http://localhost:8080/trails/list/Apple
• http://localhost:8080/trails/new/Apple

Este nuevo mecanismo de procesamiento de URLs conlleva un gran cambio en el manejo del ciclo de vida de las páginas de Trails que repercute en una considerable mejora en la performance. Este cambio en el ciclo de vida de las páginas también permite que Trails pueda ser configurado para funcionar completamente stateless (aunque sacrificando el callback stack), multitab y multiwindow.

Otras nuevas características de la versión 1.2.1 son:

• un nuevo componente para combos anidados (kudos a Pablo Graña y Pablo Ruggia)
• soporte para claves compuestas
• soporte para nuevos tipos de página, y un nuevo tipo de página para vistas "readonly"
• mejoras en el manejo de archivos binarios
• y otros tantos minor tweaks que pueden consultarse en el changelog del JIRA.
  

Lamentablemente, a partir de la aparición de Tapestry5, Trails ha pasado a un gran segundo plano dentro del mundo Tapestry dado que Tapestry5 ya incorpora "out of the box" muchas de las carácterísticas que Trails ofrece para Tapestry4.

La próxima major release de Trails será basada en Tapestry5, intentaremos aportar aún más valor que el que ya aporta Tapestry5 para el desarrollo rápido de aplicaciones.
Tarea que no va ser fácil.

Ya hay cerca de 80 personas inscriptas para el taller de Trails en el OpenJavaDay Madrid 2008.
Dada la cantidad de inscriptos me preocupa la performance de la red wifi ya que el kickstart de Trails baja unos 45Mb de librerías desde los repositorios de Maven.
Para el taller intentaremos configurar un servidor de Maven local con todas las librerías necesarias. Pero.... nunca está de más ser prevenido, así que para evitar problemas yo recomendaría a los participantes venir con todas las librerías ya bajadas a sus correspondientes repositorios locales de Maven.

Para esto hay dos opciones:
1)

$ mvn archetype:create -DarchetypeGroupId=org.trailsframework

-DarchetypeArtifactId=trails<wbr style="font-family:courier new;">-archetype -DarchetypeVersion=1.2-SNAPSHO<wbr style="font-family:courier new;">T -DgroupId=org.javahispano -DartifactId=openjavaday -DremoteRepositories=http://snapshots.repository<wbr>.codehaus.org

$ cd openjavaday
$ mvn jetty:run

A fines de Junio tendré la oportunidad de presentar Trails en el OpenJavaDay 2008.

Sun Microsystems y javaHispano organizan el OpenJavaDay, un evento sobre tecnología Java creado por la comunidad y para la comunidad que se celebrará los días 26 y 27 de junio, en la Universidad Complutense de Madrid. Este encuentro constituye la undécima edición en España de este evento para desarrolladores.

Noticia en javaHispano: http://www.javahispano.org/contenidos/es/agenda_del_openjavaday_2008/
Inscripción Gratuita: http://javahispano.org/openjavaday/registro.html
Agenda del Evento: http://javahispano.org/openjavaday
Detalle del taller de Trails: http://javahispano.org/openjavaday/detalle.html?id=195

La idea del taller de Trails será construir una aplicación con Trails en una hora.
Estoy explorando varios modelos de dominio para usar como ejemplo, y el que más me gusta hasta ahora es el identity model de jBPM, creo que da una buena base para explorar todas las características de Trails. También existe la posibilidad de no usar ningún modelo base previamente preparado y codificar un modelo con el input de los asistentes, pero esto depende de la cantidad de asistentes, si somos demasiados no será viable.

También tendré la oportunidad de participar en la Mesa redonda sobre frameworks web.

Nos vemos en el OpenJavaDay!

Yo me considero un desarrollador ágil JAVA, o mejor dicho yo me considero un desarrollador ágil Tapestry. Pero he de reconocer que si bien la velocidad de desarrollo con Trails y/o Tapestry está entre las mejores del (sub)mundo JAVA, no sirve ni siquiera como punto de referencia cuando se la compara con la de otros lenguajes y frameworks.
Uno de los principales problemas del desarrollo en JAVA es la agilidad y productividad del programador. Realmente estamos lejos de imitar la agilidad con la que se puede desarrollar en lenguajes como Ruby o PHP, y si hablamos de frameworks web en particular, estamos lejísimos de frameworks como Rails o Akelos.

¿Por qué el desarrollo con Akelos o Rails es tanto más rápido/ágil que el desarrollo con cualquier framework web JAVA?
La clave es el Zero Turnaround Time (ZTT), que podría traducirse como: "Recarga sin demora" o "Recarga inmediata" o "Cero tiempo de recarga".
El ZTT permite que cualquier pequeño cambio en la aplicación se pueda ver inmediatamente en el navegador, simplemente alcanza con hacer "refresh" en el navegador y listo, "feedback inmediato".

El gran beneficio del feedback inmediato es que permite determinar muy rápidamente si los cambios en la aplicación son correctos o no, y ésta es la gran ventaja que hace que el "desarrollo ágil" vaya de la mano con ZTT.

Este es el punto de partida de una serie de posts donde compartiré mis trucos para agilizar mi proceso de desarrollo y para aproximarme (aunque sin alcanzarlo nunca) al ZTT.

Uno de los desarrolladores de AppFuse (y escritor de un libro sobre AppFuse que está por publicarse) se pregunta que framework debería estar aprendiendo por las noches y se queja (aunque minimamente) de la cantidad de frameworks que ha tenido que aprender este año.

Entre los destinatarios de sus quejas estoy yo que intenté convencerle de que le preste un poco de atención a Trails. No lo logré :( pero las experiencias que hemos intercambiado han hecho que el intento valga la pena.

Como resultado de ese intercambio se creó una configuración de CAS usado como SSO que es compatible tanto con AppFuse como con Trails.

La versión para AppFuse se publicará en http://code.google.com/p/casidentity/
y la versión para Trails en http://code.google.com/p/amneris/

Continuando con el post de David y con el título de este post: Mi elección personal y recomendación es: Tapestry 5
Tapestry 5 va a ser la nueva revolución en el mundo Java, recuerden lo que les digo.

Por último David arenga a los programadores web Java a echarle un ojo a Rails y yo quiero aprovechar este post para hacer lo mismo.

MIREN RubyOnRails, préstenle atención, desarrollen algo, indaguen en las entrañas del framework (son una joya en cuanto a diseño y programacíon), les aseguro que como resultado de la exploración saldrán siendo mejores programadores (Java o cualquier otro lenguaje).

Conclusión:
Pregunta: ¿A qué framework web le deberías estar dedicando tu tiempo libre?
Mi respuesta: Tapestry 5 y/o Ruby on Rails