Diario de Programación

Hace tiempo comenté que teníamos que traducir nuestra interface gráfica al ruso. Pues bien, está a punto de estar a punto y también está a punto de que vengan los rusos a ver lo que hemos hecho.

La primera etapa, el internacionarlizar las etiquetas de java, con la ayuda de eclipse, ha sido un trabajo fácil, rutinario y algo pesadito. Hemos aprovechado para ponerlo en inglés, así al menos vemos qué etiquetas se quedan sin traducir. Los ficheros de properties con las etiquetas se han pasado a un traductor ruso.

Todavía no tenemos la traducción, pero nos queda un rollo pesado y un par de pegas.

El primer rollo pesado es que cuando el traductor nos traiga los ficheros de propiedades, posiblemente tengamos que buscar y reemplazar todos los caracteres cirílicos por los códigos unicode equivalentes. No he probado si hay alguna pega por dejarlo directamente en cirílico, pero desde luego eclipse protesta si intentas ponerlos directamente. Y eclipse convierte los acentos españoles y eñes a códigos unicode al internacionalizar. ¿quizás un pequeño script en algún lenguaje novedoso para aprender algo?.

En cuanto a las pegas, la primera es que dimos los textos al traductor hace tiempo, pero claro, hemos ido desarrollando cosas en el prototipo. Hay textos que no le hemos entregado. Lo del inglés lo podemos apañar, pero como no venga el traductor a pasarse una tarde con nosotros a rematar detalles antes de la demo, quedarán varios textos sin traducir. Hombre, el google traductor puede ayudar, pero ni puñetera idea de si el texto lo pone bien o no en ruso. Nos tendríamos que limitar a copiar y pegar. Encima, los textos en ruso son muy largos (algo así como las palabras alemanas), por lo que quizás incluso nos toque recolocar botones y rediseñar ventanas.

Y la segunda pega va a ser divertida. Me gustará ver a nuestro jefe haciendo la demo sobre una aplicación en ruso. Apenas la conoce y desde luego, los botones, tooltips y ayudas no le van a ayudar a saber qué botón apretar en cada momento.

La solución que vamos a adoptar es tener dos ordenadores uno al lado del otro, uno con la aplicación en ruso y la otra en inglés.

Por cierto, la siguiente creo que va a ser una traducción al chileno. Espero que sea más fácil

El otro día nos hicieron una auditoría interna de software. Como era de software, me soltaron a mí al auditor. Le duré menos de cinco minutos.

El auditor empezó su ristra de preguntas, que básicamente consistía en de los dos mil documentos que teóricamente pueden hacerse (requisitos, plan de desarrollo, diseño preliminar, manual de usuario, de instalación, de árbol de configuración, …), preguntarme uno por uno si lo hacíamos. Yo me dedico a codificar software y algunos de esos documentos sí me suenan, o bien porque me llegan, o bien porque incluso colaboro en ellos, pero del resto ni idea, ni si se hacen, ni cual es el proceso para hacerlos e incluso muchos de ellos, nombrados por sus siglas, los había oido por primera vez. De hecho, en la lista anterior he puesto algunos de los que sí conozco, porque de los otros mil novecientos ni siquiera me acuerdo ahora del nombre.

Cuando llegó el momento en que nos acercamos al tema de software real, vi llegar mi oportunidad, pero al auditor le importaba tres pepinos qué herramientas usábamos (cruise control, bugzilla, test de junit, etc). Unicamente hablamos de que usabamos CVS y hacíamos ramas de vez en cuando. Realmente lo que le interesaba era saber si teníamos controladas las versiones del proyecto completo y si teníamos algún documento que reflejara todas las mejoras y peoras de una versión respecto a la anterior. Asi que de software nada de nada, lo único de interes es que usamos CVS.

Cada vez me da más pena este mundo empresarial, en el que lo importante son las apariencias y no la realidad, en donde lo realmente importante del softwre son los documentos que le acompañan, y no el software en sí mismo. El software puede ser una patata, pero si va acompañado de varios documetnos tamaño "El Quijote", está bien hecho. Y si tienes todos esos documentos, aunque el software no vaya, cumplirás con las normas de calidad ISO 9001 y similares. Luego, claro, se sacan premios a la "excelencia empresarial" (nombrecito, ¿de dónde lo habrán sacado?).

Suelo visitar y participar en varios foros de java. Algunas preguntas son realmente curiosas, pero esta pregunta me ha llamado la atención. ¿Cómo se puede desplegar un Combo hacia arriba?. Será cuestión de investigarlo un poco …

No sé de qué se queja la gente con Windows Vista. Si se instala correctamente, como se indica en este video, queda listo para su uso y no da ningún problema… nunca.

Visto en Instalar Window Vista correctamente.

Nuestros proyectos son -o eran- habitualmente para España, por lo que nunca hemos prestado demasiada atención al idioma de las interfaces gráficas, ni a la internacionalización de java, ni a los ResourceBundle, ni a ninguna otra cosa parecida. El texto va directamente en el código y en español.

Pero la hemos liado. Tenemos que hacer uno de nuestros proyectos para un país de habla rusa. Tenemos que traducir todas las etiquetas al ruso, con caracteres cirílicos, por supuesto.

Pues nada, me he puesto a ello. He cogido eclipse y con su "externalize strings…" me he puesto a sacar ficheros de propiedades con los textos. Eclipse es una pequeña maravilla y todo eso se hacer rápido. Sin embargo, se me han planteado varias dudas.

Hay cosas, como los formatos de fecha y hora que no sé si tienen o no tienen traducción al ruso, si el formato usado en código para las máscaras sería correcto o no en ruso. Por ejemplo, en inglés suele ponerse delante el mes, luego el día y finalmente el año, mientras que en español va primero el día. Algo como dd/mm/yy en inglés podría ser mm/dd/yy. Encima, esa posible traducción visible no sé hasta qué punto es compatible con el cirílico.

Por otro lado tenemos mensajes que se componen de cosas como "hay " + variable + "chirimbolos en " +otraVariable. ¿Se compondrá la frase igual en ruso?. El que nos traduzca los ficheros de propiedades traducirá literalmente "hay" y "chirimbolos en". La cadena en cirílico se compondrá de la misma forma. ¿tendrá sentido?. Veo aquí que la internacionalización no es sólo sacar cadenas de texto y usar ResourceBundle. Posiblemente también hubieras sido necesario usar cosas como la clase MessageFormat, que compone mensajes de ese tipo. Siempre me pregunté para qué serviría esa clase. Ahora lo veo más claro. El formato del mensaje sería "hay {0} chirimbolos en {1}". Indicándole al traductor que [0} {1} son números y no se traducen, el traductor puede componer la frase correctamente en ruso sabiendo todo el significado.

Y se me ocurren otras chorradas, pero supongo que Windows es Windows para todos. ¿localhost es también localhost en ruso o hay que ponerlo en cirílico? ¿y los nombres de los servidores con los que debemos conectarnos por socket? ¿En cirílico se usan las mismas comas, puntos, barras separadoras de directorios \ y demás con el mismo significado?.

En fin, que veo altas probabilidades de pequeños problemas de funcionamiento de código debidos a la traducción a cirílico de ciertas cosas…. Si ya en español tenemos problemas con las vocales acentuadas que a veces salen como gurruños o cuadraditos según cómo se escriban y vengan de la base de datos, no te digo si encima no hay dos letras que se parezcan.

Pues acabo de aprender una cosa nueva. Cómo no, una cosa que NO debo hacer, porque hoy me ha tocado sufrir las consecuencias.

Hace aproximadamente un año tuve que hacer un cambio importante en un proyecto. Un cambio en unos pocos ficheros fuente, pero que podían dejar "descojonado" el sistema durante una buena temporada hasta que se volviera a afinar. Así que me decidí a abrir una rama de CVS para hacer mis cambios, de forma que cuando en esa rama todo estuviera adecuadamente depurado, juntarlo con la rama principal con ciertas garantías.

Pues bien, comencé los cambios y lo dejé después de un par de semanas de trabajo casi todo a punto… pero me interrumpieron con otra de esas labores super importantes que no pueden esperar a otro día … y aquella rama se quedó sin juntar … hasta ahora.

Hoy me he puesto a intentar juntar aquella rama con la principal y es un verdadero lio. En parte por recordar qué es lo que había tocado, pero principalmente he tenido que sufrir una de mis pequñas manías. Tengo la manía de refactorizar el código que toco, comentar lo que está sin comentar, arreglar los sangrados, eliminar warnings, etc, etc. Pues bien, eso ha hecho que sea prácticamente imposible ver qué cambios reales de código se hicieron entre la rama principal y la rama secundaria. Un diff de ambas versiones daba por cambiadas casi todas las líneas, aunque sólo fuera por temas de sangrado.

Así que ya sé dos cosas que NO debo hacer:

1. Dedicarme a hacer refactoring en una rama. En las ramas hay que tocar lo mínimo imprescindible para facilitar la tarea de unirlas a la rama principal.
2. No dejar tanto tiempo hasta integrar la rama. Si dejas mucho tiempo, es posible incluso que se te ocurra hacer refactoring y comentar el código de la rama principal, aunque no lo hagas en la secundaria, con lo que el efecto es el mismo.

Y de paso, sé una cosa que no deben hacer NUNCA los jefes

1. Interrumpir a un currito cuando tiene algo a medias con otra cosa muy importante. Y menos interrumpirlo durante un año.

Esta es la pequeña historia del departamento de la empresa en la que trabajo, de cómo el cambio a lenguaje Java, a la larga, ha ayudado a crear el caos donde antes sólo había desorden.

En el departamento realizamos sistemas más o menos similares unos a otros, con sus variantes, modificaciones, mejoras, pero similares. De media los proyectos duran dos o tres años, involucran a bastante gente codificando y a veces hay varios en paralelo. Tradicionalmente, estos sistemas los hemos realizado en C++ y en Ada.

En aquellos tiempos de C++ y Ada teníamos los problemas normales de hacer software: diseños que no se hacían o que si se hacían eran papel mojado, falta de organización, de planificación, etc, etc. Pero todo esto quedaba suplido más o menos porque la gente, en la escala jerárquica, ocupaba más o menos los puestos adecuados. Básicamente, había tres niveles:

• Un grupo numeroso de gente con poca experiencia, recién incorporados, que se dedican básicamente a programar. Esta gente tenia poca experiencia en C++ -las prácticas de la carrera-, no sabían Ada y no conocía nuestros sistemas.
• Un grupo de gente con experiencia, con uno o dos proyectos a cuestas -unos añitos programando-. Esta gente conocía los sistemas y conocía muy bien los lenguajes Ada y C++. Normalmente esta gente se dedicaba a llevar un pequeño grupo de nuevos a los que supervisaban el trabajo y resolvían dudas de los lenguajes de programación. Incluso las partes más delicadas las reservaban para programarlas ellos mismos.
• Los jefes, muy buenos conocedores del sistema, encargados de tratar con los cliente, decidir qué hay que hacer y repartir marrones. Normalmente estos tienen la programación algo olvidada.

En un momento dado se decidió cambiar nuestros sistemas a lenguaje Java. Primero la parte de C++, en el siguiente proyecto la parte Ada. Y varios años después se hizo el caos. Seguimos siendo igual de malos en diseños, planificaciones, etc, etc y además, se nos fastidió la bonita estructura jerárquica que suplía esas carencias. El motivo es que la gente ha ido subiendo en la jerarquía de una forma anormal.

• Los que antes programaban, ahora saben mucho Ada y C++ y conocen el sistema. Muchos de ellos, al no saber Java, han ascendido directamente al nivel de jefes, saltándose de alguna forma el escalón intermedio.
• Los que antes tenían experiencia, también han subido al nivel de jefes. Sólo los dos o tres que tienen pasión por la programación y horror a ser jefes se mantienen aquí y han conseguido llegar a un nivel aceptable de java. También hay aquí alguno de los que antes era nuevo y que ahora conoce el sistema y sabe Ada y/o C++. Es más, si es de los que sólo sabe Ada, no sabe ni siquiera de orientación a objetos.
• Muchos, muchos jefes. Los de antes, más lo que se han promocionado del escalón intermedio, más los que han venido directamente desde abajo.

Así que ahora tenemos una pirámide jerárquica descompensada, en la que hay más jefes que curritos y en la que a los nuevos les enseñan java los que no saben java. Mucha gente con conocimiento del sistema para tomar decisiones sobre el sistema y muy poca gente con conocimientos profundos del lenguaje para organizar adecuadamente el código y programar como se debe. Suelen ser habituales las reuniones de cinco o seis "jefes" para decidir qué es lo que tienen que hacer uno o dos programadores.

La verdad es que es una pena. Cada vez veo más cerca lo de las software factory y subcontratar el hacer código. Tan cerca lo veo que estoy pensando en desinstalar java e instalar Word, porque creo que dentro de nada tendré que empezar a "programar" en Word, escribiendo especificaciones y documentos variados.

Al menos me queda la ilusión de tratar de buscar un plugin de Word para eclipse, de forma que pueda programar con "Word" desde mi IDE favorito. Incluso como me toquen mucho las narices, me lo acabo haciendo…

Hombre, otra opción es pedir el traslado a la software factory, así sigo haciendo lo mismo que hago ahora. Mis antiguos jefes me subcontratarán el código que antes me mandaban hacer y alguna software factory se enriquecerá con mi trabajo haciendo de intermediario.

Esto es de locos.

El mismo jefe del post anterior, cuando ya era jefe pero un poco más joven, tenía dos costumbres. Por un lado, una mala costumbre, habitual en muchos jefes, que consistía en pedirnos con demasiada frecuencia que echáramos horas por las tardes y que fueramos a trabajar los fines de semana. Por otro lado, una buena costumbre, que consistía en que si nos engañaba para ir el fin de semana, él aparecía el Sábado o Domingo por la mañana con unas raciones de churros y porras. Así, al menos, podíamos tomarnos un pequeño desayuno.

Con el tiempo, según se fue haciendo jefe más experimentado, perdió una de sus costumbres y se afianzó más en la otra. Sí, has adivinado qué constumbre perdió y cual reforzó.

En cierta ocasión, ante la proximidad del fin de un proyecto, para presionar a la gente y en su deseo de innovar, tomó otra nueva mala costumbre: preguntarnos los Viernes, uno por uno, si ibamos a ir el Sábado a trabajar. Me llegó a mi el turno de la preguntita

- ¿Vas a venir el Sábado?

y yo, con la habitual mano izquierda que me caracteriza, le pregunto

- ¿Vas a traer porras?

Dicen que no llevó churros ese Sábado, aunque lo sé de oidas. No volvió a preguntarme ningún Viernes más.

Recuerdo hace ya unos años en que yo era más o menos responsable de una interface de usuario hecha en C++, con motif y sobre Solaris. Yo hacía el diseño detallado al estilo de la empresa y luego, junto con tres o cuatro nuevos, realizábamos el código.

Llegadas las pruebas con el cliente … ¡¡ La hecatombe !!. Una caída de la interface de usuario, con el famoso mensaje "core dumped". Una vez acontecido el desastre, la única salida con algo de honra era corregir ese fallo lo antes posible mientras el cliente seguía probando otra parte de la interface y más adelante demostrarles que el fallo esta corregido. Así que nos pusimos a ello.

Una o dos horas después coincido en el baño con uno de los jefes de alto nivel, de esos que maneja los dineros y a la gente, pero no tiene ni p..a idea de lo que es el código. Y así, ambos frente a la pared y entre chorrito y chorrito me pregunta

- ¿Qué tal el core?

y yo, con la mano izquierda que me caracteríza, le pregunto

- ¿Cual de ellos?

No volvió a preguntarme.