El síndrome NIH

Desde el blog de Juanjo Navarro he llegado casualmente a una entrada sobre el síndrome NIH (Not Invented Here), consistente en el caso de la informática (aunque aplicable en muchos campos) en rechazar desarrollos creados “fuera de casa” por razones como los distintos orígenes de estos desarrollos, fiándose siempre más (en muchos casos sistemáticamente) del clásico “Bah, esto me lo pico yo en un par de días”.

Hay alguna razón más en el artículo original, pero sobre todo las siguientes tres me han llamado mucho la atención porque me parece que siempre hay que vigilarlas y es bastante sencillo caer en ellas:

1. Nunca es tan sencillo como parece. Empiezas pensando que lo puedes hacer en dos días, y acabas invirtiendo meses. Literal. Conozco varias historias y frases memorables de este tipo.
2. Probablemente no es la guerra en la que deberías estar. Sería mejor invertir ese tiempo en tu negocio que en hacer algo que ya existe. Bien es verdad que el tiempo que no te tomas creando tú algo, te lo tomas entendiendo lo de los demás. Aquí en este caso hay que analizar mínimamente cada situación. Tampoco es un axioma en mi opinión.
3. Mucha gente lo ha intentado antes y falló. Todos nos creemos los programadores más listos sobre la tierra, pero es para pensarlo. También literal. Siempre pasa. Y cuando digo siempre, es SIEMPRE.

Personalmente podría añadir otra razón que me parece sumamente importante, y es la siguiente:

Un desarrollo que ya está usando mucha gente y hace algo (aunque sea mejorable) como poco está más testeado / probado que tu nuevo desarrollo. En muchos casos, si es Open Source y uno cree que puede mejorarlo, es posible colaborar además.

[Meme] Seis pequeñas cosas que te hacen feliz

Vía Historias de JP llego hasta un meme que básicamente consiste en expresar seis cosas pequeñas que te hacen feliz. Estoy totalmente de acuerdo en que aun siendo pequeñas, muchas de ellas te hacen una ilusión terrible, así que como me llamó la atención la temática (no soy excesivamente amigo de los memes) procedo a recogerlo y pasarlo a quien quiera responderlo.  Siempre es interesante conocer un poco más a los demás …

Mis seis pequeñas cosas que me hacen feliz (o que al menos ahora mismo recuerdo) son:

1.- La playa. Estando allí, para mi el tiempo “no pasa”. Me encanta Madrid. Es una ciudad fascinante. Pero es algo a lo que ni hoy ni nunca me temo que me acostumbraré de estar tan lejos :( .

2.- La gente que me hace ser feliz. En las ocasiones más normales y cotidianas me refiero. Desde la camarera que te pone un café con una sonrisa hasta el compañero que te hace una broma según llegas por la mañana a la oficina. No siempre la vida es de color de rosa, así que creo que merece la pena disfrutar de esos pequeños momentos.

3.- Como el propio JP, regar y cuidar las plantas observando cómo crecen y florecen, aunque a veces nos den disgustos cuándo inexplicablemente no responden a nuestros cuidados. Es sorprendente a veces lo que coincides con los demás en estos “extraños hábitos” :)

4.- Salir del gimnasio por la tarde / noche cansado pero totalmente desestresado de un día largo de trabajo y darte esa ducha de después. Tengo la extraña sensación de volverme con la obligación cumplida jeje.

5.- Viajar, o más bien “estar fuera”. Si, puede parecer raro, pero me hace sentir vivo. El cambiar, el hacer desaparecer por momentos la rutina, el conocer nuevos sitios, culturas o personas, … Es maravilloso.

6.- Cualquier tipo de reunión o encuentro con mis familiares más cercanos. Viendo como está mucha gente en el mundo, soy y me considero realmente afortunados por tener gente que me quiera y que estaría dispuesta a darlo todo por mi. No ser feliz sería casi insultante.

Espero vuestros memes ! ;)

Un par de apuntes mañaneros de Maven

Esta mañana estaba reordenando algunos plugins de Maven en los poms genéricos empresariales y curiosamente a través del Blog de Antonio Manuel Muñiz he encontrado un enlace al plugin DashBoard, que te permite un control “unificado” de algunos plugins estándar dentro de la comunidad Maven (JXR, Surefire, Cobertura, …).

Ciertamente en los procesos que mantenemos con Continuum y Archiva ya estaban incluidos casi todos por defecto, pero creo que un plugin de estas características aporta el tener de un vistazo rápido acceso a gráficas y estadísticas que son realmente muy interesantes.

En este plugin es posible también configurar mediante Hibernate y una BBDD una serie de reportes que podemos almacenar y recuperar configurando un histórico de versiones temporal “DashBoard” en nuestros proyectos.

Como siempre es bastante sencillo de preparar y configurar aunque merece la pena juguetear un poco con las configuraciones (sobre todo con el objetivo persist).

Por otro lado, me he dado cuenta que al pasar a la versión 2.5 de JavaDoc se ha marcado como deprecated el parámetro aggregated, muy útil para multiproyectos ya que nos permite no tener que ir viendo el JavaDoc generado para cada jar si tenemos 30 proyectos sino “entremezclado”.

Si actualizais vuestra versión podeis encontraros con algo así:

As of version 2.5, use the goals javadoc:aggregate and javadoc:test-aggregate instead.

Simplemente accediendo al objetivo javadoc:aggregate o al test-aggregate se solucionará evitando así ese parámetro.

Por otro lado, me he encontrado con un documento de CodeHaus que me ha ayudado a evitar problemas de codificación de plugins que hagan uso de ficheros fuente. Algo parecido a:

[WARNING] Source files encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent!

Como ellos mismos dicen, “Currently, the character encoding for source files needs to be configured individually for each and every plugin that processes source files. In this context, source file refers to some plain text file that – unlike an XML file – lacks intrinsic means to specify the employed file encoding. The Java source files are the most promiment example of such text files. Velocity templates, BeanShell scripts and APT documents are further examples.”

La solución ha pasado por una modificación de una propiedad general, más en concreto:

<project.build.sourceEncoding>iso-8859-1</project.build.sourceEncoding>

Si usais otro formato de codificación, lógicamente debereis modificar el interior de este tag.

Y en realidad, viendo el listado de plugins afectados, no me cabe duda de que os encontraréis con ello:

Affected Apache plugins:

• maven-changes-plugin (velocity template for announcement): MCHANGES-71
• maven-checkstyle-plugin (source analysis): MCHECKSTYLE-95, done in 2.2
• maven-compiler-plugin (source processing): MCOMPILER-70, done in 2.1-SNAPSHOT
• maven-invoker-plugin (beanshell script evaluation): MINVOKER-30, done in 1.2
• maven-javadoc-plugin (source processing): MJAVADOC-182, done in 2.5
• maven-jxr-plugin (source processing): JXR-60, done in 2.2-SNAPSHOT
• maven-plugin-plugin (javadoc extraction, java source generation): MPLUGIN-101, MPLUGIN-100
• maven-pmd-plugin (source analysis): MPMD-76, done in 2.4
• maven-resources-plugin (contents filtering): MRESOURCES-57, done in 2.3-SNAPSHOT
• maven-site-plugin (apt sources): MSITE-314, done in 2.0-beta-7

Momento pro-software libre

Cada día que pasa en la industria informática tengo más clara una cosa:

“Toda persona que es realmente capaz de programar un código cojonudo, no le tiene ningún temor o miedo a liberarlo y hacerlo libre si se diese el caso”.

Supongo que esto también tiene mucho que ver con el ego del programador, pero en fin, todos somos humanos :-).

97 cosas que todo Arquitecto de Software debería conocer

Esta mañana me he encontrado con una iniciativa interesante por parte de O’Reilly, y que no sé si alguno la conocería ya pero que a mi me ha resultado curiosa.

Se trata de la creación de un libro mediante un wiki en el que puede escribir cualquier persona. En su título se indica de qué versa: “The following are axioms for software architects by software architects. They have been contributed under the Creative Commons, Attribution 3 open source license. If you have a rule-of-thumb, principle, axiom, or maxim you believe is important to being a successful software architect, this is the place to share it with the world”.

En spanish, viene a decir en traducción libre y rápida que “se trata de un conjunto de axiomas para arquitectos de software hechos por arquitectos de software (aunque desde mi punto de vista esta frase la veo un completo sinsentido vista la estructura del libro. Pero quien soy yo para llevar la contraria a los grandes gurús …).  Las contribuciones se realizan mediante la licencia Creative Commons, Attribution 3 open source, y que si tienes una regla de manual, principio, axioma o máxima que consideres que es importante para llegar a ser un buen arquitecto de software, deberías compartirla aquí”.

Para poder participar en la iniciativa, debes registrarte previamente, previa lectura de las reglas de compromiso claro. Una vez postees tu axioma, este se irá votando  por los demás usuarios. Además de ello, un moderador, en este caso Richard Monson-Haefel y/o editores de O’Reilly Inc. , aprobarán tu axioma en caso de que lo consideren oportuno (no se cita bajo qué criterios, imagino que la puntuación que obtenga y criterios personales), para ser aceptado, ya que finalmente solo 97 axiomas pueden quedar al final.

En mi opinión, la iniciativa es curiosa pero quizás la veo excesivamente “selectiva”: un moderador que aprueba tus posts, solo votas si estás registrado, solo consejos de “arquitectos de software”, … Será defecto mío profesional, pero el hecho de ver un wiki “capado” me resulta algo chocante como poco. Además de ello, me da la sensación de que ese control en Internet vale poco más que nada.

Fuente: Pensamientos Ágiles