Antiguo y abandonado blog de Ricardo Galli :-(

Hace ya bastantes años que tengo centralizado todo mi correo en mnm.uib.es. Allí me llegan los correos (re-enviados) de @uib.es y @mnm.uib.es. Además tengo el fetchmail que me recoge el correo vía POP3 desde otro par de cuentas de antiguos ISPs y de AtlasInternet, empresa de la que fui socio fundador.

Desde casi el primer día que salió también uso Gmail, y cada vez más. De hecho ahora se convirtió en mi dirección principal. Pero siempre he tenido todo duplicado, lo que me llega a Gmail lo re-envió a mnm.uib.es y viceversa (así cuando estoy en casa o la UIB uso el Kmail con IMAP del mnm, pero cuando voy de viajes o con el portátil uso siempre Gmail).

En fin, que es una chorrada monumental pero puede servir a alguien: la forma más simple de hacer lo anterior sin perder correos y fundamental sin tener correos duplicados que se re-envían de una cuenta a otra. Para ello uso el formato usuario+etiqueta@...

(more…)

Para los que hayan estudiado informática (o sean buenos programadores ) les sonará el término deadlock, o “interbloqueo”, o “abrazo mortal”. Es una situación que se puede producir en la compartición de recursos de un ordenador cuando muchos procesos intentan acceder a recursos compartidos y se llega a una situación de “bucle” (es en grafo de asignación) en el que ningún proceso puede continuar porque está esperando recursos asignados a otro que a su vez también espera que se liberen otros recursos…

Hay muchos métodos para evitar que se produzcan los interbloqueos, desde prevenirlo evitando que se produzca una de las cuatro condiciones necesarias:

1. exclusión mutua,
2. retención y espera (hold and wait),
3. no apropiativo (no preemption),
4. espera circular (circular wait).

Muchas veces no es posible evitar que se produzcan esas condiciones y se deben tomar otras medidas más complejas:

1. Prevención dinámica: en cada solicitud de recursos se verifica si la satisfacción de esa asignación podría llevar a una situación “peligrosa” de interbloqueo. Aquí se usan algoritmos o técnicas similares y derivadas del algoritmo del banquero.

2. Detección y recuperación: otra forma es detectar cuando se ha producido un interbloqueo mediante técnicas de detección de bucles en un grafo. Es un poco más complejo (fundamentalmente de complejidad O(n^2)) por lo que se usan simplificaciones –por ejemplo poniendo tiempos de expiración a los bloqueos–. El problema es cómo “recuperarse” de un interbloqueo, no es nada simple. Hay dos técnicas fundamentales:

   a. Matar a unos o varios de los procesos involucrados en el interbloqueo. De esta forma se “rompería” la espera circular y los demás procesos podrían continuar. Este tipo de soluciones es subóptima, ya que es muy difícil escoger al proceso adecuado (lo que pasaba con el Out of Memory Killer del Linux, que era una forma de soluciones el interbloqueo generado por la falta de memoria) y además producen que se acaben procesos de forma errónea.

   b. Vuelta atrás o roll back. Esta técnica se basa en retornar el estado del proceso a uno anterior conocido y luego dejarlo continuar. Es muy difícil hacerlo en un sistema operativo genérico, pero es un área muy conocida y usada en las bases de datos transaccionales.

¿A qué viene todo este rollo? Al siguiente mensaje que me encontré varias veces en una página web enlazada desde Slashdot:

Microsoft OLE DB Provider for ODBC Drivers error ‘80004005′ [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 156) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. /efytimes/lefthome.asp, line 193

Me llamó mucho la atención por varios motivos:

1. El problema en este caso era claramente una “sobrecarga” de la base de datos. En estos caso lo que suele ocurrir es una “espera infinita” (o starvation) y no un interbloqueo.

2. El tiempo entre el acceso a la página y el mensaje que obtenía era muy corto y se cargaba rápidamente, por lo que quizás no era una espera infinita sino de un interbloqueo de verdad que haya sido detectado por la base de datos (en este caso SQL Server).

3. Que una base de datos transaccional tenga problemas de deadlocks con un caso tan sencillo de consultas para generar una página web. Quizás tengan alguna actualización para registrar accesos, pero en todo caso ésta debería ser independiente de las consultas para generación por lo que:

   1. La página se podría haber generado igualmente y ocultar el error al visitante.

   2. EL SQL Server o el programa de la página web tiene un serio problema en las actualizaciones.

En todo caso esto me recuerda nuevamente a que “no hay soluciones mágicas”, muchas veces los sistemas más complejos y sofisticados no son lo mejor para tareas sencillas como generar una página web. Lo que explica en gran parte el porqué la base de datos MySQL se hizo tan popular en servicios web aún cuando no tenía ni los mínimos requisitos para ser una base de datos ACID. También explica porqué se sigue usando mucho el motor MyISAM (sin locks por filas ni transacciones) en vez del InnoDB que sí tiene todas las características transaccionales (y rollback por interbloqueos).

Y por otro lado me recuerda lo estúpido que pueden ser los presuntos “mensajes de error ultra explicativos”. ¿Cuántos lectores entenderían ese mensaje?

Es más, ¿cuántos “informáticos” o presuntos geeks lo entenderían correctamente?

Pues eso, que este apunte sirva para entusiasmar a estudiar esa “informática dura” pero que en realidad es la más divertida… o al menos tenga valor didáctico para entender los mensajes tan guais del SQL Server

Acabo de recibir el siguiente mensaje de un amigo de una noticia que parece pasaron por las noticias de TVE-2 de las 2 de la madrugada.

En las noticias de la 2 de las 2,30 han comentado el asunto de la actividad vandalica que se atribuye recientemente a la CIA alterando la entrada de la wikipedia y se han referido a algún caso más. 

Para darle mas interés a la noticia han calificado a la wikipedia de “enciclopedia libre, tan libre que cualquiera puede alterarla”, y una amable “experta” ha ilustrado a los televidentes con un ejemplo práctico sobre lo fácil que es vandalizarla. Lo ha demostrado  introduciendo en la  entrada de Lennon una afirmació “sobre su interés por la paella”. Después ha dicho que de todos modos también es posible con mucha facilidad volverlo a arreglar.

Lamentable. ¿Alguien lo ha visto o puede confirmar? (Edición: parece que ha sido en TVE1, mi respuesta).

Actualización: por el comentario #1 veo que se trata del usuario Cristina Olea. Encontré datos de ellas por Internet relacionadas con TVE, como no estoy seguro de que sea la misma persona me los reservo. ¡Qué vergüenza! Desde una televisión pública haciendo guarradas y en directo (además que lo dejó sin eliminar). ¿Comentarán este caso por los noticieros? ¿Explicarán lo rápido que se solucionó? ¿Está esto incluido en la asignatura de educación para la ciudadanía?

Segunda actualización: Antena 3 ha seguido el mismo ejemplo (vía Menéame, también en Barrapunto). Felicitaciones a TVE por mostrar el camino, y a Antena 3 por ayudar en la diseminación de los “valores ciudadanos” que predica la televisión pública. Pero podrían haber sido al menos más originales.

Hace unas horas escribí Ahora empiezan a verse los problemas del ERP. Sergi de Tecnorantes me contesta en su blog porque la respuesta le estaba quedando muy larga para un comentario.

A mí me pasó exactamente lo mismo, así que lo que iba a ser un comentario de lo que discrepaba lo dejo finalmente como un nuevo apunte.

Discrepo fundamentalmente en:

No obstante, y aquí si que voy a discrepar ligeramente con Ricardo, el que el ERP sea libre o propietario no cambia mucho el escenario. … Como decía, libre o propietario, el escenario no cambia esencialmente.

Como bien dice Sergi (Obviamente los proveedores van buscando la cautividad), la cautividad es uno de los objetivos perseguidos por los proveedores. Esa cautividad desaparece automáticamente si el programa es libre –aunque hay tácticas como la de MySQL para mantenerla a pesar de la licencia libre–. La frase tan repetida el software libre libera el mercado de servicios lo explica todo.

Yo diría que todas las otras razones de los problemas del ERP son prácticamente derivadas de su característica de privativo, especialmente aquellas de los altos costes de puesta en marcha y personalización. Si el programa fuese libre este mercado de servicios sería mucho más competitivo y seguramente de mejor calidad.

Pagar a consultores por extender el ERP es un coste para la empresa, tanto si el ERP es libre como propietario, como también lo es si tienes que tener a personas en plantilla para hacer las adaptaciones.

No es así, porque no sólo los costes no son comparables –costes de cautividad versus costes de mercado libre–, sino que en un caso estás muy limitado a lo que puedes hace –”personalizar o adaptar módulos”– mientras que en otro tienes la libertad de cambiar hasta el propio núcleo.

Si los ERP fuesen libres –¡ojo! que no digo que en su momento haya sido posible– la evolución hubiese sido muy distinto. Por ejemplo hoy tenemos que la infraestructura imprescindible para la gran mayoría de proyectos “web 2.0″ es la pila LAMP. Esta pila no surgió como una agregación instantáneo por diseño de comité o de un “producto” de una empresa, sino que fue una agregación natural y casi biológica.

Pero hay un caso paradigmático al que llamaría la “Ley de Evolución Impredecible del Software Libre”, o LEISL:-) ). Cuando Linus Torvalds liberó la primera versión del núcleo Linux fue muy criticado –especialmente por Tanenbaum– por tratarse de un núcleo monolítico. Según ellos esta característica haría imposible que el núcleo pudiese exportarse a otras plataformas distintas a la original x86 (de hecho el diseño original de Linux esta orientado específicamente a esta plataforma).

Sin embargo pocos años después el núcleo Linux (y toda la pila GNU que lo convertía en un sistema operativo completo) se ejecutaba en más plataformas que ningún otro sistema operativo, desde pequeños controladores, set top boxes, ordenadores personales hasta los superordenadores más grandes. Eso no lo había logrado nadie, ni siquiera grandes y multimillonarias empresas como Microsoft que ni siquiera pudo mantener el soporte multiplataforma del Windows NT, a pesar que estaba especialmente diseñado para ello.

Por el contrario el ERP es por diseño una “pila” preconcebida con algunas opciones, y los módulos y opciones dependen exclusivamente de un sólo proveedor. Este diseño tiene problemas intrínsecos de complejidad como detallan en los estudios enlazados, pero además tiene el problema de la cautividad. El cliente está atado y sujeto sólo a las soluciones de su proveedor.

Además en el estudio comentan que muchas empresas siguen todavía con versiones de hace diez años porque les es imposible gastar nuevamente fortunas en nuevas versiones y la correspondiente adaptación y pruebas de todas sus “personalizaciones” que funcionan en las versiones antiguas.

“It didn’t matter that he was honing his skills on a 10-year-old version of the software because the costs of upgrading are so huge — tens, even hundreds of millions of dollars, or as much as it cost to install the stuff in the first place — that he keeps installing old versions of the software so that it will line up with the old software they already have.”

¿Qué hubiese pasado si cada empresa hubiese podido adaptar o mejorar cada uno de esos módulos en vez de tener que conformarse con hacer cada vez más chapuzas con versiones antiguas o invertir grandes cantidades de dinero? Y aquí traigo a colación a la LEISL, quizás hubiesen evolucionado hacia una pila SOA de forma natural.

Reconozco que lo anterior es pura especulación, pero la realidad es que hay evidencias serias de que los ERP podrían haber sido un gasto inútil de tiempo y grandes cantidades de dinero sin que haya habido un mejora y simplificación de los procesos de negocio. Quizás todo lo contrario.

Me decía que él era partidario de pequeñas soluciones específicas para cada problema, y que se comunicaran bien entre ellas.

Esto es lo que precisamente falló en los ERP, era una solución muy compleja y que además generaba una gran cautividad, yo diría que insostenible (y no me explico cómo una empresa, sobre todo las grandes, pueden gastar tanto dinero para convertirse en prisioneros).

El truco está en cómo unir todas esas pequeñas soluciones específicas para que funcionen en armonía. Yo creo que la única opción es que se agreguen naturalmente y que vayan definiendo sus propias “pilas”, como ha pasado con GNU/Linux y LAMP. Esto no se logrará con la cautividad actual de los ERP privativos –aunque Microsoft lo entendió muy bien en el caso del Windows, que es mucho más “abierto” a desarrollos externos que su propio Navision–

La verdad es que casi me da igual si una empresa usa o no software libre, problemas de ellos. Pero estoy seguro que si hubiesen adoptado soluciones libres –o al menos abiertas– no estarían sufriendo los problemas de dinero y complejidad que tienen ahora. También estoy seguro que un ERP libre hubiese evolucionado de forma muy diferente, quizás hoy el SOA sería lo habitual o estaríamos hablando de “pilas de software de negocio”.

Ahora veremos como las grandes se liberan de la cautividad de SAP, y las medianas y pequeñas del Oracle o Navision. Será divertido, sobre todo escuchar las justificaciones

Nicholas Carr hace un breve comentario sobre los problemas del ERP a partir del estudio The Trouble With Enterprise Software en MITSloan.

Aunque dije que escribiría sobre ello mañana, con más tiempo y las neuronas en un estado menos pésimo que lo habitual, pero no pude reprimirme.

A mí me parece que es una especia de catástrofe anunciada. Desde mediados de los 90, cuando ya era notable la forma en que Internet estaba cambiando de forma radical nuestra forma de usar los ordenadores y de interactuar con las personas (y clientes), las grandes empresas se lanzaron a gastar enormes fortunas a su propia “revolución” del negocio, los ERP.

Aunque sólo se trataba de una aplicación de las arquitecturas cliente-servidor, las modularización (como la que conocemos en Unix desde hace casi 40 años) y las ideas de las hojas de cálculo aplicadas al software de gestión de las empresas.

La promesa era que ya no había que programar casi nada, sencillamente había que instalar y configurar los módulos adecuados y “personalizarlos” casi como si se tratasen de hojas de cálculo.

La realidad fue mucho más compleja, los principales problemas según el estudio son:

1. Se tardaba muchísimo tiempo en ponerlos en marcha por la complejidad de la “personalización”.

2. Se gastaban fortunas en consultores externos que hacían dicha instalación.

3. El 75% de los proyectos de instalación de ERP fallaron, tanto que acabar con la puesta en marcha ya era considerado un éxito en sí mismo.

4. Se han dado cuenta de la exponencialmente creciente complejidad del software, que la idea de tratar módulos de software como piezas de Lego es imposible.

Aunque en el estudio no lo mencionan hay otro problema fundamental, las empresas se volvían cautivas de sus proveedoras de software (fundamentalmente SAP y Oracle). Sumado a que estos programas son privativos, de millones de líneas y que el panorama informático estaba cambiando radicalmente, se tiene la receta perfecta para la catástrofe a medio plazo.

Pues parece que eso está ocurriendo, y aunque muchos plantean que la solución es la nueva palabrota de moda, el SOA (Services Oriented Applications), parece que tampoco se libra de sus problemas. Estos sistemas SOA heredarían y mezclarían código de los ERP aumentando así su complejidad –y yo diría también la cautividad–.

Pero lo importante del estudio es que de alguna manera formaliza el problema: aunque estaban diseñados para reemplazarlos, los ERP ya son parte de los sistemas legacy (heredados) de las organizaciones. Pero además han agregado aún más complejidad después de gastarse fortunas.

Se acercan años de justificaciones y cambios importantes en los departamentos. Carr dice que tampoco sabe la solución, yo creo que hay pistas por dónde irán las cosas. Una de ellas es que el “tratamiento masivo de datos” es un área “caliente” de investigación e incluso de negocios: es el fundamento de Google –que lo lleva al extremo de hacer altamente distribuido, replicado y auto recuperable–, y de casi todos los nuevos sitios sociales o Web 2.0 (aunque estos en mucha menor escala).

Quizás dentro de unos años veamos que además de lo que está enseñando Google a los conservadores informáticos de “empresas”, lo que hoy conocemos como Web 2.0 también dejará su contribución (sino basta mirar los problemas y soluciones ad hoc de bases de datos en Technorati, Wordpress.com, Facebook, Digg, Twitter… [1]):

No te preocupes tanto de los programas y algoritmos como de la forma en que almacenas y recuperas una enorme cantidad de datos, con latencias mínimas y alta disponiblidad.

A los estudiantes que me preguntan les digo siempre que se dediquen a estudiar a arquitecturas y organización de bases de datos orientadas a tratamiento de enormes cantidades de datos.

[1] Menéame no es comparable en volumen de datos, aunque también una cantidad considerable –12 millones de votos, 1 millón de comentarios, 200.000 noticias…– y los requisitos de tiempo de respuesta son similares –incluso más estrictos– y con 800 consultas por segundo de media a la base de datos.

Veo en “Ya no te ajunto” de Tecnorantes el pollo que han montado entre Calacanis y David Winer, tirándose los trastos entre ellos. La verdad es que son cansinos. Tampoco entiendo cómo ambos se convirtieron en gurús de la blogosfera (aunque en realidad está claro).

Pero en fin, me agrada mucho como no tienen problema en criticarse sin pelos en la lengua aunque con un lenguaje educado y poniendo los enlaces adecuados para que el lector conozca la opinión contraria. Además seguramente se encuentran en los habituales piscolabis y barbacoas y se descojonan de risa juntos.

Es muy educativo para la blogocosa nativa. Aquí las reacciones y lenguaje hubiesen sido muy distintas. Si Calacanis hubiese sido un cañí podría haber hecho lo siguiente:

1. Método repetitivo pero sin riesgos, el-comentarista-anónimo-sabelotodo

Iría a todos los blogs de la Alist y dejaría comentarios desvelando presuntos secretos de Dave Winer, salpicado de unos cuantos comentarios del estilo:

Es un cabrón/ladrón/inútil que censura cuando no le gusta algo.

2. Método perezoso-no-sabe-con-quien-se-ha-metido

Editaría http://en.wikipedia.org/wiki/Dave_Winer y pondría allí cosas como:

Es un censurador que interfiere en los negocios de Calacanis por pura envidia. Además ha abusado sexualmente de niños y robado dinero del petróleo de Irak y varias ONG.

3. Método sofisticado sin riesgos: el-blogger-anónimo-que-desvelo-la-verdad

Abriría un blog del tipo “deconstructingwiner.wordpress.com” y escribiría lo mismo que #1 y #2 pero en plan apuntes. Además en los apuntes pondrá una foto de Dave Winer con Xeni Jardin en alguna fiesta y le pondría un pie de foto del estilo:

Las relaciones entre la glamurosa damisela y Winer son claros. Mientras a uno le interesa aquello que lleva debajo de tan fastuoso vestido, la otra lo aprovecha para conspirar contra los negocios de su ex patrón al que abandonó por el insoportable acoso al que la sometía.

4. Método spammer-ofendido-sin-tapujos

Escribiría en su blog un apunte titulado

CENSURA!!! CENSURA!!! La MAFIA de Winer y su doble moral censura a Calacanis

Luego de escribir el apunte –por supuesto sin ningún enlace a las respuestas de Winer– enviaría el enlace a Digg. Netscape, Corank, Techmeme, BoingBoing, Slashdot, etc. Así por varios días seguidos.

5. Método con-cojones-pedante que está por encima de todo

Winer me invitó y no me avisó de nada, tal como se ve en la imagen de abajo. Asistí al encuentro en cuyo programa no se avisa de nada –adjunto enlace–, hablé por teléfono con él –adjunto trascripción abajo– e incluso nos intercambiamos los siguientes emails que muestro abajo.

Vaya vaya con estos blogocósicos.

(no sé porqué este método me suena mucho)

6. Método Finoli 2.0 al-enemigo-ni-agua

Aunque arranques mi leproso brazo no podrás evitar que escupa tu estúpida cara — Joe Sixpack en “El regreso de los zombies de Rubik al infinito de Pi”

La verdad que prefiero a los Winer-Calacanis, son divertidos además de cínicamente elegantes.

Pero también es verdad que los métodos nativos también pueden ser divertidos, menos el #6 (aunque esas frases de copiar&pegar es lo mejor que pueden hacer para generar reacciones sinápticas).

PS: Hay otro método muy de moda, el Manga-troll: dibujar enrollados aunque insultantes cutre-comics sobrecargados de referencias a películas clásicas. Pero no sé dibujar ni una montaña nevada, lo siento.

Como era de esperar, el apunte Diez señales de que no eres tan buen programador como piensas generó mucho debate (también en Java Hispano, como era de esperar por mencionar a Java:-) ), como también respuestas falaces y alguna que otra crítica como “que es muy generalista y/o poco técnico”. Pues vale, empecemos con algo más “técnico” para seguir pasando el agosto.

Supongamos que en C (en Java debería dar resultados comparables [1]) inicializamos una matriz de tamaño considerable:

#define S 10000

int a[S][S];

Al bucle siempre lo haríamos de la siguiente forma:

for (i=0; i<S; i++)
    for (j=0; j<S; j++)
        a[i][j] = 0;

Preguntas:

1. Explicar porqué –casi intuitivamente aunque muchas veces sin saberlo– hacemos la asignación así y no a[j][i].

2. Fundamental aunque derivada de la anterior. ¿Por qué si hacemos la asignación a[j][i] el código se ejecuta al menos un orden de magnitud más lento? La respuesta es muy concreta y se puede dar en menos de dos tres líneas.

3. ¿Por qué pongo a la matriz como global y no local?

4. ¿Por qué a veces las primeras veces que se ejecuta el código toma más tiempo que en las siguientes?

5. ¿Qué relación tienen este problema de eficiencia con la programación estructurada?

[1] Pruebas con Java

Hice las pruebas en un “sencillo” programa en Java.

class j1 {
        public static void main(String[] args) {
            int[][] a = new int[10000][10000];
            int i, j;
            for (i=0;i<10000;i++)
                    for (j=0;j<10000; j++)
                            a[i][j] = 0;
       }
}

Con Java GNU no tuve ningún problema para ejecutarlo, todavía no sé cómo lograr que se ejecute el Java6 de Sun sin que me de problemas de heap y luego que pueda pre-asignar la memoria con el -Xmx y -Xms, me da siempre Could not create the Java virtual machine ¿Alguien sabe cómo resolverlo si liarme con clases especiales? En resumen, el ejecutable “óptimo” tarda unas 6 veces más que C, unos 6.5 segundos. Mientras que en C el bucle erróneo toma 11 segundos, en Java 25 segundos.

Conclusión de Java: la gestión de memoria es bastante más lenta y se nota menos la diferencia entre uno y otro (no llega al orden de magnitud). Pero lo importante: también hay con el mismo cuidado que con C, el compilador no “optimza” estos casos. No vale la excusa, “en Java no te preocupas de estos temas”.

PS: Por favor abstenerse mis alumnos y amigos que me hayan escuchado sobre este ejemplo

La señora Rowling cautivó primero a los niños, demostrando con la irrefutable lógica de algo así como tropocientos de millones de libros vendidos que los chicos están deseosos de dejar de lado sus iPods y Game Boys para coger libros… si la magia está en ellos — Stephen King en una [altamente positiva] crítica a la serie Harry Potter.

Como es verano, hay mucho tiempo para pensar, me hizo gracia Diez señales de que no eres tan listo como piensas, y tenía ganas de provocar un poquillo elaboro la misma lista pero para programadores.

1. Estás convencido que eres “muy buen programador”.

   En general los buenos programadores interactúan y trabajan mucho con el código de otros programadores, y siempre hay alguien que tiene soluciones más creativas, eficientes y elegantes que lo que se le puede ocurrir a una sola persona.

   Los buenos programadores suelen pensar que hay demasiadas personas que programan mejor que él.

2. Reconoces inmediatamente a Jobs, Gates o Torvalds pero no sabes quiénes son y/o qué han hecho Turing –además de su modelo matemático tan conocido–, von Neumman –además de su famosa definición de “arquitectura”–, Dijkstra, Knuth, Wirth, Kernighan, Ritchie, Engelbart, Corbató, Hoare, Minsky…

   ¿Irías a un médico que no sabe qué ha hecho Pasteur o Ramón y Cajal? Pues eso. (No significa que saber la vida de esos personajes garantiza ser buen médico, pero un buen médico seguro que lee mucho sobre su profesión, si no sabe es que ni siquiera se preocupa en leer más allá de lo que le exigieron en la carrera, y que además se le olvidó una gran parte).

3. A primera vista del código de programas grandes de otras personas dices “vaya mierda de código, muy complicado, yo lo puedo hacer mejor”.

   En general los programas grandes son desarrollados por muchas personas, cada una con su visión –a veces contradictoria con otros– y estilo propio. Aunque haya sido desarrollado por una sola persona, seguramente ésta evolucionó y cambió –en general a mejor– durante el desarrollo. También van cambiando la “realidad” y las herramientas, lo que implica que las soluciones no son siempre las mismas. Además el software se hace cada vez más complejo y requiere soluciones sofisticadas para solucionar los diversos problemas –por ejemplo las race conditions– que aparecen.

   Un programador que ha participado en proyectos grandes reconoce inmediatamente estos patrones y problemas asociados, además de tener muy claro que una sólo persona es incapaz de desarrollar grandes programas por sí sola, por eso nunca desmerecería el trabajo de otros sin un conocimiento exhaustivo del programa y sus problemas asociados (y lo más seguro es que envíe parches o soluciones mejores).

4. Justificas que tu código es ilegible para no mostrarlo o publicarlo.

   Este es un problema bastante importante en la gente que empieza a programar… y si perdura con el tiempo es que nunca ha llegado a comprender que los lenguajes de alto nivel se han desarrollado para las personas, no para la CPU –que sigue entendiendo sólo binario–.

   Así te encuentras con código sin sangrar, variables y funciones con nombres que no dan ninguna pista de lo que hace –kaka, pepito, f1, v1…–, variables de una letra –como i, j, k– usadas en variables que no son contadores ni índices, ningún comentario… o lo que es peor, exceso de comentarios del tipo /* asigno 0 a la variable i */.

   Como las novelas, ¿alguien leería novelas sin ningún tipo de estructura de oraciones, párrafos y capítulos? ¿o sin signos de puntuación o escritas en lenguaje de teléfonos móviles? Si uno sabe de antemano que su código será revisado y modificado por otras personas se plantea escribirlo de otra forma, más acorde con el estilo de cada lenguaje y que sea agradable de leer.

   Ésta es una gran ventaja de los programadores de software libre, además que se programa pensando en que otros lo mirarán, en general ya ocurre lo que está explicado en #2: se aprende mucho mirando el código de otros.

5. No sabrías definir en pocas palabras qué es la programación estructurada, ni sus relaciones y ventajas/desventajas con las arquitecturas y diseño del hardware.

   Pues eso, un buen programador sabría explicar que las estructuras de control tienen un sólo punto de entrada y puede tener varios puntos de salida –aunque hubo bastantes discusiones sobre este aspecto–, y que estas restricciones tienen mucho que ver con las “localidad espacial y temporal” del código –además de las ventajas obvias del código fuente de alto nivel estructurado–.

6. Afirmas “el último lenguaje/librerías/framework XYZ es el mejor”. O que “C y ensamblador desaparecerán”, o peor aún, “el C++ reemplazará al C en los sistemas operativos”.

   Cualquiera que haya vivido o leído sobre las diferentes tecnologías y soluciones informáticas entenderá muy bien lo que explica Brooks en “no existe la bala de plata” (There is no silver bullet, mejor traducido como “no hay soluciones mágicas”). Cada lenguaje además tiene sus ventajas y desventajas para cada tipo de problema. Hay cosas que se pueden solucionar mejor con un lenguaje que con otros. Por ejemplo el tratamiento y control de la memoria –gracias a los odiados punteros y asignación dinámica de memoria– que se puede hace con C son casi imposibles o tan costosos que no merece la pena en lenguajes como Java. Aún más, hay cosas necesarias en determinados programas que sólo se pueden hacer con ensamblador, como gestionar registros, TLB, cache, etc.

   El que crea que con su lenguaje preferido puede solucionar todo es como el refrán para el que sólo tiene un martillo todo lo que ve son clavos. La informática y programación es mucho más amplio que programar sistemas de facturación o páginas web.

7. Te dicen que puedes tener una race condition en tu código y pones cara de pasmado.

   La programación de sistemas modernos es cada vez más compleja, lo que hace que habitualmente se usen modelos de multiprogramación, programación concurrente y programación distribuida. Incluso la programación web es un ejemplo típico de multiprogramación. Todos esos modelos tienen asociados los problemas de concurrencia por compartición de recursos que hacen que los programas tengan fallos que parecen casi aleatorios aunque los algoritmos analizados independientemente sean correctos. Los conceptos y problemas de concurrencia son de los más difíciles de aprender, lo que sólo se logra con el estudio de los problemas fundamentales y mucha práctica.

8. Piensas que en la universidad deberían enseñar Java desde el primer curso y que enseñar Pascal no tiene sentido.

   Este es el típico argumento de los que piensan que la universidad sólo debe enseñar lo que “demanda el mercado”, o aún peor, que él o ella sólo debe aprender lo que demanda su mercado.

   El primer objetivo cuando se empieza a programar es aprender qué es un algoritmo, cómo se representa en un lenguaje de alto nivel, estructurado, secuencial e imperativo –es el modelo más usado y con más métodos formales de diseño y verificación–. Lenguajes como C++ o Java son antes que nada estructurados, secuenciales e imperativos.

   Estos son conocimientos previos necesarios para aprender correctamente las abstracciones y estructuras orientadas a objetos, empezar con estos lenguajes con abstracciones y construcciones más complejas sólo introducen problemas y ruido en el aprendizaje, y lo que es peor, introduce vicios que luego son muy difíciles de eliminar.

9. Te han explicado alguna que tu código quizás se ejecute más rápido si lo compilas para reducir el tamaño antes que optimizar código y has pensado que te engañaban.

   Así como está enunciado parece una tontería, pero sólo podrían entenderlo los que tienen un conocimiento más profundo de los que conocen a la arquitectura del hardware que ejecutan al programa. Esto significa conocimientos de gestión de memoria virtual, memoria cache, características del TLB, etc. (De hecho este es un caso real, el núcleo del Linux, la velocidad de los procesadores se incrementó notablemente más rápido que la memoria RAM, por lo que el papel de las técnicas de caché creció en relevancia).

10. Eres parte del movimiento mileurista, o te quejas del intrusismo laboral.

    No conozco a ningún buen programador que cobre mil euros al mes –y conozco a muchísimos, la ventaja de haber sido su profesor–. El paro de los programadores es casi cero –casi diría que negativo en Balears, es una lucha dura evitar que los buenos programadores que están en tercero de informática no empiecen a trabajar sin acabar al menos la técnica, luego se eternizan como alumnos–.

    Además, ¿no hablan tanto al “libre mercado”? Un buen programador no tiene problemas para encontrar puestos mejores. Un buen programador no está preocupado del “intrusismo”, si los “intrusos” son buenos programadores, bienvenidos sean.

    Si en cambio no lo son no representan ningún problema para él, todo lo contrario, le quitan el trabajo que él no está interesado en hacer.

Y por último y aunque está fuera de las diez no podría dejar de ponerla

10bis. Si te dicen expresiones regulares y sólo tienes un problema

Yo he cometido todos esos “pecados”, y sigo cometiendo algunos. Pero intento dejar de hacerlo. Lo malo es que cuando ya deje de hacerlo tendré muchas más “pistas” que agregar a la lista, y así volveré al punto inicial nuevamente.

O quizás eso es justamente lo mejor de ser un programador.

Edición: Paco propone una que no sé cómo se me ha pasado:

10bis2. Consideras que ya eres suficientemente buen programador y que debes dedicarte a otras tareas como el análisis, diseño o planificación. La programación es una tarea secundaria y trivial que puede hacer cualquiera.

Me hizo mucha gracia –sobre todo porque me identifiqué con algunas– el artículo Ten signs that you’re not as clever as you think. Pongo una traducción liberal de las diez reglas –no me atrevo a arruinar también las cortas pero simpáticas explicaciones–:

1. Deploras la obsesión con la cultura de los celebridades, pero tienes opiniones sobre algunos famosos.

2. Usas la palabra nazi, fascista o comunista (o el típico español “progre”) para describir lo que no te gusta.

3. Alguna vez has dicho “no tienes derecho a juzgarme”.

4. Sermoneas sobre el medio ambiente pero comes carne de animales de granjas.

5. Has llamado a un país “tierra de inmigrantes”.

6. Has dicho algo muy interesante y lo arruinas con “lo que nos lleva a la cuestión” (en el original begs the question).

7. Recuerdas a todo el mundo que “no quieres volver a la edad media” (en el original “oscura”).

8. Citas a una película como prueba.

9. Te describes como una persona creativa.

10. Has dicho algo, alguna vez con un mezcla de sarcasmo y risa forzada (como un “yayaya” de superioridad).

Las actualizaciones del atime son de lejos la más grande de las deficiencias que Linux tiene actualmente. Eliminando las actualizaciones del atime mejorará el rendimiento de los Linux normales más que todas las mejoras del pagecache de los últimos 10 años, combinadas. — Ingo Molnar

No puedo estar más de acuerdo, hace tiempo que todos mis ordenadores –de escritorio y hasta del Menéame– tienen deshabilitada las opciones de atime y diratime. No sé porqué las distros como Ubuntu ya no vienen así por defecto.

Es muy fácil, basta agregar las opciones “noatime,nodiratime” en el /etc/fstab. Por ejemplo (la siguiente es la línea del servidor del menéame):

Actualización: Leo en LWN que no hace falta el nodiratime si se especifica atime, ya que este último lo engloba.

/dev/sda1    /   ext3    defaults,noatime,nodiratime,errors=remount-ro 0       1

Si no quieres reiniciar el servidor/ordenador para que tengan efecto las modificaciones, también es muy fácil:

mount -o remount,noatime,nodiratime /

Breve explicación

Siguiendo el diseño original de Unix, para cada fichero se almacenan una serie de “metadatos”, entre ellos la fecha de creación/modificación –mtime–, modificación del inodo –ctime–, y también la fecha de último acceso –el atime–. Eso significa que aunque se acceda a un fichero para sólo lectura se genera una escritura al disco para actualizar la hora de acceso –tiene precisión de un segundo–. Esto ocurre aunque el contenido del fichero esté completamente en el pagecache, lo que lo hace aún más ridículo.

El noatime indica que no se actualice la hora de acceso a un fichero. nodiratime es similar pero para accesos a directorios (por ejemplo cuando se busca un fichero por su nombre).

¿Por qué se sigue usando? Sobre todo por razones históricas y porque unos pocos programas de correo –creo que también el mutt– lo usan para verificar si han llegado un correo nuevo. Ya no tiene ni sentido para esto, porque el Linux tiene interfaces más adecuadas para ello, por ejemplo el inotify, que notifican a los programas cuando se modifica un fichero o directorio.

¿Cómo llamar al envío de una carta un 31 de julio, justo cuando comienzan las vacaciones, y te dan cinco días para que retires comentarios de terceros en un lenguaje del tipo “rogamos encarecidamente”? ¿Cómo además llamarías si no especifican exactamente qué es lo que consideran que es delito? ¿Y si además pretenden que creas que con eso ya estás “debidamente informado” de que hay un delito y que si no haces caso iniciarán acciones penales contra tí y todo el que se tercie? No sé, pero me suena muy similar a estilos mafiosos de las pelis –nunca recibí una carta de una mafia real, creo–. O muy cachondo, vaya uno a saber.

Pero es que hoy otra de esas “cartitas” de abogados exigiéndose retirar críticas que molestan a su “cliente” (que por cierto es una empresa, no hay persona física mencionada). Qué manera de perder y hacer perder el dinero y tiempo.

Con todo lo que pasó últimamente nadie nos asegura que imperará el espíritu de la ley y el sentido común, pero ya está bien de tener que aguantar y hacer extorsiones para limitar la libertad de expresión en cuanto se hace la mínima critica a determinadas empresas u organizaciones.

PS: El web del “cliente” es cutre a más no poder, estilo “HOYGAN” en la portada –todo en mayúsculas–, con HTML inválido que no deja ver enlaces y con títulos tan fantásticos como Página sin nombre. Espero sinceramente que sus encuestas sean de mejor calidad técnicas que su sitio web. Si me pidiesen un consejo les diría que gasten menos en “cartitas veraniegas” para invertirlo en mejorar el sitio y dar allí respuestas a las críticas muy razonables que les hacen por la falta de información técnica de las encuestas, todos –módulo abogados– saldríamos ganando.

PS2: Comentarios en menéame, gracias.

Debe ser cierto eso que dicen unos pocos iluminados que el software libre provocará el hambre de los programadores. En dos semanas de viaje de vacaciones hice larguísimas caminatas y muchos juegos en las piscinas o playas con las niñas. Sólo desayunaba (con muchos zumos), comía y cenaba (en general en restaurantes buenos o pasables y con mucha comida regional). Nunca más de dos cañas o copas de vinos diarias.

Lo único que dejé de hacer es programar en el Menéame. Y sin embargo acabo de pesarme y subí dos kilos. WTF? Tiene varias interpretaciones. Una es que programar también consume calorías…. o que ayuda a comer menos.

Pero seguramente le estaré dando la razón a muchos iluminados: el software libre no te hará engordar. Por eso es mejor prohibirlo, sobre todo en países pobres donde el alimento diario no tiene las calorías suficientes.

PS: Como cada año, regresé agotado de las vacaciones, menos mal que me queda agosto para recuperarme antes de que empiecen los follones post estivales. Espero que tengan razón los que afirman que lo importante es el cambio de ritmo.