Diario de Programación

Título un poco raro. ¿qué es cada cosa?. La sopa de piedras hace referencia a una historia y una técnica para conseguir las cosas, explicada en "The pragmatic programmer". El capitán araña hace referencia al dicho "Capitán araña, que a todos embarca y a todos engaña".

En la historia de la sopa de piedras, unos soldados entran en una aldea enemiga y todos los aldeanos se esconden con toda su comida. Los soldados, hambrientos y sin posibilidad de conseguir comida de los aldeanos, cogen una olla, la llenan con agua de río y unas piedras. Lo ponen todo al fuego y empiezan a comentar lo rica que estará la sopa de piedras, típica de su país. Los aldeanos, con curiosidad por una cosa tan extraña se acercan y preguntan por la famosa sopa de piedras. Los soldados comentan que es un plato riquísimo, típico de su país, pero que no va a estar del todo buena porque le falta un poquito de sal. Los aldeanos traen la sal y entonces los soldados comentan que, para que la sope esté perfecta, necesitaría también unas patatas. Tras varias maniobras de estas, consiguen todos los condimentos para una sopa en condiciones (en cuanto sacan las piedras).

Según se comenta en el libro The pragmatic programmer, esta es una forma de conseguir las cosas. Cuando quieres conseguir algo y no encuentras apoyos, lo mejor es empezarlo tú mismo hasta donde puedas y enseñar los resultados a los demás. De esta forma, es más fácil que los demás estén dispuestos a añadir su granito de arena que tener que hacer ellos todo el trabajo.

Hace algún tiempo rubén puso un comentario en este blog indicando que le gustaba mi técnica de marketing viral para propagar las cosas entre mis compañeros de trabajo. Yo prefiero pensar que hago sopas de piedras. Que creo que es bueno usar Spring Framework, comienzo/modifco un proyecto para que use Spring Framework y le enseño a los demás como funciona y sus ventajas. Que creo que es bueno usar Javahelp, preparo la estructura por debajo, hago la ayuda de las primeras ventanas y enseño lo bonito que queda. Que creo que es bueno usar redmine, lo instalo, meto algún proyecto y lo enseño a la gente.

Pero claro, también está la versión de mi compañero de trabajo. Viene a decir algo así como "Empiezas las cosas hasta que ya no se puede volver atrás y luego no nos queda már remedio que seguir el camino que has empezado". Vaya, lo del capitán araña.

En fin, a mi me gusta más pensar en lo de la sopa de piedras y espero que mi "compa" me lo diga en broma, pero claro, también es mi opinión y es más subjetiva….

Un par de cosillas que aunque no son muy de programación, ahí van.

La primera es una pequeña anécdota que me ha pasado hoy. Pregunté a mi compañero cómo se hacía "no sé qué" con log4j, que estaba seguro de que se podía hacer, pero no recordaba cómo. El tampoco sabía, así que miró en google, encontró cómo y me mando un corredo diciendo "me engañas, sí que sabes cómo se hace" y un enlace … ¡ a mi propia página de log4j en la Chuwiki !. Creo que me estoy haciendo mayor y no sólo la mano izquierda no sabe lo que hace la derecha, sino que además no se acuerda.

La otra es sobre un compañero de trabajo, que ha hecho un sitio web sobre  venta de pastores alemanes y cahorros. Aunque es fan de las herramientas de Microsoft, casi le tengo convencido para que la haga con PHP y CSS. Por cierto, si alguien visita la página y se decide a comprar un perro, que le diga que va de mi parte, que me llevo comisión  ; – )

Parece un poco radical, pero es la conclusión a la que estoy llegando, al menos para el 99% de las empresas que hacen software.

El problema principal es que un programador que se queda de programador mucho tiempo es considerado como un fracasado. Y el programador, viendo que le consideran un fracasado, acaba sintiéndose como tal. En cuanto lleva un poco de tiempo, tienden y tiende a subir de categoría, ser jefe de algo y dejar de programar.

Sin embargo, ya lo dice el refrán, sabe más el diablo por viejo que por diablo. Hay montones de pequeñas tonterías de programación que se aprenden con la experiencia. Y son muchas pequeñas cosas. Se puede hacer un listado de ellas y dárselas a los que empiezan a programar, pero lo verán como un rollo, no entenderán el porqué de esas cosas y no pondrán en práctica la mayoría de ellas. Tampoco se las puedes explicar una a una ni perseguir que las cumplan.

El resultado es que según los programadores no fracasados ascienden y entran nuevos programadores, se tropieza una y otra vez con los mismos problemas, la misma forma no idónea de hacer las cosas.

Y es que programar bien es casi un arte. Un antiguo artesano era capaz de hacer un buen bolso de cuero, un buen botijo o unos zapatos estupendos sólo después de haber pasado unos años de aprendiz de un maestro y sólo después de haber pasado otro montón de años haciendo él mismo de maestro. Un programador entra en la empresa y nadie le enseña nada, aprende sobre la marcha y cuando aprende a compilar sin el IDE, le hacen jefe de cualquier cosa y meten a otro programador.

Así sale el software que sale y pienso que es ese el principal motivo del fracaso de muchos proyectos software, no la falta de una metodología estupenda. Y salen bien los proyectos que cuentan con la suerte de tener programadores nuevos muy, muy espabilados, o conservar programadores con experiencia y que sigan con ganas de hacer cosas sin sentirse fracasados.

Twitter lleva mucho tiempo en danza. Me dí de alta en su día, puse un par de frases y me olvidé del tema. No tenía ni idea de para qué puede servir el asunto.

Hace un mes aproximadamente empezó a apuntarse toda mi famlia en facebook, y aunque también me había dado de alta en su día, puesto un par de frases y olvidado, empezaron a darme la paliza para que lo retomara. Les hice caso y me puse a buscar gente. Encontré muchos compañeros de trabajo, algunos compañeros de colegio y mucha más familia que hace tiempo que no veo. Y allí nos hemos tirado un mes poniendo chorradas, diciendo qué estabamos haciendo en el momento. Desgraciadamente, yo soy un poco "geek" y mientras los demás ponían cosas como "pensando el disfraz para carnaval", o "me voy de cañas", yo ponía cosas como "mirando un ejemplo de hibernate" o "cagándome en python". Por supuesto, mi hermana me llamó al orden.

Así que he dejado de usar facebook con tanta frecuencia y he decidido ir poniendo estas cosas en Twiter, especialmente si pongo algún tutorial en la Chuwiki o en la página principal. Ahí, al menos, no lo va a ver nadie y quien sabe, quizás alguien tenga interés en esas cosas: http://twitter.com/chuidiang

En fin, que le he encontrado utilidad (aunque sea inútil) a Twitter.

El otro día me dio por retomar python y en concreto, me puse a ver cómo podía enviar y recibir correos con python y gmail. Y la verdad, es cada vez entiendo menos el éxito de python.

Me puse a googlear, para ver cómo se hacía lo del envío y recepción de correo. Sobre el envío hay muchos ejemplos y tutoriales, no me costó mucho hacer un poco de copy-paste de esos ejemplos, ajustarlos a lo que quería y ponerlos en marcha. La recepción de correos es otro tema, apenas hay tutoriales o, por lo menos, no los he encontrado, salvo uno que parece copiado una y otra vez que es el de ver cuántos correos tengo y sacar por pantalla, en bruto, lo que recibimos del servidor. No me extraña, porque python se usa sobre todo con aplicaciones web y en estas aplicaciones web lo habitual es enviar correos, no leerlos. Me costó un montón encontrar cómo se "parsea" el mensaje leido, para extraer sus adjuntos, el texto, etc, etc. Al final encontré un ejemplo en un foro perdido de alguien que lo había puesto para contestar a alguien.

Pero bueno, eso son mis peripecias concretas y no tienen nada que ver con que python sea bueno o malo. Las cosas que veo mal de python son las siguientes:

Por un lado, al no ser en absoluto tipado, me da la impresión de que debe ser muy, pero que muy complejo, hacer y mantener un programa grande. O pones muy buenos comentarios, o nunca sabrás qué te esta llegando como parámetro en una función, qué tienes que pasar como parámetro a una función o qué te devuelve una función.

Los IDE lo tienen bastante dificil con los autocompletar. Desde luego la sintaxis coloreada ayuda mucho, pero lo fundamental para mí de un IDE es el autocompletar. Sin necesidad de ir a mirar dónde está definida la clase o sin tener que ir a la documentación, tener accesible qué métodos tiene y qué parámetros puedo pasarle. Eso, en python, con un IDE, es poco menos que imposible, salvo quizás (no lo he probado), que se haga el "new" en el mismo sitio. El único autocompletar que he visto lo que hace es ponerte los métodos que ya has usado para esa variable poco más arriba en el código. El primer autocompletar de esa variable sale vacío, el segundo sale con el método que hayas usado en el primero y así sucesivamente.

Bueno, el autocompletar, aunque es una ayuda importante, no sería tan grave si la documentación estuviera en condiciones. Pero me temo que, al menos para mí, tampoco es así. Con esto del correo me he ido a la documentación, a ver los métodos de clases como POP3_SSL o SMTP. Vamos, por ejemplo, al método list() de POP3 o el retr() que está justo detrás. Bien, ambos devuelven una cosa estilo (response, ['message num_octects', ... ], octects). ¡¡ Mande !!. Lo de response pone más arriba que es el texto de respuesta del servidor, así que en principio no hay mucha pega. Lo de message num_octects… bueno, intuiremos que es un string por aquello de que está entre comillas, intuiremos que es el número de bytes del mensaje y que esa lista tiene tantos números-string como mensajes. Lo del octects del final ya se me escapa. También es cierto que eso que hemos intuido del segundo parámetro, lo he intuido después de haber hecho el ejemplo, porque en mi primera lectura me sonó a chino.

Dicen que la ventaja de python sobre java es que se escribe menos código (ver imagen), pero mi impresión es que cuesta más escribirlo. Y desde luego, me hace la impresión de que cuesta muchísimo más mantenerlo. Pero si tiene el éxito que tiene y se usa tanto, supongo que todo esto en realidad son las impresiones de un novato mal acostumbrado a java. Seguramente estoy equivocado y tendré que seguir con ello para ver si llego a acostumbrarme.

Siguiendo la última entrada de bicosyes – since evermore…, llegamos a un trozo de código con una licencia nueva interesante que seguramente es muy vieja, pero con mi despiste habitual no había visto nuca: WFTPL, o DoWhatTheFuckYouWant Public Licence. Creo que voy a empezar a aplicarla en algunos de mis "chismes".

En varias ocasiones he visto sobre el tema de persistencia en java la discusión de si es mejor usar annotations o ficheros de configuración XML.

Mi primera opinión, sin pensar mucho más, es que era mejor los ficheros de configuración XML, sin lugar a dudas. ¿Por qué?. Pienso que los bean de java deben ser reutlizables de proyecto en proyecto, que la base de datos es un tema aparte cuyas tablas pueden cambiar de un proyecto a otro y no me gusta meter dependencias de jar raros en mis clases básicas del modelo de datos. Las annotations de persistencia necesitan esos jar para compilar. De alguna forma, pienso que estoy "casando" mis clase con una herramienta específica.

Sin embargo, ahora que me he metido a jugar un poco con hibernate más en serio y empiezo a comprender la filosofía de trabajo de estas herramientas de persistencia, empiezo a dudar si es mejor los ficheros XML.

Por un lado, estoy mal acostumbrado en los proyectos en los que trabajo. Alguien diseña la base de datos primero, o incluso nos la da el cliente ya hecha y tenemos que hacer código para tratar con esa base de datos. De proyecto en proyecto, aunque la temática es la misma, nos hacen cambios en las bases de datos. Por ello, nuestras aplicaciones pretenden tener su propio modelo de datos a base de java beans y tratan de aislarse lo más posible de los detalles de la base de datos. El patrón DAO se nos hace fundamental.

Pero veo que la forma de trabajo de Hibernate está pensada al revés. Tú te haces tu modelo de datos con java beans y te olvidas de la base de datos. Con annotations o con ficheros XML haces el mapeo de esos beans sobre la base de datos e Hibernate se encarga de crear todas las tablas. Y pensándolo de esta forma, en que lo principal son tus java beans y las tablas de base de datos son "secundarias", empiezo a ver ventajas en las annotations sobre los ficheos XML.

Si se hacen java beans y ficheros XML de mapeo separados, estamos hasta cierto punto violando el principio DRY (Don`t repeat yourself). Si tocamos los java beans, debemos acordarnos de tocar el XML correspondiente y al revés. Debemos tocar en dos sitios distintos si cambia el tipo de una columna, añadimos o borramos un atributo a un java bean, etc. Con annotations es más dificil el despiste. Si cambio un atributo, lo añado o lo borro, la annotation está justo al lado y es más difícil olvidarse de ella.

Además, si vamos a reutilizar nuestros beans en otros proyectos y vamos a seguir el mismo mecanismo de persistencia, dejando a Hibernate o la herramienta de turno crear las tablas de base de datos, no es tan malo llevarse los bean con sus annotations. De hecho, es más cómodo que llevarse los bean y además sus ficheros xml.

La única pega que le veo a esto es que las annotations en ocasiones se complican demasiado, quitando claridad a un código en principio simple (un java bean). Y como ejemplo, este trozo de código sacado de la documentación de Hibernate, donde sólo se empieza a declarar la clase Forest (si, fíjate al final, la última línea….)

@Entity
@BatchSize(size=5)
@org.hibernate.annotations.Entity(
        selectBeforeUpdate = true,
        dynamicInsert = true, dynamicUpdate = true,
        optimisticLock = OptimisticLockType.ALL,
        polymorphism = PolymorphismType.EXPLICIT)
@Where(clause="1=1")
@org.hibernate.annotations.Table(name="Forest", indexes = { @Index(name="idx", columnNames = { "name", "length" } ) } )
@Persister(impl=MyEntityPersister.class)
public class Forest { ... }

Hace algún tiempo me puse a jugar con Hibernate y no me causó demasiada buena impresión. Me daba muchos problemas, las herramientas que bajaba parecian bastante descuidadas, no me funcionaba nada bien sin tener que pelearme con ello y un sin fin de descalabros. Pero estos días atrás me entró remordimiento de conciencia. De aquella, había empezado supongo que de mala manera, sin saber nada de hibernate, tratando de arrancar las herramientas de "ingeniería inversa", es decir, tratar de sacar de las tablas de base de datos ya creadas los bean de java y los xml de mapeo. Así que hace unos días me decidí a retomar el tema desde cero, empezando con la documentación de Hibernate y siguiéndola más o menos paso a paso.

Pues creo que me reafirmo en mi idea. La documentación, aunque están claros los conceptos que explica, deja bastante que desear en cuanto a cómo arrancar el ejemplo. Ahi van algunas pegas:

• Si te bajas hibernate, no vienen ahí todos los jar necesarios. Aparte del conector con la base de datos, se echa en falta una implementación para slf4j-api. Hibernate trae la Api, pero no la implementación y no funciona el ejemplo sin una implementación. Sí, la documentación dice que es necesaria una implementación en el punto 3.5,  pero el ejemplo y el arranque del mismo está en el punto 1.2. No parece el orden adecuado eso de "tú arranca, que más adelante te diré qué está mal".
• Si intentas la configuración con maven, en la documentación no pone el groupId a usar, sino una variable ${groupId} que no está definida en ningún sitio. Bueno, no cuesta mucho inventarse un valor y sacarlo, pero podrían haberlo puesto. Por cierto, tampoco pone la versión.
• Si sigues con maven, no se baja el jar de javassist, sea lo que sea eso. El caso es que en el pom.xml debes poner la dependencia a mano y en la documentación no lo indica.
• Además, por supuesto, falta la dependencia de la implementación de slf4j-log4j (o el logger que quieras). La podemos poner sin problemas, pero hay que tener cuidado, porque la versión que se ponga de dicha implementación debe coincidir con la versión de slf4j-api de la que depende hibernate y, que por supuesto, tampoco se ve directamente en ningún sitio.

En fin, que el ejemplo muy bien, pero ponerlo en marcha cuesta unos cuantos ensayo, error y googlear, añadiendo dependencias y jars, según nos van saliendo errores. No me extrañan nada comentarios como este de Nicolás.

Así que como siempre, copiando de la documentación y ampliándola precisamente en estas pequeñas pegas, ahí va mi "Hola mundo con hibernate", en el que espero quede más claro exactamente que jars necesitamos y cómo arrancar la aplicación de la documentación.

Y de paso, sigo leyendo la documentación dichosa, a ver si aprendo algo de Hibernate. Lo que he leido y probado hasta ahora me está gustando bastante.

Respecto a lo de skydrive que comenté el otro día, resulta que en aDrive dan 50 Gigas, también gratis y sin límite de tamaño de fichero (skydrive limita a 50 Megas).

¿Alguien da más?. ¿Cuanto tarda un upload de 50 Gigas con un ADSL normal?

Como de todos es sabido, soy un "pupas" y las cosas nunca me funcionan bien a la primera ni a la segunda. Comenté hace unos días que había instalado y probado sonar. Las primeras pruebas fueron bastante bien, pero con el uso me he ido encontrando las pegas.

Realmente, pegas no tiene muchas, en realidad, sólo le he visto una, pero molesta bastante.

El plugin de sonar para maven compila nuestro proyecto y pasa todas las métricas. Luego, se pone a insertar en la base de datos de sonar toda esa información. Durante ese tiempo, el servidor web de sonar se queda bastante pillado y responde muy lentamente. El problema es que en ese ordenador tenemos también instalado redmine, archiva y hudson. Todas esas "web" dejan de responder o responden muy mal mientras se están insertando estadísticas en la base de datos.

La siguiente pega, que es más de lo mismo, es que el plugin de sonar para maven también intenta acceder a la web de sonar. No sé el motivo exacto, pero me estoy temiendo que es para avisar al servidor de sonar de que hay nuevas estadísticas en base de datos y empiece e echar unas cuentas, organizar los datos o algo. El caso es que cuando el plugin de maven termina, el servidor sonar puede tirarse diez u once minutos "procesando estadísticas", según pone en la web. Durante ese tiempo, todo el ordenador va muy lento y dejan de responder el hudson, el redmine y el archiva.

Y otra pega más, que viene a ser lo mismo, es que cuando el plugin de maven intenta acceder a la web de sonar, tiene para mi gusto un timeout muy corto, dando error rápidamente si no consigue conectarse. Basta con que pille a Hudson compilando para que aquello tenga ciertas probabilidades de error en la conexión. Y no te digo si le pilla procesando estadísticas del mismo sonar de un proyecto anterior. Ahí es imposible conectarse y hay que esperar. Esta pega es realmente gorda, porque me impide meter el plugin de sonar en el hudson, de forma que además del compilado nocturno, se calculen las métricas nocturnas. El compilado del primer proyecto funciona o no, según le de, pero los demás nunca funcionan.

Total, que voy a tener que agenciarme otro pc/estación de trabajo para instalar exclusivamente sonar. Y aun así, quizás hudson no pueda publicar las estadísticas si pilla a sonar "procesando" información.

Ah, el ordenador no es lo más mejor del mundo, pero tampoco es viejo. Supongo que tendré que probar en un linux en vez de un windows, o quizás es una estación de trabajo solaris.