Me acabo de dar de alta en ono y ya puestos a hacer gasto, lo he cogido todo: televisión, teléfono e internet.
Me dí de alta por teléfono un martes. Ese mismo día me dijeron que el técnico vendría a ponerme los cables el siguiente martes sobre las cinco y media, hora que yo había solicitado. El técnico aparecio puntual y tardó casi dos horas en instalar todo. No es complejo, pero son tres cables que tiene que llevar por la casa y dos aparatos a instalar, el decodificador de tv y el cable modem para el internet. Cuando se fué sólo funcionaba internet. El decodificador que trajo estaba mal y el teléfono no lo probamos, poque me comentó que el cajetín de telefonos de la calle estaba mal y a mí no me llegaba señal.
Volvió al día siguiente por la mañana, con un decodificador nuevo y habiendo arreglado lo del teléfono. Con ello ya tenía el decodificador de TV en condiciones y señal en el teléfono. Sin embargo, el teléfono iba a medias, podía hacer llamadas interprovinciales pero no locales. La tele seguía sin ir. El tema es que todavía no me habían dado de alta en el servicio.
Esta mañana tempranito (Viernes después de un Jueves festivo) ya estaba todo funcionando. El internet funcionó desde el primer día. El teléfono y la televisión, desde que llamé para darme de alta hasta que lo he tenido en marcha, han pasado semana y media.
En general, salvo esas pequeñas vicisitudes que se solucionaron rápido, el servicio ha ido bastante bien. El técnico puntual, venía cuando decía que iba a venir.
13 octubre 2006
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.
10 octubre 2006
Eclipse y CVS
Bueno, ahora que han pasado unas horas desde mi última experiencia de eclipse con cvs, creo que no voy a echar demasiados juramentos.
Mi experiencia con el cvs de eclipse, "team" según el menú de eclipse, no es nada buena. Le veo muchas pegas que o bien no he sabido solucionar, o bien no se puede. Voy a enumerar algunas de las que menos me gustan:
Mi experiencia con el cvs de eclipse, "team" según el menú de eclipse, no es nada buena. Le veo muchas pegas que o bien no he sabido solucionar, o bien no se puede. Voy a enumerar algunas de las que menos me gustan:
- No puedes poner en eclipse un proyecto cvs que ya tengas fuera. Eclipse obliga a hacer él el checkout del proyecto. Al hacerlo así, mete además con los fuentes sus ficheros de proyecto .classpath y .project. No he conseguido hacer funcionar cvs sobre un proyecto de cvs que tuviera previamente sacado.
- No consigo hacer updates recursivos por los directorios. Cuando alguien toca algo en cvs, debo irme desde línea de comandos de ms-dos o bash al directorio en cuestión y hacer el update a mano, o bien ir en eclipse, paquete por paquete, haciendo update.
- Si cambio de nombre un paquete, con las opciones de refactor, eclipse "borra" el paquete viejo, pero no de cvs. Sin embargo, haciendo updates tampoco lo saca. Debe acordarse que ese paquete tiene ahora otro nombre. ¿Como borro el paquete de cvs?. Desde eclipse imposible, porque ni siquiera puedo verlo. Hay que irse nuevamente a una ventana de ms-dos o bash y hacerlo a mano.
- De vez en cuando falla y marca paquetes como que los tengo editados, pero no muestra ningún fichero editado. Veo también que se "corrompe" el fichero Root de algunos directorios CVS, de forma que queda inutilizable y no me queda más remedio que repararlo a mano.
Eclipse y CVS
Bueno, ahora que han pasado unas horas desde mi última experiencia de eclipse con cvs, creo que no voy a echar demasiados juramentos.
Mi experiencia con el cvs de eclipse, "team" según el menú de eclipse, no es nada buena. Le veo muchas pegas que o bien no he sabido solucionar, o bien no se puede. Voy a enumerar algunas de las que menos me gustan:
Mi experiencia con el cvs de eclipse, "team" según el menú de eclipse, no es nada buena. Le veo muchas pegas que o bien no he sabido solucionar, o bien no se puede. Voy a enumerar algunas de las que menos me gustan:
- No puedes poner en eclipse un proyecto cvs que ya tengas fuera. Eclipse obliga a hacer él el checkout del proyecto. Al hacerlo así, mete además con los fuentes sus ficheros de proyecto .classpath y .project. No he conseguido hacer funcionar cvs sobre un proyecto de cvs que tuviera previamente sacado.
- No consigo hacer updates recursivos por los directorios. Cuando alguien toca algo en cvs, debo irme desde línea de comandos de ms-dos o bash al directorio en cuestión y hacer el update a mano, o bien ir en eclipse, paquete por paquete, haciendo update.
- Si cambio de nombre un paquete, con las opciones de refactor, eclipse "borra" el paquete viejo, pero no de cvs. Sin embargo, haciendo updates tampoco lo saca. Debe acordarse que ese paquete tiene ahora otro nombre. ¿Como borro el paquete de cvs?. Desde eclipse imposible, porque ni siquiera puedo verlo. Hay que irse nuevamente a una ventana de ms-dos o bash y hacerlo a mano.
- De vez en cuando falla y marca paquetes como que los tengo editados, pero no muestra ningún fichero editado. Veo también que se "corrompe" el fichero Root de algunos directorios CVS, de forma que queda inutilizable y no me queda más remedio que repararlo a mano.
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.
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.
Suscribirse a:
Entradas (Atom)
