Han pasado ya varios meses desde que se celebrase la segunda desconferencia. Pero lo importante es que durante estos días se ha estado organizando la tercera desconferencia.
¿Cuándo?
Miércoles, 22 de Julio de 2009 a las 19:00
¿Dónde?
BitRock S.L.
C/ Salado 11 – Local 15
41010 Sevilla
Spain
En esta ocasión, mi compañero y amigo Antonio Manuel Muñiz y yo, nos hemos ofrecido a preparar un pequeño taller sobre:
- Instalación y configuración de Apache Archiva
- Integración de mis proyectos maven con Apache Archiva
- Instalación y configuración de SONAR
- Integración de mis proyectos maven con SONAR
- Instalación y configuración de Apache Continuum
- Integración de mis proyectos maven con Apache Continuum
Evidentemente, es una propuesta, luego saldrán muchos otros temas.
Este es el nombre del seminario que he impartido recientemente. Un seminario de introducción en el que he hecho especial hincapié en aquellos detalles que hacen que los que se enfrantan por primera vez desistan con los primeros intentos.
Las transparencias están publicadas en el sitio web oficial de Maven, en el apartado recursos externos.
Configuré este plugin hace algunas semana en un proyecto y me encontré con un pequeño inconveniente que me hizo perder unas horas. Hoy me disponía a configurarlo en Opina y me he encontrado con otro inconveniente. Para que no se me olvide, y por si a alguien le sirve, dejo por aquí la configuración que estoy usando:
<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>buildnumber-maven-plugin</artifactid>
<version>1.0-beta-3</version>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<docheck>true</docheck>
<doupdate>false</doupdate>
</configuration>
</plugin>Para es funcione debemos tener correctamente configurado el repositorio SCM:
<scm>
<connection>scm:svn:http://svn.ebabel.info/repos/opina/branches/1.x</connection>
<developerconnection>scm:svn:http://svn.ebabel.info/repos/opina/branches/1.x</developerconnection>
<url>http://trac.ebabel.info/projects/opina/browser</url>
</scm>Que no se os olvide la entrada developerConnection, sino, no funcionará.
JSONView es una extensión de Firefox que he conocido hoy. Cuando uno trabaja con JSON, resulta de mucha utilidad poder visualizarlos en el navegador tabulados y coloreados, especialmente si se está desarrollando. Hasta ahora usaba SOAPUI, pero nunca viene mal tener a mano una extensión como esta.
Os animo a que visitéis el sitio web de Benjamin Hollis, el autor de esta extensión. Desde luego este chaval no pierde el tiempo, pero es que sus padres tampoco.
El otro día escribía una entrada en la que comentaba que me había encontrado con algunos problemas en la versión 2.0.10 de Maven trabajando en Windows. Os recomendaba no actualizar y esperar unos días a que se resolviesen algunos problemas con los plugins básicos. Pues bien, en esta ocasión os animo a que actualicéis vuestra instalación de Maven a la versión 2.1.0. La resolución de dependecias en paralelo es impresionante como mejora. Por lo hablar de la encriptación de las contraseñas.
Hace casi un año publicábamos la versión 0.2.0 de Tracquirement. Un plugin de Trac para reflejar en la wiki la información que se gestiona con la herramienta REM.
Hemos publicado una nueva release que los siguientes cambios:
Mejoras:
- Modificar matriz de trazabilidad
- Añadir enlaces en Casos de Uso
- Modelar elemento REM “Petición de Cambio”
Tareas:
- Compatibilizar con Trac 0.11
- Mostrar saltos de línea en los comentarios
Problemas:
- Problema al importar a Trac Casos de Uso Abstractos
- Error en la tranformación XSL para la trazabilidad reducida
El plugin está publicado bajo licencia GNU/GPL v.2, sólo tenéis que instalarlo y si algo no os gusta o no funciona, vosotros mismos podéis modificarlo.
Hace ya casi dos años que venimos definiendo nuestro ecosistema software. A continuación os muestro una ilustración con su arquitectura lógica:
Nuestro departamento de Desarrollo Software cuenta con un commiter en Sonar y un contributor en Apache Continuum.
¿Alguna duda?
Llevo todo el fin de semana usando JavaRebel y desde luego sólo tengo comentarios positivos para esta gran herramienta. En el sitio web oficial se refieren a ella como JVM plugin. En lugar de contaros qué proporciona, os invito a que veáis uno de los screencasts que tienen publicados.
Su instalación en mi entorno (Eclipse 3.4 + WTP, JDK 1.6 y Apache Tomcat) realmente sencilla y bien documentada. Desde luego son herramienta que cambian tu forma de trabajar. Ahora puedo lanzar la aplicación en modo debug y continuar desarrollando. Si necesito poner un punto de ruptura, lo pongo y estudio lo que pasa.
No os perdáis la animación que tienen publicada. Muy cachonda. A muchos les vendrá a la mente Hot Redeploy o JVM HotSwap, pero desde luego JavaRebel es otra historia.
Nuestro ecosistema software tiene cosas que mejorar, y ahí está lo bueno. Siempre hay ideas nuevas para mejorar el ecosistema y con ello refinar nuestra forma de trabajar. Hace algún tiempo publicábamos un simple plugin de TRAC que nos genera una página wiki con los requisitos que recogemos con la herramienta REM. Evidentemente era una primera aproximación que seguimos usando pero ha llegado el momento de avanzar, de ahí el título de esta entrada. A continuación algunas cosas que considero básicas para una herramienta de modelado de requisitos:
- Posibilidad de categorizar y etiquetar los requisitos.
- Posibilidad de reutilizar categorías y etiquetas entre proyectos.
- Reutilizar requisitos entre proyectos para evitar introducirlos múltiples veces
- Relacionar requisitos y definir en qué cosiste la relación (dependencia, ámbito, de interés, etc…)
- Representaciones gráficas (grafos) con los requisitos y sus relaciones
- Generación de artefactos documentales como entregables según perfiles
- Versionado de requisitos
- Posibilidad de que los requisitos tengan archivos adjuntos (documentos, audio y vídeo)
- Que para usarla sólo necesitemos un navegador web (y quizás ni conexión permanente si usamos algo como Google Gear)
- Que gestione correctamente una petición de cambio (quién la solicita, por qué, cómo, cuándo, etc.)
La lista se podría extender muchísimo. ¿Qué le pedirías tú?
Si alguien ha decidido actualizar Maven a su versión 2.0.10 y trabaja con Microsft Windows es probable que:
${project.build.directory}/classes
en la fase de procesado de recursos se transforme en:
C:\\nivel1\\nivel2\\target/classes
Con las versiones previas, el resultado hubiera sido:
C:\nivel1\nivel2\target/classes
Y os encontréis con algunos problemas. En nuestro caso hemos tenido problemas a la hora de que hibernate encuentre las clases del dominio con sus correspondientes anotaciones que necesita procesar. Con las versiones previas no había encontrado problemas, funcionaba tanto en linux como en windows.
Si tus ingredientes son: Eclipse, Web Tool Platform (WTP), m2eclipse y un proyecto modelado con maven y con varios módulos, quizás te has encontrado con el problema de que tu aplicación web no se lanza correctamente. Usando m2eclipse puedes importar tu proyecto maven a Eclipse creando un proyecto para cada uno de los módulos. Uno de ellos corresponderá con tu webapp, en mi caso opina-webapp.
Es probable que cuando lances tu aplicación con WTP (p.e. con Apache Tomcat) no se encuentren las librerías y salten excepciones ClassNotFound. Esto se debe a que el proyecto Eclipse que contiene tu aplicación web (webapp) no está incluyendo (en tiempo de ejecución) las librerías que tu has definido previamente como dependencias del proyecto. Para resolver esto, accedemos a las propiedades del proyecto (webapp), J2EE Modules Dependencies y seleccionados:
- Maven Dependencies (declaradas en el POM de este módulo, más las heredadas del POM padre).
- En mi caso además tuve que incluir:
- opina-model (modelo de datos)
- opina-dao (capa de acceso a datos)
Ahí queda esta nota por si a alguien le pasa. Supongo que si me hubiera leído documentación de m2eclipse esto no me hubiera pasado.
Recientemente se creó un hilo muy interesante y enriquecedor con el asunto “Maven y Eclipse: ¿Qué plugin usar?” en la lista de correo Ecosistemas Software.
José Manuel Beas es uno de los miembros más participativo del grupo, y prueba de ello es la traducción que ha realizado al español del tutorial Introduction to m2eclipse publicado en TheServerSide.
Enhorabuena JMBeas.
El pasado viernes 17 de octubre se celebró la segunda edición de la desconferencia del grupo Ecosistemas Software. Tal y como se adelantaba en la lista, la asistencia sería muy reducida, finalmente asistimos 5 personas (Paco, Viki, Darío, Felipe y el que escribe). Pero tuvo su lado positivo, esta desconferencia estuvo más acotada y dirigida que la anterior, y nos permitió participar mucho más.
A continuación cito algunos de los temas que se trataron (18:20h – 21:15h aprox.):
- Dado que teníamos una nueva incorporación, Felipe se presentó, nos contó donde trabajaba, a qué se dedicaba, cuál era su marco tecnológico, cómo era su ecosistema, etc…
- Estuvimos hablando sobre las distintas formas de distribuir nuestros aplicativos Java (war, jar, ear, aar, zip, con instaladores, etc) y yo estuve hablando sobre las ventaja de usar el plugin de maven assembly y como lo estoy usando en Opina y otros proyectos.
- Y por último sobre metodologías de trabajo y especialización en los equipos.
El segundo punto sí estaba previsto que lo tratásemos y así lo hicimos, sin embargo, y esto es lo bueno que tienen estas reuniones, salen temas realmente interesantes donde uno aprende mucho justificando sus ideas y escuchando a los demás.
Algunas cuestiones/ideas interesantes que me gustaría destacar:
- Felipe planteó que las aplicaciones web se podían distribuir en formato WAR y que los parámetros de configuración fueran proporcionados por el contenidor o servidor de aplicaciones a través de un recurso JNDI. Desde luego es una forma de que WAR sea válido en cualquier entorno de despliegue siempre y cuando se conozca el nombre del recurso que el administrador de sistemas asigne.
- El plugin Assembly es muy útil para diseñar los distribuibles clásicos: binario, fuentes, etc.
- Debemos organizar una desconferencia para hablar única y exclusivamente de metodologías y su vinculación con los ecosistemas software.
- Las desconferencias debemos guiarlas y centrar los temas que se van a tratar.
- Deberíamos elegir otras opciones que no sean los viernes.
Una foto (Darío, Viki, Paco, Felipe, Dani) en las oficinas de BitRock. Aprovecho para darles las gracias por su hospitalidad.
Tras el parón veraniego, el grupo de ecosistemas-software organiza “Desconferencia 02″. Como ya sucediera en su primera edición, esta nueva edición se volverá a celebrar en las instalaciones de BitRock.
La desconferencia se celebrará el próximo viernes 17 a las 18:00h:
BitRock S.L.
C/ Salado 11 – Local 15
41010 Sevilla
Spain
Para esta segunda edición voy a preparar algunas cositas sobre distribuibles en Java. Supongo que luego saldrán otros muchos temas. Se ruega a todos los que tengan pensado asistir confirmen su asistencia en la lista de correo. El espacio es limitado y además tengo que saber la gente que asistirá para comprar unos refrescos y algo para picar.
Supongo que con este título no estoy diciendo nada nuevo, sin embargo, el día a día nos dice otra cosa. Tan importante es desarrollar un software de calidad como su mantenimiento o explotación, de hecho, la experiencia nos dice que cuanto mejor hagamos el trabajo al principio más fácil y cómodamente abordaremos las etapas futuras.
Hablamos siempre de lo importante que es documentar, definir pruebas, refinar nuestras metodologías, definir buenas prácticas, especialización de los recursos y otras miles de cosas, pero todas ellas afectan -en gran medida- el equipo de desarrollo. ¿Y qué pasa con el resto de perfiles que interviene el ciclo de vida del software? ¿Qué pasa con los administradores de bases de datos y/o administradores de sistemas? ¿Cómo es nuestra relación con ellos? ¿Qué herramientas y procedimientos compartimos con ellos? Dentro del equipo de desarrollo hay “cosas” que comienzan a madurar y síntoma de ello es que a veces nos preguntamos, ¿Qué haríamos sin…?
En este post os hablaré concrétamente de Maven e Hibernate. En mi entorno profesional, estas dos herramientas son muy frecuentes y ambas tienen mucho que decir sobre la relación del equipo de desarrollo y el resto de perfiles que normalmente pertenecen al departamento de sistemas.
Desde hace tiempo la elaboración de libros blancos de buenas prácticas se ha convertido en una moda. En un próximo post daré mi opinión al respecto (“La parte oscura de los libros blancos”), pero por ahora sólo hago referencia porque son precisamente estos libros blancos los que indican/recomiendan/exigen el uso de herramientas como Maven e Hibernate. De qué vale que el equipo de desarrollo haga uso de este tipo de herramientas si luego nos encontramos con situaciones como estas:
- El despliegue del software lo lleva a cabo el propio departamento de sistemas y allí reina su propio libro blanco de buenas prácticas. Si nuestro proyecto está modelado con Maven, y contamos con un ecosistema software mínimamente definido, ¿Por qué tenemos que entregar un WAR con la aplicación que posteriormente descomprimen para configurar (base de datos, LDAP, SMTP, etc)? ¿Por qué los administradores de sistemas no usan Maven? Se podrían beneficiar de muchas cosas como por ejemplo los perfiles para los distintos entornos de despliegue, ejecución de pruebas que no pueden faltar y un largo etcetera. Creo que sería genial que tanto el equipo de desarrollo como el departamento de sistemas compartiesen el uso de Maven. Evidentemente, cada uno desde su perspectiva.
- ¿Por qué debemos entregar al DBA los script de creación de esquemas cuando de eso se encarga automáticamente hibernate? Recientemente preparamos para un proyecto un módulo con una interfaz de línea de comandos con varias finalidades, crear el esquema de base de datos, creación de sinónimos y carga inicial de información (tablas maestras). Con un módulo de estas características, el proceso de instalación como podéis imaginar queda resumido en ejecutar un par de sentencias desde la línea de comandos. Pues parece que esto no entraba dentro del libro blanco del departamento de sistemas.
Estos son sólo dos ejemplos que ponen de manifiesto que el equipo de desarrollo y el departamento de sistemas deben tener un único libro blanco de buenas prácticas y que existe una brecha que debe estrecharse cuanto antes.
En varias ocasiones he tenido oportunidad de charlar con responsables de departamentos de sistemas y una de sus preocupaciones es que los equipos de desarrollo les entregan software que una vez puesto en producción comienza a dar problemas. ¿Qué pasa en esta situación? Al igual que existen pruebas unitarias y funcionales, el departamento de sistemas puede disponer de pruebas de integración y sistemas que proporcionen unos indicadores para garantizar unos mínimos. No sería la primera vez que se pone en producción una aplicación con la configuración por defecto del pool C3P0 muy usado con Hibernate. Luego vienen las sorpresas. ¿Cómo comprueban los DBAs que las tablas de un sistema de información comienzan con un determinado prefijo? ¿Mirando los scripts? ¿No sería más fácil con un plugin de Maven?
Una vez más, la comunicación entre los distintos perfiles es fundamental para que el ciclo de vida de un software funcione.
Recent Comments