Nov 28

Primeras impresiones con redmine

Al final no pude instalar redmine en el trabajo el lunes pasado, me puse malo y hasta el miércoles no fuí al curro.

La instalación, por supuesto, no fue tan sencilla como en casa gracias a las excelencias de nuestro proxy corporativo. Por supuesto, las gemas de ruby no pasan por el proxy con autenticación directamente, así que tuve que googlear un rato para ver cómo configurar lo del proxy. No fue difícil, basta poner una variable de entorno asi

C:\> set http_proxy=http://usuario:password@proxy:puerto

y listo. Eso sí, mi primer despiste fue que me bajé una versión algo más antigua que la más nueva de ruby y no soporta lo del usuario y password en la URL, así que no me funcionó hasta que me bajé la más nueva.

Luego todo sobre ruedas, la instalación sencilla y en unos minutos estaba funcionando. Cree un primer proyecto y metí algunas tareas para hacer la "presentación" de la herramienta a los compañeros.

La acogida me asombró, normalmente suelen ser reacios a este tipo de herramientas, pero la sencillez de uso y el ver que les sirve de gestor de tareas público, les gustó bastante. Todos, de una manera u otra, llevan sus tareas y los que tienen alguna resposabilidad echan de menos el poder tener accesibles las tareas de los desarrolladores a los que llevan, tanto para asignarles nuevas tareas, como para ver el avance de las mismas.

Así que nada. Estamos ahora metiendo las tareas en un proyecto del que acababamos de hacer la planificación con el microsoft project. Es repetir el trabajo de meter las tareas, pero al menos espero que esta vez sí se mantengan actualizadas en tiempo "real" y no como pasa habitualmente, que el microsoft project queda en el olvido precisamente por lo complejo que es ir actualizando dichas tareas. Y empezaremos a ir metiendo los demás proyectos ahí, además de ir migrando poco a poco nuestros actuales bugs en bugzilla.

Nov 27

Humillación pública

En algún sitio leí que era una buena costumbre "humillar públicamente" al desarrollador que rompa la compilación nocturna de los proyectos.

Por más vueltas que le daba, no se me ocurría que podía querer decir eso de la "humillación pública". ¿Ponerle unas orejas de burro durante todo el día, como en el cole? ¿Ponernos alrededor de él, señalarle con el dedo y reirnos?. ¿Una lista negra colgada en un sitio visible? No sé, me parecía una cosa "muy americana".

Sin embargo, en el post "La build y la botella" de Pensamientos ágiles, he visto una forma muy "española" de hacerlo. El que rompe el compilado, echa una moneda al bote y al final de año nos vamos todos de cañas con el fondo. Eso sí, en nuestro caso, creo que vamos a necesitar una botella muy, pero que muy grande e irnos de cañas con más frecuencia.

 

Nov 26

Alucinando con Grails

El otro día me puse a jugar con Grails, símplemente por ver de qué iba, y me he quedado alucinado.

La instalación realmente sencilla. Un zip a desempaquetar y poner un par de variables de entorno.

Luego generar una aplicación "hola mundo". Basta un comando sencillo para crear todos los directorios del proyecto, incluidos los ficheros del proyecto eclipse correspondiente.

El único código que hice para el ejemplo fue una clase groovy con un par de atributos y un controlador por defecto, que no es más que otra clase groovy con una única línea de código para poner a true una ¿variable? Y listo, ya está la aplicación "hola mundo" lista para arrancarse.

Se arranca y se arranca un pequeño servidor web de prueba con tu aplicación. Entras en el navegador y tienes una página web en la que aparece una lista de tus entidades almacendas en base de datos, con posibilidad de crear, editar y borrar dichas entidades desde el navegador, funcionando todo bonito y a la perfección.

Y eso es la primera cosa que me alucinó: Ha creado automáticamente unas tablas en una base de datos (HSQLDB por defecto) y ha creado toda la interface de usuario (web) para poder leer y modificar dicha tabla. Quizás la aplicación no es muy útil o exactamente lo que queremos, pero desde luego es una forma muy rápida de tener el esqueleto con lo básico.

Animado por este éxito, me pongo a investigar cómo se hacen dos entidades relacionadas entre sí. También es muy sencillo. Basta crearse la nueva clase groovy para la nueva entidad y poner algún atributo static "raro", que dice "hasMany", "belongsTo" y/o "mappedBy" y ya está hecha la relación. Nuevo controlador para la nueva entidad …. y nueva cosa alucinante: sin necesidad siquiera de rearrancar el servidor, se recrean las tablas, incluida la asociación y toda la interface web para manejar ambas entidades y las relaciones entre ellas.

En cuanto a la interface web, hay una por defecto para todo esto que no se ve, pero con un comando de grails podemos generarla para dejarla visible y podemos tocar en ella para modificarla o rehacerla entera a nuestro gusto.

Y ahí es donde me tropecé y me paré. No tengo ni idea de groovy ni de gsp (lenguaje que usa grails para la interface web y que imagino que el nombre viene de jsp al que han cambiado la j de java por la g de groovy), así que cualquier cambio no trivial (y muchos de los triviales) se me hace un mundo. De todas formas, parece una opción más que interesante para el desarrollo rápido de aplicaciones web. Sólo el hecho de que te puedas despreocupar casi totalmente (y digo casi sólo por precaución) de la base de datos y de su existencia, ya merece la pena.

Nov 22

trac & redmine

Sigo con mi tanda de evaluaciones de herramientas y criando Apaches en mi PC.

Tras ver que trac se me resiste y fisgando los instalables que tienen en bitnami, me he encontrado con redmine. Es una herramienta de gestión de proyectos y bugs similar a trac, así que me he decidido a probarla.

El bitnami stacks de redmine me falló, al igual que el de tracks. Se instala bien, se abre el navegador con la página inicial de bienvenida de bitnami, pero cuando pinchas el enlace que te lleva a la aplicación, da un error de proxy. Así que lo desinstalo, lo borro y me decido a hacerlo a mano.

Primera sorpresa agradable de redmine respecto a trac. La página en la que te explica la instalación está muy clarita, indicándote paso a paso qué hacer, qué descargarte previamente (ruby on rails) y cómo configurar el correo (cosa que considero básica en una de estas herramientas). Y siguiendo los pasos, me ha funcionado a la primera. Con trac seguí los pasos, me dio errores, me pelee con él, conseguí que funcionara, me dieron errores los scripts de administración para crear proyectos, me pelee con ellos y al final pasé. Por supuesto, ni intenté lo del correo porque no he visto cómo (tampoco lo buscado). Sé que existe easy_install para instalar fácilmente trac, pero ese easy_install no es nada easy de install (perdón por el juego de palabras). Si sigues el link de easy_install desde trac te lleva a una página que a su vez te redirige a otra de python y después de instalarlo no funciona a través de un proxy que requiere autentificación y tienes que ponerte a rebuscar en una documentación poco clara a ver si hay alguna forma de hacerlo funcionar  y ves que quizás si te instalas un APS proxy server a lo mejor funciona, pero entonces tendrías el problema de ver cómo ese APS proxy server se configura para que acceda a internet a través de tu proxy que requiere autentificación. En fin, bastante easy.

Segunda sorpresa agradable con redmine. Toda la administración se hace través de la web y bastante sencilla. Creas los proyectos, configuras los repositorios de fuentes, das de alta a los usuarios o incluso ellos pueden registrarse. Con trac necesitas un comando que viene con apache para dar de alta un usuario o bien copiar un trozo de script python para generarlos. Sí, ya sé que trac viene con un plugin para administración desde la web, incluso dice que a partir de la versión 0.11 ya viene por defecto, pero hay que habilitarlo en un fichero de configuración que no encontré en ningún sitio de la instalación y que en ningún sitio de la documentación he visto donde hay que ponerlo. Por cierto, la instalación de trac no se si instala algo en algún sitio, porque lo único que ha hecho es meterme un montón de scripts en el directorio donde tengo instalado python (cosa que me parece un poco "guarra").

Más sorpresas agradables, redmine soporta directamente varios controles de versiones, incluido CVS. Trac sólo soporta subversion, salvo que le instales más plugines. Algunos se quejan de que redmine no soporta Git, que es el que está ahora de moda, pero a mi de momento no me afecta.

Así que me pongo a jugar con redmine y veo que aparentemente tiene todo lo que tiene trac (navegar por el código, línea de tiempo y bugs) y más cosas. Soporta varios proyectos con subproyectos, pero en tu página de acceso tienes las tareas asignadas a tí de todos ellos. No tienes que ir visitando todos los proyectos uno a uno para ver qué tienes que hacer como en trac. Tiene foro por proyecto. Tiene posibilidad de subir documentos por proyecto. Y saca un gráfico de Gannt con la evolución del proyecto (quizás no sirva de mucho, pero queda bonito). Presenta además estadísticas de horas gastadas por proyecto, por componente, por persona, por tipo de tarea, etc. Eso sí, habría que ir poniendo todos los días cuántas horas gastas, cosa que seguramente no consiga que todos lo hagamos con la suficiente diligencia.

Además es muy configurable en determinadas cosas. Puedes poner los roles de usuario que quieras, borrando los de defecto o añadiendo nuevos. Para cada rol puedes modificar los permisos, incluido qué cambios de estado de los bugs son permitidos para cada usuario según su grupo: por ejemplo, un desarrollador puede marcar una incidencia como resuelta, pero no como cerrada. También puedes decidir los tipos de tareas a realizar (por defecto diseño y codificación), prioridades de bugs, etc.

En cuanto a pegas y pros a favor de trac o redmine, la gente se queja de trac por no soportar de forma cómoda múltiples proyectos y no tener cosas como, foro, gannt, etc. He visto en foros problemas de instalación similares a los mios. Es decir, son problemas o carencias reales. En cambio, las quejas de redmine son menos tangibles, coas como que es una herramienta muy nueva y no está tan probada como trac (sin indicar ningún problema concreto (bugs tendrá, como todos los proyectos, incluido trac)) o como que es más fiable el python de trac que el ruby on rails de redmine (es posible, no conozco ninguno de los lenguajes en profundidad como para saber si es un problema real, pero desde luego no me ha dado ningún problema en las pruebas que he hecho).

Así que por mi parte la decisión está tomada. Por facilidad de instalación y administración, claridad de la documentación, así como por tener más posiblidades sin complicarse la vida, el lunes lo instalaré en el curro y meteremos un proyecto del que precisamente tenemos que empezar a hacer la planificación.

Nov 21

Apaches como setas

 

Ultimamente me ha dado por probar algunas herramientas nuevas e incluso volver a probar algunas que ya había probado. En concreto, me he vuelto a instalar un servidor de subversion, he vuelto a intentar instalar trac, también otra cosa que he encontrado por equivocación y que se llama traks (una aplicación web para usar GDT, con lo cual me resultó interesante), etc, etc.

Como soy vago y encima estoy mal acostumbrado a Windows, para todas ellas me he buscado instaladores de windows, de esos que se instala todo solo con un par de clicks. En concreto, he usado los instaladores de bitnami, u otros del estilo, cuya principal ventaja es que con un par de clicks instalan TODO lo necesario para tener la aplicación funcionando.

Y la ventaja de estos instaladores es precisamente su problema.

Casi todo lo que he instalado son aplicaciones web, así que creo que tengo todos los puertos desde el 8080 al 9999 ocupados con servidores apache, cada uno para su aplicación. Debo tener como tres o cuatro versiones de python instaladas en distintos directorios (que además ya tenía instaladas previamente), varios servidores MySql y sabe Dios cuántas cosas más por tripitido.

Menos mal que después de probada un poco la aplicación, se desinstala igual de fácil que se ha instalado.

Por cierto, los tra* no me van bien. trac me sigue pareciendo demasiado complejo de configurar sin el instalador, aparte de que me da errores al ejecutar los python. Y el bitnami stack de track, después de la instalación, me ha fallado en el arranque, por lo que no he podido siquiera verlo en marcha.

Nov 15

Los móviles no tienen Ctrl-C

Ayer me puse a hacer un pequeño jueguecito para el móvil, como siempre, no por el juego, sino para aprender cosas nuevas, en este caso algo de J2ME. Un cuatro en raya.

Hago una primera "cosa" para dibujar el tablero y poder colocar las piezas, genero el jar correspondiente y lo pongo en el móvil. Juego un poquito con esa pequeña chorrada y todo va estupendo…. hasta que quiero dejar el juego. ¡¡ Vaya por Dios !!. No he puesto un botón de salir y el móvil no tiene Ctrl-C. La única forma que encontrado de salir de mi juego es apagar el móvil.

Objetivo conseguido, he aprendido una cosa nueva: En los móviles es imprescindible poner un botón de Salir.

Nov 12

Más de Subversion

Hace poco me tocó hacer una rama CVS de los proyectos para estabilizar una versión para unas pruebas con el cliente. Ya se sabe, rama del repositorio del proyecto y rama de todos los repositorios con librerías que utilice el proyecto.

Pues bien, ha sido horrible. Son cuatro o cinco repositorios y cada uno de los proyectos/librerías a "enramar" tienen fácilmente tres mil ficheros java. Eché toda la tarde en hacer las dichosas ramas. Primero un update, luego el cvs tag para poner una etiqueta justo en el punto donde comienza la rama y luego el cvs tag -b para crear la rama. Al hacerlo CVS fichero a fichero, media hora larga con algunos de los repositorios mientras cvs hace el trabajo.

Se me ocurrió, harto de ello, montar un servidor de subversion, migrar alguno de los repositorios CVS a subversion (usando cvs2svn) y mirar a ver cuánto tarda subversion en hacer la rama (svn cp). Es casi inmediato, ya que realmente no realiza la copia real de todos los ficheros (lo hará cuando se vayan modificando si se van modificando) y tampoco tiene que andar recorriendo todos los ficheros para ver su versión actual (CVS tienen un número de versión para cada fichero, mientras que subversion tiene un único número para todo el repositorio).

Todo el mundo habla que los sistemas de control de versiones distribuidos, estilo Bazaar o Git son maravillosos. También se habla mejor de Subversion que de CVS, aunque no todos lo hacen. A mí realmente todo eso me parece bien, pero mientras no veo una necesidad real o una mejora importante, no veo tampoco necesidad de cambiar. Ahora sí he encontrado un motivo, así que es cuestión de empezar a mirar en serio la posibilidad de migrarlo todo a Subversion.

De momento descarto Bazaar o Git por tener menos soporte para los IDEs habituales (eclipse en concreto). Tampoco tengo muy claro lo veloz que puede ser hacer un branch de un repositorio grande si eso implica la copia completa de todo el repositorio, con su historia (ya digo, repositorios de tres mil clases java con cuatro o cinco años de historia y alrededor de veinte desarrolladores de media desarrollando día a día).

Nov 07

Plugin de maven para cambio de versiones en los pom.xml

 

Hace tiempo que tengo una necesidad en el trabajo y que he ido dejando olvidada por falta de tiempo. Cuando en maven manejas proyectos grandes, cada uno con varios subproyectos  y encima esos proyectos grandes dependen de otros proyectos grandes que también tienen sus subproyectos, llevar un versionado en condiciones de cada jar puede ser un infierno.

Me explico, tu proyecto grande lleva un fichero pom.xml. Cada uno de los subproyectos también. En los demás proyectos también y en sus subproyectos también. Algunos de los jar de alguno de esos subproyectos pueden ser librerías básicas, por ejemplo, una librería de componentes swing o de utilidades para acceso a base de datos, de gráficos, o lo que sea. Aparecen dependencias de esa librería en los pom.xml de muchos de los proyectos y subproyectos.

¿Qué pasa si cambiamos la versión de esa librería?. Que no queda más remedio que ir en todos los proyectos y subproyectos en los que queremos actualizar la versión buscando dicha librería por los pom.xml y cambiando el número de versión. Desde luego, una tarea rutinaria, pero algo aburrida, que lleva un tiempo y susceptible de error "humano" al hacerla a mano.

Así que pensé en hacer un script o algo que buscara por los pom.xml y cambiara automáticamente las versiones que se le dijeran. Así que por fin me puse a ello y como siempre, para jugar y aprender algo nuevo, en vez de un script, decidí hacerlo como plugin de maven.

El resultado es un plugin de maven con dos goals:

  • lista saca en un fichero un listado de todos los artifacts que aparecen en el pom.xml del proyecto y subproyectos actuales y con la nueva versión o groupId que queremos para cada sub/proyecto. Ese fichero lo utilizará el siguiente goal para hacer los cambios en el pom.xml.
  • cambia realiza los cambios indicado en el fichero anterior en todos los pom.xml que encuentre del proyecto y subproyecto. 
    • Si se ejecuta este goal en el mismo proyecto en que se ejecutó el lista, obtenemos un cambio de versión en el proyecto. Quizás el plugin release de maven hace esto mismo y mejor.
    • Si se copia el fichero de cambios en otros proyecto distinto y ejecutamos allí el goal cambia, conseguimos cambiar la versión de las dependencias con el primer proyecto.

Lo he estado usando ya y probando, va bastante bien, aunque veo que el uso no es demasiado intuitivo, siempre se me olvida hacer alguna cosa.

Ahí van un par de enlaces:

Aprender, pues aprendí algunas cosillas, sobre todo, ¿cómo no?, problemas con los que me he tropezado. El más gordo ha sido que no hay forma de hacer un deploy de un plugin en condiciones. En el pom.xml del plugin, el packaging es "maven-plugin". Pues el deploy no sabe hacer un deploy de una cosa cuyo packaging es "maven-plugin", así que para que funcione el deploy, debes poner packaging "jar". Pero claro, eso sube el fichero .pom al repositorio remoto con ese packaging que no es, así que luego, a mano y en el repositorio remoto, tienes que cambiar el "jar" por "maven-plugin" otra vez. Y el problema sigue, ya que al cambiar eso a mano, los ficheros de checksum/huella o como quieras llamarle .md5 y .sha1 que se crean en el repositorio remoto ya no cuadran y al bajarte el plugin con maven dan un warning.

Y yo creo que ya está bien de proyectos. Esta tarde me dedicaré a otra cosa.

Nov 05

maven, jar, assembly y snapshots (y III)

 

Bueno, pues al final la solución al problema del assembly, el jar y los snapshots no ha sido tan compleja. Complejo, complejo, lo que se dice complejo, ha sido encontrarla por la web. La implementación una chorrada.

Resulta que el plugin assembly admite que digamos cómo queremos que se llamen los jar que va a meter en el zip, por lo que podemos cambiar el nombre para que no tengan el timestamp yyyymmdd.hhmmss-x y sí salga la palabra SNAPSHOT. Para ello, en el fichero de configuración de assembly (dep.xml suelo llamarlo), basta poner algo como esto

<dependencySets>
   <dependencySet>
      <outputDirectory>/Jar</outputDirectory>
      <outputFileNameMapping>${artifact.artifactId}-${artifact.baseVersion}
                   ${dashClassifier?}.${artifact.extension}</outputFileNameMapping>

      <scope>runtime</scope>
   </dependencySet>
</dependencySets>

 El "truco" está en el tag <outputFileNameMapping>. Con él podemos decir qué nombre queremos que tengan los jar y para ello podemos usar variables que nos proporciona el plugin para cada jar. Así, por ejemplo, ${artifact.artifactId} es el artifactId del jar en cuestión.

La diferencia con la opción por defecto es ${artifact.baseVersion}. Esta variable contiene la versión con la palabra SNAPSHOT. Si usamos la opción por defecto, ${artifact.version}, esta contiene el timestamp en vez de SNAPSHOT.

Curiosamente, descubrí que también forma parte del nombre una cosa que se llama ${dashClassifier}. Cuando uso rmi, uso un plugin que genera los stubs. Ese plugin genera dos jar. Uno de ellos, el normal de maven, por ejemplo proyecto-1.0.jar. El otro, con los stubs e interfaces para el cliente rmi, al que llama proyecto-1.0-client.jar. Pues bien, el dashClassifier es ese "-client" que se añade al nombre del fichero.

Más detalles en "Hacer un zip para distribuir".

Nov 04

maven, jar, assembly y snapshots (II)

 

Bueno, pues después de compilar el maven-assembly-plugin, lo he intentado en el trabajo y me has pasado las siguientes cosas:

Hago el mvn install. Me pide uno de los jar que mencioné en el post anterior. Le hago a ese jar el mvn install:install-file para instalarlo a mano. Sigo compilando y no me pide el segundo. Sin embargo, fallan los test de compilado.

Vuelvo a recompilar sin pasar los test   ( mvn -Dmaven.test.skip=true install ) y compilado, sin test. Me pongo a ejecutar el mvn assembly:assembly en un proyecto … y excepción, class not found de una de las clases del plugin

Después de pelearme, buscar ese class not found a ver de dónde es para poner la dependencia y desesperarme un rato gordo, se me ocurre hacer el mvn install:install-file del segundo jar mencionado en el post anterior. Cosa curiosa, aunque ese mismo jar me lo bajó maven de algún repositorio, y aunque el número de versión coincide, no es el mismo. Con este segundo jar ya compila todo pasando los test y no da excepción en el mvn assembly:assembly. Supongo que este tipo de cosas es lo que tiene el tirar de versiones beta-SNAPSHOT. De todas formas, también deja claro que no son demasiado cuidadosos con los jar que suben a internet, ya que con el mismo número de versión parece que puedes encontrar versiones distintas.

Y al final resulta que no funciona. Efectivamente, el mvn assembly:assembly te mete en el zip las versiones snapshots de los jar de los que dependes sin poner la fecha y manteniendo la palabra snapshot …. simpre y cuando en tu repositorio local hayas hecho un mvn install de ese snapshot con fecha posterior a la más moderna del repositorio de snapshot. O sea, que para que funcione, tienes que sacar el cvs de todos los proyectos snapshot de los que dependes y hacer mvn install de todos ellos y rezar porque nadie suba una snapshot al repositorio común en el entretanto.

En fin, estoy planteándome hacer un plugin que llame a assembly:directory. Este goal deja todos los ficheros en el target, desempaquetados. Luego, mi plugin, cambiará los ficheros-fecha.jar por fichero-snapshot.jar y hará el zip. Este bug lleva ya al menos un año en la página de bugs y todavía da la impresión de que no tiene una corrección seria.

Se me ocurrió mirar a mi los fuentes del plugin assembly a ver si podía hacer un arreglo…. pero de svn se baja la friolera de unos 6000 ficheros en los que hay 286 ficheros fuente java. No sé, creo que me da un poco de pereza….