Diario de Programación

Bueno, ya estoy con el nuevo ordenador, el que mencioné en el post anterior. Por supuesto, hay muchos problemas y no va todo como debe, pero son las cosas habituales de los ordenadores y la informática.

Lo de windows vista, tendré que acostumbrarme. Al menos, de momento, pregunta demasiadas cosas cada vez que haces algo, por tonto que sea, como arrancar otro programa. Tampoco es capaz de ver mi disco interno de datos que extraje del ordenador antiguo. El de antes, con windows 2000 lo veía perfectamente. Con linux veía una de las particiones y la otra tenía que montarla a mano.

El teclado que viene con el ordenador no es ninguna maravilla. Las teclas son un pequeño asquito, de esas que parece que cuesta apretarlas y que el <intro> como que se atasca y hay que darle con energía. El ratón bien.

Por lo demás, todo bien. El ratón es luminoso -de esos que no llevan bola-, el ordenador arranca rápido. La sintonizadora de TDT que lleva funciona bien, aunque eso del windows media center me cuesta un poco. Lleva muchos conectores por delante, incluidas las ranuras para las tarjetas de cámara de fotos.

Ahora toca acabar de ponerlo todo a mi gusto: instalar firefox y thunderbird, java, eclipse, etc. Y sobre todo la partición para linux. El primer intento con partition magik ha sido un pequeño fracaso, ya que hace rearrancar el ordenador, da un error y vuelve a rearrancar y así hasta que tres veces, en las que me he hartado. Al menos he podido cancelarlo y se ha quedado todo como estaba. Tendré que probar con el gparted.

Bueno, el ordenador acabó de fastidiarse del todo. Tiene voltios y hace ruiditos, pero no arranca, ni en windows ni en linux. Tiene pinta de haberse fastidiado el disco C.

De todas foras, aunue el arreglo fuese fácil -cambiar el disco C-, el ordenador era un poco viejo: pentium IV y 128 M de RAM, con la placa base tocada -no funcionaban los USB-. Por eso he decidido que mejor me compro uno.

Dicho y hecho. Ayer pasé por el BEEP de debajo de casa, hablé un poco con el tio y le encargué uno. Desmonté el viejo, le saqué la grabadora de DVD, el disco duro D de 120 Gigas y hoy se lo llevaré para que los monte en el nuevo.

Ya contaré qué tal el nuevo ordenador. No me convence mucho eso de Windows Vista….

Hay días en que parece que todo se tuerce, sobre todos los "chismes" electrónicos. En esos días pienso que lo mejor sería dejarlo todo y dedicarse a pastor de ovejas, sin móvil, de los de antes.

• Recién comprada una nintendo DS para mi hija, se da un golpe y se le fastidia un botón. Por supuesto, el golpe se ve y ni la cambian ni vale la garantía.
• Se me ha ido al garete el ordenador. Windows empieza a arrancar y cuando está a punto de terminar, se resetea el ordenador.  Lo de reparar windows y demás desde el CD me hace lo mismo. Sin embargo, con linux funciona….
• Por primera vez en año y pico, mi banco rechaza el recibo del hosting. No es grave, pero si el incordio de tener que pagar ahora de alguna otra manera y visita al banco a ver qué ha pasado.
• Esta mañana se fastidió la antena de la tele, se ve todo en blanco y negro y con mucho grano.

y todo eso sólo en un par de días -desde el Sábado hasta hoy-.

Así que estas vacaciones me iré a algún sitio de lo más rural posible, de esos en que las casas ni siquiera tienen luz, me olvidaré de pitiditos electrónicos y me dedicaré estar tumbado a la bartola todo el día.

Aunque en muchas metodologías se comenta la necesidad de hacer diseño detallado, el que se hace realmente suele consistir en comentar con tus compañeros que vais a hacer. Normalmente en esas "reuniones" participan también el papel y el lápiz y estos suelen ser los resultados:

Un diseño detallado en una versión "libre" de UML:

y aquí otro diseño detallado, esta vez de la interface de usuario.

He estado mirando herramientas de gestión de proyectos en web. He encontrado y comparado -por encima- dotProject y PHProjekt. Ambas son php, se instalan en un servidor web con php y base de datos y son accesibles desde navegador.

Ambas son fáciles de instalar, basta con desempaquetar el zip en nuestro sitio web, crear a mano una base de datos en la base de datos que tengamos y visualizar la página. En ambas nos salen una serie de pantallas para configurar todo, en las que nos piden nombre de la página, de la base de datos, usuario y password de la misma, etc.

Me sorprendió gratamente PHProjekt en el sentido de que está todo en Español. Después de pelearme con la página http://www.phprojekt.com que está en alemán y aunque la pongas en inglés, insiste en pasarse a alemán cuando te descuidas, no esperaba que el programa estuviera en español.

En dotProject, para obtener los gráficos, fue necesario activar el módulo GD support de php. Para ello -mi php es sobre windows-, me bastó con descomentar la línea extension=php_gd2.dll del fichero php.ini y reiniciar el servidor apache. Con esto se pueden ver gráficos de gannt.

Una vez instalados, me ha parecido mucho más intuitiva y me ha gustado más dotProject.  Quién sabe, quizás lo de intuitiva es porque está en inglés y para estas cosas siempre estamos más acostumbrados a los nombre en inglés…. El caso es que con dotProject fui haciendo cosillas sin problemas y a la primera, mientras que con PHProjekt tuve que andar con ensayo y error para conseguir lo que quería.

En dotProject defines primero compañías, que pueden ser la tuya o con las que tienes relación. Luego defines proyectos para cada compañía. También añades personas indicando en qué compañía trabajan. Para cada proyecto vas definiendo tareas, poniendo fecha de inicio y fin, dependencias entre ellas, subtareas, etc. Cada tarea la asignas a un proyecto y a una o más personas.

Al final, viendo un proyecto dado, puedes ver una lista de tareas para hacer, con sus tiempos y porcentaje de progreso. Se puede visualizar un gráfico de gannt de dicho proyecto. Lo que no me queda claro si lo hace bien o mal, aunque parece que puede hacerlo, es recalcular los tiempos y fechas de las tareas en función de las dependencias de unas y otras.

Otra cosa que me llamó la atención de estas herramientas es que tanto dotProject como PHProjekt tienen la posibilidad de crear foros y gestión de bugs.

Puedes crear foros para temas de un proyecto. Supongo que es para que la gente que trabaja en el proyecto pueda discutir y quede constancia por escrito sobre decisiones o problemas en el desarrollo de las distintas funcionalidades del proyecto.

En cuanto a los bugs, también se pueden gestionar con el mismo programa. Se pueden crear bugs nuevos, añadir comentarios, etc. En teoría -no he conseguido configurarlo correctamente por culpa de mi proxy y servidor smtp- también envía correos a las personas implicadas en los bugs.

Seguiré probando un poco más con dotProject…

Cuando queremos pintar nuestros gráficos en java, lo normal es redefinir el método paint() de algún componente. En este método recibimos un clase Graphics como parámatro que tiene montones de métodos para dibujar.

Sin embargo, hay una cosa que quizás no es tan conocida. Esa clase Graphics que recibimos, en las versiones modernas de java es en realidad una clase Graphics2D. Esta clase tiene muchísimas más posibilidades de pintado.

Una posibilidad tonta, es la de poder dibujar líneas gruesas. Aquí un pequeño ejemplo tonto de como hacerlo. Heredamos de alguno de los Component de java y redefinimos el método paint() así

public void paint (Graphics g)
{
   if (g instanceof Graphics2D)
   {
      Graphics2D g2 = (Graphics2D)g;
      g2.setStroke(new BasicStroke(5.0f)); // grosor de 5 pixels
      g2.drawLine (10, 10, 100, 100);
   }
}

Esto dibujará una línea de 5 pixels de grueso.

Otra posibilidad muy interesante de Graphics2D es la posibilidad de pasarle una clase AffineTransform. Esta clase define un "transformación" de las coordenadas, de forma que cualquier cosa que dibujemos de la forma habitual, se "deforma" siguiendo esa transformación. Podemos agrandar, alejar, trasladar, cizallar o rotar las figuras. Podríamos, por ejemplo, dibujar un texto o un cuadrado girados cualquier ángulo en cualquier sentido.

Aquí puedes ver un ejemplo un poco más detallado de cómo usar la clase AffineTransform.

Cuando presentamos un diálogo secundario es importante ponerle un padre adecuado, de forma que este diálogo no se vaya detrás de la ventana principal. Esto es particularmente importante si vamos mostrando diálogos modales uno detrás de otro, si no queremos "efectos especiales" desagradables, como que el usuario no pueda usar ninguna ventana.

Se nos presenta un pequeño problema, especialmente con los JOptionPane, si presentamos mensajes de error que no tienen que ver con la pulsación directa de un botón o de alguna acción sobre otra ventana. Imaginemos que como consecuencia de una consulta a base de datos, la llegada de un mensaje de un socket o la lectura de un fichero debemos mostrar un diálogo de error con JOptionPane, que es modal. ¿Qué ventana ponemos como padre?

Una opción es poner como ventana padre la que esté activa en ese momento, es decir, la que tenga el foco del ratón. La clase KeyboardFocusManager nos ayuda a obtener esta ventana. Los métodos getActiveWindow() y getFocusedWindow() nos devuelven la ventana en cuestión. No sé muy bien la diferencia entre un método y otro, no entiendo muy bien qué quiere decir la API, pero para este caso concreto con los experimentos que he hecho, parece portarse mejor getFocusedWindow().

Si por un socket recibimos un mensaje que nos obliga a mostrar un JOptionPane de aviso, el código puede ser así

Window ventanaActiva = KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusedWindow();

// si no hay ventana activa, cogemos el Frame por defecto.
if (ventanaActiva == null)
   ventanaActiva = JOptionPane.getRootFrame();
JOptionPane.showMessageDialog(ventanaActiva, "Esto es un aviso");

Esto mismo está en KeyboardFocusManager y Diálogos Modales.

En su momento estuve mirando plugins de UML para eclipse, pero ninguno me convenció, hacían demasiado lento eclipse o eran demasiado cutres. Así que me he decidido a buscarlas por separado, independientes.

Por supuesto, tenemos Together -que creo que ahora va con JBuilder-, y Rational, pero son muy, muy caras.

Como gratuitas, he probado ArgoUML, que es sencilla de instalar y tiene ingeniería inversa. Sin embargo, me da problemas en cuanto hago una ingeniería inversa de un centenar de clases. Supongo que es cuestión de investigar cómo arrancarla con más memoria. Tampoco me ha parecido demasiado intuitiva. Quizás sea porque las herramientas UML con las que he trabajado suelen tener otra organización de las cosas.

Me ha gustado más StarUML, se parece más a las que estoy acostumbrado y es nativa, pero tiene un pequeño problema con las comas y los puntos -cosas del idioma-. Se arregla con un LocaleFix.bat que alguien ha hecho. Al final y de momento, creo que esta es la herramienta gratuita por la que me decido.

También probé Netbeans, que en su versión 6.0 viene con UML -creo que está en beta-, mientras que se puede añadir dicho UML a la actual estable, la 5.5.1. Me ha  sorprendido gratamente, no sólo el UML, sino el entorno en sí. Hace años trabajé con él y lo dejé para pasarme a eclipse. Veo ahora que netbeans ha mejorado bastante. En cuanto al UML de netbeans, parece bastante más robusto y potente que el StarUML o el ArgoUML, pero hay una cosa que no me ha gustado. Pone los diagramas demasiado bonitos, con muchos colorines. Supongo que es configurable.

Lo que sí tengo que pensar, ahora que he visto netbeans, es si le doy otra oportunidad. Quizás me cambie de entorno uno o dos meses para comparar con eclipse.

Una cita que me ha parecido curiosa.

Mientras que el desarrollo de software es inmune a la mayoría de las leyes físicas, la entropía nos golpea con fuerza. La entropía es un término de la física que se refiere a la cantidad de "desorden" en un sistema. Desgraciadamente, las leyes de la termodinámica garantizan que la entropía en el universo tiende al máximo. Cuando el desorden crece en el software, los programadores lo llaman "software basura".

 "The Pragmatic Programmer".

Me decido a escribir este post viendo los comentarios del post anterior y porque los test unitarios también es otra cosa en la que tengo interés. También tenemos que ir poniéndolos.

Estoy de acuerdo en que es muy difícil hacer determinados test -e incluso unos pocos bien hechos-, pero también es cierto que hacer el código de cierta forma ayuda a hacerlos.

Por ejemplo, si tengo una clase que instancia una clase de sockets, lee un mensaje de ella, actúa en consecuencia y como resultado envía otro mensaje con, no podré hacer un test fácilmente, salvo que en el test construya el servidor del socket y lo lance. Y quizás no pueda hacerlo, porque el servidor igual debe correr en otro ordenador y no puedo lanzarlo desde mi clase de test en remoto. Sin embargo, si tengo mi clase de socket que implementa una interface y luego se la paso a la clase que quiero, esa clase es más fácil de probar. Desde el test puedo simular la clase de socket con otra hecha a mi medida -creo que se conoce en este mundillo como mock-object- y que implemente la interface. Esta clase simulada de socket puede devolver un mensaje a medida cuando la clase de prueba intente leer y esta clase simulada recibirá los que la clase de prueba intente enviar, por lo que sí puedo comprobar como se comporta la clase sin necesidad de tener el socket abierto.

Para testear la clase de socket, sí puedo instanciar dos sockets en la clase de test de forma que se comuniquen entre ellos. Claro, siempre que la clase de socket sea suficientemente configurable como para indicarle que el servidor es "localhost".

Con base de datos pasa algo parecido. Si la clase consulta o inserta directamente, es difícil probar salvo que tengas la base de datos. Si haces una clase con interface que es la encargada de realizar las inserciones y consultas, es posible pasarle un mock-object de la clase de base de datos a la clase bajo prueba, con lo que se podría hacer alguna prueba sin necesidad de tener la base de datos y teniendo los datos controlados -es el mismo mock-object el que devuelve los datos a nuestra medida o el que recibe lo que la clase bajo prueba intenta insertar.

En fin, no digo que sea fácil y que no requiera trabajo, pero muchas veces el cómo se hace el código ayuda, dificulta e incluso hace imposible el hacer los test.