Diario de Programación

Entre las herramientas que usamos habitualmente, está Hudson como herramienta de integración continua. Tiene un montón de plugins para instalar y de vez en cuando me dedico a jugar con ellos, para ver qué hacen, alegrar un poco el día a la gente poniendo algún plugin divertido, o haciéndoles tirarse de los pelos cuando necesitan hudson y no está disponible porque le he instalado una cosa que no va.

Entre los plugins, recientemente instalé dos, el de Chuck Norris, que hace que aparezcan fotos de Chuck Norris contento si la compilación ha ido bien, o cabreado si ha ido mal, aparte de poner frases aleatorias estilo "Chuck Norris’s first program was kill -9". También puse otro similar, pero con fotos de chicas.

Pues bien, justo ayer, cinco minutos antes, me llaman por teléfono que van a venir de una auditoría de software para ver, entre otras cosas precisamente el Hudson. Así que, como un loco, mirando qué fotos salían en los proyectos para enseñar sólo proyectos de Chuck Norris, no vaya a ser que algún auditor/a se me mosqueara o mosquease.

Hace ya un mes largo me llamaron a una reunión en la que íbamos los posibles candidatos para hacer un nuevo proyecto, previsiblemente en java. El proyecto consiste en hacer unos bancos automáticos de prueba para unos equipos electrónicos que se van a empezar a fabricar en serie. ¿Adivináis a quién le ha tocado el fregado de entre todos los candidatos?.

Así que nada, he cambiado totalmente de tercio. He pasado de hacer ventanas Swing en java a controlar equipos de instrumentación electrónica (analizador vectorial, fuente de alimentación, generador de señal….) y llevo más de un mes en ello, junto con algunos de mi grupo.

Por un lado estaba la posibilidad de tener que controlar un puerto RS-485, (similar a un puerto serie RS-232 pero de otra manera). La librería a usar RXTXcomm, pero después de unas pruebas y ver que funciona correctamente, me comentan que vamos a comprar un conversor de serie a lan, de forma que podemos hablar con el equipo con puerto serie a través de un socket normal de lan.

Por otro lado, los otros equipos de instrumentación tiene conexión lan directamente y el protocolo de mensajería para controlarlos es estándar, SCPI. La verdad es que es muy tonto, se abre un socket normalito y se mandan comandos de texto terminados en un retorno de carro. El equipo devuelve también comandos de texto terminados en retorno de carro. De hecho, hay posibilidad de conectarse con un vulgar "telnet", escribir los comandos a mano y leer en el mismo terminal las respuestas.

Lo curioso del caso es que hace algo más de 15 años, cuando empecé a trabajar, empecé precisamente controlando instrumentación electrónica para bancos automáticos de pruebas (de aquella en BASIC y con una versión primitiva de LabWindows), Y estoy alucinado de los cambios que ha habido en este mundillo. Antes un osciloscopio era una cosa con botones gordos, pantalla de fósforo verde y un tubo de rayos catódicos. Ahora un analizador de espectros tienen un display LCD, con un Windows XP metido y una aplicación que arranca al encenderlo. Por supuesto, viene con conexión lan y un pequeño servidor web, de forma que desde tu PC y con un navegador "vulgaris" puedes acceder al equipo y controlarlo.

En fin, me lo estoy pasando como los indios (aunque diga que me aburro al programar según las buenas costumbres) y siempre viene bien un cambio de actividad para renovar los ánimos (aunque siga siendo java).

Es increíble, pero si me pongo a programar de acuerdo a las buenas costumbres (TDD, DRY, métricas, clases pequeñas, código reutilizable, etc), el trabajo de programador se me hace aburrido y pesado. Pierdo más tiempo pensando cómo debería ser el código que en hacerlo.

Me divierto más cuando me lanzo a lo loco, sin pensar y programo/corrijo código según salen las cosas, veo rápidamente resultados y juego sobre ellos.

Pobre del que coja mi código después….

Leyendo este post Potencia tu equipo (4) Evita jerarquías y especialistas, no me he podido resistir a hacer mis propias reflexiones al respecto, basadas en lo que he ido viendo durante muchos años de hacer software, viendo como los grupos y departamentos se hacen y deshacen para tratar de mejorar las carencias de la organización anterior.

Mi idea final es que no hay organización buena o mala, sino gente buena o mala. Las cosas no son blancas ni negras, cada organización tiene sus ventajas e inconvenientes, puede ser mejor o peor según para qué, pero al final funciona bien o no dependiendo de la gente que la integra.

Los grupos de especialistas tienen la ventaja de que acaban desarrollando su parte de código muy rápido, puesto que se la conocen perfectamente, y que de forma natural hacen sus propias librerías, ya que ellos mejor que nadie son capaces de ver qué cosas necesitan reutilizar siempre tal cual, cuales pueden reutilizar con algo de configuración y cuales cambian constantemente de un proyecto a otro. Y esta es la pega que he visto cuando se hacen grupos multi-disciplinares. Esos grupos tienden a trabajar aislados y no realizan tantas librerías comunes. Distintas partes de un mismo proyecto tienden a no parecerse unas a otras ni en la manera de funcionar, ni en aspecto visual, ni el estilo del código. Siempre acaban perdiendo bastante tiempo rehaciendo y uniformizando todo más adelante. Al final puedes ver un ejemplo real de falta de uniformidad.

Pero el trabajo por grupos multi-disciplinares tiene una ventaja enorme de la que carecen los grupos de especialistas. Al haber un grupo responsable de una funcionalidad, hay un grupo que se preocupa de que esa funcionalidad vaya bien totalmente. Cualquier bug que aparezca tiene un claro responsable (el grupo) y se suele corregir rápido. En los grupos de especialistas la integración puede/suele ser un infierno. No hay un responsable claro de la funcionalidad y cada grupo se limita a ver que su parte funciona y soltar "el marrón" a otro de los grupos. El resultado es que los bugs tardan mucho en corregirse y es fácil llegar a peleas entre miembros de distintos grupos o incluso grupo contra grupo.

Con todo esto quiero decir que las cosas no son ni blancas ni negras. Cada forma de trabajo tiene sus ventajas e inconvenientes y que debemos estar muy pendientes de los inconvenientes para no dar al traste con el proyecto.

Y lo más importante, la gente. No debes caer en el tópico de que si hacemos una estructura jerarquizada no va a funcionar porque el jefe será un torpe, pero si hacemos un grupo auto-gestionado va a funcionar todo de maravilla porque todos son guays. Cada uno es como es. El usar metodologías ágiles no hace que nadie sea más "guay". Ni hacer un grupo jerarquizado hace que el jefe sea torpe. He visto grupos jerarquizados funcionar estupendamente porque el jefe es capaz de tener a la gente contenta, dejarles las decisiones técnicas que no controla y haciéndoles rendir a tope (en su horario normal). Quizás no es lo habitual, pero tampoco son más habituales los grupos scrum que realmente funcionan como scrum que los que no lo hacen. Como digo, es cuestión de la gente (sea jefe o scrum master).

Da igual qué tipo de organización elijas, funcionará o no dependiendo de la capacidad y predisposición de la gente que haya en ellas. Un grupo jerarquizado funcionará muy bien si el jefe es competente. Los grupos de especialistas funcionarán muy bien si hay "buen rollo" entre ellos a la hora de integrar. Los grupos multi-disciplinares funcionaran muy bien si hay buen rollo entre ellos a la hora de uniformizar las cosas.

Y quiero poner un ejemplo real de falta de uniformidad al hacer las cosas distintos grupos sin comunicación fluida entre ellos. Una ventana con cuatro botones juntos, cada botón hace una cosa distinta y cada botón realizado por un grupo distinto. Lo único común que tienen esos botones es que realizan una consulta a base de datos y muestran una ventana de resultados. ¿Cual fue el resultado real?

1. botón 1. Si no hay resultados en bd, no hace nada.
2. botón 2. Si no hay resultados en bd, saca una ventana de aviso indicándolo.
3. boton 3. Si no hay resultados en bd, saca la lista de resultados vacía.
4. botón 4. Si no hay resultados en bd, saca una ventana de aviso indicándolo y la lista vacía.

Me habría gustado que hubiera un quinto botón y un quinto grupo, para ver por dónde salían.

OSGI es una de esas cosas de las que quería enterarme de qué iba y aprovechando el manual de OSGi de Roberto Montero publicado en javahispano, me he puesto a ello.

El manual, para alguien como yo que tiene ciertos conocimientos de java y no le suenan a chino cosas como fichero de manifiesto, classloader o maven, pero que no tiene ni puñetera idea de qué es OSGi, está muy bien. Da una explicación desde el principio y mostrando un ejemplo "Hola Mundo" en diversas plataformas y con distintas herramientas (Equinox, Apache Félix, Eclipse, Pax Constructor, etc). Al final me queda más o menos claro qué es OSGi y sólo queda hacerme mis propios ejemplos y pruebas.

La idea básica de OSGi es que es una forma de desarrollar aplicaciones java a base de hacer módulos más o menos independientes, pero que pueden colaborar entre ellos. Estos módulos (llamados bundles) no son más que jars con algunas clases especiales propias de OSGi y un fichero de manifiesto con campos especiales, que entiende OSGi. Los bundles pueden colaborar entre ellos, indicando qué paquetes java exportan a otros módulos y qué paquetes java de otros módulos necesitan. Una plataforma que implemente OSGi (Equinox o Apache Félix entre otras) es capaz de cargar, arrancar o parar estos módulos en tiempo de ejecución, sin necesidad de tirar la aplicación y volver a arrancarla. También es capaz de saber qué módulos dependen de cuales para pararlos si les faltan dependencias o arrancarlos sólo cuando todas sus dependencias están cargadas.

Sin embargo hay un problema que tengo de hace mucho y que veo que OSGi no me va a solucionar. Cuando hay dos módulos (jars) que se quiere que colaboren, al final no queda más remedio que uno de ellos vea (necesite) al otro para compilar, ya que si un módulo usa otro, debe ver al menos alguna interface o tipo de dato. Esto hace que los módulos no sean realmente independientes y no puedas aprovechar un módulo para otro proyecto. Si en otro proyecto quiero llevarme el móudlo A y este tira de una interface de B, pues me tengo que llevar B también y éste, desgraciadamente, en una de sus clases que no necesito para nada, tira de una interface del módulo C y así sucesivamente. Para proyectos grandes con muchos programadores (expertos y novatos), lo normal es que todos los módulos acaben dependiendo de todos e incluso empiece a haber dependencias cruzadas. Sí, ya sé que "sólo" es cuestión de pensar antes que módulos debe haber, cómo dependen unos de otros y "sólo" hay que conseguir que todos los programadores respeten esa arquitectura.

Una posible solución, que había descartado, para este problema es que cada módulo fuera en realidad dos módulos. Uno pequeño, con sólo las interfaces y clase de datos (beans) que es lo que dependerían los demás módulos. Y otro módulo más grande con todo el resto del código. Lo descarté porque en un proyecto grande con 30 o 40 módulos, se nos duplica el número de módulos y de jars.

Sin embargo, en los ejemplos OSGi que he visto, parece que hace eso mismo. Si crea un módulo que es un servicio que van a ver otros módulos, crea dos módulos: uno con la interface del servicio y los bean de datos, el otro con la implementación. Los módulos que usen servicios de éste, sólo dependen del módulo pequeño con la interface.

En fin, a jugar un poco con OGSi y a repensar esto de partir los módulos en dos submódulos: lo visible al exterior y la implementación concreta.

 Al final me ha pasado como casi siempre. Empecé una aplicación por jugar con grails y cuando grails dejó de interesarme (ya había visto cómo era y sólo quedaba "currar"), dejé la aplicación a medias.

Y como me suele suceder siempre que tengo una aplicación a medias, no avanzo en ella porque ya no me apetece y no empiezo otra cosa nueva porque no he acabado la anterior.

Esto me pasaba con las novelas cuando una no me gustaba, la tenía a medias y no me ponía con ella porque no me gustaba, pero no empezaba otra nueva porque tenía la anterior a medias. Hasta que alguien me dio un sabio consejo: "Si una novela no te gusta, tírala a la basura y empieza otra, hay demasiadas novelas buenas como para sufrir con una que no te gusta".

Así que después de un mes de inactividad en mi proyectito grails ChuKanBoard (un tablero Kanban vía web), veo el momento de aparcarlo tal como está y buscar algún nuevo proyecto con alguna nueva herramienta para probar.

Tienes en http://wiki.github.com/chuidiang/ChuKanBoard/ el proyecto, con sus fuentes accesibles con git, con un war para descargar en la página de descargas y unas pequeñas instrucciones de instalación y uso en la wiki, junto con una foto y un video de demo (el video es de una versión algo anterior, pero ya se parece lo suficiente).

Y como siguiente proyecto/herramienta, tengo tantas en la cabeza, que posiblemente tarde un mes en decidirme por uno.

Me van a dar un ordenador nuevo y para dármelo configurado, me ha llamado por teléfono uno del departamento de informática, que si le podía dar mi contraseña corporativa. Le he contestado que esperara tres segunditos, que estaba poniendo el pin de mi tarjeta de crédito en un correo de caja Madrid que me lo solicitaban.

Creo que no entendió la indirecta…