Weblog de Alejandro Scandroli

Repositorios Maven en dev.java.net

2009-12-29T14:15:00.000-08:00

No estoy seguro que es lo que pasa últimamente con los repositorios Maven de dev.java.net. Todos los archivos descargados desde estos repositorios están fallando con un error del tipo:

slf4j-simple-1.5.8.jar; error in opening zip file

Parece ser que han trasladado los servidores de https://maven-repository.dev.java.net/nonav/repository a http://download.java.net/ y en lugar de usar un HTTP Redirect 301 están usando algún otro tipo de redirección que Maven no es capaz de procesar.

Para evitar el uso de estos servidores he escaneado mi ~/.m2/repository en busca de poms con referencias a java.net y he creado una especie de blacklist profile que permite ignorarlos.

<profile>
<id>blacklist</id>
<repositories>
<repository>
<id>maven-repository.dev.java.net</id>
<url>https://maven-repository.dev.java.net/nonav/repository</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>java.net</id>
<url>https://maven-repository.dev.java.net/nonav/repository</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>

</repositories>
</profile>

luego mvn compile -P blacklist y voilà

.

Trails is dead, long live Tynamo!

2009-10-28T01:45:00.000-07:00

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!

.

Involucrados y comprometidos según Michael Jordan

2009-09-15T16:30:00.000-07:00

El fin de semana estaba mirando el video del discurso de Michael Jordan en la ceremonia del Hall of Fame de la NBA y una parte del discurso me llamó mucho la atención.
A ver si a alguno de uds esto les suena a la parábola de "cerdos y gallinas" (aka: Ham 'n Eggs).

Juzguen ustedes mismos (comienza en el minuto 12):

El dijo (en referencia a Jerry Krause) las organizaciones ganan campeonatos, pero yo no vi a la organización jugar engripada en Utah, no la vi jugando con el tobillo lesionado. Las organizaciones arman equipos, pero es el equipo el que tiene que salir a jugar, así que los jugadores ganan campeonatos. No me mal interpreten, por supuesto que las organizaciones tienen mucho que ver con el campeonato, pero no pongan a la organización por encima de los jugadores porque al final del día son los jugadores quienes tienen que salir a jugar, la organización es quien tiene que pagarnos pero somos los jugadores los que tenemos que dar la cara y salir a jugar.

UPDATE: por alguna extraña razón el video embebido no funciona, aquí dejor el link al video original: http://www.nba.com/video/channels/hall_of_fame/2009/09/11/nba_20090911_hof_jordan_speech.nba/

.

Cambios en en el stack de Amneris (Tiempo de Balances 1)

2009-08-26T15:50:00.000-07:00

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!

Escribir software es como ..... Escribir (by Bruce Eckel)

2009-04-21T15:35:00.000-07:00

El gran Bruce Eckel como siempre dando justo en la tecla con la última entrada de su blog: Writing Software is Like ... Writing en donde presenta una analogía de los programadores como escritores.

Vale la pena leerlo todo y asimilarlo bien.
Algunas de las cosas que me parecieron más interesantes:

¿Porqué necesitamos una analogía? Nosotros sabemos lo que hacemos. Programamos computadoras, con todo lo que eso conlleva. Y nosotros sabemos lo que eso significa, porque nosotros lo hacemos. Pero para los stakeholders -- managers, CEOs, clientes, accionistas, etc -- el desarrollo de software es un misterio. Ellos no quieren saber todo al respecto, pero quieren saber lo suficiente como para poder predecir el comportamiento del desarrollo de software, aunque sea aproximadamente.

No estamos solos en este trabajo, y nuestros colaboradores necesitan poder entender que es lo que hacemos y como trabajamos, las analogías pueden ser útiles en este sentido.

(...) "Si los programadores son como ingenieros, Yo debería ser capaz de reemplazar a un ingeniero por otro y obtener resultados similares, correcto?"

Todavía me parece escuchar la voz de un antiguo jefe: "no hay problema, total después contratamos otro? no?"

JA!

(...) Aquí esta mi propuesta. Creo que explica todo. Será muy insatisfactoria para los stakeholders que quieren un comportamiento completamente predecible y que quieren reemplazar un programador con otro y obtener resultados similares. (Eso aún no pasará. La única compensación para la impredecibilidad son aproximaciones como la de los métodos Ágiles, que incrementan el ancho de banda de la comunicación con los stakeholders).

Hay 3 cosas que pueden salvarnos: Comunicación, Comunicación y Comunicación!

Somos Escritores.

Interesante, no?

(...) Aunque los stakeholders no necesariamente entiendan los intrincados detalles de los procesos de escribir y publicar, típicamente entienden que hay diferentes maneras de escribir y que habilidad artesanal de escribir es rara, inconmensurable y un procesos artístico que no puede garantizar resultados. Así que aunque "programar sea como escribir" y esto no necesariamente vaya a incrementar la predictibilidad de lo que hacemos, puede que aunque sea ayude a los no-programadores a entender su impredecibilidad.

Aprovecho esta oportunidad para saludar a todos los que tienen que lidiar con mi falta de capacidad para explicar porque no puedo predecir, con un margen de error de 5 minutos, cuanto tiempo me llevará encontrar la linea de código que está haciendo que la memoria se vaya a las nubes y los invito a leer (a conciencia) al querido Bruce:

Writing Software is Like ... Writing

La deuda técnica

2009-02-22T11:35:00.000-08:00

Desde principio de año la deuda técnica es un tema constantemente en consideración en la empresa.
Para los que no están al tanto, la deuda técnica es una metáfora de la deuda en la que se incurre al avanzar en el desarrollo de manera quick and dirty, sin prestar la debida atención a la calidad del código. Esta deuda, como la financiera, tiene intereses que se irán acumulando y que finalmente terminaremos pagando de una u otra manera. La deuda se puede ir cancelando, por ejemplo con refactoring que aunque puede costar un esfuerzo extra sirve para recortar el pago de grandes intereses en un futuro.

La semana pasada en un thread de la lista de agile-spain: Quien deberia pagar la deuda ? el usuario Ángel Medinilla escribió una GRAN verdad:

Lo que no es planteable en software es decir "Ups. cometisteis un error. Os toca venir el fin de semana a arreglarlo, ya que yo no os pago por solucionar errores". En software se cometen errores. Punto. Si la tasa de errores es demasiado elevada, o se piden overtimes y se quema al equipo o se va invirtiendo poco a poco en mejorar la tasa, tanto a priori como a posteriori. La vía de Agile es la segunda. Las consultoras no opinan lo mismo :_D

Me gusta tanto que me voy a imprimir en una remera (camiseta) la frase:

En software se cometen errores. Punto.

¿Quién no ha recorrido alguna vez (sino muchas) los interminables caminos de la primera vía?

JBoss 5.0.0.GA error: SocketProcessId.getpid could not get unique port.

2009-02-12T15:30:00.000-08:00

Un pequeño error en la configuración de resolución de nombres de mi Ubuntu, impedía que que el JBoss 5.0 levantará normalmente con una configuración local en mi maquina de desarrollo.

El log de error no es muy descriptivo que digamos:

23:29:34,795 INFO [TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.
23:29:34,795 INFO [TransactionManagerService] Setting up property manager MBean and JMX layer
23:29:35,287 ERROR [AbstractKernelController] Error installing to Create: name=TransactionManager state=Configured
com.arjuna.ats.arjuna.exceptions.FatalError: [com.arjuna.ats.internal.arjuna.utils.SocketProcessId_2] - SocketProcessId.getpid could not get unique port.
at com.arjuna.ats.internal.arjuna.utils.SocketProcessId.getpid(SocketProcessId.java:105)
at com.arjuna.ats.arjuna.utils.Utility.getpid(Utility.java:277)
at com.arjuna.ats.arjuna.common.Uid.(Uid.java:105)
at com.arjuna.ats.arjuna.utils.Utility.getProcessUid(Utility.java:289)
at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.(TransactionStatusManagerItem.java:366)

La solución es fácil, aunque costo un poco encontrarla. El S.O. tiene que poder resolver correcta y bidirecionalmente su hostname.
Para verificarlo probar que funcione correctamente el comando:

$ ping `hostname`

En un PC de desarrollo el hostname comúnmente resuelve a 127.0.0.1

Si el comando no funciona revisar la configuración de resolución de nombres, en mi caso fue suficiente con editar "/etc/hosts" y agregar una linea que resuelva correctamente mi hostname a 127.0.0.1

.

Gmail & Magnolia & JavaMail [FIXED]

2009-01-22T16:01:00.000-08:00

(continuación de Gmail & Magnolia & JavaMail)

Finalmente lo entendí! y resulta que los simpáticos muchachos de SUN tenían razón. Hay que leer hasta entender.

Lo que estaba haciendo mal era agregar un SSLSocketFactory cuando la comunicación era TLS.
Claro, ahora es fácil decirlo: "si es TLS obviamente no necesita socket SSL!", pero costó sangre darse cuenta.

La configuración finalmente queda así:

if (Boolean.valueOf((String) this.mailParameters.get(SMTP_SSL)).booleanValue()) { // port 465
props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
props.put("mail.smtp.socketFactory.fallback", "false");
}

if (Boolean.valueOf((String) this.mailParameters.get(SMTP_TLS)).booleanValue()) { // port 587
props.put("mail.smtp.starttls.enable", "true");
}

Gracias a Teresa Miyar el parche ya está integrado en el trunk de Magnolia. :)

.

Gmail & Magnolia & JavaMail

2009-01-18T09:20:00.000-08:00

Estaba trabajando en agregar soporte para Gmail en Magnolia (MAGNOLIA-2420), dándome la cabeza contra la pared con errores de JavaMail cuando me encontré con este grato aviso en la documentación

Note also that THERE IS NOT SUFFICIENT DOCUMENTATION HERE TO USE THESE FEATURES!!! You will need to read the appropriate RFCs mentioned above to understand what these features do and how to use them. Don't just start setting properties and then complain to us when it doesn't work like you expect it to work. READ THE RFCs FIRST!!!

(Las negritas también son originales: http://java.sun.com/products/javamail/javadocs/com/sun/mail/smtp/package-summary.html)

Que simpáticos los muchachos de SUN!!!

Para conectar JavaMail con Gmail la misma FAQ oficial de JavaMail propone usar unos parámetros de configuración "smtps" (notar la S final) que no aparecen en ningún otro lugar de la documentación y que, como siempre, a mi no me funcionan. Buscando por la red he encontrado varias referencias a la configuración con "smtps", pero ninguna oficial. http://www.google.com/search?q=%22mail.transport.protocol%22++site%3Ajava.sun.com

Dado que la documentación no me ayudaba decidí seguir sus consejos y esto es lo que encontré:

La documentación de Gmail indica que Gmail soporta 2 puertos para la conexión SMTP: el 465 y el 587, e indica también que debe usarse el comando STARTTLS.

El comando STARTTLS debería iniciar una comunicación encriptada sobre el submission port 587 siguiendo el protocolo TLS según el RFC 2476: Message Submission. Pero por alguna razón (que todavía no he descubierto) JavaMail da un mensaje de error al intentar usar este puerto. Después de probar varias configuraciones decidí probar el otro puerto, que si que funcionó al primer intento.
El puerto 465 es "menos" estándar (incluso hay otro servicio, el URD - “URL Rendesvous Directory for SSM” registrado por Cisco en el mismo puerto) y utiliza el protocolo SSL. El puerto 465 se menciona en el apendice A de la especificación: The SSL Protocol Version 3.0 “Simple Mail Transfer Protocol with SSL” de 1996.

La diferencia entre SSL y TLS es muy sutil y es simplemente la versión. SSL hace referencia a SSL 3.0 y TLS hace referencia a TLS 1.0 que es igual a SSL 3.1
Repito:

TLS 1.0 == SSL 3.1

Aunque el protocolo permanece sustancialmente igual existen pequeñas diferencias entre SSL 3.0 y TLS 1.0.

Al final la configuración del JavaMail para Gmail quedó algo así:

Properties props = new Properties();
props.put("mail.smtp.host", "smtp.gmail.com");
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.port", "465");
props.put("mail.smtp.starttls.enable", "true");
props.put("mail.smtp.socketFactory.port", "465");
props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
props.put("mail.smtp.socketFactory.fallback", "false");

props.put("mail.debug", "true");

Session session = Session.getInstance(props);

(Java 1.6 valida automáticamente los certificados de Gmail así que no hay necesidad de agregarlos a mano a la truststore)

Aunque encontré una solución a mi problema, y el código ya está funcionando me quedé muy intrigado de porqué no funciona con el puerto 587 y porqué en la red hay tantas referencias a la configuración "smtps" pero la única referencia oficial está en la FAQ, así que, aunque sea para sacarme la duda, seguiré investigando.

.

Diagramas de flujos según xkcd

2008-12-17T03:51:00.000-08:00

http://xkcd.com/518/

jejejejejejejejeja

iBicing disponible en el App Store

2008-11-17T01:10:00.000-08:00

Después de varias idas y vueltas con el lenguaje, con las tecnologías, con el IDE, con las apis, con los límites de la memoria, con los certificados de provisionamiento, con el proceso de registro de aplicaciones, con la censura, etc, AL FIN! ya está disponible en el App Store una aplicación que contiene una buena parte de mi código en su ADN.

Se trata de la app de Bicing para el iPhone desarrollada por Mi Mundo iPhone.
El objetivo de la aplicación es el acceso a información en tiempo real de:

Estaciones más cercanas
Listado de estaciones favoritas
Bicis disponibles
Sitios libres

iBicing es extremadamente útil, sobretodo en horas pico cuando realmente hace mucha diferencia saber de antemano que no hay espacios disponibles para dejar la bici en ninguna de las estaciones de plaza Catalunya, así que es mejor dejarla en Urquinaona de pasada y caminar las otras 2 calles.

Si tenés un iPhone y el carnet de Bicing esta es una app indispensable.

iBicing ya disponible en el App Store cortesía de Mi Mundo iPhone.

Extrañando a los recolectores de basura de mi barrio.

2008-10-07T09:00:00.000-07:00

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:

POSIBLE MEMORY LEAK!!!! POSIBLE MEMORY LEAK!!! POSIBLE MEMORY LEAK!!!!.

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.

Trails 1.2.1

2008-09-15T04:28:00.000-07:00

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.Apple
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.

3 días para el taller de Trails en el OpenJavaDay 2008

2008-06-23T07:58:00.000-07:00

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-archetype -DarchetypeVersion=1.2-SNAPSHOT -DgroupId=org.javahispano -DartifactId=openjavaday -DremoteRepositories=http://snapshots.repository.codehaus.org

$ cd openjavaday
$ mvn jetty:run

Con estos 3 simples pasos se bajan y se instalan todas (o casi todas) las librerías necesarias para seguir el taller.

2) Para los más perezosos.
He creado un archivo comprimido con las librerías necesarias, partiendo de un repositorio local vacío y siguiendo los pasos mencionados anteriormente. Descargar (35Mb)

Recuerden traer instalado Maven, y configurados sus IDEs :)
Nos vemos el Jueves.

Yo soy P R O G R A M A D O R

2008-06-15T10:00:00.000-07:00

Juan Palacio denuncia en su blog una actitud que, lamentablemente, es muy común entre los programadores: "A ver cuando me ascienden para dejar de programar"
El post generó una interesante discusión en los comentarios, y Betawriter hace un más que interesante análisis de los porqués de esta actitud, de la enumeración de Betawriter me quedo con:

- Aburrimiento: Seamos realistas. En general, la programación empresarial más típica es tremendamente aburrida. En la mayoría de las empresas los problemas suelen ser siempre los mismos aunque estén asociados a distintas tecnologías e incluso los buenos programadores acaban rindiendo poco por puro aburrimiento. El tipo de reto que supone un proyecto tras otro, o un proyecto empresarial largo, no es lo que la mayoría se espera.

- Decepción: Sí, asumámoslo. Gran parte del esfuerzo y del código de muchos programadores acaba en la basura. Directamente. En otros casos acaba en programas de baja calidad, protestas de los clientes o parcheo continuo de monstruos inmantenibles. El programador es visto como el "responsable directo" (y en cierta medida obviamente lo es). También siente decepción al ver las cosas como realmente son y no como se ven desde fuera.

- Instatisfacción: El buen programador tiene al perfeccionismo, a la belleza, al minimalismo. El contacto continuo con código basura y su conciencia de la generalmente mediocre calidad y de la gran cantidad de fallos que pueden ocurrir en su aplicación, de la imposibilidad de tender hacia una mejora continua por cuestiones económicas y de calendario, le provocan insatisfacción.

Gracias Betawriter, yo no lo podría haber escrito mejor.
Yo, por mi parte, soy PROGRAMADOR y hago un gran esfuerzo por no dejar de serlo.

Trails en el OpenJavaDay 2008

2008-06-02T02:13:00.000-07:00

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!

jBPM performance

2008-04-23T03:47:00.000-07:00

Existen ciertos falsos mitos sobre la performance de jBPM. Estos mitos informáticos pueden hacer que un cliente descarte una tecnología sin siquiera haber tenido una evaluación real de los beneficios de su uso. Joram Barrez ha salido, como los cazadores de mitos, a refutar la fama de mala performance de jBPM con una muy interesante presentación: Some real-life jBPM action: PoC jBPM Orchestration. Esta presentación ha causado una muy buena impresión en el mismísimo creador de jBPM y ha dado pie a una interesante discusión en el blog de Tom Bayens y a un nuevo post de Joram, con un benchmark más exhaustivo: Short jBPM Performance Showdown

Entre las optimizaciones que menciona Joram destacan:

Deshabilitar el logging a JBPM_LOG

250.000

configurar Log4j a nivel ERROR

poner la propiedad "show_sql" en false.

Según Joram la mejor ayuda a la performance de jBPM es configurar correctamente la cache de Hibernate.

Por supuesto que todo esto es solo para cuando se quiere exprimir al máximo hasta el último ciclo del procesador. Porque en mi opinión, para el uso estándar de jBPM la configuración por defecto es lo suficientemente buena.

History Meme

2008-04-17T00:52:00.000-07:00

Contribuyendo al ruido de la red:

ascandroli@gualicho:~$ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
115 mvn
102 cd
92 sudo
36 exit
32 ll
21 history
20 .
18 ssh
12 svn
10 ps

ascandroli@hermes:~$ history | awk '{a[$2]++}END{for(i in a){print a[i] " "i}}' | sort -rn | head
122 cd
74 mvn
53 ll
41 exit
31 sudo
25 .
21 svn
19 cg
14 ps
11 ssh

Que dicen estos comandos de mi:

mvn: ;-)

. : que tengo demasiados scripts para cambiar las variables de entorno.

exit: que cierro los tabs de las consolas desde la misma linea de comandos.

history: que no me acuerdo de memoria los comandos para usar javarebel o para hacer debug con jetty y maven.

ps: que el tomcat se cuelga demasiado y que tengo que ir a matarlo manualmente.

Git y Cogito

2008-04-05T10:28:00.000-07:00

He abogado por el uso de Git en varias oportunidades. Lo he intentado usar en varios proyectos, pero solo lo he logrado en mis propios proyectos o en proyectos que no son Java.

¿Por qué solo en proyectos que no son Java?

Porque el programador Java medio tiene un extraño rechazo visceral por las herramientas de línea de comandos y lamentablemente Git todavía no está integrado ni a Eclipse, ni a NetBeans ni a IntelliJ IDEA.
Lo curioso es que ahora que los chicos "cool" del barrio planean mudarse a Git yo recibo más consultas en un día que nunca.

Así que si sos capaz de superar el trauma emocional que implica abandonar el mundo de las ventanas y querés probar de que están hablando nuestros vecinos más ágiles, acá va mi arenga:

La GRAN GRAN ventaja de Git es el "working tree" (árbol de trabajo), el repositorio local al PC del programador. Todos los "commits" suceden en local y no se suben al repositorio hasta que no se hace un "push". Esta copia local del repositorio, permite hacer branches en local sin siquiera la necesidad de cambiar de directorio o hacer un nuevo checkout. Gracias a esto yo puedo estar trabajando un mi trunk local, crear un branch para trabajar en un parche urgente, subir todos los cambios del branch al repositorio central y volver a trabajar en mi trunk, todo sin cambiar del proyecto abierto en el Eclipse. Otra característica de Git difícil de digerir para los usuarios de Subversion es que Git jamás se confunde en un merge, JAMÁS!. Y créanme, he intentando sin éxito "hacerle pisar el palito", porque me costaba creerlo.

Para adentrarse en el mundo de Git, en realidad es preferible empezar usando Cogito, Cogito es meramente una interfaz de Git, que ha sido especialmente adaptada para el hombre de a pie. Cogito es completamente compatible con GIT (aunque hay que seguir ciertas convenciones) y hace que la transición SVN > Git sea más amena.
Por ejemplo el comando de Cogito:

$ cg-init

equivale a los comandos de Git:

$ git init && git add . && git commit

Incluso cg-init, por defecto, ignora los .svn, cosa que Git no hace.

Lo más fácil para los que recién comienzan, es empezar imitando el flujo de trabajo que tiene Subversion, que aunque limita algunas de las carácterísticas de Git, es suficiente como para un primer acercamiento. Para esto basta con crear un repositorio central contra el que trabajar. Este tipo de repositorios centrales se llaman "bare". Un repositorio "bare" es un repositorio que no es una copia activa, que no tienen un árbol de trabajo (working tree), es decir un repositorio al que nadie hace un cg-commit (tener en cuenta que svn commit no es conceptualmente igual a cg-commit)
La mayoría de los repositorios Git que se ofrecen via web (ej: github), son de este tipo de repositorios "bare".

Crear un repositorio "bare" en un servidor es tan fácil como:

$ cg-admin-setuprepo -g gitpushers /srv/git/myproyecto.git

El valor indicado en "-g" es el groupid de los usuarios que tienen permisos de "push"

Luego en local en el directorio donde esté el proyecto que se quiera subir:

$ cg-init (inicializa la copia local, ignora los .svn en caso de que existan, así que se puede usar Cogito y Subversion a la misma vez)

$ cg-branch-add origin git+ssh://git.amneris.es/srv/git/myproyecto.git (le indica a la copia local que en realidad es un branch del repositorio git.amneris.es/srv/git/myproyecto.git, el nombre "origin" es una convención de Cogito)

$ cg-push (sube la copia a local al repositorio central)

Cada usuario que se quiera bajar una copia del proyecto (svn co) tendrá que ejecutar:

$ cg-clone git+ssh://git.amneris.es/srv/git/myproyecto.git

para bajar cambios del repositorio:

$ cg-update

para hacer commit de las modificaciones

$ cg-commit -m "No olvidarse de comentar todos los checkins aunque sean locales"

y cuando ya tengan todo listo y estén preparados para subir sus cambios al repo central:

$ cg-push

Los invito a probarlo, vale la pena el esfuerzo, aunque sea simplemente para conocer otro paradigma de SCM.

PS: Lo que daría yo por tener un 1% del poder de influencia que tiene DHH y 37signals. La verdad es que a veces siento que mis opiniones provocan una reacción en la dirección opuesta.
Algo así como que ahora todos los lectores de este post abandonan el uso de Subversion pero en dirección CVS :(

re: Análisis de rendimiento y la necesidad de contratar especialistas

2008-03-09T09:35:00.000-07:00

Hace tiempo que vengo pensando en como presentar el tema de la contratación de especialistas y me encanta cuando alguien me ahorra el trabajo: Pensamientos ágiles: Análisis de rendimiento y la necesidad de contratar especialistas.

Me cansé de escuchar: "eso lo podemos hacer entre nosotros, no necesitamos contratar a nadie para que se dedique a X" donde X pertenece a {diseño web, maquetación, análisis funcional, documentación, manual de usuario, análisis de performance, testing funcional, testing de usabilidad, optimización de queries, deploy, gestión de carga y load balancing, etc.... }

Muchas de esas tareas necesitan de una persona exclusivamente dedicada a eso. Esta persona puede ser parte del "equipo titular" siempre y cuando su función esté claramente definida. Hay que considerar que los programadores de la aplicación no pueden hacer TODO (especialmente no en el mismo pliegue espacio/temporal) y hay que asignar una partida presupuestaria para estas tareas desde el comienzo del proyecto.

Volviendo al problema puntual que se planteaba en el blog de Martín, yo también le recomendaría, a quien hizo la consulta, que contrate a un especialista. Si es muy impaciente y mientras tarda en llegar el especialista puede ir probando habilitando Hibernate Statistics y JAMon para Spring, esto le ayudará a determinar los valores exactos de cantidad de conexiones a la DB, cantidad de sesiones Hibernate (OJO! que no son lo mismo que las conexiones), número de transacciones y número de llamadas a los métodos de servicios. Con estos valores en la mano podrá tener una mejor perspectiva que le permita determinar donde está el problema.

"Una cosa es ir al médico de cabecera, o quedarse en casa automedicarse y otra muy diferente es ir al especialista".

Gracias Martín.

Bicing y usabilidad.

2008-02-22T06:36:00.000-08:00

Alzado.org ha publicado una buena reseña de bicing desde el punto de vista del diseño y usabilidad.
Reconozco muchos de los aciertos de los diseñadores de bicing que se mencionan en el artículo, pero en los "aspectos a mejorar" se han olvidado del detalle más importante de todos. El detalle que puede hacer que yo deje de considerar y utilizar bicing como medio de transporte público diario para relegarlo solo a momentos de ocio.

Muchas veces no hay lugar para dejar las bicicletas.

Que es peor desde el punto de vista de la usabilidad?
1) que el usuario llegue a una estación y no encuentre bicicletas.
2) que el usuario siempre encuentre bicicletas en las estación de partida, pero que no encuentre lugar para dejarla en la estación de destino (o en las 4 estaciones más cercanas).

Ergonomía por Geert Bevin

2008-02-05T01:12:00.000-08:00

Ando en la búsqueda constante de la configuración ideal de mi espacio de trabajo. La silla más cómoda, el mejor teclado, un buen monitor, un mouse ergonómico, etc. Una incansable lucha en contra de las contracturas y del dolor de espalda.
En esa búsqueda estaba cuando un conocido programador me recomendó el AlphaGrip , un muy buen teclado, que todavía me cuesta manejar y que me ha convertido en blanco de las más viles bromas y cargadas. Mi amiga Itxaso se queja: "pero que freakies que sois".

El programador que me recomendó el AlphaGrip se llama Geert Bevin, es el creador del framework web Rife y ayer mismo comentaba en su blog que se vio obligado a ir un paso más adelante en la batalla por la ergonomía.

Gracias Geert por ir abriendo el camino. Espero que te mejores pronto de las hernias de disco.

Ahora me pregunto, que me diría Itxaso si me viera programando en esa posición?

ZTT y Tapestry4

2008-02-04T12:00:00.000-08:00

Este es el cuarto en una serie de posts donde hablo de ZTT en mi proceso de desarrollo.

1) Desarrollador ágil JAVA. ¿Oxímoron?
2) ZTT y Tapestry5
3) Matt Raible acerca de ZTT

Live Template Reloading

Tapestry4 tiene un muy promocionado "modo desarrollador" en el cual los cambios en los templates html se reflejan en la aplicación sin necesidad de reiniciar el servidor de aplicaciones.
Basta con agregar -Dorg.apache.tapestry.disable-caching=true al comando de ejecución del servidor de apps.

Si bien esta simple configuración es muy útil, tiene sus inconvenientes. El primero es que recarga todos los templates por cada request, hayan o no sido modificados. Cuando la cantidad de componentes en una página es muy grande (como suele ser mi caso) y cuando la cantidad de requests es mucha (como cuando se utiliza AJAX) la velocidad de respuesta de la aplicación se vuelve intolerable y después de la 5 o 6 recargas de la página suele dar algún que otro problema de memoria.

Una mejor alternativa es habilitar el servicio de reset usando -Dorg.apache.tapestry.enable-reset-service=true. Con este servicio habilitado es posible resetear la caché de templates y el pool de componentes simplemente accediendo a la URL /app?service=reset&page=Home o /reset.svc?page=Home

Existen varias propuestas de mecanismos para facilitarle al programador el acceso al servicio de reset. La opción tradicional es dejar abierto un tab del firefox en esa URL y hacer F5 cada vez que se quiera hacer reset. Andreas Andreu (uno de los commiters de tapestry) propone hacerlo desde un script de greasemonkey. Yo, en cambio, prefiero usar una tarea de ant:

<telnet port="8080" server="localhost" timeout="20"> <read> <write>GET /reset.svc?page=Home HTTP/1.0</write> <write></write> </read> </telnet>

El servicio de reset está desabilitado por defecto porque en producción podría ser muy fácilmente explotado para obtener una denegación de servicio.
Para habilitar reloading de templates en producción fui un paso más allá de lo documentado y expuse el servicio de reset via JMX (gracias a HiveMind) de tal manera de poder automatizar el reset de la cache tomando las mayores precauciones de seguridad (y así evitar un posible DoS).

hivemodule.xml

<contribution configuration-id="hivemind.EagerLoad"> <load service-id="hivemind.management.MBeanRegistry"/> </contribution> <contribution configuration-id="hivemind.management.MBeans"> <mbean service-id="TapestryMBean"/> </contribution> <service-point id="TapestryMBean" interface="org.amneris.tapiz4.jmx.TapestryMBean"> <invoke-factory> <construct class="org.amneris.tapiz4.jmx.TapestryMBeanImpl"> <set-object property="resetEventHub" value="infrastructure:resetEventHub"/> </construct> </invoke-factory> </service-point>

java

import org.apache.tapestry.services.ResetEventHub; public class TapestryMBeanImpl implements TapestryMBean { ResetEventHub resetEventHub; public void resetTapestryCache() { resetEventHub.fireResetEvent(); } public void setResetEventHub(ResetEventHub resetEventHub) { this.resetEventHub = resetEventHub; } }

Live Class Reloading

En cuanto a class reloading en Tapestry4, ya comenté en el post anterior que solo conozco 2 alternativas (si alguien de alguna más por favor que me lo comente).

1) Sysdeo tomcat launcher plugin (open source)
2) JavaRebel de ZeroTurnaround (software de pago, altamente recomendado)

Matt Raible acerca de ZTT

2008-01-24T14:33:00.000-08:00

En un reciente post Matt Raible dice que si tuviera que pedir un deseo para el 2008 sería que todos los frameworks web en Java tuvieran soporte para ZTT.

Matt no usa el término ZTT sino que le dice "hot deploy", pero el concepto es el mismo. En su post menciona Groovy, Grails (que está en Groovy), Seam y Tapestry5 como frameworks que ya lo soportan "out of the box", y comenta que no debería ser necesario comprar JavaRebel para poder usar ZTT en Java sino que debería ser obligación de todo framework proveer esta funcionalidad (cosa que veo un poco difícil).

Yo soy un feliz usuario de JavaRebel y lo recomiendo. La única alternativa FLOSS que conozco es el tomcat launcher plugin de Sysdeo (si alguien conoce alguna más por favor que me lo comente), que viene con un classloader propio. El plugin de sysdeo es excelente pero tiene sus limitaciones, sólo funciona con el IDE Eclipse y con el servidor de aplicaciones Tomcat (cualquiera de sus versiones) y, además, tiene varios problemas especialmente cuando se agregan métodos nuevos a una clase o cuando se cambian parámetros en anotaciones.
JavaRebel, en cambio, funciona con cualquier IDE (incluso funciona con maven :D ) y con varios servidores de aplicaciones. Como contra tiene que no es open source y que su licencia cuesta $150 (aunque bien valen la pena).

Ambas alternativas son incompatibles con cambios de estructura en el modelo Hibernate. Me pregunto como hará Seam para manejar los cambios en el modelo? los detectará? Hmmm tendré que hacer la prueba.

Por cierto, si no saben lo que es JavaRebel no se pierdan el simpático corto animado: "La historia de un rebelde Java" (A Story of a Java Rebel)

ZTT y Tapestry5

2008-01-13T03:52:00.000-08:00

Al comenzar a hablar de ZTT en java hay que hacer la siguiente aclaración: es prácticamente imposible asegurar que cualquier estrategia para ZTT para java funcionará en el 100% de los casos.
La principal razón para esto es que no hay una manera estándar establecida de hacer manipulación de bytecode de clases (weaving), y entonces cada framework o librería implementa su manera: algunos usan AspectJ, otros Javassist, otros Jakarta Commons JCI y otros como Tapestry5 implementan su propio ClassLoader.
Esto lleva a que varios esfuerzos para aproximarse a ZTT resulten incompatibles entre si y con determinados frameworks. El caso más típico es Hibernate. En esta serie de post veremos diferentes estrategias para acelerar el desarrollo al utilizar frameworks como Trails, Tapestry4, Tapestry5, Spring. Pero cuando se trata de Hibernate siempre hay que hacer consideraciones aparte, porque al realizar una modificación sobre una clase del modelo Hibernate, no todas las estrategias para ZTT funcionan correctamente. Hibernate tiene su propio weaving de classes (weaving estático con Javassist) que no permite hacer el cambio "on the fly" de una clase sin notificarle a Hibernate y recargar toda la configuración. En otro post mostraré de que manera se puede disminuir el impacto de esta limitación de Hibernate recargando el contexto de Spring.

Tapestry5 seamless ZTT

Una de las nuevas características de Tapesty5 es la recarga automática ("on the fly") de clases o templates que hayan sido modificados (Live Class and Template Reloading).
Lo mejor de la implementación de Tapestry5 es que funciona exactamente igual en desarrollo que en producción y no necesita (prácticamente) ninguna configuración o consideración extra.
Para verlo en funcionamiento se pueden consultar los excelentes screencasts de Tapestry5 que Howard ha preparado como introducción a las diferentes características del framework.
Incluso es realmente fácil de probar para aquellos familiarizados con Maven. Existe un archetype que permite probar estás caracteristicas de Tapesty5 en 10 minutos.
Las limitaciones: Tapestry5 implementa su propio ClassLoader y debido a la ambigüedades en las especificaciones de "class loading" (lo que ha generado varias discuciones) para servidores de aplicaciones, hay que tener ciertas precauciones al usar otros servidores de aplicaciones que no sean Jetty.
Otra limitación es que el class reloading se limita a clases controladas por Tapestry5 IoC, por lo que si el cambio ha sido en clases del modelo Hibernate o alguna clase que se inyecta via Spring, estos cambios no serán detectados.

Tapestry5 "Live Class and Template Reloading" es LO MEJOR (dentro del open source) que he visto para facilitar la vida del desarrollador web java y reducir el tiempo del ciclo de deployment al mínimo posible. Gracias a esta característica creo se convertirá en "él" framework web java del 2008 y seguramente volverá a ganar el premio que otorga Sun a la innovación en Java.