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.

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.

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.

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.

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.

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.

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.

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.