Había una vez un programador que había recorrido el bosque de Internet buscando el árbol de las columnas de MySQL para concatenar tres frutos -dos partes de enteros y una parte de cadena- y así llenar una canasta que su abuelita le había pedido con la información de los visitantes de su host. Como su abuelita prefería las hojas de Bill el programador debía guardar aquella concatenación en una canasta de ODBC, y para su sorpresa la canasta parecía no llenarse por más que pusiera en ella los frutos una y otra vez. Por un día entero se recorrió los bosques de hipertextos de Sun y no encontró una respuesta a su situación, hasta que ya entrada la noche -algo a lo que estaba acostumbrado el programador, si se me permite la aclaración, así que no debería sorprender el que le tocara olvidarse de sus necesidades fisiológicas por una noche- un hierofante en la blogósfera en un rincón poco iluminado por los soles de Google le explicó que en ODBC la función de concatenación solo acepta frutos de cadena, y que los frutos enteros hacen que se desintegren en el aire y no llenen las canastas como uno esperaría. El hierofante le recomendó al pobre desdichado que pasara por un cast los frutos enteros antes de concatenarlos. El programador volvió donde su abuela, pasó por un cast los frutos enteros, los concatenó y los cocinó con ODBC. La abuelita se alegró mucho al ver su lista de invitados poblarse con cada visita a su host.

Leer más »

La fortaleza que le ha valido a Ajax su puesto de supremacía entre las tecnologías de mayor crecimiento en Internet es la posibilidad de modificar el contenido de una página sin tener que refrescarla. Implementar un sistema con Ajax para actualizar la información de una página no representa mayores dificultades cuando se hace un único llamado, pero cuando se hacen múltiples comunicaciones, muchas de ellas sin esperar acuse de recibo, la situación requiere de algún método para regular las solicitudes.

La técnica convencional para regular el paso entre procesos es la declaración de un semáforo, un registro con el que los procesos determinan cuándo un recurso está siendo empleado y en qué momento está libre.

Leer más »

A pesar de haber sido proyectado para resolver una situación muy particular, el plugin indizar ha tenido una buena acogida, lo que ha supuesto que usuarios de todo el mundo lo pongan a prueba y encuentren requerimientos que jamás me habría imaginado. En particular uno de estos requerimientos para los que no había sido diseñado proponía reflejar el orden correcto de numeración de los capítulos en la URL cuando el post estuviera dividido en algo del siguiente estilo:

Prefacio – Capítulo 1 – Capítulo 2 – Capítulo 3.

Como se puede suponer, la URL asignaría al Prefacio la primera posición, y al ‘Capítulo 1′ la segunda posición, lo que se reflejaría en la URL como chapter/2 cuando en realidad su nombre es ‘Capítulo 1′. La numeración asignada por el escritor no se reflejaba en forma correcta en la URL.

Para esta situación se programó esta nueva versión de Indizar, y de paso se hicieron algunos nuevos ajustes que aparecieron en el período de desarrollo de esta nueva versión.

Leer más »

La idea detrás de un plugin es -resumiendo- hacer más fácil la vida de los usuarios, aunque eso signifique la muerte de la vida social del programador. Pequeñas modificaciones pueden hacer grandes cambios en toda la lógica de un algoritmo, mandando al trasto con ideas preconcevidas sobre interfaz de usuario, como sucedió en concreto con MudSlideShow y Lexi. Ambos plugins hicieron nuevos ajustes en Minimax y de ahí los cambios se sucedieron en cascada por todos los plugins que hacían uso de la librería Mínima de Ajax. Alguna vez leí que un programador es aquel que dedica días enteros a encontrar la forma de hacer en 1 minuto lo que le toma 10. Me siento identificado con esa frase.

Leer más »

Desde Helsinki, ciudad natal de Linus Torvalds, preguntaron si podían usar Lexi para leer datos desde una página en Blogspot. Luego de hacer unas pruebas me di cuenta con horror que no funcionaba cuando se declaraba el feed sin caché, pero cuando se almacenaba en caché todo volvía a su curso normal. ¿Qué pasaba? Hablando a nivel de código, la diferencia entre la versión con caché y la versión que no usa caché es la librería que cada opción particular implementaba para leer los datos; los feeds almacenados en caché empleaban la librería de RSS disponible en WordPress, y los restantes empleaban un grupo de funciones básicas creadas para este plugin. La razón por la cual hice esta separación es porque con la librería de WordPress no había encontrado la forma de actualizar los datos en un período menor a 10 minutos, así que creé los mecanismos para leer los feeds directamente para estos casos particulares donde hay una alta frecuencia de actualización. Por cuestión de utilidad solo me preocupé por el formato RSS y descuidé las demás opciones. He ahí el por qué Lexi no entendía ciertos casos particulares; Blogspot usa RSS como una segunda opción, porque su formato por defecto es Atom. La solución rápida era por lo tanto leer los datos con la librería de WordPress que, dicho sea de paso y aceptando mi error, debí haber diseñado como opción por defecto a nivel de interfaz desde un principio, pero la versión actual no daba la suficiente claridad al usuario sobre cuándo usar esta opción, así que en el caso propuesto desde Helsinki era seguro que se estaba usado la opción por defecto, es decir el mecanismo sin caché.

Leer más »