martes 29 de diciembre de 2009

Repositorios Maven en dev.java.net

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à

.

miércoles 28 de octubre de 2009

Trails is dead, long live Tynamo!

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!


.

martes 15 de septiembre de 2009

Involucrados y comprometidos según Michael Jordan

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/

.

miércoles 26 de agosto de 2009

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

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!

martes 21 de abril de 2009

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

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:

domingo 22 de febrero de 2009

La deuda técnica

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?

jueves 12 de febrero de 2009

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

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

.