El banco automático de pruebas que me cayó en su día es uno de esos proyectos de otros departamentos. Su duración prevista era de unos tres meses y debo tenerlo terminado en Julio. Mi parte de software va bastante bien, pero el banco lleva mucho hardware (instrumentación electrónica, conectores, cables, aparatos variados, incluso un "armario" para montarlo todo) y creo (sé seguro) que todo eso van a retrasarse. Supongo que tengo trabajo de integración con todo ese hardware al menos hasta Septiembre. El lenguaje de programación para el banco lo elegí yo y pensé en LabWindows/LabView, pero visto el corto plazo y que el protocolo SCPI de control de instrumentación es bastante simple, decidí hacerlo en java.

Y pasado Septiembre … ya me tienen buscado otro proyecto. Este es en .NET, así que me toca aprender un lenguaje nuevo. Espero sólo un par de cosillas:

• Que me metan en el proyecto a un nivel de "currito", de forma que pueda programar y aprender .NET. No sé qué me han comentado de requisitos y zarandajas varias, así que me veo más con el Word que con el .NET. Bueno, en ambos casos es Microsoft.
• Que el proyecto dure lo suficiente (fecha prevista Septiembre de 2011) como para aprender bien .NET. Supongo que podré hacer cosas en .NET en cuestión de semanas, pero sé por experiencia que pueden pasar años hasta que aprendes a hacer las cosas correctamente y ni aún así, siempre estás aprendiendo. De hecho, esta frase "
  Sigo pensando todo de nuevo mil veces y todavia encuentro mejores maneras de hacer lo mismo. Creo que ya tenemos todas las soluciones al igual que lo creia 8 años atras" del blog de Lucas Ontivero creo que refleja perfectamente lo que quiero decir.

Ya me veo añadiendo un apartado en algún sitio de esta web sobre .NET

En cierta ocasión vi que la tienda tenía una página web, así que en una de mis visitas se lo comenté. El dueño me dijo que no andaba muy contento con los que se la habían hecho y que si yo sabía algo de eso, que le hiciera un presupuesto para llevarle yo la página web. Bueno, no es lo mío, sólo llevo la mía por hobby, tampoco soy autónomo así que no podría darle factura y encima soy vago. Una cosa es "jugar" con mi página web cuando tengo ganas y otra es comprometerme a algo. Así que lo dejé correr. De esto debe hacer ya cerca de dos años.

Pero hace poco volví a visitar la web y vi cosas que no me gustaron nada. Enlaces internos rotos, fotos que no salen y la página muy parada, en dos años apenas había nada nuevo. Así que le envíe un correo al dueño diciéndole que podía arreglarle la página y que siempre que fueran cosas puntuales y sin mucho trabajo, no le cobraría. Me conformaría con algún descuento/regalo en los arreglos que me fuera haciendo en la bici. Vaya, un trueque. Así que quedamos para un café … y me llamaron la atención varias cosas.

Lo primero es "hacer negocios" con gente de un negocio totalmente distinto al tuyo. Si le pregunto con quién tiene contratado el dominio y el hosting o cómo accede al panel de control, pues pone la misma cara que cuando él me comenta a mí que en una bici a medida se seleccionan unos treinta tipos de piezas y que la junta de la trócola no forma parte de ellas.

Y por otro lado, yo iba con mi idea de arreglarle un poco la página, ponerle un os-commerce para que tuviera un carrito de la compra o incluso un foro en el que la gente pudiera preguntarle on-line si tiene tal o cual pieza, cuánto tardaría en conseguirla o el precio. Pues bien, no tiene tiempo para atender el foro adecuadamente y lo del os-commerce le da igual porque casi todas las tiendas de bicis tienen y el que compra on-line al final se va al más barato, que suele ser alguna gran superficie. El lo que quería es algo que muy pocas tiendas de bicis tienen y es que un cliente pueda hacerse una bicicleta a medida, eligiendo las piezas del catálogo y hacer el pedido sobre ello. Es más, tampoco quiere que esa aplicación esté abierta al público en general, sino que sólo puedan acceder ciertos usuarios a los que él dé de alta y que hayan pasado previamente por la tienda, es decir, clientes conocidos.

Así que me pareció entretenido y a ello me he puesto. Llevo ya un par de semanas a ratos libres desempolvando mi php y me he creado un proyecto de bicis a la carta en GitHub, donde he subido una primera versión, más o menos funcional, pero todavía con faltantes y algunos ideas pendientes. A la vuelta del verano le llevaré mi bici para que le haga una revisión general por debajo del barro que tiene acumulado desde el invierno.

Por cierto, entiendo que sólo le interesen esos pocos clientes conocidos que "suelen" comprarle bicis a medida. Jugando con la aplicación y un catálogo real, haciendo bicis de forma aleatoria, no me ha bajado ningún precio de los 2000 €.

Hace tiempo que tengo una necesidad en el trabajo y que he ido dejando olvidada por falta de tiempo. Cuando en maven manejas proyectos grandes, cada uno con varios subproyectos  y encima esos proyectos grandes dependen de otros proyectos grandes que también tienen sus subproyectos, llevar un versionado en condiciones de cada jar puede ser un infierno.

Me explico, tu proyecto grande lleva un fichero pom.xml. Cada uno de los subproyectos también. En los demás proyectos también y en sus subproyectos también. Algunos de los jar de alguno de esos subproyectos pueden ser librerías básicas, por ejemplo, una librería de componentes swing o de utilidades para acceso a base de datos, de gráficos, o lo que sea. Aparecen dependencias de esa librería en los pom.xml de muchos de los proyectos y subproyectos.

¿Qué pasa si cambiamos la versión de esa librería?. Que no queda más remedio que ir en todos los proyectos y subproyectos en los que queremos actualizar la versión buscando dicha librería por los pom.xml y cambiando el número de versión. Desde luego, una tarea rutinaria, pero algo aburrida, que lleva un tiempo y susceptible de error "humano" al hacerla a mano.

Así que pensé en hacer un script o algo que buscara por los pom.xml y cambiara automáticamente las versiones que se le dijeran. Así que por fin me puse a ello y como siempre, para jugar y aprender algo nuevo, en vez de un script, decidí hacerlo como plugin de maven.

El resultado es un plugin de maven con dos goals:

• lista saca en un fichero un listado de todos los artifacts que aparecen en el pom.xml del proyecto y subproyectos actuales y con la nueva versión o groupId que queremos para cada sub/proyecto. Ese fichero lo utilizará el siguiente goal para hacer los cambios en el pom.xml.
• cambia realiza los cambios indicado en el fichero anterior en todos los pom.xml que encuentre del proyecto y subproyecto. 
  • Si se ejecuta este goal en el mismo proyecto en que se ejecutó el lista, obtenemos un cambio de versión en el proyecto. Quizás el plugin release de maven hace esto mismo y mejor.
  • Si se copia el fichero de cambios en otros proyecto distinto y ejecutamos allí el goal cambia, conseguimos cambiar la versión de las dependencias con el primer proyecto.

Lo he estado usando ya y probando, va bastante bien, aunque veo que el uso no es demasiado intuitivo, siempre se me olvida hacer alguna cosa.

Ahí van un par de enlaces:

• Proyecto en chuidiang : http://proyectos.chuidiang.com/pom_version/index.html
• Proyecto en google-code: http://code.google.com/p/chuidiang-pom-version/

Aprender, pues aprendí algunas cosillas, sobre todo, ¿cómo no?, problemas con los que me he tropezado. El más gordo ha sido que no hay forma de hacer un deploy de un plugin en condiciones. En el pom.xml del plugin, el packaging es "maven-plugin". Pues el deploy no sabe hacer un deploy de una cosa cuyo packaging es "maven-plugin", así que para que funcione el deploy, debes poner packaging "jar". Pero claro, eso sube el fichero .pom al repositorio remoto con ese packaging que no es, así que luego, a mano y en el repositorio remoto, tienes que cambiar el "jar" por "maven-plugin" otra vez. Y el problema sigue, ya que al cambiar eso a mano, los ficheros de checksum/huella o como quieras llamarle .md5 y .sha1 que se crean en el repositorio remoto ya no cuadran y al bajarte el plugin con maven dan un warning.

Y yo creo que ya está bien de proyectos. Esta tarde me dedicaré a otra cosa.

Hace tiempo me puse a hacer en perl, por aquello de aprender perl, un script que me pasara tipos de ficheros .h de C a clases java, de forma que pudiera enviarlas y recibirlas por socket desde un ejecutable C a uno Java y viceversa. Con ese experimento, aprendí el tema de expresiones regulares algo más en serio. Luego, para sorpresa mía, vi que en java las expresiones regulares son calcaditas a las de perl, y que se parecen mucho a las del editor vi y que finalmente supongo que vienen del mundo unix. Así que me quedé con las ganas de hacer algo un poco más en serio con expresiones regulares en java.

Otra cosa que tenía pendiente es la de conectarme desde java a una URL y ver cómo bajar el fichero correspondiente a esa URL, bien sea un html, bien sea un doc, un pdf o una foto.

Así que junté lo uno con lo otro y para probar más que por otro motivo, decidí hacer un descargardor de ficheros de páginas web. La idea es darle una página html, que se la descargue, que busque dentro todos los href y que si apuntan a ficheros con determinadas extensiones, que se las descargue también. Eso cumple ambos requisitos, jugar con las expresiones regulares y descargar ficheros de una URL.

Me puse con ello y he estado en ello hasta que me ha aburrido el tema (ya no iba a aprender nada más sin meterme en camisa de once varas) y he probado un poco para ver que más o menos funciona, pero a pesar de todo ello, me he decidido a ponerlo en la web.

Así que en el repositorio maven de chuidiang.com están los jar y los fuentes empaquetados en un jar del descargador.

En la parte de proyectos, he puesto la documentación generada por maven de dicho descargador.

Y finalmente, para rizar el rizo, he creado en google code el proyecto chuidiang-descargador, para que los fuentes estén accesibles vía subversion. La verdad es que mi primera intención era meterlos en el repositorio launchpad de bazaar, pero no me funcionó a la primera por problemas de seguridad, firmas digitales, claves públicas y privadas y como no sé del tema más que lo básico, pero nada de lo práctico y como encima windows no ayuda a estas cosas, pues lo dejé en subversion de google-code.

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.

Acabo de subir a google-code los fuentes de otro pequeño proyecto que me traigo entre manos, chuidiang-editores.

De momento son simplemente unas clases que heredan de JFormattedTextField y hace de editores simples: un EditorNumerico, EditorDate, EditorLongitud, EditorLatitud, etc. Por supuesto, intentando que sólo admitan números correctos, que se puedan poner restricciones, como que el número esté entre un mínimo y un máximo, etc.

También hay un EditorPanelGeneral. Es un JPanel al que se añaden editores de una forma simple y él se encarga del Layout y de colocarlos de forma automática. Este JPanel admite como dato un Hashtable. Con las claves identifica a qué editor pertenece el dato y se lo pasa. En el método getDato() devuelve un Hashtable con los datos de cada uno de los editores.

Y eso es más o menos lo que hay. La intención final es ligar todo esto con base de datos, de forma que para un conjunto de columnas dadas de unas tablas, se construya automáticamente el formulario y más adelante, facilitar también el tema de consultas e inserciones, así como la presentación en un JTable de los resultados, con sus botones de crear/editar/borrar, filtro, etc.

Ahí van algunos enlaces:

• La documentación del proyecto: http://proyectos.chuidiang.com/editores/
• El proyecto en google-code: http://code.google.com/p/chuidiang-editores/
• Repositorio Maven: http://maven2.chuidiang.com/com/chuidiang/ChuidiangEditores/

y sólo falta lo de siempre, porque empezar he empezado con ganas. Lo que hay que ver es lo que dura.