Acabo de descubrir (por casualidad) que el navegador de Microsoft IExplorer no muestra bien esta plantilla si algún post contiene algún trozo largo de texto en cursiva (dentro de los tags <em> y </em>). Me imagino que será una cadena de efectos producidos al final por alguna incompatibilidad o interpretación extraña que hace IExplorer del HTML o del CSS.

Me da igual. (Por cierto, tampoco trata bien las dimensiones de una de las divisiones cuando se muestra un post en solitario).

Estoy hasta las $%&&*** del IExplorer. No lo aguanto más. Es más, he estado a un tris de que le dieran por ahí y no tocar la plantilla ni el post con el que tenía el problema.

Por favor, NO CUESTA NINGÚN TRABAJO INSTALARSE OTRO NAVEGADOR. Usad Firefox, o Chrome, o cualquier otro. Os lo digo por mi modesta experiencia de diseñador/programador web: IExplorer es UNA PESADILLA. Enlentece el desarrollo de sitios web, interpreta los estándares como le da la gana, NO ES MEJOR que los demás, ni más eficiente. Es cuestión de minutos instalarse otro; podréis seguir usando el IExplorer si queréis en la misma máquina (el otro no os dará problemas para instalarse/desinstalarse, al contrario que el de Microsoft), aunque no querréis seguir usándolo cuando veáis qué bien van los demás.

Y haréis un inmenso favor a los diseñadores. Lo cual redundará, a la larga, en un desarrollo de la web mucho más rápido y eficiente, lo que beneficiará a los usuarios.

La UMA ha concedido hoy un proyecto de innovación educativa (PIE) donde participo, con el que usaremos robots Lego Mindstorms NXT para asignaturas relativas a sistemas de control. Más trabajo

Por otra parte, sigo con mis pesquisas para parsers de BDL; ahora estoy revisando posibles herramientas que sólo generen ASTs (Abstract Syntax Trees), que a fin de cuentas, es de lo que se trata. Hay dos candidatas claras: Spirit y ANTLR. El problema es que la primera tira de las librerías Boost (no me gusta tirar de tanta cosa) y la segunda está en JAVA (lenguaje que cada vez me gusta menos, si es que me gustó alguna vez) y no genera para C++. En fin, seguimos al lío.

Entre las innumerables dudas que aún tengo sobre el universo, hay una que destaca especialmente: ¿cómo es posible que a estas alturas Adobe siga sin sacar una versión nativa para 64 bits de Flash?

Y no sé qué es peor: que lleven tantos años sin hacerlo porque el código esté tan chungo de pasar a 64 bits o que no quieran por alguna oscura motivación comercial…

En un fin de semana de tres días de supuesto asueto en el que, a saber, he dado un pasito más en el desarrollo de las nuevas plataformas para BABEL terminando un servidor de nombres distribuido, he arreglado un poco el sistema de estadísticas que usamos para las descargas de nuestros papers, he revisado un paper de próximo deadline, y he planificado más o menos un par de proyectos fin de carrera (luego volvemos a hablar de la cantidad de vacaciones que tienen los profesores ), vuelvo a retomar el siguiente paso para BABEL y voy revisando generadores de parsers para el lenguaje BDL, un subconjunto del IDL de CORBA definido por nosotros, porque el que tenía hecho con Bison no me gustaba mucho dada la cantidad de capas que necesitaba encima para pasarlo a C++.

En el proceso he encontrado una bonita tabla de parser generators aquí, y revisando los que generan directamente C++ y son LALR (aunque probablemente BDL no necesite tanto), al final me he quedado con Bisonc++ (no confundir con Bison++, que genera código un poco más lioso y no está nada documentado). Bisonc++ es muy parecido a Bison y Bison++, pero genera directamente una clase, con lo que me limpia un poco el código que tenía, y tiene una documentación completa adaptada de la de Bison. Viene en los repositorios de Ubuntu, así que qué más se puede pedir…

Pues que me quite más trabajo que el que me quita, que ahora mismo es bastante pero menos del que querría: me evita la interpretación de ficheros BNF y la generación del parser, pero sigue siendo demasiado lío sacar simplemente el árbol sintáctico de un trozo BDL (que sólo contiene declaraciones de datos), porque al tener las acciones mezcladas con las reglas sintácticas tienes que ir construyendo tú el árbol, y además si necesitas una tabla de símbolos te la tienes que hacer también tú.

Podría estar la cosa más avanzada en estos asuntos, digo yo…

P.D.: En el camino he encontrado una implementación de árboles compatible con STL que tiene una pinta decente.

Después de tener la fantástica y originalísima idea de diseñar un lenguaje de programación cuya ontología fueran variables aleatorias con el objetivo de programar con incertidumbre intrínseca en el lenguaje; después de rumiarla un par de días para ver cómo integrar el control de flujo con esos tipos de datos tan especiales, cómo manejar la variedad de especificaciones posibles para distribuciones de probabilidad; después de ilusionarme, en fin, comencé a caerme del guindo y a pensar que era imposible que se me hubiera ocurrido a mí primero.

Lo que era una sospecha hoy se ha hecho completamente obvio. Ay, si no fuera porque esta ingenuidad enfermiza ayuda a ser creativo, tendría que deprimirme y todo

Un simple truco para que no cuenten tus propias visitas en un sitio tuyo que tenga estadísticas (por ejemplo, este blog con WordPress). No es útil para todos los usuarios, pero en mi caso me soluciona el filtrado de estadísticas cuando navego con IPs dinámicas.

Se necesita tener una página web editable en algún lugar, llamémosle A, y que el sitio que contiene las estadísticas, llamémosle B, tenga páginas editables y se base en PHP.

Consiste en poner en A un enlace al sitio que tiene las estadísticas (simple HTML). Luego, en B, hay que editar la página que contenga el código de estadísticas (en WordPress, típicamente sidebar.php). Justo antes del bloque de código de estadísticas hay que poner:

<?php if ($_SERVER['REFERER']!='<aqui la URL completa de la página A>'): ?>

Y luego, tras el bloque de estadísticas:

<?php endif; ?>

Y listo. A partir de ese momento, siempre que visites tu sitio B pinchando en el enlace de la página A, no contará en las estadísticas. Incluso si recargas la página de B seguramente seguirán sin aparecer las estadísticas porque el navegador mantendrá el valor de la variable REFERER.

P.D.: La variable $_SERVER['REFERER'] puede no funcionar; depende del navegador que utilices. En Firefox va todo bien.