Antiguo y abandonado blog de Ricardo Galli :-(

Un ya “viejo” conocido me dejó el siguiente comentario:

Yo me he pasado años dando clases a los MBA´s de modelos de negocio en Internet y hoy esas asignaturas se han quitado del programa. ¿Porque? Internet ya no está de moda y el que paga manda…:-) también en la enseñanza. Sin embargo, no estoy de acuerdo con la generalización. Tengo amigos dispuestos a pagar oro por buenos programadores y no los encuentran. muchos de ellos prefieren la “tranquilidad” de un trabajo de esos que describes en grandes empresas o administraciones a arriesgar el puesto en una pequeña, con grandes posibilidades de crecer pero corta vida

EN primer lugar me parece que Internet está más de moda que nunca, lo que pasa es que me parece que los business plans son los que se han pasado de moda. En la burbuja 1.0 eran maestros con el Excel y PowerPoint para hacer grandes planes, que así han quedado

Pero lo fundamental que quería contestar es la última parte, la de los “programadores” que prefieren tranquilidad antes que el “oro”.

Creo, estoy convencido, que los mejores programadores no tienen como motivación fundamental ganar “fortunas”. Si es que realmente te apasiona la programación la pasas mucho mejor en eso que intentando gastar dinero, o al menos es lo que me pasa a mí (y no me catalogaría como de “los mejores programadores”, pero me divierte y paso de muchas otras cosas).

Creo que el ya mítico error está en seguir creyendo que las motivación fundamental de todos es el dinero. No lo es, creo que es evidente. Si es que realmente un programador de esos de “grandes empresas” rechazó ofertas millonarias podría haber pasado que:

1. No se haya fiado de la oferta.

2. No le haya interesado ganar más de lo que ya gana.

3. Se lo estaba pasando muy bien en su empresa.

4. Todos: #1, #2 y #3.

O puede ocurrir todo lo contrario, que quizás sea un “producto de consultora” que reconoce sus límites, o que sencillamente la programación no sea lo suyo. Lo malo es que en ambos casos quizás hayan apuntado a la persona equivocada, o que no hayan sabido vender el proyecto.

A muchas personas nos ocurre que nos hablan del business plan y se nos saltan todas las alarmas. No es que sea malo planificar, sino que si alguien habla de planes de negocios a un programador quizás se está olvidando de lo fundamental para esa persona: además de ganar razonablemente bien, ¿tendrá tiempo para adaptarse y aprender? ¿será interesante el proyecto? ¿no será que si se remarca tanto al business plan es porque hay demasiados MBA y pocos técnicos?

PS: También puede ocurrir que se tenga miedo a cambiar por la posible inestabilidad, cosas de las hipotecas, supongo. Si es así, cómo nos están jodiendo las hipotecas.

Ruby on Rails es perfecto para la Web2.0, el hype va incluido en el lenguaje — Hass, en la fisgona.

En respuesta a mí mismo (y por extensión a edans):

Programar es fácil. Programar bien es muy difícil. — Richard Stallman

Vía Menéame leo un artículo muy acertado de Enrique Dans ¿Alguien ha visto un programador?. Lo comenté muchas veces en este blog, pero para dar unas respuestas muy escuetas a lo que creo son algunos de los problemas:

1. Las empresas grandes que pueden pagar bien a los buenos programadores tienen obsoletas estructuras piramidales que lo único que logran es quemar a los buenos programadores en menos de un año.

2. Las puntas de esas pirámides suelen ser aquellos que no quieren saber nada de programación y se dedican a ascender, delegando toda responsabilidad a los “analistas senior”, que a su vez delegan y culpan a los “analistas junior” y así abajo en la cadena hasta llegar al buen programador que está a punto de dejar porque ya está quemado.

3. Empresas grandes que venden carne de ingenieros al kilogramo pagando salarios de becarios y haciendo verdaderas chapuzas porque al final nadie es el responsable. ¿Alguien recuerda al web del Congreso y tantas otras administraciones por ejemplo?.

4. Las administraciones y grandes empresas, como tienen problemas en mantener a sus buenos programadores (por 1 y 2), contratan ingenieros al kilogramo a las que se dedican a venderlos.

5. Las empresas pequeñas buscan programadores “básicos”, que sepan un poco de Visual Basic, con suerte Java, y montón de otras cosas como instalar MS Office o “un servidor Linux”.

6. Muy pocas empresas tienen asumido que sus programadores requieren un entrenamiento inicial especializado en lo que va a hacer –que no puede brindarle ninguna universidad o ciclo formativo– y que esos programadores también necesitan una formación continua –vía cursos específicos o tiempo y tranquilidad necesario para trabajar en proyectos con técnicas y métodos más modernos y diferentes–.

7. El problema de la disfunción metacognitiva, muy generalizada entre los informáticos.

8. Existe una especie de presión a las universidades para que “formen profesionales adecuados al mercado del trabajo”. Ese mensaje ha calado profundo en muchos profesores, pero aún más entre los alumnos que exigen que se les enseñe Java desde primero –y nada más que Java– porque es lo que demanda el “mercado laboral” y que hace que pasen olímpicamente de otras asignaturas que marcan diferencias, por ejemplo álgebras o conceptos complejos de la “ciencia de la computación”.

9. Quizás por #6, muy pocos programadores dedican tiempo a leer, aprender y navegar mucho por Internet, que se ha convertido en la fuente principal y fundamental para aprender las nuevas técnicas, tendencias y formas de llevar adelante proyectos. Existe una especie de sentimiento generalizado –que todavía no puedo comprender, con lo guapa y divertida que es la informática y programación– de “en mi poco tiempo libre me olvido del ordenador”…

Lo que me lleva a un punto bastante crítico y quizás el más importante, aseguraría –y es una opinión bastante generalizada– que más del 70% de los alumnos de las ingenierías informáticas están completamente desmotivados y/o desinteresados por su carrera, especialmente la programación.

Quizás se debe a que durante muchos años de habló que era la “carrera del futuro”. Quizás también se deba a que ser un buen programador es cada vez más difícil y que obliga a un esfuerzo intelectual muy importante. Quizás también se deba a la “falta de perspectiva” de cómo es la profesión en los centros importantes: mucho esfuerzo pero a la vez mucha autoconfianza y coraje.

¿O quizás se deba a que parece que muchos piensan que un título de ingeniero debe ser un salvoconducto para nunca pasar por la etapa de mileurista cuando el único salvoconducto es mostrar lo que uno vale programando de verdad y sacando proyectos adelante… pero esto no lo lo puede dar un título de forma automático, se necesitan unos cuantos meses, o años. ¿O es que ahora hay que tener una mega e infinita hipoteca antes de los 25 años?

Seguramente los profesores tenemos parte de esas culpas. Conozco a muchos que piensan que un “ingeniero no necesita programar”, conozco también a muchos que ya no se acuerdan de cómo se programa. Pero también conozco a muchos profesores que son unos monstruos programando y dando clases, pero esos justamente son los más “odiados” o ignorados por esa gran mayoría de alumnos que sólo desean aprobar las asignaturas de la forma más sencilla, segura y sin liarse demasiado el coco. Así muchas veces terminan festejando al profesor que les cuenta batallitas por que así sí que aprenden “cosas prácticas” y útiles.

Pero sí, los profesores –incluido yo–, somos parte importante del problema

Si las generaciones que nos siguen fuesen mejores el problema no sería grave, se solucionaría con el cambio generacional. Pero tengo serias dudas de que pueda resolverse de esa forma.

Yo sí he visto unos cuantos buenos programadores. Ganan muy bien, bastante más que un profesor de universidad. Eso sí, no lo han logrado en los primeros seis meses, a pesar que son unos “cracks”. Además cuesta mucho encontrarlos, y cuando se los encuentra suelen estar muy contentos en su trabajo actual que han conseguido después de años.

Sólo aquellos que hacen cosas complejas y sofisticadas valoran a esos profesores y asignaturas que le enseñaban esos conceptos tan complejos y sofisticados. Los que sólo se dedican a instalar anti virus y ofimática siempre pensarán que el estudio para ellos fue una pérdida de tiempo. No les falta razón, así está diseñado –a posta– el mercado del software como “producto”. Una pena –para ellos– que este mercado ya esté obsoleto.

The year was 1988, (Era en 1998)
I almost lost my nerve. (Casi perdí mis nervios)
For at that time, I had to climb (En aquel tiempo tuve que escalar)
a long, steep, learning curve. (una interminable, de mucha pendiente, curva de aprendizaje)

For I was then expected to (Entonces tenía que ser)
not just a user be, (no sólo un usuario)
but also a developer (también un programador)
and sys-admin. All three! (y administrador de sistemas. ¡Los tres a la vez!)

vi and C shell, Bourne shell, cron,
lex, yacc, and gcc,
man, make, and diff, grep, find, and biff,
all these were new to me. (todos ellos nuevos para mí)

And if all that weren’t quite enough (Si eso no era suficiente)
to make me fume and fret, (para enfurecerme y agobiarme)
I also had to learn to use (también tuve que aprender)
this thing called “Internet.” (una cosa llamada “Internet”)

Then one day while on Usenet, I (Entonces un día en Usenet)
heard someone recommend (escuché a alguien recomendar)
a language that I’d never used (un lenguaje que nunca había usado)
but soon thought a godsend. (pero que pronto lo consideré un regalo de los dioses)
…
The language, it was Perl, of course, (el lenguaje fue por supuesto Perl)
I took to right away. (inmediatamente lo adopté )
It was such fun, to get things done, (fue tan divertido hacer las cosas)
that work seemed more like play. (que el trabajo se parecía más a un juego)

…
“Information Superhighway,” (“Autopistas de la información”)
the phrase was all the rage. (la frase era la última moda)
Another, less insipid, was (otra menos insípida)
“The Information Age.” (“La era de la información” )

“The Web,” “The Web” was everywhere, (“La web”, “La web” estaba en todos lados)
the press was tickled pink. (la prensa flipaba)
“The Web,” “The Web,” their only care. (sólo se preocupaban de “La web”, “la web”)
It could drive you to drink. (podían convertirte en un alcohólico)

Now after this publicity, (Después de toda esa publicidad)
there appeared a whole slough (apareció un enorme lodazal)
of self-proclaimed “Web programmers” (de auto-proclamados “programadores web”)
who didn’t have a clue. (que no tenían la mínima idea)
…
I played around with Java some, (Estuve probando Java)
and even Python, too, (incluso Python)
but they just never seemed to fit (pero nunca parecían ajustarse)
with what I had to do. (a lo que tenía que hacer)

So I continue to use Perl (Así que continué usando Perl)
and C when speed is key. (y C cuando la velocidad era fundamental)
Though neither is now “cutting-edge,” (Aunque ninguno es lo “último”)
they both work fine for me. (funcionan bien para mí)
…

Segmentos de unos bonitos versos de Stephen B. Jenkins (vía Guillem) que hace que todos los programadores nos sintamos identificados total o parcialmente.

Habrá otros que se cabreen –especialmente por la estrofa dedicada a los “programadores web”– y digan que es elitista y una provocación. Si es así lo mejor que pueden hacer es pedir una beca en Indra y tendrán oportunidad de hacer algún web de la administración tan exitoso como la del Congreso

Tal como me dice el recordatorio, hoy me toca hablar de Twitter. Pero no hablaré de si es una tontería mayúscula, de algo muy útil y de la revolución de las comunicaciones… eso que cada uno decida, yo también programo las mismas “tonterías”.

El tema viene del artículo y debate Twitter Problem, surgido a raíz de una entrevista a Alex Payne, uno de los desarrolladores de Twitter. Me llamó muchísimo la atención.

Un pequeño resumen de la entrevista y los temas que se comentaron:

(more…)

Con Kolivas ha presentado una nueva propuesta del scheduler para el kernel. Parece tan buena, y es tan simple y clara la estructura que seguramente será integrada rápidamente (quizás para la versión 2.6.22), el Rotating Staircase Deadline Scheduler.

Este nuevo planificador sigue teniendo, como los anteriores y estándar en UNIX, una lista activa y una inactiva. Los procesos sólo se seleccionan de la activa, cuando consumen todo su tiempo se mueven a la inactiva. Cuando ya no hay más procesos en la lista activa se intercambian los punteros y la que estaba inactiva pasa a ser la activa –y viceversa–.

Pero lo anterior no es lo nuevo, sino en cómo está estructurada cada una de esas listas. Como es de esperar, continúa con las bien conocidas “múltiples colas con retroalimentación”. Cada lista está dividida en varios niveles, cada nivel corresponde a una prioridad. Los procesos son movidos dinámicamente de un nivel a otra dependiendo de su prioridad dinámica –el nice en UNIX–.

Los procesos son seleccionados siempre por el nivel de mayor prioridad, sólo si no hay más procesos en ese nivel se pasa al siguiente –tal como se hace en el método de múltiples colas–.

A cada proceso se le asigna dos límites temporales –o cuantos–, una para el nivel en que están y otro para el tiempo máximo que pueden pasar antes de ser movidos a la cola inactiva. Cuando a un proceso se le acaba el tiempo para el nivel en que está es movido hacia el nivel inferior.

Pero además cada nivel tiene asignado un tiempo máximo, si se supera ese tiempo, todos los procesos que todavía están en dicho nivel son movidos al nivel inferior –le llaman una “rotación menor–.

Finalmente, cuando un proceso acaba su cuanto –o expiración– es movido a la cola inactiva. Cuando ya no quedan más procesos en la cola activa, se intercambian las colas, le llama “rotación mayor”.

Este método es muy simple, mucho más sencillo que el método actual, donde la prioridad está calculada por el tiempo de espera de cada proceso. Este cálculo es bastante complejo e impredecible, por lo que no se pueden calcular tiempos de respuesta máximo. En cambio con el nuevo método sí se puede calcular y demostrar formalmente que existe un tiempo máximo, y por lo tanto no se producen esperas infinitas (o starvations).

Parece que los tests que están haciendo para cargas extremas está dando resultados espectaculares, así que seguramente será rápidamente admitido en la siguiente ronda de desarrollo para el 2.0.22. La verdad es que ste nuevo scheduler me impresionó bastante, en primer lugar porque es de tan simple es bello, y en segundo lugar porque reusa, simplifica y mejora ideas que tienen 30 años.

Pero también me sorprende su autor, un médico en activo, solucionando semejante tipo de problemas informáticos.

Disclaimer: este apunte es una procastinación tamaño baño.

(more…)

Como visión casi opuesta a mi apunte de ayer, Jonathan ‘Wolf’ Rentzsch asegura que a los programadores no ls gusta programar sino resolver problemas [que a menudo significa programar algo].

Pues sí y no.

Sí porque a todo el mundo le encanta resolver problemas, a los fontaneros, ingenieros y abogados, sólo faltaría que sólo a los programadores e informáticos nos gustase resolver problemas.

No porque pretender que sólo a los programadores les gusta resolver problema es de una soberbia insoportable: “somos la hostia, más que los demás, a nosotros sí nos gusta resolver problemas –a pesar que creamos muchos más de los que solucionamos–”. Supongo que no se lo pensó demasiado al escribir el artículo.

Muchas veces resolver problemas de fontanería o electricidad (cualquiera que se haya quedado sin luz o con una cañería atascada un viernes a la tarde lo puede atestiguar) puede ser más gratificante que resolver el problema de un dirección IP que se representa mal en enteros de 32 bits porque el lenguaje no puede trabajar con enteros sin signos.

Antes de ir a la universidad ya tenía el título de “técnico mecánico-electricista”. Durante mis años de estudio hacía trabajillos de electricidad y mecánica –de hecho casi patenté una herramienta muy simple que diseñé, fabricaba y vendía a buen precio para ajustar más fácilmente la correa del aire acondicionado de un modelo de Ford– y era divertido y ganaba bastante buena pasta cuando apenas tenía 16 años. Podría haber seguido así y quizás hoy estaría mucho más holgado económicamente… y vaya si eso sí era resolver problemas reales. La gente encantada.

Pero no, por suerte a muchos también les gusta resolver otro tipo de “problemas”, aunque sean muchos menos acuciantes para el mundo real y bastantes más complicado: primero hay que crear el problema (tener la idea de un programa, aunque éste solucione a otro es un problema en sí mismo) y luego además hay que resolverlo en un lenguaje matemático, estricto y completamente abstracto.

Para la mayoría de la gente –incluso para la mayoría de auto proclamados programadores– eso es un auténtico coñazo. Supongo que es lo que diferencia entre un programador mal, normal y uno que se sale de la escala.

Además supongo que lo mismo que es aplicable a programadores es aplicable a cualquier rama de los oficios y profesiones, sobre todo aquellos que exigen un alto nivel de trabajo intelectual. Yo sería incapaz de escribir un libro decente, o de analizar en profundidad la nueva Ley de Propiedad Intelectual, o de hacer complejas fórmulas matemáticas para demostrar oscuros teoremas que sólo podrían ser apreciados y valorados dentro de 50 años. Hay gente para todo, y seguramente ellos también se divierten con lo que hacen.

Los programadores son programadores porque les gusta programar. –Scott Rosenberg

La cita en una muy buena entrevista, Software is hard. Y no podría estar más de acuerdo, en ambas, la cita y el título. La programación es abstracta y compleja, sólo soportable por aquellos a los que les gusta programar.

Lema #1: Si no te gusta programar no eres [buen] “programador”, y nunca lo serás a menos que modifiques tus gustos.

Lema #2: Cuando uno hace lo que le gusta lo intenta hacer mejor posible, cometerá muchos errores, pero aprenderá de ellos además de pasárselo en grande.

Lema #3: Los que se sienten obligados a programar –aunque la URSS ya no exista– sin que les guste demasiado se preocupan más de otros temas que de hacer [buenos] programas, aprender, practicar o ajustar sus preferencias.

Lema #4: Buscar la protección o reconocimiento social mediante procesos exógenos, por ejemplo “regulaciones legales”, es un síntoma del Lema #3.

No, este apunte no va de conventos, o sí. Ayer leí un artículo –al que no voy a enlazar porque no se trata de escarnio público de nadie, y tampoco es importante– que es una muestra perfecta del desconocimiento general que hay sobre la “informática profunda”, esa que en teoría se estudia y se aprueba en las universidades pero que parece nadie toma en cuenta ni hace las relaciones pertinentes.

En el artículo que hago referencia había un resumen-traducción sobre las diferencias entre Python y Java. Uno de los temas era las closures, que para cualquiera que haya estudiado álgebra en su carrera lo debería asociar inmediatamente a clausuras, sin embargo el autor no supo siquiera traducirlo correctamente –lo tradujo como “cierre”–.

(more…)

Vía barrapunto leo en Baquia ¿Quién mató a los webmaster?. No sé si estaría de acuerdo con lo que dicen de la desaparación de esta “espcialidad”, pero…

Evidentemente hay que cuidar y proteger a estos puestos de trabajo, porque detrás de cada web hay un autor, y hay que pagarles por su trabajo. Por lo que propongo:

1. Hacer una ley específica para protegerlos y fomentar los web y la cultura, haremos la LPW.
2. Un canon que se cobrará a todo dispositivo capaz de visualizar el código fuente de páginas web.
3. Buscar la forma de implantar DRM para evitar la copia de código fuente HTML, diseños y hasta comandos como /etc/init.d/apache reload.

–

Perdone señora ministra, nos dice el Ingeniero Victor Hugo que hay una forma mucha más simple y eficaz de lograr lo mismo y además con el apoyo de la mayoría de webmasters: los Colegios Oficiales de Webmísters.

–

Es usted un genio Ingeniero Ramoncín.

1. Que un programa tenga bugs, es lo más normal del mundo… si lo sabré yo que genero los míos propios.

2. Que un programa que genera y almacena muchos ficheros en disco no verifique que lo pueda hacer, ya es una chapuza más seria. Pero vaya, nos pasa incluso en las mejores familias.

3. Que un programa decaiga de forma tan brusca y genere mensajes de error textuales cuando se espera una imagen en vez de enviar una imagen alternativa es un una chapuza más grave, pero también es de esperar, a veces nos ocurre.

4. Que el administrador del servidor se olvide de quitar los mensajes de debug en un servidor en producción, también es una chapuza, nos ocurre a todos –sobre todos a los para-administradores de servidores Windows–.

5. Un disco no se llena en pocas horas, lo hace de forma bastante lenta y progresiva. Que no se hayan dado cuenta indica que a nadie se le ocurrió que en un sistema que genera muchos ficheros hay que controlar cómo están de capacidad ya es una chapuza bastante importante, ya casi imperdonable.

6. Que además el servidor, que se dice de Web 2.0 y según ellos que han gastado varios cientos de miles de euros, esté así desde hace más de 24 horas cuando es muy fácil de solucionar (borrar los ficheros más antiguos) ya le quita la mínima credibilidad que podían tener.

Es lo que tiene creerse el rey del mambo, y que esto de la Web 2.0 es hacer unos pocos cientos de líneas de código, ponerlo en marcha que la magia o la “comunidad” se encargará de que funcione. Pues no.

¿Buenas alternativas?

Nota: Ya que es una “crítica” y a mí me encanta hacerlas, como a casi todos de la blogocosa, ¿cuándo estos algunos bloggers empezarán a encajar mejor las críticas que reciben de respuesta a las suyas propias sin que tengan que difamar y entrar en falacias ad hominem? ¿cuándo se darán cuenta que no sólo ellos sino que detrás de todo proyecto o comunidad que ellos critican tan duramente también hay personas y no “robots” a los que les da igual que le digan de todo y que no van a responder nunca? En fin, supongo que es lo que queda después de tanto mal entendido relativismo del new age, y como dice Lobo de “chuparse demasiado…”.

Si te encanta criticar y mofarte de los demás desde tu blog, encaja las que van a ti con el mismo talante que esperas del receptor de las tuyas. Y responde con opiniones razonables y argumentos racionales, deja de recurrir a las falacias y hacerte el víctima de una put* vez (va en general, al que le pica… ).

Si la ley es el código, los parlamentarios son los programadores, y los jueces, jurados y abogados son la CPU (y los ciudadanos los sufridos usuarios).

Buena la metáfora de Dave, aunque tenga la impresión que la leí antes en otro lugar. ¿Lessig?.

Pero lo más interesante del apunte es que el sistema de justicia no es fuente de ética: no se preocupa por los “bugs morales [éticos]” del código, eso deben hacerlo en el Congreso (por eso “lo que hice es legal” o “lo dice la ley” no es siempre una buena justificación).

Pero como dice Dave, el problema es que el Congreso tiene demasiados abogados… entrenados y acostumbrados [legitimamente] para ignorar los “bugs éticos-morales” de la ley. Así estamos en un problema.

Como siempre tengo que provocar un poco a mis “colegas”, ¿qué pasaría si en el Congreso hubiese demasiados informáticos?. No tendríamos el problema de estar entrenados en ignorar los “bugs éticos”… es que ni siquiera sabemos lo que es ética, ni reconoceríamos los “bugs”. Echaríamos la culpa a los “usuarios” –los ciudadanos– y que si supiesen más de informática no habría esos problemas. Además haríamos las leyes secretas con acceso restringido y vía non disclosure agreements y licencia de usuarios, porque es la única forma de que puedan vivir los parlamentarios, jueces, jurados y abogados.

Siguiendo con el “espíritu” del apunte anterior. Txipi hizo diana, sí, se trata del artículo de Joel Spolsky “volver a lo básico”. Para alguien que no conoce esas bases, ni cómo funcionan los strings enseguida dice “vaya chapuza”, si eso se puede hacer con la clase XYZStringOnSteroids o con un buen SQL estándar…

[1] Alerta, aunque hay optimizaciones imprescindibles, la mayoría son prematuras, las madres de todos los males.

Hablando de SQL, en los últimos meses aprendí mucho de sql, pero sobre todo cuando hay que saltarse el “camino obvio” y buscar un hack para aquellas optimizaciones imprescindibles. Una que me paso hace pocas horas con el nuevo modelo de tres columnas del Menéame, en particular con la generación de las etiquetas que aparecen arriba a la derecha.

Seguramente para los expertos en bbdd es una tontería como una casa, pero para mí no fue obvio, es como el tema de seguridad. No es que te enseñan unas reglas y ya está, debes asumirlas e integrarlas en el proceso de desarrollo. Lo mismo me pasó con muchas cosas del SQL, especialmente del SQL, cuando se trata de generar una decenas de páginas por segundo, lo más rápido posible, aunque cada una tenga decenas de consultas a la bbdd.

Lo último, para ver si lo sabéis –expertos abstenerse, sólo dejad la pista –. Aquí se observa la última modificación que hice a esa función. En la columna de la izquierda se observa en amarillo el código que fue modificado por el de la derecha (sólo interesa la primera línea).

El de la izquierda ya es “raro”, ya que es un sql adicional. Pero el de la derecha es aún más bizarro para alguien que nunca lo haya pensado. ¿Por qué están ambos códigos? ¿por qué quedó como está? (sí, ya, es una optimización como dice el “log”).

PS: Curioso los trucos que hay que aprender a usar, sin algunos de los dos quizás hubiese tenido que quitar lo de las etiquetas porque el servidor no hubiese aguantado, al menos en horas pico. Hace un año atrás no se me hubiese ocurrido esta solución para quitar muuuuuuucho trabajo a la bbdd.

Actualización/Respuesta: es la cache

MySQL tiene un sistema de cache de consultas SQL. Para un web como el menéame, con cientos de consultas por segundo, esta cache es fundamental para no recargar el servidor. En el caso mostrado se trata de contar cuáles son las etiquetas más repetidas en las últimas 48 horas, lo que significa recorrer la tabla de etiquetas (tags) y contar unos pocos miles de etiquetas.

Si esa consulta se repitiese para cada página que se genera el servidor se cargaría demasiado. Por ello es indispensable que estén en cache. Una forma de consulta habitual es usar el date_sub, por ejemplo:

date > date_sub(now(), interval 48 hour)

Pero tiene un problema, el “now()” es un dato que varía constantemente, por ello el mysql no cachea estas consultas. Para permitir que se haga lo mejor es seleccionar una fecha que permanezca constante durante un tiempo razonable.

Por ello primero use una fecha de noticia publicada y luego lo simplifiqué a la hora actual (sin minutos ni segundos) menos 48 horas. Así se puede mantener en cache la consulta hasta una hora si es que no hay cambios en las tablas.

Para todo el desarrollo del menéame fui con mucho cuidado en permitir la máxima cantidad de cache posible, y cuando se sabe que no tiene sentido el cache (por ejemplo cuando verifica la IP de cada cliente) lo obligo a saltarse con el SQL_NO_CACHE para evitar gastar tiempo y sobre todo memoria. Por ejemplo en el control de votos de cada usuario:

 SELECT SQL_NO_CACHE count(*) FROM votes WHERE $where

Por lo demás, tengo configurado el mysql para usar 24 MB de RAM (antes tenía 16) para el cache de SQL.