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.
03 octubre 2006
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.
17 septiembre 2006
Historieta en el Criptonomicón
Estoy leyendo la novela del criptonomicón (novela gorda, partida en tres libros). Hay una pequeña historia que me ha llamado la atención y por eso la escribo aquí.
En la novela el protagonista tiene en su portatil un texto cifrado por los Japoneses (nipos) en la segunda guerra mundial. Ese texto ha estado oculto y nadie lo ha descifrado nunca. En el texto supuestamente está la localización de un depósito de oro que los japonenes tenían escondido durante la guerra.
Los "malos" de la novela consiguen por malas artes meter al protagonista de la novela junto con su portatil en una carcel de Filipinas y consiguen hacerlo de tal manera que pueden ver la pantalla de su portatil, pero sólo la pantalla. Su intención es mantenerlo en la carcel hasta que descifre el código y ver el texto en claro con la ubicación del oro japones.
El protagonista, que para eso es el protagonista y es muy listo, lo sabe, así que se propone descifrar el código, pero sin mostrarlo por pantalla y a su vez presentar un texto falso. Ahí viene lo interesante. ¿Como ver el código descifrado sin mostrarlo por pantalla? ¿Cómo escribir un texto falso sin que se vea en pantalla?
Para la primera solución, nuestro protagonista aprovechó que sabía morse. Descifró el código con un programa que se hizo, de forma que lo volcara a un fichero, sin visualizarlo en pantalla. Con un segundo programa y usando la librería XLEDS, envió el fichero ... ¡a uno de los leds del teclado!, de forma que parpadeando en morse, le mostraba el contenido del fichero.
En cuanto a generar el fichero falso para mostrar en pantalla, hizo un programa similar, pero con la barra de espacio. Luego se dedicó a ver ficheros largos con el comando "more" de unix. Pulsando la barra espaciadora rítmicamente, aparentemente estaba viend el fichero, pero en realidad estaba escribiendo en morse un fichero falso.
No deja de ser una novela, pero desde luego la idea es original.
En la novela el protagonista tiene en su portatil un texto cifrado por los Japoneses (nipos) en la segunda guerra mundial. Ese texto ha estado oculto y nadie lo ha descifrado nunca. En el texto supuestamente está la localización de un depósito de oro que los japonenes tenían escondido durante la guerra.
Los "malos" de la novela consiguen por malas artes meter al protagonista de la novela junto con su portatil en una carcel de Filipinas y consiguen hacerlo de tal manera que pueden ver la pantalla de su portatil, pero sólo la pantalla. Su intención es mantenerlo en la carcel hasta que descifre el código y ver el texto en claro con la ubicación del oro japones.
El protagonista, que para eso es el protagonista y es muy listo, lo sabe, así que se propone descifrar el código, pero sin mostrarlo por pantalla y a su vez presentar un texto falso. Ahí viene lo interesante. ¿Como ver el código descifrado sin mostrarlo por pantalla? ¿Cómo escribir un texto falso sin que se vea en pantalla?
Para la primera solución, nuestro protagonista aprovechó que sabía morse. Descifró el código con un programa que se hizo, de forma que lo volcara a un fichero, sin visualizarlo en pantalla. Con un segundo programa y usando la librería XLEDS, envió el fichero ... ¡a uno de los leds del teclado!, de forma que parpadeando en morse, le mostraba el contenido del fichero.
En cuanto a generar el fichero falso para mostrar en pantalla, hizo un programa similar, pero con la barra de espacio. Luego se dedicó a ver ficheros largos con el comando "more" de unix. Pulsando la barra espaciadora rítmicamente, aparentemente estaba viend el fichero, pero en realidad estaba escribiendo en morse un fichero falso.
No deja de ser una novela, pero desde luego la idea es original.
16 septiembre 2006
Monitor TFT
Acabo de comprarme un monitor TFT de 19" y marca "ni-su".
Lo cogí en el beep de debajo de casa, en una oferta baratita (el más barato que he encontrado de 19"). La marca es hannsg y el monitor es HC194DP.
En principio estoy contento. No soy jugador empedernido del Quake ni un fan de ver películas divx. Soy más bien programador de ver pantallas de texto todo el rato, así que el monitor se comporta bastante bien. No sé que tal irán los refrescos con juegos de acción y películas de la guerra de las galaxias.
Tiene un par de altavoces, que no son gran cosa ni de gran calidad. El ajuste de volumen es algo incómodo y no puedo bajarlo lo suficiente. El nivel más bajo es demasiadao alto para trabajar a altas horas de la madrugada con mujer y niños durmiendo en habitaciones cercanas. Aunque bien pensado, puedo jugar con el volumen de windows, ese altavocito que sale abajo a la derecha.
También es el primer monitor TFT que tengo, así que no tengo nada con qué comparar. Antes en casa tenía uno de tubo de 14" o 15", así que 19" ahora me parecen una maravilla. En el trabajo tengo también uno de tubo de 17" (creo). Ya sabes, trabajo en una empresa de tecnología punta.
Lo cogí en el beep de debajo de casa, en una oferta baratita (el más barato que he encontrado de 19"). La marca es hannsg y el monitor es HC194DP.
En principio estoy contento. No soy jugador empedernido del Quake ni un fan de ver películas divx. Soy más bien programador de ver pantallas de texto todo el rato, así que el monitor se comporta bastante bien. No sé que tal irán los refrescos con juegos de acción y películas de la guerra de las galaxias.
Tiene un par de altavoces, que no son gran cosa ni de gran calidad. El ajuste de volumen es algo incómodo y no puedo bajarlo lo suficiente. El nivel más bajo es demasiadao alto para trabajar a altas horas de la madrugada con mujer y niños durmiendo en habitaciones cercanas. Aunque bien pensado, puedo jugar con el volumen de windows, ese altavocito que sale abajo a la derecha.
También es el primer monitor TFT que tengo, así que no tengo nada con qué comparar. Antes en casa tenía uno de tubo de 14" o 15", así que 19" ahora me parecen una maravilla. En el trabajo tengo también uno de tubo de 17" (creo). Ya sabes, trabajo en una empresa de tecnología punta.
15 septiembre 2006
Joel on software
Ya lo mencioné en un post anterior, pero llevo varios días leyendo artículos de él y casi todos son geniales.
En Joel on software hay pequeños artículos en español (hay muchos más en inglés) sobre metodologías y formas de organizar y trabajar en los proyectos de software.
En ellos se cuentan verdades como puños, se pone a parir a las metodologías serias, a los consultores, a la política de la mayoría de las empresas y a muchas de las cosas que se dan por supuestas. Básicamente defiende que para hacer buen software lo que necesitas son buenos programadores y un mínimo de organización/planificación.
Las metodologías tradicionales no son más que un montón de reglas que tratan de hacer que los programadores mediocres llegen a un nivel mínimo, pero que atan y hacen sentirse incómodos a los buenos programadores.
Aunque en tu proyecto no haya algunas buenas costumbres, puedes implantarlas tú mismo, aunque no seas jefe, símplmente dedicando un poco de tiempo cada día para irlo haciendo sólo para tí en tu pc. Poco a poco, cuando la gente vaya viendo la utilidad de ello, se irán metiendo, aunque no hay un "jefe" que diga que hay que hacerlo así.
Esto es una de las cosas que he comprobado personalmente. En muchas ocasiones he hecho cosas para mí o como favor personal a un compañero, que me resultaban útiles a mí o a mi compañero, y he visto cómo se han "divulgado" incluso entre los "jefes" y lo han convertido en algo "importante" e "imprescindible". Recuerdo en concreto una interface gráfica para un equipo, que empecé a hacer por mi cuenta, como favor a un compañero. Cuando mi jefe me vio haciéndola, me prohibió seguir con ella, había otras cosas más importantes que hacer a las que dedicar mi tiempo. De todas formas, seguí haciéndola y cuando estuvo terminada, acabó en una feria en Paris para mostrar el equipo a los visitantes. Es más vistoso enseñar en una pantalla el equipo funcionando que enseñar el equipo apagado sobre una vitrina.
Volviendo a Joel on software, en la página hay montones de artículos divertidos del estilo comentado y prácticamente ninguno de ellos tiene desperdicio.
En Joel on software hay pequeños artículos en español (hay muchos más en inglés) sobre metodologías y formas de organizar y trabajar en los proyectos de software.
En ellos se cuentan verdades como puños, se pone a parir a las metodologías serias, a los consultores, a la política de la mayoría de las empresas y a muchas de las cosas que se dan por supuestas. Básicamente defiende que para hacer buen software lo que necesitas son buenos programadores y un mínimo de organización/planificación.
Las metodologías tradicionales no son más que un montón de reglas que tratan de hacer que los programadores mediocres llegen a un nivel mínimo, pero que atan y hacen sentirse incómodos a los buenos programadores.
Aunque en tu proyecto no haya algunas buenas costumbres, puedes implantarlas tú mismo, aunque no seas jefe, símplmente dedicando un poco de tiempo cada día para irlo haciendo sólo para tí en tu pc. Poco a poco, cuando la gente vaya viendo la utilidad de ello, se irán metiendo, aunque no hay un "jefe" que diga que hay que hacerlo así.
Esto es una de las cosas que he comprobado personalmente. En muchas ocasiones he hecho cosas para mí o como favor personal a un compañero, que me resultaban útiles a mí o a mi compañero, y he visto cómo se han "divulgado" incluso entre los "jefes" y lo han convertido en algo "importante" e "imprescindible". Recuerdo en concreto una interface gráfica para un equipo, que empecé a hacer por mi cuenta, como favor a un compañero. Cuando mi jefe me vio haciéndola, me prohibió seguir con ella, había otras cosas más importantes que hacer a las que dedicar mi tiempo. De todas formas, seguí haciéndola y cuando estuvo terminada, acabó en una feria en Paris para mostrar el equipo a los visitantes. Es más vistoso enseñar en una pantalla el equipo funcionando que enseñar el equipo apagado sobre una vitrina.
Volviendo a Joel on software, en la página hay montones de artículos divertidos del estilo comentado y prácticamente ninguno de ellos tiene desperdicio.
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.
05 septiembre 2006
Agregar meneame y del.icio.us a blog en blogger
Pues nada, en Agregar meneame y del.icio.us a blog en blogger tienes cómo hacerlo.
03 septiembre 2006
Meneando noticias
Me he dedicado un poco a navegar por internet, intentando enterarme de algunas cosas sobre los blogs, feeds y demás que no acabo de entender bien como van. Aquí van algunas pequeñas explicaciones de lo que creo que he entendido, que seguramente será inexacto y equívoco, y algunos enlaces.
Resulta que los diarios (blogs), wikis, páginas de periódicos y muchas otras páginas tienen una cosa que llaman "feed". Esa cosa es una especie de página en un formato simple con las últimas noticias que se publican en ese blog, wiki y tal. El que hace el blog no tiene que preocuparse de ello, se hace automáticamente.
Este, por ejemplo, es el feed de este blog. Si lo estás viendo con firefox, pincha en "ver", "estilo de página", "sin estilo" para verlo más mejor. El de este blog es un fichero "atom.xml" (el que ofrece blogger). También hay otros con "rss", que es más o menos lo mismo, un fichero resumen, pero de otra manera.
Existen por otro lado montones de herramientas capaces de anotar estos feeds, de forma que un internauta pueda ver rápidamente los últimos añadidos a sus blogs favoritos. Por ejemplo, el mismo navegador firefox, se puede añadir como "favorito vivo" un "rss" de estos, de forma que en tus favoritos aparecerán automáticamente las, por ejemplo, 20 últimas publicaciones en ese blog. En http://www.coseju.com/rss.php?PHPSESSID=cf6fdcce689002c950e1d7ace36f6cbf tienes cómo hacerlo.
En el rss de este diario, tienes arriba a la derecha un "suscribe now". Ahí aparecen un montón de herramientas capaces de suscribirte a este diario. Debes elegir la que tengas. Por ejemplo, puedes, si tienes cuenta de gmail, ponerlo en tu página de búsqueda de google personalizada.
Hay sitios, como feedburner, que ofrecen a los que publican blogs la posibilidad de poner un icono
en su sitio indicando que tienen "feed" y de alguna manera ellos lo ofrecen. La gente, pinchando el icono puede "suscribirse" a estas noticias con alguna de las herramientas comentadas antes, como el navegador firefox. La persona que publica el blog puede enterarse, a través de feedburner, cuantos navegantes hay suscritos a su "feed". En fin, algo complejo que todavía no acabo de entender bien y tengo que ver mejor como funciona esto.
Finalmente, supongo que con un fin parecido pero de otra manera, me he tropezado con meneame, un sitio en el que la gente manda noticias que se encuentra en los blogs y demás. Los visitantes de meneame pueden ver las noticias que han enviado los demás y darles un voto ("menearla") si les gusta. Meneame muestra primero las noticias más votadas, de forma que de alguna manera tienes una página de noticias "favoritas" de la gente. Vaya, otra cosa a investigar.
Supongo que la idea final de todo esto es que tú no tengas que revisar todos los blogs favoritos, sino tener las últimas noticias de todos ellos en un único sitio, el navegador firefox, la página de búsqueda de google u otras páginas (como netvibes), de forma que simplemente entrando ahí, ves las últimas publicaciones de todos tus sitios favoritos.
La verdad es que todas estas cosas avanzan muy rápido y me desbordan, sobre todo si tu actividad principal es otra, java en mi caso.
Resulta que los diarios (blogs), wikis, páginas de periódicos y muchas otras páginas tienen una cosa que llaman "feed". Esa cosa es una especie de página en un formato simple con las últimas noticias que se publican en ese blog, wiki y tal. El que hace el blog no tiene que preocuparse de ello, se hace automáticamente.
Este, por ejemplo, es el feed de este blog. Si lo estás viendo con firefox, pincha en "ver", "estilo de página", "sin estilo" para verlo más mejor. El de este blog es un fichero "atom.xml" (el que ofrece blogger). También hay otros con "rss", que es más o menos lo mismo, un fichero resumen, pero de otra manera.
Existen por otro lado montones de herramientas capaces de anotar estos feeds, de forma que un internauta pueda ver rápidamente los últimos añadidos a sus blogs favoritos. Por ejemplo, el mismo navegador firefox, se puede añadir como "favorito vivo" un "rss" de estos, de forma que en tus favoritos aparecerán automáticamente las, por ejemplo, 20 últimas publicaciones en ese blog. En http://www.coseju.com/rss.php?PHPSESSID=cf6fdcce689002c950e1d7ace36f6cbf tienes cómo hacerlo.
En el rss de este diario, tienes arriba a la derecha un "suscribe now". Ahí aparecen un montón de herramientas capaces de suscribirte a este diario. Debes elegir la que tengas. Por ejemplo, puedes, si tienes cuenta de gmail, ponerlo en tu página de búsqueda de google personalizada.
Hay sitios, como feedburner, que ofrecen a los que publican blogs la posibilidad de poner un icono
en su sitio indicando que tienen "feed" y de alguna manera ellos lo ofrecen. La gente, pinchando el icono puede "suscribirse" a estas noticias con alguna de las herramientas comentadas antes, como el navegador firefox. La persona que publica el blog puede enterarse, a través de feedburner, cuantos navegantes hay suscritos a su "feed". En fin, algo complejo que todavía no acabo de entender bien y tengo que ver mejor como funciona esto.Finalmente, supongo que con un fin parecido pero de otra manera, me he tropezado con meneame, un sitio en el que la gente manda noticias que se encuentra en los blogs y demás. Los visitantes de meneame pueden ver las noticias que han enviado los demás y darles un voto ("menearla") si les gusta. Meneame muestra primero las noticias más votadas, de forma que de alguna manera tienes una página de noticias "favoritas" de la gente. Vaya, otra cosa a investigar.
Supongo que la idea final de todo esto es que tú no tengas que revisar todos los blogs favoritos, sino tener las últimas noticias de todos ellos en un único sitio, el navegador firefox, la página de búsqueda de google u otras páginas (como netvibes), de forma que simplemente entrando ahí, ves las últimas publicaciones de todos tus sitios favoritos.
La verdad es que todas estas cosas avanzan muy rápido y me desbordan, sobre todo si tu actividad principal es otra, java en mi caso.
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...
29 agosto 2006
Joel on Software
En Joel on Software hay un montón de artículos es español sobre temas de software. Son sobre cosas que se hacen bien o mal en las empresas, a la hora de hacer software, qué tener en cuenta para diseñar buenas interfaces de usuario, etc.
He leido varios de ellos y la verdad es que no tienen desperdicio. Dicen muchas verdades como puños y ponen en claro todas esas cosas que los desarrolladores sabemos que debemos hacer pero que no solemos hacer por pereza o por no saber hacer bien.
He leido varios de ellos y la verdad es que no tienen desperdicio. Dicen muchas verdades como puños y ponen en claro todas esas cosas que los desarrolladores sabemos que debemos hacer pero que no solemos hacer por pereza o por no saber hacer bien.
28 agosto 2006
Día Aciago
De vuelta al trabajo, después del mes de vacaciones. Un asquito.
Bueno, ahí van cuatro tonterías que he encontrado/me han encontrado y que en algún momento habrá que mirar:
Bueno, ahí van cuatro tonterías que he encontrado/me han encontrado y que en algún momento habrá que mirar:
- Java y Matlab: http://www.held-mueller.de/JMatLink/
- Los de google tiene para dejar tus propios proyectos de software relativos a google: http://code.google.com/
- Una pequeña herramienta de google para hacer modelado en 3d, gratuita por supuesto: http://sketchup.google.com/
- Para llevar tu propio calendario de citas/eventos/tareas en web, cortesía de google: http://www.google.com/googlecalendar/overview.html
15 agosto 2006
Acabo de encontrarme
Acabo de encontrarme en otra página. Resulta que en granainfo, en la parte de programación, está básicamente copiado este blog, manteniendo enlaces a la fuente original. No veo enlaces o artículos de otro sitio...
Bueno, me alegra comprobar que lo que escribo le parece lo suficiemente bien a alguien como para reproducirlo. Además, manteniendo un enlace al original, es más mejor.
Bueno, me alegra comprobar que lo que escribo le parece lo suficiemente bien a alguien como para reproducirlo. Además, manteniendo un enlace al original, es más mejor.
28 julio 2006
Mozilla SeaMonkey
Jugando con internet acabo de descubrir mozilla seamonkey. Miré a ver que era y ponía que es una especie de navegador, correo y editor de html todo junto.
Lo he instalado y me ha decepcionado un poco. Es casi exactamente lo que antes era netscape, que venía con navegador, composer, etc. No quiero decir que el programa esté mal, sino simplemente que es lo mismo que el antiguo netscape, pero con otro nombre.
Seguiré con el firefox y el thunderbird, que me gustaron bastante más nada más instalarlos.
En cuanto a editor de html, tradicionalmente he utilizado el netscape composer. Sin embargo, hace poco, que empecé a meter algun java script ajeno, me empezó a hacer cosas raras. Y desde luego, no he conseguido que se trague una página php sin descuajeringarla, a pesar del que el 90% de la página es html. Por eso me he acabado cambiando a dreamweaber y de momento estoy contento con él. No uso todo lo que tiene, puesto que mis páginas son muy sencillitas, sólo html y algo mínimo de php en alguna ocasión, y algún javascript ajeno que inserto (contadores de estadísticas, google adsense, etc), unas pruebas con css, pero me hace bien lo que quiero que haga. Sobre todo no me descuajeringa una página cuando su extensión es php.
Lo he instalado y me ha decepcionado un poco. Es casi exactamente lo que antes era netscape, que venía con navegador, composer, etc. No quiero decir que el programa esté mal, sino simplemente que es lo mismo que el antiguo netscape, pero con otro nombre.
Seguiré con el firefox y el thunderbird, que me gustaron bastante más nada más instalarlos.
En cuanto a editor de html, tradicionalmente he utilizado el netscape composer. Sin embargo, hace poco, que empecé a meter algun java script ajeno, me empezó a hacer cosas raras. Y desde luego, no he conseguido que se trague una página php sin descuajeringarla, a pesar del que el 90% de la página es html. Por eso me he acabado cambiando a dreamweaber y de momento estoy contento con él. No uso todo lo que tiene, puesto que mis páginas son muy sencillitas, sólo html y algo mínimo de php en alguna ocasión, y algún javascript ajeno que inserto (contadores de estadísticas, google adsense, etc), unas pruebas con css, pero me hace bien lo que quiero que haga. Sobre todo no me descuajeringa una página cuando su extensión es php.
Crear .exe de java
Aunque la forma normal de hacer un programa java es generar un fichero jar, su ejecución puede ser compleja para un usuario que no conozca java. Por ello, entregar una aplicación java a un usuario normalito de ordenador suele requerir entregar también un .bat de arranque, que revise si existe máquina virtual, que ponga cosas como el classpath, etc, etc.
Hay utilidades que permiten pasar nuestro .jar a un fichero .exe normal de windows, de forma que a un usuario no programador le resulte más fácil el arranque.
Algunas de estas utilidades, como JSmooth, simplemente crean un pequeño exe que arranca la aplicación, pero necesitan que la máquina virtual esté instalada.
gcj sí crea un verdadero ejecutable, pero gcj está pensado para el entorno de gnu, por lo que para ejecutarlo en windows es necesario instalar previamente el cygwin. gcj venga mejor posiblemente para usuarios de linux/unix.
java2exe (ahora JexePack) también permite generar .exe, pero es una aplicación de pago.
Algunos IDE, como JBuilder, también permiten generar el exe.
De todas formas, no he probado ninguno de ellos. De momento no tengo ninguna necesidad especial de generar .exe. Además, pienso que se pierde un poco la filosofía de java, que es que el "ejecutable" se pueda ejecutar en cualquier sistema operativo. Tampoco suelo hacer aplicaciones para usuarios no programadores.
Hay utilidades que permiten pasar nuestro .jar a un fichero .exe normal de windows, de forma que a un usuario no programador le resulte más fácil el arranque.
Algunas de estas utilidades, como JSmooth, simplemente crean un pequeño exe que arranca la aplicación, pero necesitan que la máquina virtual esté instalada.
gcj sí crea un verdadero ejecutable, pero gcj está pensado para el entorno de gnu, por lo que para ejecutarlo en windows es necesario instalar previamente el cygwin. gcj venga mejor posiblemente para usuarios de linux/unix.
java2exe (ahora JexePack) también permite generar .exe, pero es una aplicación de pago.
Algunos IDE, como JBuilder, también permiten generar el exe.
De todas formas, no he probado ninguno de ellos. De momento no tengo ninguna necesidad especial de generar .exe. Además, pienso que se pierde un poco la filosofía de java, que es que el "ejecutable" se pueda ejecutar en cualquier sistema operativo. Tampoco suelo hacer aplicaciones para usuarios no programadores.
27 julio 2006
Cambiar el icono de la taza de café en java
La forma normal de cambiar el icono de la taza de café en java en una aplicación consiste en llamar al método setIconImage() del JFrame principal de la aplicación. Luego, el resto de JDialog de la aplicación deben ser hijos, nietos o biznietos de este JFrame, heredando así su icono. Puedes ver más detalles de este cambio de icono.
Sin embargo, ayer un compañero de trabajo encontró una forma más bruta de hacerlo, de forma que queda cambiado para todas las aplicaciones java de nuestro ordenador (salvo que ellas lo cambien de forma expresa dentro).
Este método de fuerza bruta consiste en buscar dentro de nuestra instalación de java los ficheros rt.jar y awt.dll, que contienen dentro dicho icono de la taza de café y cambiarlo por otro. En Cambiar el icono de la taza de café están los detalles.
Sin embargo, ayer un compañero de trabajo encontró una forma más bruta de hacerlo, de forma que queda cambiado para todas las aplicaciones java de nuestro ordenador (salvo que ellas lo cambien de forma expresa dentro).
Este método de fuerza bruta consiste en buscar dentro de nuestra instalación de java los ficheros rt.jar y awt.dll, que contienen dentro dicho icono de la taza de café y cambiarlo por otro. En Cambiar el icono de la taza de café están los detalles.
25 julio 2006
Dos programas opuestos
Aquí un par de programitas para java que pueden ser más o menos útiles y que sirven para lo contrario.
El primero es un "descompilador" de java. El DJ Java Decompiler es un programita que dándole los ficheros .class es capaz de sacarnos los fuentes .java. Tiene interface gráfica y es gratis.
El otro programa, en realidad son varios, son los ofuscadores de código java. Precisamente para evitar que nuestros programas java puedan ser "descompilados", existen estos ofuscadores. Básicamente lo que hacen es cambiar los nombres de clases, métodos y variables por nombres crípticos. El programa .class puedes descompilarse igualmente, pero no es lo mismo intuir que el método setNombre(String nombre) de la clase Persona mete el nombre de la persona en la clase Persona, que intuir qué demonios hace afaewser(String afew) de la clase Xdañsiñwe. Supuestamente, además de ofuscar y ya puestos a tocar el jar, la mayoría de ellos llevan a cabo labores de optimización, tratando de reducir el jar lo máximo posible, eliminando código innecesario, variables no usadas, métodos no usados, etc. De hecho, la ofuscación de código es más bien un "efecto secundario" de este proceso. Para reducir el tamaño del jar, no hay nada como llamar a las clases, métodos y variables con nombres lo más cortos posibles. No he probado ninguno, pero por lo que he leido es lo que intuyo que hacen...
ProGuard es un ofuscador gratuito y en la misma página tienes un listado de otros ofuscadores de código.
El primero es un "descompilador" de java. El DJ Java Decompiler es un programita que dándole los ficheros .class es capaz de sacarnos los fuentes .java. Tiene interface gráfica y es gratis.
El otro programa, en realidad son varios, son los ofuscadores de código java. Precisamente para evitar que nuestros programas java puedan ser "descompilados", existen estos ofuscadores. Básicamente lo que hacen es cambiar los nombres de clases, métodos y variables por nombres crípticos. El programa .class puedes descompilarse igualmente, pero no es lo mismo intuir que el método setNombre(String nombre) de la clase Persona mete el nombre de la persona en la clase Persona, que intuir qué demonios hace afaewser(String afew) de la clase Xdañsiñwe. Supuestamente, además de ofuscar y ya puestos a tocar el jar, la mayoría de ellos llevan a cabo labores de optimización, tratando de reducir el jar lo máximo posible, eliminando código innecesario, variables no usadas, métodos no usados, etc. De hecho, la ofuscación de código es más bien un "efecto secundario" de este proceso. Para reducir el tamaño del jar, no hay nada como llamar a las clases, métodos y variables con nombres lo más cortos posibles. No he probado ninguno, pero por lo que he leido es lo que intuyo que hacen...
ProGuard es un ofuscador gratuito y en la misma página tienes un listado de otros ofuscadores de código.
21 julio 2006
Método toString() de Element de org.w3c.dom
Me he tropezado con un pequeño problemilla que cuento aquí por si a alguien más le pasa lo mismo.
Resulta que trabajando con la versión 1.4 de java, cuando tengo un Document correspondiente a un fichero xml guardado en memoria, haciendo toString() del Element raiz del Document, me devuelve un String con el contenido del fichero xml.
Sin embargo, ¡sorpresa!, en la versión 1.5 de java este método toString() ya no devuelve el String el formato xml, sino que devuelve una cosa rara, cortita, que no vale.
En Bug ID: 6181019 REGRESSION: org.w3c.dom.Element.toString() no longer returns the xml document: "toString" está comentado este problema con más detalle.
Resulta que trabajando con la versión 1.4 de java, cuando tengo un Document correspondiente a un fichero xml guardado en memoria, haciendo toString() del Element raiz del Document, me devuelve un String con el contenido del fichero xml.
Sin embargo, ¡sorpresa!, en la versión 1.5 de java este método toString() ya no devuelve el String el formato xml, sino que devuelve una cosa rara, cortita, que no vale.
En Bug ID: 6181019 REGRESSION: org.w3c.dom.Element.toString() no longer returns the xml document: "toString" está comentado este problema con más detalle.
Suscribirse a:
Entradas (Atom)
