te cambio 3 de complejidad ciclomatica por una de error de consola que la tengo repe.
Al final los bugs son como los cromos, se cambian los "repes" y si no me gusta el mio, te lo cambio por el tuyo.
Mostrando las entradas con la etiqueta herramientas. Mostrar todas las entradas
Mostrando las entradas con la etiqueta herramientas. Mostrar todas las entradas
01 diciembre 2006
Bugzilla es divertido
Como comenté anteriormente, instalé bugzilla en el trabajo y lo hemos puesto en marcha. A la hora de repartir bugs, es entretenido en algunos casos ver cómo se lo toma la gente que resuelve las incidencias. Este es el comentario literal en uno de los bugs
Al final los bugs son como los cromos, se cambian los "repes" y si no me gusta el mio, te lo cambio por el tuyo.
Al final los bugs son como los cromos, se cambian los "repes" y si no me gusta el mio, te lo cambio por el tuyo.
23 noviembre 2006
syncback
Como siguiente paso a la compra del disco duro externo USB, me he bajado syncbak. Es un programa de copias de seguridad con un montón de opciones, entre que se incluyen unas opciones interesantes de sincronización de directorios.
Se le dicen los dos directorios, por supuesto en mi caso uno en el disco duro interno y otro en el externo, y se le dan las opciones de copia que se desea. Pueden ser cosas como esta:
Resumiendo, una cosa útil para tener copias de seguridad en dos discos, poder restaurar, etc.
Se le dicen los dos directorios, por supuesto en mi caso uno en el disco duro interno y otro en el externo, y se le dan las opciones de copia que se desea. Pueden ser cosas como esta:
- Lo que está en origen que no está en destino, copiarlo.
- Lo que está en destino que no está en origen, copiarlo o ignorarlo. Si elegimos copiarlo, cada vez que borremos un fichero en origen y ejecutemos el programa, se nos restaurará.
- Si el mismo fichero está modificado en ambos lados, quedarse con la versión más moderna.
- etc
Resumiendo, una cosa útil para tener copias de seguridad en dos discos, poder restaurar, etc.
08 noviembre 2006
Continuum
Continuum es otra herramienta de gratis similar al CruiseControl, de esas que están pendientes en un proyecto de si alguien mete algo en CVS (o subversion o lo que tengamos) y lo saca, lo compila y envía un correo avisando automáticamente.
Aunque no he hecho demasiadas pruebas, la he instalado para ver qué pinta tiene. Desde luego de aspecto me gusta más que CruiseControl.
En primer lugar la instalación es mucho más sencilla. En CruiseControl tienes que andar copiando y creando directorios a mano, con lo que te lees el manual para ver qué es lo que tienes que hacer, o no hace nada. Continuum es simplemente desempaquetar en un sitio y ejecutar.
Continuum crea un usuario administrador que desde el mismo navegador puede añadir nuevos proyectos, eliminarlos y demás. Los demás usuarios pueden ver los resultados de la compilación y hacer compilaciones. En CruiseControl toda la administración se hace desde un fichero .xml, en el que ahora tengo varios proyectos y en el que tengo varios bloques muy similares repetidos (una vez por proyecto). Unicamente cambia el directorio, el nombre del proyecto y poco más.
Sin embargo hay una cosa que no me ha gustado de Continuum. Si el proyecto es maven, Continuum pide que en el pom.xml esté la información necesaria para extraer el proyecto de CVS. Eso quiere decir que en el pom.xml hay que meter un CVSROOT válido, con usuario y todo. ¿Por qué el pom.xml que está en CVS y supuestamente es compartido por todos los programadores del proyecto debe llevar un usuario de uno de ellos dentro?.
Tampoco me ha funcionado a la primera el meter un proyecto maven con subproyectos. Como de momento tengo CruiseControl funcionando, tampoco me he preocupado de investigar cómo hacerlo y ese es el momento en que dejé las pruebas con Continuum.
Sin embargo, la buena pinta que tiene, me hace pensar que en cualquier momento volveré a él para probar.
Aunque no he hecho demasiadas pruebas, la he instalado para ver qué pinta tiene. Desde luego de aspecto me gusta más que CruiseControl.
En primer lugar la instalación es mucho más sencilla. En CruiseControl tienes que andar copiando y creando directorios a mano, con lo que te lees el manual para ver qué es lo que tienes que hacer, o no hace nada. Continuum es simplemente desempaquetar en un sitio y ejecutar.
Continuum crea un usuario administrador que desde el mismo navegador puede añadir nuevos proyectos, eliminarlos y demás. Los demás usuarios pueden ver los resultados de la compilación y hacer compilaciones. En CruiseControl toda la administración se hace desde un fichero .xml, en el que ahora tengo varios proyectos y en el que tengo varios bloques muy similares repetidos (una vez por proyecto). Unicamente cambia el directorio, el nombre del proyecto y poco más.
Sin embargo hay una cosa que no me ha gustado de Continuum. Si el proyecto es maven, Continuum pide que en el pom.xml esté la información necesaria para extraer el proyecto de CVS. Eso quiere decir que en el pom.xml hay que meter un CVSROOT válido, con usuario y todo. ¿Por qué el pom.xml que está en CVS y supuestamente es compartido por todos los programadores del proyecto debe llevar un usuario de uno de ellos dentro?.
Tampoco me ha funcionado a la primera el meter un proyecto maven con subproyectos. Como de momento tengo CruiseControl funcionando, tampoco me he preocupado de investigar cómo hacerlo y ese es el momento en que dejé las pruebas con Continuum.
Sin embargo, la buena pinta que tiene, me hace pensar que en cualquier momento volveré a él para probar.
05 noviembre 2006
Maven otra vez
Como últimamente ando muy metido en maven, qué menos que hacer un pequeño tutorial para iniciarse en maven.
He puesto lo mínimo para hacerse una idea y empezar con un pequeño proyecto java, pero se me han quedado muchas cosas en el tintero. La verdad es que cuanto más me meto en maven, más cosas descubro y más me gusta el que todos los proyetos se hagan igual, que el script de compilado no sea distinto en cada sitio, no tener que revisar los antiguos scripts de otros proyectos para que el script del nuevo proyecto se parezca.
Sin embargo, contar todo lo de maven, aparte de que yo no me lo sé, iba a ser demasiado extenso y rollo. Por eso prefiero un pequeño tutorial para enterarse de qué va y dar los primeros pasos, de forma que el que tenga interés tenga una base mínima para empezar a investigar.
He puesto lo mínimo para hacerse una idea y empezar con un pequeño proyecto java, pero se me han quedado muchas cosas en el tintero. La verdad es que cuanto más me meto en maven, más cosas descubro y más me gusta el que todos los proyetos se hagan igual, que el script de compilado no sea distinto en cada sitio, no tener que revisar los antiguos scripts de otros proyectos para que el script del nuevo proyecto se parezca.
Sin embargo, contar todo lo de maven, aparte de que yo no me lo sé, iba a ser demasiado extenso y rollo. Por eso prefiero un pequeño tutorial para enterarse de qué va y dar los primeros pasos, de forma que el que tenga interés tenga una base mínima para empezar a investigar.
01 noviembre 2006
Plugins de Maven
Sigo investigando con maven.
En FreeHep he encontrado un pequeño "filón" de plugins para maven.
Un tema que me preocupaba eran los objetos remotos de rmi en java. Para que funcionen, una vez compilados, hay que pasarles el compilador rmic. No tenía muy claro cómo se hacía esto con maven y creo que lo he encontrado. Hay un plugin de forma que poniendo en el pom.xml qué clases son las que necesitan pasar rmic, lo pasa. En la Chuwiki puedes ver qué es lo que hay que añadir al pom.xml para que maven pase el rmic a las clases que lo necesitan.
También había oido hablar de él, pero aquí lo he encontrado. Otro plugin de maven que desempaqueta las librerías externas que necesitamos (log4j.jar, ojdbc14.jar, etc) y empaqueta sus class junto con los nuestros en un único jar. De esta forma evitamos tener que distribuir nuestra aplicación con varios jars. En la Chuwiki puedes ver la configuración del plugin jarjar en el pom.xml.
Además de plugins, en FreeHep hay otras librerías java que pueden ser interesantes.
En FreeHep he encontrado un pequeño "filón" de plugins para maven.
Un tema que me preocupaba eran los objetos remotos de rmi en java. Para que funcionen, una vez compilados, hay que pasarles el compilador rmic. No tenía muy claro cómo se hacía esto con maven y creo que lo he encontrado. Hay un plugin de forma que poniendo en el pom.xml qué clases son las que necesitan pasar rmic, lo pasa. En la Chuwiki puedes ver qué es lo que hay que añadir al pom.xml para que maven pase el rmic a las clases que lo necesitan.
También había oido hablar de él, pero aquí lo he encontrado. Otro plugin de maven que desempaqueta las librerías externas que necesitamos (log4j.jar, ojdbc14.jar, etc) y empaqueta sus class junto con los nuestros en un único jar. De esta forma evitamos tener que distribuir nuestra aplicación con varios jars. En la Chuwiki puedes ver la configuración del plugin jarjar en el pom.xml.
Además de plugins, en FreeHep hay otras librerías java que pueden ser interesantes.
31 octubre 2006
No es oro todo lo que reluce
Como ya he comentado, llevo varios días jugando y poniendo en marcha varias herramientas que se supone ayudan a las costumbres de buena programación: Cruise Control, Maven, Bugzilla, etc.
En el caso concreto de Maven estoy contento y ahorra mucho trabajo. También hay muchas cosas que es capaz de hacer y que ayudan, pero....
Maven es una herramienta gratuita desarrollada en plan libre y con montones de plug-ins propios o de terceros también en plan libre. El problema que tiene todo esto es que la documentación es escasa y dispersa por internet. El caso es que cuando quiero hacer algo, me puedo pasar unas cuantas horas buceando por google en busca de una respuesta.
Por ejemplo, no me funciona el comando mvn site:stage, y por lo que veo en internet, simplemente no funciona bien.
Tampoco acabo de encontrar cómo trata maven con las clases Remote de rmi y el rmic. Veo que había un plugin para maven 1, pero todavía estoy buscando a ver si encuentro algo para maven 2.
El plugin de cobertura, que ya mencioné en alguna ocasión, se encuentra fácilmente en la página de maven para maven 1, pero no para maven 2. Hay que irse a la página oficial de cobertura para desde ahí llegar el plugin para maven 2.
Algo similar me pasa con eclipse. Existen muchos plugins de terceros, pero algunos dan problemas o van retrasados respecto a las versiones nuevas. Me acabo de bajar eclipse 3.2 y el plugin de jalopy, para formatear código, me da problemas, a veces va, a veces no.
De todas formas, sigue mereciendo la pena meterse en estas cosas, ahorran mucho trabajo y es mejor pelearse o no disponer de alguna de estas funcionalidades secundarias que andar haciendo todo desde cero y a pelo.
En el caso concreto de Maven estoy contento y ahorra mucho trabajo. También hay muchas cosas que es capaz de hacer y que ayudan, pero....
Maven es una herramienta gratuita desarrollada en plan libre y con montones de plug-ins propios o de terceros también en plan libre. El problema que tiene todo esto es que la documentación es escasa y dispersa por internet. El caso es que cuando quiero hacer algo, me puedo pasar unas cuantas horas buceando por google en busca de una respuesta.
Por ejemplo, no me funciona el comando mvn site:stage, y por lo que veo en internet, simplemente no funciona bien.
Tampoco acabo de encontrar cómo trata maven con las clases Remote de rmi y el rmic. Veo que había un plugin para maven 1, pero todavía estoy buscando a ver si encuentro algo para maven 2.
El plugin de cobertura, que ya mencioné en alguna ocasión, se encuentra fácilmente en la página de maven para maven 1, pero no para maven 2. Hay que irse a la página oficial de cobertura para desde ahí llegar el plugin para maven 2.
Algo similar me pasa con eclipse. Existen muchos plugins de terceros, pero algunos dan problemas o van retrasados respecto a las versiones nuevas. Me acabo de bajar eclipse 3.2 y el plugin de jalopy, para formatear código, me da problemas, a veces va, a veces no.
De todas formas, sigue mereciendo la pena meterse en estas cosas, ahorran mucho trabajo y es mejor pelearse o no disponer de alguna de estas funcionalidades secundarias que andar haciendo todo desde cero y a pelo.
25 octubre 2006
Cobertura Plugin Usage
Comenté de un plugin para maven que permite sacar un informe en el que sale qué trozos de código se han recorrido en los test unitarios y que trozos no se han recorrido.
Aquí está el cómo configurar maven para que coja ese pluging
Cobertura Plugin Usage: " org.codehaus.mojo cobertura-maven-plugin "
Aquí está el cómo configurar maven para que coja ese pluging
Cobertura Plugin Usage: "
Una sesión de herramientas
Ultimamente me he instalado casi todas las herramientas instalables. Lo siguiente viene a ser más o menos un día de trabajo entre herramientas.
Cuando me pongo a trabajar, que no suele coincidir con el momento en el que llego al trabajo, abro el eclipse. Un plugin de eclipse, llamado mylar, se va a revisar nuestra página de bugzilla y me trae a eclipse todos los errores que alguien ha levantado en el proyecto. Simultánemente, veo en el thunderbird que bugzilla me ha enviado correos con los mismos bugs que se han levantado y mylar me ha traido a eclipse.
Reviso los errores y elijo uno para ponerme a trabajar. Con mylar lo marco como activo y en ese momento se pone en marcha automáticamente un cronómetro. Me dedico a revisar ficheros java, depurar y así hasta que encuentro el error. Desactivo (paro el cronómetro) del bug a la hora del café, cuando me interrumpen, etc y vuelvo a activarlo cuando sigo.
Cuando encuentro el error y lo corrijo, le digo a mylar que meta en cvs todos los ficheros que he tocado. Automáticamente pone un comentario en CVS del estilo "progresando en el bug ###". Añado al comentario algo más específico de lo que he hecho.
Le digo también a mylar que adjunte al bug de bugzilla mi contexto de eclipse. Esto guarda en bugzilla junto al bug un fichero xml en el que se dice qué ficheros he tocado para corregir el bug. Cualquier otro que tenga el mismo proyecto en eclipse con mylar, puede ver qué ficheros he tocado.
Finalmente, con mylar en eclipse marco el bug como "resolved fixed" o como "no me da la gana corregirlo (wontfix que diría bugzilla)" y mylar se encarga de tocar la página de bugzilla. Este último envía un correo a la persona que ha levantado el bug. Me autocomplazco un rato mirando con mylar el histórico de bugs que he resuelto en los últimos días y viendo cuánto tiempo he tardado en cada uno de ellos. Otras veces hago lo mismo, pero tirándome de los pelos viendo que un pueñetero bug lleva un par de días abierto y todavía no tengo ni idea de por donde van los tiros.
Un rato después, CruiseControl ve que he tocado ficheros en CVS del proyecto, así que automáticamente saca dichos ficheros y compila el proyecto entero desde cero. Cuando termina, me envía un correo diciéndome si los fuentes que he metido en CVS compilan o no correctamente.
Y todo herramientas gratuitas.
Cuando me pongo a trabajar, que no suele coincidir con el momento en el que llego al trabajo, abro el eclipse. Un plugin de eclipse, llamado mylar, se va a revisar nuestra página de bugzilla y me trae a eclipse todos los errores que alguien ha levantado en el proyecto. Simultánemente, veo en el thunderbird que bugzilla me ha enviado correos con los mismos bugs que se han levantado y mylar me ha traido a eclipse.
Reviso los errores y elijo uno para ponerme a trabajar. Con mylar lo marco como activo y en ese momento se pone en marcha automáticamente un cronómetro. Me dedico a revisar ficheros java, depurar y así hasta que encuentro el error. Desactivo (paro el cronómetro) del bug a la hora del café, cuando me interrumpen, etc y vuelvo a activarlo cuando sigo.
Cuando encuentro el error y lo corrijo, le digo a mylar que meta en cvs todos los ficheros que he tocado. Automáticamente pone un comentario en CVS del estilo "progresando en el bug ###". Añado al comentario algo más específico de lo que he hecho.
Le digo también a mylar que adjunte al bug de bugzilla mi contexto de eclipse. Esto guarda en bugzilla junto al bug un fichero xml en el que se dice qué ficheros he tocado para corregir el bug. Cualquier otro que tenga el mismo proyecto en eclipse con mylar, puede ver qué ficheros he tocado.
Finalmente, con mylar en eclipse marco el bug como "resolved fixed" o como "no me da la gana corregirlo (wontfix que diría bugzilla)" y mylar se encarga de tocar la página de bugzilla. Este último envía un correo a la persona que ha levantado el bug. Me autocomplazco un rato mirando con mylar el histórico de bugs que he resuelto en los últimos días y viendo cuánto tiempo he tardado en cada uno de ellos. Otras veces hago lo mismo, pero tirándome de los pelos viendo que un pueñetero bug lleva un par de días abierto y todavía no tengo ni idea de por donde van los tiros.
Un rato después, CruiseControl ve que he tocado ficheros en CVS del proyecto, así que automáticamente saca dichos ficheros y compila el proyecto entero desde cero. Cuando termina, me envía un correo diciéndome si los fuentes que he metido en CVS compilan o no correctamente.
Y todo herramientas gratuitas.
24 octubre 2006
jakarta commons io
Acabo de enterarme de otro proyecto de jakarta, el commons io, en el que hay montones de utilidades para java para el manejo de entradas/salidas. Entre otras, está por ejemplo la posibilidad de ver el espacio libre en disco duro, copia de ficheros, manejo de nombres de ficheros, manejo de ficheros de texto a base de leer líneas, etc, etc.
Aparte de la posible utilidad de todo esto, lo que más me llama la atención, como ando metido con maven y con sus informes sobre el proyecto, son los informes maven que han metido en su documentación.
El de checkstyle no lo conocía, pero parece que revisa las cosas típicas de estilo de java, como poner nombres de clases con mayúscula primero y minúscula después, métodos empiezan con minúscula, etc.
Me ha llamado especialmente la atención el de cobertura. Básicamente nos por qué partes de código han pasado nuestros test de JUnit y qué partes no han tocado. De esta forma sabemos lo completos que son nuestros test. Además, pinchando en las clases del informe, acabamos llegando al listado del fuente, en el que se marcan en verde y rojo las líneas por las que pasa o no pasa el test.
También me ha llamado la atención JDiff, que nos muestra las diferencias entre dos APIS de nuestro proyecto en distintas versiones, indicándonos qué clases se han añadido, borrado o modificado de una versión a otra, al igual que los métodos. Es curioso ver, por ejemplo, el JDiff aplicado a las versiones 1.4.2 y 1.5.0 de java.
Es increible la cantidad de cosas que hace la gente por el mundo, y lo más increible, gratis.
Aparte de la posible utilidad de todo esto, lo que más me llama la atención, como ando metido con maven y con sus informes sobre el proyecto, son los informes maven que han metido en su documentación.
El de checkstyle no lo conocía, pero parece que revisa las cosas típicas de estilo de java, como poner nombres de clases con mayúscula primero y minúscula después, métodos empiezan con minúscula, etc.
Me ha llamado especialmente la atención el de cobertura. Básicamente nos por qué partes de código han pasado nuestros test de JUnit y qué partes no han tocado. De esta forma sabemos lo completos que son nuestros test. Además, pinchando en las clases del informe, acabamos llegando al listado del fuente, en el que se marcan en verde y rojo las líneas por las que pasa o no pasa el test.
También me ha llamado la atención JDiff, que nos muestra las diferencias entre dos APIS de nuestro proyecto en distintas versiones, indicándonos qué clases se han añadido, borrado o modificado de una versión a otra, al igual que los métodos. Es curioso ver, por ejemplo, el JDiff aplicado a las versiones 1.4.2 y 1.5.0 de java.
Es increible la cantidad de cosas que hace la gente por el mundo, y lo más increible, gratis.
19 octubre 2006
Dreamweaver
La verdad es que soy un poco "rupestre".
Empecé con la informática allá en los tiempos del sinclair zx81 (anterior al Spectrum). Luego seguí con los ordenadores de fósforo verde y aprendí a escribir a máquina antes de usarlos. En el trabajo caí en un cutre-empresa que trabajaba con estaciones de trabajo unix y no se gastaban un duro en entornos de desarrollo, así que pasé muchos años programando con el vi (uno de los mejores editores del mundo), pero que está muy orientado a comandos desde teclado.
Todo esto hace que sea un usuario muy orientado a usar el teclado y que el ratón muchas veces sea más una molestia, algo que retarda el hacer las tareas, más que una ayuda.
Por ello quizás, siempre me han gustado los programas simples, sin demasiadas ventanas y con posibilidad de hacer las cosas con teclas en vez de ir con el ratón a un menú y navegar entre submenus y submenus de submenus.
Hasta no hace mucho, para mi página web, usaba el netscape composer. Una herramienta gratuita y simple, pero que permitía escribir fácilmente y tocar directamente el código html. Para mí siempre ha sido una de las herramientas más cómodas para trabajar con html. Probé por encima varias más avanzadas, como la de microsoft que venía con visual studio 6 (no recuerdo el nombre), dreamveaver, etc. Todas me parecieron muy engorrosas. Para hacer una simple página web pedían cosas como montar un sitio web, definir un montón de parámetros, si te descuidas te lo suben al servidor web, etc.
Sin embargo, hace poco me puse Dreamveaver y me puse a mirarlo con un poco más de detalle. Sigue pareciendome una herramienta engorrosa. Nada más abrirla sale un "ventanón" con montones de subventanas que no sé para qué sirven (ni las he usado en el tiempo que llevo) y el espacio de trabajo (para escribir tu página) es más bien reducido.
Pero he visto que tiene pequeñas maravillas. Todo lo que echaba en falta en una herramienta simple como netscape composer, lo tiene esta herramienta. Las cosas más útiles que he encontrado son:
Empecé con la informática allá en los tiempos del sinclair zx81 (anterior al Spectrum). Luego seguí con los ordenadores de fósforo verde y aprendí a escribir a máquina antes de usarlos. En el trabajo caí en un cutre-empresa que trabajaba con estaciones de trabajo unix y no se gastaban un duro en entornos de desarrollo, así que pasé muchos años programando con el vi (uno de los mejores editores del mundo), pero que está muy orientado a comandos desde teclado.
Todo esto hace que sea un usuario muy orientado a usar el teclado y que el ratón muchas veces sea más una molestia, algo que retarda el hacer las tareas, más que una ayuda.
Por ello quizás, siempre me han gustado los programas simples, sin demasiadas ventanas y con posibilidad de hacer las cosas con teclas en vez de ir con el ratón a un menú y navegar entre submenus y submenus de submenus.
Hasta no hace mucho, para mi página web, usaba el netscape composer. Una herramienta gratuita y simple, pero que permitía escribir fácilmente y tocar directamente el código html. Para mí siempre ha sido una de las herramientas más cómodas para trabajar con html. Probé por encima varias más avanzadas, como la de microsoft que venía con visual studio 6 (no recuerdo el nombre), dreamveaver, etc. Todas me parecieron muy engorrosas. Para hacer una simple página web pedían cosas como montar un sitio web, definir un montón de parámetros, si te descuidas te lo suben al servidor web, etc.
Sin embargo, hace poco me puse Dreamveaver y me puse a mirarlo con un poco más de detalle. Sigue pareciendome una herramienta engorrosa. Nada más abrirla sale un "ventanón" con montones de subventanas que no sé para qué sirven (ni las he usado en el tiempo que llevo) y el espacio de trabajo (para escribir tu página) es más bien reducido.
Pero he visto que tiene pequeñas maravillas. Todo lo que echaba en falta en una herramienta simple como netscape composer, lo tiene esta herramienta. Las cosas más útiles que he encontrado son:
- Revisa todos los vínculos de tu sitio, indicándote si hay alguno erroneo. Para un sitio como el mio tarda un rato, pero lo hace
- Si cambias el nombre de una página o la mueves de directorio, arregla todos los links en las demás. Con netscape composer ese era el principal motivo para NO mover las cosas. netscape no hace eso. ¡¡La de horas que me he pasado cambiando y revisando links!!
- Y lo mejor de todo, el tema de plantillas. Puedes hacer un esqueleto de página web con huecos para rellenar más adelante. Ese esqueleto se graba como plantilla. Cuando luego quieras crear la página, le dices que es según la plantilla y llisto. Te sale la página con su formato y los huecos para que pongas el texto. Si cambias la plantilla, se cambia automáticamente el formato de todas las páginas. ¡¡La de horas que me he pasado cambiando el aspecto de las páginas una a una!!
17 octubre 2006
Jasper Report
Con un ejemplo tonto que me hizo un compañero de trabajo y el correo que me envió John, de Colombia, he hecho un guia-burros de Jasper Report. No es más que una especie de "Hola mundo", pero por algo se empieza.
Espero que algún Rodrigo de riolambre, que creo que un poquito de esto sabe, colabore y meta más cosas en la Chuwiki esa. Si no, cualquier otro que sepa un poco del tema está invitado a tocarlo.
Espero que algún Rodrigo de riolambre, que creo que un poquito de esto sabe, colabore y meta más cosas en la Chuwiki esa. Si no, cualquier otro que sepa un poco del tema está invitado a tocarlo.
12 octubre 2006
Ares
En su día probé un poco con e-mule y con Kazaa.
El primero me dejaba el ordenador colgado. Después de mucho mirar, buscar por los foros y demás vi que no era el único al que le pasaba y la conclusión a la que llegué al final es que era algún tipo de incompatibilidad con mi tarjeta de red, una D-Link Airplus DWL-520+
El Kazaa no tenía ese problema, al menos con tanta frecuencia, aunque sí me dejaba colgado el ordenador de pascua en ramos.
Ahora, aparte de que tengo otra tarjeta de red (no wi-fi), acabo de hacer unas pruebas con Ares. Me ha dejado maravillado este programa, comparado con los otros dos. No hay tantísimos ficheros para descargar como había en e-mule, pero es miles de veces más rápido bajando cosas. Aparentemente no lleva ningún tipo de ad-ware como llevaba kazaa y no hay que andar configurando cosas raras como en e-mule. En fin, un programa sencillo de usar y muy veloz descargando.
El primero me dejaba el ordenador colgado. Después de mucho mirar, buscar por los foros y demás vi que no era el único al que le pasaba y la conclusión a la que llegué al final es que era algún tipo de incompatibilidad con mi tarjeta de red, una D-Link Airplus DWL-520+
El Kazaa no tenía ese problema, al menos con tanta frecuencia, aunque sí me dejaba colgado el ordenador de pascua en ramos.
Ahora, aparte de que tengo otra tarjeta de red (no wi-fi), acabo de hacer unas pruebas con Ares. Me ha dejado maravillado este programa, comparado con los otros dos. No hay tantísimos ficheros para descargar como había en e-mule, pero es miles de veces más rápido bajando cosas. Aparentemente no lleva ningún tipo de ad-ware como llevaba kazaa y no hay que andar configurando cosas raras como en e-mule. En fin, un programa sencillo de usar y muy veloz descargando.
04 octubre 2006
Cruise Control
Bueno, ya he estado jugando más y tengo más claro lo de Cruise Control.
Una vez instalado y configurado Cruise Control, tiene asignada un area de trabajo con los fuentes de los proyectos. Normalmente está dormido y espera cierto tiempo (el que le digamos en la configuración) para despertar. Cuando despierta, mira los proyectos (a través de CVS o el sistema de control de versiones que usemos) para ver si alguien ha cambiado algún fichero fuente. Si ve que ha habido cambios, puede o no traerse los nuevos fuentes (según le indiquemos en la configuración) y llama al script de compilado del proyecto. Se lleva bien con maven y con ant, por lo que nos vale perfectamente con el pom.xml (de maven) o el build.xml (de ant).
Si la compilación es correcta, en http://localhost:8080 se puede ver que todo ha ido bien. Si falla, se ve el fallo en el mismo sitio y además puede incluso enviar un correo a la persona que indiquemos.
Es curioso, pero en esa página de localhost se ve si ha ido bien o no la compilación y los fuentes que se han tocado y provocado la compilación.
En fin, que lo tengo arrancado y en marcha con un par de proyectos y parece que funciona bien. En cuanto alguien mete algo en CVS que no compila, la herramienta se "chiva" al jefe de proyecto ;-).
Una vez instalado y configurado Cruise Control, tiene asignada un area de trabajo con los fuentes de los proyectos. Normalmente está dormido y espera cierto tiempo (el que le digamos en la configuración) para despertar. Cuando despierta, mira los proyectos (a través de CVS o el sistema de control de versiones que usemos) para ver si alguien ha cambiado algún fichero fuente. Si ve que ha habido cambios, puede o no traerse los nuevos fuentes (según le indiquemos en la configuración) y llama al script de compilado del proyecto. Se lleva bien con maven y con ant, por lo que nos vale perfectamente con el pom.xml (de maven) o el build.xml (de ant).
Si la compilación es correcta, en http://localhost:8080 se puede ver que todo ha ido bien. Si falla, se ve el fallo en el mismo sitio y además puede incluso enviar un correo a la persona que indiquemos.
Es curioso, pero en esa página de localhost se ve si ha ido bien o no la compilación y los fuentes que se han tocado y provocado la compilación.
En fin, que lo tengo arrancado y en marcha con un par de proyectos y parece que funciona bien. En cuanto alguien mete algo en CVS que no compila, la herramienta se "chiva" al jefe de proyecto ;-).
03 octubre 2006
Cruise Control
Siguiendo, en el trabajo, con la manía de probar nuevas herramientas que se supone que nos pueden ayudar, ayer me bajé e instalé Cruise Control.
Es una herramienta, gratis por supesto para que se la pueda permitir mi cutre-empresa, que supuestamente compila los proyectos desde cero todos los días (o cada cierto tiempo que le indiquemos). Si el proyecto tiene test de JUnit o similar, también los ejecuta. Si algo falla, se puede configurar para que envíe un correo a la gente implicada, responsables del proyecto o lo que sea.
La instalación para windows es fácil, simplemente se ejecuta el instalable y ya está. El tema de la configuración me ha parecido más complejo.
En primer lugar, los resultados del compilado parece que se pueden ver en formato web con jsp. Eso parece indicar que es necesario instalar un Tomcat o similar, pero no. Cruise Control viene con una cosa (creo que se llama Jetty) que hace las veces.
La documentación que da parece que está un poco obsoleta para la versión más moderna. En los ficheros de configuración de ejemplo que copie, tuve que descomentar algunas lineas que venían comentadas y comentar (eliminar) otras que estaban sin comentar. En fin, que a base de probar y de intuición "femenina" conseguí, en unos minutos que me compilara un proyecto y después de varias horas, ver los resultados en un navegador.
Para que Cruise Control pueda compilar el proyecto, es necesario que haya un build.xml de ant o un pom.xml de maven que sea capaz de compilar el proyecto, puesto que Cruise Control lo unico que hace es llamar a uno de esos y recoger los resultados. Cruise Control también es capaz de detectar si ha cambiado algún fuente en cvs de forma que hace o no la compilación según lo considera necesario.
Me queda configurar lo de que envíe correos.
Es una herramienta, gratis por supesto para que se la pueda permitir mi cutre-empresa, que supuestamente compila los proyectos desde cero todos los días (o cada cierto tiempo que le indiquemos). Si el proyecto tiene test de JUnit o similar, también los ejecuta. Si algo falla, se puede configurar para que envíe un correo a la gente implicada, responsables del proyecto o lo que sea.
La instalación para windows es fácil, simplemente se ejecuta el instalable y ya está. El tema de la configuración me ha parecido más complejo.
En primer lugar, los resultados del compilado parece que se pueden ver en formato web con jsp. Eso parece indicar que es necesario instalar un Tomcat o similar, pero no. Cruise Control viene con una cosa (creo que se llama Jetty) que hace las veces.
La documentación que da parece que está un poco obsoleta para la versión más moderna. En los ficheros de configuración de ejemplo que copie, tuve que descomentar algunas lineas que venían comentadas y comentar (eliminar) otras que estaban sin comentar. En fin, que a base de probar y de intuición "femenina" conseguí, en unos minutos que me compilara un proyecto y después de varias horas, ver los resultados en un navegador.
Para que Cruise Control pueda compilar el proyecto, es necesario que haya un build.xml de ant o un pom.xml de maven que sea capaz de compilar el proyecto, puesto que Cruise Control lo unico que hace es llamar a uno de esos y recoger los resultados. Cruise Control también es capaz de detectar si ha cambiado algún fuente en cvs de forma que hace o no la compilación según lo considera necesario.
Me queda configurar lo de que envíe correos.
21 septiembre 2006
Nuevamente Mylar
Esto es algo que me ha comentado un compañero de trabajo, pero que no he probado.
En un post anterior comenté sobre Mylar, un plug-in de eclipse que hace de programador de tareas y que permite recoger bugs desde bugzilla o similar.
Un compañero me ha comentado una nueva característica que parece muy útil de Mylar. Si un programador de un proyecto resuelve una incidencia con eclipse y mylar, cogiéndola de bugzilla, cuando termina puede marcarla como terminada desde el mismo eclipse-mylar. Mylar automáticamente añade un adjunto (attachment) propio a la incidencia. Ese adjunto no es más que un fichero propio de Mylar en el que se indican, de alguna forma, qué ficheros se han tocado para resolver esa incidencia y que son los que en eclipse se ven si filtramos con Mylar (como comenté en el post anterior).
Si ahora ese compañero no está (ha encontrado un trabajo mejor en otro sitio, que suele ser lo habitual) y se reabre la incidencia (no había terminado de arreglarla correctamente, que también suele ser lo habitual), lo normal es que le caiga a otro pringado que todavía no ha encontrado trabajo en otro sitio.
Con eclipse-mylar es muy fácil. El nuevo pringado abre eclipse, se conecta a bugzilla, se trae la incidencia y ¡¡maravilla!!, eclipse-mylar importa el fichero adjunto y le filtra automáticamente los ficheros java mostrándole sólo aquellos que se tocaron para resolver la incidencia. Este nuevo pringado no debe perder un par de horas rebuscando entre los tres mil ficheros java del proyecto grande cuáles demonios son los que tienen que ver con el fallo.
Todavía no me he instalado Mylar. ¿Por qué?. El problema que tengo es que como instalo y desinstalo miles de plug-ins para probar en eclipse, ahora intento instalar mylar me da un error de eclipse y no se instala. Cualquier día tendré que reinstalar eclipse desde cero y poner el mylar este, que parece una pequeña maravilla para proyectos grandes.
En un post anterior comenté sobre Mylar, un plug-in de eclipse que hace de programador de tareas y que permite recoger bugs desde bugzilla o similar.
Un compañero me ha comentado una nueva característica que parece muy útil de Mylar. Si un programador de un proyecto resuelve una incidencia con eclipse y mylar, cogiéndola de bugzilla, cuando termina puede marcarla como terminada desde el mismo eclipse-mylar. Mylar automáticamente añade un adjunto (attachment) propio a la incidencia. Ese adjunto no es más que un fichero propio de Mylar en el que se indican, de alguna forma, qué ficheros se han tocado para resolver esa incidencia y que son los que en eclipse se ven si filtramos con Mylar (como comenté en el post anterior).
Si ahora ese compañero no está (ha encontrado un trabajo mejor en otro sitio, que suele ser lo habitual) y se reabre la incidencia (no había terminado de arreglarla correctamente, que también suele ser lo habitual), lo normal es que le caiga a otro pringado que todavía no ha encontrado trabajo en otro sitio.
Con eclipse-mylar es muy fácil. El nuevo pringado abre eclipse, se conecta a bugzilla, se trae la incidencia y ¡¡maravilla!!, eclipse-mylar importa el fichero adjunto y le filtra automáticamente los ficheros java mostrándole sólo aquellos que se tocaron para resolver la incidencia. Este nuevo pringado no debe perder un par de horas rebuscando entre los tres mil ficheros java del proyecto grande cuáles demonios son los que tienen que ver con el fallo.
Todavía no me he instalado Mylar. ¿Por qué?. El problema que tengo es que como instalo y desinstalo miles de plug-ins para probar en eclipse, ahora intento instalar mylar me da un error de eclipse y no se instala. Cualquier día tendré que reinstalar eclipse desde cero y poner el mylar este, que parece una pequeña maravilla para proyectos grandes.
15 septiembre 2006
Primeros días con Bugzilla
Como comenté en un post anterior, acabo de instalar Bugzilla en el trabajo, en mi propio PC y para uso general.
La herramienta en sí está muy bien. Es cómoda de usar, no requiere demasiado aprendizaje y funciona muy bien. Echo de menos alguna cosilla, como la posibilidad de poner más campos para exportar en el formato CSV (en concreto la descripción larga del bug). También el poder restringir permisos a los usuarios, como el de abrir o cerrar incidencias, etc. En principio cualquier usuario que puede modificar incidencias puede modificar CUALQUIER campo de la incidencia. Sería quizás interesante que sólo pudieran cerrar incidencias o cambirar prioridades los responsables de las pruebas. De todas formas, nada grave, siempre y cuando se establezcan unas normas generales y la gente del proyecto sea más o menos responsable. Y lo son, teniendo en cuenta que todo lo que hagan queda registrado con su usuario.
De todas formas, quizá todo estos temas de permisos sean posibles y simplemente todavía no he encontrado dónde. Hay cosas, por ejemplo, como que cualquiera puede dar de alta un bug, pero queda en estado "sin confirmar", hasta que un usuario con permiso de confirmación lo confirme.
Me ha llamado la atención la buena acogida que ha tenido entre la gente del trabajo. Se lo he enseñado primero a los más "allegados", pero rápidamente se ha corrido la voz e incluso se han registrado como usuarios algunos "jefes". Por supuesto, ellos le han encontrado otras utilidades a la herramienta. La más pérfida es ver si trabajamos o no y vamos resolviendo bugs. Encima, como todo queda registrado con quién hace qué, pueden incluso saber quién resuelve más y quién menos.
La otra utilidad que le han visto los jefes es el de enseñársela a los clientes. Siempre han pedido que tengamos una herramienta de gestión de bugs interna. Siempre hemos dicho que la teníamos, pero ahora es la primera vez que podemos enseñar algo parecido. Creo que incluso lo quieren enseñar en las auditorías. También para preparar informes rápidamente que entregar a los clientes sobre el estado de nuestras incidencias internas.
La herramienta en sí está muy bien. Es cómoda de usar, no requiere demasiado aprendizaje y funciona muy bien. Echo de menos alguna cosilla, como la posibilidad de poner más campos para exportar en el formato CSV (en concreto la descripción larga del bug). También el poder restringir permisos a los usuarios, como el de abrir o cerrar incidencias, etc. En principio cualquier usuario que puede modificar incidencias puede modificar CUALQUIER campo de la incidencia. Sería quizás interesante que sólo pudieran cerrar incidencias o cambirar prioridades los responsables de las pruebas. De todas formas, nada grave, siempre y cuando se establezcan unas normas generales y la gente del proyecto sea más o menos responsable. Y lo son, teniendo en cuenta que todo lo que hagan queda registrado con su usuario.
De todas formas, quizá todo estos temas de permisos sean posibles y simplemente todavía no he encontrado dónde. Hay cosas, por ejemplo, como que cualquiera puede dar de alta un bug, pero queda en estado "sin confirmar", hasta que un usuario con permiso de confirmación lo confirme.
Me ha llamado la atención la buena acogida que ha tenido entre la gente del trabajo. Se lo he enseñado primero a los más "allegados", pero rápidamente se ha corrido la voz e incluso se han registrado como usuarios algunos "jefes". Por supuesto, ellos le han encontrado otras utilidades a la herramienta. La más pérfida es ver si trabajamos o no y vamos resolviendo bugs. Encima, como todo queda registrado con quién hace qué, pueden incluso saber quién resuelve más y quién menos.
La otra utilidad que le han visto los jefes es el de enseñársela a los clientes. Siempre han pedido que tengamos una herramienta de gestión de bugs interna. Siempre hemos dicho que la teníamos, pero ahora es la primera vez que podemos enseñar algo parecido. Creo que incluso lo quieren enseñar en las auditorías. También para preparar informes rápidamente que entregar a los clientes sobre el estado de nuestras incidencias internas.
12 septiembre 2006
Otros lenguajes que compilan a bytecodes
En lenguajes que compilan a bytecode hay una noticia que me ha llamado la atención. Por lo visto hay más lenguajes de programación, aparte de java, que compilan y generan bytecodes de java, de forma que se pueden ejecutar en una máquina virtual java. No deja de ser una opción interesante quizás para ciertas tareas, que resulten más fáciles de desarrollar en uno de estos lenguajes que en java.
¿Se podrán mezclar los bytecodes de un lenguaje con los de otro?. Creo que sería una prueba interesante de hacer.
¿Se podrán mezclar los bytecodes de un lenguaje con los de otro?. Creo que sería una prueba interesante de hacer.
01 septiembre 2006
Mylar
Un compañero de trabajo, aprovechando que he puesto bugzilla, a hecho unas pruebas con Mylar.
Mylar es un plug-in para eclipse que permite gestionar nuestras tareas, poniendo tiempos de inicio, de fin, avisos, etc, etc. Vaya, un planificador de tareas integrado en eclipse.
Una vez creada una tarea, cuando trabajamos en ella, hay dos cosas interesantes que hace Mylar. Por un lado lleva el tiempo que estamos trabajando en esta tarea. Por otra, y lo que es realmente interesante, es que podemos "filtrar" las clases que vemos en nuestro arbol de clases de forma que sólo se ven las que estamos usando. Esto es muy interesante en proyectos grandes. Cuando dentro del proyecto grande, de miles de clases, trabajamos en un tema concreto, sólo veremos un grupo reducido de clases, las que nos han ido haciendo falta. Se facilita un montón el tema de navegar entre clases.
Mylar se integra además con bugzilla, trac y jira. Cuando creamos una nueva tarea, podemos poner la url de un bug que esté registrado por ejemplo, en bugzilla. Al hacerlo, el nombre de la tarea se pondrá automáticamente como el nombre del bug y además, permite abrir en una pestaña de eclipse un navegador en el que veremos el bug de bugzilla y podremos modificarlo.
La parte de bugzilla es curiosa, pero no sé si merece la pena abrir una tarea por cada bug, sobre todo en proyectos grandes en los que hay miles y miles de bugs. Quizás sea interesante si la empresa (o uno personalmente) lleva una estadística del tiempo que tarda en resolver cada bug. Al crear una tarea por bug, Mylar lleva el tiempo que trabajas en esa tarea, así que cuando terminas de arreglar el bug, tienes el tiempo que has tardado en resolverlo.
De todas formas, sólo por el filtro de clases en proyectos grandes, Mylar merece la pena.
Mylar es un plug-in para eclipse que permite gestionar nuestras tareas, poniendo tiempos de inicio, de fin, avisos, etc, etc. Vaya, un planificador de tareas integrado en eclipse.
Una vez creada una tarea, cuando trabajamos en ella, hay dos cosas interesantes que hace Mylar. Por un lado lleva el tiempo que estamos trabajando en esta tarea. Por otra, y lo que es realmente interesante, es que podemos "filtrar" las clases que vemos en nuestro arbol de clases de forma que sólo se ven las que estamos usando. Esto es muy interesante en proyectos grandes. Cuando dentro del proyecto grande, de miles de clases, trabajamos en un tema concreto, sólo veremos un grupo reducido de clases, las que nos han ido haciendo falta. Se facilita un montón el tema de navegar entre clases.
Mylar se integra además con bugzilla, trac y jira. Cuando creamos una nueva tarea, podemos poner la url de un bug que esté registrado por ejemplo, en bugzilla. Al hacerlo, el nombre de la tarea se pondrá automáticamente como el nombre del bug y además, permite abrir en una pestaña de eclipse un navegador en el que veremos el bug de bugzilla y podremos modificarlo.
La parte de bugzilla es curiosa, pero no sé si merece la pena abrir una tarea por cada bug, sobre todo en proyectos grandes en los que hay miles y miles de bugs. Quizás sea interesante si la empresa (o uno personalmente) lleva una estadística del tiempo que tarda en resolver cada bug. Al crear una tarea por bug, Mylar lleva el tiempo que trabajas en esa tarea, así que cuando terminas de arreglar el bug, tienes el tiempo que has tardado en resolverlo.
De todas formas, sólo por el filtro de clases en proyectos grandes, Mylar merece la pena.
31 agosto 2006
Bugzilla en los correos y windows
Al final he conseguido que bugzilla envie correos. Ha sido todo una historia.
El primer problema es que el servidor de smtp (el que envía los correos) es el de la empresa, por lo que para enviar correos necesito identificarme con mi usuario y password.
En bugzilla no encontré ningún sitio que permitiera configurar el usuario y password para el servidor smtp. Sí permitía poner el nombre/ip del servidor pero no usuario/password, al menos, yo no lo he encontrado.
Al final me decidí a, en vez de usar directamente smtp, configurar bugzilla para que use la utilidad sendmail de unix (se hace directamente desde el navegador). Como estoy en windows, tuve que buscar un sendmail para windows. ¡Sorpresa!. Hay un sendmail para windows con instalador para bugzilla. Si no queremos tocar los ficheros de bugzilla, hay que instalar sendmail en C:\usr\lib. Lo instalé, lo configuré y seguía sin funcionar.
Afortunadamente, sendmail tiene una salida de log para debug (hay que descomentar una línea en el fichero de configuración de sendmail.ini para que ese log salga). En ese log de debug veo toda la mensajería entre sendmail y mi servidor de smtp. En ese log veo que el servidor de smtp rechaza los envios de correo porque el campo "from" no coincide con mi dirección de correo real. En realidad esto se podría hacer, pueden ser distintas, pero el servidor de smtp de mi empresa no nos deja "inventarnos" otra personalidad para el "from".
El campo "from" de bugzilla pone "bugzilla-admin-daemon" o "bugzilla-admin" según de dónde se envíe el correo. Así que tanto buscando en los ficheros de bugzilla como desde el navegador en la página de configuración de correo, cambio todos estos "bugzilla-admin*" por mi dirección real de correo. ¡Voila!, ¡ya funciona!. La única pega es que voy a ser yo el que envíe todos los correos de bugzilla a todo el mundo.
Bueno, ahora a ver si convenzo a la gente para que lo use ....
El primer problema es que el servidor de smtp (el que envía los correos) es el de la empresa, por lo que para enviar correos necesito identificarme con mi usuario y password.
En bugzilla no encontré ningún sitio que permitiera configurar el usuario y password para el servidor smtp. Sí permitía poner el nombre/ip del servidor pero no usuario/password, al menos, yo no lo he encontrado.
Al final me decidí a, en vez de usar directamente smtp, configurar bugzilla para que use la utilidad sendmail de unix (se hace directamente desde el navegador). Como estoy en windows, tuve que buscar un sendmail para windows. ¡Sorpresa!. Hay un sendmail para windows con instalador para bugzilla. Si no queremos tocar los ficheros de bugzilla, hay que instalar sendmail en C:\usr\lib. Lo instalé, lo configuré y seguía sin funcionar.
Afortunadamente, sendmail tiene una salida de log para debug (hay que descomentar una línea en el fichero de configuración de sendmail.ini para que ese log salga). En ese log de debug veo toda la mensajería entre sendmail y mi servidor de smtp. En ese log veo que el servidor de smtp rechaza los envios de correo porque el campo "from" no coincide con mi dirección de correo real. En realidad esto se podría hacer, pueden ser distintas, pero el servidor de smtp de mi empresa no nos deja "inventarnos" otra personalidad para el "from".
El campo "from" de bugzilla pone "bugzilla-admin-daemon" o "bugzilla-admin" según de dónde se envíe el correo. Así que tanto buscando en los ficheros de bugzilla como desde el navegador en la página de configuración de correo, cambio todos estos "bugzilla-admin*" por mi dirección real de correo. ¡Voila!, ¡ya funciona!. La única pega es que voy a ser yo el que envíe todos los correos de bugzilla a todo el mundo.
Bueno, ahora a ver si convenzo a la gente para que lo use ....
30 agosto 2006
Bugzilla
Bugzilla es un conjunto de scripts cgi que con apache y una base de datos nos permite llevar desde el navegador una base de datos de errores/fallos/incidencias/"bugs" de nuestro proyecto.
En otras palabras, una vez instalado y configurado, cuando pruebo el programa en el que estoy trabajando y encuentro un fallo, abro el navegador, me conecto a la página donde tengo instalado bugzilla y escribo la incidencia.
Esto es útil para equipos de trabajo. Cada uno de los integrantes se da de alta en donde hemos instaldo nuestro bugzilla y da su correo electrónico. Cada vez que alguno encuentra un fallo en el programa, lo pone en bugzilla y da la dirección de correo del que se supone responsable del fallo. Bugzilla envía un correo con la incidencia a la persona indicada. Esta, cuando la mira, corrige o decide que no es de él, lo anota en bugzilla y correo al canto a la/s personas indicadas.
De esta forma, queda una base de datos con todos los fallos, la historia de esos fallos, si se han corregido o no, etc. La gente del navegador mozilla usa bugzilla y puedes verlo en marcha en https://bugzilla.mozilla.org/.
Bueno, me he decidido a probarlo en el trabajo, así cuando los "jefes" prueben los programas, en vez de anotar los fallos en un papel guarro (no de marca "guarro", sino "papel cutre arrancado de libreta de espiral que se me ha caido al suelo y he pisado por el camino"), podrán escribirlos sobre la marcha con el navegador, nos enteraremos automáticamente con un correo y cuando los arreglemos, les llegará el correo correspondiente.
He instalado bugzilla en windows, y todavía estoy peleandome un poco con ello. En el trabajo tenemos proxy y un servidor smtp que requiere contraseña. Además, estoy dentro de una red local. El caso es que lo he puesto todo, pero todavía no consigo que bugzilla envíe los correos. Si es que todo esto está pensado para funcionar en unix...
La instalación no es una instalación tonta, pero siguiendo las instrucciones y teniendo un poco de idea de qué va el tema, resulta más o menos asequible. Eso sí, hay que instalar perl para windows, una serie de módulos para perl que necesita bugzilla, el servidor apache y mysql si no están ya instalados, tocar la configuración de apache, etc, etc. Bueno, que me he tirado un par de horas consultando internet y demás para tenerlo más o menos en marcha.
Igual que bugzilla, hay otros.
Finalmente, está Mylar, que tampoco he probado. Es un plug-in para eclipse que permite organizarte tareas. En cada tarea eclipse sólo muestra aquellos ficheros que son intersantes para la tarea, de forma que en un proyecto grande de miles de ficheros no se ven todos a la vez, sino sólo por tareas de pocos en pocos cada vez. Es decir, si para la tarea1 necesito fichero1.java, fichero2.java y fichero3.java, cuando seleccione la tarea1, eclipse sólo me mostrará esos ficheros y ocultará los demás. Lo que más me ha llamado la atención es que dice que es capaz de coger tareas de bugzilla, jira o trac. ¿Quiere esto decir que cojo un error/bug de bugzilla y lo puedo poner como tarea de mylar en eclipse?
Bueno, el caso es que estoy con todo esto. Seguiré investigando...
En otras palabras, una vez instalado y configurado, cuando pruebo el programa en el que estoy trabajando y encuentro un fallo, abro el navegador, me conecto a la página donde tengo instalado bugzilla y escribo la incidencia.
Esto es útil para equipos de trabajo. Cada uno de los integrantes se da de alta en donde hemos instaldo nuestro bugzilla y da su correo electrónico. Cada vez que alguno encuentra un fallo en el programa, lo pone en bugzilla y da la dirección de correo del que se supone responsable del fallo. Bugzilla envía un correo con la incidencia a la persona indicada. Esta, cuando la mira, corrige o decide que no es de él, lo anota en bugzilla y correo al canto a la/s personas indicadas.
De esta forma, queda una base de datos con todos los fallos, la historia de esos fallos, si se han corregido o no, etc. La gente del navegador mozilla usa bugzilla y puedes verlo en marcha en https://bugzilla.mozilla.org/.
Bueno, me he decidido a probarlo en el trabajo, así cuando los "jefes" prueben los programas, en vez de anotar los fallos en un papel guarro (no de marca "guarro", sino "papel cutre arrancado de libreta de espiral que se me ha caido al suelo y he pisado por el camino"), podrán escribirlos sobre la marcha con el navegador, nos enteraremos automáticamente con un correo y cuando los arreglemos, les llegará el correo correspondiente.
He instalado bugzilla en windows, y todavía estoy peleandome un poco con ello. En el trabajo tenemos proxy y un servidor smtp que requiere contraseña. Además, estoy dentro de una red local. El caso es que lo he puesto todo, pero todavía no consigo que bugzilla envíe los correos. Si es que todo esto está pensado para funcionar en unix...
La instalación no es una instalación tonta, pero siguiendo las instrucciones y teniendo un poco de idea de qué va el tema, resulta más o menos asequible. Eso sí, hay que instalar perl para windows, una serie de módulos para perl que necesita bugzilla, el servidor apache y mysql si no están ya instalados, tocar la configuración de apache, etc, etc. Bueno, que me he tirado un par de horas consultando internet y demás para tenerlo más o menos en marcha.
Igual que bugzilla, hay otros.
- JIRA, que es de pago.
- Trac, que es gratis, pero me da la impresión de que está todavía un poco en pañales. Ellos mismos dicen que no ha sido probado suficientemente con MySQL y andan todavía por la versión 0.x
Finalmente, está Mylar, que tampoco he probado. Es un plug-in para eclipse que permite organizarte tareas. En cada tarea eclipse sólo muestra aquellos ficheros que son intersantes para la tarea, de forma que en un proyecto grande de miles de ficheros no se ven todos a la vez, sino sólo por tareas de pocos en pocos cada vez. Es decir, si para la tarea1 necesito fichero1.java, fichero2.java y fichero3.java, cuando seleccione la tarea1, eclipse sólo me mostrará esos ficheros y ocultará los demás. Lo que más me ha llamado la atención es que dice que es capaz de coger tareas de bugzilla, jira o trac. ¿Quiere esto decir que cojo un error/bug de bugzilla y lo puedo poner como tarea de mylar en eclipse?
Bueno, el caso es que estoy con todo esto. Seguiré investigando...
Suscribirse a:
Entradas (Atom)
