Dec 19

¿Es bueno dejar las cosas a medias?

Obviamente, la mayoría de la gente responderá que no, que cuando se empieza una cosa, hay que acabarla. Sin embargo, tengo mis dudas.

Yo soy de esas personas que les gusta, en temas de programación, jugar y aprender cosas nuevas. En casa miro perl, python, grails, últimamente ando mirando groovy y multitud de herramientas que hay por ahí. Soy un poco caótico y cuando aprendo un lenguaje, en vez de leerme unos manuales antes de empezar, decido que la forma más entretenida es hacer directamente un programa que haga algo, a ser posible un programa no muy complejo, pero tampoco trivial. Por ejemplo, para perl hice un script que cambia tipos de ficheros .h a clases Java. Con python hice una pequeña web para pedir a los desarrolladores las horas dedicadas a cada proyecto y almacenarlo en una base de datos, etc.

¿Cual es el problema?. Muchas veces el programa que me propongo hacer es más complejo de lo que pensaba en principio y llego a un punto en que no me apetece seguir con ese programa. Ya he aprendido lo que quería del lenguaje (o se me ha pasado la "novedad" del asunto) y lo que me queda del programa que me propuse es ya rutinario y pesado de hacer.

Llegado a ese punto, puedo "emperrarme" en acabarlo, pero el resultado final es que me da pereza la tarea y me paso varios días o semanas que no sigo con él y tampoco empiezo un tema nuevo porque quiero terminar el que tengo a medias. Me está pasando actualmente con un programa que me propuse hacer para el móvil, usando J2ME: un cuatro en raya. Ya he aprendido lo básico para meter un programa en el móvil y codificar con el Midlet y hacer gráficos, pero me he quedado atascado en el algoritmo para que el ordenador sea capaz de jugar al cuatro en raya. Por supuesto, sí tengo una idea de cómo hacer el algoritmo que sé que no es la mejor, pero sí lo suficientemente válida como para ganar a un humano no muy avispado, pero el problema es que tengo que implementarlo. He empezado a hacerlo, pero me da pereza depurarlo y acabarlo. Y ahí estoy, que no avanzo en mi juego ni empiezo otros temas. Y llevo ya tres o cuatro semanas en ese plan.

Me pasa lo mismo con las novelas. Si una novela empieza a no gustarme y me obligo a acabarla, el resultado es que paso varias semanas sin leer. No empiezo una novela nueva porque tengo otra a medias, pero no acabo la que tengo a medias porque no me gusta.

Por eso pienso que, si te no querer dejar algo a medias te bloquea, es mejor dejarlo a medias y desbloquearse. Tanto en novelas como en ordenador, hay muchísimas opciones y si por la que has tirado no te convence o deja de gustarte, puedes saltar alegremente a otra. Muchos dirán que así no llegaré a conocer en profundidad ningún lenguaje, y tienen razón. Pero también hay que pensar que por mucho que me esfuerce en casa como hobby, tampoco voy a llegar a conocer nunca un lenguaje con la misma profundidad que si trabajo con él, ocho horas al día, varios años y compartiendo experiencias y problemas con mis compañeros de trabajo. Así que, puesto que voy a aprender superficialmente en cualquier caso y que en casa lo hago como hobby para entretenerme, ¿no es mejor hacer "lo que te pide el cuerpo" que "obligarse" a seguir con algo que ya no te llama la atención?.

Yo pienso que sí, aunque a veces da rabia no terminar lo que has empezado.

Dec 17

Problemillas con StarUML

En ocasiones y para hacer diagramas UML rápidamente, usamos StarUML. Es una aplicación gratuita y sencilla para hacer diagramas UML rápidamente. Sin embargo, tiene una serie de problemas que nos han traido de cabeza hasta que hemos descubierto los motivos y hemos podido evitarlos.

El problema principal es con el idioma español de Windows y los puntos/comas decimales de los números. La herramienta no entiende la coma decimal de español y da los siguientes problemas:

  • No permite hacer ingeniería inversa. Si se intenta, empieza a dar errores con estos temas.
  • No permite el "layout" automático de los diagramas (que automáticamente recoloque las figuras para que queden más ordenadas).

Buscando por internet, encontramos un LocaleFix.bat. Si arrancamos StarUML con este bat, supuestamente se corrigen estos problemas. Sin embargo, usarlo trae otros problemas.

  • Al abrir con LocaleFix.bat, es posible que algunas etiquetas de los diagramas de secuencia (y otras) se descoloquen, quedando un poco más arriba o abajo de lo normal.
  • Si volvemos a poner en su posición esas etiquetas descolocadas, es posible que la siguiente vez que abramos el proyecto esas etiquetas no sean visibles (siguen estando las flechas, pero no los textos). En esta situación, si intentamos exportar el gráfico a un fichero jpg nos dará un error y no lo hará.

Al final, la solución, es andar con mucho cuidado:

  • Abrir StarUML sin usar el LocalFix.bat para el trabajo normal.
  • Abrir StarUML con LocaleFix.bat si queremos hacer una ingeniería inversa, pero sólo para eso y sin tocar nada más. Una vez hecha la ingeniería inversa, se salva el proyecto y se rearranca StarUML sin LocaleFix.bat

 

Dec 14

Informes de base de datos con phpMyAdmin

Antes de entrar en materia, y puesto que este post sale de ahí, seguimos trabajando con redmine. Los problemillas que encontré con redmine se solucionaron en su mayoría, puesto que es casi todo tema de configuración y ponerlo a tu gusto. De hecho, la herramienta ha tenido muy buena acogida y va a reemplazar al antiguo bugzilla, a la wiki e incluso a la base de datos de incidencias en access que tiene el cliente y el departamento de calidad.

Y ahí el tema de este post. Esa antigua base de datos de access venía con su aplicación access, que permitía generar informes muy personalizados. Redmine, una vez configurados los bugs para que tengan los campos "oficiales" de calidad, no tiene posibilidad de generar informes tan a medida. Tiene los suyos propios, que básicamente son un listado de bugs o tareas en el que puedes elegir algunos de los campos a mostrar.

Así que me puse a investigar como podríamos hacer esos informes. Por supuesto, la primera idea es hacerte tus propios scripts que accedan a la base de datos de redmine y generen el informe a tu gusto, haciendo los select que quieras y presentando la información que quieras. Pero, maravilla de las maravillas, mirando la base de datos de redmine con phpMyAdmin, un compañero mio se dio cuenta de que phpMyAdmin tiene posibilidad de crear vistas en la base de datos y de exportar a un montón de formatos (excel, pdf, csv, etc).

Y esa va a ser la forma de hacer los informes. Primero, con phpMyAdmin, haremos un select todo lo complejo que nos haga falta, con joins y wheres kilométricos, de forma que obtengamos una tabla de resultados a nuestro gusto. Luego, crearemos una vista (una especie de tabla "ficticia" en la base de datos), que contendrá ese select monstruoso. De esta forma, no será necesario escribir el select cada vez que queramos generar un informe.

Con eso estaría todo listo. Cuando queramos un informe, pulsaremos en la vista (a todos los efectos como una tabla más de la base de datos, salvo que no se puede insertar, borrar o modificar, sino sólo consultar), obtendremos los resultados y le daremos al botón de export. Habrá que crear tantas vistas como tipos de informes queramos obtener.

Más detalles de cómo hacer esto, en crear informes con phpMyAdmin.

Dec 11

iPhone con tarjeta prepago

Leo en "El Mundo" esta noticia sobre que sale el iPhone con tarjeta prepago por "sólo" 549€

¿Habrá alguien que se gaste algo más de las antiguas noventa mil pesetas en un aparatito de esos?.  Yo me he gastado cuarenta euros en un móvil que "tragara" java, sólo para jugar con j2me, y me han dolido…..

Dec 06

¿Se puede motivar a un programador?

En varias ocasiones he leido posts en varios blogs o incluso capítulos en algún libro sobre cómo motivar a un programador. Sin embargo y según mi experiencia, casi todo lo que he leído me parece teórico, sin demasiado fundamento con la realidad.

Si entendemos por motivado que una persona le guste su trabajo, tenga ganas de innovar y probar cosas nuevas, mejorar su forma de trabajo y ayudar a los demás a hacerlo, que llegar el lunes al curro no se le haga cuesta arriba, que el tiempo se le pase volando porque está centrado en lo que hace porque le divierte, pues entonces, creo que NO se puede motivar a la gente.

Según veo con mis compañeros de trabajo, los que hacen esas cosas es más porque va con su forma de ser que porque alguien les motive desde fuera. Al que le gusta programar, jugar con herramientas nuevas, aprender leguajes nuevos y tiene iniciativa, lo hace casi independientemente del entorno de trabajo, siempre que sea un entorno normal (o incluso en un entorno ligeramente hostil). El que no tiene esa personalidad, se limita a hacer estrictamente su trabajo, mejor o peor según su capacidad, y da igual que le des lo que le des. Las subidas de sueldo motivan temporalmente, un ordenador nuevo también, un proyecto interesante nada en absoluto si la persona no es de las que le gustan estas cosas, etc.

Desgraciadamente, lo que sí se puede hacer fácilmente es desmotivar a la gente. Si tienes una persona con mucha capacidad, iniciativa y que le gusta su trabajo, puedes fácilmente echarlo a perder dificultándole las cosas. Darle trabajos repetitivos y aburridos, un entorno desagradable, ordenadores especialmente viejos con monitores enano/cutres, engañándole repetidadmente con fechas de entrega falsas, obligándole a hacer horas bajo amenaza, congelándole el sueldo, etc, etc.

Así que todo esto me hace pensar que es importante tratar de que la gente esté en un ambiente agradable, trabajos interesantes y con sueldos adecuados, al menos para que no se vayan, pero que lo realmente importante, es elegirlos bien en las entrevistas de trabajo. Ver si esa persona tiene un blog o web de informática que lleve por su cuenta, preguntarle qué lenguajes de programación/compiladores tiene instalados en el ordenador de su casa aunque no tengan nada que ver con lo que van a trabajar, si hace pequeños proyectos en su casa por su cuenta y en definitiva, determinar si es un "pirado por la informática", creo que es fundamental en una entrevista.

Dec 05

Bugzilla 3.2

Ayer, en el trabajo, después de una pequeña charla sobre herramienta de bugs y bugzilla, me entró el gusanillo de reinstalar bugzilla, esta vez una versión más nueva. Tenemos desde hacer unos años funcionando la 2.22 y la actual es la 3.2, así que me puse a ello.

La instalación sigue siendo igual de compleja que antes (o casi), pero esta vez me sabía los trucos de instalación de bubzilla en windows y en vez de tres días, he tardado sólo una tarde. Eso sí, me tropecé otra vez con la misma tontería de la otra vez. Por más que le daba al navegador, siempre obtenía un "server internal error" o algo así. Revisando mis apuntes del enlace anterior, me fijé en un pequeño detalle: bugzilla busca perl en /usr/bin/perl, y ActivePerl en windows se instala por defecto en c:/Perl, por lo que no lo encontraba. Arreglado eso, funcionó a la perfección.

Luego el tema de migrar los bugs de la antigua base de datos a la nueva. Me hice un backup, lo recuperé en la nueva base de datos, le dí al script de instalación de bugzilla otra vez y este, él solito, migró la base de datos sin problemas. Bueno, un problema sí hubo, pero tonto. Decía que había un componente de un producto repetido y no pasaba de ahí. En realidad el componente estaba dos veces, con el mismo nombre, pero en uno de ellos con tilde y en el otro sin tilde. Me bastó un simple update de ese componente para cambiarle el nombre por otro parecido y la migración fue como la seda.

La configuración del e-mail, incluso a través de smt autentificado y restrictivo como el nuestro, tampoco fue compleja. Esta vez todo es configurable a través de la interface web y no hubo problemas (servidor smtp, usuario, password, campo from para los correos, etc).

Así que tenemos la nueva versión de bugzilla en marcha. Ahora es cuestión de que me decida de una vez a tirarla a la basura y usar los bugs de redmine, o no tirarla a la basura y seguir con los bugs en bugzilla.

Dec 04

Segundas impresiones con Redmine

Ya llevamos una semana larga usando redmine y ya voy encontrando algunas "peguillas". Realmente no son fallos del programa, sino que estoy mal acostumbrado a otras herramientas.

Por un lado, usamos habitualmente bugzilla, que es una herramienta específica para llevar el tema de bugs. Y por supuesto, una herramienta específica que lleva ya bastante tiempo en funcionamiento es mucho más completa y con más posibilidades que una gestión de incidencias en una herramienta que hace más cosas y es más nueva. Ahí van unas cuantas cosas que echo en falta (y que algunos compañeros me han comentado también):

  • En redmine no hay posibilidad de poner "con copia" en los bugs para que reciba el correo no solo la persona asignada, sino quizás también su jefe u otra persona que pueda saber algo sobre ese bug aunque no sea la encargada de resolverla. Parece que tampoco puede enviar automáticamente el correo semanal recordando a la gente que tiene "un montón de bugs pendientes".
  • También echo en falta la facilidad de bugzilla para cambiar estados de los bugs. Con redmine me he encontrado, por ejemplo, que no puedo reabrir una incidencia cerrada, pero no sé en qué ocasiones, porque en otras sí me deja.
  • Finalmente, la posibilidad de generar informes con las incidencias, no es que bugzilla sea ninguna maravilla generando informes, pero tiene más posibilidades que redmine.
  • Tampoco parece muy lógico en redmine que mezcla los comentarios de resolución de incidencias/tareas con comentarios de cambios en el porcentaje de tiempo invertido en la tarea. Si miro la historia de una incidencia/tarea, veré consecutivamente todos los comentarios asociados, tanto específicos de la resolución, como de cambios de tiempos.

En cuanto a la wiki integrada en redmine, estoy acostumbrado a usar mediawiki, otra herramienta específica de wiki con mucha andadura (de hecho, es la que usa wikipedia). No he usado demasiado la wiki de redmine, pero da la impresión de ser más sencilla que mediawiki.

Así que todo esto me está haciendo replantear algunas cosas:

  • Seguir usando redmine, pero sólo como herramienta de planificación, con hitos, versiones y tareas a realizar.
  • Seguir usando bugzilla para los bugs, pero sólo bugs de los que son fallos, no mejoras.
  • Usar la wiki de redmine para especificaciones y cosas propias de los proyectos. Seguir usando mediawiki para cosas más generales no específicas de un proyecto concreto, como guía de estilo, de buenas costumbres, tutoriales, normas generales a seguir en todos los proyectos, etc.

No me gusta lo de tener las tareas por un lado y los bugs por otro, así que le daré otra "pensada" al tema.