Diario de Programación

Veo en Arragonán que hay una cosa que se llama Wordle, a la que le das la dirección de tu blog (o de cualquier página web que tenga un feed o rss) y te saca una nube de tags. He hecho la de este blog y aquí va el resultado.

En su día, para nuestros proyectos grandes, teníamos muchas librerías y módulos separados. Cada programador solía ser responsable de uno de los módulos y tenía su proyecto independiente, con sus programas de prueba, simuladores y todo lo que le hiciera falta.

Eso estaba bien, pero tenía una ligera pega. No usábamos algo como maven y no teníamos control ninguno de dependencias cruzadas. Cada programador ponía sus dependencias de otros módulos según lo necesitaba. El problema, al final, es que no había forma de compilar eso desde cero, ya que era fácil que un módulo necesitara del jar de otro módulo, que a su vez necesitaba de un tercero y tras una cadena más o menos larga, había un módulo que necesitaba del jar del que estamos compilando. Sí, ya sé que es una falta grave de diseño y debería haberse pensado al principio y dejar claras esas dependencias, pero también es cierto que entre lo que lo pensado antes y la realidad después hay muchas diferencias.

Al usar maven, decidimos hacer un proyecto grande con subproyectos debajo (uno por módulo). Así maven comprueba las dependencias y si un programador pone una dependencia que no debe, maven le protesta. Sin embargo, esto también tiene una gran pega. El compilado desde cero se hace desde arriba del todo y el fallo de un módulo hace que los demás ni siquiera intenten compilar. Además, la dependencia se hace entre fuentes, por lo que para estar a la última, necesitas hacer update de todos los fuentes. Eso, en un proyecto grande, puede ser un buen rato casi todos los días.

Al descubrir que se puede usar el core de Spring Framework, aunque sean aplicaciones de escritorio, para instanciar los módulos y usar los eventos de Spring Framework para comunicarlos entre sí, me da la impresión de que se puede hacer relativamente fácil que los módulos hablen entre ellos y se pasen datos sin necesidad de que tengan dependencias entre ellos. Los primeros mini-proyectos en la que hemos usado este framework y hemos hecho módulos indpendientes totalmente, comunicados a través del framework y de código de transformación de tipos de datos de un módulo a los tipos del otro en el main, están resultando una pequeña maravilla en cuanto a organización.

Así que me estoy planteando el volver a módulos separados, en proyectos independientes, y con prohibición de poner dependencias de otros módulos, salvo algunos muy concretos pensados más como librerías comunes que como módulos a instanciar como beans de Spring Framework.

La pega es la de siempre, la paliza de mover todos los repositorios de CVS para que tengan otra estructura y el retocar todo el código, sobre todo quitando dependencias de unos módulos con otros. Todo se andará, poco a poco.

Una pequeña aclaración sobre las dependencias entre módulos. Suponamos que tenemos modulo1.jar y modulo2.jar y que modulo1.jar necesita llamar a cosas de modulo2.jar. Para no meter la dependencia a lo bestia, normalmente hacemos una InterfaceModulo2 con las llamadas a las cosas del módulo2 que sean de interés desde fuera. Por supuesto, esa interface está en modulo2.jar. Y por supuesto, los parámetros y retornos de los métodos de la interface son tipos primitivos de java o bien tipos que están en modulo2.jar. Pues bien, eso hace que modulo1 dependa de modulo2, ya que ve al menos a la interface y a los tipos de parámetros y retornos. Por supuesto, una opción es hacer un tercer módulo InterfaceModulo2.jar con la interface y los tipos, pero me parece multiplicar el número de jars a lo tonto.

La opción que estamos planteando ahora es que modulo1 no vea en absoluto a modulo2. Cuando necesite algo de módulo2 (en realidad, cuando necesite algo, lo que sea), debe lanzar un "evento" indicándolo. Es el código del main el encargado de recoger ese evento y hacer la petición a modulo2, para pasar luego los resultados a módulo1. Esto puede parecer costoso, sobre todo si hay mucha necesidad de cosas de modulo2 por parte de modulo1, pero… si hay tanta necesidad de cosas ¿no estará mal pensado hacer dos modulos? ¿no estará mal pensada la funcionalidad de cada módulo?.

En fin, un pequeño rollo, pero como indico en el título, son símplemente "pensamientos".

Hace algunos meses descubrí Git y empecé a oir hablar de los sistemas de control de versiones distribuidos. Me quedé con las ganas de echarle un ojo con más calma y ver qué era exactamente eso, qué ventajas aporta y si merece la pena usarlo. Sin embargo, me echaba atrás el que Git sólo estuviera disponible para linux. Para windows había que usar cygwin o bien con cosas como msysgit.

Gracias a un comentario del post anterior, descubro Bazaar, con soporte para linux y windows, con una documentación bastante agradable y sobre todo, con fama de ser fácil de usar. Así que me puse a jugar con ello.

La instalación en Windows muy sencilla con el instalador. En Ubuntu con el gestor de paquetes synaptic también (eso sí, hay que buscar "bzr" que es el comando de línea de comandos para Bazaar (como cvs, o svn en CVS o Subversion).

Cogí uno de los proyectos que tengo en Java y cree el primer proyecto con Bazaar. Fue realmente sencillo, basta con situarse en el directorio del proyecto ya creado y ejecutar los comandos

$ cd /home/chuidiang/PROYECTO
$ bzr init
$ bzr add
$ bzr commit -m"Primera version"

Todo fue de perlas. Sin necesidad de instalar ningún servidor ni nada parecido ya tengo mi primer proyecto (ya existente previamente) bajo el control de versiones de Bazaar.

Me voy ahora a otro directorio y pruebo a "sacarlo". También es sencillo

$ cd /tmp
$ bzr branch /home/chuidiang/PROYECTO RAMA_PROYECTO

Y ya tengo mi copia de trabajo en /tmp.

Aquí empieza, además, la primera diferencia con un sistema de control de versiones normal. Si hubiese ejecutado el comando bzr checkout en vez de bzr branch, habría extraido en /tmp el proyecto de forma similar a CVS o SVN. Cualquier commit que hiciese, se haría directamente en /home/chuidiang/PROYECTO, como si fuese el servidor o repositorio central. Sin embargo, al hacerlo con bzr branch, tengo ahora en /tmp una copia completa e indpendiente del proyecto original en /home/chuidiang/PROYECTO. Puede hacer commits independientes en un lado y en otro, cada uno con su propia historia y sus propios comentarios.

Sin embargo, tenemos más comandos de Bazaar, como bzr push, bzr pull, bzr merge, etc que permiten tanto a uno como a otro, traerse los cambios hechos en el otro proyecto, o bien llevarse tus propios cambios al otro proyecto.

Con un sistema de control de versiones distribuido tenemos libertad de organizar los repositorios del proyecto como queramos. Podemos o no poner un repositorio central y los desarrolladores pueden llevar sus propias ramas, intercambiarse unos con otros los fuentes antes de llevarlos al repositorio central y cualquier combinación que se nos ocurra.

Por ejemplo, suele ser buena idea tener un repositorio central donde esté la última versión en condiciones del proyecto. Los desarrolladores, con bzr branch se hacen sus propias copias y repositorios locales. Tocan, prueban y hacen commits locales todas las veces que quieran, conservando toda la historia de sus ficheros. Cuando todo está en condiciones, llevan su copia local al repositorio central, donde se actualizará con toda la historia local del desarrollador.

Es más, dos desarrolladores trabajando en una funcionalidad común, pueden actualizarse sus repositorios locales de uno a otro todas las veces que haga falta. Cuando sus copias locales estén en condiciones, las pueden subir al repositorio central. Se evita así, que estos desarrolladores tengan que compartir código todavía no probado subiéndolo previamente al repositorio central.

En fin, una pequeña maravilla, abierta a tantas posiblidades como seamos capaces de imaginar.

Hace unos días comentaba si la habría cagado al aceptar un puesto un poco más de "jefecillo" que antes. Y efectivamente, compruebo que la he cagado. La prueba de ello es que en vez de hacer código, me estoy dedicando a mirar cosas como statcvs, una herramienta que mira el log de todos los commits que se han hecho en un proyecto en CVS y luego saca un montón de gráficos molones, inútiles, pero molones.

Aquí van unos cuantos ejemplos. El siguiente es un gráfico que muestra los commits como puntitos de varios desarrolladores a lo largo de cerca de cuatro años. Me he cargado el nombre del proyecto y de los desarrolladores, por  aquello de la discrección. En cada gráfico, el eje y son las horas del día, de 0 a 24. En el eje x son los días a lo largo de los años. El primer gráfico, de puntitos azules, muestra el total de commits del proyecto. Los siguientes, con puntitos rojos, cada uno de los desarrolladores.

Llama la atención el tercer desarrollador, que se fue a teletrabajar hace un año. Se nota claramente que desde ese día NO tiene horarios. Antes hacía commits de 8 a 6, horario de oficina. Ahora es habitual que haga commits a la una de la madrugada.

También llama la atención el último, con una densidad de commits especialmente alta. Se ve que es amigo de CVS. Curiosamente, se ve una pequeña franja horizontal sin commits, correspondiente a la hora de comer.

En el sexto desarrollador, hacia el principio del gráfico, también se ven unos días de agobio. con un commit pasada la media noche.

También se ve, gracias a Dios, que en mi empresa tenemos un horario en general normal. Son raros los commits más allá de las seis de la tarde.

y en este otro gráfico, se ve cómo han ido añdiendo líneas de ćodigo en otro proyecto distintos desarrolladores. Las grandes subidas se deben posiblemente a copy-paste de otros proyectos (vergüenza) o bien a "refactoring" intensivo, a base de mover grandes fuentes bloques de fuente de un sitio a otro (espero que sea eso). En la parte baja estaba el nombre de los desarrolladores, asociado a cada una de las líneas de color, pero me los he cargado.

y aunque no he puesto ejemplos, también hay gráficos para cada desarrollador indicando en qué horas del día mete más en CVS o en que días de la semana. Aunque en general este tipo de gráficos si es más o menos aleatorio, a veces se ve gente que tiende a meter en CVS los viernes, o bien justo antes de comer o de irse a casa por la tarde. Supongo que eso también es una mala costumbre, da la impresión de que no meten el código cuando lo han probado bien, sino como una especie de "backup" de su trabajo diario, metiendo en CVS cosas que quizás no están lo suficientemente probadas.

Aquí puedes ver un ejemplo completo de los gráficos estadíscos generados por statcvs.

Como comenté hace unos días, había instalado el plugin pretty-urls en mi foro SMF. Pues bien, dos semanas después y habiendo quitado el sitemap de google webmaster tools, reviso las estadísticas de visitas y aparentemente van subiendo notablemente. Parece quedar demostrado que es importante para salir bien en el buscador de google tener palabras interesantes en la url, y no números feos.

Ahí va el gráfico de estadísticas del último mes.

Hace un año me pusieron algo así como de "asesor" en java, herramientas y forma de hacer las cosas de un montón de gente. No tenía responsabilidad directa en los proyectos ni tampoco en la gente. Debía encargarme de que unos y otros no hicieran las mismas cosas por duplicado, que todos usaran herramientas similares, formas de hacer las cosas similares, etc. Sin embargo, la decisión final era de cada grupo.

En esas condiciones era dificil conseguir grandes cosas, pero tenía cierto tiempo libre para ver cosas nuevas, experimentar y en definitiva, jugar con java y todo lo que hay alrededor.

Sin embargo, hace unos meses me ofrecieron llevar un grupo más reducido de gente, esta vez sí, totalmente responsable de ellos y de su trabajo. Me tocaría hablar con los responsables de proyectos para ver qué tenemos que hacer, organizar el trabajo de la gente y hacerlo. Y lo cogí.

Ahora mi trabajo consiste en repartir marrones, perseguir a la gente para ver si los hacen o no, probar lo que hacen y lo peor de todo, con agobios y prisas, muchos proyectos, todos para ayer y con poca gente. No tengo tiempo en absoluto no solo para jugar con java, sino ni siquiera para codificar algo, lo que sea.

Así que sólo me queda esperar un tiempo a ver si la situación se alivia para poder intentar hacer todas esas cosas nuevas que tengo pendiente de probar. O bien la otra opción, pedir que me hagan responsable de un proyecto con todo lo que eso lleva: trato con el cliente, hacer un montón de documentación y olvidarme de java totalmente, aunque al menos sólo me dedicaré a un proyecto y podré (supongo) organizarlo a mi gusto (no a nivel de código). Me sigo resistiendo a olvidarme de programar, pero veo que el tiempo me lleva inexorablemente a ello.

Se me ha ocurrido mirar el dominio chuidiang.com en el ranking alexa, más que nada por curiosidad y he aquí el resultado

Lo que me ha llamado la atención es el escalón de subida a mediados de Mayo y el escalón de bajada a mediados de Junio. Yo no he hecho nada especial en mi página ni en una fecha ni en la otra. Tampoco creo que una pequeña multitud de webmaster hayan decidido enlazar con mi página y un mes después esa pequeña multitud haya decidido quitar los enlaces.

Aunque no puedo probarlo, lo más probable es que google haya hecho algún experimento con su algoritmo de búsquedas, pageranks o cualquier cosa. Igual les ha dado por experimentar con un coeficiente del algoritmo o cualquier tontería similar. El resultado de ese experiemento es que el número de visitas a mi página se incrementa casi al doble y luego vuelve incluso algo por debajo de lo normal.

A mi no me va nada en ello, me gusta que la gente visite mi página, pero tampoco me supone un trauma si no lo hacen. Pero ¿qué pasa con una empresa cuyo negocio depende fuertemente del número de visitas a su página? Un pequeño experimento de google puede hacer que su volumen de ventas se duplique, o que caiga a la mitad. Todopoderoso google.

Ultimamente he encontrado un par de tablas interesantes por internet.

Por un lado, gracias a un compañero de trabajo, descubro en indiangeek una tabla en la que están los diversos niveles de conocimiento/experiencia a los que puede llegar un programador. Por ejemplo, en el tema de algoritmos va desde el que no sabe hacer la media de varios números guardados en un array hasta el que sable "la leche" de algorítmica y en el tema de control de versiones, desde el que hace sus versiones a base de copiar el directorio con varias fechas hasta el que usa sistemas de control de versiones distribuidos, como Git. Aquí tienes la matriz de competencias de un programador, un poco grande y en inglés.

Es curioso, al menos en mi caso, ver como en los temas más relacionados con mi trabajo sí llego hasta la experiencia/conocimientos de la tercera o cuarta columna, mientras que en otros me quedo en la primera o apenas me introduzco en la segunda. En fin, supongo que no se puede saber en profundidad de todo.

Por otro lado, la segunda tabla interesante que descubro vía LuAuF es una tabla en la que se cuentan los directorios típicos de linux /bin, /opt, /etc para qué sirven, qué es lo que se espera encontrar en ellos. Aquí debajo tienes dicha tabla

Tenía mi versión algo más detallada, que en su día traduje del inglés,  en Directorios de Unix, a la que he añadido esta imagen.