Diario de Programación

Vía Sistema Orca - Software Tips encuentro esta lista de comandos útiles de linux bash. Un buen enlace para tenerlo a mano.

Lo siento, pero este post es sólo para desahogarme.

En mi empresa, en dos o tres años, ha habido dos o tres cambios de jefes por arriba, de alto nivel. Cada nuevo jefazo decide "organizar" la cosa y lo primero que hace es quitar a los subjefes que había antes y poner como subjefes a sus amiguetes. Estos hacen lo mismo con sus subsubjefes y así sucesivamente.

El resultado es que uno o dos meses después del cambio de un super jefe, el cambio de subsubjefes nos llega a los curritos. Según seas amigo o no del que te ponen de jefe, acabas a tu vez de jefecillo o de currito -yo los llamo curritos avanzados y curritos de decimotercera clase-.

Cuando te toca ser jefecillo, intentas organizar las cosas o arreglar lo que creías que iba mal antes. Por supuesto, cambias a tus subjefes, si es que tienes suficiente nivel. Cuando lo tienes casi a punto, otro nuevo cambio de super jefe se ha propagado hasta ti y vuelves a ser currito de decimotercera. Ves como el nuevo jefecillo deshace todo lo que has hecho y cuando el caos está a punto de caérsete encima, otra nueva propagación de onda de cambio jeferil te llega y vuelves a ser jefecillo. Vuelta a empezar a organizar todo y a dejar que la onda siga propagándose por debajo de ti.

Pues eso, que estoy hasta las narices. Vuelvo a estar de jefecillo, pero no sé si me quedan ganas de organizar nada, ya que empiezan a oirse los rumores de cambio de superjefe, así que el esfuerzo que haga ahora se perderá dentro de dos o tres meses ….

¿No se darán cuenta en las altas esferas que tanto cambio seguido sólo aporta caos a la forma de trabajar?. Me da igual ser currito que jefecillo, me van a pagar lo mismo e incluso me gusta más codificar que tratar con gente. Sólo quiero hacer lo que tenga que hacer sin andar cambiando cada tres meses de tarea/responsabilidad/trabajo, dejando código a medias porque en tu nuevo puesto ya no haces código. Dejando la organización a medias porque en tu nuevo puesto sólo eres currito.

Puñeta de empresa.

Lo siento, pero no recuerdo en que blog lo leí, aunque dejé en él un comentario.

En http://java-source.net/ hay un listado de herramientas y librerías java gratuitas. Está bastante bien organizado y es muy completo. Al menos, muestra herramientas en las que tengo o he tenido interés en algún momento:

• Programación orientada a aspectos
• Analizadores de código (métricas, posibles problemas con el código). En concreto tengo ganas de probar algo como FindBugs, que en teoria revisa nuestro código java y nos indica errores típicos de programación, posibles problemas de sincronización de hilos, etc.
• Embellecedores de código. Actualmente uso Jalopy como plugin de eclipse.
• Cobertura de los test. Estas herramientas nos dan el porcentaje de líneas de código por las que han pasado los test. Estas herramientas tiene ahora un especial interés para mí, porque es posible que este porcentaje de líneas de código forme parte de mi retribución variable por objetivos en el trabajo este año….. Actualmente uso cobertura como plugin de maven, aunque no me funciona bien del todo en proyectos maven con subproyectos.
• Gestión de proyectos, tanto herramientas UML como de planificación de tiempos

Esas en las que tengo actualmente o he tenido interés no hace mucho, pero hay muchas más, como bases de datos, CMS, profilers, ofuscadores de código, etc, etc.

Una página interesante de visitar cuando estamos en busca de librerías o herramientas gratuitas en java.

Casi todos, y yo el primero, solemos ponernos a programar sabiendo lo mínimo para empezar y vamos aprendiendo sobre la marcha. Prácticamente nadie se coge los miles de manuales que hay disponibles en java y se los lee antes de empezar a hacer el programa que quiere hacer.

Un caso concreto es el paquete SWING de java. Casi todos, y yo el primero, aprendo lo mínimo de cómo hacer la ventana y me pongo a hacerla. Luego aprendo sobre la marcha.

Después de varios años programando ventanas SWING, vas aprendiendo de mala manera todo eso que no has leido a priori. Tus primeras ventanas son desastrosas. Las ventanas secundarias se van detrás de la principal y no se ven, la interface de usuario se te queda bloqueada mientras se ejecuta un algoritmo más o menos complejo, a veces las cosas se quedan bloqueadas sin motivo aparente….

Bueno, pues aquí van algunas de las cosas básicas que se deben tener en cuenta al hacer ventanas y con las que se suele meter la pata al principio por desconocimiento.

• En la aplicación sólo debe haber un único JFrame, correspondiente a la aplicación principal. Todas las ventanas secundarias deben ser JDialog. Todas las ventanas secundarias deben tener una ventana padre, que es a partir de la cual se despliega. Es decir, todos los JDialog secundarios deben tener como padre al JFrame principal. Si desde un JDialog se va a visualizar otro, este segundo debe tener como padre al primero, y así sucesivamente.
• Evita en lo posible los JDialog modales, o ten muy en cuenta su jerarquía de padres. El primer JDialog modal no tiene problemas si le pones su padre adecuadamente. Si tienes un JDialog modal visible, no muestres otro JDialog secundario, salvo que también sea modal y sea hijo del anterior. Si pones visibles a la vez dos JDialog modales y no son el uno hijo del otro, tendrás problemas al intentar escribir en ellos o cerrarlos.
• Nunca heredes de JFrame o JDialog o JApplet para hacer tus ventanas. Hazlo siempre de un componente que no sea ventana y que no te limite. Si tus ventanas heredan de JPanel, podrás ponerlas siempre que quieras dentro de un JFrame, un JDialog, un JInternalFrame, un JApplet o incluso incrustarlas en otro JPanel. Si tu ventana hereda de JFrame, está condenada a ser un JFrame toda su vida.
• Reaprovecha las ventanas, no se las dejes al recolector de basura. Si un botón, al apretarlo, visualiza un JDialog, no hagas un new de JDialog cada vez que pulsas el botón. Es mejor hacer sólo un new la primera vez y guardarselo. En las siguientes veces bastará con hacer setVisible(true) y setVisible(false). Para que el recolector de basura libere una ventana, además de lo habitual, hay como minimo que llamar al método dispose() de dicha ventana  -cosa que mucha gente no sabe- , para que el sistema de eventos de teclado y ratón eliminen todas las referencias que tienen a ella. De todas formas, incluso así no tengo muy claro que los JDialog se liberen siempre y, desde luego, en versiones anteriores de java, los JFrame NUNCA se liberaban. La excusa de SUN es que como sólo debía haber un JFrame principal, no tenía sentido liberarlo.
• Los layouts para situar componentes no son tan complicados, sólo hay que ponerse a ello. No uses el layout null, ya que tu ventana no será redimensionable y puedes tener problemas si cambia la fuente de letra, si tu programa se ejecuta en otro sistema operativo, se cambia el look & feel, etc.
• Una vez que sepas los layouts simples, tenderás a hacer ventanas grandes a base de anidar muchos JPanel que a su vez tienen dentro JPanel que su vez tienen dentro JPanel, todos ellos con un layout simple. Eso hace ventanas muy pesadas y que consumen mucho. Aprende a usar el GridBagLayout para hacer un solo panel con todo. La excepción a esto es que tengas pequeños JPanel reutilizables, como un editor de coordenadas geográficas que pida latitud, norte/sur, longitud, este/oeste, un panel que pida usuario y password, etc.
• Todos los eventos de ratón y teclado se ejecutan en el mismo hilo que repinta las ventanas. Si en un actionPerformed(), keyPressed(), … tu código tarda mucho o pretendes que se pinte algo en una ventana, simplemente no lo hará hasta que tu código termine. Si tu código en un actionPerformed() va a tardar mucho o tiene que pintar cosas en la ventana, lanza un hilo aparte para hacer esa tarea y termina el actionPerformed() lo antes posible.

Y como esto hay muchísimas más cosas, pero estas son las que si no se hacen bien desde el principio, luego cuesta muchísimo arreglar el programa.

Me encanta lo que he leído aquí sobre los principios básicos de realización de pruebas, sobre todo lo de que hay que probar también que el código no hace lo que tiene no tiene que hacer.

Todo esto me recuerda además que tengo que seguir haciendo test de JUnit del código, porque cuando hay tiempo se van haciendo, pero cuando te entra la pereza o tienes prisas, pasas de ello -como es mi caso ahora mismo-. Pero luego la verdad es que cuando tocas código antiguo, sobre todo si es de una librería que utilizas mucho, lo tocas con más tranquilidad si están esos test hechos. En más de una ocasión nos han avisado antes de meter la pata en una de esas librerías.

Llevo mucho tiempo intentando hacer código que se pueda reutilizar en varios proyectos.

Al principio es fácil. El código reutilizable que haces suelen ser pequeños componentes o librerías a las que más o menos es fácil llamar y que cumplen un trabajo muy concreto: Un algoritmo matemático, unos editores numéricos, de fecha/hora etc.

Poco a poco, la cosa se va complicando. Ves posibilidad de hacer código reutilizable de más alto nivel. Ves que en todas tus aplicaciones hay partes comunes. Por ejemplo, pedir un usuario y password y entrar en la aplicación. Muchas ventanas que van contra base de datos, etc, etc. Te lo piensas y los grupos de componentes y librerías que salen son más grandes y requieren configuraciones más complejas. También es más difícil que te salgan bien a la primera.

Sin embargo, el problema realmente gordo es otro. Si estás trabajando con un grupo de desarrolladores más o menos grande -y más de dos son multitud-, que además entran y salen de la empresa, difícilmente van a reutilizar ese código. En primer lugar no saben que existe salvo que alguien se lo cuente. Tampoco, aunque sepan que existe, saben cómo usarlo. La "curva de aprendizaje" de esos componentes reutilizables es muy pendiente.

¿Soluciones? La verdad es que no tengo ni idea. Todavía ando peleándome con esos temas.

Una que parece evidente es hacer documentación de esos componentes. Sin embargo tengo mis dudas de que funcione -de hecho ya hay documentación y nadie la mira ni por asomo-. A los nuevos hay que decirles que existen los componentes y que los usen. La documentación les puede aclarar cómo usarlos. Si no les dices qué componentes hay y les das un tocho-documento de componentes reutilizables, veo muy probable que ni siquiera lo miren. Muchas veces pensarán que tardan menos en hacer algo nuevo que en buscar si existe en la librería.

Otra que me planteo es la programación por parejas propia de la programación extrema. La programación por parejas, entre otras cosas, permite que la gente vaya conociendo sin demasiado esfuerzo los componentes comunes. Los nuevos van aprendiendo su existencia y cómo utilizarlos cuando programan en pareja con alguien más antiguo que ya los usa. Sin embargo, este tipo de cosas, programación en parejas, está en general muy mal visto por los jefes ¿para qué hacen falta dos para el trabajo de uno?. Encima, siguiendo las modernidades de ahora de que la gente debe trabajar en mesas corridas y salas diáfanas, sin despachos, podría ser un pequeño guirigay tantas parejas trabajando y hablando.

¿Quizás un diseño detallado de verdad en el que se diga qué componentes deben utilizarse en cada caso?. Seamos realistas, ¿quién hace diseño detallado antes del código y lo hace de verdad, pensando en lo que se va a codificar?. No sé, puede que alguna empresa lo haga, pero no la conozco.

Lo único que parece que medio funciona y, desde luego, no es la mejor solución, es que los que saben de esos componentes vayan llevando de la mano a los nuevos, diciéndoles qué usar y cómo. No es la programación por parejas, pero se le parece mucho, al menos en este aspecto de aprendizaje. El problema es que los antiguos van ascendiendo, cogiendo responsabilidades y cada vez pueden dedicarse menos a los nuevos.

Veo en JavaHispano de un sitio web JavaBat en el que te plantean problemas java para resolver, en principio sencillos y para novatos. La novedad del sitio es que en el mismo navegador y desde la misma página, puedes escribir el código, compilarlo y comprobar si has resuelto bien o no el problema.

Hay una historia de hace tiempo que cuenta como un "hacker", en un chat, retaba al moderador a que le diera su IP. Según el hacker, con esta IP podía borrarle el disco duro al moderador. El moderador, simplemente le dio la IP 127.0.0.1, que hace referencia a la propia máquina de uno. Lo último que se supo del hacker es que le decía al moderador que ya le había borrado un 33% de su unidad C:

Aunque la historia es antigua, he encontrado una copia de la conversacion en el chat.

De todos es sabido que cuando un proyecto está empezado y va con apuros, meter nuevos programadores es contraproducente. El tiempo que tardan en enterarse de lo que hay que hacer y la atención que requieren de los programadores que están en el ajo, hace que estos últimos pierdan parte de su valioso tiempo y el proyecto vaya más despacio. Incluso a veces un programador experimentado tarda más en explicar al nuevo lo que hay que hacer que en hacerlo él mismo.

Pensando en el problema se me ha ocurrido una posible solución. Una característica muy importante de cualquier programa serio que se precie son los "huevos de pascua", subprogramas escondidos dentro del programa y que se activan con una combinación extraña de teclas. Uno de los huevos de pascua más conocidos es el simulador de vuelo escondido en excel.

Pues bien, esta es la solución ideal para un nuevo programador que entra en un proyecto que va apurado. Se le pasa el tutorial de java sobre space invaders y se le encarga la creación del huevo de pascua de nuestra aplicación.

Es más, si el jefe se empeña en meter dos programadores nuevos, tres o más, es simplemente cuestión de inventar más combinaciones extrañas de teclas a las que añadir huevos de pascua.

Como todos sabemos, el Principio de Peter viene a decir que "cada persona asciende hasta alcanzar su máximo nivel de incompetencia".

Contrariamente a lo que piensa mucha gente, esto no significa que cuanto más incompetente eres, más asciendes. El significado real es que si eres competente en tu trabajo, posiblemente te asciendan. Así seguirás asciendo hasta que llegues a un puesto que no puedes desempeñar, para el cual eres incompetente. A partir de ahí, puesto que no haces bien tu trabajo, posiblemente no te asciendan más.

Si tenemos en cuenta este principio, que normalmente es cierto, nos lleva a dos conclusiones terribles:

• Acabaremos ocupando un puesto para el que seremos totalmente inútiles y ahí nos quedaremos.
• Todos los jefes son incompetentes, salvo que estén en el proceso de ir ascendiendo.

Y la conclusión peor de todas: Tu jefe es un inútil, pero no te preocupes, que acabarás siendo como él.